7
MSI verteilung via GPO schlägt fehl
Moin zusammen,
ein bisschen Kontext zu dem Problem:
über GitHub Actions habe ich mir einen eigenen RustDesk Client gebaut, dieser wirft ihn mir dann als .exe aus, aus dieser exe habe ich mittels des "--silent-install" Parameters eine .msi gebaut ( Exe to MSI Converter ). Die Msi an sich funktioniert gut, es kommte eine UAC Abfrage, wenn diese ausgeführt wird läuft die Installation silent im Hintergrund.
Nun leider funktioniert die Verteilung dieser MSI nicht wie gewünscht.
Wenn ich es versuche in der GPO über die Softwareverteilung direkt zu verteilen bekomme die folgenden Fehler:
mittels Start-Skript:
funktioniert es allerdings.
Auf die SoftwareDeployment Freigabe hat "Jeder" Zugriff, andere msi Dateien wie Chrome oder Firefox werden auch problemlos installiert, jedoch hapert es an dieser msi.
Ich würde es am liebsten alles über die eingebaute Softwareverteilung managen und nicht zusätzlich Skripte verwenden.
Grüße
Florian
ein bisschen Kontext zu dem Problem:
über GitHub Actions habe ich mir einen eigenen RustDesk Client gebaut, dieser wirft ihn mir dann als .exe aus, aus dieser exe habe ich mittels des "--silent-install" Parameters eine .msi gebaut ( Exe to MSI Converter ). Die Msi an sich funktioniert gut, es kommte eine UAC Abfrage, wenn diese ausgeführt wird läuft die Installation silent im Hintergrund.
Nun leider funktioniert die Verteilung dieser MSI nicht wie gewünscht.
Wenn ich es versuche in der GPO über die Softwareverteilung direkt zu verteilen bekomme die folgenden Fehler:
start cmd /c start \\file\SoftwareDeployment\Rustdesk\rustdesk-1.2.4-x86_64.msi -qnfunktioniert es allerdings.
Auf die SoftwareDeployment Freigabe hat "Jeder" Zugriff, andere msi Dateien wie Chrome oder Firefox werden auch problemlos installiert, jedoch hapert es an dieser msi.
Ich würde es am liebsten alles über die eingebaute Softwareverteilung managen und nicht zusätzlich Skripte verwenden.
Grüße
Florian
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 53203631090
Url: https://administrator.de/contentid/53203631090
Printed on: May 2, 2024 at 10:05 o'clock
7 Comments
Latest comment
Deine Aussage ist etwas durcheinander:
1) Entweder startest du MSI-Installationen direkt via Computerkonfiguration -> Richtlinien -> Softwareeinstellungen -> Softwareinstallationen
2) Oder über ein Startskript Batch/Powershell.
Hier startet man MSI-Installationen normalerweise aber immer mit
1) Entweder startest du MSI-Installationen direkt via Computerkonfiguration -> Richtlinien -> Softwareeinstellungen -> Softwareinstallationen
2) Oder über ein Startskript Batch/Powershell.
Hier startet man MSI-Installationen normalerweise aber immer mit
msiexec /i <PfadzumPaket><Parameter> 
Hi.
Die GPO triggert die Installation mit dem Systemkonto. Kann dieses nicht auf den Pfad rauf (z.B. hat man ein Netzlaufwerk angegeben, dass nutzergebunden ist), dann kommt Fehler 1603 wie bei Dir.
->Teste bitte die Installation manuell als Systemkonto auf diesem PC.
->dazu psexec.exe von Microsoft runterladen (pstools entpacken, da ist es drin), dann auf einer elevated command line
Auf der sich nun öffnenden Kommandozeile kannst Du den Befehl
msiexec /i \\server\share\dein.msi /quiet
starten und schauen, was passiert.
Die GPO triggert die Installation mit dem Systemkonto. Kann dieses nicht auf den Pfad rauf (z.B. hat man ein Netzlaufwerk angegeben, dass nutzergebunden ist), dann kommt Fehler 1603 wie bei Dir.
->Teste bitte die Installation manuell als Systemkonto auf diesem PC.
->dazu psexec.exe von Microsoft runterladen (pstools entpacken, da ist es drin), dann auf einer elevated command line
psexec -si cmdmsiexec /i \\server\share\dein.msi /quiet
starten und schauen, was passiert.
1) Entweder startest du MSI-Installationen direkt via Computerkonfiguration -> Richtlinien -> Softwareeinstellungen -> Softwareinstallationen
Wie gesagt, wirft den oben aufgeführten Fehler aus.Hier startet man MSI-Installationen normalerweise aber immer mit
Habe es umgeändert sodass das Skript diesen Code verwendet auch wenn das Ergebnis das Selbige ist, funktioniert ja trotzdem mitmsiexec /i <PfadzumPaket><Parameter> start cmd /c start \\file\SoftwareDeployment\Rustdesk\rustdesk-1.2.4-x86_64.msi -qn
starten und schauen, was passiert.
Berechtigungen habe ich soweit gegeben, auch an die Domänencomputer. Die Fehlermeldungen mit %%1603 bestehen leider weiterhin.Über das SYSTEM Konto wird die .msi über psexec Problemlos ausgeführt.
Du könntest jetzt den Plan ändern und einen geplanten immediate Task deployen, der als System-Konto läuft. Die Ausführung auf nur einmalig stellen. Das wird funktionieren und du musst nicht mehr ergründen, woran es liegt. Man verliert dabei jedoch die Möglichkeit, bequem automatisch zu deinstallieren oder upzugraden, aber auch das könnten Tasks erledigen.
Man verliert dabei jedoch die Möglichkeit, bequem automatisch zu deinstallieren oder upzugraden, aber auch das könnten Tasks erledigen.
Das ist leider der Punkt der mich davon abhält.Danke für die Denkanstöße.
Ok, dann weiter im Text.
Prüfe bite, ob das Installationsproblem auch bei Neustarts passiert (im Gegensatz zu herunterfahren und wieder einschalten). Teste auch mehrere Computer.
Prüfe bite, ob das Installationsproblem auch bei Neustarts passiert (im Gegensatz zu herunterfahren und wieder einschalten). Teste auch mehrere Computer.
