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.
Hoffe, es ist so halbwegs verständlich.
Gruß EWG
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.
Schritt 1 - Dateien erstellen:
- man erstellt ein neues Gruppenrichtlinienobjekt (man könnte auch das alte nehmen)
- jetzt erstellt man das Softwarepaket mit allen Einstellungen
- 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
- kopieren des alten Namens
- löschen oder umbenennen der alten aas-Datei
- umbenennen der neuen Datei mit dem alten Namen
Schritt 2 - Eigenschaften und Attribute ändern
- 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)
- öffnen des Schlüssels DC=domain,DC=local\CN=System\CN=Policies\GUID-der-alten-Gruppenrichtlinie\Machine oder User\Class Store\Packages
- in der Detailansicht befinden sich alle Softwarepakete, die von dieser Gruppenrichtlinie verteilt werden
- Hinweis die Namen der Pakete stimmen mitunter nicht mit denen aus dem Gruppenrichtlinienordner im SYSVOL-Verzeichnis überein. Hier muss man dann ein wenig suchen
- hat man das entsprechende Objekt gefunden, kann man mit einem Doppelklick die Eigenschaften bearbeiten
- 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
Schritt 3 - Ersetzen der Dateien auf dem Client
- auf den Clients muss natürlich noch die alte aas-Datei mit der neuen aus dem SYSVOL-Verzeichnis ersetzt werden
- hier bietet sich ein Startskript (!!Kein Anmeldeskript!!) an, da man für das Ersetzen Administratorrechte benötigt
- im Ordner "%windir%\system32\appmgmt\MACHINE" die entsprechende aas-Datei ersetzen
Schritt 4 - Änderung der Registry auf dem Client
Schlüssel | Wert-Name | Wert-Wert |
---|---|---|
HKCR\Installer\Products\GUID der Software \SourceList\Net | 1 | neuer UNC-Pfad |
HKLM\Software\Classes\Installer\Products\GUID der Software \SourceList\Net | 1 | neuer UNC-Pfad |
HKLM\Software\Microsoft\CurrentVersion\Uninstall\GUID der Software | InstallSource | neuer UNC-Pfad |
Schritt 5 - Hoffen, dass beim nächsten Update die Software entfernt wird
Hoffe, es ist so halbwegs verständlich.
Gruß EWG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 67378
Url: https://administrator.de/contentid/67378
Ausgedruckt am: 22.11.2024 um 22:11 Uhr