SCCM 2012 gives the option of installation an application as the currently logged in user, or as the LocalSystem account. There are differences in why you would choose one over the other – namely, easy access to current user paths and registry keys. Some Windows Installers have a lot of Per User components and if installed using LocalSystem, tend to be a pain in the ass to get installed when an actual user logs in. So running deployments as the currently logged in user can be very handy.
However, there is a limitation in the Application Model whereby if you chose to install an application as a User, it inherits their user privileges for the installation. This is a problem if your users are Standard Users as opposed to Local Administrators – more often than not, you won’t have the permissions to perform a full install.
If you’re lucky enough to have deployed Avecto DefendPoint (formerly Privilege Guard), you can very easily overcome this by granting Administrator Privileges to PSAppDeployToolkit installation scripts. Here’s how I have this working:
I created two Application Groups, and one Work-Style. The first App Group is for the SCCM Agent:
The second App Group is for the Deploy-Application.ps1 scripts themselves. It is set to match child processes of the first App Group. You can make this more secure by using a wildcarded path such as “%WinDirCCMCache*Deploy-Application.ps1”. Better still, ensure you code sign your Deploy-Application.ps1 scripts and add a match criteria against the Publisher:
Finally, the Work-Style is set to automatically add Admin Rights to any Deploy-Application.ps1 that gets run – provided it is a child process of the SCCM Agent. This ensures the PSAppDeployToolkit installation script only gets Admin Rights when called by the SCCM Agent:
And there you have it. Simples! 🙂