Acces to WMI failes... on some pc's not all

have an issue that I have been trying to solve for quite a while now.

When the vbscript is executed from a command line there is no issue, but
when executed as a custom action during installation it fails. Here is the
Dim objLocator, objService, obj, BuildNumber

Set objLocator = CreateObject("WbemScripting.SWbemLocator")
Set objService = objLocator.ConnectServer( , "root\cimv2") <---- it failes
here on some PC's
objService.Security_.ImpersonationLevel = 4
Set obj = objService.Get("Win32_OperatingSystem=@")

BuildNumber = obj.BuildNumber

If obj.BuildNumber >= 6000 Then
If InStr(obj.OSArchitecture,"64") Then
OS = True
End If
End If

If OS Then
'IsVista64 = True
MsgBox "You are running 64-bit"
'IsVista64 = False
MsgBox "You are running 32-bit"
End If
First I thourght that the issue has something to do with rights, but I have
not been able to find any setting that could solve the issue

0 Comments   [ + ] Show comments

Answers (4)

Posted by: anonymous_9363 11 years ago
Red Belt
I'm surprised it works at all, since the script is missing a vital part, i.e. the name of the "server" to connect to. Set objService = objLocator.ConnectServer( , "root\cimv2")should beSet objService = objLocator.ConnectServer(".", "root\cimv2")where "." indicates that WMI is to query the local computer. If that still fails (and at my last client, it did on a very few machines, you could try the same syntax but with different credentials passed in. Clearly, if you used an account which was a member of domain admins, you should be able to connect to every machine in the domain:strRemoteServerName = "."

Set objService = objLocator.ConnectServer (strRemoteServerName, "root/cimv2", strRemoteUserName, strRemotePassword)
Obviously, you would want to encrypt the username and password (perhaps using public properties to hold the encrypted string) and add suitable error-trapping to the code.
Posted by: mba_ 11 years ago
Yellow Belt
See http://msdn.microsoft.com/en-us/library/aa393720(VS.85).aspx

objwbemServices = SWbemLocator.ConnectServer(
[ strServer = "." ],
[ strNamespace = "" ],
[ strUser = "" ],
[ strPassword = "" ],
[ strLocale = "" ],
[ strAuthority = "" ],
[ iSecurityFlags = 0 ],
[ objwbemNamedValueSet = 0 ]
Computer name to which you are connecting. If the remote computer is in a different domain than the user account under which you log in, then use the fully qualified computer name. If you do not provide this parameter, the call defaults to the local computer.

I have tested this script on may pc's and it is ok. There is just some PC's on which this does not work.
Posted by: Jsaylor 11 years ago
Second Degree Blue Belt
Obviously, you would want to encrypt the username and password (perhaps using public properties to hold the encrypted string) and add suitable error-trapping to the code.

Not to derail the conversation (okay, maybe I'm ruthlessly derailing it on purpose) but isn't this an enormous security hole? Anybody who gets their hands on that script could very easily discover the domain admin name/password with some really simple wscript.echo action when they recognize that you're using the connectserver method with the additional username/password arguments specified.

At some point the password has to be plain text, and that's just unnerving with something like a high-powered interactive account.

EDIT: Also, I only ask because I hope I'm wrong, I'd love to have a truly secure method of programmatic user rights elevation that doesn't rely on a third party wrapper.
Posted by: mba_ 11 years ago
Yellow Belt
Well, all parameters for the function a input parameters... so no security hole here.

But to get back on the track, is there any restriction you can set for the Windows installer or msi that will prevent acces to wmi during installation ?
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ