[Update: this article was updated on 15 April 2014. As information about the second scenario has changed from an Office build issue, to a Office Deployment Tool issue]

There are several reasons why your Office 365 Pro Plus might fail with the error, error code: 30088-27. However, in this article I point out one scenario which I believe could be common, and a second scenario, which is specific to early builds of the Office Deployment Tool.

First Common Scenario

This occurs when Office 365 Pro Plus is attempting to fetch updates. The process which fetches the updates, doesn't run as the user who is logged into the PC, it runs as “Local System”. If “Local System” cannot connect to the internet, you will receive this error. “Local System” might not be able to connect to the internet for a variety of reasons, but the most common appears to be when your company is using manual proxy settings in the web browser. When you configure manual proxy settings for your users, it doesn't effect the “Local System” account, rather Local System is always set to “Automatically detect settings”. Therefore if it cannot identify the proxy through “Automatically detect settings”, the update will fail as the updater process cannot connect to the internet. Interestingly, on earlier builds of Office 365 Pro Plus, you don't get an error, you just don't see Office ever update itself (even after turning update off, and back on again, as described here).

To prove if you are a victim of this issue, you can force Local System (and all winhttp applications) to use a proxy, by running the Netsh command. I don't believe the Netsh command is a long term solution, but rather helps you troubleshoot the issue. A long term solution is recommended later in this article.

Open the command prompt (run as administrator), and use the following command to import the manual proxy settings from IE:

netsh winhttp import proxy source=ie

Now rerun the update, and it should start work…well, it will work if you are a victim of the issue described above. To reset winhttp back, run the following command:

netsh winhttp reset proxy

2 other reasons why you might receive the same error code. 1 - It could be the Local System cannot authenticate to your web proxy. 2 - You might be updating from a local file share, and local system doesn't have rights to the local file.

Troubleshooting techniques that allowed us to find the route cause, that you might be interested in:

1. Use network monitor on the PC in question, and see what is happening under the hood. You should see Office reach out to a URL which looks something like this one; http://officecdn.microsoft.com/pr/39168D7E-077B-48E7-872C-B232C3E72675/Office/Data/v32.cab. The cab file contains the latest Office 365 Pro Plus version number, and the “Local System” account must be able to fetch this cab file. Using network monitor, you should be able to see if this is happening, if the request is hitting your proxy server, or trying to go via a direct route.

2. Enable version logging. This works for both installation and updates. These 2 articles are good references for verbose logging:

  1. http://support.microsoft.com/kb/2826852
  2. http://community.office365.com/en-us/blogs/office_365_community_blog/archive/2013/04/04/office-365-proplus-administrator-series-enabling-verbose-logging-for-troubleshooting-office-365-proplus-installations.aspx

Longer term solution:

The better long term solution for this, in my opinion, is that you rather want to use “automatically detect settings”, this is for both local system account, and also for users. This can be implemented with “not much effort”, by using WPAD with any existing web proxy solution. I am not an expert on WPAD, but here is a quick 101 on how it works.

Use a PAC / DAT file to hold the proxy configuration for the network. This is a text file, placed on a web server on your network, which holds configuration as to which proxy server(s) to use, for which end points. This allows you to specify which IPs / Host Names are internal, and gives greater flexibility than the manual settings you probably have today anyway. This file should be placed on a highly available web server, perhaps on your proxy server(s) is a good place.

Next, in your local DNS (or hosts file for testing), you register the name WPAD to point to the server(s) where the text file is located. That’s it. Now, any web browser which is configured to use “automaticly detect settings”, will fetch the proxy text file (http://wpad/wpad.dat) from the web server and work accordingly. This means, without changing any user’s PC settings, Office 365 Pro Plus will start working because local system account is set to automatic detect settings by default. You can then over time, change user’s manual settings to auto detect.

Second Scenario, specific to early build of the Office Deployment Tool

We (project team) found a specific issue, when you have deployed Office 365 Pro Plus, using an earlier build of the Office Deployment Tool. We found that specifically, build 15.0.4535.1503 of the Office Deployment Tool causes this issue. In this case, we found that a missing registry key was causing an issue that prevents Office 365 Pro Plus updating, and we would get the same error i.e. error code: 30088-27. The registry key in question, tells Office 365 Pro Plus where to go, to fetch updates. By manually adding the key, updating started to work (as long as you are not a victim of the “Local System” issue too).

What key?

You should have 1 of the following keys (just having one of them works, you don't need both).

  • HKLM\Software\Microsoft\Office\15.0\ClickToRun\Configuration\CDNBaseUrl
  • HKLM\Software\Microsoft\Office\15.0\ClickToRun\Configuration\updateurl

The value should be set to the path where updates are retrieved from. We copied ours from a value in the propertybag key. It will look something like this http://officecdn.microsoft.com/pr/39168D7E-077B-48E7-872C-B232C3E72675. Disclaimer: we haven't checked all deployments of Office Deployment Tool, so I am not sure if this value is the same for all users, countries, and versions of Office 365 Pro Plus, hence the suggestion to copy it from an existing key in your registry.

The image below shows this value:


Second Disclaimer: This has yet to be officially published as a bug by Microsoft, but is rather something that I found on a recent engagement with a customer. I accept no responsibility for your actions when editing the registry. Use this information to help identify the issue, and contact Microsoft support for guidance on how best to resolve it.