My standing recommendation to all my clients is as follows:
- Do NOT install any CU until it's been in the wild for at least a month. There has been many retractions and re-publishings of CUs over the course of history and unfortunately, Microsoft's track records with CU regressions is not stellar. The last thing you need to to install a CU that breaks your production environment. By waiting a month, any obvious issues with the CU would become known before you apply it to your environment.
- Install the target patch or CU into DEV first. Let it simmer in this environment for 2 weeks. Ensure that you have the ability to roll back the CU through VM snapshots. Since most DEV environments are virtual these days, this isn't really a problem. If ANY issue is reported by developers in the DEV environment, investigate it and do NOT proceed to step 3 until you're sure the problem was not caused by the CU. If the CU is the cause of the problem, simply roll back to your previous snapshot. Be sure this policy is well published and communicated, especially within your developer community as developers would lose any code that resided on the DEV farm without being checked into source control, when you conduct the rollback. But that never happens, right? Developers always check their code into source control, right? ;-)
- Once the CU passed the DEV test, it's time to move it to your QA environment for validation against what should be in PROD. Again, the assumption here is that your QA environment is a true representation of the PROD environment. If the CU breaks anything in QA, simply stop the process and do NOT proceed to step 4. As with step 2 above, if your QA environment is also virtual (most are these days) then you can simply roll it back as well when problems are encountered. Leave the CU in the QA environment for at least 2 weeks to simmer before advancing to step 4.
- Finally deploy the CU to your PROD environment. Since there is no uninstall for CUs, and given that a lot of PROD SQL Servers are still physical, once you get to this point, there's no going back. If some regression issues are discovered after you've installed to PROD, you're at the mercy of Microsoft releasing a patch to resolve the issue. It is best to open a support ticket as soon as possible to help them determine how widespread and serious the regression is.
Now in each of the install steps above, you'll sometimes find that running PSConfig.exe or the Configuration Wizard after completing the CU/Patch installation, would fail or get stuck. This leaves you in no man's land and has to be resolved in order to complete the installation/upgrade.
NOTE: A CU/PATCH INSTALLATION IS NOT COMPLETE UNLESS YOU HAVE A SUCCESSFUL RUN OF PSCONFIG ALL ALL YOUR SERVERS IN TURN!!!
When this happens, you can manually run PSConfig to force the completion as follows:
- Run the SharePoint Management Shell as admin. (Right click icon, Run as Administrator)
- There should be a path to BIN already defined in the management shell, but if you get a command not found error when you enter PSConfig, you could manually change directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\BIN
- Execute psconfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
If PSConfig fails on step 9 or 10, proceed as follows:
- Edit C:\ProgramData\Microsoft\SharePoint\Config\GUID\cache.ini
- Reset value to 1
- From the SharePoint Management Shell, execute stsadm -o execadmsvcjobs
- From the SharePoint Management Shell, execute psconfig.exe -cmd upgrade -inplace b2b -wait -force
This should complete your update successfully.
REMEMBER THAT YOU HAVE TO DO THE ABOVE PSCONFIG FOR EACH AND EVERY SERVER IN YOUR SHAREPOINT FARM. START WITH THE CENTRAL ADMIN SERVER AND THEN PROCEED WITH EACH SERVER IN TURN ONCE THE PREVIOUS SERVER COMPLETED.
It is said that you don't HAVE to run PSConfig in a single threaded fashion as stated above, but from personal experience, whenever I've had issues with CU installations, it was because PSConfig was run concurrently on multiple servers in the farm, but I'd recommend you let your own personal experience be the judge.