As a packager you always want to know if the application works as described in a intake document. Also you want to eliminate deployment issues.
I run into issues that the application installed perfectly – even under the system account – but with SCCM 2007 the deployment failed.
Lets take the following scenario:
Windows 8 x64
The question is: why did the installation fail?
As an example I made a SCCM program that only starts cmd.exe. If the advertisement is run, the command ‘whoami’ and ‘set PROCESSOR_ARCHITECTURE’ are entered, this is shown on the screen:
As you can see, the PROCESSOR_ARCHITECTURE is x86, even if the x64 cmd.exe is used.
Why is that?
SCCM 2007 is only 32 bits. So that means if the 32 bits ccmexec.exe starts a process, all the subprocesses are also 32 bits! See the numbers ‘1’ and ‘2’ below:
Now we know how SCCM is dealing with the processor architecture. But how can we simulate this?
Use psexec from a remote system and start cmd.exe with the command: psexec \\remotecomputer -i -s cmd.exe
Now c:\windows\sytem32\cmd.exe is started… but the PROCESSOR_ARCHITECTURE is still x64. Not the correct behavior, as we would like to have the 32 bits cmd.exe.
How can we simulate the SCCM behavior so that the 32 bits cmd.exe is used?
Use psexec from a remote sytem and start c:\windows\syswow64\cmd.exe with the command: psexec \\remotecomputer -i -s c:\windows\syswow64\cmd.exe
Conclusion: use c:\windows\syswow64\cmd.exe together with psexec to test the installation of applications.
With SCCM 2012 that is no issue anymore as it has both 32 and 64 bits support.
Update: 16 July 2013
On How to workaround 64-bit redirection in SCCM 2007 (Microsoft TechNet Forum) I found an alternative. Use the following command line:
Tested on Windows 7 x64:
(With a special thanks to Peter Fonk for pointing me to that Technet article.)