Adding Dynamics CRM Service account as a CRM user

Noooooooo, what have I done! That was what I thought, when I realized what I had just done. Now let’s take it from the beginning.

I was looking for a service account in the AD and found one called CRM Service account and I thought, great let’s use that for testing. So I went and added that as a user to an organization development organization here at work. But just as I pressed save I got a strange error message back that said that I did not have any roles and that I cannot view the record. Strange… asked my colleague to check if he could help me, but no. He got the same error message! Then it hit me, I just added the account running the app pool in IIS to be a CRM User, nooooo!

No one could access that organization any more, and trying to do a trace said:

SecLib::RetrievePrivilegeForUser failed – no roles are assigned to user. Returned hr = -2147209463, User: [userid]

But checking the database clearly stated that I had roles still. Searching for the error message I found a KB: http://support2.microsoft.com/kb/2500917 and that clearly states:

By default, when a CRM user is created in Microsoft Dynamics CRM, the user has no security roles. Because the CRM service account is mapped with the newly created user, the CRM service account cannot operate anything. Therefore, the system crashes.

This behavior is by design. Making the account that is running the CRMAppPool into a Microsoft Dynamics CRM user is not supported.

and there was a Resolution, but it was not very helpful:

Keep the CRM service account as a dedicated service account.

Trying to find if someone have managed to solve this before I found this from 2012: http://crmbusiness.wordpress.com/2012/02/03/crm-2011-license-error-the-selected-user-has-not-been-assigned-a-security-role/

Here Ben Hosking is trying to go about it by changing the service account, but that means that all organizations will be affected, at least for a short while. But since this is local, we have development going on, on other organizations and I did want to make a bigger mess. So I chose a more dangerous path J. Removing the user I just added.

Now before you go down this path, ask yourself, if this organization will be completely unrecoverable will you be ok? In my case since it was a development environment and the data was not important, and all customizations was in TFS I was fine with that option too. So I started to create a new organization just in case everything blows to pieces.

I started with localizing the Guid the new user had, and then used a script to search for that value inside the database. I used this: http://gallery.technet.microsoft.com/scriptcenter/c0c57332-8624-48c0-b4c3-5b31fe641c58 with a tweak (of course).  Where they are specifying that they are looking inside “WHERE STY.name in (‘varchar’,’char’,’nvarchar’,’nchar’,’text’)” I changed that to just uniqueidentifier instead. That listed a bunch of tables and columns with the data in it. I did this for both the organization database and the MSCRM_CONFIG.

So I created a short delete script and tried it, this is what I came up with:

delete from usersettingsbase
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from QueueMembership
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from TeamMembership
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from SystemUserPrincipals
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from SystemUserPrincipals
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from PrincipalObjectAccess
where PrincipalId = '0585361D-083F-E411-B71B-005056AB641F'

delete from QueueBase
where OwnerId = '0585361D-083F-E411-B71B-005056AB641F'

delete from ResourceBase
where ResourceId = '0585361D-083F-E411-B71B-005056AB641F'

delete from MailboxBase
where OwnerId = '0585361D-083F-E411-B71B-005056AB641F' OR RegardingObjectId = '0585361D-083F-E411-B71B-005056AB641F'

delete from InternalAddressBase
where ParentId = '0585361D-083F-E411-B71B-005056AB641F'

delete RB from CalendarRuleBase RB
INNER JOIN CalendarBase B on B.CalendarId = RB.CalendarId
where PrimaryUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from CalendarBase
where PrimaryUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from OwnerBase
where OwnerId = '0585361D-083F-E411-B71B-005056AB641F'

delete from SystemUserBase
where SystemUserId = '0585361D-083F-E411-B71B-005056AB641F'

delete from MSCRM_CONFIG..SystemUserOrganizations
where CrmUserId = '0585361d-083f-e411-b71b-005056ab641f'

And voila the organization started again.
Now do you ask yourself if this is support?

You are kidding right?
Of course not!