Daim

Servus, korrekt. Die Frage hast du dir doch schon selbst beantwortet. "Für den Fall der Fälle" sollte man immer ein Backup vom System haben. Allerdings kann ich sagen, dass ich einige 2003 Server auf R2 aktualisiert habe und nie ging etwas schief. Aber wie heißt es so schön: Sag niemals nie ;) . Also diese Frage kannst du dir genauso beantworten. Natürlch kann in der IT immer und zu jederzeit etwas schief gehen. Ich kann nur aus eigener Erfahrung sprechen, dass ich bisher keine Probleme hatte. Nein.

Es heißt R2 und nicht Release Candidate 2! Ist auf den 2003er DCs das DNS installiert und sind auf diesen der GC aktiviert? Werden den Clients die 2003er als weitere DNS-Server mitgeteilt? Wenn ich eines überhaupt nicht mag, dann sind das Angaben zu posten, OHNE die Quelle anzugeben :mad: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Servus, der Benutzer kann zwar in beliebig vielen Gruppen Mitglied sein, aber in das Access-Token des Benutzer können maximal 1.024 SIDs eingetragen werden. Users Who Are Members of More Than 1,015 Groups May Fail Logon Authentication Tatsächlich kann es aber schon weit unter dem Wert (1.024) zu Problemen kommen. Unter Windows 2000 - dort je nach SP-Stand - kann es schon ab 120 Gruppenmitgliedschaften zu Problemen kommen. New resolution for problems with Kerberos authentication when users belong to many groups Group Policy may not be applied to users belonging to many groups Unter Windows Server 2003 kann es schon bei ca. 70 Gruppenmitgliedschaften zu Problemen führen. Noch dazu kommt noch unter Windows Server 2003, dass die SID-History dazu zählt. Microsoft Corporation

Das brauchst du aber auch nicht, denn der DCPROMO-Assistent hätte das für dich gemacht. Zumal du ja jetzt eine primäre "nicht AD-integrierte" Zone hast. Du solltest in den Eigenschaften der FLZ die Zone im AD speichern.

Moin, du kannst dir mit DSACLS die Berchtigungsstruktur ausgeben lassen. Wie Verwenden von Dsacls.exe in Windows Server 2003 und Windows 2000 In diesem Artikel weiter unten, unter dem Punkt Dokumentation findest du ein Beispiel: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Mit DSREVOKE kannst du das ebenfalls erledigen: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Denen hätte ich was erzählt... Scheinbar doch nicht... Microsoft empfiehlt das diverse Rollen zusammenbleiben sollen, da die Aufgaben eng miteinander verzahnt sind. Welche das sind, erfährst du aus dem Link, den ich in meiner ersten Antwort gepostet hatte. Das schon, aber wenn du dir den Link den ich gepostet hatte durchgelesen hättest, wärst du jetzt schlauer.

So wie firefox es bereits geschrieben hatte, du brauchst weder vor dem erstellen einer AD-Domäne, noch nachher irgendetwas wo einzutragen. Das passiert alles automatisch während des heraufstufens zum DC. Den DNS-Namen der AD-Domäne "intra.contoso.com" trägst du erst dann ein, wenn beim heraufstufen des Servers zum DC, der Assistent dich an entsprechender Stelle nach dem DNS-Namen der Domäne fragt. Nur dort trägst du den Namen ein. Der DCPROMO-Assistent erledigt die Arbeit für dich.

Moin, bei der Wahl des richtigen Domänennamen - was ich mit eienr der schwierigsten Aufgaben in einem Unternehmen halte - gilt es einiges zu beachten. Man sollte es z.B. tunlichst vermeiden einen einfachen NAmen zu wählen (z.B. DOMÄNE). Der DNS-Name der AD-Domäne sollte mindestens einen Punkt im Namen enthalten. Richtet man die Domäne mit einem sogenannten single-label Namen ein, kann man das zwar trotzdem zum laufen bekommen (aber nur mit viel Aufwand), bekommt aber in die Zukunft blicken Probleme. Denn in einer single-label Umgebung, wird der Einatz von Exchange Server 2007 nicht unterstützt. Zudem kommt noch hinzu, dass sich das SP1 für Exchange in einer solchen Umgebung nicht installieren lässt. Für die Wahl des Domänen-Namens, gibt es mehrere Varianten. 1. Der Active Directory-Name lautet so wie die Internetdomain. 2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt. Bedeutet, wenn der Inet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante, wäre auch meine empfohlene. 3. Der Active Directory-Name ist ein anderer als die Inet-Domain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.). 4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net. 5. Noch besser wäre die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ. Diese TLDs sind für die private Verwendung reserviert. ISO 3166 - Wikipedia

Servus, müssten die beiden Rollen Infrastrukturmaster sowie RID-Master, die jeweils pro Domäne exitieren, etwa auch auf diesem DC liegen? Oder wurden dieses beiden Rollen zufällig auf einen anderen DC verschoben (warum auch immer) der evtl. zur Zeit nicht erreichbar ist oder der in vergangener Zeit gecrasht ist und diese beiden Rollen einfach vergessen wurden? Werfe sicherheitshalber noch einen Blick in die GUI (Active Directory-Benutzer und -Computer) und kontrolliere was dir bei diesen beiden Rollen für ein Fehler angezeigt wird. Es wäre von Vorteil zu wissen, welcher DC diese beiden Rollen hatte. Denn die beiden Rollen können mit Gewalt auf einen anderen DC verschoben werden. Dabei darf dann aber der Ursprungsträger nie mehr online gehen. Einer der davon betroffenen Rollen, wäre der RID-Master. Wenn un also die beiden Rollen auf einem anderen DC waren, der heute nicht mehr im Netz ist, kannst du die beiden Rollen auf den bestehenden DC mit Gewalt verschieben (sizen). Wie das geht, erfährst du aus diesem Artikel, weit unten: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Des Weiteren sollte natürlich im Netz auch ein globaler Katalog verfügbar sein.

Redundanz in der IT bedeutet, dass eine Ressource mehrfach mit der gleichen Funktion vorhanden ist. Dieses erreicht man bereits ab zwei DCs. Hast du drei DCs, bekommst du eine größere Redundanz. Aber im Fall reiner Infrastruktur-Server wie es eben DCs darstellen, reichen zwei völlig aus. Wichtig dabei ist, dass mindestens das System State vom DC, idealerweise der die FSMO-Rollen trägt, gesichert wird. Mit viel Liebe oder was? Das geht nur, wenn die Rollen auf einem anderen DC mit Gewalt "gesized" werden. Denn dabei bekommt der Ursprungsträger der FSMO-Rollen davon nichts mit und somit wären zwei DCs mit den gleichen Rollen in der gleichen Domäne. Das passiert aber nicht automatisch. DAS muss ein Administrator ausführen. Dann aber... Gute Nacht! Waren da zufällig auch noch die Lotto-Zahlen vom Samstag dabei? ;)

Salut, dem stimme ich zu. Ja, der DC der die FSMO-Rollen hält muss nicht gerade die neuste sein. Aber es kommt auch darauf an, wie intensiv mit dem AD gearbeitet wird. Ich hatte mal eine interessante Unterhaltung per Mail mit einem US-MVP Kollegen, der sich viel in weltweiten Umgebungen mit millionen von Objekten bewegt. Dort kann es durchaus von Vorteil sein, die Rollen zu trennen. Das muss natürlich genaustens untersucht werden. Hierzulande können die Rollen oftmals auf einem DC liegen. Ohhjaa, daswurde bisher noch garnicht erwähnt. Gerade bei der Rolle des RID-Masters ist es von Vorteil.

Servus, in den meisten Umgebungen, sollten die FSMO-Rollen auf einem DC liegen und nicht verzeilt werden. Je nach Umgebung und größe des Netzwerks, kann man aus Last-Gründen die FSMO-Rollen teilen. Aber auch dabei gibt es einiges zu beachten. Einer der Rollen (Infrastrukturmaster) spielt eine wichtige Rolle, im Zusammenspiel mit dem GC. Wenn die Gesamtstruktur lediglich aus einer Domäne besteht, quasi ein Single-Domänen Forest, dann gibt es für den Infrastrukturmaster keine Arbeit und es spielt keine Rolle, ob der DC auch GC ist oder nicht. Denn es existieren ja keine weiteren Domänen von denen Objekte repliziert werden, die der Infrastrukturmaster vergleichen müsste. Existieren in einer Gesamtstruktur mehrere Domänen (Multi-Domänen-Forest), darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC. Siehe: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Na dann hast du aber nicht lange gesucht ;) .

Das wird es nicht. Denn wenn du z.B. die Leiche aus dem AD nicht entfernen würdest, dann würde das Eventlog der DCs überlaufen, weil sie ihren Replikationspartner nicht erreichen konnten. Der Benutzer bekommt davon nichts mit. Edit: DHCP war nicht auf dem DC installiert? Falls doch, muss er noch aus der Liste der autorisierten DHCP-Server.

Korrekt. Wenn dieser Fehler nicht während der täglichen Arbeit protokolliert wird, kann man diesen Fehler der lediglich beim neu starten erscheint, ignorieren. Behalte das aber im Auge und gehe auf Nummer sicher, dass dieser Fehler nur beim neu starten erscheint.

Buenos dias, als Ergänzung: Das geht bereits ab SP2 und einem Hotfix. Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server @ guybrush Aber genau das ist das Problem. Die letzte erfolgreiche Replikation ist bereits zu lange her. Sein gegenüber (Replikationspartner) will vom veralteten DC nichts mehr wissen. Demzufolge kann er seinen Austritt aus dem AD seinem Replikationspartner auch nicht mitteilen. Ein DC muss sich mindestens einmal in der Tombstone Lifetime (TSL) mit seinem Replikationspartner replizieren. Da die Replikation aufgezeichnet wird, blockiert ein DC seine eingehende Replikation, wenn er merkt, dass sein Replikationspartner sich nicht einmal erfolgreich in der TSL repliziert hat. Dann vertraut ihm der gesunde DC nicht mehr und um sich selbst zu schützen, blockiert er die eingehende Replikation vom veralteten DC. Ordnungegemäß heißt hier etwa nicht das gesamte AD (alle Verzeichnispartitionen), sondern z.B. eine einzige Verzeichnispartition. Bei der Replikation wird die letzte Replikation im AD aufgezeichnet. Diese bekommst du z.B. im Replmon angezeigt. Man könnte aber trotzdem einen DC, auf dem die Tombstone Lifetime überschritten wurde, erneut in die Struktur wieder einbinden. Das ist aber mit viel Arbeit und Nerven verbunden. Stichwort: Lingering Objects. Daher kann ich grizzly nur zustimmen, da der DC ohnehin aus der Domäne soll, mache es auf die harte Tour ;) .

Genau so ist es. Auch wenn du ihn irgendwie an den Rechten beschneidest, kann er sich das Recht, wenn er möchte, JEDERZEIT wieder geben. Die einzigste Möglichkeit wäre, den Ordner zu verschlüsseln.

Servus, ein Administrator ist ein Administrator, ist ein Administrator... dieser kann sich immer und jederzeit die Rechte erneut geben. Die Devise lautet, mit delegierten bzw. nicht administariven Rechten zu arbeiten.

Da bist du (neben dem Pfarrer) nicht alleine, der das glaubt ;) . Wenn du an deinem Auto auf der Autobahn bei Tempo 100 einen Platten am Reifen hast und du bereits auf den Felgen fährst, weiss auch niemand so richtig wie lange du damit noch fahren könntest, ohne das dir etwas zustößt. Warum auch? Denn du würdest sofort alle Maßnahmen dazu ergreifen (Rastplatz aufsuchen und Reifen wechseln) um weitere und somit "zukünftige" Schäden zu vermeiden.

Erstens braucht es dir nicht leid tun und zweitens, hatte ich geschrieben "Ohne dir jetzt etwas zu wollen...". Finde ich (wie du merkst) nicht. Sorry - und sehe das bitte erneut nicht persönlich - aber ein MCSE, der ja nunmal ein Netzwerk verwalten kann (sonst wäre er ja kein MCSE), muss sich für mich in den Themen AD sowie DNS auskennen. Dann erläutere mir bitte wie ich es formulieren muss, damit DU dich nicht als ein Bäcker degradiert fühlst. Abgesehen davon halte ich einen Bäcker nicht schlechter oder besser als einen ITler/MCSEler ;) . Bist zu für ein Netzwerk zuständig oder bist du im Consulting Bereich zuständig? Dann MUSST du dich damit auskennen und das gehört eben zum erreichen des MCSEs dazu. Wie bereits erwähnt, natürlich nicht. Deine Frage hatte ich aber auch bereits - min. zum Teil - schon beantwortet. Nein. Nein und was hat denn "jedes Attribut" damit zu tun. Du weißt was die Tombstone Lifetime bedeutet? In diesem Zusammenhang muss man auch noch die "herumlungernde Objekte" in den Raum werfen, die mit der Tombstone Lifetime zusammenhängen. Yusuf`s Directory - Blog - Lingering Objects (veraltete Objekte) Wie sich nun genau das Verhalten, beim rücksichern eines veralteten System States bei nur EINEM DC verhält, kann ich dir nicht wiedergeben. Das brauche ich aber auch nicht, da das ein NO GO ist!

Andersrum, wie das Attribut eben heisst "Tombstone Lifetime". Das ist die Zeit, in dem ein gelöschtes Objekt "Tombstone" (zu deutsch Grabstein) im AD bestehen bleibt, bevor es dann endgültig aus der Datenbank fliegt. Nein das macht er nicht. Das brauchen wir hier aber auch nicht weiter zu vertiefen. Denn, du hattest in deinem ersten Post etwas von "...wäre Gesetz von Microsoft" erwähnt. Wenn man es so will ist es Gesetz, nicht ein Backup zurückzuspielen das die Tombstone Lifetime überschritten hat. Gerade mit Blick auf die Zukunft. P.S. Ohne dir jetzt etwas zu wollen, mit Blick auf deine Signatur solltest du das Thema Backup vom System State bereits verstanden haben.

Ei das hat doch grizzly geschrieben. Ob du den Systemstatus mit NTBACKUP gesichert hattest? Na klar hast du die nach dem POST.

Huhuu, ich will auch meinen Senf dazugeben ;) . Richtig. Mit seinen cached Credentials kann man sich auch nur dann anmelden, wenn das Netzwerkkabel am Client gezogen wurde. Ansonsten meldet der Client den Fehler, dass die Domäne nicht zur Verfügung steht. @blob Also diese Frage erübrigt sich von alleine. Auf welchen Servern läuft denn die Active Directory-Datenbank? Genau, auf dem DC und nicht etwa einem Memberserver. Wenn nun also der einzige DC - was im übrigen grob fahrlässig wäre - in der Domäne ausfällt, kann somit ja auch kein AD zur Verfügung stehen. Leuchtet doch wohl ein, oder? Beim Crash des einzigen DCs, geht sogut wie nichts mehr in der Domäne. Denn die logische Komponente Domäne läuft nunmal lediglich auf der physikalischen Komponente DC, des Active Directorys. Wie gesagt, anmelden geht nur wenn man das Netzwerkkabel zieht. Auf den Mitgliedsservern kann man ebenfalls nicht arbeiten, denn um z.B. auf eine Freigabe zuzugreifen zieht der Memberserver das Access Token des Benutzers heran (in dem alle Gruppenzugehörigkeiten in Form von SIDs enthalten sind) um zu prüfen, welche Berechtigungen des Benutzer erhält. Dieser kann das aber nicht, da zum einen der Benutzer gar kein Token vom DC erhalten hat und zum anderen, der Memberserver selbst garnicht weiß wie er das prüfen könnte, da eben kein DC und somit keine Domäne zur Verfügung steht. So wie grizzly es bereits geschrieben hatte, dann kannst du eben die dementsprechende Aktion nicht durchführen. Wenn z.B. der PDC-Emulator fehlt, dann funktioniert z.B. dieses nicht mehr: - Zeitabgleich - Kein Zugriff bzw. bearbeiten der GPOs - Kennwort-Änderung der Benutzer wird zum Problem - Externe Trusts Ohne RID Master wird eine Zeit lang nichts passieren, da jeder DC ein Kontingent von 500 SIDs zugewiesen bekommt, die er selber verwaltet. Es wird erst dann zu einem Problem, wenn die RIDs verbraucht sind. Denn dann kann der DC kein Objekt mehr erstellen.

Servus, die Variante mit dem autoritativen Restore hat den Vorteil, dass die Objekte eins zu eins wiederhergestellt werden. Bringt allerdings den Nachteil, das der DC zweimal neu gestartet werden muss und während dieser Zeit nicht zur Verfügung steht (da er offline ist). Da gibt es da noch die Variante mit dem Tombstone, den man - sofern die Tombstone Lifetime noch nicht abgelaufen ist . wiederbeleben kann. Das hat den Vorteil, dass dazu der DC nicht neu gestartet werden muss. Bringt aber den Nachteil, dass die meisten Attribute von den Objekten auf ewig entfernt werden. Das bedeutet, beim wiederbeleben eines Tombstones fehlen viele Informationen/Einstellungen. Da könnte man dann aber das Skript Werding einsetzen. Das alles steht in diesem Artikel: Yusuf`s Directory - Blog - Active Directory Wiederherstellung

Aloha, zu allererst sollte ein /aktuelles/ sowie natürlich funktionierendes Backup vom System State existieren. Du musst du im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Was sonst noch alles zu beachten ist und wie du die einzelnen Dienste übernehmen kannst, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Zum Schluss noch eine Empfehlung: Wenn möglich, sollten in jeder Domäne zwei DCs existieren.

Da hat sich unser Daim sehr unglücklich ausgedrückt. Es sollte heißen "Technisch ist das zwar möglich, wird aber eben von seitens Microsoft nicht empfohlen". Das habe ich auch so schon etliche Male geschrieben, ist mit wohl hier in dem Thread durch die Eile beim tippen ein vaux paux unterlaufen ;) .