QuickPost – blank icons on Windows 10 desktop when using FSLogix to mask Office

Quick blog today, an oddity you may see using App Masking to hide Microsoft Office.

I noticed this problem pop up in World of EUC Slack (you’re not on World of EUC? Go and join immediately!) when Jen Sheerin said she was getting some odd-looking blank icons after using FSLogix to mask Microsoft Office. Masking Office isn’t something I commonly do, and I try to avoid it where possible – Jim Moyle has some excellent collateral on doing advanced app masking within Office and usually if Jim has to get involved in it I get the feeling it could be a potential minefield 🙂 But anyway, some people do it, so let’s have a look and see what was going on.

First, we ascertained that Jen was not imagining it, and there were some odd blank icons landing on the desktop every time a user logged in with a new profile 🙂

You can interact with these icons in that you can delete them, but can’t move them anywhere. If you drop to a command prompt, they appear to all intents and purposes to be invisible. They do, though, affect every single user that logs on with a fresh profile.

The App Masking rules had been generated using the FSLogix Rules Editor scanning wizard, so they were pretty much the expected defaults.

Naturally my first instinct was to blame Teams or Microsoft Edge. Both of these programs are generally a pain in the proverbials and insist on dropping shortcuts out to the desktop when a new user logs in. You can stop Teams and Edge depositing shortcuts by changing the following Registry keys

HKLM\Software\Wow643Node\Microsoft\Windows\CurrentVersion\Run – remove the TeamsMachineInstaller value

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer – set a DWORD value called DisableEdgeShortcutCreation to 1

Naturally, getting rid of these made no difference.

Next up we suspected Chrome, as Chrome usually drops a StubPath entry that deposits a desktop shortcut when a new user logs in. However, as you can probably guess, this was getting a bit “stab in the dark”, because the Office masking rules weren’t touching Chrome in any way. So this made no difference at all.

My next idea was to remove the FSLogix rules while the user was logged in and showing the blank icons. This made a bit of a difference – it revealed one of them as a folder with a name

Now we seemed to be warming up a bit – NameSpaces are often linked to the creation of shell folders, and OneNote is (very obviously) part of the Microsoft Office suite.

Digging through the Registry revealed a couple of keys that were of particular interest

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{0875DCB6-C686-4243-9432-ADCCF0B9F2D7}] 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{138508bc-1e03-49ea-9c8f-ea9e1d05d65d}] 

The first specifically mentions the “Microsoft OneNote Namespace Extension for Windows Desktop Search”, and the second was some form of MAPI extension that seemed to be tied to it. Crucially, though, neither of them appeared in the FSLogix App Masking Rules for Microsoft Office when they were generated via the wizard, so I added these manually

Once these are added to the App Masking Rules and copied to the Rules folder on the target Windows 10 device, when a new user logs in, you can see the desktop looks like it normally should.

So this appears to be a slight bug in the FSLogix wizard’s detection for Microsoft Office. It is leaving two Registry keys accessible that the user account tries to process at first logon, but obviously whatever it is trying to do then is blocked by the other rules and hence leaves the blank icons. Adding them manually to your configured Rules solves this straight away.