Recently, my Active Directory user account was getting locked out on a regular basis after changing my user account password. In our environment, the most two common causes for Active Directory user account lockouts are disconnected RDP sessions or an invalid password on a mobile device configured for Exchange ActiveSync access.
I used the LockoutStatus.exe Tool to search for one or more disconnected RDP sessions using my old password but I was not able to find anything. So, the next thing I checked was my iPhone. I checked my iPhone Exchange account settings and password and confirmed everything checked out and my device was synchronizing mail just fine.
After several hours of additional troubleshooting, I learned that it was an older mobile device, a Pocket PC, that I own that was causing my user account to lockout. To make a long story short, I needed to charge up the battery for my Pocket PC device for another project I was working on and I had forgotten that I had previously configured the device for Exchange ActiveSync access quite some time ago and didn’t even think about it while I was charging up the battery. After taking care of my Pocket PC device, my Active Directory user account was no longer getting locked out.
Here are a couple of troubleshooting tips to help you narrow down your search if you run into something similar in your environment.
1) On a CAS Server, run the PowerShell command: Get-ActiveSyncDevice –Mailbox <user’s email address> to get a list of user devices
2) On a CAS Server, run the PowerShell command: Get-ActiveSyncDeviceStatistics –Mailbox <user’s email address> to get the LastSync information for the each of the devices the user owns
3) Search through the IIS logs on all of your CAS servers. You can search for iPhone or, in my case, PocketPC entries in the logs on each of the CAS servers to help narrow down your search.
Recently, several enabled Remote call control (RCC) users reported that they were having issues making phone calls from Communicator.
When they attempted to call a number, they got a “Cannot locate <user>” error message and when they clicked on Retry, they got another error message, “There may be an error in the address. Check the address and then try again.”
After some troubleshooting, we found out our CSTA Gateway server was using an expired certificate.
For communication to take place, the CSTA Gateway and Microsoft Office Communications Server 2007 R2 must exchange signed server certificates each time a TLS session is opened.
After installing a valid certificate and restarting the services on the CSTA Gateway server, our users were able to make phone calls from Communicator again.