Google Chrome and Office Servers - the continuing saga

Following along from the showModalDialog fiasco that still affects Outlook Web App (OWA) and the Exchange Administration Center (EAC) in Exchange 2013, Exchange 2010, and Office 365 as well as Microsoft Dynamics CRM, another example of how Google Chrome doesn’t quite play nice with Microsoft Office applications is in the inability of the 64-bit version of the browser to handle Lync meeting URLs correctly.

I first noticed this problem after upgrading to the newly released 64-bit version of Chrome in early September.  At that time, I thought the issue was due to teething problems or something to do with the fact that I had run the development (“Canary”) version of 64-bit Chrome on the PC for a while beforehand. The workaround was simple: past the URL into IE and all was well.

Now I’m not so sure that matters might be as simple as I imagined. I was frustrated by several Lync problems on Tuesday. Lync Online was up and down like nobody’s business and connection drops had interfered with several meetings. I got past that and then wondered why the URL issue still lingered a month after Google had released the 64-bit version. After all, Chrome is updated in the background on a very frequent basis and I imagined (in my nativity) that this would have solved everything.

So I tweeted some frustration (is that a proper sentence?) and received a reply that this was a known issue documented in the Chrome “Issues” forum. Bizarrely, the bug (for that is what it is), was first documented on February 10, 2014 and nothing has been done to solve the problem.

A Google engineer replied on February 11 to say that Microsoft needed to provide an updated plug-in for Lync. A reply on March 5 provided a response from Lync Support to say that they felt the problem was with Chrome. I think that this is more likely because a) Chrome 32-bit works fine and b) IE 64-bit works fine too. I have not tried other browsers as life is too short to pursue every bug that needs to be squashed.

The saga continues with a recommendation to update the registry settings so that the browser can find the right Lync code to load. All the settings were in place anyway so that tip doesn’t work at all for me (Windows 8.1 Professional) nor did it for other readers.

Next, the recommendation is to load Firefox onto your PC. These seemed enough for at least one person but others recommended that you copy npMeetingJoinPluginOC.dll to the Chrome plugin folder. I love the prospect of copying modules around until things work out.

The bottom line appears to be that Google has made yet another change in the Chrome browser that affects the ability of Microsoft users to work as smoothly as they did before the update. I realize that all the people in Mountain View would never feel the need to test their code against common Microsoft Office applications, but geez…

And Microsoft doesn’t come out of this too well either. Surely someone in Lync Support raised a flag last March to say that a problem had appeared with the 64-bit version of Chrome? Or maybe not on the basis that the bug was clearly in Chrome and the nice Google people would fix it. But it would have been nice had someone checked the released version of Chrome 64-bit, just to make sure.

After all, Microsoft’s formal statement on browser support for Office 365 says:

“Office 365 is designed to work with the current or immediately previous version of Firefox, or the latest version of Chrome or Safari.”

Well, I hate to break the news but the design fails at present as even my newly updated Chrome (version 38.0.2125.101) continues to have problems with Outlook Web App, the Exchange Administration Center, and Lync - and I guess with Microsoft Dynamics CRM as well. Not much has happened to improve matters since the showModalDialog problem emerged in September (at least a registry hack exists to keep things running until May 2015) and the Lync issue appears to be even older.

Oh well, I guess we should all be using IE anyway.

Update: Some people are reporting issues with the OWA calendar with Exchange 2010 and Exchange 2013 after Chrome 38 and other beta builds (for 39, etc.) were installed. I couldn't reproduce the issue but there are lots of reports. No smoke without fire and all that. More details can be found in this problem report. 

Update 2: If you attempt to use OWA to view message details in Chrome, you see a simple message box first and then, after a short delay, the message header information is revealed. Bizarrely, this sequence appears for the first time that you attempt to look at a message header in a session and works OK afterwards. Everything works as expected with IE on both on-premises and Exchange Online.

Follow Tony @12Knocksinna