none
Softwareinstallation via GPO RRS feed

  • Frage

  • Hallo zusammen,

    ich habe folgendes Problem bzw. Frage:

    Ich habe ein .MSI File welches ich gern per GPO verteilen möchte. Wenn ich das File lokal mit den Parametern "File.msi /quiet /passive /norestart" ausführe, dann klappt das auch ohne Probleme.

    Unter Server 2008 R2 war es mir so, als gäbe es, wenn man das File verteilen möchte noch die Möglichkeit Argumente mitzugeben. Nun haben wir hier Server 2012 R2 und da geht es (offenbar) nicht mehr.

    Das File ist original vom Hersteller. Clients sind Windows 7 Pro. Permissions für Share und NTFS sind für Authenticated Users und Domain Computers lesend gesetzt. Wenn der PC sich hochfährt steht auch ganz kurz da "File" wird installiert, aber es springt sofort weiter.

    Kann mir evtl. jemand weiterhelfen wie ich das File verteilen kann?

    Vielen Dank!

    Freundliche Grüße

    Sandro

    Donnerstag, 30. Oktober 2014 08:18

Antworten

  • Nein, Gruppenrichtlinien werden unter dem SYSTEM-Konto ausgeführt, das sogar noch mächtiger ist als der lokale Admin. :-)

    D.h. Du müsstest mal die Berechtigungen auf dieses Verzeichnis prüfen, ob SYSTEM hier evtl. keinen (Voll-)Zugriff hat. Die Berechtigungen könntest Du dann ggf. ebenfalls per GPO (per Skript) anpassen, sofern die falsch sind.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    • Als Antwort markiert SandroReiter Donnerstag, 30. Oktober 2014 10:58
    Donnerstag, 30. Oktober 2014 09:09

Alle Antworten

  • Hi Sandro,

    es war noch nie möglich, Installationsparameter in einer GPO mitzugeben (außer mittels einer MST-Antwortdatei, die bezieht sich aber auf das Setup selbst).

    Macht aber nichts, weil die Softwareinstallationsrichtlinie jedes eingefügte MSI-Paket automatisch mit den Parametern /quiet und /norestart ausführt. D.h. Du musst hier nichts weiter einstellen, um Dein MSI-Paket zu verteilen.

    Nebenbei noch zur Info: es ist entweder /quiet oder /passive zu verwenden, nicht beides zusammen. /quiet = nichts wird angezeigt, /passive = es wird ein Fortschrittsbalken angezeigt.

    Im Ereignisprotokoll werden unter "Anwendung" und "System" fehlerhafte Verarbeitungen protokolliert, schau also am Besten mal da nach, wenn es nicht geht. Rein vom Procedere her sollte es mit Deinen Einstellungen gehen.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Donnerstag, 30. Oktober 2014 08:23
  • Hallo Ben,

    vielen Dank für Deine Antwort!

    Im Log des Clients finden sich unter Anwendung folgender Eintrag:

    "Product: SOFTWARE-- Error 1303. The installer has insufficient privileges to access this directory: C:\Program Files (x86)\HERSTELLER.  The installation cannot continue.  Log on as administrator or contact your system administrator."

    unter System steht:

    "Die Installation der Anwendung SOFTWARE der Richtlinie SOFTWARE-Installation ist fehlgeschlagen. Fehler: %%1612"

    _____________

    Liegt das evtl. daran das der lokale Admin deaktiviert ist, welcher die "Root"-Perms zur Verfügung stellt?


    • Bearbeitet SandroReiter Donnerstag, 30. Oktober 2014 08:34
    Donnerstag, 30. Oktober 2014 08:28
  • Nein, Gruppenrichtlinien werden unter dem SYSTEM-Konto ausgeführt, das sogar noch mächtiger ist als der lokale Admin. :-)

    D.h. Du müsstest mal die Berechtigungen auf dieses Verzeichnis prüfen, ob SYSTEM hier evtl. keinen (Voll-)Zugriff hat. Die Berechtigungen könntest Du dann ggf. ebenfalls per GPO (per Skript) anpassen, sofern die falsch sind.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    • Als Antwort markiert SandroReiter Donnerstag, 30. Oktober 2014 10:58
    Donnerstag, 30. Oktober 2014 09:09
  • > Unter Server 2008 R2 war es mir so, als gäbe es, wenn man das File
    > verteilen möchte noch die Möglichkeit Argumente mitzugeben. Nun haben
    > wir hier Server 2012 R2 und da geht es (offenbar) nicht mehr.
     
    Nee, gab's noch nie :)
     
    > Das File ist original vom Hersteller. Clients sind Windows 7 Pro.
    > Permissions für Share und NTFS sind für Authenticated Users und Domain
    > Computers lesend gesetzt. Wenn der PC sich hochfährt steht auch ganz
    > kurz da "File" wird installiert, aber es springt sofort weiter.
     
    Dem Computer zugewiesen oder dem Benutzer?
     
    BTW: ERROR_INSTALL_SOURCE_ABSENT      1612     The installation source for
    this product is not available. Verify that the source exists and that
    you can access it.
     
    Wenn ich das mit dem 1303 kombiniere, bin ich völlig ratlos... Aktiviere
    mal das Installer-Logging: http://gpsearch.azurewebsites.net/#1985 ->
    "voicewarmup". Das Log findest dann im %TEMP% von System (normalerweise
    c:\windows\temp) als MSIxxxx.log.
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Donnerstag, 30. Oktober 2014 09:48
    Beantworter
  • Also ich hatte das so versucht zu Lösen:

    Freigabe auf E:\Ordner angelegt. Auf diese Freigabe habe ich Domain Computers und Authenticated Users nur in den Share Permissions hinterlegt. Anschließend habe ich in einem darunterliegenden Ordner (E:\Ordner\installs) die NTFS Berechtigung auf Lesen und Ausführen gesetzt. So hat das ganze nicht funktioniert. Nun habe ich eine Extra-Freigabe install$ angelegt und von dort an die Berechtigungen für Domain Computers und Authenticated Users vererbt - so funktioniert es nun.

    Nebenbei ist mir noch aufgefallen das ich bei der GPO selbst vergessen hatte, den Sicherheitsfilter auch für Domain Computers zu berechtigen - evtl. wäre es dann mit Szenario 1 auch schon erfolgreich gewesen.

    Ich danke Euch für Eure Zeit und Mühe. Auch bei einer so kleinen Aufgabe habe ich wieder viele neue Erkenntnisse gewonnen :)

    Donnerstag, 30. Oktober 2014 10:57