Posted: August 5, 2005
In my last post, I talked about how ISA 2004 could keep your WMI scripts from running properly on your SBS machine. Here’s how I diagnosed it on my server:
ISA 2004 has an awesome monitoring capability. It can monitor the firewall and display sessions and blocked ports in real time. ISA has a query filter you can edit down to client IP’s, destination IP’s, ports and protocols. Great for troubleshooting, especially in this case!
It helps to know that WMI uses DCOM which uses RPC, in fact it’s essential to know what protocols your script or program may use under the hood.
First, pick your WMI script. It should be one that you can run against a remote machine. Most Scriptomatic-generated scripts can do this.
Open ISA Management and select Monitoring and click the Logging tab. Click Edit Filter. Select Log Record Type Equals Firewall and Log Time set to Live. If there are any other filters, remove them. Select Filter By Destination IP and enter the IP address of the remote machine you are running the script against. Click Start Query.
In another window, such as a command window, run your script. It should fail. Rerun it again a few times. In the ISA Management window, you should see some entries pop up in the Logging Tab. Click on Stop Query. Click on Copy All Results to Clipboard and paste it to a spreadsheet.
The formatting of this blog won’t let me put the whole log in here legibly, but these are the fields that came up in my troubleshooting that I want to point out:
Client IP: 192.168.12.x (the SBS machine)
Destination IP: 192.168.12.10 (the remote machine)
Protocol: RPC (all interfaces)
Action: Closed Connection
Rule: Allow RPC from ISA Server to trusted servers
Result Code: 0x80074e24
Note that ISA will log the rule it uses to deny (or allow) access. "Allow RPC from ISA server to trusted server" is an ISA system policy, according to the ISA help file. The help file also explains that this system policy is grouped under Authentication Policy and that I can change it with the System Policy Editor.
The result code, unfortunately, is not in ISA Help but it is on the ISA 2004 SDK page. 0x80074e24 is listed as FWX_E_CONNECTION_KILLED. In other words, ISA dropped it, as it does most RPC connections (and WMI) when "Enforce strict RPC compliance" is checked.
As I mentioned in my last post, I’ve been running in circles for over a month trying to fix this. Once I got smart and had the idea of using ISA monitoring to troubleshoot this, it only took me about 30 minutes to fix. ISA 2004 is an excellent product!
Posted: August 5, 2005
If you just upgraded to SBS 2003 SP1 with ISA 2004 and you use scripts on the SBS machine to monitor and control your client machines or member servers (such as the scripts you find at Technet Script Center), your scripts might not work any longer.
This problem is acute when you use WMI scripts (such as those from the famous Scriptomatic tool) to run against a remote machine and get information from it. The scripts may give no results, or fail with a 0x800706ba error.
Scripts that you run on a workstation against your SBS machine may fail as well.
After running in circles for a month, I figured it out. I’ll explain how I finally diagnosed this in my next post, but if you have this problem and just want to stop banging your head, here’s how to fix it:
On the SBS machine, open up ISA Server Management (if you don’t remember where it is, click Start/All Programs/Microsoft ISA Server/ISA Server Managment)
Find "Firewall Policy" on the left pane and right click it. Select Edit System Policy. The System Policy Editor should pop up.
Scroll down to Authentication Services and select it. In the General tab, note the checkbox marked "Enforce strict RPC compliance". Note the information balloon that reads: "When ‘Enforce strict RPC compliance’ is not selected, additional RPC type protocols, such as DCOM, will be enabled."
Uncheck "Enforce strict RPC compliance". Click OK. Note the bar on the top of the ISA console that prompts you to apply or discard your changes. Click Apply. Click OK.
Your WMI scripts should now work.