AD zerschossen durch Freenas installation

[michelo82 12]

Ja wie gesagt tägliche Systemstate Backups und auch komplette Server Sicherung.

[zahni 550]

Wenn ich den 1. DC nicht mehr booten kann...kann MS doch auch nichts machen. Der macht gerade noch ein CHKDSK, weil da auch noch Fehler aufgetreten sind...

 

Och, die können schon, keine Sorge. Sinnvoll ist das Ganze aber nur, wenn nicht versucht mit gesundem Halbwissen das selber zu lösen.

 

Wichtig ist, dass Du den Support genau erzählst, was Du schon alles probiert hast.

 

Ein Kollege hatte vor Jahren mal versehentlich auf einem DC einen sehr Systemstate zurückgesichert (damals mit Arcserve). Der andere DC fand das doof. Der eingeflogene MS-Engineer hat es wieder gerichtet....

[PowerShellAdmin 169]

Ich will hier dem gesagten nicht widersprechen.

Von irgendwelchen Basteleien oder Rücksicherungen würde ich auch erstmal Abstand nehmen.

 

 

Aber wenn auf dem betroffenen DC nur die Rollen, GC laufen, wäre doch ein Umzug der 5 Rollen auf den 2.DC möglich, im Anschluss kann man den 1. DC wieder neu installieren, Promoten und die Rollen verschieben.

Hierzu kann man sich bei Bedarf ja auch einen lokalen Dienstleister zu Beratung hinzuziehen.

Allerdings sind mir die Eintragungen der Freenas ins AD und im DNS ein Dorn im Auge, das müsste ja auch sicher bereinigt werden.

 

Grüße Admin

[zahni 550]

Bist Du Dir sicher, dass der DC nicht schon irgendwann mit den anderen DC's repliziert hat . Als er mit dem FreeNAS gespielt hat ?

 

Nee, wenn das Netz produktiv ist, Support anrufen.

[michelo82 12]

Aber wenn auf dem betroffenen DC nur die Rollen, GC laufen, wäre doch ein Umzug der 5 Rollen auf den 2.DC möglich, im Anschluss kann man den 1. DC wieder neu installieren, Promoten und die Rollen verschieben.

 

Das wäre der nächste Schritt. Die Rollen Offline zu übertragen. Zu allen übel, startet der 1. DC überhaupt nicht mehr. Der Raidcontroller ist wahrscheinlich defekt. Also kommen hier einige Sachen zusammen...

 

Replikation lief noch nicht, da der noch funktioniert.

[PowerShellAdmin 169]

Mach jetzt das Beste draus.

 

Ich denke nicht dass der Raidcontroller grundlos abgeschmiert ist, eher dass die Fehler dank deiner Reboots erzeugt wurden und jetzt der Verbund einen weg hat.

Das übertragen der Rollen löst womöglich aber nicht dein Problem, wenn die Freenas Einstellungen im AD beschädigt hat und der alte DC noch repliziert, dann sieht es bitter aus und du machst noch mehr kaputt...

 

Dadrum erstmal ruhigen Kopf bewahren, der Karren ist erstmal festgesetzt.

Ich würde an erster Stelle alle "Versuche" dokumentieren und die Situation aufschreiben. Im Anschluss rufst du den MS Support an eröffnest einen Call und lässt abwegen wie teuer das Ganze werden kann - kann ich dir nicht sagen.

Es ist auch im Sinne deines Chefs, dass die IT wieder schnell läuft, da hier ja auch Ausfallkosten anfallen, daher auf professionelle Hilfe zurückgreifen.

 

Grüße Admin

 

PS: Hatte hier für 1,5 Jahren auch eine Kleinigkeit am AD, hatte mir zur Sicherheit trotzdem noch nen MS Arbeiter telefonisch/Remote ins Boot geholt.

 

edit:

Bzgl. Replikation lief nicht, das würde ich aber ganz genau prüfen (DNS und ins AD schauen), womöglich noch an andern Punkten.

[iDiddi 27]

Hallo michelo82,

 

Man geht davon aus, dass damit der DC gemeint ist. Dies ist jedoch nicht so, sondern der Hostname von Freenas im AD!

wieso bitte schön geht man davon aus, dass dort der DC rein muss? Für den Server existiert doch ein eigenes Feld! Wie kommst Du darauf, dass Du den zweimal eintragen musst?

 

 

Wenn Du die Hardwareprobleme in den Griff bekommen hast, lies Dir das mal genau durch:

 

FreeNAS forum • View topic - Did I Break Windows 2008 AD with FreeNAS? (Edit: Yes)

 

 

 

Dort wird wie folgt erklärt, was genau Dein FreeNAS da angerichtet hat ...

If you accidentally join your Freenas server to and Active Directory (AD) using the DC name in the Freenas server name field, you will overwrite the computer registration in the AD for this DC. Not completely, but enough to cripple it.

 

To dive right into the actual problem: You existing DC registration is crippled because the userAccountControl attribute is overwritten. This is the most important 'damage' that is done. This attribute determines, amongst a lot of other settings, the role the server has. Look up this attribute on the Microsoft/MSDN site for more details:

 

How to use the UserAccountControl flags to manipulate user account properties

User-Account-Control attribute (Windows)

 

The server you just crippled should have had the following value: Domain controller : 0x82000 (532480). But since you have overwritten this registration with another server, it will probably read: Trusted for delegation : 0x8000 (524288). This is a completely different role and prevents your DC from doing what it should be doing.

 

 

 

...und es wird auch eine Lösung beschrieben:

 

You can correct this by using the ADSI editor to alter the userAccountControl attribute. This is the part where i say that the use of this tool is at your risk. Please make back-ups, safeguard any data on your server and don't try this if you are not completely sure you are experiencing the same problem. This is nothing to be taken lightly.

 

1.Click on Start > Run, type adsiedit.msc in the Open text-box, and click the OK button.

2.In ADSIEDIT, connect to the domain.

3.Navigate to the Domain Controllers OU.

4.Right-click on the domain controller for which you want to change the userAccountControl attribute and select Properties from the pop-up menu.

5.Locate the userAccountControl attribute. The value of the attribute should be something other than 532480. I would suspect it to be 524288.

6.Change the value to 532480 and exit ADSIEDIT.

7.Reboot the DC for which you just changed the attribute

 

If you have several DC's in your network, please give replication time to correct things on its own. If after one hour replication, authentication and all other DC functions are not back up, please correct the exact same attribute on the other DC's too for the Domain Controller that was experiencing the problem and reboot each DC after making the changes. Again allow one hour for replication to restore. If everything is still not working, reboot each server and wait another hour.

 

I think you will find that you Active Directory will come back to online. Please keep checking replication, eventviewer logs and DCDIAG output for errors.

 

Da Du, wie ich Deinen Posts entnehmen kann, nicht vorhast, einen Support-Call bei MS auf zu machen, könnte das Deine letzte (kostengünstige) Rettung sein. Also sei hier sehr vorsichtig. Hol Dir zumindest einen Experten ins Haus und lass Ihn da ran.

 

Viel Vergnügen ;)

[olc 18]

Leute,

 

hier ist viel mehr krumm als "nur" die FreeNAS Fehlkonfiguration. Siehe etwa:

 

Wir hatten schon die edb.chk und ndts.dit vom 2. DC auf den ersten kopiert. Da bootet er aber nur noch mit einem Bluescreen.

 

Allein mit den beschriebenen Aktionen ist es also nicht getan.

 

Manchmal muß man auch eingestehen, daß man selbst oder ein Forum mit mangelnder Kenntnis aller (ggf. kontraproduktiv) durchgeführten Aktionen nicht weiter helfen kann. Und je länger das Spiel hier läuft, umso größer wird ein etwaiger Produktionsausfall.

 

FreeNAS forum • View topic - Did I Break Windows 2008 AD with FreeNAS? (Edit: Yes)

 

Dort wird wie folgt erklärt, was genau Dein FreeNAS da angerichtet hat ...

 

...und es wird auch eine Lösung beschrieben:

 

Da Du, wie ich Deinen Posts entnehmen kann, nicht vorhast, einen Support-Call bei MS auf zu machen, könnte das Deine letzte (kostengünstige) Rettung sein. Also sei hier sehr vorsichtig. Hol Dir zumindest einen Experten ins Haus und lass Ihn da ran.

 

Um die userAccountControl zu überschreiben, würde ich im FreeNAS Setup für einen Domänenbeitritt z.B. Domänen-Admin (!) Rechte benötigen - denn sonst ließe sich das Attribut eines DCs nicht überschreiben.

 

Sollte also tatsächlich ein Domänen- / Org- / DC builtin-Administrator Account verwendet worden sein, stellt sich einmal mehr die Frage, wie viel Fachkenntnis hier vorhanden ist.

 

Wieder ein Punkt mehr darauf hinzuweisen, daß der TO einen Dienstleister oder MS anrufen sollte. Schnellstmöglich.

 

Viele Grüße

olc

[michelo82 12]

Das kann ich dann von dem laufenden 2. DC aus machen :) ?

[iDiddi 27]

@olc: Hast ja Recht.

 

Ich fand halt nur wichtig, dass der TO die Hintergründe kennt oder zumindest dem Dienstleister oder MS weitergeben kann.

 

Das kann ich dann von dem laufenden 2. DC aus machen ?

Wenn Du das noch fragen musst, dann lass es doch besser sein. Wo bleibt noch mal der Dienstleister?

 

Wieder ein Punkt mehr darauf hinzuweisen, daß der TO einen Dienstleister oder MS anrufen sollte. Schnellstmöglich.

Genau meine Meinung

[olc 18]

Ich fand halt nur wichtig, dass der TO die Hintergründe kennt oder zumindest dem Dienstleister oder MS weitergeben kann.

 

Da bin ich absolut bei Dir! :)

[michelo82 12]

Der Raidcontroller ist nicht beschädigt. Allerdings startet der 1. DC, wegen des unsauberen Ausschaltens mit der Meldung:

\windows\system32\config\system

 

Hab dann:

c:\windows\system32\config\system
c:\windows\system32\config\software
c:\windows\system32\config\sam
c:\windows\system32\config\security
c:\windows\system32\config\default

mit den gleichen Dateien aus dem Ordner RegBack ausgetauscht. Danach kam der DC zumindest bis zum CHKDSK...danach wieder:

\windows\system32\config\system

 

Sobald man das CHKDSK abbricht, bootet der Server normal und ich konnte mich anmelden.

 

Das userAccountControl Attribut ist geändert! Vielen Dank!

[iDiddi 27]

Sobald man das CHKDSK abbricht, bootet der Server normal und ich konnte mich anmelden.

 

Das userAccountControl Attribut ist geändert! Vielen Dank!

 

Was heißt das denn jetzt genau? Ist jetzt denn wieder alles in Butter?

 

Falls ja, Glückwunsch. Das war aber von Dir ein Spiel mit dem Feuer und mehr unter "Schwein gehabt" zu verbuchen ;)

 

Aber mal ehrlich: Ich würde dem System nach den ganzen Änderungen nicht mehr vertrauen :(

[michelo82 12]

Was heißt das denn jetzt genau? Ist jetzt denn wieder alles in Butter?

Zumindest startet der 1. DC wieder, Anmeldung als Domänenadmin ist möglich, das Attribut userAccountControl vom 1. DC-Computerobjekts wurde wieder auf den Wert "532480" korrigiert und die Exchange GUI lässt sich wieder aufrufen.

 

DCDIAG liefert beim 1. DC:

 Verzeichnisserverdiagnose Anfangssetup wird ausgefhrt: Der Homese - Pastebin.com

[b]und beim 2. DC:[/b]

[xml] Verzeichnisserverdiagnose Anfangssetup wird ausgefhrt: Der Homese - Pastebin.com

 

:(

 

Aber mal ehrlich: Ich würde dem System nach den ganzen Änderungen nicht mehr vertrauen :(

Ich möchte im nächsten Schritt die FSMO's Online mit ntdsutil auf den 2. DC übertragen und den 1. DC mit DCPROMO aus der Domäne nehmen. Ist es dann auch erforderlich die Metadaten zu "säubern"? Danach möchte ich den 1. DC mit gleichen Namen, sowie gleicher IP wieder aufsetzen und hochstufen.

 

Die Frage ist nur, ob der Exchange das verträgt. Da sich wie gesagt, die GUI erst wieder starten ließ, als der 1. DC Online war. Ich weiß nicht genau warum den Exchange der 2. DC nicht ausgereicht hat, um eine Verbindung zum AD herzustellen (ich Tippe darauf, dass dem 2. DC eben die Betriebsmaster gefehlt haben).

[zahni 550]

Du gibst nicht auf, oder ?

 

Im Ernst: in so einem Fall würde ich auch den Support von MS anrufen.