Jump to content
Sign in to follow this  
haeckle

Schemaänderung durch Rücksicherung vom Systemstatus möglich.

Recommended Posts

Hallo,

 

ist es möglich, dass man durch Rücksicherung des Systemstatus folgendes Beheben kann:

 

1) Zu Testzwecken wurde ein Server al DC einer vorhandenen Domäne aufgesetzt.

2) Durch ein Mißgeschik ist er in den laufenden Betrieb gelandet.

3) Als das festgestellt wurde, hat man ihn sofort vom Netz genommen.

4) Nun hat dieser DC den eigentichen DC verdrängt. D.h. die Betriebsmasterrollen und Schemamaster lauten nun auf den Testserver.

5) Der eigentliche DC ist nun offline, bzw. er arbeitet nicht mehr korrekt.

5) Ich habe noch eine Sicherung von gestern, bei der auch der aktuelle Systemstatus des

eigentlichen DC gesichert wurde.

6) Kann ich den Fehler beheben, indem ich den Systemstatus zurücksicher?

Bin dankbar für jede Hilfe.

Share this post


Link to post

Welcher DC läuft denn nun noch? Evtl. solltest Du in Deiner Beschreibung die DCs nummerieren.

Btw, wie kann ein DC den anderen 'verdrängen', von allein doch wohl nicht :suspect:

Share this post


Link to post

Hi,

 

sorry!

also nochmal:

 

DC 1 > Standard DC (Erster DC der Domäne)

DC 2 > Test DC

(Es gibt auch einen DC3, als Backup für die Domäne)

 

DC 2 wurde wie DC 1 Konfiguriert. Es sollte dort eine Exchange DB repariert werden.

Durch ein Mißgeschick hing der DC2, ohne es zu Bemerken, in laufenden Betrieb.

Plötzlich gab es bei DC1 Probleme, und es wurde festgestellt, dass die Betriebsmasterrollen etc. nun den DC2 eingetragen hatte. DC1 ist unter AD Benutzer-und Computer etc. nicht erreichbar. Im DC3 habe ich dann bei AD Benutzer-und Computer festgestellt, dass dort der die Rollen nun auf DC2 lauten.

DC2 wurde sofort aus dem Netz genommen.

 

Kann ich nun mit Rücksicherung des Systemstauts dieses Problem beheben?

Share this post


Link to post

Hallo,

 

1) Genau deswegen würde ich eine Testumgebung immer lösgelöst von der produktiven neu aufbauen.

 

2) siehe 1)

 

3) ist er wirklich weg? Das ist für die Lösung dieses Problems wichtig

 

4) kein DC "verdrängt" einen andern. Und die Betriebsmaster holt er sich auch nicht automatisch. Wie hat die die FSMOs bekommen. Wurden die ihm, als er noch losgelöst von der Produktivumgebung war, per seize übergeben? Dann hast du ein Problem, weil dann eine zeitlang jeweils doppelte FSMOs vorhanden waren.

 

5) Würde durch die Theorie bei 4) erklärt.

 

5) Bevor du was tust, sollten wir genauere Infos haben. Gab es je 2 FSMOs? Dann musst du den Restore machen. Wenn die Rollen einfach auf den Testserver verschoben wurden, dann kannst du sie auch per ntdsutil und seize wieder zurückholen.

 

6)Gibt es nur einen DC? Sonst müsstest du einen authoritativen Restore machen.

 

 

Mit dem Schema hat das alles übrigens wenig zu tun.

Share this post


Link to post
Hi,

 

sorry!

also nochmal:

 

DC 1 > Standard DC (Erster DC der Domäne)

DC 2 > Test DC

(Es gibt auch einen DC3, als Backup für die Domäne)

 

DC 2 wurde wie DC 1 Konfiguriert. Es sollte dort eine Exchange DB repariert werden.

Durch ein Mißgeschick hing der DC2, ohne es zu Bemerken, in laufenden Betrieb.

Plötzlich gab es bei DC1 Probleme, und es wurde festgestellt, dass die Betriebsmasterrollen etc. nun den DC2 eingetragen hatte. DC1 ist unter AD Benutzer-und Computer etc. nicht erreichbar. Im DC3 habe ich dann bei AD Benutzer-und Computer festgestellt, dass dort der die Rollen nun auf DC2 lauten.

DC2 wurde sofort aus dem Netz genommen.

 

Kann ich nun mit Rücksicherung des Systemstauts dieses Problem beheben?

 

 

Wie habt ihr den DC2 ins Leben gerufen? Habt ihr ihn in der Domäne installiert und dann rausgenommen?

Share this post


Link to post

Wenn die FSMO-Rollen wirklich alle auf dem DC2 gelandet sind, könntest Du

1. beide (DC2 und DC3) ins Netz hängen,

2. die Rollen sauber auf DC3 verschieben,

3. DC2 sauber demoten

4. DC1 neu aufsetzten

Share this post


Link to post

Hi Woiza,

 

wir haben den DC2 separat, als ersten DC der Domäne installiert, wie halt DC1, der erster DC der Domäne ist.

Als erstes habe ich den DC2 in die Domäne aufgenommen, ohne Dcpromo auszuführen.

Ich wolle die Exchangedateien (16GB) per Netzwerk auf den DC2 schieben.

Dann habe ich DC2 vom Netz genommen und mit Dcpromo konfiguriert und Exchange aufgespielt. Zum Schluß habe ich von Band noch den Systemstatus vom DC1 auf den DC2 gespielt, damit DC1 und DC2 identisch sind (Fast gleiche Hardware vorhanden)

Irgenwann müssen beide, im Netzgewesen sein. Und ich bin mir ganz sicher, das ich beim heraufstufen den DC2, diesem vom Netz hatte.

Nun habe ich halt die beschriebenen Probleme.

Im übrigen habe ich nun auch noch das Problem, dass der DC2, nach einspielen des Systemstauts von DC1 nun nicht mehr hochfährt, das ein inaccessible_boot_device vorhanden ist.

 

Ich kapier nur nicht, warum dann auf einmal die Rollen des ersten DC weg waren?

Share this post


Link to post
Wenn die FSMO-Rollen wirklich alle auf dem DC2 gelandet sind, könntest Du

1. beide (DC2 und DC3) ins Netz hängen,

2. die Rollen sauber auf DC3 verschieben,

3. DC2 sauber demoten

4. DC1 neu aufsetzten

 

Aber reicht es denn nicht, dass der DC2 vom Netz ist und ich den Systemstatus zurücksichere.

Damit ist doch auch das komplette AD zurückgesichert, oder?

Dc3 sollte sich dann wieder mit DC1 replizieren und gut ist, oder sehe ich da was falsch?

Wo kann eine solche Rücksicherung scheitern?

Share this post


Link to post
Hallo,

 

1) Genau deswegen würde ich eine Testumgebung immer lösgelöst von der produktiven neu aufbauen.

 

2) siehe 1)

 

3) ist er wirklich weg? Das ist für die Lösung dieses Problems wichtig

 

4) kein DC "verdrängt" einen andern. Und die Betriebsmaster holt er sich auch nicht automatisch. Wie hat die die FSMOs bekommen. Wurden die ihm, als er noch losgelöst von der Produktivumgebung war, per seize übergeben? Dann hast du ein Problem, weil dann eine zeitlang jeweils doppelte FSMOs vorhanden waren.

 

5) Würde durch die Theorie bei 4) erklärt.

 

5) Bevor du was tust, sollten wir genauere Infos haben. Gab es je 2 FSMOs? Dann musst du den Restore machen. Wenn die Rollen einfach auf den Testserver verschoben wurden, dann kannst du sie auch per ntdsutil und seize wieder zurückholen.

 

6)Gibt es nur einen DC? Sonst müsstest du einen authoritativen Restore machen.

 

 

Mit dem Schema hat das alles übrigens wenig zu tun.

 

Hi,

 

1 und 2:

Ja, ich war wohl sehr unachtsam.

 

3)

DC2 ist definitiv nicht mehr da.

 

4) Ich denke das ich beim Dcpromo vom DC2, noch im Netz gewesen sein muss.

Dann gab es zu diesem Zeitpunkt zwei Domänen mit dem gleichen Namen und beide haben dann auch die FSMO-Rollen für eine gleichlautende Domäne.

 

5)

Das war wohl der Fall.

 

5)

Wie kann ich feststellen, ob es je zwei FSMO´s gegeben hat?

 

6) Es gibt noch einen DC, ich nenne ihn DC3 in der Domäne. Bei dem konnte ich halt feststellen, dass dort als Betriebsmaster nun der Testserver DC2 eingetragen ist.

Was versteht man unter authorativen Restore, bzw. wie muss ich da vorgehen?

 

7)

Wie gehe ich am besten nun vor?

 

Meine vorstellung nun:

a) Alle User vom Netz

b) DC3, zweiter DC der DC auch vom Netz nehmen

c) Systemstatus zurücksichern

d) DC1 hochfahren und überprüfen

e) DC3 hochfahren und Replikation erzwingen. (Ändern sich daurch automatisch die Rollen auf DC3?

 

Ist das so Sinnvoll?

Share this post


Link to post

Halt, stop!

 

Hast du DC2 in die Domäne hineininstalliert oder neu installiert, weil im zweiten Fall hättest du keine doppelten oder verschobenen oder sonstwie FSMOs. Zwei DCs gleichnamiger Domänen, die separat installiert wurden, haben nix miteinander zu tun. Dann können auch keine Rollen verschoben werden.

Share this post


Link to post

Hi,

 

also:

 

1) Zuerst habe ich DC2 in die Domäne aufgenommen, um die Dateien zu kopieren.

2) Dann habe ich DC2 vom Netz genommen, so dachte ich zumindes!

2) Dann habe ich DC2 per Dcpromo zum DC seiner eingenen Domäne gemacht.

Der Domänenname war bzw. ist in beiden fällen gleich!

Share this post


Link to post
Nach dem Schlamassel wäre m.E. ein seize der FSMO-Rollen (Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller) auf DC3 und eine Neuinstallation und dcpromo von DC1 die beste Variante, um schnell wieder ein sauberes System zu bekommen. Die Wiederherstellung des Exchange steht dann aber noch auf einem anderen Blatt ...

 

 

Hi,

 

warum ist denn ein Zurücksichern des Systemstatus für Dich keine Alternative? Dann müßte

doch DC1 wieder sauber sein und auf DC3 kann ich dann mit Ntdsutil die Rollen erzwingen, oder?

Share this post


Link to post

Servus,

 

ich darf mich mal einklinken.

 

ist es möglich, dass man durch Rücksicherung des Systemstatus folgendes Beheben kann:

 

hast Du überhaupt eine Schemaänderung durchgeführt und wenn ja, welche ?

 

1) Zu Testzwecken wurde ein Server al DC einer vorhandenen Domäne aufgesetzt.

2) Durch ein Mißgeschik ist er in den laufenden Betrieb gelandet.

3) Als das festgestellt wurde, hat man ihn sofort vom Netz genommen.

4) Nun hat dieser DC den eigentichen DC verdrängt. D.h. die Betriebsmasterrollen und Schemamaster lauten nun auf den Testserver.

 

Das erläuterst Du bitte mal genauer.

Die FSMO-Rollen verschieben sich nicht vonalleine. Entweder werden diese ordnungsgemäß online übertragen (TRANSFER) oder mit Gewalt verschben (seize).

Aber sie wandern nicht von alleine auf einen anderen DC.

 

6) Kann ich den Fehler beheben, indem ich den Systemstatus zurücksicher?

 

Schildere genauer Dein Vorgehen und beantworte meine Fragen.

Share this post


Link to post
Hi,

 

warum ist denn ein Zurücksichern des Systemstatus für Dich keine Alternative? Dann müßte

doch DC1 wieder sauber sein und auf DC3 kann ich dann mit Ntdsutil die Rollen erzwingen, oder?

Ich sage ja nicht, dass das Rücksicher des Systemstate nicht klappen kann ... vom Gefühl her würde ich es aber machen wie beschrieben.

Wenn Du rücksicherst, solltest Du im DNS auch noch mal dei Service-Einträge (unter _msdcs) checken und ggf. korrigieren.

Share this post


Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...