5 out of 9 rated this helpful - Rate this topic

Connecting Between Different Operating Systems

You can create a remote connection between most operating system versions. However, in the basic remote connection scenario where Computer A connects to a WMI namespace on Computer B, the target Computer B may require higher levels of security.

Note Content in this topic applies to operating systems earlier than Windows Vista. For more information, see Connecting to WMI Remotely Starting with Vista.

The following sections are discussed in this topic:

Connecting Between Operating Systems
DCOM Impersonation and Authentication Settings
Failure to Connect
Time-out on Connection
Related topics

Connecting Between Operating Systems

Computer A connects to a WMI namespace on Computer B

Only domain accounts in the Administrators group can establish a connection to a remote WMI computer namespace in a domain. The target computer requires certain settings for impersonation and authentication levels to accept a remote connection. For example, if Computer A is running Windows 2000 Server with Service Pack 2 (SP2) and Computer B is running Windows XP, the moniker connection string must set the authentication level to Pkt because Windows XP does not accept a connection at a lower authentication level.

The following VBScript code example shows how to set the authentication level to Pkt.

Set objWMIService = GetObject("winmgmts:" _
   & "{authenticationLevel=Pkt}!\\" _
   & "ComputerB" _
   & "\root\cimv2")

For more information about setting authentication and impersonation levels, see Setting the Default Process Security Level Using VBScript and Constructing a Moniker String.

The following VBScript code example obtains the computer up time from a remote computer named "RemoteXPMachine". The "\\" required before the remote computer name is added by the script following the impersonation level setting.

Set dtmConvertedDate = CreateObject("WbemScripting.SWbemDateTime")
strComputer = "RemoteXPMachine"
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=Impersonate," _
    & "authenticationLevel=Pkt}!\\" _
    & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
    ("Select * from Win32_OperatingSystem")
For Each objOS in colOperatingSystems
    dtmConvertedDate.Value = objOS.LastBootUpTime
    dtmLastBootUpTime = dtmConvertedDate.GetVarDate
    dtmSystemUptime = DateDiff("d", dtmLastBootUpTime, Now)
Wscript.Echo dtmSystemUptime 
Next

For more information and examples of setting impersonation and authentication in WMI, see Creating a WMI Script or Creating a WMI Application Using C++.

DCOM Impersonation and Authentication Settings

WMI has default DCOM impersonation, authentication, and authentication service (NTLM or Kerberos) settings that the target computer (Computer B) in a remote connection requires. Computer A may use different defaults that Computer B does not accept. You can change these settings in the connection call. For more information, see Setting Client Application Process Security. However, for the authentication service, it is recommended that you specify RPC_C_AUTHN_DEFAULT and allow DCOM to choose the appropriate service for the target computer.

You can supply settings in parameters for the calls to CoInitializeSecurity or CoSetProxyBlanket in C++. In scripts, you can establish security settings in calls to SWbemLocator.ConnectServer, in an SWbemSecurity object, or in the scripting moniker string. For a list of all the C++ impersonation constants, see Setting the Default Process Security Level Using C++. For the Visual Basic constants and scripting strings for using the moniker connection, see Setting the Default Process Security Level Using VBScript.

The following table lists the default DCOM impersonation, authentication, and authentication service settings required by the target computer (Computer B) in a remote connection. For more information, see Securing a Remote WMI Connection.

Computer B operating system	Impersonation level scripting string	Authentication level scripting string	Authentication service
Windows 2000 (WMI 1.5)	Impersonate	Connect	Kerberos
Windows XP Professional	Impersonate	Pkt	Kerberos
Windows Server 2003	Impersonate	Pkt	Kerberos
Windows Vista	Impersonate	Pkt	Kerberos

WMI remote connections are affected by User Account Control (UAC) and Windows Firewall. For more information, see Connecting to WMI Remotely Starting with Vista and Connecting Through Windows Firewall.

Windows Server 2003 and Windows XP with SP2: Remote connections are affected by Windows Firewall and DCOM settings but User Account Control does not exist.

Windows 2000: Only DCOM settings affect remote WMI connections.

Be aware that connecting to WMI on the local computer has a default authentication level of PktPrivacy.

Failure to Connect

The following connections between operating system versions are not supported:

You cannot connect to a computer that is running Windows XP Home Edition.
A computer running Windows NT cannot connect to an operating system later than Windows 2000, such as Windows XP or Windows Server 2003.
Accessing a Windows Server 2003 computer from Windows Me/98/95 is not supported.

The following connections between operating system versions have special requirements:

To connect to a Windows 2000 Server with Service Pack 4 (SP4) and later running WMI version 1.01, you must explicitly set the impersonation level to Impersonate.
Windows 2000 computers must have Service Pack 2 installed to be able to connect to Windows XP and later operation systems.
To connect from Windows Server 2003 to computers running Windows Me/98 or Windows NT Server 4.0 with Service Pack 3 (SP3) and later, the credentials must be specified. If you try to use the default current user by not supplying a user name and password, then the connection will not work.

You may be trying to connect to a namespace which requires an encrypted connection, one that requires an authentication level of pktPrivacy, WbemAuthenticationLevelPktPrivacy, or RPC_C_AUTHN_LEVEL_PKT_PRIVACY. For more information, see Securing WMI Namespaces, Securing C++ Clients and Providers, or Setting the Default Process Security Level Using VBScript.

Time-out on Connection

When connecting to WMI through a call to SWbemLocator.ConnectServer or IWbemLocator::ConnectServer, you can set the wbemConnectFlagUseMaxWait flag (scripting) or the WBEM_FLAG_CONNECT_USE_MAX_WAITin C++ value to 128 (0x80) to impose a two (2) minute time-out on the call.

Windows 2000: The wbemConnectFlagUseMaxWait and WBEM_FLAG_CONNECT_USE_MAX_WAIT flags are not available.

Community Additions