Notable Problems with WMI and ADSI

Notable Problems with WMI and ADSI
When several scripting experts talked about common scripting errors in VBScript files, they mentioned a few notable problems that can occur when using Active Directory Service Interfaces (ADSI) and Windows Management Instrumentation (WMI). According to these experts and articles from a variety of sources, here’s a brief look at some dangers to watch out for.

ADSI Faux Pas
Ethan Wilansky, a chief technologist for EDS in its Next Generation Technologies and Architectures practice, says, “When using ADSI automation interfaces, I've commonly seen incorrect case on the provider moniker.” Unlike most items in VBScript code, ADSI provider names (i.e., ADSI OLE DB, GC, IIS, LDAP, NDS, NWCOMPAT, and WinNT) are case sensitive.

WMI Watch List
When you’re using WMI in VBScript code and your code fails, keep in mind the following problems. As this list shows, sometimes a problem isn’t necessarily your doing:

• If your machines are running Windows XP Service Pack 2 (SP2) and you have Windows Firewall enabled, you might receive the Remote Server Machine Does Not Exist or is Unavailable. 'GetObject' error message when your script tries to connect to a remote computer from WMI. To fix this problem, you have to make configuration changes on the remote computer you're trying to access. For more information about these changes, see the Windows Scripting Solutions article “Solving a WMI Remote-Connection Problem,” May 2005, InstantDoc ID 45822.
• Some WMI read-only properties (e.g., the read-only properties in the Win32_ComputerSystem and Win32_OperatingSystem classes) don't generate error messages as they should. If your script tries to write to one of these read-only properties, the scripting engine doesn’t return an error, although the write operation failed. To learn workarounds for this problem, see the Windows Scripting Solutions article “Rem: Identifying and Verifying Writable Properties,” January 2003, InstantDoc ID 27340.
• If your script is retrieving information from WMI’s Win32_QuickFixEngineering class, your script might hang because the WMI provider (cimwin32.dll) that services that class contains a bug. The problem is isolated to the Win32_QuickFixEngineering class and occurs only when using WMI 1.5 with Windows 2000. For more information about this bug, see “WMI Win32_QuickFixEngineering Queries Cause Winmgmt Process to Hang,” http://support.microsoft.com/?kbid=279225.
• If your script is trying to use WMI’s Win32_Processor class to inventory the total number of physical processors installed in a server farm, WMI might report hyperthreaded processors as multiple processors. For more information about this problem, see the Windows Scripting Solutions article “Rem: WMI Isn’t Hyper-Thread-Aware,” November 2003, InstantDoc ID 40228.