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.
Windows Server 2003 with SP1: The Windows Firewall is not enabled by default.
Resetting the firewall settings will enable the firewall—regardless of the platform.
Windows Server 2003: 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.
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.
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.
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=tcp port=135 name=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.exe name=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 Computer
- Connecting Between Different Operating Systems
- Securing a Remote WMI Connection
- Creating Processes Remotely
- Setting Security on an Asynchronous Call
- Setting Security on an Asynchronous Call in VBScript