Link to home
Start Free TrialLog in
Avatar of wantabe2
wantabe2Flag for United States of America

asked on

Windows 2008 Errors

I have a Windows 2008 domain contoller & it has started throwing numerous event ID 12294:

The SAM database was unable to lockout the account of Administrator due to a resource error, such as a hard disk write failure (the specific error code is in the error data) . Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above.


This server is also a FSMO role holder & a WSUS server. Has anyone seen this? I rebooted the server & it is still doing this...any ideas?
Avatar of Venugopal N
Venugopal N
Flag of India image

Avatar of wantabe2

ASKER

Doesn't help any...can't disable the admin account.
ASKER CERTIFIED SOLUTION
Avatar of Member_2_6515809
Member_2_6515809

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
There are no services as such exposed to eh outside world. This is just an internal LAN server that holds the following roles:

WSUS, Domain Controller, DNS server

I've ran a full virus scan & found nothing. There are no authentication failures in the security log. Still getting there same event around 4 or 5 events per minute.
I've looked in the netlogon.log file to see if there where any clients trying to log on as the administrator but I see no bad password logged....
Avatar of Sarang Tinguria
Follow this

Troubleshooting Account Lockout
http://technet.microsoft.com/en-us/library/cc773155(v=ws.10).aspx

Troubleshooting account lockout the PSS way
http://blogs.technet.com/b/instan/archive/2009/09/01/troubleshooting-account-lockout-the-pss-way.aspx

Below link is of specific tool which removes the Kido Virus found majorly producing such issues

http://support.kaspersky.com/1956
Go to "Protection measures":->kk.zip

You may check security event logs if auditing is enable to see which machine is generating bad password requests
I checked the log & discovered which clinet was trying to authenticate to the DC.