Daim

Servus, das halte ich für keine gute Idee. Besser wäre es ein dediziertes Domänen-Benutzerkonto dafür zu erstellen.

Aloha, ohh ein Hesse. das ist soweit korrekt. Das könnte zwar sein, da die Seite seit der Beta existiert, aber die Grafik ist soweit korrekt. Nein, nicht zwangsläufig. Es ist eine Frage des Netzwerkdesigns. Ja, so könnte es auch aussehen. Vor deiner Grafik steht aber auch der Satz: Zitat: 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, 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, 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?

Bitte wie meinen bzw. das ist jetzt aber nicht dein Ernst, oder? Und was willst du nun von uns dazu hören? Ppfffffffffff.......

Du schreibst es selbst mein Bub... "Wenn...", dann ja. ;) Sag mal kannst du hellsehen oder was? Genau darüber schreibe ich etwas in meinem nächsten Artikel. ;) 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. ;) 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

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 - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen 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. ;) 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. 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.

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. ;) 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: Yusuf`s Directory - Blog - Objektdelegierungen einrichten

Moin, mit ADMT kannst du ebenfalls Gruppen in andere Domänen migrieren: Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Salut, genau so ist es, wie soll es auch anders sein. 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.

Der war nicht an dich gerichtet. Es ist ein Insider. Ich konnte damit nichts anfangen... Dazu gibt es auch eine EventID. Poste die einmal.

Aloha, 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. ;)

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. 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, 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.

Morsche. 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.

Das hast du aber schön und dazu noch so früh am morgen, formuliert. ;) 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. ;) How to disable automatic machine account password changes

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: Event ID 53258 is logged in Event Viewer after you install or remove Active Directory in Windows Server 2003 Evtl. verschwindet dann auch der Feler 4193, dass musst du beobachten. Fü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, ganz schlechte Idee. Du solltest SYSPREP anwenden, alles andere führt früher oder später zu Schiffbruch. 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.

Uii... ich bedanke mich sehr für das Lob. :) Na klar. 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, 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 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 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. 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 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: Gruppenrichtlinien - Übersicht, FAQ und Tutorials