14.08.2020

9299

MSI Installation als User auf TS funktioniert nicht

Guten Tag zusammen,
ich habe eine Frage bezüglich der Installation von einer MSI-Datei auf einem Server 2016 Datacenter Terminalserver.

Wenn ich eine User-Software installieren will, kann ich das als normaler User problemlos. Ich starte die Installation und der Wizard installiert ihn unter AppData. Nun will ich aber bei allen Usern die Software installieren (muss auf User-basis sein, damit gewisse Registry-Einstellungen dafür greifen).

Ich starte die Installation per Powershell-Script (weil UNC-Pfad) mit dem Parameter /passive (start namedermsi.msi /passive). Aber auf dem Terminalserver läuft die Installation nicht erfolgreich durch und bricht ab. Nach einiger Recherche habe ich herausgefunden, dass es abbricht, weil anscheinend aufgrund einer administrativen Richtlinie das verhindert wird.
Ich habe aber sicherlich keine Richtlinie aktiv, die sowas explizit einschränkt (die normale Installation per klick klick klick ok funktioniert). Es muss also eine sein, die irgendwie standardmäßig aktiv ist, ich finde aber keine Infos dazu. Und ich finde auch keine korrekten Google Ergebnisse, vielleicht suche ich auch falsch. Starte ich jedenfalls diese Installation auf dem TS als Domänenadministrator, läuft sie planmäßig durch.

Stelle ich die Situation auf meinem lokalen Win 10 Rechner nach, funktioniert es genauso, wie es soll. Ich habe das Script + die MSI im Netzwerk freigegeben (Jeder lesen) und greife über \\localhost\freigabe\script.ps1 zu. Ich werde gefragt, ob ich das Powershell-Script ausführen will, ich bestätigt das, die Installation läuft sauber durch. Ich bin mit dem User, mit dem ich angemeldet bin, kein lokaler Administrator, bin also als normaler User unterwegs.

Ich habe dann die Idee gehabt, dass PowerShell Scripte auf Terminalservern nicht erlaubt sind, Stichwort Execution Policy. Da ich aber nicht "unrestriced" nutzen wollte, bin ich sogar soweit gegangen und habe das kleine Script mit der internen Zertifizierungsstelle signiert, gleiches Ergebnis.

Kann mir jemand sagen, was hier eventuell falsch läuft?

Vielen Dank im Voraus!

MfG

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 596241

Url: https://administrator.de/forum/msi-installation-als-user-auf-ts-funktioniert-nicht-596241.html

Ausgedruckt am: 22.12.2024 um 07:12 Uhr

44 Kommentare

Neuester Kommentar

Hi.

Starte die MSI interaktiv als schwacher (Test-)nutzer auf dem TS - was passiert?

Hallo,
danke für die schnelle Antwort.
Wie schon gesagt (vielleicht nicht deutlich genug) läuft die Installation als normaler User (gleiche Rechte und z.T. Gruppen wie alle anderen User auch) mit Doppelklick auf die MSI problemlos durch. Ein paar mal klicken und das Ding ist installiert.

Ich würde aber gerne dafür sorgen, dass nicht alle User die Software bekommen, es dürfen nur ausgewählte User die Software bekommen. Aber da wir mehrere Terminalserver haben und mehrere Standorte ist das viel Arbeit, wenn jeder User auf jedem Terminalserver einmal die Installation durchklicken müsste. Daher die Idee, die Installation zu automatisieren; Anmelde-Powershell-Script, das prüft, ob gewisse Dateien vorhanden sind, wenn ja, wird die Installation übersprungen wenn nein, wir sie durchgeführt. Das ist zumindest mal der langfristige Plan. Als erstes wollte ich erstmal dafür sorgen, dass die Installation generell mal durchläuft :D Und daran scheitert es derzeit schon.

Danke!

Dann liegt das Problem ja eindeutig im Aufruf durch Powershell.
Was passiert über Batch
msiexec /i \\server\share\dein.msi /qn

Hi,
es passiert gar nichts. Kein Fenster, kein Fehler, kein Hinweis, kein nichts.
Edit: Und die Software installiert sich natürlich auch nicht, das wäre ja sonst zu einfach :D

/qn zeigt ja auch nix an. Probier mal /qb.

/q - set the UI level:

    n - no UI
    n+ - no UI except for a modal dialog box displayed at the end.
    b - basic UI
    b+ - basic UI with a modal dialog box displayed at the end. The modal box is not displayed if the user cancels the installation. Use qb+! or qb!+ to hide the [ Cancel ] button.
    b- - basic UI with no modal dialog boxes. Please note that /qb+- is not a supported UI level. Use qb-! or qb!- to hide the [ Cancel ] button.
    r - reduced UI
    f - full UI

Hi,
"Der Systemadministrator hat Richtlinien erlassen, um diese Installation zu verhindern."
Welche Richtline kann das sein bzw. ist dafür verantwortlich? Mir wäre nichts bekannt.

Das einzige, was dem am nächsten käme, ist eine GPO, die mal gültig war: dass nur eine bestimmte Usergruppe ein bestimmtes Programm starten darf. Da das aber so viele Negierungen benötigt hatte, wurde diese Regel wieder deaktiviert.
Das war die GPO "Angegebene Windows-Anwendung nicht ausführen", dann wurde die Programm.exe genannt und diese Richtlinie quasi für die Gruppe "ALLE_USER_AUSSER_DIE_DIE_DÜRFEN" gefiltert. Total Banane. Wie gesagt, diese GPO ist aber nicht mehr aktiv.

Hm..es gibt noch die GPO "Einstellungen für die Installation optionaler Komponenten und die Reparatur von Komponenten angeben", die aktiviert ist, damit optionale Komponennten wie Net-Framework o.ä. oder Windows Reparaturen direkt von MS und nicht dem WSUS gezogen werden können.
Die dürfte damit ja nichts zu tun haben, oder?

Danke!

Das ist applocker oder eine Softwareeinschränkungsrichtlinie ("SRP").
Einfach am Server ein elevated command Prompt öffnen und dort

gpresult /h %temp%\result.html /f & %temp%\result.html

abfeuern und in der sich öffnenden Reportdatei nachschauen, ob Applocker oder SRPs aktiv sind und von welcher GPO die stammen.

Hallo,
es gibt keine Richtline, die dafür verantwortlich ist.
Kann ich hier die gpresult Datei posten oder stehen da zu viele Details drin? Kann ich dir die irgendwie per PM oder so zukommen lassen?`

Danke

Öffne sie in notepad. Drücke STRH und H (Suchen und ersetzen), suche gründlich nach Namen/Wörtern, die Du nicnt veröffentlichen willst und ersetze sie durch Dummies. Speichere, uploade hier: https://fromsmash.com/

fromsmash kenne ich nicht.
Aber ich habe die html-Datei mal angepasst und hier hochgeladen:
https://www.file-upload.net/download-14233608/gp.html.html

Ich finde keine Applocker-Einstellungen o.ä.

Edit: Grml, sehe gerade, dass beim Downloaden das LE Zertifikat abgelaufen ist.
Hier nochmal von einem anderen Hoster:
https://filehorst.de/d/deIAHIiE

Danke
MfG

Ok, hab's durchgesehen. Richtig, dort ist keine SRP/Applockerpolicy zu finden.
Deine Meldung kommt auch, wenn das MSI eben doch Adminrechte erfodert, aber die UAC aus ist. Prüf das bitte.

Und bitte bitte, tut euch einen Gefallen und setzt https beim WSUS ein. Das ist schon extrem wichtig!

Zitat von @DerWoWusste:
Ok, hab's durchgesehen. Richtig, dort ist keine SRP/Applockerpolicy zu finden.
Deine Meldung kommt auch, wenn das MSI eben doch Adminrechte erfodert, aber die UAC aus ist. Prüf das bitte.

UAC steht auf Immer benachrichtigen, ist also an. SmartScreen ist auch aus.
Das Problem besteht übrigens bei dem zweiten Terminalserver des Kunden ebenfalls, gleiche Domäne, anderer Standort.

Zitat von @DerWoWusste:
Und bitte bitte, tut euch einen Gefallen und setzt https beim WSUS ein. Das ist schon extrem wichtig!

Darf ich fragen, warum? Der WSUS selbst lädt die Updates ja sogar auch über HTTP runter. Sogar die Standardansicht beim WSUS setzt HTTP voraus und man muss SSL erst in den virtuellen Verzeichnissen im IIS aktivieren und dann noch über die Shell SSL aktivieren.

Wir hätten mit der AD Zertifizierungsstelle schon die Möglichkeit, aber warum ist das nötig?

Danke!

Gut. Zum ersten Punkt: nimm mal ein MSI, das Adminrechte erfordert, zum Beispiel 7zip und teste damit. Was passiert?
Wg. Wsus: Es gibt wunderbare Exploitkits, die geben sich selbst als WSUS aus und hauen Deinen Kisten die Malware als Updates getarnt um die Ohren. Bekannt seit Ewigkeiten, ausgenutzt seit Ewigkeiten Risiko: hoch. Wahrscheinlichkeit der Ausnutzung: hoch. Abhilfe: simpel: https.

Der WSUS selbst lädt die Updates ja sogar auch über HTTP runter

Hö?
https://docs.microsoft.com/en-us/windows-server/administration/windows-s ...
Siehe 2.1

2.1.1. Connection from the WSUS server to the Internet
If there is a corporate firewall between WSUS and the Internet, you might have to configure that firewall to ensure WSUS can obtain updates. > To obtain updates from Microsoft Update, the WSUS server uses port 443 for HTTPS protocol.

Zitat von @DerWoWusste:
Gut. Zum ersten Punkt: nimm mal ein MSI, das Adminrechte erfordert, zum Beispiel 7zip und teste damit. Was passiert?

Die Installation startet, ich komme zur Auswahl Modify, Repair, Uninstall (7zip ist bereits installiert) und nachdem ich eine Sache ausgewählt habe, fragt di UAC, ob ich Änderungen am Gerät erlauben will. Wenn ich mich mit meinen User-Credentials versuche zu authentifizieren, kommt der Hinweis, dass der Vorgang erhöhte Rechte braucht. So wies sein soll.
Macht ja keinen Sinn, mich an der Stelle als Domänen-Admin zu authentifizieren, oder?

Zitat von @DerWoWusste:
Wg. Wsus: Es gibt wunderbare Exploitkits, die geben sich selbst als WSUS aus und hauen Deinen Kisten die Malware als Updates getarnt um die Ohren. Bekannt seit Ewigkeiten, ausgenutzt seit Ewigkeiten Risiko: hoch. Wahrscheinlichkeit der Ausnutzung: hoch. Abhilfe: simpel: https.
https://docs.microsoft.com/en-us/windows-server/administration/windows-s ...
Siehe 2.1

Okay, danke. Ich dachte, ich hätte beim WSUS beobachtet, dass er über Port 80 Dateien runterlädt. Vermutlich habe ich mich da getäuscht.

MfG

Ja, 7zip braucht ja auch Adminrechte. Nimm doch mal eins, was noch nicht installiert ist, z.B. xml notepad: https://download.microsoft.com/download/6/e/e/6eef2361-33d4-48a2-b52e-58 ...

Zitat von @DerWoWusste:

Ja, 7zip braucht ja auch Adminrechte. Nimm doch mal eins, was noch nicht installiert ist, z.B. xml notepad: https://download.microsoft.com/download/6/e/e/6eef2361-33d4-48a2-b52e-58 ...

Eh, ok, dachte, das wäre das Ziel der Übung.
Jedenfalls, XML Notepad verhält sich gleich (es ist noch nicht installiert): Die Installation startet, ich komme zur Auswahl des Installationsziels und nachdem ich das ausgewählt habe, sagt die Installation Ready to install.
Wenn ich nun auf Install klicke, fragt die UAC, ob ich Änderungen am Gerät erlauben will. Wenn ich mich mit meinen User-Credentials versuche zu authentifizieren, kommt der Hinweis, dass der Vorgang erhöhte Rechte braucht, geht also nicht.

Gibt es eine Einschränkung, die bei Terminalservern gilt, die man erst noch irgendwo deaktivieren muss oder sowas?

Danke...

Nee, gibt's nicht. Kannst du das Msi hochladen?

Zitat von @DerWoWusste:

Nee, gibt's nicht. Kannst du das Msi hochladen?

Hi,
ja, das sollte ok sein.

https://www.file-upload.net/download-14237858/Z1GatewayCompanionPerUserS ...

Gibts auch als "per Computer" Installation, aber wenn ich diese installiere, greifen eben die Registry-Einstellungen nicht (weder im CURENT USER Verzeichnis, noch im LOCAL MASCHINE Verzeichnis). Davon ab habe ich damit die Installation auch nicht getestet.
Ist eigentlich nur ein Outlook Plugin, für den Kunden aber wichtig.

Noch irgendwelche Ideen?

Danke

Ich habe das nachvollzogen auf einer 2016er Testinstallation - ist bei mir genau so.
msiexec /i paket.msi /qb führt zu "Der Systemadministrator hat Richtlinien erlassen...", während das Selbe auf Win10 einfach geht.
Frag den Entwickler des Paketes, ob es bei ihm auf 2016 Server läuft (vermutlich auch nicht, da meiner jungfräulich ist) und wenn ja, wie.

Wie wäre es damit: https://support.microsoft.com/de-de/help/223300/how-to-enable-windows-in ...

Oder

msiexec /i paket.msi /qb /L*iew "C:\TEMP\install.log"

Abwegig, aber warum nicht: wird .net 3.5 benötigt?

Zitat von @DerWoWusste:

Ich habe das nachvollzogen auf einer 2016er Testinstallation - ist bei mir genau so.
msiexec /i paket.msi /qb führt zu "Der Systemadministrator hat Richtlinien erlassen...", während das Selbe auf Win10 einfach geht.
Frag den Entwickler des Paketes, ob es bei ihm auf 2016 Server läuft (vermutlich auch nicht, da meiner jungfräulich ist) und wenn ja, wie.

Okay, danke fürs Testen. Dann frag ich mal beim Hersteller nach.

Zitat von @Inf1d3l:
Oder

msiexec /i paket.msi /qb /L*iew "C:\TEMP\install.log"

Abwegig, aber warum nicht: wird .net 3.5 benötigt?

Da die Installation per einfachem Doppelklick funktioniert, kann ich das eigentlisch ausschließen. Trotzdem habe ich 3.5 mal installiert, leider selbes Ergebnis.
Hier das Log, das aus dem Befehl generiert wird:

MSI (s) (C4:28) [11:52:08:571]: Produkt: Z1GatewayCompanion -- Installation fehlgeschlagen.

MSI (s) (C4:28) [11:52:08:571]: Das Produkt wurde durch Windows Installer installiert. Produktname: Z1GatewayCompanion. Produktversion: 1.1.0. Produktsprache: 0. Hersteller: Zertificon Solutions GmbH. Erfolg- bzw. Fehlerstatus der Installation: 1625.

Information 1625.Die Installation wird durch Systemrichtlinien verhindert. Wenden Sie sich an den Systemadministrator.
\\fs01\deployment\Z1GatewayCompanionPerUserSetup1.1.msi

Danke!
MfG

Zitat von @support-m:
Okay, danke fürs Testen. Dann frag ich mal beim Hersteller nach.

Hi,
Also ich habe beim Hersteller nachgefragt und er behauptet, dass für die Installation Adminrechte benötigt werden (was ich ja quasi schon rausgefunden habe - obwohl die Installation mit einem Doppel-Klick funktioniert und auf einem Windows 10 mit Userrechten installiert die Software auch ordentlich).

Daher die nächste Frage, gibt es eine Möglichkeit, das MSI Programm mit Adminrechten auszurollen? Die Installation sollte weiterhin auf User-Basis sein.

Vielen Dank
MfG

Was macht das Programm denn, dass es pro User installiert werden muss?
Du willst sicherlich nicht deine Nutzer zu Admins machen, damit sie es installieren können.

Zitat von @DerWoWusste:

Was macht das Programm denn, dass es pro User installiert werden muss?
Du willst sicherlich nicht deine Nutzer zu Admins machen, damit sie es installieren können.

Das Programm ist ein Outlook-Plugin. Das Plugin kann "per Klick" einen speziellen X-Header zu der Mail hinzufügen und anhand diesen X-Header-eintrags wird die Mail speziell geroutet. Entweder einfach zum Smarthoster oder zu einem s.g. Messenger, der die sichere Kommunikation mit externen Koop-Partnern ermöglicht.
Und dieser X-Header setzt 3 Registry-Einstellungen voraus, die nach meinen Tests nur auf User-basis gelten. Und außerdem darf nicht jeder User diese Art von Mails verschicken. Es gibt einen ausgewählten Personenkreis. Außerdem spielt auch die Zahl der Lizenzen für diese Mailverfahren eine Rolle.

Nein, ich will auf keinen Fall jeden relevanten User zum Admin machen.
Gibt es denn eine Möglichkeit, mithilfe eines Scripts oder so tempoäre Adminrechte nur für die Installation zu genehmigen?

Danke
MfG

Gibt es denn eine Möglichkeit, mithilfe eines Scripts oder so tempoäre Adminrechte nur für die Installation zu genehmigen?

Nein. Du kannst jedoch MSI Usern per GPO zuweisen, so dass diese von Nichtadmins über den Weg appwiz.cpL installiert werden können (ruf das mal auf, da gibt es einen Bereich "Programme vom Netzwerk installieren, wo das dann auftauchen würde).

Aber warum das Ganze: wenn es nur um die Verteilung von einer Plugindatei und 3 Registryeinträgen geht, dann mach das lieber per Group Policy Preferences.

Bevor ich den Usern erzähle, wie sie appwiz.cpl aufrufen und dort ein Programm installieren, lege ich lieber eine Verknüpfung zu der MSI auf den Desktop der Benutzer und sage, bitte einmal doppelt anklicken, hat den gleichen Effekt. Bei der Installation muss nur ein paar mal auf weiter und am Ende auf ok geklickt werden. Das muss dann halt der Kunde einmal als Dienstanweisung festlegen. Problem ist halt die Menge an Usern und Terminalservern.

Wie Du meinst. Meinen zweiten Vorschlag hast Du verstanden?
Nebenbei: bei mir lässt es sich als User nicht installieren über Doppelklick. Es kommt der selbe Fehler - da es ein frisches System ist, wird es sicherlich bei Dir ebenso wenig funktionieren bei Nichtadmins.

Zitat von @DerWoWusste:

Wie Du meinst. Meinen zweiten Vorschlag hast Du verstanden?
Nebenbei: bei mir lässt es sich als User nicht installieren über Doppelklick. Es kommt der selbe Fehler - da es ein frisches System ist, wird es sicherlich bei Dir ebenso wenig funktionieren bei Nichtadmins.

Ehm, ich bin bisher davon ausgegangen, dass die Installation als normaler User durchläuft. Ich habe noch gar nicht die eigentliche Installation bis zum Ende durchgeführt. Mir hat bisher gereicht, dass der Install-Wizard überhaupt ausgeführt wird ._.
Okay, dann betrifft das trotzdem nur Server 2016. Bei Windows 10 läuft die Installation druch. Danke für den Hinweis!

Wie kann ich die Plugin-Datei per GPP verteilen? Angenommen, der Weg wäre Einstellungen > Windows-Einstellungen > Anwendungen > Neu > Anwendung, kann ich an dieser Stelle keine weiteren Einstellungen vornehmen, es öffnet sich nichts, wenn ich auf Anwendung klicke.
Die Registry-Werte verteile ich damit schon und funktioniert auch. Es fehlt nur noch die Installation des Plugins.

Danke

https://social.technet.microsoft.com/Forums/security/en-US/65f67962-582a ... - muss im Nutzerabteil der GPO gemacht werden, nicht im Computerabteil.

Zitat von @DerWoWusste:

https://social.technet.microsoft.com/Forums/security/en-US/65f67962-582a ... - muss im Nutzerabteil der GPO gemacht werden, nicht im Computerabteil.

Hi, danke, das Kopieren hat soweit funktioniert. Nun liegt die entsprechende .dll mit allen Dateien im korrekten Verzeichnis.

Ich habe jetzt nur die "Daten" des Addins, muss dieses aber noch irgendwie dem Outlook bekannt machen. Ich habe die 2016er Office admx Files im Einsatz, dort gibt es die GPO "Liste der verwalteten Add-Ins", aber die scheint nur zu funktionieren, wenn das Addon quasi schon installiert ist und damit forciert werden kann. Ich nehme an, dass das MSI diese Aufgabe erledigen würde.

Gibt es nun noch die Möglichkeit, das Addon automatisch hinzuzufügen und zu aktivieren? Oder muss ich diese Registry-Einstellungen auch nachbauen...wenn das überhaupt möglich ist, ohne Entwickler vom MSI zu sein.

Vielen Dank!
MfG

Nimm Dir ein Programm, welches anzeigt, was das MSI alles tut: Microsoft Orca oder InstEd
Diese Aktionen dann nachbauen.

Zitat von @DerWoWusste:

Nimm Dir ein Programm, welches anzeigt, was das MSI alles tut: Microsoft Orca oder InstEd
Diese Aktionen dann nachbauen.

Hallo,
ich denke nicht, dass es mir möglich sein wird, die Installation einer Software nach zu bauen.

Könntest du mir bitte noch sagen, wie ich

Zitat von @DerWoWusste:
appwiz.cpl aufrufen und dort ein Programm installieren

korrekt umsetze?
Ich habe die MSI-Software als Benutzer-GPO angelegt und auf die OU eines Test-Users gelegt (getestet sowohl mit veröffentlichen als auch zuweisen). Nach einigen Minuten warten und ab - und anmelden sowie einem gpupdate /force, habe ich als User nicht die Möglichkeit, das MSI über appwiz.cpl zu installieren (es erscheint nicht in der Liste). Ich krieg hier noch die Krise.

Wenn ich die GPO "Immer mit erhöhten Rechten installieren" aktiviere, gilt das dann nur für MSI-Dateien oder generell für Programme?

Danke

ich denke nicht, dass es mir möglich ist, die Installation einer Software nach zu bauen.

Orca würde dir zeigen, welche Dateien kopiert werden und welche Registrywerte gesetzt werden - mehr brauchst Du doch nicht. Hast Du es dir in orca überhaupt angesehen?

Ich habe es getestet mit dem an User assignen - geht.
Nutzer nicht publish oder assign, sondern advanced, setze dann folgenden Haken:

und dann läuft das unter appwiz.cpL:

Hi,
ich bin kein Anwendungsentwickler und kenne mich weder mit MSI-Dateien, noch mit Orca oder IntEd aus. Aber ich habe gestern ein paar Minuten in InstEd und heute ein paar Stunden in Orca verbracht. Die Registry-Einträge habe ich auch gefunden, allerdings ist mir nicht klar, wie z.B. ein Pfad zu %username%\Appdata\local\.....dll generiert wird. Der steht z.b. nirgends zumindest für mich als nicht-programmierer erkennbar drin.
Nurmal so:

CLSID\{971CBEE8-2530-3D7C-A8CC-5EB2020035AC}\InprocServer32
CodeBase
[#_0426DE3ACBF4E3DE2ED77582F6466F18]

Der codeBase Wert erstellt in der "echten" Registry einen vollständige Pfad file:///usw/usf.dll

Wenn ich nach 0426DE3ACBF4E3DE2ED77582F6466F18 suche, finde ich z.b. sowas wie Z1GATE~1.DLL|Z1GatewayCompanion.dll oder Verweise auf andere...Hash-Werte, oder was auch immer diese Werte sind. Für mich nicht nachvollziehbar.

Anyway, ich habe die Richtlinie neu erstellt, aber sie funktioniert nicht.

Mein Vorgehen:
Es existiert eine Sicherheitsgruppe, wo alle User drin sind, die später die Software bekommen sollen, unter anderen der test-User ist drin.
Es existiert eine GPO, die im Bereich Benutzerkonfiguration > Softwareinstellungen die MSI mit deinen o.g. Einstellungen veröffentlicht. Diese Gruppenrichtlinie dürfen Authentifizierte User lesen, und die Sicherheitsgruppe darf diese lesen und übernehmen.
Diese GPO wiederum liegt auf einer OU, in der nur der Test-User ist. Die Richtlinie ist aktiv und sie ist verknüpft. Ein gpresult zeitgt auch, dass die GPO für den test-User angewandt wird.
Trotzdem erscheint das Programm nicht. Auf die Freigabe, wo das MSI liegt, hat "jeder" lesen-Zugriff, NTSF-seitig haben authentifizierte Benutzer Lesen Recht.

Habe ich hier einen Gedankenfehler? Mache ich etwas falsch?

Danke für deine Hilfe und Geduld!
MfG

Du machst alles richtig.
Als User am TS öffne mal cmd und schreibe

gpresult /h %temp%\Resultat.html /scope user /f & %temp%\Resultat.html

Taucht die Anwendung auch im Resultat auf an folgender Stelle (hier englisch):

Zitat von @DerWoWusste:
Als User am TS öffne mal cmd und schreibe

gpresult /h %temp%\Resultat.html /scope user /f & %temp%\Resultat.html

Taucht die Anwendung auch im Resultat auf an folgender Stelle (hier englisch):

Nein, ich sehe diesen Eintrag nicht. Ich sehe nur den Namen des "Angewandten Gruppenrichtlinienobjekts", aber nicht die eigentliche Policy. Ich muss in der GPO selber nicht noch die Sicherheitsgruppe hinzufügen, oder? In den Eigenschaften der veröffentlichten MSI gibt es ja auch noch einen Sicherheits-Reiter.
Hm..wir haben in der Domäne 3 Standorte mit unterschiedlichen Subnetzen. Könnte es theoretisch sein, dass die Anmeldung am Terminalserver bei einem anderen DC nachfragt, der von dort aus dann keinen Zugriff auf den UNC-Pfad hat (weil Firewall/Routing)? Der Terminalserver und der AD sowie der Fileserver mit der Deployment-Freigabe befinden sich im gleichen Subnetz, am gleichen Standort. Die Standorte sind auch ordentlich konfiguriert.

Was könnte das Problem sein?
Danke

MfG

Berechtige jetzt den Testuser einmal direkt mit "GPO lesen und übernehmen" und teste erneut.

Zitat von @DerWoWusste:

Berechtige jetzt den Testuser einmal direkt mit "GPO lesen und übernehmen" und teste erneut.

Grml, funktioniert noch immer nicht.

Ich habe die Geschichte auch inzwischen bei unserer eigenen internen Domäne nachgebaut, dort funktioniert es wunderbar. Ich glaube, ich gebe an der Stelle auf und schaue mir das irgend ein ander mal nochmal an.
Ich habe nun testweise die beiden GPOs "Immer mit priviligierten Rechten ausführen" getestet, und damit funktioniert die Installation zufriedenstellend. Ich denke, ich werde es so umsetzen, dass diese Regel für ein paar Stunden / Tage aktiv ist, bis jeder User auf jedem TS das Plugin installiert hat, und danach deaktiviere ich die GPO wieder. Erfreulicherweise betrifft das nur .MSI-Dateien, .EXE-Dateien brauchen nach wie vor Adminrechte.

Also, vielen Dank und wenn dir oder jemand anderem noch etwas einfällt, gerne darauf hinweisen.

MfG

Ich denke, ich werde es so umsetzen, dass diese Regel für ein paar Stunden / Tage aktiv ist,

Wie Du meinst. Wenn User findig sind, dann scannen Sie den Rechner nach dieser Einstellung und nutzen das gnadenlos aus und übernehmen den Server. Nicht unrealistisch, also Vorsicht!

Oh mein Gott, ich habe die Lösung. Reproduzierbar. Nachdem die Installation der blöden MSI selbst als User mit lokalen Adminrechten nicht funktioniert hat (abgesehen vom "Administrator"-User) und inzwischen Feierabend war, habe ich bis jetzt in meiner Testumgebung das Problem genauer überprüft.

Ich habe bei mir einen Server 2019 installiert, reine Workgroup, keine Domäne, mit dem integrierten Administrator und einem normalen User "Test".

Um mich zusätzlich von Zertificon zu trennen, habe ich die MSI-Installation von VLC genutzt:
Die 64 bit Version von hier:
https://www.vlc.de/download/vlc/msi/

Test-Vorgehen:

Test-User zur Remotedesktopbenutzergruppe hinzugefügt, RDP in Firewall erlaubt
mit Test-User per RDP auf den Workgroup-Server
in normaler CMD msiexec /i c:\test\vlc-3.0.4-win64.msi /lvx install.log

Installation durchgeklickt und am Ende Fehler bekommen, dass die Installation wegen einer administrativen Richtlinie verhindert wird

Test-User abgemeldet
Als Administrator eingelogt und test-User zur lokalen Admingruppe hinzugefügt
mit Test-User per RDP auf den Workgroup-Server
in normaler CMD msiexec /i c:\test\vlc-3.0.4-win64.msi /lvx install.log

Installation durchgeklickt und am Ende Fehler bekommen, dass die Installation wegen einer administrativen Richtlinie verhindert wird (als Administrator!)

Abgemeldet, wieder als Administrator eingelogt und in lokaler GPO die beiden User+Computer Richtlinien gesetzt "Immer mit erhöhten Rechten installieren" unter \Administrative Vorlagen\Windows Komponenten\Windows Installer\
mit Test-User per RDP auf den Workgroup-Server
in normaler CMD msiexec /i c:\test\vlc-3.0.4-win64.msi /lvx install.log
Installation durchgeklickt und am Ende Fehler bekommen, dass die Installation wegen einer administrativen Richtlinie verhindert wird (als Administrator! Sogar mit der GPO für priviligierte Installationen!!!)

An der Stelle habe ich angefangen genauer nach dem Fehler zu suchen und bin hier auf den Hinweis gestoßen:
https://www.borncity.com/blog/2014/02/10/windows-installer-troubleshooti ...
https://docs.microsoft.com/en-us/windows/win32/msi/disablemsi

In der Regsitry war der Eintrag DisableMSI NICHT gesetzt, müsste also laut Microsoft alle Installationen erlauben.

Zitat:

if the policy value is Null, absent, or any number other than 1 or 2 [...]
On Windows XP, Windows Vista, and Windows 7, the Windows Installer is enabled for all applications. All install operations are allowed.

Ich habe den Registry-Eintrag DisableMSI gesetzt und den Wert auf 0 gelassen.

in normaler CMD msiexec /i c:\test\vlc-3.0.4-win64.msi /lvx install.log
Installation durchgeklickt und am Ende war die Installation erfolgreich

WTF?

Ich bin nun hin und habe alle anderen Schritte schrittweise rückgängig gemacht. DisableMSI Registry-Wert wieder gelöscht, Deinstallation von vlc nicht möglich. Eintrag wieder hinzugefügt, Deinstallation wieder möglich.
User abgemeldet, als Admin angemeldet und Test-User wieder zum normalen User gemacht, Installation mit einer normalen cmd unter Test-User nach wie vor möglich!

Das einzige Problem ist in dem Fall nachwievor: Wenn ich die GPO für die erhöhten Rechte entferne, schlägt die Installation wieder fehl, trotz gesetztem DisableMSI Eintrag.
Also für den Fall, dass jemand über diesen Thread stoßt, ich musste "Immer mit erhöhten Rechten installieren" unter \Administrative Vorlagen\Windows Komponenten\Windows Installer aktivieren, sowie "Windows Installer deaktivieren" - aktivieren und auf "Nie" stellen.

Nachdem ich diese Info nun habe, versuche ich morgen nochmal die Softwarebereitstellung mit ebenfalls aktiviertem DisableMSI Wert. Irgendwas scheint Microsoft bei Server 2016 und 2019 (2012 und früher habe ich nicht getestet) anders zu sehen als bei Win 10 Client-PCs. Denn nochmal, auf einem Windows 10 hat die Installation der MSI mit normalen Benutzer-Rechten funktioniert. Nur auf den Server-Versionen hat das nicht funktioniert.

Hoffentlich kann ich damit jemanden helfen.
Danke für die Hilfe.

MfG

Ich habe mittlerweile getestet, dass die Zuweisung per GPO an User auf Server 2016 funktioniert, wenn man es einstellt wie im Bild:

Hattest Du vielleicht im Zuge deiner Tests auch schon gemacht.
Ich rate weiterhin schwer davon ab, die Policy zu setzen, dass MSIs immer mit den Rechten des Installerdienstes installiert werden, aber man könnte es ja temporär erlauben:
Ein immediate scheduled Task läuft bei Anmeldung des Nutzers als Nutzer und triggert einen weiteren Task (der mit hohen Rechten läuft), der den Registrywert setzt, der zur Policy "Immer mit erhöhten Rechten installieren" gehört. Dann kommt msiexec /i dein.msi /qn und danach wird wieder ein Task mit hohen Rechten angetriggert, der den Registrywert entfernt.
Wird funktionieren und löst Dein Problem hinreichend sicher.

So, hier nun die Lösung.

2016er Server Teil der Domäne.
User mit Userrechten.
Registrywert NoMSI auf Null gesetzt - sonst nichts weiter! KEIN "Immer mit erhöhten Rechten installieren" nötig.

Anmeldeskript mit

msiexec /i \\server\share\dein.msi /qb

Zitat von @DerWoWusste:

So, hier nun die Lösung.

2016er Server Teil der Domäne.
User mit Userrechten.
Registrywert NoMSI auf Null gesetzt - sonst nichts weiter! KEIN "Immer mit erhöhten Rechten installieren" nötig.

Anmeldeskript mit

msiexec /i \\server\share\dein.msi /qb

Jap, das wars. Ich habe nicht daran gedacht, den cmd Befehl für die Installation zu nutzen.
Ich habe das Vorgehen bei unserem 2019er Terminalserver mit einem Test-User nachgestellt, die Installation läuft erfolgreich durch.

Aber schon ein komisches Verhalten, oder? Dass man extra diesen Registry-Wert setzen muss? Obwohl das laut Microsoft nicht nötig wäre...

Vielen Dank für die Hilfe!

MfG