WMI execution in Win7 differs from WinXP
Hi
I would like to know why Win7 handles a WMI execution so differently compared to WinXP, and what to change to make it work.
The return error indicates that the remote server refuses or domain rules don't accept this but testing the very same WMI-script from a "similar" WinXP gives a successful execution.
We can take a very simple script as an example, for ex. 'get remote server up time':
strComputer = "SERVERNAME"
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem")
For Each objOS in colOperatingSystems
dtmBootup = objOS.LastBootUpTime
dtmLastBootupTime = WMIDateStringToDate(dtmBootup)
dtmSystemUptime = DateDiff("h", dtmLastBootUpTime, Now)
Wscript.Echo dtmSystemUptime
Next
Function WMIDateStringToDate(dtmBootup)
WMIDateStringToDate = CDate(Mid(dtmBootup, 5, 2) & "/" & _
Mid(dtmBootup, 7, 2) & "/" & Left(dtmBootup, 4) _
& " " & Mid (dtmBootup, 9, 2) & ":" & _
Mid(dtmBootup, 11, 2) & ":" & Mid(dtmBootup, _
13, 2))
End Function
So, I have 2 machines, (Win7 Ultimate and WinXP pro) both are members of the same Win Domain, I'm using the same domain uid on both machines and this uid is local admin on both machines.
On Win7 I'm getting an "access denied" on row 4 (Set colOperatingSystems = objWMIService.ExecQuery....)
but on WinXp there is no problem to get the uptime.
I also tried running this via an elevated DOS-prompt, but getting the same error back.
I believe the problem lies within the UAC but I can figure out how to make it work.
Rgds Kjell
February 18th, 2011 6:09am
On Win7 I'm getting an "access denied" on row 4 (Set colOperatingSystems = objWMIService.ExecQuery....)
but on WinXp there is no problem to get the uptime.
Do you run it on XP also with user rights?"A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
Free Windows Admin Tool Kit Click here and download it now
February 18th, 2011 9:00am
Not sure if I understand your question.
I'm using the same domain user account logged on to both systems, on both machines this user is member of "Local administrator" group. and finally, this user is also member of Domain Administrator group in the domain.
so, apart from the fact that one machine is WinXP and the other is Win7, the 2 situations is pretty darn identical :-)
both machines are very clean "out of the box" installations and members of the same domain (Win2003)
The only thing I've tested extra was via an elevated DOS-prompt as I'm aware of UAC in Win7, maybe this did not run correctly. I find it very difficult to know if something is running in elevated mode or not.
For VBS-files there are no option for "Run as Administrator" in the pull down menu.
Kjell
February 18th, 2011 11:36am
With UAC you have standard user rights. So user in the admin group doesn't have admin rights all the time. You have to request them for some operations. Thats the difference between XP and Vista/7."A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
Free Windows Admin Tool Kit Click here and download it now
February 18th, 2011 4:22pm
Maybe I have been unclear in the description of the problem, I'm sorry for that, english is not my native language.
I'll try again:
We are using the above script as an example: it's simple, will not harm any machine, but will give clear answer on how it works.
Executed on my Win7, by double clicking it on the desktop, targeting my Win7 (.), no problem; success
The same happens on my WinXp, both of these 2 are expected.
Now, changing the target machine to be my file server win2003 instead of the local machine (SERVERNAME) vs (.)
Still successfull if executed from my WinXP just by double clicking the script file, but not from my Win7
I know about the "truncation effect" UAC has on Vista/Win7 but that doesn't really explain the result.
Maybe, if you say that executing this script targeting the local Win7 is OK as a regular "user" but due to the truncation it will not work on my file server, this also sounds strange to me, I can run the script agains other workstations in the domain
from Win7
How can I make "Admin rights" take effect when executing a vbs-script file?
Kjell
February 19th, 2011 7:48am
How can I make "Admin rights" take effect when executing a vbs-script file?
start command prompt (cmd) as administrator (righclick and select "Run as administrator") and run the VBS file there.
If this fails, it must be something to do with the Server 2003. I don't have a server 2003, so I can't test it."A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
Free Windows Admin Tool Kit Click here and download it now
February 19th, 2011 8:53am
I thank you for the time spent on this, but sofar this is still an unsolved issue.
Just before your last comment (Saturday) it all of a suddenly worked as expected, the same way as it does on WinXP
No eleveted rights needed, just double click the vbs-script on desktop (and it keept working during Saturday evening)
But, now this morning I'm back on square one again :-( (I have not rebooted anything)
Access denied on line: Set colOperatingSystems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem")
The source for the error is : SWbemServiceEx
I also tried with the eleveted command prompt as you suggested but it gives the same error, Access denied
and yes, It still works on WinXP and has never failed there.
It must be UAC routines on Win7 causing this, since vbs scripts are executed via a script compiler so that's where the fucking up must happen, the biggest problem is that the error now shows an intermittent error as it worked for
a while Saturday.
Regards Kjell
February 22nd, 2011 4:25am
I beleive this to be a bug i win7, and I have tried to call Microsoft but could not find anyone interested in this so I'm dropping the subject too and staying with WinXP until solved by it self.
If anyone knows someone within MS interesting in possible bugs feel free to forward.
Regards Kjell Liljegren, Stockholm Sweden
Free Windows Admin Tool Kit Click here and download it now
February 22nd, 2011 5:31am
we are an Users are helping users forum. For such a technical issue you should create a support case at the MS support."A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
February 22nd, 2011 9:11am