Sharepoint 2010 PSCONFIG Basic guidelines

  • Article

We have few questions and doubts related to the PSConfig guidelines for SharePoint 2010. Here are the below FAQs and answers.

1. Difference between PSConfig wizard and PSConfig command line:

A: Both are quite similar except for the part where there are fewer commands being run in the command line vis-à-vis the PSConfig UI. In the command line, you have the option to force the upgrade. Also, you have separate commands to perform separate functions which is of course not possible via UI. Refer https://technet.microsoft.com/en-us/library/cc263093.aspx for the available PSConfig command lines.

2. Is it mandatory to run PSConfig after a patch/security update has been installed in the SharePoint farm?

A: Yes, it is mandatory to run PSConfig (UI/Command line) after every patch/security update has been installed on the SharePoint servers. Most of the security patches may not have the mandatory to run PSConfig, but we recommend that you run the wizard or command line every time to ensure that the corresponding .dlls get updated as and when patches are released. When a patch gets installed on the server, only the file system level update takes place. When we run PSConfig, it updates the database as well as it is a necessary to have the database and the SharePoint servers in sync at all times. We will run into issues in the future if PSConfig has not been run as this will result in an unstable farm.

3. Is there a particular order in which the PSConfig has to be run?

A: Yes, we need to start with the server hosting the Central Administration (CA) site first and then move to the other servers in the farm. This order is required as we need to first upgrade/update the Config database which holds the entire farm configuration details. Although the binaries/patches can be run in any particular order, we recommend that you first begin with the server hosting Central Administration first and then move to the other servers in the farm.

IMPORTANT: Always ensure that you finish installing binaries/patches on all the SharePoint servers in the farm successfully and only then start the PSConfig (UI or Command line).

4. PSConfig wizard failed on the CA site hosted server. Shall I try to update the other servers and then re-visit the CA server?

A: No. Please ensure that the CA server gets upgraded first. We need to look into the PSCDiagnostics logs or the Upgrade.log (whichever is available) and fix the error on the CA server first. Then, we will need to move on to the others servers in the farm. Even if PSConfig were to fail on any 1 server in the farm, do not move ahead with the other servers without fixing the error on the failed server. This can result in other potential issues with the failed server.

TIP: You can go to the default location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Logs and check the upgrade.log or the PSCDiagnostics log file. In case you are unable to find the logs in the default location, you can go to Central Administration –> Monitoring –> Configure Diagnostic Logging –> Scroll down and in the “Trace log” section, the path will be specified.

5. Do we have to install the patches for both Microsoft SharePoint Foundation 2010 (MSF 2010) as well as Microsoft SharePoint Server 2010 (MSS 2010) like we used to for MOSS 2007?

A: No, it is not required to run both the patches. If you have MSS 2010, you need to run the patches only for MSS 2010 and then run PSConfig (UI/Command line) to complete the farm upgrade.

6. I have a lot of customization on my SharePoint 2010 farm. How do I ensure that I don’t lose the customization?

A: Whenever there is any patching to be done on the SharePoint farm, we need to first have the database backups and take backups of the Virtual directories (Inetpub folder) which has the web.config customizations. Also, if you have any customizations made on the OOB files, please take a backup of all the required files as PSConfig will re-write the OOB files to its original state. Note: Ideally, it is not recommended to modify the OOB files for just this reason. It is better to make a copy of the OOB file and modified the copy and not the original file.

You can refer https://msdn.microsoft.com/en-us/library/bb803457.aspx which although deals with MOSS 2007, but is also applicable for SharePoint 2010 regarding the supportability for modifying built-in files in SharePoint.

7. What are the preparations to be made before I start running the binaries and then run PSConfig on the SharePoint farm?

A: There are a few points to keep in mind before we start patching the SharePoint environment. Below are the key points:

  • Have backups taken of the databases – all the databases including Config and Admin content. Use the following references to take backups with the SharePoint inbuilt tools: https://technet.microsoft.com/en-us/library/ee428316.aspx 
  • You may also have 3rd party utilities to backup your data, however, we recommend that you also use the SharePoint tools listed in the above technet article to backup your data additionally. This helps in easy restore of data.
  • Take backups of your customization (custom features/solutions, inetpub folder, 14 Hive (14 folder where the files are stored). Refer https://technet.microsoft.com/en-us/library/ee748642.aspx for backing up customization.
  • Make sure that the backups you have taken have not failed for some reason before starting with the installation of patches.
  • Always test the patches first on a test/staging/dev environment before applying it in production directly. This will ensure that you are aware of any changes that might incur with your customization.
  • When ready to install the patches in the production, ensure that you have a long maintenance window (preferably during weekends or during holidays to reduce the user impact).
  • Make sure that you are using the service accounts to perform the patch updates so that you don’t run into any permission issues while running PSConfig (UI/Command line).
  • Turn off the WWW Publishing service on all the servers (disabled state in the services.msc) so that no user can access the site during the maintenance window.
  • Do not have any scheduled backups or crawls or any other jobs scheduled during the maintenance window. This can slower the upgrade process and also result in failures in accessing the databases during the upgrade process.

This sums up the very commonly asked questions. Enjoy patching and upgrading your SharePoint 2010 farm!!!