117471
Jan 30, 2018, updated at 09:48:18 (UTC)
1979
5
0
MSI-Pakete im SYSVOL
Hallo,
ich verteile via Gruppenrichtlinien MSI-Pakete. Momentan liegen diese auf einer separaten Freigabe des primären DC.
Ich hätte hier gerne "etwas Redundanz". Weiterhin ist der PDC ein SBS2011 und ich bin bei dem Teil grundsätzlich bestrebt, auf diesem Server möglichst wenig Veränderungen durchzuführen und alles über die Assistenten zu erledigen. Und für DFS / DFR hat der nun mal keinen Assistenten
Ich habe mir überlegt, den Ordner mit den MSI-Paketen im SYSVOL abzulegen um zu erreichen, dass dieser über die übliche SYSVOL-Replikation auf alle DCs repliziert wird.
D.h., auf jedem DC würde dann letztendlich so ein UNC-Konstrukt entstehen:
\\hostname\SYSVOL\meine.domaene\MSI-Installationspakete\
In den Gruppenrichtlinien würde ich dann als Quelle für die MSI-Datei(en) z.B. so etwas angeben:
\\meine.domaene\SYSVOL\meine.domaene\MSI-Installationspakete\
Krank oder genial?
Gruß,
Jörg
ich verteile via Gruppenrichtlinien MSI-Pakete. Momentan liegen diese auf einer separaten Freigabe des primären DC.
Ich hätte hier gerne "etwas Redundanz". Weiterhin ist der PDC ein SBS2011 und ich bin bei dem Teil grundsätzlich bestrebt, auf diesem Server möglichst wenig Veränderungen durchzuführen und alles über die Assistenten zu erledigen. Und für DFS / DFR hat der nun mal keinen Assistenten
Ich habe mir überlegt, den Ordner mit den MSI-Paketen im SYSVOL abzulegen um zu erreichen, dass dieser über die übliche SYSVOL-Replikation auf alle DCs repliziert wird.
D.h., auf jedem DC würde dann letztendlich so ein UNC-Konstrukt entstehen:
\\hostname\SYSVOL\meine.domaene\MSI-Installationspakete\
In den Gruppenrichtlinien würde ich dann als Quelle für die MSI-Datei(en) z.B. so etwas angeben:
\\meine.domaene\SYSVOL\meine.domaene\MSI-Installationspakete\
Krank oder genial?
Gruß,
Jörg
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 362887
Url: https://administrator.de/contentid/362887
Printed on: April 19, 2024 at 23:04 o'clock
5 Comments
Latest comment
Hi,
ich habe irgendwann irgendwo mal ein Whitepaper von MS gelesen, in welchem davon abgeraten wurde, im SYSVOL irgend etwas anderes zu speichern als das, wofür es vorgesehen ist. Sonst gibt es ggf. keinen Support bzgl. Problemen bei der DC-Replikation.
Nun kann man das bei MSI-Paketen, welche mittels GPO verteilt werden, nicht so klar abgrenzen. Gehört es zur GPO oder nicht?
Ich erinnere mich aber auch daran, gelesen zu haben, dass man Startup-, Shutdown-, Login- und Logot-Scripte unbedingt in den dafür vorgesehenen GPO-Ordnern speichern soll. Hier wurde als Argument die Sicherheit genannt. Diese Scripte können dann nur von Admins bearbeitet werden, welche auch die betreffende GPO bearbeiten dürfen. Die Berechtigungen von GPO-Objekt und korrespondierendem GPO-Ordner im SYSVOL werden ja i.A. automatisch synchron gehalten.
Ich habe für mich den Kompromiss gefunden, dass ich kleinere MSI-Pakete im Startup-Ordner der verteilenden GPO speichere und dann von dort importiere. Weil kleine Pakete macht es auch nichts, wenn mehrere verschiedenen GPO das gleiche Paket enthalten sollten. Große Installationspakete speichere ich i.A. in einem dedizierten DFS-Stamm, dessen Stamm- und Ordnerziele ebenfalls über min. 2 Server repliziert werden. Wenn eines der beiden Server kein Windows Server ist und deshalb kein DFS-R kann (z.B. ein NAS), dann kann man diesen trotzdem als Ziel im DFS-N nutzen, muss die Daten halt nur alternativ synchron halten, z.B. mit Robocopy im Scheduled Task oder sonstwie.
E.
ich habe irgendwann irgendwo mal ein Whitepaper von MS gelesen, in welchem davon abgeraten wurde, im SYSVOL irgend etwas anderes zu speichern als das, wofür es vorgesehen ist. Sonst gibt es ggf. keinen Support bzgl. Problemen bei der DC-Replikation.
Nun kann man das bei MSI-Paketen, welche mittels GPO verteilt werden, nicht so klar abgrenzen. Gehört es zur GPO oder nicht?
Ich erinnere mich aber auch daran, gelesen zu haben, dass man Startup-, Shutdown-, Login- und Logot-Scripte unbedingt in den dafür vorgesehenen GPO-Ordnern speichern soll. Hier wurde als Argument die Sicherheit genannt. Diese Scripte können dann nur von Admins bearbeitet werden, welche auch die betreffende GPO bearbeiten dürfen. Die Berechtigungen von GPO-Objekt und korrespondierendem GPO-Ordner im SYSVOL werden ja i.A. automatisch synchron gehalten.
Ich habe für mich den Kompromiss gefunden, dass ich kleinere MSI-Pakete im Startup-Ordner der verteilenden GPO speichere und dann von dort importiere. Weil kleine Pakete macht es auch nichts, wenn mehrere verschiedenen GPO das gleiche Paket enthalten sollten. Große Installationspakete speichere ich i.A. in einem dedizierten DFS-Stamm, dessen Stamm- und Ordnerziele ebenfalls über min. 2 Server repliziert werden. Wenn eines der beiden Server kein Windows Server ist und deshalb kein DFS-R kann (z.B. ein NAS), dann kann man diesen trotzdem als Ziel im DFS-N nutzen, muss die Daten halt nur alternativ synchron halten, z.B. mit Robocopy im Scheduled Task oder sonstwie.
E.
Das ist ein uraltes Konzept. Klar geht das. Wenn Dein Fileserver nicht redundant ist (der könnte doch genau so DFS-Replikation machen wie der DC), dann kannst Du das so machen. Bläht natürlich das Laufwerk wo sysvol liegt auf.
Hallo,
danke für die Einschätzung.
Ich durfte neulich eine defekte SYSVOL-Replikation reparieren und bin so erst auf die Idee gekommen, dort "Lastdaten" abzulegen.
Auf der anderen Seite habe ich momentan keine Ahnung, warum die Replikation auf einmal nicht mehr funktionierte und da einige Seiten als Ursache eine prophane "Überlastung" angeben, kann ich nicht einschätzen, wie glücklich ich dort mit meinem MSI-Installationsordner werde.
Gruß,
Jörg
danke für die Einschätzung.
Ich durfte neulich eine defekte SYSVOL-Replikation reparieren und bin so erst auf die Idee gekommen, dort "Lastdaten" abzulegen.
Auf der anderen Seite habe ich momentan keine Ahnung, warum die Replikation auf einmal nicht mehr funktionierte und da einige Seiten als Ursache eine prophane "Überlastung" angeben, kann ich nicht einschätzen, wie glücklich ich dort mit meinem MSI-Installationsordner werde.
Gruß,
Jörg
Die Last entsteht doch nur, wenn sich dort was ändert. Hin und wieder ein Paket drauf zu legen ist kaum die Ursache.
Die Last entsteht doch nur, wenn sich dort was ändert. Hin und wieder ein Paket drauf zu legen ist kaum die Ursache.
Sehe ich auch so.Höchstens wenn man es übertreibt und mal einen neuen DC an einem WAN-Standort installiert. Dann muss dieser diesen ganzen Kram schon bei seiner Erst-Synchronisation über die Leitung schleifen, bevor er funktionstüchtig ist.
