One of my customers contacted me recently to ask about a challenge they had seen with Windows 10. After blocking untrusted fonts in Windows 10, they noticed that parts of the Office 365 portal were missing icons.
The issue is that Office 365 uses a font to display icons/glyphs (to improve the experience when scaling to adapt to different screen sizes). It appears some browsers are unable to display the embedded fonts when they are untrusted – including Internet Explorer according to one blog post that my colleague Gavin Morrison (@GavinMorrison) found – apparently Edge has no such issues (though I can think of many more issues that it does have…) – Chrome also seemed to work for me.
There’s some good information about blocking untrusted fonts on TechNet and this highlights that:
“Using Internet Explorer to look at websites that use embedded fonts. In this situation, the feature blocks the embedded font, causing the website to use a default font. However, not all fonts have all of the characters, so the website might render differently.”
So, that appears to be the issue. What’s the fix?
It seems there are two workarounds – one includes excluding processes from the font blocking (but it’s no good excluding a browser – as the most likely attack vector for a malicious font would be via a website!) and the other includes installing the problematic font to %windir%\Fonts.
Tracking down the Office 365 font
So, where do you get hold of the Office 365 font? I thought it should be part of the Office UI fabric but I couldn’t find it there, nor any reference to it in the Office developer documentation (there are some icons in the fabric – but they don’t seem to be the ones used for the Office 365 portal).
There is a site where you can select Office 365 glyphs and download a font file but I’m not sure that will address the issue with the Office 365 fonts being blocked in the portal, so some more detective work was required…
Stefan Bauer has posted quite a lot of information on the Office 365 fonts (there’s more in his “lab”) but it seems the CDN location Stefan highlights has changed. Thomas Daly found some new locations (and helpfully hosts a copy of the font on his site) but I wanted to signpost my customer to a Microsoft-provided source.
One of the locations that Thomas highlights is https://outlook.office365.com/owa/prem/16.0.772.13/resources/styles/fonts/office365icons.ttf but that results in an HTTP Error 404 now (not found). So I opened the Office 365 portal in my browser and started the Debugger. Then, I found the following line of code that gave me a clue:
<meta name="msapplication-TileImage" content="https://r1.res.office365.com/owa/prem/16.1630.11.2221454/resources/images/0/owa_browserpinnedtile.png"/>
I used that base location (up to and including the version number) with the tail end of the URI that Thomas had provided and was pleased to find that https://r1.res.office365.com/owa/prem/16.1630.11.2221454/resources/styles/fonts/office365icons.ttf got me to an installable TrueType font file for the Office 365 fonts on Windows.
I expect the location to change again as the version number is updated but the method of tracking down the file should be repeatable.
Testing my theory
Testing on one of my PCs with HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\MitigationOptions set to 0x1000000000000 resulted in Internet Explorer loading the Office 365 portal without icons and Event ID 260 recorded in the Microsoft-Windows-Win32k/Operational log:
C:\Program Files (x86)\Internet Explorer\iexplore.exe attempted loading a font that is restricted by font loading policy.
After installing the Office 365 icons font (office365icons.ttf) and refreshing the page, I was able to view the icons:
Uninstalling the font locally and refreshing once more took me back to missing icons.
I then tidied up by setting the MitigationOptions registry key to 0x2000000000000 and restarting the PC, before removing the registry entry completely.