of the
It’s quite common to configure Microsoft Dynamics CRM during the installation to use domain account to run web application service. In fact, this is exactly how you configure load balancing front-end configuration.
It might be tempting to add the domain account selected to run CRMAppPool as CRM user. (Have no idea why, it just is). Harmless, right? Well, yes, if you consider completely crashing your CRM server a harmless event.
If you did not know any better, it is not the end of the world, the recovery process is reasonably straightforward and painless.
This tip is brought to you by Andre “I’ve got 88 in my handle” Margono.
Hi Team,
I read the KB Article 2500917 and tried to understand the scenario. I could infer that if a domain user configured to run the CRMAppPool is later on added as a user in CRM then the system may lead to crash. I would really appreciate your insight into this.
Thanks,
Anubhav.
Hi Anubhav,
it’s not “may”, adding CRMAppPool account as CRM user will lead to a crash.
Thanks George for the prompt reply.
Hi
This scenario recently occurred for one of my clients. they created a new CRMAppPooluser domain user account and swapped them out . but it sounds like not all the permissions have been set for the new CRMAppPool account because reports are failing. I have told them the new account is probably missing the required SPNs as documented in the implementation guide.
They are pushing for a method to put back the old service account which is currently a user in CRM. Disabling the user account in CRM does not seem to solve this because the old CRMAppPool account was used as the service account for the CRM services and disabling it as a user actually stops the ASYNC service from functioning.
Has anybody tried re-importing an org and then intentionally not mapping a user as a workaround ? I’m thinking this could be tried with the old CRMAppPool account which is still an active user in CRM , then swapping it back in as the CRMAppPool identity. Will that prevent it crashing again ?
IMHO, this is the wrong place to experiment and I’d recommend following KB article to repair. If the client insists, I would try importing the org and mapping old pool account to a new dummy account in AD to take it out of the equation; leaving it “as is” without mapping does not address the problem if AD is the same.
We messed up our test environment like this and importing it again would have taken another day (getting the approvals, backup, restore, import, etc.).
The microsoft KB (https://support.microsoft.com/en-in/help/2500917/the-system-crashes-when-you-add-an-account-that-is-running-the-crmappp) said that the problem is due to no roles assigned to this user as soon as it gets added to CRM. We noticed that while CRM UI wasn’t accessible, the APIs were working fine. So we wrote a quick console app to Assign admin role to this user – voila! it worked and we have testing going on now. I am not sure of the side affects but since its just a test environment which anyways would get refreshed next week so we don’t have to worry about anything (hopefully!)