Best practice for maintaining web.config files with multiple front-end servers

Question

How are people handling the maintenance of the individual web.config files when dealing with multiple SharePoint front-end servers (FES)?

Microsoft recommends that you should not update your IIS server's web.config file directly. They recommend that you use a secondary config file where changes to the web.config file are maintained; a sort of a "delta" file. There are several reasons for this, outlined here.

However, the Microsoft articles (and others that I have seen) do no discuss the issues of maintaining multiple FES systems in a single SharePoint farm, which by definition means multiple web.config files. Should the approach be:

1. Update one FES system's web.config "delta" file directly, get this file replicated across all the other FES systems and then run the "apply updates" across all FES systems.
2. Update one FES system's web.config "delta" file directly, run the "apply updates" on that server and then run a process on all other systems to apply updates based on differences between the local web.config and the "master" web.config for the farm.
3. Update all FES web.config "delta" files at once and run the "apply updates" all at once.
4. Something else.

BTW: In our SharePoint farm all FES systems are offering the same services, so changes to one FES system would apply to all FES servers.

For the "apply updates" process I am considering using this codeplex offering. Does anyone use this, or have any experience with alternatives?

Answer 1

The ideal solution is to use PowerShell (or C#) and use SPWebConfigModification class for making configuration changes.

The advantage of this approach is that the changes will get retained in case of System Upgrades, Migration etc.

This will also push the configuration to all servers in the farm.

Some useful links

http://southworks.com/blog/2013/01/04/updating-the-web-config-in-sharepoint-applications-the-right-way/

http://blogs.technet.com/b/heyscriptingguy/archive/2010/09/14/use-powershell-to-script-changes-to-the-sharepoint-web-config-file.aspx

Answer 2

There are two ways to customize the Web.Config settings.

1. How to: Create a Supplemental .config FileThe declarative approach is best suited to situations where you need to add large amounts of XML code. In addition, all the configuration changes are applied to every application on the server.
2. How to: Add and Remove Web.config Settings ProgrammaticallyThe SPWebConfigModification class provides more control than the declarative approach. You can modify any node or attribute in the Web.config file. This means that the modifications can be as granular as you require. In addition, you can also target the modifications to a specific Web application instead of applying them to every application on the server.

Both method are recommended:

Changes that you make to any of the web.config files that are built into SharePoint Foundation, or that are created when a SharePoint Foundation Web application is created, may be overwritten when you install updates or service packs for SharePoint Foundation, or when you upgrade an installation to the next product version. For this reason, we recommend that you not directly edit these files. Make changes to web.config settings using either the method described in How to: Create a Supplemental .config File or the method described in How to: Add and Remove Web.config Settings Programmatically. With either method, your custom settings can be reapplied post-upgrade.

Working with Web.config Files