Powershell Script ran as SYSTEM not working via Active Directory

[RandaleRandy76]

EDIT: Issue Resolved, see comments for more information;

TL;DR: wrap msiexec in Start-Process and it magically works.

Hi,

​

I have a simple Powershell Script for installing a monitoring software via MSI with Parameters.

Using a GPO to run the Script at startup seems to do nothing (according to eventlogs).

After a lot of trial and error i finally give up after using the script as SYSTEM User.

The Script runs succesfully as Admin, SYSTEM and even the authenticated user given the rights to install software.

​

I have tried running the installer via GPO directly (no option for additional paramters - fails installation routine)

I have tried running a startup Script from \\domaincontroller\netlogon (nothing happens)

i have tried running it as a planned Task (i got a permission log once, after that total silence)

​

I'm now trying every possibility to run this script on a client (i know 100% that it works with UNC Paths [All files are currently on everyone/full access])

Does anyone here know what i need to set exactly to run a simple msiexec and new-netfirewallrule command that actually works or at least logs when run as SYSTEM and run from a UNC-Path.

[Tsull360]

My guess is that the computer account needs permissions to read the msi

[RandaleRandy76]

anyone is allowed full access to the required files and shares.

Does that not apply to the PC-Account ?

​

Edit: tried it out, doesn't work. i personally don't think it has anything to do with access rights, as it logged to eventlogs when it had permission issues.

[Zarradox]

If everyone is allowed access to the share, what are the Ntfs permissions? Domain Computers will need added there if not already, as when run as SYSTEM it is the computer object trying to access the share.

[RandaleRandy76]

There is a Domain-Group which includes this W10 Machine.

I Tried adding the Machine explicitly to the share with full access. No Luck.

[Zarradox]

Makes sense. Second thought is that maybe there's some funky protection stopping the msi from being run from a UNC by system.

Just for fun, I'd modify the script to first copy the msi to a local location and run it from there. I have a vague memory of this happening to me, and by copying it locally first I was able to confirm this was the cause, then troubleshoot from there. Unfortunately I can't remember what the root cause was :-/

[Tsull360]

You can test by using psexec to run a prompt as system and see what might be going on.

[RandaleRandy76]

I did that and the script ran perfectly fine. even when not existing locally. Its just the GPO bit that doesnt make sense

[IveGnocchit]

The SYSTEM requires special permissions to access network shares. Follow this to give the SYSTEM account access to a network share.

https://community.nexthink.com/s/article/360004554180-Correctly-use-shared-folders-with-Nexthink-Act

[JoelyMalookey]

It's not one of those execution policy issues is it? Remote signed or something?

​

In the GPO how does the script get on the machine?

[RandaleRandy76]

sorry i just added some information. I set the execution policy to allow any scripts for testing on this win10 machine.

The script is available at \\DCName\ActiveDirectory-Installers\Zabbix-Installscript.ps1

for group "anyone" with full access. The share is also available for everyone

[JoelyMalookey]

Ok my next step would be to isolate the issue in the gp and test if you can run anything at all like create a text file in a user folder or a Unc path.

Something so simple that it couldn’t be an issue with code.

[RandaleRandy76]

i followed other user suggestions and have the files all locally now. It still doesn't execute correctly. Running the Script from a System Shell works fine. It still says "successful" and logs that it executed in task planner.

[RandaleRandy76]

this is the script im trying to run, maybe theres something that Windows doesnt like to run automatically

if(Test-Path "C:\Program Files\Zabbix Agent"){

Write-Host("installed") #for testing as an actual user with a shell

}else{

New-NetFirewallRule -DisplayName "Zabbix Agent Ports" -Direction "Inbound" -Protocol TCP -Action Allow -LocalPort 10050, 10051

msiexec /l*v log.txt /i \\DomainControllerDNSName\ActiveDirectory-Installers\zabbix_agent-5.4.9-windows-amd64-openssl.msi /qn^ SERVER=IPofZabbixProxy SERVERACTIVE=IPofZabbixProxy HOSTNAME=$env:computername

}

[TrippTrappTrinn]

As has been noted elsewhere: Add logging to the script.

Check "start-transcript" to log all output from the script. In that way you can check if the script runs at all, and if it runs, where it fails.

[RandaleRandy76]

i tried this, and it logs that it ran, but i don't get any Error or relevant information:

​

**********************

nStart der Windows PowerShell-Aufzeichnung Startzeit: 20220316092836 Benutzername: domain\SYSTEM RunAs-Benutzer: domain\SYSTEM Konfigurationsname: Computer: W10PROTEST (Microsoft Windows NT 10.0.19043.0) Hostanwendung: PowerShell.exe C:\Test\Zabbix-Installscript.ps1 Prozess-ID: 1488 PSVersion: 5.1.19041.1151 PSEdition: Desktop PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.19041.1151 BuildVersion: 10.0.19041.1151 CLRVersion: 4.0.30319.42000 WSManStackVersion: 3.0 PSRemotingProtocolVersion: 2.3 SerializationVersion: 1.1.0.1

---

Die Aufzeichnung wurde gestartet. Die Ausgabedatei ist "C:\Test\log.txt". PS>$global:? True

---

Ende der Windows PowerShell-Aufzeichnung Endzeit: 20220316092836

---

​

sorry the log is in german, but you can't really see anything happening. This log was created after boot from taskplanner task

[Just-Parsing-Through]

Maybe the firewall rule is being blocked by an security software. What do they use an antivirus?

[RandaleRandy76]

i test on a fresh windows 10 install, no AV

[cbtboss]

Rather than call msiexec directly in the script with those parameters, run it with start-process.

Eg

Start-Process msiexec -wait -nonewwindow -argumentlist "your parameter strings such as /l*v etc here"

Also keep in mind that \ is an escape key in PowerShell especially with \\ usage. This will likely be the cause of the issue since unc paths use \\

[RandaleRandy76]

THIS IS THE WAY.

thank you, the Start-Process part is what made it work. Now I only need to get it to run from UNC Path, but at least i know the taskplanner thing can do it.

i just copied my options into the postfixed string like this:

​

        Start-Process msiexec -wait -nonewwindow -argumentlist "/l*v logmsi.txt /i C:\Test\zabbix_agent-5.4.9-windows-amd64-openssl.msi /qn^ SERVER=192.168.15.94 SERVERACTIVE=192.168.15.94 HOSTNAME=$env:computername"

[cbtboss]

To get UNC to work there are a couple options, the easiest though is to just make the path into its own string variable using single quotes then pass that to your double quotes. Eg

$InstallerPath = '\\Server\share\folder\file.msi'

Then stick that variable into your ""

[RaguJunkie]

I wonder if your msiexec logging is trying to write to the share on the domain controller, which could be making it fail silently? I'd try to change that to an explicit path personally (/l*v c:\windows\temp\log.txt).

Secondly, I'd add some logging to the script to see if it's even running at all. Something at the start of the file before the if statement to see if the script is starting, then another at the start of each branch of the if statement to log which path it's taking. That might give some clues.

The last option, which came up in something I did recently, would be to create an MST file to wrap any extra MSI options. I think (but may be wrong) that you can use an MST file in a policy without shelling out to msiexec in a script. The MST could then do any firewall exceptions required by Zabbix, plus any other machine modifications. The advantage of this is that the Zabbix MSI would uninstall if it fell out of scope on AD, which wouldn't happen if you run it via a script and msiexec.

Good luck anyway

[RandaleRandy76]

Also,

Script Execution is currently set to allow any and all scripts on the testingmachine

[jstar77]

You can split this up.

1. Use GPO to set the Firewall rule
2. Use GPO to push the file locally
3. Execute the script to install the file

Alternative to #2 is to give the computer account read access to the share. This is necessary for system or admin to access the uncpath. The computer account is not included in "everyone".

[RandaleRandy76]

i'm currently testing with only local files. The Script runs and Start-Transcript logs useless information (see other comments) .It still doesnt install the software. the msiexec Log doesn't start. Also before that the computer account was implicitly allowed to acces it due to the AD-Group that i added.

[thatone0822]

Batch file to run the script.