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
WMI Problem
Moderators: Developers, Moderators
-
- Posts: 49
- Joined: Fri Mar 18, 2005 7:33 am
- Location: France
just need rights..
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.
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.
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)
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)
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
-
- Posts: 2
- Joined: Sat Aug 13, 2005 9:25 am
Re: just need rights..
Just to chime in here with my $0.02...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.
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. "
Who is online
Users browsing this forum: No registered users and 3 guests