What are the PSConfig.exe -cmd upgrade risks?

Question

I am about to run the following command in production but I would like a solid understanding of what could break. We ran this command on QA environments, but we don't know if everything is in fact running, as far as we can tell it is, but I would like to know if there is a possibility that this could break things such as workflows, features or anything else.

Here is the command:

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent
-install -cmd installfeatures

According to documentation: There are actually 3 commands in one:

• psconfig.exe –cmd upgrade
• psconfig.exe –cmd applicationcontent

• psconfig.exe –cmd installfeatures

  1. Psconfig.exe -cmd upgrade => Perform SharePoint upgrade. This command is automatically executed when running the SharePoint Products configuration Wizard if SharePoint needs to be upgraded.

     • inplace b2b ==> If b2b is chosen, then an in-place build to build upgrade will be performed. The other option is v2v (version to version)

     • force ==> The SharePoint Products Configuration Wizard stops any currently running upgrade actions, and then restart upgrade.

  2. -cmd applicationcontent ==> Manages Shared application content

  3. -cmd installfeatures ==> registers the SharePoint features in the server farm that are located on this server.

We will take a full farm backup (using SharePoint 2010 backup feature) to backup/restore the farm in place in case there is something wrong. Is this the recommended approach?

According to one user the last time they did this on the farm the workflows were gone. Is there a possibility of this happening after this command is ran on all farm servers?

Thank You for reading.

Answer 1

When you install the executable for a Cumulative Update (CU), you have not actually upgraded your servers yet. The PSConfig.exe (Command Line), or the SharePoint Products Configuration Wizard (GUI), will need to be run to upgrade both the running binaries, and make any changes to the SharePoint database schemas provided in the CU.

In this case, you have the August 2012 CU updates in place, but the farm is technically not running at the August 2012 CU level until you either run the psconfig command, or use the GUI version in the SharePoint Products Configuration Wizard.

Creating a farm backup prior to finishing the update is a good idea, as this will give you an environment to roll-back to in case of issues.

On the positive side, these updates are published by Microsoft, and do include a level of testing. Having also waited this long, you will also have community reference for any issues that were encountered. On the negative side, CU's are not as tested as Service Packs, and so you should not rush out and install a CU right when it comes out, as they are occasionally known to introduce bug regressions. A good site to stay on top of issues found per CU is the following by Todd Klindt:

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=224

For example, here are known regressions with the August 2012 CU:

http://www.toddklindt.com/blog/Regressions/August2012CU.aspx

In summary, you should definitely apply a CU in a QA environment first, test your critical business functionality, take a backup of Production, then apply the CU once you have tested in QA and been reassured there are no major regressions.

I personally prefer to use the GUI-based SharePoint Products Configuration Wizard when updating a farm, as it has more built-in intelligence to know what actions to perform (more of a click Next, Next, Next experience), but you may prefer to use the command line tool. Also note that regardless of which option you choose, the process needs to be run on each server in the SharePoint farm.