When running the Config Wizard for the SharePoint 2013 upgrade with My Sites deployed, you may run across an error similar to this which causes the upgrade to fail:

This is due to a new method called DoMySite_PersonalDocLicPermissionReset in the class Microsoft.SharePoint.Portal.UserProfiles.MySitePersonalSiteUpgrader.  This class looks for a Document Library named “Personal Documents”.  On pre-April 2013 CU, the lack of this library can cause the Cumulative Upgrade to fail with the above error.  There are two workarounds that I’ve identified:

A) Create a document library in the user’s My Site named “Personal Documents”

B) Delete the user’s My Site

While the April 2013 CU may be in this failed state, any My Sites created during this failed state do not suffer from the above error.

When running /extract against the April 2013 Cumulative Update, it takes… hours.  Using Process Monitor, it appears that the CU is going through the entire CU exe to identify and extract the files, in a one-by-one process.  For example, we’ll look at the extraction of two files, edumui-es-es.msp and edumui-et-ee.msp.

First, the extraction process finds edumui-es-es.msp and creates a file as well as begins the extraction:

Next, the extraction finishes, and the extraction process starts parsing the ubersrv2013 executable from the beginning again:

Next, the extraction process, using 8KB to ~32KB reads, finds edumui-et-ee.msp in the ubersrv2013 executable some ways into it (about 663MB):

Finally, edumui-et-ee.msp is extracted and the read process of the ubersrv2013 executable begins again:

Compare to the March 2013 PU, which goes through the ubersrv2013 executable and picks out files as required:

Okay, that was a misleading title.

As we know, with the SharePoint 2010 post-June 2012 Cumulative Updates, you can no longer slipstream them into the base media due to the post-June 2012 Cumulative Updates requiring Service Pack 1.

It appears that the SharePoint 2013 April 2013 Cumulative update will also encounter this issue due to the requirement to have the March Public Update installed for all updates moving forward.

Certain components of the April 2013 CU, for example, let’s take coreserver-x-none.  It updates the product 90150000-10F7-0000-1000-0000000FF1CE, otherwise known as the Microsoft Document Lifecycle Components.  The April 2013 CU requires that this particular product be at version 15.0.4481.1005 (March PU) prior to updating.  In order to update from 15.0.4481.1005, you obviously need to first install the March PU.  However, since the msp files have the same file names between the March PU and April CU, the April CU msp will overwrite the March PU and you’ll end up with the April CU finding that the farm has a version number of ​​15.0.4420.1017 (RTM).  Since the product version number does not match, the particular product is not updated from RTM to the April CU.

We see the same thing between the SharePoint 2010 June 2012 and August 2012 CUs.  Going back to the original example, the Microsoft Document Lifecycle Components in the June 2012 CU requires version 14.0.4763.1000 (RTM) or 14.0.6029.1000 (SP1).  And in the August 2012 CU, it requires just version 14.0.6029.1000 (SP1).

Some products in the SharePoint 2013 April 2013 CU only require their version be at RTM.  In the end, you’ll end up with a farm that has a mix of RTM and April CU which isn’t a good situation to be in.