SharePoint ULS Error Could Not Load Microsoft Office 16.0

SharePoint ULS Error Could Not Load Microsoft Office 16.0

These days with Office 365 there are several ways to move content to and from the cloud to your On Premises environment. Several vendors (my employer AvePoint Included) make it easy for users to copy, migrate or replicate between the environments using their tools. Normally information is being migrated to the cloud from On Premises or from other cloud environments, however several customers find that replicating content from the cloud to their local environments fit many workloads such as extranets or for data archival. So we have begin to see the shift of data from cloud environments back to on premises environments.

There remains one core problem though with bringing back data that was once housed in the cloud and that is that the fundamental versions of SharePoint are different. On premises the latest release of SharePoint has a major version 15.0 however the Office 365 environment is running the major version of 16.0. This issue is widely known within the Office 365 community especially when it comes to the release of new features to the Tenants. This issue manifests in content was once stored in Office 365 and is now on premises. Errors such as the one below will load which say that SharePoint is unable to find the version of SharePoint referenced by a page or webpart, since that version is still only in the cloud.  

We know now that SharePoint is looking for the Microsoft.Office.DocumentMangement assembly in the Global Assembly Cache specifically for version 16.0.0.0. What we also know is that there is not currently a way to move that assembly from the cloud to on premises, so we need to tell SharePoint to look for the version of SharePoint we have installed which is 15.0.0.0. From previous readings I have come across Assembly Version Redirection on MSDN which is used normally during upgrades to redirect requests for Assemblies from the older version to the newest version that has been installed. What is lucky is that this also supports bindings from new assemblies to old assemblies in addition to the old->new scenario. So we need to create a section then in our SharePoint web.config that has an assembly redirection for the Microsoft.Office.DocumentManagement Assembly which was referenced in the log above. So for each affected web application, an administrator would need to insert the following section into their web.config to remediate this issue.

There should already be existing DepedentAssembly sections in the Web.Config, so the administrator should be able to easily insert this section along with them. Once you save the web.config it will trigger an Application Pool recycling so modify it with care. This will need to be replicated on each Web Front End in the farm so plan your updates accordingly.

Leave a Reply

Your email address will not be published. Required fields are marked *