Windows Tip Sheet

Unleash the WMI Within

Configure Windows Firewall to accept incoming traffic.

• By Don Jones
• 12/15/2004

Over at ScriptingAnswers.com (my Web site on administrative scripting), we’ve had a number of users fighting with Windows XP SP2 issues related to Windows Management Instrumentation (WMI) scripting. Turns out that SP2 locks down computer security a bit tighter than some folks realized, leaving you to pick up the pieces and reconfigure things so that your old WMI-related scripts will still work.

Not Just Windows Firewall
Sure, Windows Firewall causes some problems by blocking the incoming traffic trying to talk to the WMI service. In other words, a script running on one machine won’t be able to connect to WMI on a remote machine unless Windows Firewall is modified. Of course, you should first make sure that your WMI script works against the local machine—then you can start debugging SP2 security issues.

Remote WMI scripting needs to perform two basic tasks: First, it needs to establish a connection to the remote WMI service. An XP machine running the script will allow the outgoing traffic through Windows Firewall, but the target machine’s Windows Firewall will block the traffic. You need to configure the firewall so that the Windows Firewall: Allow remote administration exception is enabled; this will punch a hole for the incoming WMI traffic. The other thing WMI needs is Distributed Component Object Model (DCOM) permissions to run; Administrators on local machines have the necessary DCOM permissions, but ordinary users don’t. If you need them to, give them the DCOM Remote Launch permission on the target machine(s), using the DCOM configuration utility (Start, Run, DCOMCNFG).

Some WMI connections are made asynchronously, which means the computer issuing the request can go about its business until a response comes in from the remote machine. This traffic needs to make it through the requesting computer’s firewall, which requires the firewall to allow traffic on TCP port 135. Run netsh firewall add portopening tcp 135 DCOM_port to do it.

There’s more detail in Knowledge Base (KB) article 875605 to cover different situations, such as anonymous connections. No doubt, though, SP2’s beefy new security features have sacrificed a level of functionality in favor of tighter security, so you’ll need to carefully test everything in your environment to see what reconfigurations are necessary.

Micro Tips Remember that, by default, Windows Firewall disables most incoming traffic except the basics like file and print sharing. Everything else—Remote Desktop, Windows Messenger and so forth—may require you to add an exception. Windows Firewall will normally offer to create the exception for you the first time you run an application, by popping up a dialog and asking if you’d like to keep blocking (don’t create an exception) or stop blocking (create an exception) the application. Trying to configure your Windows Firewall settings but find that the user interface is disabled (grayed out)? There’s a Group Policy responsible, being applied from Active Directory and centrally configuring the Windows Firewall settings on your machine. Windows disables the user interface as a visual cue that any changes you make wouldn’t have any effect, anyway.

More Resources:

• Microsoft has a KB article on this very set of problems.
• Join the scripting discussion at ScriptingAnswers.com.
• Check out my series of free Microsoft TechNet Webcasts on administrative scripting.
• Read more about troubleshooting Windows Firewall in SP2 here.