Archive

Archive for February, 2011

Importing CRM 4.0 Organisation Fails while Adding Users

February 16, 2011 3 comments

Every now and again I’ll get stuck on a problem and it will consume me for days.  In these situations, there are scraps of information on the InterWebs but not quite that killer blog post which nails your problem.  Well I’m hoping this is going to save some others a few days of madness…

Scenario

You are attempting to import a CRM 4.0 organisation from one deployment to another. In my case, I was trying to import a copy of my production organisation into UAT.  During the import, the process fails with the following error in the import log:

10:55:16|  Error| Failed to add user using the DistinguishedName = CN=test test,OU=Test Users,OU=Restricted,DC=XXX,DC=local, Account Name = XXX\testSystem.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.DirectoryServices.DirectoryServicesCOMException (0x80072035): The server is unwilling to process the request. (Exception from HRESULT: 0x80072035)
   …
10:55:16|  Error| An error occurred when populating Microsoft CRM user groups. Ensure that CRM user accounts are accessible from the current domain and run the wizard again.System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.DirectoryServices.DirectoryServicesCOMException (0x80072035): The server is unwilling to process the request. (Exception from HRESULT: 0x80072035)
  

Checks:

I was pretty confident this was a permissions issue on Active Directory due to the ‘System.DirectoryServices’ signatures in the error.  However the following checked out to be true:

– Account running the Import had rights on the destination OU and subsequent security containers to create objects (users) for the new deployment.  I double checked by running AD Users & Computers on the CRM Server as the account I used to run the import.  I then manually created some user accounts inside the CRM Security Groups e.g UserGroup_GUID

– Both source and destination deployments were on the same RollUp (Rollup 8 in this case).

 

Solution:

So the AD security all checks out.  Why on earth was the import failing??? During my frantic Googling, I came across a comment which suggested that the account used to run the Import MUST be in the same Domain as where the CRM deployment is based! 

My account wasn’t! This may sound strange, but the reason was that the CRM deployments originally lived inside the LONDON domain.  The production deployment was moved to a SWISS domain, but the CRM Users remained in the LONDON domain, including the CRM Admin user.  This was the guy I was using to run my failed import to UAT.  The domains were trusted both ways, and as I mentioned above, I had no problem manually adding users into the UAT security groups?

However, when I ran the import wizard using an authorised user account native to the UAT deployment’s domain, hey presto – the import was SUCCESSFUL!

I still do not understand why this matters, however I hope the solution helps someone out there one day!

Categories: Uncategorized