- AD account deleted and re-created
- AD restores
- Or anything else that would change the objectGUID in AD
External Error - No such Object on Server
If you haven't disabled the account, you don't have to follow the next instructions, simply change the username field to a random test account and save, and change it back again to the user account you want to configure and save, this will update the user GUID and the AD SID in CRM. However if you have disabled the account you need to do the following steps.
Building the LDAP Query
The process is simple and it involves finding out the new objectGUID and objectSID in AD with an LDAP query and update the CRM database manually.
You can use any LDAP tool, for simplicity I find LDP tool simple to use and also available with windows 2008 R2 servers.
Simply search for ldp on the windows search box, or type on the command prompt c:\ldp and press enter
1. With the tool open go to the menu Connection and select connect, type the LDAP/DC server
2. When connected, you need to bind the session to a user account, to perform the search under that user context. Go to the Menu Connection > Bind
3. I've used the currently logged on user, but you can specify any account you want.
4. When you bind the session to an account you should get a successful message like the below message:
0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User='NULL'; Pwd=
Authenticated as: 'DOMAIN\your_account'.
5. Now that you connected, go to Browse > Search
6. On the Search window, you type the Base DN (Distinguish Name) which is the location of the account in AD, select the scope: Base, and the most important select the attributes you want to view, in this case you only need:
objectGUID
objectSID
7. Click Run and the below screenshot shows the account new GUID and SID.
Compare the results with CRM
Compare these values with the ones in the CRM database:
select DISTINCT sub.fullname, sub.ActiveDirectoryGuid, sua.AuthInfo, sua.UserId
from SystemUserbase sub
inner join MSCRM_CONFIG.dbo.SystemUserOrganizations suo ON
suo.CrmUserId = sub.SystemUserID
inner join MSCRM_CONFIG.dbo.SystemUserAuthentication sua ON
sua.UserId = suo.UserId
where sub.DomainName = 'domain\username'
Update CRM database
From the screenshots above, we can see the information match with what it's in CRM and in AD. if the AD object changes in AD e.g. account deleted and re-created; the GUID and SID would be different in the LDAP results; with the results provided from the LDAP query, update the CRM database manually:
Conclusion
The above process applies to most scenarios when an account had the objectGUID and objectSID updated in AD and CRM becomes out-of-sync with AD, however if you didn't disable the account you are in a better position to simply change the domain username to a dummy account and revert it back, but when you disable accounts you can't enable it back again, you can then use the above process to recover the CRM accounts.
Hope this helps and please leave your feedback.
Thanks you very much ! Very Helpful ! Amazing How To with Good Screenshots.
ReplyDeleteThanks again;
Thanks Andy, I'm glad it helped.
DeleteRegards
Nuno
Hello. Just to say this article has been a real life saver for me today. Really helpful. The account I needed to recreate was an Deployment account. Without it the organisation import of a migration I'm doing failed as the account was disabled and deleted from AD.
ReplyDeleteFor anyone else that finds this article can I add a point? After updating SQL with the correct SID and GUID I had to restart the Dynamics SQL instance before I could enable the account in Dynamics.
Again- massive thank you!