Optimizing the process of deploying SharePoint Packages to minimize the impact on farm’s availability
If you have deployed SharePoint Packages in the past, you know, that, unless you have a second farm, deploying SharePoint Packages means outage to your Web Applications. There are however a few things that you can control to minimize the impact on the availability of your websites.
The deployment process is a black box
The process of deploying SharePoint Packages might seem to you like a blackbox. Not surprisingly: you build a SharePoint Package, add it to your SharePoint farm and finally deploy it to one or more Web Applications. Except for scheduling when the deployment should be executed, it seems like there isn’t much you can tweak. It turns out however, that there is some fine print in the deployment process and changing a few things in your deployment process could help you minimize the impact on the availability of your websites during the deployment process.
When talking about deployment process of SharePoint Packages, I mean the deployment itself as well as retracting and upgrading SharePoint Packages. All of those are being managed by the same Timer Job so to keep things simple I’ll refer to all of those as the deployment process.
Defining the boundaries
Depending on the contents of your SharePoint Package, you might experience some outage of your Web Applications, but you might also need to restart the SharePoint Timer Service, Search Service or other components. You should know, that the deployment process affects only Application Pools. All other components are not being touched during the deployment process, and if you must reset them, for example to update a Timer Job, you have to do it yourself.
How it works: the deployment process
The deployment process starts with a check to determine if SharePoint should stop Application Pools. The logic behind this check depends on the deployment mode.
- When deploying a SharePoint Package, the deployment Timer Job checks if you have used the Force switch.
- When upgrading a SharePoint Package the job checks if the value of the ResetWebServerModeOnUpgrade attribute has been set to StartStop.
- When retracting a SharePoint Package the check simply returns true.
Whenever this check returns true, the deployment job will stop Application Pools. If your SharePoint Package contains Web Application resources and is being deployed to one or more Web Applications, the deployment job will stop only Application Pools of the Web Applications to which the SharePoint Package is being deployed. If you however deploy a Global SharePoint Package (one that has no Web Application-scoped resources) then it will stop Application Pools of all Content and Administration Web Applications. Another important thing to notice here is that the StartStop value is the default value for the ResetWebServerModeOnUpgrade attribute in Solution Manifest. So unless you explicitly set it to Recycle, it will remain set to StartStop.
After this check the real deployment work starts. This is the process involving unpacking the SharePoint Package and provisioning all its contents to servers in your farm.
When the provisioning process is finished, another check is being executed. If the first check returned true, and Application Pools were stopped, all of them will be started now. The deployment job keeps a list of all Application Pools that have been stopped so it knows which of them should be started. If however the first check returned false, the deployment job will now check if it should recycle Application Pools. Just like the first check, also here the logic depends on the deployment mode.
- When deploying a SharePoint Package, the deployment job checks if you have set the ResetWebServer attribute to true and you haven’t used the Force switch.
- When upgrading a SharePoint Package, the deployment job checks if you have set the ResetWebServerModeOnUpgrade attribute to Recycle.
- When retracting a SharePoint Package the check simply returns false.
If this check returns true, then the deployment job will recycle affected Application Pools. Similarly to the previous check, if the SharePoint Package is being deployed to one or more Web Applications only Application Pools of those Web Applications will be recycled. Deploying Global SharePoint Package will cause all Applications Pools to be recycled.
Tips
With all that it becomes clear that preferably you would want your Application Pools to be recycled to minimize the downtime and you would want the deployment job to recycle only those Application Pools that belong to your Web Applications. With regard to minimizing the impact on the availability of your and other Web Applications we can define the following tips:
- Never use the Force switch. Not only it makes SharePoint stop affected Application Pools but also it prevents you from seeing errors should there be any. The Force switch might be useful in some scenarios, like fixing broken deployments of SharePoint Packages, but in general you should try to avoid using it.
- Set the ResetWebServerModeOnUpgrade attribute to Recycle. You have to do this explicitly in the SharePoint Package configuration. Without it, the setting will default to the StartStop mode which will cause stopping affected Application Pools.
- Schedule retracting SharePoint Packages when there is the least traffic on your Web Applications as it always stops affected Application Pools.
- Avoid creating a lot of global SharePoint Packages and try instead to provision as much as you can to specific Web Applications. Every time you touch a global SharePoint Package all Applications Pools will be stopped/recycled. Although there are some scenarios when you can’t avoid creating global SharePoint Packages, you should try to avoid them.
Summary
Deploying SharePoint Packages often equals some downtime on your Web Applications. There are however some things that you can control about the deployment process that can help you minimize the downtime and lower the impact on availability of other Web Applications in your farm.