The perils of the SharePoint Cumulative Updates

There has always been trade-off when it comes to applying Cumulative Updates to your SharePoint Farm. You want to keep your Farm stable, secure and up-to-date, but there’s always the concern that an over-aggressive CU may cause some functionality issues for your end user. The recommended stance when it comes to CU’s is to only apply them to your Farm if there’s a compelling reason to do so – it fixes something!

Generally, SharePoint Service Packs are released by Microsoft having undergone a far more vigorous testing cycle in comparison to CU’s, and if there’s anyone out there still running SharePoint 2010 RTM and not SP1 I’d ask the question ‘why’?

Patching SharePoint is pretty simple; download the patch, apply it to every SharePoint Server in your Farm (excluding SQL or FAST), and then run PSConfig (starting with the Server(s) which are running Central Administration).

Despite this simplicity, I recently came across a SharePoint Farm where the build version wasn’t what I expected. The Farm had been manually patched to February 2012 CU but the build version was displaying April 2013 CU – the culprit, a SharePoint 2010 Foundation patch had been deployed, mistaken as a Windows Security patch. (http://support.microsoft.com/kb/2810059). PSConfig had also been run as the databases had been showing the ‘Upgrade is required’ warning, and this has caused the Farm build version to iterate.

Unfortunately there is no roll-back option with SharePoint patches and therefore the only valid approach was to install what was essentially a year’s worth of SharePoint Server patches to bring the Farm comprehensively up to April 2013 CU (http://support.microsoft.com/kb/2775353). And this is where the fun (actually pain) begun.

When I attempted to run the April 2013 CU SharePoint Server patch, I was stopped in my tracks by the following message:


SharePoint believed that the patches were already installed, so the way to circumvent this was to change the following registry value (on all the servers) to reflect the former build version (in this instance, Feb 2012 CU)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0

14.0.06117 (Feb CU 2012)


 

Then, if I pass a switch below to the patch updater executable, we bypass the version check which is causing the update to fail:

ubersrv2010-kb2767793-fullfile-x64-glb.exe PACKAGE.BYPASS.DETECTION.CHECK=1


 

 

 

RSS Viewer Web Part failing after installing KB2810059

I was recently troubleshooting against a SharePoint 2010 Farm where users were suddenly reporting that the RSS Web Part was not loading when it was active on a page which also had the Content Editor Web Part deployed. So, what’s changed?

I soon discovered that although the Farm had only been patched from a SharePoint Server perspective to February 2012 CU, the build number was reflecting 14.0.6137.5002 – which is April 2013 CU. Further investigation led to me discovering that a SharePoint Foundation patch (ttp://support.microsoft.com/kb/2810059) had been deployed by mistake as it was perceived to be a Windows Security patch. Subsequently, any SharePoint site which had Publishing turned on was failing to load the RSS Viewer when it shared a page with the CEWP.

Having consulted Microsoft about this issue, I was pleased to hear that this has been recognised as a bug…….although it won’t be fixed until either June 2013 CU, or Service Pack 2 – whichever is released first.

The suggested workaround was to either ‘Disable Web Page Security Validation’ at the Web App level (OK, it works, but it’s not recommended due to the security concern)

Or, apply the following Javascript:

)      Page Level: Adding a Content Web Part to the page that is having the problem, and using a custom script with it.

a)     Save the following JavaScript to a .txt file and upload the file to any document library in the root of the site. 

<Script Type=”text/javascript”> 

function CustomUpdateFormDigest() 



if(window._spPageContextInfo != null) 



var $v_2 = window._spPageContextInfo; 

var $v_3 = $v_2.webServerRelativeUrl; 

var $v_4 = window._spFormDigestRefreshInterval; 

UpdateFormDigest($v_3, $v_4); 





CustomUpdateFormDigest(); 

</Script>

b)    Add a “Content Editor” web part from “Media and Content” web parts category to the page not rendering web parts.

c)     Edit the “Content Editor” web part and link its content to the .txt file path we created and uploaded in Step 1 using the “Content Link” field.

d)    Hide the web part by checking “Hidden” under “Layout”.

e)     Save and publish the page.