given that you are using a local admin user for your authentication. I am wondering what //hostname resolves to? There is a possibility of the RPC handshake going wrong and therefore the communication never taking place successfully (see http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/99c278fe-df63-408b-b5b1-b95554b6b630/)
That would make sense, but in this case I dont think it applies. The machines (both zenoss server and the ToBeMonitored win2k3 mahcine) are in the same network segment. if I do a dns resolution of that hostname, it comes back with the correct IP. Same thing goes for the reverse-lookup.
Thanks for the help. If you have any other clues, please let me know.
Try running the same WMI command with the IP address instead of hostname.
If you get the same successful result, check out the event logs for any failures to connect.
If you see nothing in the event logs try getting a network capture on the Windows server side with Wireshark if you can or Windows NetMon. That should provide a little more information to what exactly is happening and where.
That is a great idea, I will try it with this server, although this may be a firewall realted issue as we are using old local sygate installation for firewall filtering.
I'm seeing the same issue, its mostly 2008 issues. It looks like UAC issues. What has worked so far is to add the zenoss user into the distributed dcom group (if it isnt a domain controller) or go into the dcom program and give the user access (if it is a domain controller).
then, restart the WMI service. I also suspect a windows bug on some of the servers I've seen, especially pre-SP1 2008 R2 servers.
I had really hoped Doug's suggestion above would work but adding my ZenAdmin to the DCOM group did not resolve the problem. The account is also a member of Administrators.
I recently built 4 Windows 2008 servers and added them to Zenoss. Only one of them is having this issue where Zenoss is getting NT_STATUS_ACCESS_DENIED everytime it tries to connect via WMI.
I can connect to this server with the same credentials that are in zWinUser and zWinPassword over RDP and through the WMI test tool (wbemtest.exe). Oddly enough the error that is logged in the Security event log on the server states "Unknown user name or bad password". I've tried creating multiple accounts and even having Zenoss use the Administrator account without success. It's almost like Zenoss is passing weird credentials to this device only...
Any ideas? I've been banging my head against this wall for several hours.
Event log entry:
"An account failed to log on.
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: zenadmin
Account Domain: WORKGROUP
Failure Reason: Unknown user name or bad password.
Sub Status: 0xc000006a
Caller Process ID: 0x0
Caller Process Name: -
Workstation Name: NA-DEN-ZEN-01
Source Network Address: 220.127.116.11
Source Port: 56545
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested."
Fixed my WMI issue...this turned out to be a weird setting that was applied when doing security lockdown. I think it was applied incorrectly. I found this by comparing local security policy between a server that was working and this server that wasn't.
I found under Local Security Policy > Local Policies > Security Options > Network security:
LAN Manager authentication level was set to Send NTLMv2 response only. Refuse LM & NTLM. Once I matched my other server and changed it to Send NTLMv2 response only Zenoss could login correctly.
No idea why this did it but I'm glad it's working finally.
Follow Us On Twitter »
||Latest from the Zenoss Blog »||Community||Products||Services||Customers||About Us|
Copyright © 2005-2011 Zenoss, Inc.