Daim
-
Gesamte Inhalte
4.534 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Daim
-
-
Aloha,
ohh ein Hesse.
eine kurze Frage, auf der Webseite von MS steht geschrieben, das ein RODC nicht mit einem W2K3 DC sich replizieren kann (die Domänenpartition) und deshelb muss immer ein W2K8 DC der Replikationspartner sein.das ist soweit korrekt.
Irgwendwie verstehe ich das nicht so ganz. Ich habe das Gefühl das da ein Fehler in der Grafik sowie im Text ist.Das könnte zwar sein, da die Seite seit der Beta existiert, aber die Grafik ist soweit korrekt.
In meinen Augen müsste Standort B ein W2K8 DC seinNein, nicht zwangsläufig. Es ist eine Frage des Netzwerkdesigns.
Standort A könnte in diesem Fall ohne Probleme ein W2K3 DC sein.Ja, so könnte es auch aussehen.
Könnt Ihr mir da weiter helfen? Vielleicht hab ich es ja doch nicht verstanden. :confused:Vor deiner Grafik steht aber auch der Satz:
Zitat:
In diesem Fall können Sie zusätzliche Standortverknüpfungen zwischen dem Hubstandort und den Randstandorten erstellen, um eine direkte Replikation zwischen dem RODC und dem schreibbaren Domänencontroller unter Windows Server 2008 zu ermöglichen.Das bedeutet, die Schema-, Konfigurations- sowie die ForestDNSZone könnte und wird der RODC von dem Windows Server 2003 DC vom Standort B replizieren. Zusätzlich muss dann noch zwei Standortverknüpfungen jeweils von Standort C und D zum Standort A erstellt werden, da die Standortüberbrückung deaktiviert wurde.
-
Servus,
Ich habe hier schon einiges zum ändern von IP-Adressen mit DCs gelesen und es scheint problemlos zu gehen, aber mit dieser Umgebung auch?the same Procedure. Siehe:
Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern
-
Sehe ich genauso, die meisten sollten den Assistenten nutzen mit max. der benutzerdefinierten Variante.
-
Servus,
Du musst den DN immer in Anführungszeichen setzen. Egal ob er leerzeichen enthält oder nicht.morgens, halb zehn in Deutschland... ich habe bereits eine Tasse Kaffee getrunken, was ein Glück...
Weißt du überhaupt von was du da redest?
-
Die Zeiten sind für die meisten Schüler heutzutage vorbei.
Bitte wie meinen bzw. das ist jetzt aber nicht dein Ernst, oder?
Besteht aber immer noch das Problem, das ich zu faul bin alles selbst zu schreiben.Und was willst du nun von uns dazu hören?
Hab leider noch was anders zu erledigen.Da wäre mir kopieren und bearbeiten lieber.Ppfffffffffff.......
-
Nenene. Wenn ich in der Tiefe stecke, dass ich delegieren will, dann sollte ich das Prinzip verstanden haben
Du schreibst es selbst mein Bub... "Wenn...", dann ja. ;)
Das wird er aber nur, wenn er auch die Tasks schon beinhaltet ;)Sag mal kannst du hellsehen oder was?
Genau darüber schreibe ich etwas in meinem nächsten Artikel. ;)
Jedesmal die einzelnen Attribute im Wizard zusammenklicken geht auch nicht schneller als wenn ich direkt reinschaue. ;)Norbi, du darfst nicht immer von dir ausgehen. :) Du weißt selbst das es viel mehr "Anfänger" oder Semi-Professionals im AD-Bereich gibt als Profis. Für viele wird der Assistent einfacher sein, als die Berechtigungen direkt am Objekt zu vergeben, was zwar nichts anderes ist als der Assistent, aber der Assistent nimmt doch einen an der Hand. ;)
Zu Dokumentationszwecken ist sowieso die Verwendung von dsacls zu empfehlen, da ich das was ich falsch gemacht habe, damit ganz schnell wieder rückgängig machen kann. :)Jawoll Herr Leutnant, vollkommen richtig. :)
Abtreten... wegtreten... irgendwohintreten... ach was weiß ich... verschwinden halt. :)
-
Welch eine Ehre, welch ein Ehre...
Daniel, du hier?
Jungs, wo bleibt der rote Teppich?
Schön dich hier zu sehen. ;)
Gruß, Yusuf
-
Momentan sagt mir mein Bauchgefühl, daß ich lieber wie bisher eine Domäne pro Zweigstelle aufsetze. Aber ich will nicht einen strategischen Fehler machen, bloß weil ich mich Neuerungen verschließe oder diese nicht hinreichend kenne.
Mein Bauchgefühl sagt mir aber, dass du besser mit einer einzigen Domäne fahren würdest. Wie gesagt, dass Domänen-Modell kann variieren. Du kannst später wenn du mit dem "Einen-Domänen-Modell" nicht glücklich bist, jederzeit umstellen und Sub-Domänen erstellen. Was die Administration betrifft, kannst du gezielte Berechtigungen im Active Directory an deine Kollegen delegieren. Im AD steckt schon einiges drin. ;)
Siehe:
Yusuf`s Directory - Blog - Objektdelegierungen einrichten
Jetzt kommt aber noch der Aspekt des Windows Server 2008 hinzu, in dem die Domänensicherheit dank des RODCs und Server Core erheblich erhöht wurde. Aber bevor wir hier tiefer in die Materie des Windows Server 2008 einsteigen, lies dir bitte diese Artikel durch:
Yusuf`s Directory - Blog - Windows Server 2008 Core
Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC)
Aber egal wie, du solltest dir für dieses Vorhaben externe Hilfe beiziehen, damit ein entsprechendes Konzept erarbeitet wird.
-
Servus,
auf gehts... ran an das Konzept. ;)
Nun bin ich unsicher, wie ich vorgehen soll. Nur eine große, zweigstellenübergreifende Domäne? Soll dann jeder Niederlassungsserver ein Domänencontroller dieser Domäne sein? Dann hätten wir acht verstreute DCs derselben Domäne... macht das unter ActiveDirectory Sinn?Umso weniger Domänen - desto leichter ist die Administration.
Die Anzahl an Domänen hängt z.B. davon ab, welche IT-Leute betreuen die Domäne. Wenn es die gleichen Admins sind, die den ganzen Forest betreuen, so würde sich ein Single-Domänen Forest anbieten. Denn mehrere Domänen würde man z.B. erstellen, wenn ein Standort seine eigene Sicherheitsgrenze darstellen soll. Aber ein gewiefter Admin aus der Sub-Domäne könnte sich auch Organisations-Admin Rechte erlangen. Das ist zwar nicht trivial, aber möglich. Ein weiterer Vorteil mehrerer Domänen wäre z.B., wenn man unterschiedliche DNS-Namensräume haben möchte.
Ich bin jederzeit ein Freund davon, einen Single-Domänen Forest, also eine Gesamtstruktur bestehend aus einer Domäne zu erstellen und das Unternehmen mit AD-Standorten sowie Organisationseinheiten abzubilden. Da aber jedes Unternehmen ein unikat ist, kann es natürlich je nach Umgebung und Anforderung Abweichungen geben. Wenn z.B. das Thema Sicherheit ganz groß sein soll, dann könnte man z.B. an eine leere Root-Domäne denken oder das erstellen mehrerer Gesamtstrukturen. Es kommt eben auf die Anforderung an.
Fakt ist aber, umso weniger Domänen existieren - desto leichter ist die Administration. Denn schließlich sollte in jeder Domäne gerade wegen der Ausfallsicherheit zwei DCs existieren. Dadurch entstehen hohe Hardware- sowie Softwarekosten.
Der Nachteil bei mehreren Domänen wären:
- Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte.
- Dadurch entstehen hohe Hardware- sowie Lizenzkosten.
- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.
- Jede Domäne muss gesichert werden (Backup).
Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss.
Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration.
Und was ist mit den Dateiablagen. Derzeit hat jede Niederlassung ihre eigene Dateiablage. Den ActiveDirectory-Ansatz verstehe ich so, daß es einen Riesenbaum gibt, wo man dann die einzelnen Teildateiablagen quasi als Unterverzeichnisse reinhängt. Aber daß eine Niederlassung auf die Dateiablage der anderen zugreift, ist in der Realität die Ausnahme, und beim Browsen des Baumes hätten wir dann ständig jede Menge nutzlosen Traffics auf den Fernleitungen, nur um die entfernten Verzeichnisse aufzulisten. Oder sehe ich das falsch?Erstmal hat eine Dateiablage - also ein File-Server - nichts mit dem AD zu tun.
Das AD ist ein Verzeichnisdienst, mit dem das Netzwerk verwaltet wird. Auch in einer AD-Umgebung kannst du weiterhin deinen Fileserver betreiben, wie du es bisher getan hast. Also es kann und sollte an jedem Standort sein eigener Fileserver weiterhin existieren.
... to be continued.
-
natürlich ist eine Gruppe gemeint, also die die die Admin Rechte bekommen soll.
Du drückst dich - für mich - etwas "verquer" aus. Ich möchte jetzt nicht klugsch... sondern nur die richtige Formulierung wiedergeben.
Die Benutzer die in der Gruppe Mitglied sind erhalten keine "Admin Rechte" sondern Rechte im AD eingeräumt, damit sie EINE bestimmte Tätigkeit ausführen können. Denn "Admin Rechte" können mehr. ;)
Wirken soll es lediglich auf die Benutzer.Na klar wirkt die Delegierung nur auf die Benutzer, die Mitglieder der Gruppe sind.
-
Servus,
viel wichtiger wäre es zum einen, anstatt einem Benutzer die Rechte zu delegieren die Rechte an eine Gruppe zu vergeben und zum anderen, ist es wichtig das die Vererbungsoptionen korrekt gesetzt sind. Daher wäre es immer vorteilhaft, den Delegierungsassistenten zu verwenden.
Siehe auch:
-
Moin,
mit ADMT kannst du ebenfalls Gruppen in andere Domänen migrieren:
Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To
-
Salut,
Wird da bei der Auswahl des "Quell-Installation" ein Agent auf diesem Server/PC installiert mit welchem es möglich ist die Konvertierung durchzuführen?genau so ist es, wie soll es auch anders sein.
Wie problematisch ist sowas zum Beispiel bei alten Workstations bzw. Servern (NT4.0)?Hatte ich schon erfolgreich durchgeführt, ist aber keine Garantie das es mit jeder Maschine reibungslos funktioniert.
Es kommt auch darauf an, um welche Hardware es sich dabei handelt.
-
Landeshauptstadt………
Der war nicht an dich gerichtet. Es ist ein Insider.
War es denn so undeutlich?Ich konnte damit nichts anfangen...
Meine Frage ist nur ob ich der AD-Plege „ Datenbankbereingung und Sicherung“ vom Windows aus auf eine bestimmt Zeit legen kann.Dazu gibt es auch eine EventID. Poste die einmal.
-
Aloha,
Kann man die Zeit separat einstellen wann er die Sicherung anstartet. Also nicht am DP da is mir das klar.was meinst du mit "Also nicht am DP da is mir das klar"?
Du schreibst vorher das der DP die Sicherung durchführt, möchtest wissen ob man die Zeit separat einstellen kann aber nicht im DP? Bahnhof?
Bitte klar artikulieren. Deutsch ist doch nicht sooo eine schwere Sprache, oder? Wobei vielleicht für den einen oder anderen Landsmann von der Landeshauptstadt aber schon. ;)
-
nun habe ich festgestellt, dass die Fire Wall ein Abfragen einer externen Zeitgeberquelle nicht zulässt.
Schade aber auch.
Auf der Firewall müsste der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden sollte. Du kannst ja mal nachfragen, dabei gibt es auch kein erwähnenswertes Risiko, denn es ist bisher noch kein Fall bekannt, dass durch einen offenen Port 123 etwas "verbrochen" wurde, was natürlich nichts heißen mag. Wenn es sich einrichten lassen könnte diesen Port auf der Firewall zu öffnen, dann tut es es. Falls nicht, dann eben nicht.
Wie sollte ich dann den w32 Service auf dem DC konfigurieren ?Der PDC-Emulator der Root-Domäne sollte sich zwar entweder mit einer externen Zeitquelle oder aus dem Internet die reale Zeit abgleichen, es ist aber kein muss. Denn die reale Zeit spielt für die interne Domäne keine große Rolle, bzgl. Kerberos. Du kannst nun dem PDC-Emulator der Root-Domäne sagen, dass er die zuverlässige Zeitquelle dieser Gesamtstruktur ist. Dazu schaltest du den Dienst "Windows-Zeitgeber" auf dem PDC-Emulator ab.
Dann solltest du aber für die Zukunft darauf achten, dass die Zeit auf dem PDC-Emu. mit der realen Zeit stimmt und ggf. nachstellen. Es ist aber kein muss. Wie gesagt, zwingend ist das die Synchronisation der Zeit innerhalb des Netzwerks sich nicht um mehr als plus/minus 5 Minuten abweicht, denn ansonsten gibt es Probleme mit den Kerberos-Tickets sowie der AD-Replikation.
Das bedeutet dann, den Befehl für den PDC-Emu bräuchtest du nicht ausführen, aber die restlichen auf den weiteren DCs, Memberservern sowie Clients aber schon.
-
Servus,
RID Master, Schema Master und Domain Naming Master lassen sich nicht (zumindest nicht über die GUI) übertragen.dann machst du etwas verkehrt, denn es können bis auf den RID-Master, ALLE vier FSMO-Rollen über die GUI verschoben werden. Lediglich der RID-Master MUSS zwingend mit NTDSUTIL SEIZE auf den anderen DC übertragen werden. Beachte aber, nach dem "seizen" darf der Ursprungsträger NIE MEHR online gehen.
Für den Domänennamen- sowie Schema-Master musst du folgendermaßen Vorgehen:
Domänennamenmaster:
- Öffne das MMC Active Directory-Domänen und -Vetrauensstellungen.
- Führe einen Rechtsklick auf Active Directory-Domänen und -Vetrauensstellungen aus.
- Klicke auf Verbindung mit Domänencontroller herstellen.
- Wähle den Domänencontroller aus, der die Betriebsmasterfunktion erhalten soll.
- Führe dann einen Rechtsklick auf Active Directory-Domänen und Vetrauensstellungen aus.
- Wähle die Option Betriebsmaster... aus.
- Im darauffolgenden Dialogfeld klickst du auf Ändern.
Schema-Master:
- Öffne Active Directory-Schema
- Rechtsklick auf Active Directory-Schema
- klick auf Domänencontroller ändern
- Domänencontroller auswählen der die Betriebsmasterfunktion bekommen soll
- Rechtsklick auf Active Directory-Schema
- Klick auf Betriebsmaster
- Im erscheinenden Dialogfeld Ändern
Damit das Schema-Snap-In erscheint, musst du vorher die Schema-Management DLL registrieren. Gehe dazu auf START - AUSFÜHREN und gib dort "regsvr32 schmmgmt.dll" ein.
-
Moin Yusuf,
Morsche.
Jetzt möchte ich die anderen DC bearbeiten. Meinst du mit dem _DOMHIER den Namen meiner eigenen Domain ??Ich weiß, es ist verwirrend. Aber ich meine genau den Befehl so wie er da steht nur eben ohne den Unterstrich direkt hintereinander, sonst hätte ich dich schon darauf hingewiesen. Das DOMHIER bedeutet, dass die DOMänen-HIERarchie verwendet werden soll.
-
Es gibt zwei User: Der PC als Resource und der User als Resource. Zu beiden Konten muss eine trustrelationship zwischen Domain und den Konten existieren.
Das hast du aber schön und dazu noch so früh am morgen, formuliert. ;)
Das Passwort ist auch nicht im Profil gespeichert.Genau. Das zwischengespeicherte Benutzerkennwort wird im Security-Zweig in der Registry hinterlegt, in dem der normalsterbliche (auch Administrator) so - verständlicherweise - nicht dran kommt.
@Gulp
Das Computerkontokennwort wird unter NT standardmäßig alle 7 und ab Windows 2000 alle 30 Tage geändert. ;)
-
Muss ich mir Sorgen machen ??
Den Fehler mit der EventID 53258 kannst du vernachlässigen, der ist nicht tragisch. Falls du die Meldung aber los haben möchtest (natürlich willst du das), dann befolge diesen Artikel:
Evtl. verschwindet dann auch der Feler 4193, dass musst du beobachten.
Dann habe ich noch die Merkwürdigkeit dass der time32 Service immer noch die Zeit vom alten DC syncronisiert und nicht vom neuen DCFühre diesen Befehl auf dem neuen PDC-Emulator aus:
w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL
/reliable:YES
Auf den anderen DCs, die nicht die Rolle des PDC-Emulators inne haben, führst du diesen Befehl aus:
w32tm /config /update /syncfromflags:_DOMHIER /reliable:YES
Auf einem Memberserver führst du diesen Befehl aus:
w32tm /config /update /syncfromflags:_DOMHIER /reliable:NO
An einem XP-Client kannst du dann auch diesen Befehl händisch eingeben:
"w32tm /config /update /syncfromflags:_DOMHIER"
Anschließend überprüfe auf den Maschinen das Eventlog.
P.S. Bei den Befehlen darfst du nicht den Unterstrich eingeben!
Wenn ich den Befehl aber ohne den Unterstrich poste, erscheint dieser Smiley :D . Das führt zur Verwirrung.
-
Moin,
Die VM-Ware-Maschine ist ein identischer Clone der realen Maschine (gleicher Rechnername, gleiche SID)ganz schlechte Idee. Du solltest SYSPREP anwenden, alles andere führt früher oder später zu Schiffbruch.
Das Problem, das ich kommen sehe, ist, wenn von einem Rechner das Passwort geändert wird, dann kann sich der andere Client nur noch offline mit dem alten Passwort anmelden, und dann erst online gehen...Das Domänen-Kennwort hat doch nichts mit dem Client zu tun.
Sobald eine Verbindung egal von welchem Domänen-Client zum DC besteht, kannst du dich mit deinem Kennwort anmelden. Dabei spielt es keine Rolle auf welchem Client du das Kennwort geändert hast, denn das Kennwort wird als Hash auf den DCs gespeichert.
-
respekt !! Vielen, vielen Dank für deine tollen Beiträge und für deine immer sehr wertvolle Unterstützung.
Uii... ich bedanke mich sehr für das Lob. :)
Ich kann Also Einfach den alten DC auschalten ?Na klar.
Ich dachte, das ich da mal etwas gehört habe, dass der alte DC nach dem übertragen der Rollen nie wieder in die Domaine gestartet werden darf, bevor er nicht komplett neu aufgesetzt wurde ??Fast richtig. ;)
Wenn du die FSMO-Rollen "mit Gewalt" verschieben würdest, dann dürfte der Ursprungsträger der FSMO-Rollen nie mehr online gehen. Mit Gewalt bedeutet, der DC der die FSMO-Rollen inne hatte ist gecrasht. Die Rollen müssen aber ja trotzdem wieder in der Domäne verfügbar sein, denn ansonsten müsste man die Domäne neu aufsetzen, um die FSMO-Rollen wieder zu bekommen.
Daher muss es natürlich auch in solch einem Fall (DC-Crash) die Möglichkeit geben, trotzdem die Rollen zu verschieben. In solche einem Fall kannst du die Rollen auch über die GUI auf einen anderen DC übertragen, obwohl der Ursprungsträger nicht mehr online ist. Dann werden die Rollen eben mit Gewalt verschoben. Du kannst zwar die Rollen über die GUI verschieben, aber den RID-Master MUSST Du zwingend in der Kommandozeile mit NTDSUTIL - SEIZE übertragen, dieser lässt sich nicht durch die GUI verschieben. Du kannst aber auch alle FSMO-Rollen mit NTDSUTIL verschieben. Der Befehl den du dazu benötigst, lautet: NTDSUTIL - TRANSFER.
Warum darf nun der Ursprungsrollenträger nie mehr online gehen?
Ganz einfach, er bekommt von dieser Aktion in solch einem Fall doch nichts mit. Also, der Ursprungsträger ist - warum auch immer - gecrasht, dann wurden die Rollen "mit Gewalt" auf einen anderen DC verschoben. Ein Kollege hat aber den gecrashten DC repariert (weil nur der CPU-Lüfter defekt war, hat er den Lüfter ausgetauscht). Du fährst der gecrashten DC wieder hoch... und was für einen Zustand hätte man dann? Richtig, es existieren nun zwei DCs die beide ALLE Rollen haben. Jede Rolle existiert nun zwei Mal in der Domäne und das darf eben nie sein, denn ansonsten fängt der Spass erst richtig an. ;)
Gerade wenn man zwei RID-Master in der Domäne hätte, wäre das richtig amüsant.
-
Salut,
Ich wollte jetzt eigentlich alle 5 FSMO's auf den neuen DC moven !! Ist hier eine spezielle Reihenfolge zu beachten ! Kann ich das wärend des Betriebes machen ? Bekommen die Benutzer etwas davon mit ??das verschieben der FSMO-Rollen geht schnell und schmerzlos.
Die Benutzer bekommen von diesem Vorgang nichts mit und du kannst das während dem Betrieb durchführen. Lies dir dazu bitte KOMPLETT diesen Artikel durch, denn dann erfährst du, was für die Durchführung dieser Tätigkeit zu beachten ist:
Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben
Wenn die Rollen dann übertragen sind kann ich doch den alten Server per DCPromo aus dem AD herausnehmen oder ? Muss der alte DC sofort aus dem AD herausgenommen / herabgestuft werden ??Du kannst den DC wenn alle Daten sowie Dienste auf dem anderen DC verschoben wurden, irgendwann mit DCPROMO aus der Domäne nehmen. Aber bevor du das tust, solltest du zumindest noch das EFS-Zertifikat sichern, wenn es der allererste DC in der Domäne sein sollte. Beachte dazu diesen und die weiterführenden Artikeln:
Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen
Danach können sich die Clients dann normal über den neuen DC einloggen oder habe ich da noch etwas zu beachten ?Genau so ist es. Wichtig ist eben, dass auf dem neuen DC sich bereits die DNS-Informationen repliziert haben und den Clients dieser DC als DNS-Server bekannt ist. Zu Testzwecken könntest du ja bevor du den DC herutnerstufst erstmal ausschalten und schauen ob alles so funktioniert wie du es dir vorstellst. Danach kannst du den DC immer noch herunterstufen.
Ach, kleines Problem noch mit WINS !! Läuft bei mir noch auf dem alten DC !! Muss ja auch noch rüber auf den neuen aber wie ??Bemühe doch dazu die Sichmasvhine deines Vertrauen. Da gibt es einige Links dazu. Dieser hier z.B. ist zwar für NT, sollte aber auch weiterhin seine Gültigkeit haben:
How to Move a WINS Database to Another Server
Gibt es einen Befehl mit dem ich die ipconfig von einem entfernten Client abfragen kann ? Zum Test ob auch wirklich alle IP settings auf dem Client auf die neue Server Config verweisen ?Mit PSEXEC z.B.: PsExec v1.92
Abgesehen davon, wenn du den alten DC zwei Wochen aus hast, wirst du schon merken welche IP-Informationen die Clients haben. ;)
-
Servus,
du hast dir den Artikel, den XP-Fan verlinkt hat durchgelesen?
Kennwortrichtlinien die für Domänen-Benutzer gelten sollen, müssen auf Domänen-Ebene, idealerweise in der Default Domain Policy verlinkt werden. Denn wenn du eine Kennwort-Policy auf einer OU verlinkst, betrifft das lediglich die LOKALEN Benutezrkonten auf den Clients.
Bei den Dienst-Konten setzt du in den Benutzereigenschaften den Haken "Kennwort läuft nie ab".
Mehrere Kennwortrichtlinien in EINER Windows Server 2003 Domäne ist so nicht möglich.
Dort müsstest du für jeden Standort eine Sub-Domäne erstellen um mit mehreren Kennwortrichtlinien zu arbeiten. Das funktioniert mit Boardmitteln erst ab Windows Server 2008 und nennt sich dort "Password Settings Objects" kurz PSO. Wenn du unter Windows Server 2003 auch mit mehreren Kennwortrichtlinien arbeiten möchtest, musst du auf Dritt-Anbieter ausweichen:
DNS Server auf DC läuft nicht n_exist domain.
in Windows Forum — Allgemein
Geschrieben
Servus,
das halte ich für keine gute Idee.
Besser wäre es ein dediziertes Domänen-Benutzerkonto dafür zu erstellen.