I’ve been spending a bit of time recently, working around various constraints of working in an environment where UAC is enabled and end users have no local administrative rights over their machines. This especially becomes a problem when applications are written badly, don’t provide any means to be packaged or simply touch the system in a way that needs administrative rights. Essentially, what I wanted to provide was the ability for an end user to run x app, as an administrator- be that a particular software update or simply a program that wants to set itself as the default PDF reader.
We run Sage Accounts, and fairly often they’ll release a small update. This update is provided as an .exe, has no silent switches, requires administrative rights and prompts the user to confirm the path to update. I’ve spent a fair amount of time trying to dissect this installation, capturing the process with an MSI packager (2 actually) with no luck. I even brought out the big guns and watched the installation with Sysinternals Process monitor. It gets to the point where you’re essentially re-writing the entire update, and quite frankly it’s just a massive time drain… not only that but it becomes a much riskier process and requires more testing. “Did I get everything”.
PDF readers. We run two flavours, and users are generally given the choice to which one they choose. Of course, changing the default programs associated with PDFs requires administrative access. So, we may get a support call that requires us to remote in, fire up the “other” applications with admin credentials, and set it as the default reader. This becomes an unnecessary interruption for both the end user and admin. You could go ahead and create a GPO that writes the required registry keys, but it’s a bit messy and again requires a fair bit of initial effort to configure.
Allowing users to launch applications with administrative rights
To make this possible, we’ll be using the Software Catalog provided with SCCM 2012. This application is automatically deployed as part of the agent, so shouldn’t require any additional work client side.
I’ll give you two examples, one running a local executable on a system and the second running an executable on a file share. When using this method, the executable is loaded with the “system” account.
Browse to Software Library -> Packages, right click and select create package.
Give the package a name, this is the title displayed in the software catalog, so you’ll want to make it user friendly!
This is a standard program.
The name field is tagged onto the package name, so append with run/setup/launch, whatever best describes the action. I’ve given the path and executable, and changed the run mode to run with administrative rights. You must tick “allow users to view and interact with the program installation” otherwise it’ll hide the application.
Here you can specify some additional options, it’s worth changing the estimated disk space, as this is displayed in software centre and I normally bring the run time down from 120 minutes to 15.
After this, next, next yourself through the end of the wizard. As this is running a local application there is nothing to distribute, you simply need to deploy the package to a device collection. This is a bit beyond the scope of this article, but I’ll look to write a post in the new future covering that.
Fire up the Software Catalog from the start menu and the package should be available for install.
“Installing” this package, will launch the application under the system account and allow the user to set as default (it prompts on launch). Obviously the users mapped drivers will not be present in this session, but when was the last time you opened a PDF viewer and opened the file from within?
There is a security risk when launching a full application this way, as the application is elevated a user could open other applications from within with elevated privileges. This method is more suited to allowing the end user to run scripts, or applications that do not allow the user to open applications from within.
Executable on UNC Path
The process is essentially the same, except you provide the UNC path for the startup folder. If this is going to be launched on multiple sites, I’d recommend you use something like DFS to replicate the installation files around your particular locations.
When this package is installed, it launches the accounts2013update2.exe under the system context and allows the users to confirm the update path and update the application. This particular application does not allow for any additional interaction bar allowing the user to confirm the update path, so the security concerns outlined above do not apply.