Designfrage zu GPOs
Moin moin zusammen.
Ich wollte gern mal eure Meinungen zum Thema GPO-Design hören, aktuell gegeben sei ein AD mit mehreren DCs, verteilt über mehrere physikalische Standorte, die per Site-to-Site-VPN sternförmig miteinander verbunden sind. Innerhalb des ADs gibt es pro Standort OUs, die die jeweiligen Computer- und Benutzerkonten enthalten; zusätzlich außerhalb davon eine OU, in der die Server abgelegt sind (DCs bleiben im Default-Container).
Verteilt werden per GPO Netzlaufwerke und -drucker (GPP), Shortcuts, Files sowie Office- und andere Einstellungen (AutoPlay, Point-and-Print usw.)
Sub-OUs bei den Servern, weil hier RDS-Hosts dabei sind und GPOs mit Loopback direkt auf diese Sub-OUs verlinkt sind.
Folgende Fragen drängen sich mir gerade auf:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Bin mal gespannt auf eure Antworten.
Ich weiß, sehr individuelles Thema, aber vielleicht zeichnet sich ja ein Best Practice ab - ist btw nicht so, dass GPOs bei uns generell Probleme machen würden, klappt eigentlich alles. Allerdings würde ich gern einiges konsolidieren und auch an der Verlinkung gern etwas schrauben, daher wäre der ein oder andere Schubser "von außerhalb" sicherlich nicht verkehrt.
Danke für euer Hirnschmalz.
Cheers,
jsysde
Ich wollte gern mal eure Meinungen zum Thema GPO-Design hören, aktuell gegeben sei ein AD mit mehreren DCs, verteilt über mehrere physikalische Standorte, die per Site-to-Site-VPN sternförmig miteinander verbunden sind. Innerhalb des ADs gibt es pro Standort OUs, die die jeweiligen Computer- und Benutzerkonten enthalten; zusätzlich außerhalb davon eine OU, in der die Server abgelegt sind (DCs bleiben im Default-Container).
Verteilt werden per GPO Netzlaufwerke und -drucker (GPP), Shortcuts, Files sowie Office- und andere Einstellungen (AutoPlay, Point-and-Print usw.)
Sub-OUs bei den Servern, weil hier RDS-Hosts dabei sind und GPOs mit Loopback direkt auf diese Sub-OUs verlinkt sind.
Folgende Fragen drängen sich mir gerade auf:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Bin mal gespannt auf eure Antworten.
Ich weiß, sehr individuelles Thema, aber vielleicht zeichnet sich ja ein Best Practice ab - ist btw nicht so, dass GPOs bei uns generell Probleme machen würden, klappt eigentlich alles. Allerdings würde ich gern einiges konsolidieren und auch an der Verlinkung gern etwas schrauben, daher wäre der ein oder andere Schubser "von außerhalb" sicherlich nicht verkehrt.
Danke für euer Hirnschmalz.
Cheers,
jsysde
Please also mark the comments that contributed to the solution of the article
Content-ID: 291920
Url: https://administrator.de/contentid/291920
Printed on: October 7, 2024 at 01:10 o'clock
13 Comments
Latest comment
Moin
Grüße,
Tiberius
Folgende Fragen drängen sich mir gerade auf:
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Beibehalten- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Was genau meinst du?Grüße,
Tiberius
Hi,
interessiert mich auch.
hab ich auch so. Ich finde man findet einzelne Einstellungen so leichter wieder und kann sie auch gezielt deaktivieren. Ausnahme sind Einstellungen für bestimmte Software - zb CAD - hier gibt es ein paar größere Einstellungs-Pakete.
In it-administrator gab es einmal einen Beitrag über GPO Management. Dort wuden auch viele GPOs mit wenig Einstellungen empfohlen. Performancetechnisch macht das keinen Unterschied mehr.
Mit "Einstellungen" meine ich ein paar GPO Settings. zb off-w-templates, off-ol-autoarchive und nicht eine große Office GPO
Wieso das?
sg Dirm
interessiert mich auch.
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.In it-administrator gab es einmal einen Beitrag über GPO Management. Dort wuden auch viele GPOs mit wenig Einstellungen empfohlen. Performancetechnisch macht das keinen Unterschied mehr.
Mit "Einstellungen" meine ich ein paar GPO Settings. zb off-w-templates, off-ol-autoarchive und nicht eine große Office GPO
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Änderungen an Default GPOs sind doch eh meist wischendruchschnellmal-Pfusch. Eine extra GPO kostet nix und ist überischtlicher.- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Beibehalten- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Alle Alle? Admin, DC, ...- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
zur GPO verteilung? Hier finde ich die Verlinkung auf GPO basis auch übersichtlicher. Die Gesamteliste der GPOs kann ich mir ja sowieso anzeigen lassen.sg Dirm
Zitat von @Dirmhirn:
Wieso das?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
BeibehaltenSofern ich den TO nicht falsch verstanden habe, ist das derselbe Punkt wie der erste.
Moin @jsysde
Gruß,
Dani
Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Ja. Nur wenn es gar nicht anders geht etwas ändern. Auf jeden Fall 101% dokumentieren, falls der Microsoft Support benötigt wird. Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Wir legen pro Bereich (Computer und Benutzer) und Anwendung jeweils separate Gruppenrichtlinienobjekte an.Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Bei uns sind Geräte und Benutzer in einem eigenen OU-Baum abgelegt. Ob es auf oberste Ebene ablegt wird, hängt davon ab, wie viele Computer bzw. Benutzer nicht betroffen sind. Schließlich erhöht sich dadurch die gesamte Ausführungszeit. Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Sinnvoll. Auch hier geht es um Verarbeitungszeit. Beim Hochfahren eines Rechners wird somit der Benutzerteil komplett ignoriert. Anderenfalls wird er trotzdem verarbeitet.Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
Wenn es speziell nur bestimmte Sites betrifft, macht es durch aus Sinn.Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Versuchen wir zu vermeiden, da es meiner Ansicht nach potenzielle Fehlerquellen sind.Gruß,
Dani
Moin
Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts. Reicht für unsere Zwecke bisher locker aus. Alternativ würde mir Dokusnap noch einfallen. Da sind die Jungs von Vertrags/Inventarisierung und Lizenzverwaltung scharf drauf.
Gruß,
Dani
Gruß,
Dani
Du kannst nicht zufällig ein Tool zur ausführlichen Dokumentation empfehlen? Nur so am Rande...
Ein Tool direkt nicht... wir nutzen dazu GPMC Skripts von Microsoft. Im Detail müsste ich nochmals nachlesen.Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts. Reicht für unsere Zwecke bisher locker aus. Alternativ würde mir Dokusnap noch einfallen. Da sind die Jungs von Vertrags/Inventarisierung und Lizenzverwaltung scharf drauf.
Wenige GPOs heisst weniger Overhead, dafür viele Einstellungen, die angewendet werden müssen + evtl. noch etliche Filter (ILT).
Wieso mehr Einstellungen? Die Anzahl der Einstellungen in einer GPO werden durchs aufteilen nicht mehr. Wie messe ich die Performance und erhalte belastbare Ergebnisse?
Da lege ich dir folgenden Arikel ans Herz. Damit hast du die Basics schon mal erledigt.Viele "Roaming User", die heute hier, morgen dort sind. Ich möchte denen immer einen standort-spezifischen Drucker installieren und alle anderen Drucker löschen. Je nach Drucker/Treiber dauert der Aufruf des Druck-Dialogs (egal, aus welcher Anwendung) recht lange, weil der Drucker nicht erreichbar ist (Sternförmige Vernetzung der Standorte; nicht jeder Drucker ist von jedem Standort aus erreichbar).
Ist so schon realisiert oder geht es um die Grundidee je nach Standort einen definierten Drucker zur Verfügung zustellen?Gruß,
Dani
Gruß,
Dani
Hi,
frage 10 Erperten und Du bekommst 100 Meinungen ...
Ich glaube, hier gibt es nicht wirklich die eine Best Practice. Das hängt immer von der konkreten Umgebung, den konkreten Anforderungen und - nicht zu vergessen - von den Fähigkeiten des Admins, welche dieses betreuen müssen, ab.
(Zu letzterem: Ich habe auch schon simpleste Einstellungen "super-simpel" abgebildet (zu Deutsch: "idiotensicher"), um zu erreichen, dass auch wirklich alle Kollegen da noch durchblicken. Und das ist nicht mal "böse" gemeint gewesen.)
Hier mal mein Standpunkt:
Ich selbst erstelle meistens größere, themenbezogene Basis-GPO, welche Einstellungen enthalten, die für alle oder die meisten der Benutzer und/oder Computer gelten sollen (z.B. "globale Office 2010 Einstellungen für Benutzer"), und welche ich dann auch für alle Benutzer und/oder Computer filtere. Zusätzlich erstelle ich GPO mit speziellen, vom Standard abweichenden Einstellungen, welche ich dann nur für die betreffenden Benutzer und/oder Computer filtere (z.B. "zentraler Office-Vorlagen-Pfad für Buchhaltung"). Hier muss man dann halt die GPO-Vererbung entsprechend designen.
Ob man diese GPO nun auch nach Einstellungen Nur-für-Computer und Nur-für-Benutzer trennt, das ist "Ansichtssache". Es hat keinen Einfluss auf die Verabeitungsgeschwindigkeit, da ein Computer eh immer nur die Bereiche "Computerkonfiguration" und ein Benutzer eh immer nur die Bereiche "Benutzerkonfiguration" der GPOs laden und verarbeiten wird.
Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
E.
frage 10 Erperten und Du bekommst 100 Meinungen ...
Ich glaube, hier gibt es nicht wirklich die eine Best Practice. Das hängt immer von der konkreten Umgebung, den konkreten Anforderungen und - nicht zu vergessen - von den Fähigkeiten des Admins, welche dieses betreuen müssen, ab.
(Zu letzterem: Ich habe auch schon simpleste Einstellungen "super-simpel" abgebildet (zu Deutsch: "idiotensicher"), um zu erreichen, dass auch wirklich alle Kollegen da noch durchblicken. Und das ist nicht mal "böse" gemeint gewesen.)
Hier mal mein Standpunkt:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Ich nutze diese nur für ganz wenige Basis-Einstellungen, welche i.A. "sowieso" für alle Benutzer und/oder Computer der Domäne gelten sollen.- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Beide Systeme haben Ihre Vor- und Nachteile. Wie so oft wird auch hier wohl der Mittelweg der günstigste sein.Ich selbst erstelle meistens größere, themenbezogene Basis-GPO, welche Einstellungen enthalten, die für alle oder die meisten der Benutzer und/oder Computer gelten sollen (z.B. "globale Office 2010 Einstellungen für Benutzer"), und welche ich dann auch für alle Benutzer und/oder Computer filtere. Zusätzlich erstelle ich GPO mit speziellen, vom Standard abweichenden Einstellungen, welche ich dann nur für die betreffenden Benutzer und/oder Computer filtere (z.B. "zentraler Office-Vorlagen-Pfad für Buchhaltung"). Hier muss man dann halt die GPO-Vererbung entsprechend designen.
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Wenn eine GPO keine Einstellungen für Computer oder Benutzer enthält, dann sollte man sehr wohl den nicht benötigten Bereich deaktivieren. Der Effekt ist, dass beim GPO Collect solche GPO gar nicht erst bei der Filterung berücksichtigt werden. Somit landen dann auch keine leeren GPO in der Verarbeitungsliste, welche nicht nur die Verarbeitung unnötigt verzögern würden, sondern auch den Admin bei der Fehlersuche ablenken (z.B. wenn man das GPresult auswertet). Dies wirkt sich vor allem beim Startup und/oder Login an WAN-Standorten aus, an welchen kein DC vor Ort vorhanden ist.Ob man diese GPO nun auch nach Einstellungen Nur-für-Computer und Nur-für-Benutzer trennt, das ist "Ansichtssache". Es hat keinen Einfluss auf die Verabeitungsgeschwindigkeit, da ein Computer eh immer nur die Bereiche "Computerkonfiguration" und ein Benutzer eh immer nur die Bereiche "Benutzerkonfiguration" der GPOs laden und verarbeiten wird.
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Wie oft und wo eine GPO im AD verlinkt ist, ist für die Verabeitung vollkommen irrelevant. Interessant ist nur, wie die Admins damit zurecht kommen und dass man eine GPO nicht mehrmals für einen Benutzer und/oder Computer im Vererbungsbaum verlinkt. Ich handhabe das immer so: So weit oben wie nötig, soweit unten wie möglich.- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
Die Filterung einer GPO über das AD-Standortobjekt ist schneller als die Filterung der einzelnen GPP-Einstellungen über ITL. Wenn eine GPO nur Einstellungen enthält, welche nur beim Startup oder Login an einem bestimmten Standort gelten, dann erstelle ich einen AD-Standort und hänge dort die GPOs - ohne ITL für "Standort" - dran.- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
Für Einstellungen, welche nicht über die GPP erfolgen sondern über klassische Richtlinien (und welche auch nicht auf GPP umgestellt werden können), und welche man weiterhin dynamisch von bestimmten Begebenheiten abhängig filtern will oder muss, wird man auch weiterhin die GPO über WMI-Filter filtern müssen.- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Wie ist diese Frage gemeint? Meinst Du, extra Gruppen für die Filterung von GPO anlegen und benutzen? Das kann notwendig sein, wenn es noch keine entsprechenden Gruppen gibt.Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
E.
Das Sitzungstoken eines Benutzers kann bis zu 1015 Gruppen-SID enthalten. Dazu muss man aber ggf. die max. Tokengröße erhöhen. (--> MaxTokenSize)
Die Schattenseite eines konsequenten AGDLP-Modells ist genau diese u.U. sehr hohe Anzahl an verschachtelen Gruppen beim Zugriff auf manche Server oder Dienste. Wenn man es übertreibt kann das auch dazu führen, dass einige GPO nicht angewendet werden. Das hat aber nichts mit der Anzahl der GPO und/oder deren Verlinkungen zu tun, sondern allein mit der beschränkten Tokengröße. Es sei denn, man legt für jede GPO eine Gruppe zum Filtern an. Dann würde die Gruppenanzahl mit der Anzahl der für einen Benutzer geltenden GPOs natürlich steigen. Du siehst spätestens hier, dass es Nonsens ist, extra Gruppen nur für die Zuordnung von GPOs zu erstellen. Eine GPO erstelle ich für eine bestimmte Gruppe von Benutzern oder Computern. Wenn diese nicht bereits in AD-Gruppen gruppiert sind, dann sollte man das im Zusammenhang mit der neuen GPO natürlich tun. Aber auch nur dann, wenn erforderlich.
Bsp: Gruppen "Buchhaltung" und "Lager". Beide haben keine Überschneidungen in den Mitgliedern. Für beide soll eine GPO gelten. Statt jetzt eine neue Gruppe für die Filterung dieser GPO zu erstellen, besser die beiden vorhandenen Gruppen benutzen.
Wenn eine GPO z.B. nur für 2 Computer gilt, dann kann man deren Konten auch einzeln hinzfügen. Das machen wir z.B. bei der Steuerung der lokalen Administratoren einzelner Server so. Oder man verschiebt beide Computerobjekte in eine dedizierte OU und hängt die GPO an diese OU mit Standardfilter für "autentifizierte Benutzer". Das geht auch.
Alles andere ist Bast Practice speziell auf Eure Umgebung und Eure Arbeitsweise bezogen. Und diese könnt Ihr Euch nur selbst erarbeiten. Wichtig ist nur, dass Ihr Eure Verfahren auch als definierte Prozesse niederschreibt. "Gelebte Standards", welche nur als Idee im Raum stehen, aber nirgend verbindlich festgeschrieben sind, neigen meiner Erfahrung nach dazu, ständig "angepasst" oder "ausgelegt" zu werden. X-fache Sonderlocken sind damit vorprogrammiert.
Die Schattenseite eines konsequenten AGDLP-Modells ist genau diese u.U. sehr hohe Anzahl an verschachtelen Gruppen beim Zugriff auf manche Server oder Dienste. Wenn man es übertreibt kann das auch dazu führen, dass einige GPO nicht angewendet werden. Das hat aber nichts mit der Anzahl der GPO und/oder deren Verlinkungen zu tun, sondern allein mit der beschränkten Tokengröße. Es sei denn, man legt für jede GPO eine Gruppe zum Filtern an. Dann würde die Gruppenanzahl mit der Anzahl der für einen Benutzer geltenden GPOs natürlich steigen. Du siehst spätestens hier, dass es Nonsens ist, extra Gruppen nur für die Zuordnung von GPOs zu erstellen. Eine GPO erstelle ich für eine bestimmte Gruppe von Benutzern oder Computern. Wenn diese nicht bereits in AD-Gruppen gruppiert sind, dann sollte man das im Zusammenhang mit der neuen GPO natürlich tun. Aber auch nur dann, wenn erforderlich.
Bsp: Gruppen "Buchhaltung" und "Lager". Beide haben keine Überschneidungen in den Mitgliedern. Für beide soll eine GPO gelten. Statt jetzt eine neue Gruppe für die Filterung dieser GPO zu erstellen, besser die beiden vorhandenen Gruppen benutzen.
Wenn eine GPO z.B. nur für 2 Computer gilt, dann kann man deren Konten auch einzeln hinzfügen. Das machen wir z.B. bei der Steuerung der lokalen Administratoren einzelner Server so. Oder man verschiebt beide Computerobjekte in eine dedizierte OU und hängt die GPO an diese OU mit Standardfilter für "autentifizierte Benutzer". Das geht auch.
Alles andere ist Bast Practice speziell auf Eure Umgebung und Eure Arbeitsweise bezogen. Und diese könnt Ihr Euch nur selbst erarbeiten. Wichtig ist nur, dass Ihr Eure Verfahren auch als definierte Prozesse niederschreibt. "Gelebte Standards", welche nur als Idee im Raum stehen, aber nirgend verbindlich festgeschrieben sind, neigen meiner Erfahrung nach dazu, ständig "angepasst" oder "ausgelegt" zu werden. X-fache Sonderlocken sind damit vorprogrammiert.
Guten Morgen,
wir machen das Printermapping hauptsächlich clientbasiert. So bekommt der Benutzer den Drucker, der am nächsten steht.
Bei der Anmeldung wird per Skript eine CSV mit clientname,Printserver, Drucker share und default j/n durchpflügt und con2prt gefüttert.
Bei Notebooks muss man allerdings allerdings mehrere Einträge machen, weil dort der Client wandert und nicht der Benutzer.
Dieser setzt dann manuell den Standard Drucker.
Es ist übrigens egal, ob in der CSV 10 oder 1000000000 stehen. Die Anmeldedauer verlängert sich dadurch nicht. Einzig die Anzahl der Hits beeinflusst sie... Natürlich.
Gruß,
JMcClane
wir machen das Printermapping hauptsächlich clientbasiert. So bekommt der Benutzer den Drucker, der am nächsten steht.
Bei der Anmeldung wird per Skript eine CSV mit clientname,Printserver, Drucker share und default j/n durchpflügt und con2prt gefüttert.
Bei Notebooks muss man allerdings allerdings mehrere Einträge machen, weil dort der Client wandert und nicht der Benutzer.
Dieser setzt dann manuell den Standard Drucker.
Es ist übrigens egal, ob in der CSV 10 oder 1000000000 stehen. Die Anmeldedauer verlängert sich dadurch nicht. Einzig die Anzahl der Hits beeinflusst sie... Natürlich.
Gruß,
JMcClane