Jump to content

AD zerschossen durch Freenas installation


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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....

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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 ;)

Link zu diesem Kommentar

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

Link zu diesem Kommentar

@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

Link zu diesem Kommentar

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!

Link zu diesem Kommentar
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 :(

Link zu diesem Kommentar
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).

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...