einwegglas
Goto Top

Abändern des UNC-Pfades von verteilter Software

Windows Server 2003, Softwareverteilung via Gruppenrichtlinien

Diese Anleitung richtet sich in erster Linie an Administartoren, die Software über Gruppenrichtlinien verteilen.

Wer von uns kennt das nicht - man legt Ordner für die Softwareverteilung an, verteilt die Software und stellt dann fest, dass im Laufe der Zeit immer mehr Ordner hinzukommen und die Übersichtlichkeit nicht mehr gegeben ist.

Wenn man jetzt einfach die Ordner verschiebt oder zusammenfasst, kann die Software nicht mehr geändert, aktualisiert oder entfernt werden, da die UNC-Pfade nicht mehr stimmen.

Jetzt hat man 2 Möglichkeiten.

1. Man löscht die alten Pakete in der Gruppenrichtlinie und erstellt sie wieder neu, was jedoch den Nachteil hat, das die Software wieder neu verteilt wird. Spätestens nach der 3. Installation von Office-Paketen klingelt das Telefon beim Admin Sturm und man wird mit Fragen bombardiert, warum schon wieder was installiert wird. Sicherlich kann man nun den genervten Benutzer mit ruhiger Stimme erklären, dass es sich ja nur um Sicherheitsupdates handle. Aber welcher Administrator sucht schon gern das Gespräch mit dem Anwender, besonders wenn es sich beim Anrufer um den Chef handelt.

Aus diesem Grund will ich hier mal eine 2. Möglichkeit vorstellen, die ich eher zufällig beim recherchieren eines vollkommen anderen Problems gefunden habe.

Diese Möglichkeit ist nicht von Microsoft supported, stattdessen wird auf die Verwendung von DFS hingewiesen.

back-to-topSchritt 1 - Dateien erstellen:
  1. man erstellt ein neues Gruppenrichtlinienobjekt (man könnte auch das alte nehmen)
  2. jetzt erstellt man das Softwarepaket mit allen Einstellungen
  3. die unter Sysvoll\domain\Policies\GUID-der-neuen-Gruppenrichtlinie\Machine oder User\Applications erstellte aas-Datei in den alten Gruppenrichtlinienordner kopieren, in dem die ursprüngliche Sofware mit altem UNC-Pfad liegt
  4. kopieren des alten Namens
  5. löschen oder umbenennen der alten aas-Datei
  6. umbenennen der neuen Datei mit dem alten Namen

back-to-topSchritt 2 - Eigenschaften und Attribute ändern
  1. zunächst startet man das adsiedit Snap-In mit "adsiedt.msc" (Hinweis: sollte das Snap-In nicht starten, muss es mit "regsvr32 adsiedt.dll" registriert werden)
  2. öffnen des Schlüssels DC=domain,DC=local\CN=System\CN=Policies\GUID-der-alten-Gruppenrichtlinie\Machine oder User\Class Store\Packages
  3. in der Detailansicht befinden sich alle Softwarepakete, die von dieser Gruppenrichtlinie verteilt werden
  4. Hinweis die Namen der Pakete stimmen mitunter nicht mit denen aus dem Gruppenrichtlinienordner im SYSVOL-Verzeichnis überein. Hier muss man dann ein wenig suchen face-wink
  5. hat man das entsprechende Objekt gefunden, kann man mit einem Doppelklick die Eigenschaften bearbeiten
  6. in der Attributenliste sucht man den Eintrag "msiFileList" und ändert diesen für alle Einträge (msi- und mst-Datei) auf den neuen UNC-Pfad ab

db1b39c84567dad5138514c07b9f83a0-unbenannt


back-to-topSchritt 3 - Ersetzen der Dateien auf dem Client
  1. auf den Clients muss natürlich noch die alte aas-Datei mit der neuen aus dem SYSVOL-Verzeichnis ersetzt werden
  2. hier bietet sich ein Startskript (!!Kein Anmeldeskript!!) an, da man für das Ersetzen Administratorrechte benötigt
  3. im Ordner "%windir%\system32\appmgmt\MACHINE" die entsprechende aas-Datei ersetzen

back-to-topSchritt 4 - Änderung der Registry auf dem Client
Schlüssel Wert-Name Wert-Wert
HKCR\Installer\Products\GUID der Software \SourceList\Net1neuer UNC-Pfad
HKLM\Software\Classes\Installer\Products\GUID der Software \SourceList\Net1neuer UNC-Pfad
HKLM\Software\Microsoft\CurrentVersion\Uninstall\GUID der Software InstallSourceneuer UNC-Pfad

back-to-topSchritt 5 - Hoffen, dass beim nächsten Update die Software entfernt wird

Hoffe, es ist so halbwegs verständlich.

Gruß EWG

Content-Key: 67378

Url: https://administrator.de/contentid/67378

Printed on: April 19, 2024 at 21:04 o'clock