There may be another post on this but I don't see it so I apologize if I just missed it.
I've written several agent procedures that utilize WMI. What I've found is that these scripts run fine on some machines and not others and I've been unable to figure out what the difference is. I've verified several items that are NOT the problem:
1. The name space does exist on all the machines I'm running the script on
2. This is not OS dependant (ie, it runs on some vista machines but not others, runs on some win7 machines but not others, runs on some xp machines but not others...even when the service pack is the same)
3. I've placed AV exclusions in for the agent working folder
4. All machines have agent credential set with domain admin creds (tested and they pass)
I've been pulling my hair out on this one for the better part of the day. Have others had issues getting wmi variables to come back reliably? This never used to be an issue in the past for us on Kaseya 2008 or K2 6.0.1
Thanks in advance.
hi Sam, i am experiencing the same problem.
Did you get it solved?
are you still on 6.0.1? why not upgrade to 6.1 ?
I've seen a few machines with various WMI problems (disabled / broken winmgmt service, broken repositories etc). You could test this by using the wmic.exe utility from a command line on the troublesome machines and see if you can retrieve the WMI data that way.
@ Hans: we are on 6.1
@ Sam: WMIC is working on the machine and the same query results in the expected output. Somehow the Agent Procedure failes with this message: Failed in processing THEN step 1, Get Variable, with error invalid Parameter, WMI property = root\cimv2:Win32_OperatingSystem.InstallDate
The Agent Procedures works well on some other workstations.
Patrick, can you run the WMI command succesfull locally (just for testing)?
@Hans: Locally the WMI command works fine.
For example: wmic os get installdate
I also get the OS install date on my estate, but as WMI returns me results in it's favourite long format (20091023175507.000000+060), I use a bit of VBS to grab the date, reformat it, and then drop the returned value into the System Info. It's been a pretty reliable approach so far (aside from the odd machine with a broken Windows Script Host )
If the re-apply schema doesn't work you can maybe try to force an agent update on that machine and see if that makes any difference. For me the problem just sort of went away one day which happened to be after I re-applied the schema. I assumed it was either that or an update. If none of that works you should probably open up a ticket and hope it gets escalated to level 2 in a timely manner.