Discussing the differences between SCCM CB packages and application model are not new. I have seen several posts and discussions about the advantages of using application model rather than “classic” packages. Let’s see more details about SCCM Package Vs Application.
I recommend using applications rather than packages because of several reasons. I’m not getting into the details of using advantages of using SCCM CB application model. In this post, we will see video experience of SCCM CB package runs in 32 bit and application in 64-bit context.
History of SCCM packages?
SCCM 2007 was a 32bit application, and if I understand correctly, SCCM 2007 packages always run in 32-bit context. This could be because the package implementation is simply a 32-bit code. The packages can’t run in 64-bit context. Is this true for SCCM CB as well?
As per my testing and video tutorial here, the packages in SCCM CB always run in 32 bit context. This statement is true for Windows 10 32-bit and 64-bit machines. It will be difficult to understand and reproduce this scenario when you try to deploy MSI or EXE application as a package.
The MSI/EXE applications which are packaged to run only with 32bit will work fine with SCCM CB packages. However, when trying to convert these 32bit packages into new application model then, these apps will fail. To fix this issue, we need to enable an option in SCCM app model (Deployment type properties) called “Run installation and uninstall program as 32-bit process on 64-bit clients“.
How to confirm SCCM Packages run with a 32bit code?
I created a PowerShell script to using package options in SCCM CB. Navigate \ Software Library \ Overview\Application Management\Packages” and right click and create a package with the PowerShell script. Deploy the script to Windows 10 64bit machine.
When we deploy PowerShell script to Windows 10 64bit machine then, Windows PowerShell 32 bit application is executed as you can see in the video here. This proves SCCM CB package uses 32-bit code and it can’t run on 64bit context.
You can deploy 64 bit MSI/EXE/Scripts using SCCM packages. The best method is run the package from SysNative context. Sysnative is a virtual folder which will help us to access the 64-bit System32 folder from a 32-bit application or script.
SCCM CB Software center client is still a 32bit application. You can see the app SCClient(32 bit) in the above picture. This proves that new software center is 32-bit client on Windows 10 64-bit machine.
How to confirm SCCM Applications run with 64-bit code?
SCCM CB application always runs in 64-bit context. By default all the applications created using SCCM CB app model use 64bit context to start the execution. Your 32-bit application will fail if you create SCCM application and deploy it to clients.
When there is a specific requirement to run within 32bit context then, you need to enable the following option “Run installation and uninstall program as 32-bit process on 64-bit clients“. You can get this option from Application – deployment type properties.
To prove SCCM applications use 64bit context to run MSI/EXE/Scripts, I have created an application via \Software Library\Overview\Application Management\Applications. I used the same PowerShell script (which I used to create SCCM package). Deployed application to Windows 10 device.
I have initiated the PowerShell execution from Software center as you can see in the video here. The result is the PowerShell script (Windows PowerShell) runs with in 64bit context. The same PowerShell script ran in 32bit context when we deploy it as SCCM package.
SCCM CB Task Sequence Runs within 64bit context
The Task Sequence in SCCM CB runs within 64bit context. But, the SCCM CB TS engine provides a similar option like applications to run 32bit applications/scripts. The option is to enable the following option “Run installation and uninstall program as 32-bit process on 64-bit clients“.
References – SCCM Package Vs Application
- SCCM Application Versus Package – here
- ConfigMgr 2012 and 32-bit Application Installers – here
- PowerShell App Deployment Toolkit – here