Daim
-
Gesamte Inhalte
4.534 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Daim
-
-
-
Servus outrun,
dann führst du eine INTRA Forest Migration durch, korrekt? Sprich, die Migration der User wird innerhalb *eines* Forests (z.B. von Sub-Domäne zu einer anderen Sub-Domäne innerhalb desselben Forests) durchgeführt. Dabei ist das Verhalten von ADMT korrekt und man kann das nicht verändern.
Führt man mit ADMT eine INTRA-Forest Migration durch, werden nach der Migration die Quell-Objekte gelöscht. Deshalb muss es gut überlegt sein, wann man auf welchen Knopf im ADMT klickt.
Führt man eine INTER Forest Migration durch (eine Migration zwischen zwei Forests), dann werden die Objekte kopiert und die Quell-Objekte bleiben weiterhin erhalten.
Das ADMT Verhalten das du erlebst ist also "by Design" und lässt sich nicht verändern. Ansonsten kannst du auch auf kommerzielle Tools ausweichen (kostet halt ein paar Euronen), wobei ich dann blind Quest nehmen würde...
-
Servus,
vor allem sollte man natürlich beim ändern der Subnetze darauf achten, dass man keine overlapping Subnetze erstellt. Wäre design technisch unschön.
-
-
Servus,
In welchem Modus läuft die Gesamtstruktur und die Domäne?wenn diese Bedingung nicht erfüllt wäre, würde ADPREP eine klare Fehlermeldung diesbzgl. bringen. ;)
@ Luckyluk
Was die Meldung anbetrifft: Go ahead! :cool:
-
Servus,
gibt es eine moglichkeit, eine subdomain sauber aus der gesamtstruktur herauszulösen und komplett als eigenständige domäne weiterlaufen zu lassen ?ja, gibt es. Die Antwort lautet --> Migration, z.B. mit ADMT!
LDAP://Yusufs.Directory.Blog/ - Einen Domänensplitt durchführen
-
Servus,
LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Noch Fragen? Dann fragen. ;)
-
Torsten,
jetzt machst du mich aber ferdisch...
nachdem ich heute zu testen virtuelle Computerkonten aus dem AD gelöscht habe, dachte ich eigentlich das nach einem Neustart des virtuellen Clients der Computername automatisch wieder im AD auftaucht, jenes ist aber nicht der Fall.Warum sollte das Computerkonto denn *automatisch* wieder im AD auftauchen und vor allem, wie kommst du denn darauf? :shock:
Erst nach einem erneuten Domainjoin ist das Computerkonto wieder im AD sichtbar.Ja... logisch...
Was wäre nun wenn ich keinen erneuten Domainjoin machen würde?Wird der Client nach einer bestimmen Zeit aus der Domäne geworfen?
Wenn du das Computerkonto aus dem AD löschst, ist der Client defakto nicht mehr Mitglied der Domäne. Allerdings "glaubt" der Client dann immer noch, dass er Mitglied der Domäne ist, da er nicht "ordnungsgemäß" aus der Domäne entfernt wurde. Du musst dann den Client in eine Arbeitsgruppe nehmen und dann erneut zur Domäne hinzufügen.
Jetzt klar?
-
Servus,
ich bin gerade in einer kleinen Diskussion mit meinem Kollegen, funktioniert es das man aktive Benutzer inkl. Kennwort etc. in eine komplette neues AD umziehen kann?also ihr macht vielleicht Sachen.. ;)
Ja, dass funktioniert. Jedoch muss der Benutzer dazu "migriert" werden, z.B. mit ADMT. Das ist kein Bordmittel, aber Freeware.
LDAP://Yusufs.Directory.Blog/ - Die verschiedenen ADMT Versionen
-
Eine Sache noch, Default ist ja 60 Tage eingestellt, das Log schreibt mir das die letze erfolgreiche Replizierung am 29.06.2011 war...am 30.08.2011 hab ich ihn wieder online gebracht , d.h. es waren exakt 62 Tage dazwsichen...hab ich ja wirklich Pech gehabt :(...******* Motorradunfall *grrrr*
Ahaa... das ist dann wirklich: Dumm gelaufen aber in deinem Fall ja kein größeres Problem. :-)
Du könntest (und solltest) die Tombstone-Lifetime auf 180 Tage setzen. Dabei wächst die AD-Datenank zwar an, da nun gelöschte Objekte länger in der NTDS.DIT verweilen, was aber auf der heutigen Hardware mit den heutigen HDDs kein Problem darstellen sollte.
-
Da ich ja in DE bin und DCPROMO /forceremoval nicht offline machen kann, darf ich / kann ich das auch online machen ? Was hat das für Auswirkungen wenn ich es online mache?
DCPROMO /FORCEREMOVAL macht nichts anderes, als die AD-Daten LOKAL auf dem DC zu entfernen. Mit dieser "gewaltsamen" Variante bekommt eben das AD nichts davon mit und die Informationen über den gewaltsam heruntergestuften DC bleiben weiterhin im AD bestehen. Es existiert dann eine "Leiche" im AD, die es selbstverständlich zu entfernen gilt, in dem man die Metadaten des AD bereinigt.
Du könntest genauso gut den DC ohne DCPROMO /FORCEREMOVAL auszuführen neu installieren. Aber die Metadaten des AD musst du in jedem Fall bereinigen.
-
Servus,
wenn es nicht anders geht, musst du /forceremoval machen. Kann sein, dass das beim Überschreiten der TL immer nötig ist.genau so ist es!
Die Replikationspartner möchten mit diesem DC nicht mehr reden (replizieren). Der DC der jedoch heruntergestuft werden soll, muss sich aber während des herunterstufen ordnungsgemäß von seinen Replikationspartnern verabschieden (der DC muss ja aus den Metadaten des AD entfernt werden). Wenn diese nunmal jegliche Kommunikation mit dem "scheinbar" veralteten DC verweigern, muss man den DC mit Gewalt (DCPROMO /FORCEREMOVAL) herunterstufen und anschließend die Metadaten bereinigen.
Warum jedoch die Fehlermeldung nach so kurzer Zeit erscheint, ist die andere Frage (die mich persönlich brennend interessiert). Vom Aufwand her würde sich die Suche danach nicht rechnen, daher ist das re-promoten die schnellste Variante.
@m1k2k
Einmal wird von Metadaten gesprochen und bei MS von LingeringMit "Metadaten" sind die Daten im AD bzw. das AD selbst gemeint und Lingering Objects sind veraltete/herumlungernde Objekte. Diese entstehen auf einem DC immer dann, wenn dieser sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat.
Aus: LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)
Wie entstehen Lingering Objects (veraltete Objekte)?Die Namensauflösung spielt wie so oft, bei der Replikation eine wichtige Rolle. Denn Windows 2000 sowie Windows Server 2003 Domänencontroller führen vor der eigentlichen Replikation DNS-Lookups durch. Es wird versucht den GUID-Teil des CNAME-Records das sich in der Zone _msdcs.<Root-Domäne> befindet, des Replikationspartners, in eine IP-Adresse aufzulösen.
Somit wird sichergestellt, dass der Replikationspartner erreicht und aufgelöst werden kann. Falls Lookups nicht durchgeführt werden können, kann keine Replikation stattfinden und somit besteht die Gefahr, dass veraltete Objekte entstehen.
Folgende Fehlersituationen können dazu führen, dass ein DC länger keine Replikation durchführen kann:
• Falls keine Netzwerkkonnektivität zur Domäne besteht.
• Wenn sich auf dem DC unbemerkt Replikations-Probleme eingeschlichen haben.
• Die Replikation wegen einer Fehlkonfiguration nicht durchgeführt werden kann.
• Die Namensauflösung nicht ordnungsgemäß funktioniert.
• Bei fehlgeschlagener Authentifizierung oder Autorisierung.
• Die In-Bound (eingehende) Replikation deaktiviert/blockiert ist.
• Ein Problem mit dem Datenbankspeicher besteht (die ausgeführten Transaktionen werden evtl. nicht zeitgerecht abgearbeitet und führen zu Timeouts).
• die Systemuhr bzw. das Datum falsch ist
-
Servus,
jetzt bin ich wohl gefragt. ;)
Vor etwa einem halben Jahr habe ich die strikte Replikationskonsistenz auf allen DCs aktiviertDu sagst es selbst: Du hast die strikte Replikationskonsistenz vor 6 Monaten auf den DAMALS bestehenden DCs - wie auch immer - aktiviert. Wenn du einen "älteren" DC einmal kontrollierst wirst du feststellen, dass die Einstellung auf diesem DC aktiviert ist.
Das hassu aba fein jemacht. :cool:
Nun schaue ich auf den neuen DC und die Option ist wieder nicht gesetzt.Yepp, dass ist in deinem Fall "by Design"!
Wie bekomme ich es hin, dass bei neuen DCs automatisch der Regkey gesetzt wird ?Wie ich es in meinem Artikel auf den du verweist geschrieben habe, ist standardmäßig die strikte Replikationskonsistenz bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn eine Gesamtstruktur
ab Windows Server 2003 erstellt wurde aktiviert.
Eine Gesamtstruktur die mit Windows Server 2003 oder höher installiert wurde, verfügt über eine spezielle operative GUID, der nicht in einer Gesamtstruktur mit Windows 2000 Wurzeln existiert.
Wenn ein Server zum DC hochgestuft wird, überprüft dieser ob die folgende GUID existiert:
CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<forestdomain>
Das bedeutet, damit ab sofort alle künftigen DCs innerhalb der Gesamtstruktur (die von Windows 2000 aktualisiert wurde) automatisch die strikte Replikationskonsistenz aktiviert haben, muss man manuell den operativen GUID in der Konfigurationspartition setzen.
Wie man das durchführt, ist hier erklärt:
Event ID 1388 or 1988: A lingering object is detected: Active Directory
Liegt es daran dass ich von einer Windows 2000 auf eine Windows 2003 Gesamtstruktur geschalten habe und nicht von NT4 kam ?Yepp.
Laut Blog:...ist alles korrekt erläutert!
Wenn du auf allen DCs innerhalb der Gesamtstruktur die strikte Replikationskonsistent aktivieren möchtest, kannst du das ab Windows Server 2003 SP1 mit folgendem REPADMIN-Befehl erledigen: Repadmin /regkey * +strict
P.S. Dazu sollte ich mal was auf meinem Blog schreiben. =)
-
Servus,
kontrolliere unbedingt das DNS und bereinige es ggf. Denn wenn der DC der nun an einen anderen AD-Standort verschoben wurde noch mit seinen Daten am "alten" AD-Standort im DNS eingetragen ist, könnte es zu verzögerten Anmeldeverhalten bei den Clients am alten AD-Standort kommen.
Beachte:
LDAP://Yusufs.Directory.Blog/ - Einen Domänencontroller an einen anderen Standort verschieben
-
Servus,
was für Nachteile hat es, wenn man sein AD um weitere benutzerdefinierte Attribute erweitert?keine, wenn man es "richtig" macht. ;)
Und wie verhaelt es sich beim Hochstufen auf ein 2008er Schema?Och, ganz gut. :cool:
Ohne genauere Angaben verweise ich erstmal hierhin:
LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus
-
Servus,
du könntest zwar auch an der Priorität bzw. Gewichtung in den DNS-Einträgen des DCs drehen, aber wie ist das folgende Zitat zu verstehen?
Allerdings hab ich im Hinterkopf, daß einen DC einfach vom Netz zu nehmen zu Problemen im Domänennetzwerk führen kann.Gerade deshalb "sollte" es zu keinen Problemen in einer Domäne mit mehreren DCs kommen...
-
Aber das haben wir Dir ja alles bereits gesagt. :rolleyes:
Haben wir das? Jaaaa bin schon wech, hab seit neuestem eh keine Zeit. :cool:
-
Ich hatte nichts anderes erwartet. :p :cool:
-
Servus,
Welches Attribut wird bei der Anmeldung eines Benutzers herangezogen?das hängt davon ab, mit welchen Benutzernamen du dich anmeldest. Entweder sAMAccountName oder userPrincipalName.
Der userPrincipalName oder der sAMAccountName oder doch eher das name Attribut?Siehe oben. Das Attribut "name" ist der Name der dir in der Übersicht der MMC "AD-Benutzer und Computer" angezeigt wird.
Siehe dazu:
LDAP://Yusufs.Directory.Blog/ - Die Active Directory-Attribute hinter den Feldnamen
In meinem LDAP Explorer und anderen Anwendungen funktioniert das nicht. Da muss ich den Inhalt des name Attribut angeben...Dann musst du den Hersteller kontaktieren.
...oder liegt das nur an der Anwendung selbst, welches Attribut bei der Anmeldung bzw. Authentifizierung eines Benutzers ran gezogen wird...So ist es. Das scheint die Anwendung so zu wollen. Aber kontaktiere mal den Hersteller, evtl. liegt das auch an einer Einstellung der Applikation.
-
Servus,
wir haben 2. Domain aufgebaut bei der die eine die über domain hält.beide Domänen befinden sich also innerhalb einer Gesamtstruktur, wobei es sich um eine Root- und Subdomäne handelt und keine zwei verschiedenen Domänenstrukturen (Tree) bestehen.
beispiel. überdomain ist wurst.de und die unterdomain heissen hans.wurst.de und klaus.wurst.deAlso ich zähle hier insgesamt --> drei <-- Domänen. Bei der "wurst.de" handelt es sich um die Rootdomäne und bei "hans.wurst.de" sowie "klaus.wurst.de" handelt es sich um zwei Subdomänen, die sich beide unterhalb der Rootdomäne auf der gleichen Ebene befinden.
also hans.wurst.de hält die überdomain weil es wurst.de praktisch nicht gibt.Redest du vom AD oder DNS? Ich vermute AD und das geht nicht. Falls die Rootdomäne nicht mehr existiert, ist die Gesamtstruktur "zerstört"! Wenn dann kein Backup existiert, müsstest du migrieren.
jetzt ist uns hans.wurst.de ausgefallen und logisch hat klaus.wurst.de übernommen.Oha... hier ist dringend "Grundlagen pauken" angesagt! Was soll denn bitte schön die Domäne "klaus.wurst.de" von "hans.wurst.de" übernehmen?
danach haben wir hans.wurst.de neu aufgesetzt dummer weise ist klaus.wurst.de jetzt die über domain und hat keine vertrauens stellung zu hans.wurst.deAn deinen Erläuterungen kann man schwer erkennen, dass du scheinbar noch sehr frisch im Geschäft bist. Den "so" wie du das ganze schilderst ist der Grund, warum bisher auch noch keiner geantwortet hatte. Alle haben dann auf mich gewartet, damit ich dir das sage. ;) :p
ich soll jetzt die domain von klaus.wurst.de neu machen damit die reihenfolge wieder stimmt.Das lässt du mal schön sein und greifst stattdessen zum Hörer! Hole dir einen Dienstleister der das dann hoffentlich wieder für euch richten kann.
1. wenn ich den dc runterstufe werden die anderen server die unter hyper V laufen dann gelöscht auf den server ?2. sind die installieren rollen auf dem server vom runterstufen betroffen ?
Die Antworten hierauf spare ich mir, da du in deinem Post ziemlich viel durcheinander wirfst und das eigentliche Problem ganz woanders liegt.
-
Es ist "Best Practice", dass sich die FSMO-Rollen stets auf dem DC befinden, der das aktuellste OS ausführt.
-
danke für deine Antworten, jedoch frage ich lieber nochmal etwas nach, ich bin bei solchen Sachen lieber zu vorsichtig....
Aber sicher doch, dafür sind wir schließlich hier. ;)
Die FSMO Rollen sind mir soweit bekannt, jedoch ist es doch so, dass jede Rolle nur von einem DC ausgeführt werden kann?Si senior!
Wenn ich nun, wie du geschrieben hast, die Rollen auf den neuen 2008R2 Server verschiebe, bedeutet das doch im Klartext, das der Server 2003R2 nur noch als Redundanz vorhanden ist und theoretisch ohne schlimme Folgen wegfallen kann?Die Redundanz hat man bereits, sobald zwei DCs in der Domäne existieren.
Siehe auch:
LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen
Die Forderung von "weiter oben" ist aber in meinem Fall, dass der Server 2008R2 bei einem Ausfall des Server 2003R2 die Benutzeranmeldungen weiter ermöglicht, bis der Server 2003R2 wieder verfügbar ist; Sprich der Server 2008R2 nur als Redundanz vorhanden ist.Das ist doch gerade der Witz! Wenn zwei DCs existieren und auf beiden das DNS installiert ist, können sich die Clients weiterhin anmelden, wenn ein DC ausfallen sollte. Vorausgesetzt den Clients werden beide DNS-Server mitgeteilt.
-
Das Stichwort lautet: Standortverknüpfungsrücke (site link bridge).
Eine Standortverknüpfungsbrücke dient dazu, eine Verbindung zwischen Standorten herzustellen, die keine direkte Verbindung untereinander besitzen. Wenn du eine Standortverknüpfung einmal zwischen HQ und Seattle, sowie HQ und Amsterdam erstellst, wird durch die Standortverknüpfungsbrücke eine Verbindung zwischen Seattle und Amsterdam erstellt.
Wenn das Routing es nicht zulasen würde das Standorte untereinander direkten Kontakt haben (kein durchgeroutetes Netzwerk auch nicht über die Zentrale), wie es eben bei einer klassischen Hub-and-Spoke Topologie der Fall ist, sollte man die Standortverknüpfungsbrücke deaktivieren.
Ohnehin ist das arbeiten mit Standortverknüpfungsbrücken erst mit mindestens drei Standorten möglich, wobei zwei Standorte dabei keine direkte Verbindung untereinander aufweisen, was bei dir ja der Fall ist.
Eine Standortverknüpfungsbrücke dient quasi als Routing für die zu replizierenden Daten.
Ist die Standortverknüpfungsbrücke deaktiviert, gibst du durch die Standortverknüpfung genau vor, welcher Standort mit welchem Standort replizieren soll. Dadurch steuerst du exakt die Replikation der Standorte. Damit wirst du deine Fehlermeldungen los.
Die Standortverknüpfungsbrücke kannst du in der MMC "AD-Standorte und -Dienste" deaktivieren. Navigiere dazu zum Container "Inter-Site Transports" und rufe mit einem Rechtsklick, die Eigenschaften des Containers "IP" auf. Dort kannst du dann die Option "Brücke zwischen allen Standortverknüpfungen herstellen" deaktivieren".
Falls du DFS-N im Einsatz haben solltest, darfst du die Standortverknüpfungsbrücke *nicht* über den IP Container deaktivieren, sondern musst mit dem Befehl "repadmin /siteoptions W2K3_BRIDGES_REQUIRED" die Standortverknüpfungsbrücke deaktivieren.
-
Servus,
wenn du das Computerkonto zurücksetzt, wirfst du automatisch den Client aus der Domäne. Anschließend musst du den Client erneut zur Domäne hinzufügen (joinen).
Frage zur Thematik DC
in Windows Server Forum
Geschrieben
Servus,
ich mach mal Nils in früheren Jahren. :D
So soo… und deine Glaskugel verrät dir also, das die Tombstone-Lifetime auf 180 und nicht mit 60 konfiguriert ist? Denn der Titel lautet: "2K3 - Frage zur Thematik DC". Jahaa... ich weiß auch das der Titel nicht immer was zu bedeuten hat.
Ich wollt ja nur mal päpstlicher sein als Nils. ;)