It was the perfect storm that unfurled to cause this commotion that had us spinning our wheels for a while. A User left the company and had been deactivated in CRM (we’ll call this record User1). Due to policy (I’m guessing policy, as I have heard the practice is not recommended) the user Account was deleted in Active Directory (AD). Well, lo and behold, this User decided to return to the company within a few months of leaving. When the Administrator attempted to reactivate the User within CRM, they were unable to because the User was no longer in AD; the User was added again in CRM (the new User record will be User2). After this the User was once again set up within AD, but any attempt to log into CRM failed.
Any attempts to reactivate User1 throws an error even if you deactivate User2. This is because within the DB there is a field that holds the ActiveDirectoryGuid. This value holds the link to the AD ObjectGuid and was broken once the Account was deleted from AD. In our case, when the Account was recreated in AD, the GUID was then linked to User2 in CRM. This complicated things a bit as the resolution was not as obvious, but it is still manageable.
The main fix is that the ActiveDirectoryGuid needs to be updated with the GUID from the newly created AD Account. Since we accidentally created User2 in CRM and it was updated with this new AD GUID we lucked out in that the GUID is available and visible to us. If your situation is not the same and there wasn’t a second User created in CRM, but instead the AD Account was deleted and recreated, there are articles available that can assist in finding the AD ObjectGuid.
First, query the CreatedOn, FullName, DomainName, InternalEmailAddress, and ActiveDirectoryGuid in the SystemUser table for the User that is causing the issue. Do not query the FilteredSystemUser table, as ActiveDirectoryGuid is not present in the view. You will want to copy the GUIDs into another application, such as Notepad, and mark which one is associated with the User2.
For User2 you will want to change the values in the FullName, DomainName, and InternalEmailAddress fields so that they are different from User1. This is not only to differentiate the records when you change the GUIDs, but also so the duplicate record isn’t causing crossed wires at the login. I updated each of the fields by adding a ‘1’ after the last name of User2.
Since you must have a value for the ActiveDirectoryGuid field, it must adhere to a specific format, and you cannot have duplicate GUIDs. I modified the GUID for the User2 by changing a character in the GUID.
Now you can update User1 with the new ActiveDirectoryGuid.
Within CRM deactivate User2 and activate User1. When the User attempts to log in, they should be successful now.
| SCOTT FLORANCE |CRM Business Software Consultant
Scott Florance is one of the CRM Consultants at KTL and has proven his value as a member of the team since September 2013. Whether implementing a new CRM organization or adding to existing configurations, Scott has engaged clients with a positive and enthusiastic demeanor to help them meet their organizational needs. With four plus years of experience, Scott is familiar with CRM as both a power user and administrator. Scott received his bachelor’s degree in business administration from the University of Central Florida. He is a Microsoft Certified Technology Specialist for Dynamics CRM as well as a Certified Scribe Technician. |
