Is That a Web.Config Ninja?
One of the new feature in SharePoint 2010 is the Health Analyzer. At its core, it’s a set of rules that perform checks and/or repairs executed by timer jobs. When a rule executes, the output gets rolled up into a Health Analyzer Report that helps inform SharePoint Administrators about any potential issues with their farm configuration.
Even if you don’t have any interest in Health Rules/Reports, its something you should know about. The rules (including those that ship out of the box) don’t all just harass you into maintaining a cleaner farm, some of them actually “correct” possible issues without asking first. Having a series of timer jobs that can modify your farm adds complexity, and you should know what possible modifications can be made while you’re off the clock.
If you’re curious as to where these rules live, they can be found in the Central Administration site under Monitoring->Review Rule Definitions.
Case In Point
In a recent engagement we were using the stock ASP.NET Membership Provider for user management (for FBA accounts) in a Claims Based Authentication site. It became important to be able to decrypt users password for retrieval which meant that we had to modify the encryption/decryption settings. For the stock provider, these are housed in the <machineKey> setting in the web.config.
Then things got weird.
Across many of our machines, the settings kept getting rolled back. Every night at 12:00am (midnight) parts of the web.config would get reverted to the old machine key settings. It got to the point where we were considering making the web.config read only.
Then we did some snooping around and found out about a particular Health Rule that takes syncing web.config files pretty seriously. There’s one in particular called Web.config Files are not identical on all machines in the farm which out of the box will repair automatically. This can be a huge help if your web.config settings have unintentionally fallen out of sync, but if its rolling back intentional changes, then its downright troublesome.
There’s nothing wrong with this rule per se, but if you ever find yourself having similar issues, I’d recommend unchecking the Repair Automatically check box. This will hopefully help you both find closure, and move on to the next SharePoint woe in your life. Hope it helps someone.