Problem: How do you keep a farm up to date but stable whereby patch don’t cause problems to your users or applications in a SharePoint 2010 farm.
Initial Hypothesis: Various software parts are in the SharePoint farm excluding 3rd party add-ins. Windows 2008 R2 gets patch, Cumulative updates and service packs. The 3 products to upgrade from Microsoft are:
• Windows;
• SQL Server; and
• SharePoint 2010.
Microsoft provides 3 mechanisms for patching:
1. Windows Updates are configured to pull down the updates and then prompt or install the updates automatically.
2. Manual Patching by downloading and executing the patch as directed by Microsoft.
3. Windows Server Update Services (WSUS) where a central server pulls all the patches and pushes the patches to the servers.
Resolution: Let patches unless marked as critical from Microsoft be release for a few weeks (4-8 is a good number for me) before implementing them. Roll out to test on a Monday, roll-out the patches on Wednesday and Friday night role out the patches to production.
Patch Windows, SQL & SharePoint regularly.
Windows 2008 must patch the servers on a weekly basis using the WSUS approach in a staggered phased approach as described above and currently done. Also ensure IIS application applicable patches are installed.
SQL patching should be done manually unless there are multiple instances which is only the case in the largest of farms. This should be setup manually but rolled out using WSUS.
SharePoint Patching should not be auto scheduled for deployment. An administrator/Infrastructure should periodically decide on a patch level and apply it via the WSUS service. This can be done manually but as it takes time to perform on each server and as the environment grows this can take time. We also need to watch out for running the configuration as this can take time on big content databases. Also this can be staggered so we install the patch but the content databases are staggered as to when they are updated with the new schema.
Note: An automatic update will install the binary files on the farm servers, but you must complete the software update by running the upgrade on the servers. Technet (http://technet.microsoft.com/library/ff806329(office.14).aspx)
Problem: Updating SharePoint 2010 using Cumulative Updates (CU) ensures your farm has bugs and the latest known security vulnerabilities are closed to attack. Update too early after the patch is release and you risk causing a major disruption to your farm.
Initial Hypothesis: Patches need to be implemented to ensure the farm is secure, stable and as performant as possible. I recommend letting new patches wait for 4 weeks to ensure the major bugs are discovered and potentially corrected by Microsoft.
Since the August 2011 Cumulative Update, Microsoft releases a single package that covers all the SharePoint versions (Foundation, Server), only the applicable patches (.msp files) parts that are needed on your farm are installed. You can still download the CU as a smaller package if you select the Foundation CU. The Cumulative Update contains all hotfixes since SharePoint 2010 was released.
Note that the SharePoint Server 2010 CU contains the SharePoint Foundation CU also, since the August 2011 Microsoft has taken this approach so you only need to install the CU that matches your edition. You no longer need to install the foundation and then the Server edition.
It is recommended that SP1 be installed before the CU however, if you don’t it will include the SP1 fixes. “Software updates include any update, update rollup, service pack, feature pack, critical update, security update, or hotfix”, Technet (http://technet.microsoft.com/en-us/sharepoint/ff800847).
Resolution: Plan (learn), backup (prepare), test, implement and verify (validate) is the basic testing plan suggested by Microsoft.
Deploying updates in a SharePoint Server 2010 environment consists of: downloading the binaries, installing (also referred to as updating) and upgrading by running the configuration wizard (not always). Ensure all servers in the farm (excluding the database servers) have been patched/updated before upgrading (running the configuration wizard (psconfig)).
Validate the CU upgrade:
PS>(get-spfarm).buildversion
Check if psconfig needs to be run:
PS> (get-spserver $env:computername).NeedsUpgrade
if True then
psconfig.exe -cmd upgrade -inplace b2b -force
Ensure the version is the version you are expecting after the patch.
Example of SP2010 SP1 with August 2012 CU:
Major Minor Build Revision
----- ----- ----- --------
14 0 6126 5000
CA > Upgrade and Migration > Check upgrade status
Update 17/03/2014: SharePoint 2013 with SP1 applied results in 15.0.4569.1000
More Info:
http://blogs.technet.com/b/stefan_gossner/archive/2011/12/14/december-2011-cu-for-sharepoint-2010-has-been-released.aspx
http://technet.microsoft.com/en-us/sharepoint/ff800847
December 2011 CU for SharePoint 2010 - http://support.microsoft.com/kb/2597014
http://technet.microsoft.com/library/ff806329(office.14).aspx
List of SP CU downloads and their build numbers.
PSConfig switches explained by Benjamin Athawes
Example from Benjamin Athawes
Upgrading product version (Major e.g. MOSS 2007 to SP2010 or SP2013 upgrades):
psconfig.exe -cmd upgrade -inplace v2v -wait
Applying a patch (minor e.g. CU or Service Pack):
psconfig.exe -cmd upgrade -inplace b2b -wait
Initial Hypothesis: Various software parts are in the SharePoint farm excluding 3rd party add-ins. Windows 2008 R2 gets patch, Cumulative updates and service packs. The 3 products to upgrade from Microsoft are:
• Windows;
• SQL Server; and
• SharePoint 2010.
Microsoft provides 3 mechanisms for patching:
1. Windows Updates are configured to pull down the updates and then prompt or install the updates automatically.
2. Manual Patching by downloading and executing the patch as directed by Microsoft.
3. Windows Server Update Services (WSUS) where a central server pulls all the patches and pushes the patches to the servers.
Resolution: Let patches unless marked as critical from Microsoft be release for a few weeks (4-8 is a good number for me) before implementing them. Roll out to test on a Monday, roll-out the patches on Wednesday and Friday night role out the patches to production.
Patch Windows, SQL & SharePoint regularly.
Windows 2008 must patch the servers on a weekly basis using the WSUS approach in a staggered phased approach as described above and currently done. Also ensure IIS application applicable patches are installed.
SQL patching should be done manually unless there are multiple instances which is only the case in the largest of farms. This should be setup manually but rolled out using WSUS.
SharePoint Patching should not be auto scheduled for deployment. An administrator/Infrastructure should periodically decide on a patch level and apply it via the WSUS service. This can be done manually but as it takes time to perform on each server and as the environment grows this can take time. We also need to watch out for running the configuration as this can take time on big content databases. Also this can be staggered so we install the patch but the content databases are staggered as to when they are updated with the new schema.
Note: An automatic update will install the binary files on the farm servers, but you must complete the software update by running the upgrade on the servers. Technet (http://technet.microsoft.com/library/ff806329(office.14).aspx)
Problem: Updating SharePoint 2010 using Cumulative Updates (CU) ensures your farm has bugs and the latest known security vulnerabilities are closed to attack. Update too early after the patch is release and you risk causing a major disruption to your farm.
Initial Hypothesis: Patches need to be implemented to ensure the farm is secure, stable and as performant as possible. I recommend letting new patches wait for 4 weeks to ensure the major bugs are discovered and potentially corrected by Microsoft.
Since the August 2011 Cumulative Update, Microsoft releases a single package that covers all the SharePoint versions (Foundation, Server), only the applicable patches (.msp files) parts that are needed on your farm are installed. You can still download the CU as a smaller package if you select the Foundation CU. The Cumulative Update contains all hotfixes since SharePoint 2010 was released.
Note that the SharePoint Server 2010 CU contains the SharePoint Foundation CU also, since the August 2011 Microsoft has taken this approach so you only need to install the CU that matches your edition. You no longer need to install the foundation and then the Server edition.
It is recommended that SP1 be installed before the CU however, if you don’t it will include the SP1 fixes. “Software updates include any update, update rollup, service pack, feature pack, critical update, security update, or hotfix”, Technet (http://technet.microsoft.com/en-us/sharepoint/ff800847).
Resolution: Plan (learn), backup (prepare), test, implement and verify (validate) is the basic testing plan suggested by Microsoft.
Deploying updates in a SharePoint Server 2010 environment consists of: downloading the binaries, installing (also referred to as updating) and upgrading by running the configuration wizard (not always). Ensure all servers in the farm (excluding the database servers) have been patched/updated before upgrading (running the configuration wizard (psconfig)).
Validate the CU upgrade:
PS>(get-spfarm).buildversion
Check if psconfig needs to be run:
PS> (get-spserver $env:computername).NeedsUpgrade
if True then
psconfig.exe -cmd upgrade -inplace b2b -force
Ensure the version is the version you are expecting after the patch.
Example of SP2010 SP1 with August 2012 CU:
Major Minor Build Revision
----- ----- ----- --------
14 0 6126 5000
CA > Upgrade and Migration > Check upgrade status
Update 17/03/2014: SharePoint 2013 with SP1 applied results in 15.0.4569.1000
More Info:
http://blogs.technet.com/b/stefan_gossner/archive/2011/12/14/december-2011-cu-for-sharepoint-2010-has-been-released.aspx
http://technet.microsoft.com/en-us/sharepoint/ff800847
December 2011 CU for SharePoint 2010 - http://support.microsoft.com/kb/2597014
http://technet.microsoft.com/library/ff806329(office.14).aspx
List of SP CU downloads and their build numbers.
PSConfig switches explained by Benjamin Athawes
Example from Benjamin Athawes
Upgrading product version (Major e.g. MOSS 2007 to SP2010 or SP2013 upgrades):
psconfig.exe -cmd upgrade -inplace v2v -wait
Applying a patch (minor e.g. CU or Service Pack):
psconfig.exe -cmd upgrade -inplace b2b -wait
0 comments:
Post a Comment