Änderung Pfad MSI (Softwareverteilung)
Dennis Bistron
es ist bei uns nun an der Zeit, daß die MSI-Pakete, die via GPO verteilt
werden von ServerA nach ServerB umziehen. Nun ergibt sich das Problem, daß
beim entfernen des Paketes unter dem alten Pfad (\\ServerA\Software\xyz.msi)
und hinzufügen des Paketes unter dem neuen Pfad (\\ServerB\Software\xyz.msi)
die Clients die Software erneut installieren.
Eine Änderung des Pfades eines Paketes scheint ja nicht möglich zu sein,
also ist das entfernen und hinzufügen so wie ich das sehe die einzige
Möglichkeit... aber so wie sich das ganze darstellt ist es doch auf gut
deutsch gesagt große Sch...e. Es kann doch nicht sein, daß die Software nur
wegen Verlagerung der MSI-Pakete neu installiert werden MUSS, oder???
Um das Problem zukünftig zu umgehen habe ich auch noch ein paar kleine Tests
mit DNS-Alias-Namen (CNAME) und IP-Adressen in der Pfadangabe getätigt, aber
alles ohne Erfolg (Clients konnten lt. Eventlog nicht auf die
Installationsquelle zugreifen). Es scheint als müßte der "echte" Servername
in der Pfadangabe hinterlegt sein. Ist das wirklich so?
Ich denke mal, daß wir hier nicht die einzigen sind, die Pakete von einem
auf nen anderen Server verlagern - daher hoffe ich einfach mal, daß es eine
zufriedenstellende Lösung gibt :-)
Also vielen Dank schonmal für die hilfreichen Antworten...
MfG
Dennis
Frank Röder
sicherlich mit dem Deaktivieren des "StrictNameChecking" abstellen.
http://support.microsoft.com/default.aspx?scid=kb;en-us;281308
--
Viele Grüße
Frank Röder
"Ex oriente lux"
Dennis Bistron
> Eine Lösung wäre hier DFS. Das Problem mit dem Aliasnamen kannst Du
> sicherlich mit dem Deaktivieren des "StrictNameChecking" abstellen.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;281308
>
Mit DFS habe ich leider bisher keine guten Erfahrungen machen dürfen, aber
wenn es nicht anders geht würde ich mich da vllt nocheinmal rantrauen.
Das Problem mit dem Alias tritt trotz deaktiviertem "StrictNameChecking"
auf. Auch wenn ich Anmeldeskripte auf Computerebene verteile wird der
Alias-Name nicht akzeptiert. Auf Benutzerebene ist es kein Problem...
Dennis Bistron
> auf. Auch wenn ich Anmeldeskripte auf Computerebene verteile wird der
> Alias-Name nicht akzeptiert. Auf Benutzerebene ist es kein Problem...
hier noch die Meldungen aus dem Eventlog der Clients bei Verwendung des Alias:
Ereignistyp: Fehler
Ereignisquelle: Application Management
Ereigniskategorie: Keine
Ereigniskennung: 102
Datum: 17.01.2006
Zeit: 10:16:56
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: TEST1
Beschreibung:
Die Installation der Anwendung Microsoft Office 2000 SR-1 Standard der
Richtlinie Kopie von Installation Microsoft Office 2000 Standard ist
fehlgeschlagen. Fehler: Die Installationsquelle für dieses Produkt ist nicht
verfügbar. Stellen Sie sicher, dass die Quelle vorhanden ist und Sie Zugriff
darauf haben.
Ereignistyp: Fehler
Ereignisquelle: Application Management
Ereigniskategorie: Keine
Ereigniskennung: 108
Datum: 17.01.2006
Zeit: 10:16:59
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: TEST1
Beschreibung:
Die Änderungen an den Softwareinstallationseinstellungen wurden nicht
angewendet. Änderungen an der Software konnten nicht übernommen werden. Ein
vorheriger Protokolleintrag mit Einzelheiten sollte vorhanden sein. Fehler:
Die Installationsquelle für dieses Produkt ist nicht verfügbar. Stellen Sie
sicher, dass die Quelle vorhanden ist und Sie Zugriff darauf haben.
Ereignistyp: Fehler
Ereignisquelle: Userenv
Ereigniskategorie: Keine
Ereigniskennung: 1085
Datum: 17.01.2006
Zeit: 10:16:59
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: TEST1
Beschreibung:
Die clientseitige Erweiterung Softwareinstallation der Gruppenrichtlinien
konnte nicht ausgeführt werden. Überprüfen Sie, ob diese Erweiterung bereits
früher Fehler verursacht hat.
Frank Röder
> Mit DFS habe ich leider bisher keine guten Erfahrungen machen dürfen, aber
> wenn es nicht anders geht würde ich mich da vllt nocheinmal rantrauen.
So lange die Daten im DFS statisch sind bzw. es wird nur von einer
Person schreibend auf ein und dieselbe Datei zugegriffen wird
funktioniert das.
>
> Das Problem mit dem Alias tritt trotz deaktiviertem "StrictNameChecking"
DisableStrictNameChecking <- ist der richtige Key (verschrieben????)
> auf. Auch wenn ich Anmeldeskripte auf Computerebene verteile wird der
> Alias-Name nicht akzeptiert. Auf Benutzerebene ist es kein Problem...
Haben die "Computer" auch auf NTFS und Freigabeebene Leserechte? Es
klingt mir sehr danach, das da ein Berechtigungsproblem vorliegt.
Versuche mal, ob die Computer auf den "realen" Namen zugreifen können.
Dennis Bistron
"Frank Röder" schrieb:
> Dennis Bistron schrieb:
>
> > Mit DFS habe ich leider bisher keine guten Erfahrungen machen dürfen, aber
> > wenn es nicht anders geht würde ich mich da vllt nocheinmal rantrauen.
> So lange die Daten im DFS statisch sind bzw. es wird nur von einer
> Person schreibend auf ein und dieselbe Datei zugegriffen wird
> funktioniert das.
> > Das Problem mit dem Alias tritt trotz deaktiviertem "StrictNameChecking"
> DisableStrictNameChecking <- ist der richtige Key (verschrieben????)
>
> > auf. Auch wenn ich Anmeldeskripte auf Computerebene verteile wird der
> > Alias-Name nicht akzeptiert. Auf Benutzerebene ist es kein Problem...
Nicht verschrieben... wir benutzen bereits ein Alias z.B. für Netzlaufwerke
etc. - läuft.
> Haben die "Computer" auch auf NTFS und Freigabeebene Leserechte? Es
> klingt mir sehr danach, das da ein Berechtigungsproblem vorliegt.
> Versuche mal, ob die Computer auf den "realen" Namen zugreifen können.
>
Über den realen Namen läuft alles perfekt... außer natürlich dem
Verlagerungsproblem. Ich habe aber trotz allem nocheinmal der Gruppe
"Authentifizierte Benutzer" zugriff erteilt... - mit Alias kein Erfolg
Frank Röder
>
> Über den realen Namen läuft alles perfekt... außer natürlich dem
> Verlagerungsproblem. Ich habe aber trotz allem nocheinmal der Gruppe
> "Authentifizierte Benutzer" zugriff erteilt... - mit Alias kein Erfolg
Nächster Versuch.... ;-)
Gib dem Server eine NetBIOS Alias:
HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters
"OptionalNames" als REG_SZ String
und als Wert den NetBIOS Namen des alten Servers.
Danach Neustart oder das Neustarten des Serverdienstes sollte reichen.
Frank Röder
> Über den realen Namen läuft alles perfekt... außer natürlich dem
> Verlagerungsproblem. Ich habe aber trotz allem nocheinmal der Gruppe
> "Authentifizierte Benutzer" zugriff erteilt... - mit Alias kein Erfolg
es halt auf die harte Tour ;-) .
1. Ermittle die GUID des Gruliobjekts
2. Öffne "adsiedit.msc" und navigiere zu "CN=DieNotierteGUID,
CN=Policies, CN=System, DC=Deinedom, DC=de"
3. Jetzt solltest Du folgendes sehen:
GUID
|
CN=Machine
|
CN=Class Store
|
CN=Packages
|
CN=User
|
CN=Class Store
|
CN=Packages
Je nachdem wem Du jetzt die Pakete zugewiesen hast, siehst Du unterhalb
von "CN=Machine" bzw. "CN=User" den Eintrag "CN=Class Store". Unterhalb
von Packages siehst Du dann die einzelnen Pakete.
ACHTUNG! Hier stehen auch Pakete drin, die schon längst gelöscht wurden.
Also erste schwierige Aufgabe das richtige Pakete identifizieren.
Wenn Du das richtige Paket gefunden hast, machst Du einen Doppelklick
drauf um Dir die Eigenschaften anzusehen. In der Liste der Attribute
existiert ein Attribut "msiFileList" wo der Pfad zum MSI Paket
drinsteht. Dort einen Doppelklick drauf. Jetzt siehst Du das nächste
Fenster. Da sollte was in folgender Form drin sein:
0:\\server\freigabe\deine.msi
Das markierst Du, und klickst auf remove. Jetzt hast Du die Möglichkeit,
diesen Wert zu editieren ändere also jetzt den Servernamen und den
Freigabenamen und klick dann wieder auf "Add"
*WICHTIG* Bevor Du nicht auf "Add" geklickt hast kein "OK" anklicken.
So wenn Du das alles durchgeführt hast, sollte es funktionieren. Bitte
teste das in einer Laborumgebung und poste das Ergebnis hier.
Dennis Bistron
> Wenn die Grulis es nicht auf die seichte Tour wollen, dann bekommen die
> es halt auf die harte Tour ;-) .
>
> 1. Ermittle die GUID des Gruliobjekts
> 2. Öffne "adsiedit.msc" und navigiere zu "CN=DieNotierteGUID,
> CN=Policies, CN=System, DC=Deinedom, DC=de"
> 3. Jetzt solltest Du folgendes sehen:
> teste das in einer Laborumgebung und poste das Ergebnis hier.
>
Auf jeden Fall vielen Dank schoneinmal für Deine Mühe.
Ich hoffe, daß ich das zeitlich hinkriege bzw. noch daß Deine
NetBIOS-Alias-Variante helfen wird. Wenn nicht muß ich da wohl durch :-/
MfG
Dennis B.
Frank Röder
>
>
> Auf jeden Fall vielen Dank schoneinmal für Deine Mühe.
>
> Ich hoffe, daß ich das zeitlich hinkriege bzw. noch daß Deine
> NetBIOS-Alias-Variante helfen wird. Wenn nicht muß ich da wohl durch :-/
>
Zu früh gefreut...ich bin gerade am Testen und suche noch den Fehler.
In der ass Datei im Sysvol scheint auch der Pfad drinzustehen.
Bin aber noch am Suchen...also die zweite Lösung noch nicht anwerfen ;-)
Dennis Bistron
> Gib dem Server eine NetBIOS Alias:
> HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters
>
> "OptionalNames" als REG_SZ String
>
> und als Wert den NetBIOS Namen des alten Servers.
So, ich habe das ganze mal getestet:
Zuerst habe ich den Wert entsprechend gesetzt + Neustart.
-> gleicher Fehler
Dann zusätzlich einen entsprechenden Eintrag im WINS hinzugefügt (da ohne
Eintrag im WINS auch über den Explorer kein Zugriff auf den Rechner möglich
war)
-> gleicher Fehler
Weils so schön war DNS-CNAME auch noch (auch wenn's hier schon unsinnig wird)
-> gleicher Fehler
Falls ich es hier noch nicht erwähnt habe ein zusätzlicher Versuch:
Ich habe einfach mal zum Testen versucht, bei der Verteilung eines Paketes
über die IP-Adresse zu gehen (z.B. Pfad= \\10.0.0.15\software\xyz.msi) Aber
auch bei dem Versuch hierüber Software zu verteilen behauptet der Client
wieder, daß er das Paket nicht finden kann.
Hintergrund der Idee war zum einen, daß er, wenn er mit Namen nicht
klarkommt, doch wenigstens mit etwas so "primitivem" wie einer IP-Adresse
keine Probleme haben sollte. Hätte es funktioniert hätte man einfach bei
einer Verlagerung der Pakete der Netzwerkkarte des neuen Servers zusätzlich
die IP des alten zuweisen können bzw. ihm gleich die IP des alten geben...
schade drum...
Fazit:
- Es muß der "echte" Servername in den GPOs zur Softwareverteilung
hinterlegt sein.
Lösungen zum Verlagerungsproblem:
1. Änderung des Pfades zu dem Paket auf (ich nenn es mal) "nicht-regulärem"
Weg
2. der neue Server muß genauso heißen wie der alte
3. DFS(?)
Ich frage mich immernoch wie andere bei dieser Situation vorgehen... oder
benutzen alle DFS bzw. lassen die Anwendungen bei Verlagerung einfach erneut
installieren?
Frank Röder
> Fazit:
> - Es muß der "echte" Servername in den GPOs zur Softwareverteilung
> hinterlegt sein.
>
> Lösungen zum Verlagerungsproblem:
> 1. Änderung des Pfades zu dem Paket auf (ich nenn es mal) "nicht-regulärem"
> Weg
> 2. der neue Server muß genauso heißen wie der alte
> 3. DFS(?)
>
> Ich frage mich immernoch wie andere bei dieser Situation vorgehen... oder
> benutzen alle DFS bzw. lassen die Anwendungen bei Verlagerung einfach erneut
> installieren?
Ich bin noch ein wenig am Basteln, meine aber eine Weg gefunden zu
haben(Ich muss Ihn nur noch verfizieren und das werde ich diese Woche
nicht mehr ganz schaffen)
Ich denke aber der CNAME und der NetBIOS Eintrag sollten reichen.
Eventuell funkt Dir ja noch irgendwas dazwischen. Was haben der Server A
und Server B für Betriebssysteme?
Gehe nochmal *Alles* durch:
1. CNAME und NetBIOS Alias sind gesetzt (alter server ist nicht mehr am
Netz(NetBIOS Namenskonflikt!))
2. Der Registryschlüssel "DisableStrictnamechecking" ist gesetzt?
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
Wertname: DisableStrictNameChecking
Typ: Daten REG_DWORD
Basis: Dezimal
Wert: 1
3. Auf die Freigabe haben die *Computer* bzw. die Benutzer die
entsprechenden Rechte(Freigabeberechtigung und NTFS)?
Zum Testen kannst Du ja mal versuchen für "Jeder" auf Freigabe und NTFS
Ebene "Vollzugriff" zu geben. Aber danach bitte gleich wieder entfernen,
für unsichere Tipps wird man neuerdings geteert und gefedert in der NG
und ich möchte da nicht unbedingt der Erste sein ;-)
4. Was mich noch brennend interessieren würde ist, was denn der
Installer wärend dieser Zeit macht.
http://support.microsoft.com/?kbid=249621
http://support.microsoft.com/kb/q223300/
Die Ergebnisse könntest Du ja mal posten bzw. in diesem exklusiven Fall
auch mal an meine Adresse direkt schicken. Aber poste hier bitte das Du
es getan hast, weil ich dieses Postfach eigentlich nicht abhole.
Dennis Bistron
"Dennis Bistron" schrieb:
> Fazit:
> - Es muß der "echte" Servername in den GPOs zur Softwareverteilung
> hinterlegt sein.
Korrektur:
Fazit:
- Es muß der "echte" Servername in den GPOs zur computerbezogenen(!)
Softwareverteilung hinterlegt sein.
Dies scheint bei allen Computerbezogenen Einstellungen der Fall sein.
Jedenfalls gab es bei Anmeldeskripten die ich unter Computerkonfiguration
hinzugefügt hatte ähnliche Probleme bei Verwendung z. B. eines CNAME. - Nur
kann ich hier den Pfad direkt editieren...
(ganz davon ab würden auch bei Entfernen und Neuhinzufügen hier keinerlei
unerwünschte Effekte auftreten)
Dennis Bistron
> Eventuell funkt Dir ja noch irgendwas dazwischen. Was haben der Server A
> und Server B für Betriebssysteme?
- Windows Server 2003 Standard Edition - SP1
> Gehe nochmal *Alles* durch:
>
> 1. CNAME und NetBIOS Alias sind gesetzt (alter server ist nicht mehr am
> Netz(NetBIOS Namenskonflikt!))
- Alles entsprechend Eingetragen - keine Einträge verweisen mehr auf den
alten Server und er ist auch nicht mehr am Netz
> 2. Der Registryschlüssel "DisableStrictnamechecking" ist gesetzt?
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
>
> Wertname: DisableStrictNameChecking
> Typ: Daten REG_DWORD
> Basis: Dezimal
> Wert: 1
- Gesetzt!
> 3. Auf die Freigabe haben die *Computer* bzw. die Benutzer die
> entsprechenden Rechte(Freigabeberechtigung und NTFS)?
> Zum Testen kannst Du ja mal versuchen für "Jeder" auf Freigabe und NTFS
> Ebene "Vollzugriff" zu geben. Aber danach bitte gleich wieder entfernen,
> für unsichere Tipps wird man neuerdings geteert und gefedert in der NG
> und ich möchte da nicht unbedingt der Erste sein ;-)
- Gruppe "Jeder" entsprechend hinzugefügt - keine Veränderung. (mit dem
"echten" Servernamen dürfte es bei einem Berechtigungsproblem auch nicht
gehen)
> 4. Was mich noch brennend interessieren würde ist, was denn der
> Installer wärend dieser Zeit macht.
>
> http://support.microsoft.com/?kbid=249621
>
> http://support.microsoft.com/kb/q223300/
>
> Die Ergebnisse könntest Du ja mal posten bzw. in diesem exklusiven Fall
> auch mal an meine Adresse direkt schicken. Aber poste hier bitte das Du
> es getan hast, weil ich dieses Postfach eigentlich nicht abhole.
>
Werde ich auf jeden Fall morgen mal testen. Für heute ist erstmal
Feierabend... :-)))
Ergebnisse kommen dann...
Daniel Melanchthon [MSFT]
> Ich frage mich immernoch wie andere bei dieser Situation vorgehen... oder
> benutzen alle DFS bzw. lassen die Anwendungen bei Verlagerung einfach erneut
> installieren?
DFS ist das Mittel der Wahl. Damit hast Du eine Domänenfreigabe
\\<domain>.<tld>\<share>, unabhängig davon, ob der tatsächliche Servername
dahinter sich ändert. Deswegen muß bei einer Verlagerung des
dahinterliegenden Servers die Software nicht neu installiert werden. Am
Sharenamen ändert sich ja nichts.
--
.:Daniel Melanchthon:.
Technologieberater - Exchange Server
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.
Dennis Bistron
> 4. Was mich noch brennend interessieren würde ist, was denn der
> Installer wärend dieser Zeit macht.
>
> http://support.microsoft.com/?kbid=249621
Die Logs sind zum Posten leider etwas zu umfangreich, habe sie Dir daher per
Mail geschickt.
MfG
D. Bistron
Frank Röder
Am WE schreibe ich ein kleines HowTo wie Du es hinbekommst. Ist zwas
übles gefriemel aber nur das Ergebnis zählt!
Frank Röder
> "Frank Röder" schrieb:
>
1. Erstelle eine neue Gruppenrichtlinie die *nicht* verknüpft ist
2. In dieser Gruppenrichtlinie erstellst Du ein Softwarepaket wie Du es
in der originalen Gruppenrichtlinie auch getan hast, nur das Du jetzt
den neuen Netzwerkpfad zur Datei nutzt. Wenn Du das getan hast, notierst
Du bitte die GUID des Gruppenrichtlinienobjekts.
3. Jetzt navigierst Du in das Sysvolverzeichnis in den Ordner der
entsprechenden Gruppenrichtlinie
SysVol\deinedomäne\Policies\{GPO GUID}\Machine\Applications\{GUID für
aas file}.aas
4.Die Datei mit der Endung aas kopierst Du am besten auf den Desktop.
5.Jetzt suchst Du die alte Gruli mit der ursprünglich die Software
verteilt wurde. Dort sollte sich ebenfalls eine aas Datei befinden die
auch mit einer GUID gekennzeichnet ist. Die in den Punkten 2 und 3
erzeugte aas Datei bennenst Du so um, das sie gleichlautend der
originalen aas Datei ist. Danach kopierst Du diese Datei in die alte
Gruppenrichtlinie und überschreibst somit die alte aas Datei(eine gute
Idee wäre hier, die alte vorher zu sichern).
Die Clients die bereits die Software über die Gruppenrichtlinie
empfangen habe speichern diese Datei lokal zwischen. Dadurch muss diese
Datei auch auf allen Clients ausgetauscht werden.
%windir%\system32\appmgmt\MACHINE\{guid}.aas
Das könntest Du eventuell manuell erledigen oder über ein Startupskript.
Zusätzlich befindet sich auch eine *.ini Datei in dem Ordner "appmgmt"
des Clients die Du bitte so lässt wie sie ist.
5. Jetzt kommt die Geschichte mit adsiedit:
Öffne "adsiedit.msc" und navigiere zu "CN=GUID-alteGruli, CN=Policies,
CN=System, DC=Deinedom, DC=de"
3. Jetzt solltest Du folgendes sehen:
GUID
|
CN=Machine
|
CN=Class Store
|
CN=Packages
|
CN=User
|
CN=Class Store
|
CN=Packages
Da Du den Computern das Paket zugewiesen hast, musst Du demnach
unterhalb von "Machine" suchen.
Unterhalb von Packages siehst Du dann die einzelnen Pakete.
ACHTUNG! Hier stehen auch Pakete drin, die schon längst gelöscht wurden.
Also erste schwierige Aufgabe das richtige Pakete identifizieren.
Wenn Du das richtige Paket gefunden hast, machst Du einen Doppelklick
drauf um Dir die Eigenschaften anzusehen. In der Liste der Attribute
existiert ein Attribut "msiFileList" wo der Pfad zum MSI Paket
drinsteht. Dort einen Doppelklick drauf. Jetzt siehst Du das nächste
Fenster. Da sollte was in folgender Form drin sein:
0:\\server\freigabe\deine.msi
Das markierst Du, und klickst auf remove. Jetzt hast Du die Möglichkeit,
diesen Wert zu editieren ändere also jetzt den Servernamen und den
Freigabenamen und klick dann wieder auf "Add"
*WICHTIG* Bevor Du nicht auf "Add" geklickt hast kein "OK" anklicken.
Ich habe es oberfächlich getestet und es funktioniert bei mir. Natürlich
empfehle ich Dir, das erst zu testen bis Du es auf die Menschheit
loslässt. Wenn alles bei Dir funktioniert würde ich mich freuen, wenn Du
das Ergebnis postest. Ich denke, man könnte hier ein kleines HowTo
basteln, für all die, die vor dem gleichen Problem stehen.
Viele Grüße und viel Erfolg wünscht Frank.
Was ich allerdings noch nicht verstehe ist, warum die Clients sich nicht
durch einen Aliasnamen haben austricksen lassen.
Dennis Bistron
> Um wieviele Clients handelt es sich denn?
~150 Clients und der Terminalserver
Dennis Bistron
"Frank Röder" schrieb:
> Dann wollen wir mal der Operation beginnen;-)
> Ich habe es oberfächlich getestet und es funktioniert bei mir. Natürlich
> empfehle ich Dir, das erst zu testen bis Du es auf die Menschheit
> loslässt. Wenn alles bei Dir funktioniert würde ich mich freuen, wenn Du
> das Ergebnis postest. Ich denke, man könnte hier ein kleines HowTo
> basteln, für all die, die vor dem gleichen Problem stehen.
>
> Viele Grüße und viel Erfolg wünscht Frank.
Ich werde nebenbei mal die Testumgebung aufsetzen und das Ergebnis dann hier
posten. Wird aber denke ich ein paar Tage dauern...
> Was ich allerdings noch nicht verstehe ist, warum die Clients sich nicht
> durch einen Aliasnamen haben austricksen lassen.
Das würde mich auch interessieren. Ist es vielleicht,einfach gesagt,"zu
früh" für den Client um mit sowas umgehen zu können? Habe aber leider nicht
genug Hintergrundwissen über den Ablauf des Windows-Startvorgangs um dies
belegen zu können...
MfG
Dennis
Dennis Bistron
habe es jetzt mal in einem kleinen Testnetz ausprobiert.
Also...
"Frank Röder" schrieb:
> 1. Erstelle eine neue Gruppenrichtlinie die *nicht* verknüpft ist
> 2. In dieser Gruppenrichtlinie erstellst Du ein Softwarepaket wie Du es
> in der originalen Gruppenrichtlinie auch getan hast, nur das Du jetzt
> den neuen Netzwerkpfad zur Datei nutzt. Wenn Du das getan hast, notierst
> Du bitte die GUID des Gruppenrichtlinienobjekts.
> 3. Jetzt navigierst Du in das Sysvolverzeichnis in den Ordner der
> entsprechenden Gruppenrichtlinie
> SysVol\deinedomäne\Policies\{GPO GUID}\Machine\Applications\{GUID für
> aas file}.aas
>
> 4.Die Datei mit der Endung aas kopierst Du am besten auf den Desktop.
Bis hierhin alles kP
> 5.Jetzt suchst Du die alte Gruli mit der ursprünglich die Software
> verteilt wurde. Dort sollte sich ebenfalls eine aas Datei befinden die
> auch mit einer GUID gekennzeichnet ist. Die in den Punkten 2 und 3
> erzeugte aas Datei bennenst Du so um, das sie gleichlautend der
> originalen aas Datei ist. Danach kopierst Du diese Datei in die alte
> Gruppenrichtlinie und überschreibst somit die alte aas Datei(eine gute
> Idee wäre hier, die alte vorher zu sichern).
Hier habe ich bei der alten GPO mehrere AAS-Dateien vorgefunden. Ich habe
mir die mit dem aktuellsten Timestamp rausgesucht. Die anderen schienen nur
veraltete Einträge zu sein (habe die GPO vor diesem Test bereits mehrmals
bearbeitet; in den älteren AAS-Dateien waren z.B. auch die Pfade der alten
Konfiguration zu sehen etc.)
Ich habe es nun auch Spaßes halber mit allein dieser Änderung getestet. Die
Software wird nun schon bei Neuinstallationen von der neuen Quelle
installiert.
> Die Clients die bereits die Software über die Gruppenrichtlinie
> empfangen habe speichern diese Datei lokal zwischen. Dadurch muss diese
> Datei auch auf allen Clients ausgetauscht werden.
>
> %windir%\system32\appmgmt\MACHINE\{guid}.aas
>
> Das könntest Du eventuell manuell erledigen oder über ein Startupskript.
> Zusätzlich befindet sich auch eine *.ini Datei in dem Ordner "appmgmt"
> des Clients die Du bitte so lässt wie sie ist.
Auf dem Client war ich zuerst etwas verwirrt, da hier andere GUIDs verwendet
werden als am Server. Konnte jedoch wiederum durch Timestamp und Größe die
Korrekte ausfindig machen.
Ich habe es auch getestet ohne diese zu ersetzen und konnte so direkt keine
Nachteile feststellen. (Nur zeigt der Client bei entsprechender Auswertung
der GPOs den falschen Quellpfad für das Paket an)
> 5. Jetzt kommt die Geschichte mit adsiedit:
> Öffne "adsiedit.msc" und navigiere zu "CN=GUID-alteGruli, CN=Policies,
> CN=System, DC=Deinedom, DC=de"
> 3. Jetzt solltest Du folgendes sehen:
>
> GUID
> |
> CN=Machine
> |
> CN=Class Store
> |
> CN=Packages
> |
> CN=User
> |
> CN=Class Store
> |
> CN=Packages
>
>
> Da Du den Computern das Paket zugewiesen hast, musst Du demnach
> unterhalb von "Machine" suchen.
> Unterhalb von Packages siehst Du dann die einzelnen Pakete.
> ACHTUNG! Hier stehen auch Pakete drin, die schon längst gelöscht wurden.
> Also erste schwierige Aufgabe das richtige Pakete identifizieren.
Auch hier wieder jede Menge Pakete (wieder andere GUIDs). Habe es anhand des
Attributs "whenChanged" ausfindig machen können.
> Wenn Du das richtige Paket gefunden hast, machst Du einen Doppelklick
> drauf um Dir die Eigenschaften anzusehen. In der Liste der Attribute
> existiert ein Attribut "msiFileList" wo der Pfad zum MSI Paket
> drinsteht. Dort einen Doppelklick drauf. Jetzt siehst Du das nächste
> Fenster. Da sollte was in folgender Form drin sein:
>
> 0:\\server\freigabe\deine.msi
>
> Das markierst Du, und klickst auf remove. Jetzt hast Du die Möglichkeit,
> diesen Wert zu editieren ändere also jetzt den Servernamen und den
> Freigabenamen und klick dann wieder auf "Add"
> *WICHTIG* Bevor Du nicht auf "Add" geklickt hast kein "OK" anklicken.
Die Werte die hier eingetragen werden sind aber nur "Bezeichnungen" oder?
Ich meine, es wird bei Ansicht der GPO noch
der alte, falsche Pfad angezeigt, aber installiert wird schon von dem
richtigen.
>
> Ich habe es oberfächlich getestet und es funktioniert bei mir. Natürlich
> empfehle ich Dir, das erst zu testen bis Du es auf die Menschheit
> loslässt. Wenn alles bei Dir funktioniert würde ich mich freuen, wenn Du
> das Ergebnis postest. Ich denke, man könnte hier ein kleines HowTo
> basteln, für all die, die vor dem gleichen Problem stehen.
Wie oben bereits geschrieben hat eine Neuinstallation nach den Änderungen
wie gewünscht funktioniert.
Auch die Deinstallation (bei entfernen eines PCs aus der entsprechenden OU),
Aktualisierung durch ein anderes Paket uswusf. funktionierte problemlos
(schon vor der adsiedit-Geschichte und Verteilung der AAS-Dateien auf die
Clients - allerdings wird wie bereits Beschrieben der Quellpfad falsch
angezeigt und erneutes Bereitstellen des Paketes ist ohne adsiedit nicht
möglich!).
Werde trotz allem damit noch ein wenig "rumspielen". Sollte sich
herausstellen, daß es doch noch irgendwelche Risiken und Nebenwirkungen gibt
werde ich es hier posten.
Bzgl. meines Problemes werde ich auf jeden Fall zuerst noch versuchen DFS
zum Laufen zu bringen. Ob die Verlagerung der Pakete auf den DFS-Pfad dann
über diese Methode realisiert wird oder ob wir doch eine Neuinstallation der
Software in Betracht ziehen steht noch offen.
MfG
Dennis B.
Frank Röder
kurz und knapp es funktioniert.
Das freut mich :-)