1

I'm running into an issue with installing an MSI as a domain admin using powershell and batch scripts. Just to give a little bit of background, the environment I am in has UAC enabled. So regardless of being an admin or a standard user you need to always accept the UAC prompt to run an application. Now I am aware that there are registry tweaks and GPO's that I can enable to enableLUA, disable UAC, etc etc; but I'm trying to avoid making global changes like this to run the script (unless of course making these changes is a last resort)

Now the situation I am running in to is I am a Domain Admin. My org is planning on deploying PrintLogic as a printer solution, and we are trying to find the easiest way to deploy the client on all workstations. We don't have a software deployment app in the environment so I have to do this manually. This is why I am trying to take advantage of powershell and batch scripting to try and automate as much of the task as possible.

The powershell portion of the script basically is used to read encrypted password for the service account I will be using to install the software. The service account is also a domain admin so permissions shouldn't be an issue.

Now the software reads the credentials and stores them in a variable and then I pass those credentials through Start-Process. The issue I'm running in to is I can't get the installer to launch. I've tried several variations of the start-process command. And all of them either give me a access denied error (which makes no sense because as I mentioned the service account is domain admin), or I see the following warning "Warning: This command cannot be run due to the error: The directory name is invalid."

Here is the powershell script I am using (this version of the script has the msi installer programmed part of it so there are no batch scripts), however I also tried using startprocess to launch my install.bat file and then passing the credentials to the batch script as well and try installing it that way. Both methods give the same error above.

$global:adminCreds = $null
$global:path = (Split-Path $script:MyInvocation.MyCommand.Path)

function Authentication
{
    #---------------------------------------------------
    #Authenticate Admin Account using encrypted password
    #---------------------------------------------------
    #Variables
    $global:AESKeyFilePath = $path + "\aeskey.txt"
    $global:SecurePwdFilePath =  $path + "\credpassword.txt"
    $global:userUPN = "User"

    #use key and password to create local secure password
    $global:AESKey = Get-Content -Path $AESKeyFilePath 
    $global:pwdTxt = Get-Content -Path $SecurePwdFilePath
    $global:securePass = $pwdTxt | ConvertTo-SecureString -Key $AESKey

    #create a new psCredential object with required username and password
    $global:adminCreds = New-Object System.Management.Automation.PSCredential($userUPN, $securePass)
}

function Run-SoftwareEscalated
{
    Try 
    {       
        Start-Process "msiexec.exe" -Credential $adminCreds -Argument "/i `"$path\PrinterInstallerClient.msi`" /passive /norestart HOMEURL=https://url.domain.com AUTHORIZATION_CODE=123456789 /l* `"$path\logfile.txt`"" -Wait -WorkingDirectory $path
    }
    Catch 
    {
        Write-Warning -Message "$($_.Exception.Message)"
    }
}

#Run the authentication function to authenticate our session
Authentication
#Launch our main application
Run-SoftwareEscalated

My install.bat:

@echo off
cls

pushd "%~dp0"

::Launch our installer
start /w "" msiexec /i "%~dp0PrinterInstallerClient.msi" /passive /norestart HOMEURL=https://url.domain.com AUTHORIZATION_CODE=123456789 /l*v "%~dp0logfile.txt"
Lauren Yim
  • 12,700
  • 2
  • 32
  • 59
Koobah84
  • 185
  • 2
  • 12
  • The `directory invalid` error suggests that the target user isn't permitted to access the caller's current directory - see [this answer](https://stackoverflow.com/a/62734339/45375). Additionally, the `.msi` itself must be located in a directory the target user is allowed to access. – mklement0 Jan 13 '22 at 19:00
  • The target user is the user logged into the session that is running the script correct? If so, I was running it with my account and my account is domain admin and the service account I was running the app as is also domain admin, so I'm not sure why we wouldn't have access to the directory. EDIT: I just checked the post you mentioned above. I am using the -workingdirectory switch to point to the path of the msi, so should I be doing something differently? – Koobah84 Jan 13 '22 at 19:08
  • No, by target user I meant the `$adminCreds` user. Note that using `-Credential` does _not_ run the new process _with elevation_ - only `-Verb RunAs` can do that and, unfortunately, elevating _with specific credentials_ requires a complicated, nested call - see [this answer](https://stackoverflow.com/a/43281908/45375). – mklement0 Jan 13 '22 at 19:11
  • 1
    How are you launching the script, via remote session, scheduled task, group policy, or just manually? mk's linked answer goes into detail why it can be a pain to elevate the current process, but GPOs and scheduled tasks can be set to run elevated at start. – Cpt.Whale Jan 13 '22 at 19:16
  • If you're just installing an MSI without any extra tools, group policy can do exactly this without scripting anything. And leaving your DA service account credentials around in (obfuscated) plain text is not ideal. – Cpt.Whale Jan 13 '22 at 19:27
  • What is the best way to do this? I thought securing it the way I did in my code is safe. I might need to look into doing it via a GPO. Would it be possible to make it silent without any visual or user interference? If I use the /qn switch to make it quiet; running it via GPO won't cause issues with the fact that UAC is enabled? – Koobah84 Jan 13 '22 at 19:31
  • Let me ask this question... I am running the installer from a network share, but if I were to copy it locally say c:\temp, and then run it from c:\temp would that be a better option for me? That way everyone should have access to the c:\temp folder (hopefully). – Koobah84 Jan 13 '22 at 19:42
  • Again, how are you planning to start your script? If the answer is logon/rdp to machine > run script, then you can simply cut out the run-as-different-user step, and start powershell as admin. If the answer is something else, you may be running into second-hop limitations (you can connect out to `server1`, but you are NOT allowed to reach out from there to another machine, including grabbing your MSI from `\\server2\x\`. Usually a different error though) – Cpt.Whale Jan 13 '22 at 19:59
  • The plan would be to run it off the users machine through their session. We would just point them to the custom installer and they would just double click to run it. The file is run from a file server, and the path users are running from they have access to it. It would be something like "\\fileserver\printerinstall" I hope that answers the question. – Koobah84 Jan 13 '22 at 20:06
  • GPO computer policies run as the local system and are already elevated - no uac changes required. For these, make sure your MSI file is located somewhere the AD computer account has read access to though. If you want to do the software install, you do need to create a MST file with your two `FLAG=VALUE` settings. It installs MSIs silently by default. – Cpt.Whale Jan 13 '22 at 20:06
  • "We don't have a software deployment app in the environment" - Yes you do, if you use Group Policy. (GPOs can automatically deploy MSI packages.) – Bill_Stewart Jan 13 '22 at 20:22
  • @Koobah84 1) for that plan, each user needs read access to `credpassword.txt` and the key - it would be easier to give them the credentials, right? 2) A regular non-admin user's session **cannot** easily elevate anything without UAC anyways, in mk's answer again. – Cpt.Whale Jan 13 '22 at 20:27
  • @Bill_Stewart is right. Just use Group Policy and don't reinvent the wheel. Incidentally, it's been a while since I looked at it, but if you don't digitally sign your PowerShell script couldn't some malicious user just modify it to run: Start-Process "virus.exe" -Credential $adminCreds... etc? – Captain_Planet Jan 19 '22 at 22:53

0 Answers0