This project is read-only.

Error: App Deploy Toolkit Main requires Administrator rights...

Topics: Archive - Deployment Scripts, Archive - General
Aug 27, 2014 at 11:05 PM
In Salesforces infinite wisdom they have decided against deploying their Outlook Plugin 2.5 into C:\Program Files (x86) and now have moved to installing into the user profile (%APPDATA%). This is sloppy and pathetic in my mind. I am sure it will reduce their support calls but I can think of at least a few reasons why this is a bad idea. Enough ranting...on to the issue.

I have wrapped the Salesforce installer in order to stop Outlook and uninstall the previous version as their MSI isn't smart enough to do either....manually or in an automated fashion. As far at that goes, they don't even seem to care.

If this package is executed from SCCM 2012 SP1 or any version for that matter, the install runs as SYSTEM and the install gets placed into C:\Windows\System32\config\systemprofile\AppData\Roaming and of course the users do not have access to the folder as they are not admins (BY DESIGN!).

In order to accommodate the bad deployment package decision by Salesforce I have changed the application to Deployment Types > User Experience > "install for user" in SCCM which I have NEVER had to do in the last 15 years for business apps. When the app attempts to install I get the error that PSAPP needs to run as admin. I understand what this means but I am not sure how to get PSAPP to run under this scenario. I considered just running the MSI directly from SCCM but I need Outlook to close and the old version to uninstall first which this PSAPP handles flawlessly.

Any ideas on how to get PSAPP to run as the local non-admin logged on user?

Error: App Deploy Toolkit Main requires Administrator rights to function. Please re-run the deployment script as an Administrator. ()

In case it isn't evident, I am very disappointed in these type of apps that are moving in the direction to install into %APPDATA% to get around needing admin rights. It's fine for Minecraft and Spotify as those are consumer apps but for a business app like Salesforce....

By the way, I have been using this utility for all the other deployments and I have accomplished many difficult installs with ease. Thanks for all the work on this critical deployment tool.

Thanks Again
Aug 28, 2014 at 4:38 PM
As the plot thickens...Had a call with Salesforce and they are requiring us to submit a change and then if enough users vote on the change they will consider it. Looks like it will be a while, if ever. I need to figure this out more than ever. I also realized if I could somehow let the app deploy as the user I still have to uninstall the previous version, which IS correctly installed into C:\Program Files (x86). So now I need to close outlook and uninstall the plugin (as admin) and then install the plugin (as the local logged on user). Salesforce really dropped the ball.
Aug 28, 2014 at 10:03 PM
Edited Aug 29, 2014 at 3:46 PM
I'm gonna sound like a broken record because I just suggested this in the "General" forum, but I think it's valid here.

If the user is currently logged in and I need to alter their HKCU keys or install something to their AppData, I use RunAsCurrentUser to execute a reg add or whatever.

So for instance, in my deployment, I needed to make sure that a file was copied in to the logged-in user's AppData folder. Within my Deploy-Application.ps1 I have this:
 $CMD = 'Files\RunAsCurrentUser.exe'
 $arg1 = '--w'
 $arg2 = 'cmd.exe'
 $arg3 = '/c'
 $arg4 = 'xcopy'
 $arg5 = 'Files\'
 $arg6 = '%USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\'
 $arg7 = '/y'
 & $CMD $arg1 $arg2 $arg3 $arg4 $arg5 $arg6 $arg7
I know that looks silly but I was having a hard time calling it with Execute-Process for some reason. Anyway, I'm sure you see where you could plug in an install script there. RunAsCurrentUser.exe is still being run as the SYSTEM account, and all the changes are being made to whoever is currently logged in to the computer. Pretty cool, eh?

EDIT: There's not a lot out there on this application, so here's a quick link on use.
Nov 20, 2014 at 12:30 PM
Edited Nov 20, 2014 at 12:34 PM
Hi mniccum

You could just go in to the AppDeployToolkit\AppDeployToolkitMain.ps1

Edit the file with notepad or powershell ISE or whichever ps editor you use.

Search for "administrator" string.

You should be able to find what you want in line 4995
# Check current permissions and exit if not running with Administrator rights
If ($configToolkitRequireAdmin) {
    If (!([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
        If ($ShowBlockedAppDialog -ne $true) {
            Throw "Error: $appDeployMainScriptFriendlyName requires Administrator rights to function. Please re-run the deployment script as an Administrator."
Just put the whole section in comments like this (watch the <# and #> at beginning and end):
<# Check current permissions and exit if not running with Administrator rights
If ($configToolkitRequireAdmin) {
    If (!([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
        If ($ShowBlockedAppDialog -ne $true) {
            Throw "Error: $appDeployMainScriptFriendlyName requires Administrator rights to function. Please re-run the deployment script as an Administrator."
Save the file. Now the restriction goes away. It runs with standard user rights (even if user is local admin with UAC on)

Hope this helps.

This works on 3.2.0. Haven't tested on older versions
Nov 20, 2014 at 1:07 PM
There's a much easier way of doing this, just locate the switch in the config XML file that requires admin rights.
Nov 20, 2014 at 1:28 PM
Good to know there's an easier way! :)
Nov 20, 2014 at 3:23 PM
So where do I go to vote on that change for Salesforce? Our group has to install it too and it is a PITA.