I use a program (Cobian Backup) to backup my users' laptop hard drives to a server when they are in the office. This runs as a service on the client laptop, logged in as a user with admin access to the data on the laptop and obviously the backup location.Since I moved it to AD (from an old NT4 domain), something keeps locking this account, causing the local PC service not to start and the backup to fail. I can find no evidence in the security log either on the DC or the backup location. The account's password is set to never expire and when the problem occurs the service will only restart when the password is reentered in the Service Properties tab on the local machine. It will then work again for an indeterminate length of time before "locking" out (though it's not locking out in the normal sense of the word). I'm totally stumped as to why this may be; anyone any ideas? My initial thought was to switch to MS Backup, but it too wants a username/password combo. I don't think it's Cobian at fault as I'm using a couple of versions and it was previously very stable.thanksCalum

Hi, From your description, I understand after moving a laptop to a Domain, account keeps locking, although you configure "Password never expire". And, there is no clue in Event log. Actually, expect logon, there are many other possible way a user account needs authentication with domain controller. I list some common factors as the following for your reference. To troubleshoot account lockout issues, you may check the following one by one: 1)Applications Many applications will cache credentials or keep active threads with credentials after a change in password resulting in the old password continuing to be used. 2)Service Accounts Service Account passwords are cached by Service Control Manager (SCM) on member computers and domain controllers in the forest. Resetting the password for a service account without resetting the password in SCM will cause account lockouts of the service account. Look for a pattern in Netlogon and event logs from individual clients as they retry logon authentication using the previous password. 3)User logging on to multiple machines If a user is concurrently logged on to multiple computers, the threads of network applications running on those computers may run in the context of that locally logged on user when accessing resources in the domain. If this user changes his/her password on one of the computers, applications running on the other computers will still use the original password. As those applications authenticate when accessing network resources, the old password is still being used, and the users account becomes locked. When changing the password, log off from all consoles including Terminal Service sessions, change the password from a single console, and log off there as well. 4)Scheduled Tasks Scheduled processes may have been configured to start using credentials that have since expired. 5)Persistent Drive mappings Persistent drives may have been mapped using credentials that have since expired. The simplest way to ensure current credentials are used is to cancel and re-establish the mapping. Persistent Net Use shares are often the cause of users locking themselves out accidentally. When explicit credentials are entered while connecting to a share, the credential is not persistent unless it is explicitly saved in Stored User Names and Passwords, whereas the mapping is consistent. Every time the user logs off, logs on, or reboots, Windows attempts to restore the connection, and the authentication attempt fails because there are no stored credentials. This increments the badPwdCount attribute. To avoid this problem, configure Net Use not to make connections persistent. To do this, type net use /persistent:no at a command prompt. 5)Service Accounts By default, many computer services are configured to start/log on using the Local System account. However, a service logon account can be manually configured to log on using a specific user account/password. If a service is configured to start with a specific user account and that user later changes his/her password, the service logon property will need to be updated with the new password or that service may lock out that users account. 6)Account lockout for remote connections The Active Directory account lockout feature that is discussed in this section is independent of the account lockout feature for remote connections. 7)Internet Information Services By default, Internet Information Services (IIS) has a token-caching mechanism in place in which user account authentication information is cached locally on the server running IIS. If lockouts are specific to users accessing Exchange mailboxes via Outlook Web Access and IIS, resetting the token cache on IIS may resolve the lockout problem. If there is still on progress, please try the following troubleshooting steps: 1. We need to remove the previous password cache, which may be used by some applications and therefore cause the account lockout problem. To do so: 1) Click Start, click Run, type "control userpasswords2" (without the quotation marks), and then click OK. 2) Click the Advanced tab. 3) Click the "Manage Password" button. 4) Check to see if these domain account's passwords are cached. If so, remove them. 5) Check if the problem has been resolved now. 2. In addition, I wonder what value is set as the Account Lockout Threshold in the domain password policy? You can check the following article for more information: Troubleshooting account lockout problems in Windows Server 2003, in http://support.microsoft.com/?id=315585 Please then check if the problem has been resolved. If the problem still persists, we need to perform further research by checking the event logs. I understand you have enabled logon auditing on the domain level and I just want to verify you have enable the correct settings to check the security event logs on all domain controllers. Step 1. Enable Auditing at the Domain Level: ======================================== To effectively troubleshoot account lockout, please make sure you enable auditing policy at a domain level GPO (for example, the Default Domain Policy) for the following events: - Account Logon Events - Failure - Account Management - Success - Logon Events - Failure Step 2. Analyze the event logs: ======================================== After the account lock issue occurs, we can analyze all the Security event logs on all the domain controllers to see what client/process caused the account lockout problem. To simply the operations, you can use the EventCombMT.exe tool, a multithreaded tool, to gather specific events from event logs from several different computers to one central location and then search those event logs for specific data of interest. The specific search for account lockouts has built into the tool. The following are steps to use this tool: 1. Download the EventCombMT utility from following Microsoft Web site: http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=7af2e69c-91f3-4e63-8629-b999adde0b9e Note: The EventCombMT utility is included in the Account Lockout and Management Tools download (ALTools.exe). 2. Start EventCombMT. 3. On the File menu, click Set Output Directory, select an existing folder, or click New Folder to create a new folder to save the output to, and then click OK. Note: If you do not specify an output directory, the default location is C:\Temp. 4. On the Searches menu, point to Built In Searches, and then click Account Lockouts. 5. All domain controllers for the domain appear in the "Select To Search/Right Click To Add" box. Also, in the Event IDs box, you see that event IDs 529, 644, 675, 676, and 681 are added. 6. In the Event IDs box, type a space to the end of the of existing line, and then type 12294 after the last event number. Therefore, the line should be "529 644 675 676 681 12294" (without the quotation marks). 7. On the Options menu, click "Set Data Range" to choose an appropriate data range. 8. Click Search. By analyzing these Event, we can locate which service or application is root cause for account lock.

Thanks for your help - managed to track it down to a Group Policy object; Log on as a Service was defined directory-wide but not for that particular account.Seems to be working now,Calum