I have written a script, that takes a csv file with vulnerable Servers and should replace the installed version of Notepad++. I uninstall the currently installed version from the machine, push a installer into the C:\ Directory of the machine and afterwards remove it, which works totally fine. I also have verified, that the push of the installer works, that I have admin rights on the machine and that the account I use is an (domain) admin account. However, my problems start as soon as I try to install the provided .exe: The script gets stuck at this point. There aren't any relevant errors and no prompts, just nothing happens at this point. When logging into the machine with RDP it seems like nothing happens and no installation process commences. No folders are being created and no files are moved or whatsoever.
This is the relevant part of my script:
Write-Host "push installer"
Copy-Item $installerUrl -Destination "\\$serverName\C$"
Write-Host "set path"
$installerPfad = "\\$serverName\c$\npp.8.5.6.Installer.x64.exe"
Invoke-Command -Session $session -ScriptBlock {
param ($path, $cred)
# Returns $true if elevated, otherwise $false.
[Security.Principal.WindowsPrincipal]::new(
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
whoami #The user gets recognized correctly and is domain admin
if (Test-Path -Path $path) {
Write-Host "$path ist erreichbar."
} else {
Write-Host "$path ist nicht erreichbar."
}
Start-Process -FilePath $path -WorkingDirectory $env:TEMP -ArgumentList "/S, /D=C:\Program Files\Notepad++" -Wait
} -ArgumentList $installerPfad, $credentials
#$Error[0]
#$Error[0].Stacktrace
I have the slight fear, that the installer is prompting something like the uac, but I can neither confirm nor deny it. Would starting an installation this way trigger a UAC banner?
Can you please help me determine the problem and fixing it as I have spent two days on this now and I can't find the issue. Thanks
-What I've tried:-
Obviously I was expecting the installation to work, which shouldn't take that long too, as it's a quite tiny program. What I tried:
passing -Verb RunAs, which apparently doesn't work remotely nor is it needed as I verified elevated rights
passing my credentials to the dom admin, which oddly creates a permission denied error, however this should be irrelevant here too, as my account is elevated
removing the /D=... argument
writing the /S argument as /s
omitting the -WorkingDirectory argument
checking the $Error for relevant content
Hello everybody and thank you very much for your replies. Further investigations seemed to show that some of my servers interpreted the UNC path as some kind of "bad wild west internet area" and therefore launched an additional request whether the file is to be trusted. Changing the remote invoked command to an absolute path pretty much solved the problem. 15ish machines which accepted my first patch run with the updated path version version 8.5.6 weren't able to perform the silent run on the first try and freezed, but somehow recovered a couple hours later and did perform the upgrade as intended, so I have to regard this as "jitter". So my wild guess here is that the main issue was triggering the installation using an UNC path. Greets Poweruser181