The script in Listing 1 shows the information you can retrieve at the WMI level from the ADSI computer object on a pre-Windows 2003 computer. You need to provide only the computer's Lightweight Directory Access Protocol (LDAP) name. At callout A in Listing 1, the script retrieves the ADSI computer object that represents the specified computer. From the created ADSI computer object, the script uses the ADSI-WMI extension's WMIObjectPath property to retrieve the path of the WMI object that the ADSI object represents, as the code at callout B in Listing 1 shows. In this case, the WMI object's path includes the moniker
WINMGMTS:
{impersonationLevel=impersonate}
!//W2K-EVO500A/root/cimv2:
Win32_ComputerSystem.Name=
'W2K-EVO500A'
You can then use the WMI object's path to retrieve the Win32_ComputerSystem object that the ADSI computer object represents.
Alternatively, you can use the ADSI-WMI extension's GetWMIObject to retrieve the Win32_ComputerSystem object right away, as the code at callout C in Listing 1 shows. This method uses the WMI object's path behind the scenes.
Similarly, instead of retrieving an instance of the Win32_ComputerSystem object, you can establish a WMI connection to the computer that the ADSI computer object represents. Then, you can create an instance of any class in the Root/CIMv2 CIM repository by invoking the GetWMIServices method, which returns a SWbemServices object, as callout D in Listing 1 shows. (For more information about the SWbemServices object, see "SWbemServices" at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemservices.asp.)
On a Windows 2003 computer without the ADSI-WMI extension, you can't retrieve the WMI object's path from the ADSI computer object right away. You must first construct the WMI moniker because the ADSI object no longer provides it. To build this moniker, you must use ADSI to retrieve the DNS host name and computer host name, as the code at callout A in Listing 2 shows. With these two names, you can build the WMI moniker that the GetObject function needs to retrieve the WMI object, as the code at callout B in Listing 2 shows. You then can use this moniker to retrieve and display the WMI object's path, as the code at callout C in Listing 2 shows.
Like the workaround to retrieve the WMI object's path, the workaround to retrieve the Win32_ComputerSystem object uses the DNS host name and the computer host name to build the WMI moniker. As the code at callout D in Listing 2 shows, you again use the moniker with the GetObject function to retrieve the Win32_ComputerSystem object. You can then display all the Win32_ComputerSystem object's properties, as the code at callout E in Listing 2 shows.
The workaround to establish a connection to the WMI object differs from the other workarounds, although the basic concept is the same. To connect to any class object in the Root/CIMv2 repository, you must build a WMI namespace object. As the code at callout F in Listing 2 shows, a WMI namespace object path consists of the DNS host name of the computer to which you want to make a WMI connection and the Root/CIMv2 namespace. After you establish the WMI connection, you can request any instance of any class in the Root/CIMv2 namespace, such as the Win32_Service class.
After you establish the WMI connection, you might want to use the Win32_ComputerSystem object's __PATH property to retrieve the same WMI object path that the code at callout C retrieves. (Note that Windows 2003 and XP offer an alternative property, called the SystemProperties_ property, to retrieve the __PATH property. Earlier Windows versions must use the coding technique that the code at callout C in Listing 2 shows.) Why would you want to retrieve the path again? You can use it to retrieve the object paths of other objects associated with the Win32_Computer object, such as the Win32_Service object or the Win32_Processor object. (These associations are visible with WMI CIM Studio, which you can download from "WMI Administrative Tools" at http://www.microsoft.com/downloads/details.aspx?familyid=6430f853-1120-48db-8cc5-f2abdc3ed314&displaylang=en.)
Windows 2003's design was driven by many factors, and one of the most important was security. WMI is an important underlying technology for Windows management. Because WMI supports many powerful tasks (e.g., shutting down a system, changing the system configuration), keeping it secure is important. The Trustworthy Computing initiative resulted in WMI changes that affect both administrators and developers. Therefore, a move to Windows 2003 should prompt a careful analysis of and possibly some modifications to your existing work methods and previously developed scripts.