How to start PowerShell in WiX with proper access to Windows Registry?

Oh... my... god...

Ok I finally got it working. There were actually several problems and the solutions for these problems were actually in bits and pieces of information that I gather from across multiple SO questions.

To recap, here is what I was trying to do:

1. Launch a powershell from WiX to run my install script.
2. My script search Windows Registry (requires 64bit) for installed Exchange Server's location
3. My script loads the Exchange Management Shell (EMS) script (requires 64bit AND proper user) from the install location
4. Under the EMS session, my script run a brunch of other scripts to register an Exchange plugin

Problem 1)

No matter what I did, the WiX installer always launches my powershell in 32bit, this is regardless of setting Platform="x64", Win64="yes", and even WixQuietExec64. I even built the installer in Visual Studio as x64 and everything else as x64.

The solution is to directly reference the sysnative powershell, it has to be sysnative in the SetProperty.

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe

I actually did tried this before, and thought it wasn't working, but the root cause was being masked by Problem 2 below.

Problem 2)

Everywhere I read, they said you need to run with Execute="deferred" Impersonate="No". I believe this would indeed work for the most cases if you are not doing anything funky. However, I had to Impersonate. I discovered that the WiX installer would run your CA as elevated with user NT Authority/System. This screwed me over because the Exchange Management Shell script I was trying to source would basically use your credential and try to establish a session with the Exchange Server... and of course you can't connect as NT Authority/System!

The solution is to use Impersonate="yes" so that the WiX installer would run your CA as elevated AND the user you are currently logged in. I always had the impression that you must use Impersonate="no" when using Execute="deferred"... but you don't.

I gave up troubleshoot this for a few days and then went back to it and got it working. The 2 most helpful commands that helped me figured this out were actually:

• whoami
• Get-ChildItem env: (to check the PROCESSOR_ARCHITECTURE)