Solving Office 365 \ Office 2013 proxy sign in errors

During the we summer completed our Office 2013 upgrade cycle (installed on our base image for all machines) to match up with Office 365 accounts being created for all staff and students.

With email fully migrated and SharePoint rolling out (more on that another time!) we started to notice the finer points of integrating desktop and cloud.

This gets particularly “interesting” when a proxy server gets involved, which we (like many) organisations use for content filtering before hitting the web. Microsoft’s official line is not to use one where possible; however the requirement for domain-based firewall rules don’t make this easy so we needed to solve any proxy related issues as they appeared.

One of the benefits of using Office 2013 is native integration with OneDrive, ideal for helping smooth the migration from traditional “My Documents” locations to the potential of seemingly unlimited storage in the cloud. However we soon noticed a bit of a problem, domained machines connecting via the proxy wouldn’t sign in 😦

We knew the issue was related to the proxy configuration as the same process worked fine on any machines with a direct connection to the internet. Armed with a couple of VMs the investigation begins…

Auto vs manual configuration

We’d already had to make alternations to our proxy setup before in order to fix Outlook autodiscover issues at the start of our email migration project so the finger of blame was soon pointing in a similar direction.

The usual URLs had already been added to the proxy bypass authentication list previously so it seemed that the problem didn’t lie there.

In order to fix the previous problems (caused by a known Outlook bug) we had to move from manual proxy settings to using Auto Detect with a wpad.dat file. Therefore the next step was to try doing the polar opposite and set it to manual instead, which worked successfully. That would be the end of the story but as mentioned above we need auto configuration for Outlook so more detailed investigation was required to find a fix that worked with the auto detect proxy method.

Tool of the day – winhttp trace logs

So now we knew one way of making the connection work and one way to make it break there needed to be a way to compare the traffic in each case to spot the difference. Proxy server logs were no use in this case as the traffic didn’t get that far, next stop was TCPView. Running it in each scenario showed a successful proxy connection with manual settings (as expected) but on auto the sign-in seemed to be trying to go out directly and therefore failed.

At this point I wanted to find out if I could get a more detailed traffic log and found an old Server 2003 Resource Kit tool called WinHttpTraceCfg that looked just what I needed. Initially I downloaded and ran it but later found the utility is actually integrated into Windows 7 natively as part of the netsh command. The examples below use the native tool:

Ref: http://blogs.msdn.com/b/jpsanders/archive/2009/05/28/how-to-enable-winhttp-tracing-on-vista-2008-and-windows-7.aspx

I enabled logging to a folder on the currently logged in user’s desktop using the command below. Note it’s worth setting the trace file size to a large number (50MB in the example below) as it soon fills up and I wanted the full connection history without anything being overwritten.

netsh winhttp set tracing trace-file-prefix="%userprofile%\desktop\trace\log" level=verbose format=hex state=enabled max-trace-file-size=52428800

The command creates a log file for each program that uses the winhttp proxy and gives a (very) detailed view of everything that goes on during the sign in process. I then ran through the login process under each proxy configuration and soon spotted the difference.

Office 365 federation check URL

The trace file generated When using the manual proxy configuration carried on for a lot longer than it’s failed automatic counterpart; comparing the two showed this line to be significant:

12:51:12.266 ::WinHttpCrackUrl("https://odc.officeapps.live.com/odc/emailhrd/getfederationprovider?domain=havering-college.ac.uk", 0x0, 0x0, 0xb5ead0)

It seems that Office automatically checks if the Office 365 domain is federated as you sign in your account, which makes sense given that it will automatically show OneDrive for Business and SharePoint options if your AD and O365 are hooked up via ADFS (or similar). Trying the URL manually in a browser resulted in a failed connection on the auto proxy, clearly pointing to it as a culprit.

Explicit WPAD rules

Previously we’d had to add some specific entries to our WPAD file to modify the behaviour of traffic for Outlook auto detect so I thought I’d try a similar trick again. In theory we shouldn’t need this rule as the last line of the file includes a final catch-all to route all other traffic not matching any previous instructions to go to the proxy, however something wasn’t behaving as it should so making the rule explicit removes all doubt.

My addition was a simple domain-based check:

 /* Send Office 2013 login via proxy here*/
if (shExpMatch(url, "*odc.officeapps.live.com*"))
{ return "PROXY A.B.C.D:8080";}

where A.B.C.D is the IP address of the proxy server required

With that in place I rebooted the machine to make sure the change to WPAD was detected, fired up Word and was able to log in with my Office 365 account first time. Removing the entry reverted to the previous behaviour, proving the fix.

Another interesting observation was that the odc.officeapps.live.com domain was already in our bypass proxy authentication list but in this case it didn’t seem to make any difference as the data wasn’t even getting that far. Why WPAD is acting strangely is still unknown but fortunately the workaround has proved a consistent fix thus far.

Blank login screen

When we first pushed out Office 2013 I wanted to avoid any confusion for staff by removing any references to the consumer OneDrive in case personal user accounts became tangled up and started messing with default save locations. The GPO for this sets a registry key:

Ref: http://technet.microsoft.com/en-us/library/jj715259%28v=office.15%29.aspx

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\SignIn

After SP1 is installed on a machine it seems the initial sign-in screen changes and seems to use some elements of the consumer service to figure out where an account belongs because if the proxy issue above stands and you have Microsoft Accounts disabled you get this very helpful blank screen:

no error is good error?

For reference here’s how the initial login screen looked pre-SP1 and the newer equivalent that came in after the updates. It seems the first part of the process determines what side of the consumer \ professional fence the account in question is part of then the second stage is the actual authentication (which then fails with the screenshot at the top of this post).

   
original sign in screen (left) vs SP1 sign in screen (right)

Federation

We’ve recently federated our Active Directory domain with Office 365 to give users single sign-on functionality for our new SharePoint-based Staff Intranet. In this scenario Office programs automatically detect the presence of a federated account (which explains the URL found previously) and offers up the appropriate services.

If auto proxy detection is on but the explicit entry isn’t in WPAD the federation attempt doesn’t work and you’ll just see the standard manual “Add a Place” options. If you try to add any Office 365 services you’ll (unsurprisingly) fail until you either switch to manual proxy or use the workaround above.