PSAppDeployToolkit, SCCM 2012 & Avecto DefendPoint: Deploying applications as a Standard User

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:

PG_SCCMAgent

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:

PG_DeployApp

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:

PG_Workstyle

And there you have it. Simples! 🙂

Dan

By | 2016-10-14T17:30:52+00:00 March 27th, 2015|PowerShell App Deployment Toolkit|2 Comments

2 Comments

  1. Julian March 27, 2015 at 1:48 pm - Reply

    Fantastic post Dan.
    Just want thing that I would change is to limit the Deploy-Application.ps1 to just run from the ccmcache folder. We discovered that a user can potentially elevate unwanted software using the file. Not something that you want if you take a blacklist approach 🙂
    Thanks
    Julian

    • Dan March 27, 2015 at 1:55 pm - Reply

      Hey Julian,

      Thanks 😉 Actually my thinking was that process matching on the SCCM Agent would be sufficient, as then only SCCM can elevate Deploy-Application.ps1. However, I’ve added your suggestion and gone one step further – ideally you’d code sign your scripts and match against the Publisher too.

      Cheers, Dan

Leave a Reply