Important SharePoint 2013 Patching Script Changes


 

Intro and Issue

I want to get a quick update out to my subscribers that currently use the SharePoint 2013 patching script I created back in 2013.  The script itself is located here.  While the script has been highly successful for thousands of SharePoint Admin’s, Consultants, and others, the script will always report success even if the patch fails during the install phase.  This usually isn’t a problem because we produce quality updates that don’t have issues during install.  However, in some rare instances we’ve recently observed patches that run for a long duration and unexpectedly fail halfway through installation.  In this case, the script indicates that the patch installed successfully when it didn’t.    

 

Cause

This occurs because the patching script uses the /passive switch during install.  The passive switch hides the normal UI which would appear if one were to manually double click on the file.  The original thought was to use the /passive switch making the script more efficient by limiting the manually clicks that come up with the standard installation approach. Also, it would prevent the possibility of accidently clicking cancel during the installation.  It was more about trying to achieve a seamless experience.  The problem is the /passive switch doesn’t expose errors and that’s the downfall of using this switch.  

 

Resolution

The fastest resolution was to update the script on my blog and remove the /passive switch when executing the patch.   This will cause the user running the patch to agree to the Eula and click next but the patch should start immediately.  You should keep both the script and the patch UI running together.  Now when running the script, the executable will launch with the Eula where you agree and click Continue. 

 

image

 

Leave both windows open and now if an error occurs during installation, it will pop up on the screen.  At some later date, I may add error checking but for now I highly recommend replacing the old version of the script to the latest version before applying further updates.   The script is available here and thanks to my colleagues in Germany, Nicolas and Stefan, for bringing this to my attention.

 

Thanks,

Russ Maxwell, MSFT


Comments (1)

  1. Bradley says:

    Hi, this may not be a script issue but I used with the September CU 2015 and I clicked the 'restart now' on the first, Central Admin SPWFE server I patched and had various issues with disabled Windows SP services and non-functioning site (500 internal error). Restarted the services and rebooted a couple of times, still no joy.

    I re-ran the script on the same machine, it reported that it did not need it, and then I selected 'No' and restarted manually. All came back to normal.

    My question/wonder was whether or not the reboot beat the script to the finish. Anyways, all good.

    Thank you!

Skip to main content