Dynamics CRM 2013 Map users of trusted domain fails when importing an org
This scenario is when importing an organization into CRM 2013 and map users of a trusted domain
Mapping user may fail with an application error in the CRM Administration Tool
It is not possible to map all users of the trusted domain.
When mapping certain users of a trusted domain, deployment manager will crash.
Problem Event Name: CLR20r3
Problem Signature 01: mmc.exe
Problem Signature 02: 6.3.9600.16384
Problem Signature 03: 5215ef8f
Problem Signature 04: Microsoft.ManagementConsole
These errors have been identified within CRM Platform tracing:
Error occurred while attempting to map user "Wacker, Roland" with account contoso\rwacker during user mapping: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DirectoryServices.DirectoryServicesCOMException: The object already exists. (Exception from HRESULT: 0x80071392)
--- End of inner exception stack trace ---
at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args)
at Microsoft.Crm.SecurityUtils.AddPrincipalToGroupByName(String principalName, Guid groupId, Boolean limitGlobalCatalogSearches)
at Microsoft.Crm.Tools.Admin.ADUserMappingHelper.GetUserSidAndGuidByDomainAccount(DomainAccount domainAccount)
at Microsoft.Crm.Tools.Admin.ByAccountUserMapper.MapUserAccountInfo(User user)
at Microsoft.Crm.Tools.Admin.ImportUserMapper.MapUser(User user)
Exception: Microsoft.Crm.CrmSecurityException: LookupAccountNameW failed with error
at Microsoft.Crm.SecurityUtils.GetSidFromAccount(String accountName)
Failed finding AD GUID From SID for the given domain iwb. Exception: System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException: The specified domain does not exist or cannot be contacted.
at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context)
at Microsoft.Crm.SecurityUtils.GetGuidFromSidLimitingSearches(String domain, Byte[] sid)
Cause
There is a conflict object in the "foreignsecurityprincipal" container, that looks like this:
SID for contoso\XUser: S-1-5-21-21330434097-182411894-1085159986-21628
Conflict object:
dn: CN=S-1-5-21-21330434097-182411894-1085159986-21628\0ACNF:1890a367-d7e5-4a6d-9479-cb98afe92812,CN=ForeignSecurityPrincipals,DC=contoso,DC=com
Without conflict:
dn: CN=S-1-5-21-21330434097-182411894-1085159986-21628,CN=ForeignSecurityPrincipals,DC=contoso,DC=com
When you look at the “whenchanged” and foremost “whencreated” attributes of the objects, you should see they are very close together. This is the sign of a Active Directory “name conflict”. That is resolved by renaming one of the objects.
Resolution
The objects have the same “objectsid” attribute which is the problem. They should have the same attribute values for most operationally relevant attributes. So you can delete the object with the name conflict from an Active Directory Administration tool.
Reference: https://technet.microsoft.com/en-us/library/cc772726(v=WS.10).aspx
See the section “Replication Conflict Resolution”
You can avoid the problem in the future when you have the CRM Administrator use a specific Domain Controller.
You can add a registry entry for that:
Location: HKey_Local_Machine\Software\Microsoft\MSCRM
Key Type: String
Name: PreferredDC
Value: (type the name of the DC)
Reference:
https://support2.microsoft.com/kb/954811/en
Best Regards
EMEA Dynamics CRM Support Team
Share this Blog Article on Twitter
Follow Us on Twitter
Comments
- Anonymous
January 28, 2015
Good tip. I use this along with echo %logonserver% to find out which DC I currently belong too.