WMI Problem

Post support questions that relate to the Windows 2003/2000/XP operating systems.

Moderators: Developers, Moderators

Post Reply
tman
Cacti User
Posts: 97
Joined: Thu Oct 14, 2004 4:14 pm

WMI Problem

Post by tman »

Hi, I'm running Cacti 0.8.6f on a Win2k box that is polling other Win2k/2k3 servers, network devices and some Linux hosts.

I've downloaded some of the (very) useful contributed scripts and am using these to try and poll WMI information on the Windows hosts. All the hosts have SNMP/WMI installed and configured ok.

I'm finding more and more scripts that use WMI are refusing to poll, either using cactid or cmdphp, the log error I'm regularly seeing is;

WARNING: Result from CMD not valid. Partial Result: Unable to talk to WM

This is usually preceded in the log with the script command like like;

CMD: perl C:\Inetpub\wwwroot\cacti/scripts/w32_query_cpu.pl server1 get LoadPercentage 4, output: U

Is WM in this instance, WMI? What the hell is output: U? It sounds like a security problem, i.e. not enough permissions to query remote WMI info, but I've checked this, and the permissions seem ok, although I could be missing something I suppose. Interestingly enough although one of the scripts (CPU polling) fails on all remote hosts, it works fine on the host running Cacti. Again, security?

If I run the scripts from the command line against the remote hosts, everything runs fine and returns the correct information.

I'm pulling my hair out! Any ideas?

Thanks
scavenger67
Posts: 49
Joined: Fri Mar 18, 2005 7:33 am
Location: France

just need rights..

Post by scavenger67 »

You have the same problems as me 1 week ago.
i finally found the problem :
The user that poll the w2k server must be an admin of the server.
If you are running cacti by using task scheduler, be sure that the user configured to execute the task is a member of the admin group of the target host.
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

U means no data was returned.

Win2K3 along with XP SP2 have additional security, one of them secures down WMI. Find a guide for XP SP2 on how to get WMI working and apply the same method to your Win2K3 box (I too had this problem a long time ago with my xp and win2k3 boxes, but forget the exact steps on the fix).

Your polling user on the Win2K box will also need rights on the Win2K3 box (HOW TO: Set WMI Namespace Security in Windows Server 2003)
tman
Cacti User
Posts: 97
Joined: Thu Oct 14, 2004 4:14 pm

Post by tman »

Thanks for the responses. I guessed it was security related, but for long term Cacti users, it's probably a case of been there, seen it, fixed it.

I'll check on the permissions and post back on the results. Guess it might help other Cacti users at some point if there's something on the forums!
davidarcher
Posts: 2
Joined: Sat Aug 13, 2005 9:25 am

Re: just need rights..

Post by davidarcher »

scavenger67 wrote:You have the same problems as me 1 week ago.
i finally found the problem :
The user that poll the w2k server must be an admin of the server.
If you are running cacti by using task scheduler, be sure that the user configured to execute the task is a member of the admin group of the target host.
Just to chime in here with my $0.02...

The user that polls the remote Windows server does _NOT_ need to be an admin of the local or remote server. The default WMI permissions only allow remote WMI calls to Administrators but that doesn't mean you should have your polling done as an administrator user. A much more secure setup would be to create a new Domain User account and give that account permissions on the WMI namespace of the remote server you want to manage.

Here's a good article that explains WMI security and will help you on the way to having your poller run as a lower-rights user: http://redmondmag.com/columns/article.a ... ialsID=381 .

Favorite quote from the article:

"WMI must obey native OS security limitations. If you understand the Windows security model, including access control and authentication, you’ll be able to leverage this knowledge to securely use WMI and block unauthorized use. Without this background, you’ll be continually frustrated and end it by granting everyone membership in the Administrators group. Remember, administration is not just “making it work”—it’s making it work in a secure manner. "
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest