I have roaming user profiles enabled on a Windows Server 2012 R2 domain with mainly Windows 7 Professional clients.

I've got a first-time login script which clears all Start Menu and Task Bar items, and re-populates with a few defaults.

Unfortunately - to support a piece of lab equipment - I had to downgrade one Windows 7 client from 64- to 32-bit. Naturally this broke the Start Menu and Task Bar pins which had been set under 64-bit Windows. When a user takes their roaming profile over to the 32-bit machine, all the pins which point to programs under C:\Program Files (x86) now no longer work.

As a workaround, on the 32-bit machine I created a folder junction C:\Program Files (x86) which points to C:\Program Files.

This means that all pins whose target resides in C:\Program Files on 32-bit, and in C:\Program Files (x86) on 64-bit, and which are created (by my first-time login script) on 64-bit machines work fine.

All pins, that is, except those which point to MS Office 2016 executables.

I note that, if I attempt to start, say, EXCEL.exe on the 32-bit machine from its normal install location (at C:\Program Files\Office16\root\EXCEL.exe), Excel launches normally. However, if I attempt to start it via my junction (that is, my "fake" program files directory, at C:\Program Files (x86)\Office16\root\EXCEL.exe), the Excel process starts, hangs for a little while, and then exits, returning no error message nor launching any GUI.

All my other programs play just fine with this workaround, but Office does not. Does anyone know why this is? And, if not, can anyone suggest an alternative workaround?

  • Can you just pin a x86/x64 aware .bat file with the Excel icon?
    – Ramhound
    Oct 30, 2015 at 16:24
  • That's a good suggestion, and would work for one-offs. But the problem extends to the entire Start Menu actually - a user's Start Menu follows them around, and one created under 64-bit will not work under 32-bit, simply because so many of the paths that point to Program Files now need to point to Program Files (x86).
    – pianoadam
    Oct 30, 2015 at 16:50
  • I assume you cannot change the workflow. What I mean by this is users search for "Excel" in the start menu and stop using the what is pinned and have Windows silently handle the difference between 32-bit and 64-bit versions of Office apps? The only thing you can do is have a script the updates the pins. An application isn't suppose to internally know the difference between "Program Files x86" and Program Files, provided its using the system variables, and not hardcoded paths. I am certain Office uses the system variables.
    – Ramhound
    Oct 30, 2015 at 16:58
  • Here is what I am talking about with regard to the system variables. An example that should work is something like %programfiles%//Folder\file.exe
    – Ramhound
    Oct 30, 2015 at 17:02
  • If I pin a shortcut with the target of "%programfiles%\Microsoft Office\Office14\Excel.exe" which starts in "%programfiles%\Microsoft Office\Office14\" the shortcut still works. This also means that if a 64-bit version of Windows were to install Excel it would start whichever version was installed. Since 64-bit and 32-bit of Office cannot exist on the same machine it should work. In my example I used Office 2010 by the way there is no difference in a case like this. You will have to get rid of your junction in order for this to work by the way.
    – Ramhound
    Oct 30, 2015 at 17:22


You must log in to answer this question.