If you have ever noticed that AD HelpDesk reported an account as NORMAL even though you know it is LOCKED OUT, then this blog post is for you. There is a solution to this problem! Here’s the question that I recently recieved:
I just purchased the AD Helpdesk pro version and was initially impressed with its features as a help desk manager. However in using a test machine and account I typed the wrong password in to lock out the test account and I am unable to get AD HelpDesk to recognize the locked account. It just stays as account status: NORMAL when in reality it is locked out. Is this a known issue and will there be a fix in the future?
I’ve answered this question a few times before. I read a blog post that suggested if you feel the need to write a long e-mail then you should probably just write the content in a more public forum and link to it from your email. So here goes…
The short answer to this question is, this isn’t really an AD HelpDesk problem, it’s due to Active Directory replication delays. Wait a while and the account will show up as locked out. This isn’t an especially satisfying answer, however, so here’s the detailed explanation and the real solution:
When an account becomes locked in Active Directory, the fact that it is locked out is stored on a specific domain controller. If you have many domain controllers in your AD environment, then this information takes time to replicate from one domain controller to the next. This means that it is fairly likely that if a user locks their account and then calls you immediately, the fact that the account is locked may not have replicated to the domain controller that AD HelpDesk ends up communicating with.
This is due to the fact that AD HelpDesk is not site aware. AD HelpDesk is not joined to the domain. When AD HelpDesk connects by default it will somewhat randomly get any domain controller in your organization based upon the results returned by a DNS lookup for domain controllers. This means you could be communicating with a domain controller on the other side of the country (or world). The larger the number of domain controllers and sites, the higher the likelihood that you will be communicating with one that is out of replication sync. Not good.
So how do you solve this? The best solution is to configure AD HelpDesk to communicate with a domain controller in the same site as the person whose account you are trying to unlock. For many people this should be fairly easy to accomplish if most of the people that they support tend to be in the same geographical location. Simply find the DNS name/ IP Address of a domain controller that is in the AD site for that geography and manually configure AD HelpDesk to communicate with that and only that Domain Controller. You do this by creating a “Settings Profile” in AD HelpDesk.
Alternatively, you really can just wait if you want to. Depending upon the domain controller you ended up communicating with, and how replication is set up in your AD forest, this could take quite a while. So I don’t think many people would think this is a very good solution, but it still think it important to point out that the issue does eventually resolve itself.
Configuring AD HelpDesk to talk to a domain controller in your site is very important for several of the canned searches as well. The locked account search will not find that a user is locked out, until that information is replicated to the domain controller AD HelpDesk is communicating with. It is an AD HelpDesk best practice to manually set the domain controller to one in your primary site when you maintain an AD Forest that contains more than a single geographical site.
If you need to service multiple different sites, simply create multiple settings profiles and give them site specific names. You can easily switch between the profiles to get a domain controller by domain controller view of what the user’s account settings are without waiting for replication.