If your environment has Office 2010 installed and you install parts of or all of Office 2013, for example Lync 2013, you will not be able to open or create a new Office document from the SharePoint document library. You will get a blank page displayed instead and may see the following URL links:

ms-word:nft|u|http://o15psvr:8080/Shared Documents/Forms/template.dotx|s|http://o15psvr:8080/Shared Documents

Excel Files :  "ms-excel:ofv|u|http://sharePointDocumentlibraryURL"

This problem is related to the new Microsoft SharePoint Foundation Support for Office 2013. Office 2013 installs a new version that Office 2010 is not aware of. This causes a conflict and one of the Foundation Support tools needs to be removed. We generally recommend keeping the most recent SharePoint Foundation Support (2013) but if your environment has Office 2010 and Lync 2013, you will want to remove 2013 and keep the 2010 version.

To fix this issue, we need to do two things, we need to create an MSP file to remove the 2013 SharePoint Foundation Support, and then repair Office 2010.

Create a MSP file to remove SharePoint Foundation Support using the Office Customization Tool for Office 2013 (OCT):

1) Open the OCT tool for the Office version you wish to remove SharePoint Foundation services from. In this example it will be for Office 2013.

2) Path to “Set Feature installation state” on the left, expand Microsoft Office and expand Office tools.

3) Under “Microsoft SharePoint Foundation Support, click the drop down and set the sub tier Microsoft SharePoint Foundation Support to “Not Available, Hidden, and Locked” but keep Microsoft Web Access Datasheet Component turned on. You will see the letter “H” and “L” as well as a red “X” as shown in this example:

4) Save the MSP file and close the OCT

Running a Silent Repair of Office:

1) We will need access to Office source, so find your Office source files on the network.

2) Open the config.xml file located in the ProPlus.WW folder (If you are using a different SKU such as Office Standard, the config file will be located in the Standard.WW folder)

3) Change the first editable line in the config file to look like the following:

<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes />

4) Save and close the Config file.

After applying the MSP file to remove SharePoint Foundation Support, run the following to repair Office:

“\\my-server\my-Office-2010-source\setup.exe” /repair ProPlus /config “my-Office-2010-source \proplus.ww\config.xml”

Automating this fix across your environment:

If you need to automate this across your environment there are a few ways you achieve this. You could use SCCM and schedule tasks to push out the MSP file first, then run the repair of Office 2010, or you could use a batch file to do the same thing.

Here is an example batch file that can be used to first install the MSP file, then trigger the repair of Office. (Always test scripts before deploying)

=================================
@echo off

:RUN
%windir%\system32\msiexec.exe /p \\<path to msp file>\my-file.msp
goto REPAIR

:REPAIR
“\\my-server\my-share\setup.exe” /repair ProPlus /config “\\my-server\my-share\proplus.ww\config.xml”

:END

Exit

================================

There are other ways to achieve this fix, but the biggest takeaway is to run the MSP file that removes SharePoint Foundation Support from Office 2013 first, then run a repair of Office 2010.

The Click to Run Version of Office Pro Plus behaves differently than its MSI based counterpart. Tools like Microsoft Update and corresponding MSP files are not involved in software updates. Likewise, management tools like Windows Server Update Services (WSUS) and products controlling WSUS like System Center Configuration Manager 2012 are not distributing software updates to Click-to-Run software.

Instead, The software update process in Click-to-Run functions by first discovering what is already installed, examining the updates being delivered and only applying the differential files.

As far as managing these updates, we have three different options:

#1 – User machines receive automatic updates from Microsoft

#2 – User machines pull updates from an internal location controlled by the admin

#3 – Disable automatic updates

Let’s examine these options further:

#1 User machines receive automatic updates from Microsoft

This setting has the user machines receiving automatic updates monthly directly from Microsoft Servers. Each month, on Patch Tuesday the latest build of Office is made available. User machine’s Office update service runs as a scheduled task daily to check the Office 365 service, http://officecdn.microsoft.com/ for new updates. When the latest update is available, Office will schedule a time randomly over the next few days to download and install the update. When the update triggers, the client performs a delta comparison to determine which pieces have changed and then only retrieves the pieces that have been updated to reduce network traffic. The random scheduling is also done so not all users are downloading from the web at the same time. To enable this type of updates management, in the Configuration.xml file used for install, set the enable updates to true but do not add a specified path. This will default the path to the Office 365 service – http://officecdn.microsoft.com/

<Updates Enabled="TRUE" />

#2 – User machines pull updates from an internal location controlled by the admin

In this scenario, the updates are controlled by the admin. Each month a new build of Office is available to download via the Office Deployment Tool (ODT). Administrators will specify a network location for the client machines to receive their updates from. When the administrator is ready to push out an updated build, he or she will add that build package to the specified network location and the client machines will trigger a pull. The client machines will only pull the delta’s that have changed from the build currently on their machine to reduce bandwidth and like getting updates from Microsoft directly, each machines will pull the delta’s at a random time over a few days to minimize network traffic.

To enable this configuration, when deploying Office 365, remove the XML comment marks <!—and --> from the updates option in the configuration.xml. Then specify the location where the updated versions will be stored: (*NOTE – DO NOT name your updates location folder “Office.” This will create a problem as the BaseURL value in the registry will add an additional Office folder breaking the path.)

<Updates Enabled="TRUE" UpdatePath="\\My-server-name\Office-Share-location\New-Office-build-location" />

Much like setting automatic updates in scenario one, the Office update service will run daily as a scheduled task and once the administrator adds the latest build to this specified location, Office will install the new deltas.

In this model, the user will not see software updates being applied or forced to close applications – unless instructed to do so by the administrator distributing and automating the update. Updates are applied in the background and simply by normal use of closing and re-opening the Office program, updates are applied to Office.

#3 – Disable automatic updates

In this scenario, User machines will never look for updates via Microsoft CDN Servers or from internal network shares. If this method is used, upgrading the build of Office will require manual upgrading. To achieve this, first download the latest build of Office, or the version you wish to update to. Then add the full version number to the configuration.xml file as such:

<Add SourcePath=”\\server\share\odt\" Version=”15.0.xxxx.xxxx” OfficeClientEdition="32" >

Once this is added, make any other changes to the configuration.xml file you wish, then save it. Next run setup.exe /configure configuration.xml and Office will upgrade to the latest build.

Here is a link to the sustained Engineering blog with a list of all patches that are included in the most recent and past updates:

http://blogs.technet.com/b/office_sustained_engineering/

Here is a link to using the Office Deployment Tool for Click-to-Run:

http://blogs.technet.com/b/odsupport/archive/2013/06/19/using-the-office-deployment-tool.aspx

Here is a link that lists the version history for Office 2013 Click-to-Run:

http://support.microsoft.com/gp/office-2013-click-to-run