SharePoint Server Updates for SP2010 aka Cumulative Updates–Should I apply them?
Since the release of SharePoint Server 2010 (RTM) in April 2010 the following Cumulative Updates have been released.
Current SharePoint Server updates - latest to oldest highlighted.
For most deployments which are operational these updates should (is recommended to) be applied on a regular cycle. To avoid any unforeseen “bugs” related with these (As quite a lot of people found out with the October CU breaking the UPS) what you can do is adopt a cycle of “3 months behind”. Which basically means that for any given update your production servers are updated three months after a given cumulative update. Since December 2008, cumulative updates are released on schedule every two months. This provides you with the flexibility to test the updates and also watch out for any known issues to be identified and fixed. For existing deployments always install the SharePoint Foundation build followed by the SharePoint Server Build. Or the other option is do nothing and wait for a major Service pack. However if you do encounter any issues and you call PSS you may be asked to apply the latest update. So it’s always a good idea to have tested the latest updates in a lab environment or in your test servers. This should be part of a operational management of your servers.
In the case of installing a brand new SharePoint server deployment it is a good idea to incorporate the latest update as part of the core installation. This can be done in a number of ways.
Which ever method you choose these updates provide enhancements and stability for SP2010 and you should look at deploying them and testing these as part of your operational management regime.
If you already have an existing SharePoint 2010 deployment there are some key improvements when applying the updates. In this example lab environment I have the following server farm with three servers. These are KCDEVVM01, KCDEVVM02 and KCDEVVM03 with SharePoint installed. I also have a separate VM with a DC. SQL server is running on KCDVVM01 to conserve resources in the lab (All of this running on a laptop). The lab farm mimics a standard deployment with one application server and two load balanced web servers. I am using Windows Network Load balancing in the lab. In this example I am skipping all previous updates and going straight to the December 2010 CU. Once the CU has been received the extracted files are “sharepointfoundation2010-kb2459125-fullfile-x64-glb.exe” and “office2010-kb2459257-fullfile-x64-glb.exe”. Copy the files to a shared location accessible by all three servers. You can find out the version of the update and your current farm version by going to the farm information page (Manage Servers on Farm Page).
Now in the real world before you apply a patch to production you will of course ensure that your SharePoint farm has been backed up and all operational processes have been identified and all relevant people are notified! In my case I am the only user of my lab so who cares .
The following TechNet articles provide guidance on approaches to take in order to update and upgrade your SharePoint servers to latest level. This is absolutely must read material before attempting an update and you should plan this out and test to ensure you understand the steps required.
Understanding Software Updates for SharePoint Server
Identifying the best Update approach (Decision tree)
Identifying the update version can be determined as follows. (This is listed on the KB Article page).
Highly recommend this following article which outlines all the details of what these updates are by Neil Hodgkinson and Sam Hassani > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=61dd9d08-d6f6-48af-8ab3-fae2924eb069&displaylang=en.
Basically the versions are read as: Major (14) Minor (0) Build (5130) Revision (5002). More details are in the above article which you should read.
As mentioned in my scenario I have 3 servers. And since two of my web servers are load balanced I can opt to rotate the update schedule by updating each of the front ends individually. In a large deployment where multiple web and application servers are used this method can be used to somewhat minimise the downtime. See the example(s) on TechNet at http://technet.microsoft.com/en-us/library/ff806338.aspx#usinginplace and http://technet.microsoft.com/en-us/library/ff806338.aspx#inplacewithbackcompatibility and using the database attach method http://technet.microsoft.com/en-us/library/ff806338.aspx#databaseattach
Or i could choose to stop all we requests by stopping all IIS services and taking the whole farm offline for the upgrade. In the sample I am just running the upgrade in place.
With SP2010 it’s possible to monitor the update progress and whether all your servers have the correct patch level from Central Administration. This means that you can install the update and keep the farm working until you are ready to run the upgrade process. This can be monitored on the servers on farm page in Central admin. In the below example I have installed only the SharePoint Foundation patch on the first server, therefore the status is “Upgrade Blocked”. You need to install both the updates on each server joined to the farm for the status to change. The farm is still operational and users can still access the sites at this stage. Also you can see that the other two servers don’t have the patch applied and the screen indicates this needs to be installed.
Next step is that we will install all both the required patches on all servers. Note that until all three servers have been installed with the update no upgrade tasks can be carried out. Another way of verifying the state of the farm is by navigating to the “Manage Patch Status Page”
The “Manage Patch Status” page provides detailed information for each installed components and the version number as well as if the required patches have been applied/installed or not.
Once all the required updates have been installed on all 3* (required) servers in the farm you should be able to see that the farm is ready for upgrade. The message is “Upgrade Required”. There is also an option to run STSADM (stsadm –o localupgradestatus) to check the upgrade status as well. In order to ensure that your content and service databases are also ready for update you can check the status by navigating to “Upgrade and Migration” and selecting “Review Database Status” The direct link is “http://caserver:xxxx/_admin/DatabaseStatus.aspx”. You’ll notice that on the actual page when you eventually get there it says “Manage Databases Upgrade Status”. The message you want to see is “Database is in compatibility range and upgrade is recommended” or “No action required”.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/249/5_UpgradeStatus_3CCF2919_55d1a031-d0b7-4685-b955-e2117af388ad_3CCF2919.png) ](https://www.chandima.net/Blog/Lists/Posts/Attachments/249/6_DatabaseStatus_6ABC7BD1_0a4e7b77-d18f-48d7-bc78-0c8cc9418524_6ABC7BD1.png)
Next step is to run the upgrade. This needs to be done on all servers of the farm. Usually you should start with the server that hosts the Central Administration service. This is also usually the server hosting most of Services and Service applications depending on your deployments topology. The main reason you would want to run the upgrade on this server is to be able to have access to a functioning CA. To monitor what’s happening I am using ULSViewer and also running a SQL Server trace against the db server. (just for fun).
Start the “SharePoint Products Configuration Wizard” which will prompt that the IIS Service, Admin Service and Timer Service “may” be reset. There really is no other choice of running the upgrade really so you have to say Yes here and continue by clicking Next.
The Upgrade sequence will kick in and if you want to see what’s going on open up ULS viewer and filter events by Category > ‘Upgrade’ and Event ID ‘fbv7’. Now in the case of the December update the infamous UPS (User Profile Synchronization Service) will refuse to play nicely and will not start up after upgrade. You simply need to restart the “User Profile Synchronization Service” once the upgrade fails. It will show that it failed and also say you have to start it manually. (And yes you will need to do a reboot to get it going – at least I had to in my lab but results may vary in your deployments)
Error message post upgrade.
Open the PSConfig log file and look for “ERR” and you’ll see that it’s the UPS. Close the Wizard and open CA. (You might need to do a IIS reset here manually to get CA up and running or worst case a reboot).
Also in CA you can look at the Upgrade Log file which is located in ~\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS or a directory specified by you.
Search for [ERROR] to look at specific errors and fix these. To resume an upgrade you need to run **psconfig –cmd upgrade –inplace b2b –wait –force **via a command window. Note – Don’t attempt to run upgrade on any other servers until you get the upgrade completed on the first server. You should see the “Upgrade Successful” message before going to other servers.
You can also view the Upgrade Status via Central Admin on the http://server[port]/_admin/UpgradeStatus.aspx Page.
Once you are in CA go to Services on Server Page and start the the infamous UPS (User Profile Synchronization Service. (You will might have to do another reboot if you are unlucky). Once UPS is up and running you should continue onto the other servers in the farm and run the Configuration Wizard on each server. Note that this is a December 2010 SP2010 CU issue so if you are reading this article for other updates you’ll need to review the specific KB articles relating to those and review your update strategy.
Once all servers are updated you’ll see that the version numbers have changed on services on server page.
So in summary – make sure that you have gone through the above at least a couple of times on a lab or in your test deployments. Choose your updates based on how your servers are deployed. The rule of thumb for CU is if it’s recommended then you probably should apply it. The following links are a summary of some of the resources that are available on TechNet.
Updates for SharePoint 2010 Products
Update Center for Office and Server Products