6
Softwareinstallation via GPO
Hallo nochmal alle zusammen. Ich habe mal wieder ein Problem bezüglich einer Installation. Wir haben nur Windows XP Rechner im Netz und ich muss eine Installation unserer Warenwirtschaft durchführen. Eine MSI Installation fällt flach, die funktioniert nicht.
Nun möchte ich die Installation per Runas Script durchführen und dieses Script beim Starten oder Herunterfahren des Rechners ausführen lassen.
Ich habe im Netlogon Verzeichnis unseres DCs die benötigten Dateien hinterlegt. Wenn ich das Script manuell ausführe, funktioniert es.
Nun lege ich eine Policy an (Test), Computerkonfig, Richtlinien, Windowseinstellungen, Scripts und hinterlege dort beim Starten/Herunterfahren (je nach dem) die install.bat, die den Prozess auslösen soll. Nichts passiert.
Die OU passt, Rechner und Benutzer sind der OU zugeordnet.
Wenn ich ein Richtlinienergebnis modelliere, erhalte ich einen Fehler "Unbekannter Fehler bei der Zusammenstellung von Informationen für Ordner für diese Erweiterung. Details: Nicht gefunden".
Komischerweise erhalten ich diesen Fehler auch bei unserem "normalen" Benutzeranmeldeskript. Dieses funktioniert allerdings trotz dieser Fehlermeldung.
Hätte ich dochmal die Finger von den GPOs gelassen
Nun möchte ich die Installation per Runas Script durchführen und dieses Script beim Starten oder Herunterfahren des Rechners ausführen lassen.
Ich habe im Netlogon Verzeichnis unseres DCs die benötigten Dateien hinterlegt. Wenn ich das Script manuell ausführe, funktioniert es.
Nun lege ich eine Policy an (Test), Computerkonfig, Richtlinien, Windowseinstellungen, Scripts und hinterlege dort beim Starten/Herunterfahren (je nach dem) die install.bat, die den Prozess auslösen soll. Nichts passiert.
Die OU passt, Rechner und Benutzer sind der OU zugeordnet.
Wenn ich ein Richtlinienergebnis modelliere, erhalte ich einen Fehler "Unbekannter Fehler bei der Zusammenstellung von Informationen für Ordner für diese Erweiterung. Details: Nicht gefunden".
Komischerweise erhalten ich diesen Fehler auch bei unserem "normalen" Benutzeranmeldeskript. Dieses funktioniert allerdings trotz dieser Fehlermeldung.
Hätte ich dochmal die Finger von den GPOs gelassen
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 175909
Url: https://administrator.de/forum/softwareinstallation-via-gpo-175909.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
6 Kommentare
Neuester Kommentar
Hi.
Knüpf doch mal ordentlich an MSI Installationen per GPO an: warum fällt das flach? Dein Problem hätten wir in den Griff bekommen, wenn Du mitgemacht hättest.
Zu diesem würde ich erst kommen, wenn das alte beendet ist aus gutem Grund.
Zu diesem Problem fehlen einige Infos:
-warum runas und nicht mit Systemrechten?
-ist die install.bat silent?
-stell sicher, ob das Startskript die Batch anfässt, oder nicht (Überwachungsrichtlinie am Server anschalten usw.) - mit Sicherheit wird sie angefasst. Du könntest Startskripte auch sichtbar ausführen lassen (konfigurierbar per GPO).
Knüpf doch mal ordentlich an MSI Installationen per GPO an: warum fällt das flach? Dein Problem hätten wir in den Griff bekommen, wenn Du mitgemacht hättest.
Zu diesem würde ich erst kommen, wenn das alte beendet ist aus gutem Grund.
Zu diesem Problem fehlen einige Infos:
-warum runas und nicht mit Systemrechten?
-ist die install.bat silent?
-stell sicher, ob das Startskript die Batch anfässt, oder nicht (Überwachungsrichtlinie am Server anschalten usw.) - mit Sicherheit wird sie angefasst. Du könntest Startskripte auch sichtbar ausführen lassen (konfigurierbar per GPO).
Zitat von @DerWoWusste:
Hi.
Knüpf doch mal ordentlich an MSI Installationen per GPO an: warum fällt das flach? Dein
Problem hätten wir in den Griff bekommen, wenn Du mitgemacht hättest.
Zu diesem würde ich erst kommen, wenn das alte beendet ist aus gutem Grund.
Hi.
Knüpf doch mal ordentlich an MSI Installationen per GPO an: warum fällt das flach? Dein
Problem hätten wir in den Griff bekommen, wenn Du mitgemacht hättest.
Zu diesem würde ich erst kommen, wenn das alte beendet ist aus gutem Grund.
Sorry aber das hat gar nichts mit dem Problem in diesem Thread zu tun. Bei o. g. Problem läuft die MSI, das Programm läuft nach der Installation und alles ist toll. Was nach wie vor bei diesem Thema offen ist, ist die Tatsache, warum denn diese Installation erst startet, nachdem jeder Client mindestens zweimal gestartet wird. Nicht mehr, nicht weniger.
Bei diesem Thema hier läuft die MSI Installation, das Programm funktioniert aber nicht so, wie es sein soll und bringt eine programmspezifische Fehlermeldung. Wird die Installation mittels der Setup.exe aber auf herkömmlichen Wege durchgeführt, funktioniert es einwandfrei. Somit fällt der Weg über eine MSI flach und ich muss nun einen Weg finden, um über die manuelle Installation von 84 Clients herum zu kommen
Zu diesem Problem fehlen einige Infos:
-warum runas und nicht mit Systemrechten?
Ich habe mit Runas schon bei der Vorgängerversion dieser Applikation gearbeitet und diese über unser Login Skript mittels Runas verteilt. Das war aber etwas lästig, da die Installation natürlich nach jedem Login eines Users angestossen wurde und durchlief - egal, ob das Programm auf diesem Client schon installiert war oder nicht.
Kann ich denn die Setup.exe direkt über die Computerkonfiguration aufrufen und wird die dann automatisch mit System Berechtigung installiert?? Dann kann ich mir natürlich die Runas-Sache sparen.
BTW - die Setup.exe hat leider keinerlei Möglichkeiten Attribute wie Silent Installation zu setzen.
-ist die install.bat silent?
Die Runas Datei wird Silent aufgerufen.
-stell sicher, ob das Startskript die Batch anfässt, oder nicht (Überwachungsrichtlinie am Server anschalten usw.) - mit
Sicherheit wird sie angefasst. Du könntest Startskripte auch sichtbar ausführen lassen (konfigurierbar per GPO).
Sicherheit wird sie angefasst. Du könntest Startskripte auch sichtbar ausführen lassen (konfigurierbar per GPO).
Wenn Sie angefasst werden würde, bekäme ich doch zumindest die Installationsdialoge angezeigt, in denen ich die Installation dann manuell weiter führen müsste. Die Batchdatei macht eigentlich nichts anderes (oder sie soll es zumindest), als die Setup.exe aufrufen.
Wie erwähnt, bei dem Richtlinienergebnis kommt folgender Fehler raus
"Unbekannter Fehler bei der Zusammenstellung von Informationen für Ordner für diese Erweiterung. Details: Nicht gefunden"
Sorry, aber ich fange erst mit den GPOs an und besitze noch keinen großen Erfahrungsschatz diesbezgl.
VG
Screeper
PS: Ich habe festgestellt, dass in der Ereignisanzeige des Clients die Meldung erscheint:
"Folgendes Skript konnte nicht ausgeführt werden: \\53.xxx.xxx.xxx\msi\GamisV16\install.bat. Zugriff verweigert".
Das verwirrt mich etwas, da das Verzeichnis definitiv für jedes Domänenmitglied voll zugriffsfähig ist. Wenn ich im selben Moment die Batchdatei manuell an genau diesem Ort aufrufe, funktioniert sie....?!?!
Okeydokey, da haben wir doch Punkte um anzusetzen.
Wenn die Anwendung als MSI vorliegt, dann ist doch zu unterstellen, dass der Hersteller eine Verteilung vorsieht. Wende Dich an deren Support mit der Fehlermeldung.
MSI-Pakete werden über die GPO-Softwareverteilung mit dem Systemkonto installiert - klar, es ist ja noch kein Nutzer angemeldet. Schlägt das fehl, würde eine Installation per Startskript vermutlich ebenso fehlschlagen, mit einiger Sicherheit.
Wenn die setup.exe keine Silentschalter hat, solltest Du zumindest noch einmal bei appdeploy.com in der package Knowledgebase reinschauen, vielleicht ist das Paket bekannt.
Wenn nicht, versuch es mit repackaging, d.h. mach einen before-Snapshot eines Test-PCs mit wininstall LE, installiere die Software manuell und fertige einen after-snapshot an. Wininstall LE 10 macht aus der Differenz ein verteilbares MSI, vielleicht klappt es damit http://downloads.ondemandsoftware.com/Download/Installs/Wininstall10102 ... Freeware!
Wenn die Anwendung als MSI vorliegt, dann ist doch zu unterstellen, dass der Hersteller eine Verteilung vorsieht. Wende Dich an deren Support mit der Fehlermeldung.
MSI-Pakete werden über die GPO-Softwareverteilung mit dem Systemkonto installiert - klar, es ist ja noch kein Nutzer angemeldet. Schlägt das fehl, würde eine Installation per Startskript vermutlich ebenso fehlschlagen, mit einiger Sicherheit.
Wenn Sie angefasst werden würde, bekäme ich doch zumindest die Installationsdialoge angezeigt, in denen ich die Installation dann manuell weiter führen müsste
Nein. Das Startskript läuft im Systemkontext und gewollt per default unsichtbar ab. Die Dialoge bleiben somit nicht eingreifbar.Wenn die setup.exe keine Silentschalter hat, solltest Du zumindest noch einmal bei appdeploy.com in der package Knowledgebase reinschauen, vielleicht ist das Paket bekannt.
Wenn nicht, versuch es mit repackaging, d.h. mach einen before-Snapshot eines Test-PCs mit wininstall LE, installiere die Software manuell und fertige einen after-snapshot an. Wininstall LE 10 macht aus der Differenz ein verteilbares MSI, vielleicht klappt es damit http://downloads.ondemandsoftware.com/Download/Installs/Wininstall10102 ... Freeware!
Da habe ich mich etwas missverständlich ausgedrückt. Das Package lag nicht vom Hersteller als MSI vor, das habe ich selbst mit WinInstall LE erstellt. Das funktionierte dann aber nicht - wie erwähnt. Also die Installation lief aber das Resultat war fehlerhaft.
Weiterhin wird die Setup-Datei nicht bekannt sein, da sie nahezu direkt von unserem Markenhersteller kommt. Das ist also keine öffentliche, frei zugängliche oder käuflich erwerbbare Software.
Hab meinen Beitrag von eben nochmal editiert. Da haben wir uns überschnitten:
PS: Ich habe festgestellt, dass in der Ereignisanzeige des Clients die Meldung erscheint:
"Folgendes Skript konnte nicht ausgeführt werden: \\53.xxx.xxx.xxx\msi\GamisV16\install.bat. Zugriff verweigert".
Das verwirrt mich etwas, da das Verzeichnis definitiv für jedes Domänenmitglied voll zugriffsfähig ist. Wenn ich im selben Moment die Batchdatei manuell an genau diesem Ort aufrufe, funktioniert sie....?!?!
Weiterhin wird die Setup-Datei nicht bekannt sein, da sie nahezu direkt von unserem Markenhersteller kommt. Das ist also keine öffentliche, frei zugängliche oder käuflich erwerbbare Software.
Hab meinen Beitrag von eben nochmal editiert. Da haben wir uns überschnitten:
PS: Ich habe festgestellt, dass in der Ereignisanzeige des Clients die Meldung erscheint:
"Folgendes Skript konnte nicht ausgeführt werden: \\53.xxx.xxx.xxx\msi\GamisV16\install.bat. Zugriff verweigert".
Das verwirrt mich etwas, da das Verzeichnis definitiv für jedes Domänenmitglied voll zugriffsfähig ist. Wenn ich im selben Moment die Batchdatei manuell an genau diesem Ort aufrufe, funktioniert sie....?!?!
Das verwirrt mich etwas, da das Verzeichnis definitiv für jedes Domänenmitglied...
Gib an, was in der ACL steht. "Jede Domänenmitglied" ist ungenau. Es muss für "authentifizierte Benutzer" zugänglich sein, die umfassen auch die Gruppe der Domänencomputer (=Systemkonten). Wenn Du manuell aufrufst, handelst DU und nicht das Systemkonto wie im Startskript.Frag Euren Hersteller, wie ein Deployment aussehen soll. Vielleicht sieht er doch etwas vor.
Zitat von @DerWoWusste:
Es muss für "authentifizierte
Benutzer" zugänglich sein, die umfassen auch die Gruppe der Domänencomputer (=Systemkonten).
Es muss für "authentifizierte
Benutzer" zugänglich sein, die umfassen auch die Gruppe der Domänencomputer (=Systemkonten).
Genau das steht drin.
EDIT: Wenn ich die install.bat in die Benutzerkonfig eintrage und als Startskript ausführen lasse, startet die Installation. In der Computerkonfig passiert nichts.
Frag Euren Hersteller, wie ein Deployment aussehen soll. Vielleicht sieht er doch etwas vor.
Naja versuchen kann man es mal, obwohl ich da schwarz sehe. Ohne den Hersteller nennen zu wollen, ist er in Sachen EDV nicht immer "Vorreiter"
Immerhin können wir schon Ende nächsten Jahres damit rechnen, dass alle seine Programmmodule auf Windows 7 lauffähig sein werden :-S
Habe nachher noch ein anderes Modul "EKS" zu aktualisieren. Hoffe mal, dass dieses dann als MSI Paket läuft. Anschl. muss ich mich weiter um dieses hier kümmern :-S
