Shell Script Method for Script - Errors in RMAs Event Log

[jivetolkein]

Odd problem that appears and goes way with no particular reason - I'm runnning a disk checking script from an RMA (server and RMA windows, target also) and get the following error appearing in the system log of the RMA:

Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Date: 27/07/2007
Time: 11:20:10
User: N/A
Computer: blahblah
Description:
The Security System detected an authentication error for the server host/servername.local. The failure code from authentication protocol Kerberos was "The referenced account is currently disabled and may not be logged on to.
(0xc0000072)".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 72 00 00 c0 r..À

Names have been changed to protect the innocent

Very odd, because the same check runs just fine on other servers and the account RMA runs as is not locked out or disabled. The only servers that have the issue are on one remote site.
The test function returns OK, and other checks on the same servers are just fine. The servers are in a diferent domain to the RMA, but other servers in that domain return OK (the whole site is in the other domain, so I can't check a common domian/different site scenario).

Any ideas? I'm thinking of adding an RMA to the site, but I'd rather not use another licence and complicate the setup anymore.

[KS-Soft Europe]

Strange error... Looks like some network security problems or wrong authentication information. Probably, the following article will be helpful:
http://support.microsoft.com/kb/931192
http://support.microsoft.com/kb/938702
http://support.microsoft.com/kb/823712

I suppose, the phrase "The referenced account is currently disabled and may not be logged on to" is the key. Please, verify the username/password that are specified to start RMA service. Probably, domain password was changed by administrator, but RMA service still have been using old password.

Regards,
Max

[jivetolkein]

I'll check out those articles, but my group are the only people capable of changing the service accounts password (it's running as a domain user account, which is admin on the monitored boxes)- it hasn't changed, and in fact is still working OK on other checks, and the same check on other servers. Just these few servers on this one site, and the script errors - it returns (when run by hand)

Error # -2147023071

.. it's VBScript, and I haven't found any references to that error anywhere.

I'm sure it's MS/VBScript/Network related rather than AHM, as it works everywhere else just fine. Just thought it was worth posting in case it'd cropped up before.

[KS-Soft Europe]

I'm sure it's MS/VBScript/Network related rather than AHM, as it works everywhere else just fine. Just thought it was worth posting in case it'd cropped up before.

Hm. Interesting issue. Looks like Automation error. Do you use WMI or some ActiveX objects in your script? Probably, DCom configuration was changed on target server. Have you tried to reboot the target server?

Sorry, I can not provide much help on this issue

Regards,
Max

[jivetolkein]

Yeah, WMI query.

Rebooting isn't an option, though chances are it'll get one from Patch Tuesday soonish. Plus I'm going on holiday so I'm not starting anything that might result in overtime now

Just in the process of configuring a local RMA agent on the subnet to see if it helps.

[KS-Soft Europe]

Plus I'm going on holiday so I'm not starting anything that might result in overtime now

Have a great holiday!

Just in the process of configuring a local RMA agent on the subnet to see if it helps.

Please, let us know you fix it.

Regards,
Max

[jivetolkein]

The good news - it works, using an agent on the same site/subnet

Same user account (for RMA to run as), but now the server hosting the RMA is in the same domain as the target. Strange.

I'll leave it at that, as our concept calls for an agent per site anyway - was just trying to be cheap as it was a small (<5 server) site.

I'll post an update should it stop again...

[jivetolkein]

Been fine for a while, then 11.08 this morning, packs up again.

I think theres some kind of authentication issue as there's no DC on site, but looks like more investigation required

[KS-Soft Europe]

Been fine for a while, then 11.08 this morning, packs up again.

It is a pity

I think theres some kind of authentication issue as there's no DC on site, but looks like more investigation required

While browsing thru the Internet I found out that that such error might be caused by the time defference between computers. Could you check the time difference between machine, where RMA is running, machine you want to monitor and DC? Is the time difference less than 5 minutes?

Regads,
Max

[jivetolkein]

Thanks for looking Max - no time difference. Pity, that sounded very feasible, as it seems to be a Kerberos authentication related issue.

There are 3 servers on this remote site, in domain X, AHM is on a server in Domain Y (which is at the HQ) - all in same forest. Check is now running from an RMA on a server local to the problem box, but the RMA runs in the context of a user in domain Y (as do most administrative or service tasks).

As all the other checks run quite happily, I can only conclude its something in the script - unfortunately I don't know anything about how WMI works under the hood so I'm a bit stuck where to look next. The same script works just fine on the server with the RMA installed though.

I think the next thing is to try a user account in the same domain as the servers, to run the RMA as. Maybe this'll simplify the authentication enough to be reliable.

[KS-Soft Europe]

As all the other checks run quite happily, I can only conclude its something in the script - unfortunately I don't know anything about how WMI works under the hood so I'm a bit stuck where to look next. The same script works just fine on the server with the RMA installed though.

Probably, the following article allows you to reveal WMI security isues: http://msdn2.microsoft.com/en-us/library/Aa393266.aspx

I think the next thing is to try a user account in the same domain as the servers, to run the RMA as. Maybe this'll simplify the authentication enough to be reliable.

It might help.

Regards,
Max

[jivetolkein]

Using a new account in the same domain as the server to run the RMA works - fails when I change back to the other user, that works perfectly OK for other checks., and works running the same script on servers in that domain on other sites.

Very strange, but clearly nothing AHM related. If I ever find a solution I'll post it, but I'm going to just work around this for now.