Daim

Nur damit ich nicht falsch verstanden werden, ich behaupte nicht das die Gruppe DNSUpdateProxy überflüssig ist.

Wie Ulf es in seinem Artikel erläutert gibt es durchaus Situationen in denen diese Gruppe ihre Verwendung findet.

Aber sie sollte nicht in meinem geschilderten Fall (DHCP auf einem DC der DDNS durchführt) verwendet werden, was auch nicht notwendig ist.

Siehe: DHCP, DNS and the DNSUpdateProxy-Group - Directory Services/Active Directory

Buenos tardes,

Die Gruppe wird unter bestimmten Umständen auch bei 2003 empfohlen. Damit dann aber bei Benutzung der Gruppe das mit den Secure Updates klappt, sollte ein zusätzlicher Account im DHCP eingetragen werden. Hier ist genaueres dazu zu finden:

trotzdem verharre ich weiter und bin anderer Meinung (wie Südländer eben so sind). ;-)

Die MS-Artikel die du nennst sind mir samt allen anderen x Artikeln bezgl. der Gruppe DNSUpdateProxy bekannt. Überall steht gerade in Bezug auf DNSUpdateProxy das ganze eher verwirrend drin, wie ich finde.

Rollen wir das ganze doch von vorne auf.

Die Gruppe DNSUpdateProxy wurde zu Zeiten Windows 2000 eingeführt, da damals auch noch nicht die Möglichkeit bestand ein dediziertes Konto im DHCP zu hinterlegen, dass für das DDNS-Update verwendet werden konnte und man sich der Gefahr die sich daraus ergab nicht bewußt war. Das Problem stellt bezgl. des ADs das DNS dar, sei es, dass unsichere oder aber auch nur sichere DDNS Updates erlaubt werden. Fakt ist, dass DNS stellt einfach ein (sei es ein großes oder kleines) Sicherheitsrisiko dar.

Sicherheitsfanatiker sehen es als vertretbar, lediglich das DNS zusätzlich auf einem DC zu installieren, nicht aber das DHCP. Denn umso weniger Dienste auf einem DC laufen, desto weniger bietet sich dem Angreifer eine Angriffsfläche dar.

Das Problem das mit dem DHCP auf einem DC im Zusammenhang mit dem DDNS besteht wäre folgendes:

Der DHCP-Server der auf einem DC installiert wurde, sollte eigentlich nur die Einträge verändern/entfernen können, die er verständlicherweise auch selbst angelegt hat. Auf einem DC kann der DHCP aber alle Einträge bearbeiten, weil die Privilegien von dem Konto LOCALSYSTEM es ihm erlauben.

Wenn nun also ein Client mit dem Namen TEST vom DHCP-Server eine DHCP-Adresse anfordert und der DHCP-Server so konfiguriert ist, das DDNS-Update

durchzuführen, überschreibt dieser ggf. den vorherigen Eintrag TEST. Das ist aber doof, wenn das DDNS-Update von einem Server durchgeführt werden soll - das Ergebnis einer DoS, ggf. auch einer Man-in-the-Middle Attacke ist.

Dieser Artikel beschreibt das Problem mit dem DHCP auf einem DC:

Installing Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) on a Domain Controller

Fakt ist, dass DNS ist mit sicheren oder unsicheren DDNS-Updates so oder so nicht sicher.

Worauf ich nun hinaus möchte; In den MS-Artikeln wird das Sicherheitsproblem mit der Gruppe DNSUpdateProxy überall beschrieben und das zusätzlich ein dediziertes Benutzerkonto hinzugefügt werden soll.

Da kann ich nur sagen, dann nutze ich die Gruppe DNSUpdateProxy erst garnicht und füge trotzdem ein dediziertes Domänen-Benutzerkonto im DHCP hinzu, das für das DDNS im DHCP hinterlegt und genutzt werden kann. Somit geht mir der Eigentümer der DNS-Einträge bei einem DHCP-Server crash nicht verloren. Dieses dedizierte Konto kann ich dann auf weitere DHCP-Server in der Domäne hinterlegen.

Das sind meine zwei türkische Lira dazu ;) .

Servus,

Wenn sich der Benutzer wieder anmeldet bekommt er dann das gleiche Profil mit seinen ganzen Einstellungen und so wieder?

natürlich nicht. Denn Namen sind in der IT "Schall und Rauch".

Wenn du einen neuen Benutzer mit dem gleichen Benutzernamen einrichtest, erhält dieser trotz des gleichen Namen, eine neue SID und das ist das entscheidende. Somit bekommt das neue Benutzerkonto auch ein neues Profil. Das lässt sich aber wieder richten.

Interessant wäre noch zu wissen, passiert das immer mit dem gleichen Benutzer auf dem gleichen Client?

Finde heraus was passiert, wenn sich ein anderer Benutzer an dem Client anmeldet. Tritt dabei das Problem erneut auf?

Teste weiter, der Benutzer bei dem es auftritt soll sich an einem anderen Client anmelden usw. usf.

Was spricht das Eventlog auf dem Client?

Versuche es einzugrenzen. Mein Schuss aus der Hüfte sagt Computerkonto.

Moin,

Dann gibt es da noch die Gruppe "DNSUpdateProxy". Da muss der DHCP-Server dann auch noch Mitglied sein. Dann klappt's auch mit den sicheren Updates.:D

die Gruppe "DNSUpdateProxy" sollte unter Windows Server 2003 nicht genutzt werden. Diese wurde unter Windows 2000 eingeführt, da es dort nicht die Möglichkeit gab, ein dediziertes Benutzerkonto unter dem die DNS-Updates durchgeführt werden sollten anzugeben, wie es unter Windows Server 2003 möglich ist.

Unter Windows Server 2003 sollte ein dediziertes Domänen-Benutzerkonto erstellt werden, der im DHCP eingetragen wird.

Servus,

eine Frage: Kann ich einen 2003 SBS auf einen 2003 SBS migrieren.

ja. Wie? Dann fang hier an ;) :

Microsoft Corporation

Salut,

Willst du ne Schritt für Schrittanleitung,

genau so sieht es aus mein Bub. ;)

Nun leg mal los und zwar "zz" (ziemlich zügig) :D

Moin,

du weißt schon, auf was Norbert verwiesen hat (auch wenn dieser Fehler schon Meterhohen Staub drauf hat) ?

Dies nennt man einen Hyperlink, auf den auch drauf geklickt werden kann.

Anschließend öffnet sich eine Webseite mit weiterführenden Informationen.

Nun gilt es die erschienen Informationen zu lesen, zu verarbeiten, zu kontrollieren und falls es zutreffen sollte, zu beseitigen.

Ist es denn Richtig, das sich nun keiner mehr anmelden kann, solange die FSMO´s noch nicht gezeizt sind ?

Nein, nicht richtig. Die FSMO-Rollen haben mit der Benutzeranmeldung überhaupt nichts zu tun.

DAs Netzwerk funktioniert OHNE die FSMO-Rollen weiterhin. Erst bei der Ausführung einer Tätigkeit die eine FSMO-Rolle benötigt, merkt man das fehlen der FSMO-Rollen.

Wenn 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

Wenn der RID-Master fehlt und die DCs ihre 500 RIDs aufgebraucht haben, können keine Objekte mehr erstellt werden.

Wenn der Schema-Master fehlt, können keine Schemaänderungen durchgeführt werden usw. usf.

Der Benutzer merkt in seiner Arbeit nicht im geringsten das fehlen der FSMO-Rollen.

Servus,

ich will auch meinen Senf dazu geben ;) .

Das AD befindet sich bereits dank der AD-Replikation auf den anderen beiden DCs.

Daher brauchst du dir darüber keine Gedanken machen.

Auf die FSMO-Rollen die du benötigst, haben die Kollegen bereits verwiesen.

Wichtig wäre noch, dass auf den anderen beiden DCs ebenfalls der GC aktiviert werden sollte.

Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC)

Abgesehen davon musst du natürlich noch die Dienste (WINS, DHCP etc.) die auf dem gecrashten DC liefen, auf die anderen DCs nun neu installieren. Wenn der DHCP auf diesem lief, musst du den noch aus der Liste der autorisierten DHCP-Server entfernen. Das kannst du aber so nicht ohne weiteres. Wie das geht, erfährst du erst, wenn meine These zutrifft.

Servus,

ich vermute das hier der Hase im DNS begraben liegt...

Kannst du in der Quell-Domäne einen Ping auf den Domänennamen erfolgreich absetzen?

Wenn der FQDN der Domäne "intra.contoso.com lautet" funktioniert dann ein "Ping intra.contoso.com" ?

Servus,

Mööööp: Falsch. Hier gewinnt der, der auf Reihenfolge -1- steht.

genau so ist es.

Die Priorität ist von oben nach unten, also wird von unten nach oben abgearbeitet ;) .

Servus,

Wie muß am besten die DNS Einstellung aussehen für die Domänencontroller.

Best Practice ist es, in jedemfall die Forward Lookup Zone (FLZ) AD-integriert zu speichern. Dies ist aber nur dann möglich, wenn das DNS auf einem DC installiert wird. Denn damit brauchst du dich nicht um die synchronisation bzw. Replikation der DNS-Informationen zu kümmern. Wenn die DNS-Daten im AD gespeichert werden, erledigt die AD-Replikation für dich den Rest. Zusätzlich kannst du dann von der Einstellung "Nur sichere" Updates profitieren. Somit läufst du keine Gefahr, dass fremde Clients deinen DNS-Server kompromitieren können (theoretisch).

Auf beiden läuft DNS. Sollte sich jeder als primären DNS Server din stehen haben und als sekundären dann den 2. Domänencontroller.

Dabei streiten sich auch die Geister, trotz der bestehenden Microsoft-Artikeln. ;)

Die relevanten Informationen kannst du aus dem Artikel, den phoenixcp verlinkt hat entnehmen.

Es gibt dabei auch Unterschiede zwischen Windows 2000 und Windows Server 2003.

Was man auch oft in der Praxis sieht, ist die Überkreuz-Eeinstellung.

Bedeutet, auf dem ersten DC trägst du den zweiten DC ans "Bevorzugten DNS-Server" und sich selbst als zweiten DNS-Server ein und auf dem zweiten DC, trägst du das in umgekehrter Reihenfolge ein.

Ist es Sinnvoll alle Rollen auf dem 1. Domänencontroller zu belassen?

Ja, ist es. In den meisten Umgebungen sollten alle FSMO-Rollen auf EINEM DC liegen.

Lediglich in großen Umgebungen, wo sehr viel AD-lastig gearbeitet wird, macht es unter Umständen Sinn die Rollen zu trennen. Aber auch wenn die Rollen getrennt werden sollten, gilt es einiges dazu zu beachten:

Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Wie kann ich testen ob das DNS zum Globalen Katalog funktioniert?

Anders herum, wenn es nicht funktionieren würde, würdest du es im Eventlog protokolliert bekommen.

Ansonsten kannst du die Windows Support Tools DCDIAG, NetDIAG und das mächtige DNSLint ausführen. Du musst dich dann eben mit den Tools auseinandersetzen.

Okay. Es hat etwas lange gedauert, aber ich habe kapiert, denke ich.

Das denke ich aber nicht.

Also dann mal richtig ausgedrückt: Den konkreten Beitrag zu den FSMO's aus diesem Blog würde ich so nicht empfehlen. Warum, wurde schon gesagt.

Dann hast du leider nicht viel mitgenommen!

Den technischen Sachverhalt den ich in diesem Thread, in der ausführlicheren Version geschrieben habe, wird exakt so nur mit anderen Worten, präzise auch in dem unten stehenden Artikel beschrieben. Man muss diesen evtl. mehrfach lesen, aber es steht das gleiche drin, wie ich es hier bereits wiedergegeben habe.

Denn ich erinnere, es geht um das Szenario wann auf dem Infrastrukturmaster der GC aktiviert werden darf. Genau diese Antwort, erhälst du aus diesem Artikel (nur verstehen muss man ihn):

Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Server,

schau dir entweder den EventComb oder das mächtigere Log Parser an.

Von seiner Vielfältigkeit her, wäre der Log Parser prätestiniert.

Download details: Log Parser 2.2

ScriptCenter Tools: Log Parser 2.2

List of features available in the Event Comb tool

Och man Daim. Ich lad dich zu ner Runde Kartenspielen ein! Und der, der auf den Karten die größten Zahlen stehen hat (Domänen, Standorte, Beiträge usw.), der gewinnt. Okay?

Was soll das jetzt schon wieder?

Du hast das Umfeld erwähnt in dem du dich bewegst, dann darf ich das wohl doch auch.

Abgesehen davon habe ich alles technische geschildert.

Wenn du immer noch anderer Meinung bist, dann ist das legitim.

Ob es richtig ist oder nicht, steht auf einem anderen Blatt.

1) Habe ich eben einen Pcasso angepinkelt, oder was? Ich kann auch nur meine Meinung äußern. Erstaunlich, was man damit lostreten kann ...

Deine Meinung kannst du natürlich äussern, nur sollte sie Hand und Fuss haben.

Eben auch nach KB-Artikeln, MOC und diesen ganzen Mist.

Jetzt trittst du erneut in die ...

4) Ich weiss nicht, ob Ihr schon mal in einem Umfeld mit vielen verteilten Standorten und geringen WAN-Bandbreiten gearbeitet habt.

Tagtäglich.

Da kann man nicht mit solchen Konstrukten arbeiten, von wegen alle DC in einer Domäne ein GC.

Doch, dass kann man sehr wohl.

Denn die AD-Replikation kann sogar über eine 56Kb Leitung stattfinden, diese benötigt eben nur länger. Abgesehen davon, wird auf einem DC der GC aktiviert, so entsteht lediglich bei der Initialreplikation der GC Informationen etwas Replikationslast. Wenn ansonsten nicht AD-lastig gearbeitet wird, kann die GC-Replikation vernachlässigt werden.

Und um es gleich vorneweg zu nehmen: Der Bridgehead ändert da auch nicht viel.

Was soll der Bridgehead-Server mit dem GC zu tun haben...

Dieser ist lediglich zum einen für den standortübergreifenden Transport zuständig und zum anderen für das verteilen der AD-Daten innerhalb des Standorts.

In diesem Zusammenhang halte ich es nicht für fair, einem, der sich offenbar nicht so mit den Rollen auskennt, so etwas unkommentiert zu empfehlen.

Genauso wenig wie ich es für nicht fair halte, wenn jemand ohne das er die Quelle kennt, sich noch nicht einmal die Mühe macht herauszufinden, wie vertrauenswürdig die Quelle denn ist.

5) Zum Hintergrund: Ich konzeptioniere, baue und administriere erfolgreich eine ständig wachsende Umgebung mit z.Z. 12 Domänen, 7 Standorten, zig

Übertreffe ich um längen.

6)@Daim

Danke für den Ausszug. Kenne ich schon. Aber auch dann, wenn alle DC gleich GC sind, meckert der Infra im Eventlog dies an. Propbier es einfach aus.

Ich brauche es 1.) nicht auszuprobieren, denn ich habe es Live vor mir und 2.) solltest du schon deine Hausaufgaben machen.

Wenn in einer Domäne mit mehreren DCs der GC auf dem Infrastrukturmaster aktiviert ist, wird die Event-ID 1419 protokolliert. Diese wird dann alle x Minuten immer und immer wieder protokolliert, bis... du entweder den Infrastrtukrumaster auf einen anderen DC verschoben hast der KEIN GC ist oder du auf dem anderen DC ebenfalls den GC aktiviert hast.

Du möchtest sicher einen Microsoft-Artikel dazu... bitte schön:

Event ID 1419 Generated on a Domain Controller

Ich bewege mich gerade in einem Multi-Domänen Forest in dem ALLE DCs der Gesamtstruktur (> 40) GC sind und was spricht das Eventlog?

Rein garnichts.

Ich hoffe, ich habe jetzt nicht schon wieder irgendjemanden auf den Schlips getreten?

Hättest du diesen Satz nicht oder anders beschrieben:

Ich halte diese Blog für nicht empfehlenswert!

hätten die darauffolgenden Antworten anders geklungen.

Ein Kollege von mir beschreibt das gleiche wie ich, mit diesen Worten:

faq-o-matic.net » Globaler Katalog vs. Infrastruktur-Master

Ich kann diesen Mhytos mit dem GC und dem Infrastrukturmaster bald nicht mehr lesen, geschweige denn dazu etwas schreiben.

Hoppla. Bei allem Respekt! Aber kannst Du mir das bitte mal mit ein paar MS-Artikeln belegen?

Ist schon klar. Schon wieder jemand der einem nur etwas glaubt, wenn es mit einem Artikel von Microsoft bestätigt wurde... Ist erstmal eine gesunde Einstellung, aber die Quellen solltest du kennen und vorallem wissen, wem du glauben kannst und wem nicht!

Das geht gehen alles, was ich bei MS bisher darüber gelesen habe!

Da gebe ich dir TEILWEISE recht. Microsoft hat das sehr oft in sehr vielen Artikeln falsch dargestellt.

Das haben sie aber mittlerweile wieder korrigiert.

Und jahrelang unterrichtet ...

Dann hättest du es besser wissen müssen...

Im übrigen meckert Windows im Eventlog permanent, wenn beide Funktionen auf einem Server sind. Warum wohl?

Genau, aber nur dann, wenn das wie in dem verlinkten Artikel von Stephan nicht so ist!

Ich halte diese Blog für nicht empfehlenswert!

Das kannst DU gerne tun und lassen wie du möchtest.

Ich frage mich, ob DU dich richtig auf deine Schüler vorbereitest!

Ach noch etwas, du wolltest einen Microsoft-Artikel... dann lies selbst:

As a general rule, the infrastructure master should be located on a nonglobal catalog server that has a direct connection object to some global catalog in the forest, preferably in the same Active Directory site. Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold. Two exceptions to the "do not place the infrastructure master on a global catalog server" rule are:

 

• Single domain forest:

 

In a forest that contains a single Active Directory domain, there are no phantoms, and so the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

 

• Multidomain forest where every domain controller in a domain holds the global catalog:

 

If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain.

Quelle: FSMO placement and optimization on Active Directory domain controllers

Noch irgendwelche Anmerkungen?

Servus,

GC & Infrastructure master dürfen nicht zusammen auf einem DC sein. Ausgenommen man hat nur einen DC.

siehe Stephans brilliante Antwort. ;)

Auf wievielen DCs darf maximal der Globale Katalog einer Domäne installiert sein ?

Auf allen.

Habe hier 2DCs. Einer trägt die FSMOs und beide haben den Globalen Katalog.

Ist dies in Ordnung? Kann es zu Problemen kommen?

Das ist in Ordnung, denn wenn es das nicht wäre, würdest du sofort im Verzeichnisdienstprotokoll eine entsprechende Fehlermeldung diesbezüglich erhalten. Was genau die "Spezialitäten" des GC und des Infrastrukturmasters sind, entnimmst du bitte aus dem Artikel, auf den Stephan verlinkt hat. Dort ist der entscheidende Absatz, in der zweiten Aufzählung Punkt 3.

Servus,

Eine Weiterleitung konfiguriere ich, wenn externe DNS-Namen aufgelöst werden sollen, richtig?

stimmt.

Bei der bedingten Weiterleitung gebe ich die Domäne an und eine oder mehrere IP's, richtig?

Bei einer bedingten Weiterleitung gibst du direkt vor, dass Anfragen zu einer bestimmten Domäne an die angegebene IP-Adressen weitergeleitet werden soll. Die bedingte Weiterleitung steht auch erst ab Windows Server 2003 zur Verfügung.

Wie sieht aber eine Normale (Standard-)Weiterleitung aus?

Da gebe ich ja dann keine Domänen an, aber muss ich ich dann unten eine IP angeben? Wenn ja, zu welche Domäne gehört dann die IP?

Es ist immer empfohlen, eine Weiterleitung einzurichten (in den Eigenschaften des DNS-Server, die Einstellung "Alle anderen DNS-Domänen"), nämlich idealerweise auf die IP des Routers. Es wird auch oft empfohlen das eine Weiterleitung auf die IP-Adresse des DNS-Servers vom ISP eingetragen werden sollte. Das hat aber den kleinen Nachteil (bei SoHo), dass wenn der ISP die IP-Adresse ändern sollte, du davon nichts mitbekommst.

Und die Stammhinweise im Internet lösen doch auch externe Namen auf, oder?

Ja, denn genau genommen, brauchst du keine Weiterleitung zu konfigurieren. Die Stammhinweise, dem Volksmund auch als Root-Server bekannt, reichen aus. Nur konfiguriert man trotzdem eine Weiterleitung, da die Stammhinweise nicht so schnell antworten als z.B. der DNS-Server vom ISP. Aber technisch würde es auch nur mit den Stammhinweisen funktionieren.

Das bedeutet also, hast du eine bedingte Weiterleitung an die Domäne "Contoso.com" konfiguriert und der DNS-Server erhält eine Anfrage vom Client, die die Domäne Contoso.com betrifft, so leitet der DNS-Server direkt die Anfrage an den autorisierenden DNS-Server der Domäne Contoso.com weiter. Dieser beantwortet dann die Anfrage.

Wenn der Client eine Anfrage stellt die z.B. ins Internet geht, so schaut der DNS-Serevr zuerst nach ob eine Weiterleitung konfiguriert wurde und verweist dann auf diesen. Falls keine Weiterleitung konfiguriert ist, schickt der DNS-Server die Anfrage an die Stammhinweise.

Servus,

ändere zuerst die IP-Adresse des DCs und bereinige anschließend die Dienste DNS sowie WINS.

Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

der alte Server ist gecrasht und wurde wohl nicht richtig aus der AD im Nachhinein rausgekratzt.

Dann denke daran, die Leiche noch mit NTDSUTIL oder ADSIEdit aus dem AD zu entfernen.

Befolge dabei diesen Artikel:

How to remove data in Active Directory after an unsuccessful domain controller demotion

Servus,

Gibts ein Tool, mit dem man Serverweise diese Leichen auslesen und löschen kann?

setze dich mit dem Tool SUBINACL auseinander.

faq-o-matic.net » Wie halte ich die ACLs auf meinem Fileserver sauber?

Hello,

Ich denke es wäre am besten den Memberserver am entfernten Standort zum DC zu machen und ihm ein eigenes Subnetz zu geben, aber wie mache ich das real am besten. Hat jemand einen schönen Link wie man es z.B. beim Thema DNS am besten macht?

also, bevor du im AD rumschraubst, muss natürlich das Routing stehen und der Standort IP-technisch von der Zentrale aus erreichbar sein (du errinnerst dich an das OSI-Layer Modell?) ;) .

Wenn IP-mäßig alles in Ordnung ist, deklariere den Memberserver zum zusätzlichen Domänencontroller der bereits bestehenden Domäne (DCPROMO ausführen und die Option "zusätzlichen DC..." wählen).

Was es zu beachten gilt, wenn ein weiterer DC installiert werden soll, erfährst du aus deisem Artikel:

Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Das wichtigste ist, die Forward Lookup Zone im DNS sollte AD-integriert gespeichert sein. Dann erledigt die AD-Replikation den Rest für dich. Du musst dich nach dem Heraufstufen des DCs lediglich gedulden bis die Replikation stattgefunden hat. Anschlie0end stehen dir die AD- samt DNS-Informationen auf dem neuen DC zur Verfügung.

Richte dann im Snap-In "Active Directory-Standorte und -Dienste" einen Standort samt Subnetz ein und verschiebe den DC an seinen Standort. Aktualisiere danach die Standortverknüpfung. Vorallem musst du beim verschieben eines DCs an einen anderen Standort, unbedingt danach das DNS bereinigen. Ansonsten kann es zu langen Anmeldezeiten an den Clients führen.

Yusuf`s Directory - Blog - Domänencontroller am Standort

Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben

Aber wenn vor Ort der DC nicht physikalisch sicher steht, dann solltet ihr evtl. vor Ort keinen DC aufstellen und sich die Benutzer an dem DC in der Zentrale authentifizieren lassen. Natürlich hängt das davon ab, welche Leitung zur Verfügung steht (Bandbreite und Stabilität) und was alles über die Leitung geht.

Der Nachteil an dieser Variante ist, wenn die WAN-Leitung unterbrochen wäre, könnten sich die Benutzer nicht am dem DC authentifizieren. Lediglich das anmelden mit ihren zwischengespeicherten Benutzerinformationen wäre möglich. Diese Variante solltet ihr evtl. genauer prüfen.

Oder wenn ihr zu Windows Server 2008 migrieren solltet, ist genau für dein Szenario, der Windows Server 2008 RODC gedacht.

Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC)

mit ntdsutil.exe den Befehl seize rid master abgesetzt.

Eieieii... warum den mit Gewalt, also "seize"?

Ich hatte doch extra geschrieben:

Ansonsten verschiebe diese beiden explizit mit "transfer" über NTDSUTIL erneut auf den anderen DC.

Statt "seize" hättest du "transfer" verwenden sollen. Natürlich funktioniet TRANSFER nur, wenn der Ursprungsträger noch online ist.

Denn gerade der RID-Master darf nie und nimmer zweimal in der Domäne existieren. Oder existiert der Ursprungsträger der FSMO-Rollen garnicht mehr in der Domäne? Dann wäre das ok. Falls er doch existiert, überprüfe auf dem anderen DC, wer nun in der GUI als RID-Master angezeigt wird.

folgend Meldungen kommen:

Ahh ok, anhand dieser Info wird bestätigt, dass der Ursprungsträger nicht mehr zu erreichen ist. Dann geht das mit "seize" in Ordnung.

Sehe ich richtig das das RID-Problem jetzt behoben ist?

Exakto Mundo. Denn trotz der Angabe von "seize" wird trotzdem versucht die Rolle online zu verschieben, was eben fehlschlägt wenn der Ursprungsträger nicht mehr zu erreichen ist. Daher kommt das die irritierende Fehlermeldung wobai dann aber am Ende die Rolle trotzdem verschoben wird. Das hätte Microsoft besser geschickter lösen sollen, denn die Meldung irrtiert viele, gerade wenn man das nicht jeden Tag ausführt.

Beim erneuten Ausführen es dcdiag /v schlagen jetzt nur noch kccevent und systemlog fehl der rest geht mit passed durch..

Der Test beim Systemlog prüft, ob es Fehlermeldungen in den letzten 60 Minuten im Ereignisprotokoll gab. Was den KCCEVENT Test betrifft, ist auch alles im Snap-In "Standorte und Dienste" alles sauber konfiguriert (jeder DC steht an seinem Standort, Subnetze sind erstellt und mit den entsprechenden Standorten verknüpft, richtige Zuordnung der Standorte in den Standortverknüpfungen)

Aber nun nochmals zum mitschreiben:

Wurde der Ursprungsträger der FSMO-Rollen sauber mit DCPROMO aus der Domäne entfernt oder ist dieser gecrasht?

-KnowOfRoleHolder

Bei diesem Test wird geprüft, ob sich der Domänencontroller zu allen fünf FSMO-Rollen im Active Directory, verbinden konnte, die sich entweder auf ihm selbst oder auf einem anderen Domänencontroller befinden. Es leuchtet unmittelbar ein, dass dieser Test selbstverständlich mit einem "passed" beendet werden muss.

-kccevent

Dieser Test stellt sicher, dass der Knowledge Consistency Checker auf dem Domänencontroller auf dem er läuft, alle weiteren Domänencontroller finden kann, um Replikationsverbindungen aufzubauen.

ist der Infrastrukturmaster = der KnowOfRoleHolder oder hab ich noch andere Probs in der Domäne -von denen ich noch nichts ahne :-((

Nein, die KnowOfRoleHolder sind alle fünf FSMO-Rollen, nicht nur einer.

Stelle erst einmal sicher, dass die beiden fehlenden Rollen ordnungsgemäß angezeigt werden. Führe dazu das durch, was ich in meiner vorherigen Antwort geschrieben hatte und lies dir auch den Artikel durch, den ich gepostet habe.

Erstmal vielen vielen Dank für Deine Hilfe!!!

Das du behebbare Probleme hast, die beide zusammenhängen. ;)