Office 2013 error: “Sorry, we are having some temporary server issues” – fix it by clearing a key in the registry

Update 27/02/14: Microsoft have released Service Pack 1 for Office 2013, and still does not contain a fix for the below issue.

Recently we began using Office 365 accounts with the Office 2013 desktop suite, and during a roll-out session for staff, almost everyone in the room got this error message when trying to load the sign-in screen for their Office 365 account for the first time:

“Sorry, we are having some temporary server issues.”

The error occurred even before asking for any login details, and a quick check of our Internet access logs revealed that Word wasn’t even attempting to contact a server. I hadn’t seen this during testing, and we couldn’t work past the error when we encountered it, so the roll-out session was a bust. To say I was irritated is somewhat of an understatement.

After the session, I realised I had seen something very similar before, when a teacher reported about a month ago that a class full of pupils could not get get the Online Pictures button on the Insert ribbon to work. Lo and behold, the same thing was happening for the affected staff accounts:

“Sorry, we are having some temporary server issues. You can work offline if you plan to insert pictures from your computer.”

After a couple of hours in the office turning the air blue, I discovered 3 things:

1. These problems are related,
2. it’s not a server issue, and
3. it’s not bloody temporary.

I didn’t find much useful online when searching for this error message, other than a few people having trouble activating the Office 365 Click-to-Run apps, and no-one knew how to fix it. Originally I found that uninstalling some of the Office 2013 updates helped (KB2768349, KB2767861, and KB2760624), but this turned out to be only a temporary workaround.

The root cause

When the problem came back again, I found I could also get rid of the problem by deleting the user’s roaming profile from the server, at which point I could sign in to Office 365 on the first computer they used (i.e. the one on which their new roaming profile was created), but the same user would then fail as soon as they used a different computer (with the same roaming profile).

That led me to suspect that Word was storing something outside the user’s roaming profile that it was relying on finding again later, but couldn’t find on a different machine because, well, it wasn’t in the roaming profile. I ran Procmon and looked for Word making any direct references to the user’s local copy of their roaming profile on the C:\ drive. Something quickly stood out:

I’ve looked at enough process traces over the years to know a dead giveaway when I see one. A direct reference to office15.microsoft.com in the user’s local AppData directory (which doesn’t roam), in a location that was retrieved immediately beforehand from the registry (which does roam). The offending registry value was:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet\WebServiceCache\AllUsers\office15client.microsoft.com\config15--lcid=1033&syslcid=2057&uilcid=1033&build=15.0.4433&crev=1\FilePath

Which referenced the following file location:

C:\Users\teststaff\AppData\Local\Microsoft\Office\15.0\WebServiceCache\AllUsers\office15client.microsoft.com\config15--lcid=1033&syslcid=2057&uilcid=1033&build=15.0.4433&crev=10

Because this file doesn’t roam, it was missing from any logon other than on the first computer the account was used on.

The exact key name may differ on your system, since it contains references to the Office and system locale IDs (1033 for English US and 2057 for English UK) and also the current build version of the MSO.DLL installed on your system. That version changes with each cumulative update for Office that is released on Windows update. Basically, look at everything under the office15client.microsoft.com key.

What fixed it

Deleting the offending key from the registry immediately fixed the problem, but only on that computer. If the user then went to a third computer that didn’t have the correct file in the local AppData, the problem would come right back.

I toyed with the idea of simply clearing the entire HKCU\Software\Microsoft\Office\15.0\Common\Internet\WebServiceCache\AllUsers\office15client.microsoft.com key at logon, since there appeared to be no side effects to doing so (other than that Office would actually bloody work properly), but that seemed like a bit of a sledgehammer to crack a nut. After all, the cache must be there for a reason, so why reset it when it works?

Instead, I deployed the below logon script to all my roaming profile users via Group Policy. The script enumerates every entry under the office15client.microsoft.com key and checks to see if the on-disk cache file is present. If it is, it leaves it alone. If the file is missing, it removes the registry entry that refers to it.

Result? All users can now log on to any computer and use Office 365 successfully.

Const HKEY_CURRENT_USER = &H80000001

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Set oFS = CreateObject("Scripting.FileSystemObject")

'Location of Office 2013 Web Service Cache data
sCacheKeyPath = "Software\Microsoft\Office\15.0\Common\Internet\WebServiceCache\AllUsers\office15client.microsoft.com"
oReg.EnumKey HKEY_CURRENT_USER, sCacheKeyPath, arrsubKeys

'Check each cache
If IsArray(arrsubKeys) Then
	For Each subKey In arrsubKeys
		sServiceKeyPath = sCacheKeyPath & "\" & subKey
		sKeyPath = sServiceKeyPath & "\0"
		'Find where the on-disk cache data is supposed to be
		oReg.GetStringValue HKEY_CURRENT_USER, sKeyPath, "FilePath", sValue

		'If we got the location from the registry
		If Not IsNull(sValue) Then
			'Check it exists
			If Not oFS.FileExists(sValue) Then
				'Delete the cache location from the registry if the on-disk file is not there.
				oReg.DeleteKey HKEY_CURRENT_USER, sKeyPath
				oReg.DeleteKey HKEY_CURRENT_USER, sServiceKeyPath
			End If
		End If
	Next
End If

Note: There are other things that could cause this error message

As you may have gathered, this error message is pretty vague, and the problem outlined above with roaming profiles is not the only thing that can cause this error. Unfortunately, I don’t know how to fix any other cause of this error, so if you aren’t using roaming profiles the above may not work for you. The only other suggestion I’ve seen that works for other causes is to create the user profile entirely, which is pretty drastic.

Conclusion

At least in our case, the problem seems to be triggered by a roaming profile user who first uses Office 2013 on one computer, then logs onto a different computer that they have not used before. Then, instead of realising the cache file it is looking for is missing and recreating it, Office throws an utterly false and misleading error message.

How this bug made it into production is beyond me; I can only speculate that Microsoft’s new-found love for BYOD means they have simply stopped properly testing roaming profile scenarios, which means we can look forward to a lot more of these sorts of bugs in future. Hopefully at some point they’ll fix this one, but until then, enjoy the above script as a workaround.