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
script:
-------------------------------------------
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"
Else
'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
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
script:
-------------------------------------------
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"
Else
'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)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
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 = "."
strRemoteUserName="domain_admin_member"
strRemotePassword="domain_admin_member_password"
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_
14 years ago
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 ]
)
strServer[in,optional]
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.
objwbemServices = SWbemLocator.ConnectServer(
[ strServer = "." ],
[ strNamespace = "" ],
[ strUser = "" ],
[ strPassword = "" ],
[ strLocale = "" ],
[ strAuthority = "" ],
[ iSecurityFlags = 0 ],
[ objwbemNamedValueSet = 0 ]
)
strServer[in,optional]
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
14 years ago
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_
14 years ago
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 ?
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.