Customer reports that sometimes Office was not running, and it was being blocked by AppLocker.

AppLocker has a number of internal variables that it uses to identify locations, like %PROGRAMFILES% refers to both "C:\Program Files" and "C:\Program Files (x86)", and %OSDRIVE% is "C:\".

In the AppLocker logs, you can see when programs are allowed to work or not. Ones identified as being in %PROGRAMFILES% work fine, but if AppLocker decides that the same exact executable is actually in "%OSDRIVE\Program Files", it gets blocked.

%OSDRIVE%\PROGRA~2\MIF5BA~1\OFFICE15\OUTLOOK.EXE was prevented from running.

%PROGRAMFILES%\MICROSOFT OFFICE\OFFICE15\OUTLOOK.EXE was allowed to run.

The only answer we could come up with was to expand the default AppLocker rules, adding these to support %OSDRIVE% as well.

%OSDRIVE%\PROGRA~2\*
%OSDRIVE%\PROGRA~1\*
%OSDRIVE%\PROGRAM FILES (X86)\*
%OSDRIVE%\PROGRAM FILES\*

It's weird that this seems to have something to do with NTFS short names, but we didn't find any better answer than just adding to the AppLocker rules.

Here's their original report:

<<
One of the default rules for AppLocker allows anything in %PROGRAMFILES%\* to run.
Now something about the unidesk layers causes windows to think the path is a bit different.
This seems to happen randomly for different apps and users.
For example user worked fine then they logged off and back on and they couldn't run Word or Excel, but Outlook ran fine.
>>