SharePoint 2013 – Changing Application Pool Identities Using PowerShell

​Each Application pool in SharePoint has an identity/account that it runs under. There are many scenarios where you may need to change the application pools to run under different credentials, and there are multiple ways you could possibly go about it.

However, doing it wrong can lead to a lot of headaches and service outages in your farm. In this article we will look at the correct way to change the Application Pool Identities for SharePoint for both Service Applications as well as Web Applications. This article focuses on using PowerShell to make these changes.

The number one thing to remember when making changes to application pools in SharePoint is that SharePoint is not fully aware of IIS. This means that in most cases if you make changes in IIS, SharePoint will not “know” about these changes. To make it more plane, since SharePoint does not monitor IIS, any changes you make in IIS will not be stored in the SharePoint Configuration database. Meaning that your backups and restores, etc. will not take IIS settings into account. So if you were to make changes to the application pools in IIS, then run into a situation where you had to restore a SharePoint farm backup, your changes would be ignored and SharePoint would restore the settings that it had before your changes were made. This can lead to a lot of time wasted troubleshooting issues that are not directly related to SharePoint. The other issue you run into making changes directly in IIS is that the changes are not replicated across to the other servers in your farm. Meaning you now not only have to make sure you manually configure each server to match the others, but you also have a much harder time troubleshooting as you have to start validating the settings on each server.

The better route to go when you need to make changes to the Application Pool accounts in a SharePoint farm is to do it either through Central Administration, or through PowerShell. Both of these have the benefit of ensuring that your changes are applied across every server in the farm, as well as being saved to the configuration database so that any backups or restores you perform will have the correct configuration. Another benefit of using these methods is that SharePoint will automatically assign the correct permissions and group memberships to the accounts. Service accounts in SharePoint require permissions in many areas and letting SharePoint handle assigning them automatically. For this article we will look at using PowerShell for making these changes