A customer recently had a requirement to deploy a PowerShell script to configure a setting for App-V 5.0.
Normally I’d do this with a Batch file called “Configure.cmd” containing the code displayed below. This works for the majority of tasks:
@echo off PUSHD %~dp0 PowerShell.exe -ExecutionPolicy Bypass -File ".\PowerShellScriptFileName.ps1" POPD
As usual, I tested the deployment before adding into SCCM by using psexec running under the System context (i.e. the same context that SCCM deployments run under) with the command below. One the command prompt is open you can run the required installer as the System context:
psexec /s cmd.exe
This completed successfully and made the configurations that I’d wanted. Bosh. Bloody awesome I thought…
On this occasion however I needed to reconfigure a 32-bit application (App-V 5.0) on a 64-bit operating system (Windows 7 x64).
This doesn’t play well when deployed via SCCM is seems and ends up running using the SysWOW64 redirection – the result in my case was that registry changes were made by the PowerShell cmdlet in the Wow6432Node area of the registry.
In order to get around this I discovered a new concept to me called “Sysnative” which is a virtual directory and special alias that can be used by applications/scripts to access the 64-bit “System32” folder – which is exactly what I wanted to happen in this instance for my script to produce the required result.
Therefore to use this you need to change the location that PowerShell is called from to %WinDir%\Sysnative (you can’t see it in Windows Explorer btw – but trust me, this little bugger does indeed exist):
@echo off PUSHD %~dp0 %WinDir%\Sysnative\windowsPowershell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File ".\PowerShellScriptFileName.ps1" POPD
Once changed to reference the correct PowerShell.exe my script punted out the desired results. Fucking Magic 🙂