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:

http://support2.microsoft.com/kb/954811/en

 

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter


Follow Us on Twitter



Comments (1)

  1. NatrajY says:

    Good tip. I use this along with echo %logonserver% to find out which DC I currently belong too.

Skip to main content