The expected ISA Server 2006 SP1 is on the way, Jim Harrison has blogged in the ISA Team Blog about the new features of this release. The ISA Server community is very excited about this announcement as externally by Tom Shinder on his blog.
I just delivered a webcast to the IT community in Brazil through Support Academy (an initiative from Microsoft Latam Team) about those new features and here are some of the demos (I removed the narration since it was in Portuguese J):
Demo 1 – Configuration Change Tracking
· This demo shows the functionalities of this new feature and how to easily identify what change was done in the Firewall Policy.
Demo 2 – Web Publishing Rule Test Button
· Very cool feature that can be used proactively to see if the publishing rule is working (prior to put in production) or reactively while troubleshooting an issue.
Demo 3 – Traffic Simulator
· Tired to wait for the user to be able to see the error that he is receiving when accessing a web site? Now you can do your own simulation with this tool.
Demo 4 – Diagnostic Logging Query
· With this integration you will be able to understand exactly what is going on when ISA is processing your request.
Start planning your summer migrations for ISA Server 2006 SP1.
Without a doubt one of the best features of this TMG beta version is the Malware Inspection. In my previous post you saw how to configure a Web Policy rule and one of the wizard’s windows has the option to enable this feature. Tom Shinder published a new article in the ISAServer .org that gives some examples of how this feature works.
Check it out here.
1. Introduction
The Microsoft Forefront Threat Management Gateway promises to be the milestone that all ISA Server admins were waiting for. I heard all the time people saying that the difference between ISA Server 2004 and ISA Server 2006 were not that big and that we pretty much have the same product for 4 years already. Well, that isn’t really true; there are indeed many differences between 2004 and 2006. Maybe some people were waiting for a huge upgrade like it was from ISA 2000 to 2004 and this didn’t happen. After two years since ISA Server 2006 was released, we have now (without a doubt) a big change, maybe will not be noticeable now but it will in the final version.
You can download the beta version from here and use the installation guide article that my friend Tom Shinder wrote. This beta version available for download has only a limited set of features. However, before install read the release notes to see what you can and what you cannot do.
There are many things that you will notice and see that it is different from ISA Server 2006. As far as installation is concern there are some things that you need to remember:
· IIS will be installed: that’s correct; IIS now will be installed by TMG. You might be thinking: “I remember that we have issues with IIS and ISA in the same box…”. You are right for ISA Server, but for TMG we need IIS because TMG needs SQL Reporting Services 2005 and SQL Reporting Services 2005 needs IIS. It is important to emphasize that IIS is not removed if you uninstall TMG.
· 64 bits System: although the final version of TMG requires a 64-bit processor and Windows Server 2008 64-bit, this beta version can be installed in a 32-bit system with Windows Server 2008.
· WEBS: the TMG beta version that we have available for download it will be part of the Windows Essential Business Server. TMG will be available through WEBS Standard and Premium Edition.
Note: The official TMG documentation is available at Microsoft TechNet Library web site.
2. Just installed, now what?
Now that you installed let’s create a Web Access Policy, to do that click in Configure Web Access Policy in the screen below:
Figure 1 – Web Access Policy.
Now follow the steps below to use this new wizard:
1) In the welcome screen click in Next.
2) In the Web Protection page, click in Yes, enable malware inspection feature, and click in Next:
Figure 2 – Web Protection page.
3) In the Web Access Policy Type page, click in Create customized Web access policies for users, groups and computers and click in Next:
Figure 3 – Web Access Policy Type window.
4) In the Access Policy Groups page you can select the option to allow users, groups, computers by name or IP and also subnets. For the purpose of this demo, select Users and user groups only. Click in Next to continue.
Figure 4 – Configuring the Access Policy Groups
5) In the Default Web Access Policy Page click in Allow the Web requests and click in Next.
Figure 5 – Default Web Access Policy Page.
6) In the Authenticated Web Access Policies page, click in Add.
Figure 6 – Selecting the users that will have access.
7) In the Add Access Policy window, type the policy name, click in Add button to add the group that will have access. Notice that this window is similar to the ISA Server 2006 window; you can use the same functionalities to add: windows groups, LDAP, RADIUS or SecurID. For the purpose of this demo, select All Authenticated Users. Click Add and click Close. Select Allow access to the destinations below and click in Add button to add the External network. After finish, click OK and Next to proceed.
Figure 7 – Access Policy configuration.
8) In the Malware Inspection Setting page, leave the default options selected and click in Next.
Figure 8 – Malware Inspection Setting.
Note: for more information in the Malware Inspection feature read the TechNet Article about that.
9) Since the cache driver was not configured yet, the next window will allow you to configure that:
Figure 9 – Web Cache Configuration.
10) For the purpose of this example, I’m going to disable the option Enable Web Caching. Click in Next to continue and then click in Finish.
After finished creating the rule, click in Apply to commit it. Now check it out this nice improvement in the interface:
Figure 10 – New TMG Interface with enhanced items.
3. Try to Browse now
If you try to browse after creating this rule one thing that you will notice in the live logging is the presence of new fields that can identify “on the fly” if the web site has any threat or not:
Figure 11 – New TMG Logging Interface fields.
4. Conclusion
This is a just a little overview of what is the TMG that is part of the WEBS, but as I said before, much more will be available in the future. Keep watching the news and playing with this beta version to get used to.
The first part of this article explained how to configure the IAG Server to allow full network access using the Network Connector. Now it comes the time to connect the external computers to the network. This second part will focus on what needs to be done on the client side to allow that to happen.
2. Evaluating your Needs
As I mention in all my blogs about IAG, the granularity for endpoint compliance is really a differential on IAG. At the same time that we can create tight and restrictive policies, we also can create more relaxed policies. One thing that you will notice when you try to access the SSL VPN for the first time on a computer that is not compliance with the policy is the window below:
Figure 1 – Warning about computer’s compliance.
This is due the tight default policy that we have for the Network Connector. The figure below shows the default policy and what we need to be compliant to be able to access the remote resource:
Figure 2 – Default Network Connector Policy.
For compliance configuration on the client side, the recommendation is to follow the instructions IAG User Guide, chapters 5 and 7. This document can be downloaded from Microsoft Download Center.
3. Client Connectivity
Once the endpoint compliance has been met, the client can finally get access to the resources. When this happen the following items will be notice in the client side:
- The Network Connector balloon will show up on the right corner of the.
- If you double click on the icon that appears on the right corner of the task bar you will launch the portal activity that will show the Network Connector started.
- If you open the command prompt and type ipconfig you will see that the client received the IP configured on the IAG server.
At this point the client is already a node that belongs to the internal network and can access the resources where it has permissions to.
4. Troubleshooting Network Connector
The Network Connector troubleshooter is composed of two sides: client and server. You can enable logs on the client side as well as on the server side. To enable client logging add the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\Client\NetworkConnector
"log"=dword:00000004
"log\sniff"=dword:00000001
To disable it, just change the log value to 00000000. It is important to emphasize that this is used only for troubleshooting purpose due the high intensive log creation. The file will be created at %programfiles%\Whale Communications\Client Components\3.1.0\whliocsv.log.
Here an example of a successfully connection:
Part 1 – Service starting up
19.05.08 04:42:30.254 ::_tWinMain enter
19.05.08 04:42:30.254 Create service sync event (0)
19.05.08 04:42:30.284 CNcDialer::CreateSession enter
19.05.08 04:42:30.284 CNcOS::CNcOS enter
19.05.08 04:42:30.284 mj = 5
19.05.08 04:42:30.284 mi = 2
19.05.08 04:42:30.284 build = 3790
19.05.08 04:42:30.284 platform = 2
19.05.08 04:42:30.284 cs ver = Service Pack 2
19.05.08 04:42:30.284 eType = 200302
19.05.08 04:42:30.284 CNcOS::CNcOS leave {}
19.05.08 04:42:30.284 CNcAdditionalRoutes::Cleanup enter
19.05.08 04:42:30.284 CNcAdditionalRoutes::Cleanup leave {}
19.05.08 04:42:30.284 CNcDialer::CreateSession leave {0}
19.05.08 04:42:30.294 CNcSession::Start enter
19.05.08 04:42:30.294 Validating IP address - 0XED00007F
19.05.08 04:42:30.294 Validating IP address - 0X4600A8C0
19.05.08 04:42:30.294 CNcSession::_Init enter
19.05.08 04:42:30.294 Create event {0}
19.05.08 04:42:30.294 ::WU_LoadCommonConfiguration enter
19.05.08 04:42:30.294 cfg.device_threads = 1 {0x2}
19.05.08 04:42:30.294 cfg.device_buffers_size = 0 {0x2}
19.05.08 04:42:30.294 cfg.device_buffers_size = 4 {0x2}
19.05.08 04:42:30.294 cfg.tunnel_threads = 1 {0x2}
19.05.08 04:42:30.294 cfg.tunnel_buffers_size = 64 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.net = 20000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.reg = 5000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.dev = 20000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.route = 15000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.maintenance = 20000 {0x2}
19.05.08 04:42:30.294 ::WU_LoadCommonConfiguration leave {}
19.05.08 04:42:30.294 CWioSession::Init enter
19.05.08 04:42:30.294 check status {0}
19.05.08 04:42:30.294 check sanity {0}
19.05.08 04:42:30.294 input flags: 0
19.05.08 04:42:30.294 input tun cfg: 64 KB x 1 tunnel threads (per cpu)
19.05.08 04:42:30.294 input device cfg: 4 KB x 1 device threads
19.05.08 04:42:30.294 input timeouts: 20000 (dev) / 20000 (net) / 5000 (reg) / 15000 (route) / 20000 (maintenance)
19.05.08 04:42:30.294 check input {0}
19.05.08 04:42:30.294 CWioSession::_OpenDmEvent enter
19.05.08 04:42:30.294 CWioSession::_OpenDmEvent leave {0}
19.05.08 04:42:30.294 CWioSection::Open enter
19.05.08 04:42:30.294 pfExists = 0
19.05.08 04:42:30.294 CWioSection::Open leave {0}
Part 2 – Starting Network Connector and open the session with the server
19.05.08 04:42:30.304 CWioWinsock::Load enter
19.05.08 04:42:30.304 CWioWinsock::Load leave {0}
19.05.08 04:42:30.304 CWioNIC::Open enter
19.05.08 04:42:30.304 type = Virtual
19.05.08 04:42:30.304 get list size {0x6f: 1280 bytes}
19.05.08 04:42:30.304 allocate list {0}
19.05.08 04:42:30.304 enum (list) {0, 1280 bytes}
19.05.08 04:42:30.304 set name {{B6EB736A-A20B-4C52-A13F-0D10575C90A1}}
19.05.08 04:42:30.304 set index {0x2}
19.05.08 04:42:30.304 set mac {00-ff-08-01-19-47-}
19.05.08 04:42:30.304 open key System\ControlSet001\Services\TcpIp\Parameters\Interfaces\{B6EB736A-A20B-4C52-A13F-0D10575C90A1} {0}
19.05.08 04:42:30.304 control set = 1
19.05.08 04:42:30.304 open WINS key {0 for 6bf340}
19.05.08 04:42:30.304 open CPL key {0 for System\ControlSet001\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{B6EB736A-A20B-4C52-A13F-0D10575C90A1}\Connection}
19.05.08 04:42:30.304 open NET key {0 for System\ControlSet001\Control\class\{4D36E972-E325-11CE-BFC1-08002BE10318}}
19.05.08 04:42:30.304 enum NET loop starts:
19.05.08 04:42:30.304 -> open \0000 {0}
19.05.08 04:42:30.304 -> open \0001 {0}
19.05.08 04:42:30.304 -> open \0002 {0}
19.05.08 04:42:30.304 -> open \0003 {0}
19.05.08 04:42:30.304 -> open \0004 {0}
19.05.08 04:42:30.304 -> open \0005 {0}
19.05.08 04:42:30.304 -> open \0006 {0}
19.05.08 04:42:30.304 -> open \0007 {0}
19.05.08 04:42:30.304 -> open \0008 {0}
19.05.08 04:42:30.304 -> open \0009 {0}
19.05.08 04:42:30.304 -> -> matched id (9 iterations)
19.05.08 04:42:30.304 CWioNIC::QueryReg enter
19.05.08 04:42:30.304 name = EnableDhcp
19.05.08 04:42:30.304 DWORD data read {1}
19.05.08 04:42:30.304 CWioNIC::QueryReg leave {0}
19.05.08 04:42:30.304 -> -> setting member flags (enabled = 1 ; dhcp = 1}
19.05.08 04:42:30.304 <- enum NET loop exits
19.05.08 04:42:30.304 CWioNIC::Open leave {0}
The registry key emphasize in red on the log above is the Whale Network Connector NIC Driver that is created. Although this NIC doesn’t appear on the Control Panel/Network Connections, it will be available on the Device Manager. You just need to enable the Show Hidden Devices, as show in the figure below:
Figure 3 – Whale Network Connector NDIS Driver.
Continue the log reading, we have the sessions:
· open virtual device
· verify virtual device properties
· allocate thread pools
· open device control
· device thread starts
· check status
· check input
· init srv peer
· connect
Those sessions will show minor details since they are smaller process in the logging. The next verbose session will be following one:
Part 3 – Building routing table
19.05.08 04:42:30.835 input ip = 10.1.1.151
19.05.08 04:42:30.835 input class = 10.0.0.0 / 255.0.0.0
19.05.08 04:42:30.835 input policies (servers) = 0x1 (arps); 0xff (dhcps, with static fallback)
19.05.08 04:42:30.835 input policies (other) = 0x3 (nsplit); 1 (anti-spoof)
19.05.08 04:42:30.835 CNcRouteTable::Load enter
19.05.08 04:42:30.835 CNcRouteTable::_AllocArrays enter
19.05.08 04:42:30.835 ::WU_RouteLoadTable enter
19.05.08 04:42:30.845 get size {0x7a, 1524 bytes}
19.05.08 04:42:30.845 alloc {0}
19.05.08 04:42:30.845 get array {0}
19.05.08 04:42:30.845 log entries {7}
19.05.08 04:42:30.845 ..01 00000001> 127.0.0.0/255.0.0.0 <> 127.0.0.1 (1)
19.05.08 04:42:30.845 ..02 00010004> 192.168.0.0/255.255.255.0 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..03 00000001> 192.168.0.80/255.255.255.255 <> 127.0.0.1 (20)
19.05.08 04:42:30.845 ..04 00010004> 192.168.0.255/255.255.255.255 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..05 00010004> 224.0.0.0/240.0.0.0 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..06 00000002> 255.255.255.255/255.255.255.255 <> 192.168.0.80 (1)
19.05.08 04:42:30.845 ..07 00010004> 255.255.255.255/255.255.255.255 <> 192.168.0.80 (1)
19.05.08 04:42:30.845 ::WU_RouteLoadTable leave {0}
19.05.08 04:42:30.845 set base len {7}
19.05.08 04:42:30.845 ..loop: add ip interface {192.168.0.80 / 255.255.255.0}
19.05.08 04:42:30.845 ..check entry 127.0.0.0 / 255.0.0.0 -> 127.0.0.1 | 0x1
19.05.08 04:42:30.845 -> IPlbk
19.05.08 04:42:30.845 ..check entry 192.168.0.0 / 255.255.255.0 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> LAN
19.05.08 04:42:30.845 ..check entry 192.168.0.80 / 255.255.255.255 -> 127.0.0.1 | 0x1
19.05.08 04:42:30.845 -> IP
19.05.08 04:42:30.845 ..check entry 192.168.0.255 / 255.255.255.255 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> BC1
19.05.08 04:42:30.845 ..check entry 224.0.0.0 / 240.0.0.0 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> MC
19.05.08 04:42:30.845 ..check entry 255.255.255.255 / 255.255.255.255 -> 192.168.0.80 | 0x2
19.05.08 04:42:30.845 -> BC
19.05.08 04:42:30.845 ..check entry 255.255.255.255 / 255.255.255.255 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 CNcRouteTable::_AllocArrays leave {0}
19.05.08 04:42:30.845 CNcRouteTable::Load leave {0}
19.05.08 04:42:30.845 CWioClient::_CheckRoutingConflicts enter
19.05.08 04:42:30.845 check route: 10.0.0.0 / 255.0.0.0 {type = virtual interface}
19.05.08 04:42:30.855 CWioClient::_CheckRoutingConflicts leave {0}
Part 4 – Verifying RRAS status for potential collision
19.05.08 04:42:30.855 CWioService::QueryStatus enter
19.05.08 04:42:30.855 CWioService::_OpenService enter
19.05.08 04:42:30.855 open SCM {0}
19.05.08 04:42:30.855 CWioService::_OpenService leave {0}
19.05.08 04:42:30.855 control interrogate {0x426}
19.05.08 04:42:30.855 close handle {0}
19.05.08 04:42:30.855 close SCM handle {0}
19.05.08 04:42:30.855 CWioService::QueryStatus leave {0x426}
19.05.08 04:42:30.855 CWioSession::_ConnectVirtualDevice enter
19.05.08 04:42:30.855 IP / Mask = 10.1.1.151 / 255.0.0.0
19.05.08 04:42:30.855 DNS (Primary) = 10.1.1.6
19.05.08 04:42:30.855 DNS (2nd) = 0.0.0.0
19.05.08 04:42:30.855 Wins (Primary) = 0.0.0.0
19.05.08 04:42:30.855 Wins (2nd) = 0.0.0.0
19.05.08 04:42:30.855 GW = 0.0.0.0
19.05.08 04:42:30.855 DHCP (V) = 10.1.1.150
19.05.08 04:42:30.855 Alloc Type = dhcps = 0xff, sfallback = 1
19.05.08 04:42:30.855 CWioNIC::ReleaseDhcpAddress enter
19.05.08 04:42:30.855 CWioNIC::ReleaseDhcpAddress leave {0x2}
19.05.08 04:42:30.855 control interrogate {0}
19.05.08 04:42:30.855 CWioService::QueryStatus leave {0}
Now that we know how the good log looks like, let’s see where we can find errors in the log:
Fictitious Scenario – After launch the Network Connector, I see the balloon on the right corner, however after some seconds I receive an error message saying: Whale Network Connector session failed. Server not responding (0x80004005).
In this case you can enable the tracing on the client side and track it up the error message. Open the Log and search for 0x80004005. After that, keep going up and see where we have the first failed during the connection.
The error was appearing on “device thread exits” session:
19.05.08 05:11:46.359 wait {0}
19.05.08 05:11:46.359 close {0}
19.05.08 05:11:46.359 CWioThread::Stop leave {0}
19.05.08 05:11:46.359 CWioNIC::Close enter
19.05.08 05:11:46.359 CWioNIC::Close leave {}
19.05.08 05:11:46.359 CWioIoBuffersPool::Term enter
19.05.08 05:11:46.359 CWioIoBuffersPool::Term leave {}
19.05.08 05:11:46.359 CWioSession::Term leave {0}
19.05.08 05:11:46.359 CNcSession::Start leave {0x80004005}
19.05.08 05:11:46.359 NcDialer::_StopService enter
19.05.08 05:11:46.359 OpenSCManager succeeded.
19.05.08 05:11:46.359 OpenService succeeded.
As we know, during the connection the client first starts Network Connector on its own side, and then tries to connect to the server. Therefore the initial parts of the logs will not tell too much about the issue. But, if you keep looking up in the log you will see the following on the “wait for reply” session:
19.05.08 05:11:45.357 CWioSession::_SetSessionError enter
19.05.08 05:11:45.357 input msg = 'Server not responding'
19.05.08 05:11:45.357 input code = 0xf0
19.05.08 05:11:45.357 inidicated = 0
19.05.08 05:11:45.357 CWioSession::_SetSessionError leave {0}
19.05.08 05:11:45.357 input msg = 'generic error'
19.05.08 05:11:45.357 inidicated = 1
19.05.08 05:11:45.357 CWioSession::_SetSessionError leave {0xb7}
19.05.08 05:11:45.357 CWioClient::StopSession enter
19.05.08 05:11:45.357 sync = 0
19.05.08 05:11:45.357 CWioVaProxy::Set enter
19.05.08 05:11:45.357 CWioVaProxy::Set leave {0x40}
19.05.08 05:11:45.357 CWioPeer::Term enter
19.05.08 05:11:45.357 state = 2
19.05.08 05:11:45.357 reason = 2
19.05.08 05:11:45.357 CWioPeer::Term leave {0}
19.05.08 05:11:45.858 CWioPeer::Term enter
19.05.08 05:11:45.858 state = 1
19.05.08 05:11:45.858 reason = 2
19.05.08 05:11:45.858 CWioPeer::Term leave {0x6}
19.05.08 05:11:45.858 CWioClient::_FullTunnelingUNSET enter
19.05.08 05:11:45.858 nothing to undo..
19.05.08 05:11:45.858 CNcRouteTable::Export enter
19.05.08 05:11:45.858 data flag = 0
19.05.08 05:11:45.858 CNcRouteTable::Export leave {0}
19.05.08 05:11:45.858 CWioClient::_FullTunnelingUNSET leave {0}
19.05.08 05:11:45.858 CWioClient::StopSession leave {0}
19.05.08 05:11:45.858 CWioClient::StartSession leave {0xf0}
Well, looks like server is not responding. But, why it is not responding? Keep going up in the log and look into the “init srv peer” session:
19.05.08 05:11:44.356 CWioPeer0::Connect enter
19.05.08 05:11:44.356 check input: <0> / 127.0.0.233:6004 {0}
19.05.08 05:11:44.356 CWioDTunnel::Connect enter
19.05.08 05:11:44.356 h = 532
19.05.08 05:11:44.356 CWioDTunnel::Connect leave {0}
19.05.08 05:11:44.356 CWioPeer0::Connect leave {0}
Here we know that the client was trying to connect to the Network Connector on the server side using the port 6004. However, by default the port is 6003, therefore there is a mismatch in the port. You can ask now: how come there is a mismatch if it is the server who provides this port to the client? That’s true, but there are two places where this port is defined, on the Network Connector Server / Advanced Tab and on the Network Connector Application Publishing / Server Settings / Port. In this case, the application publishing is telling the client to use this port, so we can pretty much conclude that the mismatch is on the server side and most likely in the publishing rule.
5. Conclusion
The above troubleshooting scenario was really simplistic, but the main goal was to get you familiarized with the error messages and how to track it the root cause for a problem. If you still don’t have try IAG yet, go ahead and download the demos and play with it.
The previous post was about performance and some of the symptoms that can confuse us during the problem definition. This post will be about a crash on a user mode process, in this case for the process ISA Process wspsrv.exe.
2. Scenario
Usually, when this process crashes we have the following event on the application log:
Event Type: Error
Event Source: Microsoft Firewall
Event Category: None
Event ID: 14057
Date: DATE
Time: Time
User: N/A
Computer: MyISA
Description:
The Firewall service stopped because an application filter module C:\Program Files\Microsoft ISA Server\Module generated an exception code YYYYYYY in address XXXXXX when function ZZZZZZZ was called. To resolve this error, remove recently installed application filters and restart the service.
Where:
· Module – module that generated the exception.
· YYYYYYY – Exception code, for example an access violation (C0000005).
· XXXXXX – memory address where the exception occurred.
· ZZZZZZZ – function that was called during the exception.
When the Firewall Service crashes it causes the ISA Server to stop working and the following event will appear on the application log:
Event Source: Microsoft ISA Server Control
Event ID: 14079
Time: TIME
Due to an unexpected error, the service fwsrv stopped responding to all requests. Stop the service or the corresponding process if it does not respond, and then start it again
3. Gathering Data
The big problem when this kind of event happens is that when you realize that the issue occurred then it is already too late. The root cause was already gone and you just lost the chance to grab the data.
Since we are dealing with a crash we need to attach a debugger to the process that is crashing. The program that we are going to use to do this is called DebugDiag and it was created by the IIS Team to troubleshoot inetinfo.exe crashes and leaks. Later on became a robust tool to grab and analyze user mode hangs and crashes for IIS or other processes. First thing to do is to download the DebugDiag from the link below:
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&DisplayLang=en
After install the tool on the ISA Server then follow the steps below to configure:
1. Click Start / Programs / Debug Diagnostic Tool 1.1 / DebugDiag 1.1 (x86). The following window will appear:
Figure 1 – Creating a new crash rule.
2. Leave the Crash option enabled and click in Next. The following window will appear:
Figure 2 – Target object.
3. Select the option “A specific process” and click in Next. The following window will appear:
Figure 3 – Selecting the process.
4. Select the ISA Server process that is crashing. For the purpose of this example I’m going to select the process wspsrv.exe. Click in Next and the window below will appear:
Figure 4 – Advanced configuration.
5. On this window we need to select a couple of things, let’s check below:
· Action type for unconfigured first chance exception: Full Userdump.
· Action limit for unconfigured first chance exception: 0 (unlimited).
6. Click on the exception button and select the options as showed below and on the same order:
Figure 5 – Final steps.
7. Notice that we select the “Access Violation” exception as an example, because the event 14057 in this case was the C0000005. If you are not sure which exception is happening, you don’t need to select anything here and the Debugdiag will capture the dump regardless of the exception. Click in Next to continue.
8. Type the name of rule and click in Next and then click in Finish to activate the rule.
4. Now what?
Now we just need to wait for the next occurrence and the debugger with catch the crash. Next post will show how the crash dump looks like and what to do after you have it.
One of the most trick things sometimes for the end user or even for the network administrator is to define what the real behavior is when the subject is related to performance. Sometimes they say: my ISA Server is crashing on me. Hold on, is it really crashing? How do you define crashing? Did you get a blue screen? Is it the whole server that crashes or only the ISA Services? Which service? See, it is complicated sometimes to be precise on this matter.
2. Reviewing ISA Server Architecture
Before start to talk about those issues and definitions let’s review the core ISA Server architecture:
Figure 1 – ISA Server Core Architecture.
As you can see on the picture above the main component of ISA Server that runs on Kernel Mode is the Firewall Engine (FWENG), all the others ran in User Mode. For a complete definition of the ISA Server Services check the Services article at Microsoft TechNet.
For more in depth explanation about the ISA Server architecture review the article ISA Server 2006 Firewall Core at Microsoft TechNet.
3. Performance Issues on User Mode
In the user mode one of the issues that can happen is the performance degradation due a memory leak. In some situations, the Microsoft Firewall (wspsrv) can be the one that is showing up this behavior; however it might not be the culprit for that. There is a typical scenario where the Antivirus software can corrupt the log files or the cache files. This can happen if it locks the file for scanning while ISA Server tries to access the file.
In this scenario you might see the wspsrv.exe hitting 100% CPU utilization and keep up there for awhile. This definitely will cause the server’s performance to go down the hill. There are a couple of techniques that can be used to obtain and troubleshoot data in this matter. In this case I’m going to ask you to review the post that I wrote for the ISA Server Team Blog: Isolating problems that seems to be related to the ISA Server – Part III. This was a real experience in a case that I worked and the good thing about this post is that it has the whole action plan to grab the right data that you need.
4. Issues on Kernel Mode
Usually when we have issues in the kernel mode the side effect will be more drastic, for example: server will crash with a blue screen. The good part is that it sometimes faster to identify the root cause, mainly if we compare with performance issues that sometimes can take days and days to identify who was causing this.
On a blue screen scenario what you need to pay attention is on the error message, what driver is showing up on the top of the window and prepare the system to get a dump. For more detail information on how to troubleshoot a blue screen error use the article Blue Screen or STOP Error Message Troubleshooting Before You Call Microsoft Support from Microsoft Help and Support.
5. Besides that, what should I do?
If there is something that ISA Server has in abundance, this is called: performance troubleshooting articles. I’m not going to try to reinvent the wheel here and start writing about Perf Issues and how to troubleshoot. So if you need to really dive in this area, make sure to use the articles below:
Article
When to use it?
Capacity Planning
This planner should be used during the conception of the project, before deploy ISA Server. However you also can use it to see if you ISA Server configuration are appropriated for your environment.
ISA Server Performance Best Practices
Use this article to understand what are the best practices while implementing ISA Server as far as performance is concern.
Monitoring and Troubleshooting Performance
Use this article for troubleshooting purpose. As the name suggests, this is a guide that has the steps to monitor ISA Server’s performance, collect the right data and troubleshoot performance issues.
Improving Web Proxy Client Authentication Performance on ISA Server 2006
Use this article to know how to improve client performance while browsing Internet.
So, if you follow the order above you will be covering the following phases:
1. Planning.
2. Pilot (implementing on the lab and evaluating ISA Server).
3. Post implementation through monitoring and troubleshooting isolated scenarios.
4. Fine tuning for performance improvement on the client’s perspective.
This should be a good startup to better understand how to improve ISA Server’s performance.
Note: For a complete Perfmon counters reference use Performance Counters article at Microsoft TechNet.
Last Tuesday Microsoft announced the new generation of IAG, now called UAG (Unified Access Gateway). For more information check the Forefront Team Blog site:
http://blogs.technet.com/forefront/archive/2008/04/29/microsoft-announces-its-next-generation-secure-remote-access-solution-the-forefront-unified-access-gateway.aspx
…or the UAG page:
http://www.microsoft.com/forefront/prodinfo/roadmap/uag.mspx
Keep watching the evolution of this product; it is becoming ever more powerful, secure and flexible.