Tip #133: Do not add CRM application pool account as a user

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.
Share on FacebookTweet about this on TwitterShare on Google+

5 thoughts on “Tip #133: Do not add CRM application pool account as a user

  1. Anubhav says:

    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.

  2. alan ward says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *