Connecting Through Windows Firewall (Windows)
Windows Development.aspx "Windows Development")
Administration and Management.aspx "Administration and Management")
Windows Management Instrumentation.aspx "Windows Management Instrumentation")
Using WMI.aspx "Using WMI")
Creating WMI Clients.aspx "Creating WMI Clients")
Connecting to WMI on a Remote Computer.aspx "Connecting to WMI on a Remote Computer")
Connecting Through Windows Firewall.aspx "Connecting Through Windows Firewall")
- Add code samples and tips to enhance this topic. More...
Connecting Through Windows Firewall
The Windows Firewall (formerly known as Internet Connection Firewall) service and Distributed Component Object Model (DCOM) can cause access denied errors (such as an "RPC Server Unavailable" error - 0x800706ba) when your remote computers and accounts, used for remote connections, are not properly configured.
Note Content in this topic applies to Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1 (SP1). For information that applies to Windows Vista, see Connecting to WMI Remotely Starting with Vista. Windows Server 2003 with SP1: The Windows Firewall is not enabled by default. Windows XP with SP2: The Windows Firewall is enabled by default.
Resetting the firewall settings will enable the firewall—regardless of the platform.
Windows Server 2003 and Windows XP: Windows Firewall is not available. Use Internet Connection Firewall.
When obtaining data from a remote computer, WMI must establish a DCOM connection from Computer A (the local computer) to Computer B (the remote computer)—this is shown in the diagram as Connection 1. To establish this connection, both Windows Firewall and DCOM on Computer B must be configured appropriately. The configuration must be done locally on Computer B either by changing the Group Policy settings, by executing NETSH commands, or by executing a script locally. Windows Firewall does not support any remote configuration. The following sections describe how to configure Connection 1 and Connection 2 using NETSH commands and the Group Policy editor. For more information about configuring the connections with a script, see http://www.microsoft.com/technet/community/columns/scripts/sg1104.mspx/#EJAA.
The following diagram shows the relationship of WMI, the Windows Firewall, and DCOM when a script or another WMI client makes an asynchronous call to obtain data from WMI. Synchronous and semisynchronous calls only make Connection 1. Connection 2 occurs only with asynchronous calls. If the script or application made an asynchronous call, Connection 2 from Computer B to Computer A delivers the results. This delivery is the callback to the sink. When possible, semisynchronous calls should be made instead of asynchronous calls. The performance of semisynchronous calls is almost as good as asynchronous calls and semisynchronous calls are more secure.
WMI client making an asynchronous call to obtain data from WMI
To successfully connect from Computer A to Computer B when the Windows Firewall is enabled on Computer B, some configuration of firewall settings is necessary. The following procedure helps you configure Connection 1.
.gif")To configure Connection 1
- Ensure that the user account that is on Computer A is a local administrator on Computer B.
If the user account that is on Computer A is not an administrator on Computer B, but the user account has Remote Enable permission on Computer B, then the user must also be given DCOM Remote Launch and Remote Activation privileges on Computer B by running Dcomcnfg.exe at the command prompt. For more information, see the remote launch and activation permissions procedure in Securing a Remote WMI Connection. The 0x80070005 error occurs when this privilege is not set. For more information, see Access to WMI Namespaces.
- Allow for remote administration on Computer B.
You can use either the Group Policy editor (Gpedit.msc) or a script to enable the Windows Firewall: Allow remote administration exception, or use a netsh firewall command at the command prompt to allow for remote administration on Computer B. The following command enables this feature.
netsh firewall set service**RemoteAdmin**enable
If you would rather use the Group Policy editor than the NETSH commands above, use the following steps in the Group Policy editor (Gpedit.msc) to enable "Allow Remote Administration" on Computer B.
- Under the Local Computer Policy heading, double-click Computer Configuration.
- Double-click Administrative Templates, Network, Network Connections, and then Windows Firewall.
- If the computer is in the domain, then double-click Domain Profile; otherwise, double-click Standard Profile.
- Click Windows Firewall: Allow remote administration exception.
- On the Action menu, select Properties.
- Click Enable, and then click OK.
The connection from Computer B to Computer A (Connection 2 in the diagram above) is only required when the client script or application makes an asynchronous call to the remote computer. When possible, semisynchronous calls should be made instead of asynchronous calls. The call performance of semisynchronous calls is almost as good as asynchronous calls and semisynchronous calls are more secure. For more information, see Calling a Method or Querying WMI. The following procedure helps you configure Connection 2.
.gif")To configure Connection 2
- If the Windows Firewall is enabled on Computer A, enable the "Allow Remote Administration" exception (step 2 in the procedure above) and open the DCOM port TCP 135 on Computer A. If this port is not open, the error 0x800706ba will occur. You can open port 135 using the following command.
netsh firewall add portopening**protocol=tcpport=135name=**DCOM_TCP135
- Add the client application or script, which contains the sink for callback to the Windows Firewall Exceptions List on Computer A. If the client is a script or a MMC snap-in, the sink is often Unsecapp.exe. For these connections, add %windir%\system32\wbem\unsecapp.exe to the Windows Firewall application exceptions list. You can add Unsecapp.exe with the following command.
netsh firewall add allowedprogram**program=%windir%\system32\wbem\unsecapp.exename=**UNSECAPP
Generally a C++ application has a sink written for the application. In that case, the application sink should be added to the firewall exceptions.
- If Computer B is either a member of WORKGROUP or is in a different domain that is untrusted by Computer A, then Connection 2 is created as an Anonymous connection. An anonymous connection fails with either the 0x80070005 error or the 0x8007000e error unless Anonymous connections are given the DCOM Remote Access permission on Computer A. The steps to grant DCOM remote access permissions are listed in Securing a Remote WMI Connection.
Connecting to WMI on a Remote ComputerConnecting Between Different Operating SystemsSecuring a Remote WMI ConnectionCreating Processes RemotelySetting Security on an Asynchronous CallSetting Security on an Asynchronous Call in VBScript
Build date: 1/6/2011 Community Content Add
Tell us about your experience...
Did the page load quickly? Yes No
Do you like the page design? Yes No
How useful is this topic?
Tell us more Enter description here.