Github Desktop Install

When we execute Immy as User-Current user and the user is a local administrator, this works. The failure occurs if we attempt to use that as a system or metascript. When we manually run the code on the computer, it performs just as well as when we are logged into Powershell ISE as the Administrator.

Any recommendations?

I found some more information, and it seems it is another Squirrel.Windows like Teams and Yammer etc.

Do we have to use the MSI installer and create a task to fix it? What could be the configuration to set this up?

Does your issue persist when running it as a metascript and wrapping your installation inside of the following?

Invoke-ImmyCommand -Context User -ScriptBlock {<ScriptBlock>}

The code worked on my machine when run as a meta script from Immy, as I am a local administrator logged in on my laptop.
But when I ran it on another tenant’s device, it failed with an error saying Access Denied.

$Arguments = @"
-s
"@
$Result = Invoke-ImmyCommand -Context User -ScriptBlock {

$Process = Start-Process -Wait -Passthru $using:InstallerFile -ArgumentList $using:Arguments
return $Process

}

switch($Result.ExitCode){
0 {
Write-Host “Exit Code: 0 - Indicates Success”
}
1 {
throw “Exit Code: 1 - Indicates Pending Reboot. Reboot the computer and try installing again.”
}
default {
throw “Exit Code: $($Result.ExitCode)”
}
}

Is this correct logic or need to make any changes.

Start-Process : This command cannot be run due to the error: Access is denied.
At line:54 char:16

  • … $Process = Start-Process -Wait -Passthru $__using_InstallerFile -Arg …
  •           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
  • CategoryInfo : InvalidOperation: (:slight_smile: [Start-Process], InvalidOperationException
  • FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Exit Code:
At line:67 char:9

  •     throw "Exit Code: $($Result.ExitCode)"
    
  •     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
  • CategoryInfo : OperationStopped: (Exit Code: :String) , RuntimeException
  • FullyQualifiedErrorId : Exit Code:

Your user might be a local admin, but they might be a standard user. Might be worth throwing some logic in there to determine if the current user is part of the administrators localgroup

I confirmed that they are not part of the local administrator’s group. They are the standard users. Do we need to put on a logic for Get-Credential to pass via parameters and try or not worth?

Maybe, not too sure. I did find a debloat script with a self-elevating snippet that might work. Worth a try.

If (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]'Administrator')) {
    Write-Host "You didn't run this script as an Administrator. This script will self elevate to run as an Administrator and continue."
    Start-Sleep 1
    Write-Host "                                               3"
    Start-Sleep 1
    Write-Host "                                               2"
    Start-Sleep 1
    Write-Host "                                               1"
    Start-Sleep 1
    Start-Process powershell.exe -ArgumentList ("-NoProfile -ExecutionPolicy Bypass -File `"{0}`"" -f $PSCommandPath) -Verb RunAs
    Exit
}

Does this have to be part of the system script or metascript?
Also, do we need to pass the arguments and command line inside this script block?

@Dakota_Lewis

I tried this to suppress UAC.
Set-ItemProperty -Path REGISTRY::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -Name ConsentPromptBehaviorAdmin -Value 0
#$null = & “C:\Program Files\iQuila Enterprise Client\vencmd_x64.exe” localhost /client /cmd:NicCreate vpn
$Process = Start-Process -FilePath $InstallerFile -ArgumentList $Arguments -Passthru -Wait
Set-ItemProperty -Path REGISTRY::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -Name ConsentPromptBehaviorAdmin -Value 5

Didnt work and failed/timed out.

It’s because GitHub desktop is a per-user install, and per-user installers won’t work in system context. That said, I was working on a set of scripts some time ago that would handle these kinds of installers–the most recent successful example of this is Spotify (if you want to have a look at that approach).

Thank you @DimitriRodis .
I tested with the Soptify logic, but it is still not working. The GitHub Desktop is installed in the roaming profile for the logged-in user. I am trying more options using the Spotify code logic.

Has anyone got any further scripting this install? Cheers all

The solution to this would be to create a set of scripts to turn a squirrel “per user install” into a machine-wide one. Not sure you’re going to find a nicer way, outside of pleading with the software authors to create a machine-wide installer instead (and some vendors have, like PasswordBoss).