Friday, December 20, 2013

Important Note to CRM 2011 Administrators

If you administer CRM 2011 user accounts make sure and check to see if the user already exists before adding a new one.  I saw an instance where a disabled user already existed for an Active Directory user today and a new account was successfully created somehow.

The person could not log in and I am not even sure how you would resolve this in a supported manner because you cannot delete users in a supported fashion.

-Merry Christmas!

Tuesday, December 3, 2013

Error Installing CRM 2013 and Funny Resolution: Action Microsoft.Crm.Setup.Server.GrantConfigDBDatabaseAccessAction failed

I ran into an interesting error the other day installing Microsoft Dynamics CRM  2013 for a client. The error was:

 Microsoft.Crm.Setup.Server.GrantConfigDBDatabaseAccessAction failed.

Windows NT user or group 'domainname\SQLAccessGroup {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}' not found. Check the name again.

We searched high and low for someone else experiencing the same error and we found several blogs and threads where people had resolved this for CRM 2011 and CRM 4.0 by a variety of different means.

Here are some examples and a quick blurb about the resolutions (that I think are all false).

1 - resolution: exit SQL Server Management Studio on all boxes.

2 - resolution: close remote desktop on the SQL Server

3 resolution: clear Kerberos tickets on the SQL server, reset some passwords, etc....

4 resolution: make sure the user is a member of all the created AD security groups on the CRM Install

5 resolution: close SQL Management Studio and disconnect your remote desktop session.

 6 - resolution: delete your AD groups created by the install????

One thing you will notice pretty quickly is that there isn't any real rhyme or reason to these solutions and some of them seem pretty nonsensical, but if you read the comments, these posts did seem to help a lot of people (except number 6), but why????

Let's discuss that quickly...

Upon further examination I have determined that while they may all work, they are not really the solution.

The real reason this is happening in most of these cases is Active Directory replication delays where there is more than 1 domain controller in an active-active scenario.

The real solution is waiting 5 minutes when you get this error and hit retry.  Basically the server install is creating the active directory groups against one domain controller and then it is hitting the other domain controller to perform another action shortly after before the synchronization is finished between the domain controllers.  :). So absolutely anything that takes a few minutes or restarts a server or causes an update on the domain controller would work.  That's why there is no cohesiveness between the resolutions.

- Happy Tuesday!!