Why Bring Down the Entire Farm for Patches?
Why Bring Down the Entire Farm for Patches?
Many customers are surprised to learn they have to bring down their SharePoint farm just to apply a hotfix or service pack, and express frustration when told there is no other option. Why is it necessary to stop the farm?
Think of a SharePoint farm as a living organism. It has a nervous system and a heart. The farm isn't viable if either of these components is interrupted.
The nervous system is a set of web services. All the servers in the farm are constantly chatting amongst themselves. What is the topic of the chatting? It is the farm health. The servers are constantly asking each other, "are you there and healthy?", or "do your registry settings match the configuration database, or has some human manually tried to adjust you?", or "can you respond to a search query?" These web services implement a self-healing, self-growing capability. For example, when you add a new web front end (WFE) to the farm, you don't have to manually add your custom features and solutions. The farm's nervous system recognizes that a new server has joined the farm organism, and automatically configures that WFE so it can function correctly in the farm community. If any server fails to respond appropriately to the web service nervous system conversations, because it does or does not have the same patches applied as the other servers in the farm, the farm organism could be thrown into disarray.
The heart of the farm is the configuration database, supported by the SSP databases and content databases. These databases maintain the farm state (configuration, customizations, pages, user profiles, content, etc.). The schema of these databases is tightly coupled to the configuration and content. Many hotfixes and patches must modify the database schema(s) to provide corrections and improvements. Because the databases are the heart of the farm, schema changes (open heart surgery) can only be performed by putting the patient to sleep when the changes are applied. Unfortunately, if the schema changes have to modify tables in the content databases, the result may be a long surgical procedure while thousands or even millions of rows of content data are updated.
Agreed, putting a farm to sleep for surgery is not ideal, but is necessary.
