none
Hardwaretausch an einem 2008R2 DC RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Zusammen,

    ich hoffe, ihr könnt mir noch ein paar denkanstösse geben...

    ich habe hier eine Domain aus 2 DC´s (2003R2 und 2008R2). Beide Systeme laufen zur Zeit und replizieren sich auch ohne Probleme. Am 2008er muss die Hardware getauscht werden. Beide Systeme werden mit ShadowProtect Server VSS-basierend gesichert.

    Nun habe ich ein Restore auf der neuen Hardware gemacht und in den DSRM mode gebootet. Dort habe ich alle nötigen Treiber für Chipsatz und Netzwerkkarten eingerichtete. Die alten und nichtmehr vorhandenen Netzwerkkarten habe ich via "show_nonpresent_devices" angezeigt und deinstalliert.

    Anschliessend habe ich Netzwerksettings (IP/Subnetz/Gateway/DNS) korrigiert und das System heruntergefahren.

    Um es nicht direkt im Produktivnetz ausuprobieren, habe ich den server nur an einen switch angeschlossen und gebotet. Klar hat er kein internet und kann nun auch keine externe DNS namensauflösung. 

    Erfindet natürlich auch nicht den 2003er als DC, trotzdem sollte er mir doch beim netzwerkicon unten rechts anzeigen : Domäne.local - kein internetzugriff

    Was er aber anzeigt ist : unbekanntes Netzwerk - kein Netzwerkzugriff

    Ziehe ich einmal am netzwerkstecker und stecke ihn wieder rein erscheint Domäne.local - kein internetzugriff 

    Ist dieses Verhalten so OK? oder ist das nur so, weil er nicht den 2. DC erreicht?

    Vielen Dank für eure Anregungen...

    Jürgen Ladrik

    Mittwoch, 12. Februar 2014 12:42
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Jürgen

    Warum hast Du Dich entschieden den DC zu restoren?

    Ich sehe keinen Grund für einen Restore in diesem Falle. Einerseits macht es keinen Sinn und anderer seits kannst Du Probleme elegant ausweichen.

    Ich währe wie folgt vorgegangen:
    1. DC bei dem die HW (kommt auch immer darauf an was für HW getaucht wird..) demoten
    2. HW tauschen
    3. OS neu installieren
    4. Dcpromo starten und synchen
    5. Synchronisation etc. überprüfen

    Evlt vor Punkt 1 einen dritten DC aufbauen um z.B. die Ausfallsicherheit zu garantieren. Da stellt sich die Frage ob den DC bei dem die HW gewechselt wird nicht gleich ersetzt werden sollte...

    Da ich Deine restliche Infrastruktur nicht kenne musst Du zuerst beurteilen was ein "demoten" für Auswirkungen auf Deine Umgebung hat.

    Restoren eines DC würde ich nur in einem Disaster Fall (Restore einer Domain oder einem ganzen Forest).

    Gruss Dani

    Mittwoch, 12. Februar 2014 14:38
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Dani,

    Sehe ich genauso. Ein dc restore ist immer Teil eines recovery Szenarios. Ergänzen müßte man nur noch:

    • Prüfung FSMO (netdom)
    • Übertragen der FSMO Rollen auf den verbleibenden dc bzw. Bereitstellen eines weiteren (VM)
    • Dc demote
    • HW tauschen
    • Neu installieren des OS
    • Promoten
    • Ggf. FSMO verteilen

    Sollte das Kind in den Brunnen gefallen sein, was Du Jürgen jetzt auf dem verbliebenen dc prüfen musst. Bleibt noch, das sizen der FSMO Rollen auf den verbliebenen DC.

    Wichtig bei einen 2008 DC: ein DC Restore funktioniert nur mit Voll Backup, kein Systemstate Restore.

    Viele Grüße

    Heiko

    Mittwoch, 12. Februar 2014 15:05
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    Am 12.02.2014 15:38, schrieb dahawei:

    Warum hast Du Dich entschieden den DC zu restoren?

    Weil "x" Abhängigkeiten zum Namen existieren und wahrscheinlich auch "x" Softwarekomponenten darauf installiert sind (nicht nur AD)??

    und der Weg über eine Swing Migration (neuer DC - alter Dc raus - neuer DC umbenennen) nicht wesentlich schneller ist.

    Zudem MUSS ein Restore funktinionieren, das ist also ein prima Test mit Fangnetz. Im echten Worstcase muss du den Weg ja auch gehen. Da ist dein Ausweichweg garnicht erst möglich.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 12. Februar 2014 16:42
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Mark,

    also ich habe mal ein Server 2008 AD Recovery Training bei MS in Unterschleißheim über 3 Tage mitgemacht. das Erste was man da lernt, ist das was oben beschrieben ist. Ein Restore Test mit einem Produktiv Szenario zu mischen ist einfach nur fahrlässig. Weiterhin installiert man auf einem DC keine Software, wenn doch funktioniert die nach dem demote immer noch. Deine Argumentation ist fachlich für mich nicht nachvollziehbar. Und auch wenn Mann einen Restore Test macht, muss man auch den richtigen DC mit den entsprechen FSMO Rollen restoren, sonst macht ein restore keinen Sinn.

    Mittwoch, 12. Februar 2014 17:16
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 12.02.2014 18:16, schrieb Talibaer:

    also ich habe mal ein Server 2008 AD Recovery Training bei MS in
    Unterschleißheim über 3 Tage mitgemacht.

    Vielleicht hättest du es bei einem Dienstleister machen sollen, der dir
    auch sagt, was im realen Leben stattfindet?

    Ein Restore Test mit einem Produktiv Szenario zu mischen ist einfach
    nur fahrlässig.

    Er macht es doch zum Test in einer VM. Sobald das funktioniert kann er
    es in Prod machen. Wo ist das Problem? Deswegen gibt es Backup und Restore.

    Du hast Angst, das es nicht klappt? Dann solltest du mal dein komplettes
    Backup hinterfragen, wenn du dem nicht vertraust.

    Zudem: Er hat doch den 2ten DC. Wenn der erste nach restore sterben
    sollte in der Produktion, dann macht er ein metadata cleanup und macht
    es nochmal.

    Weiterhin installiert man auf einem DC keine Software,

    Aha. Erklär das mal dem Small Business Server ... werde wach und komm
    wieder zuück ins echte Leben. ;-)

    90% aller Kunden haben wenn es hochkommt nur 2 Server, oft nur einer als
    DC, mit Glück beide als DCs und beide mit jeder anderen Software die das Unternehmen braucht.

    Andere Frage:
    Jetzt nach deinem Training, hast du immer noch Angst ein Restore in Prod durchzuführen oder fühlst du dich sicher? Wenn du das Restore eines DCs in Prod immer noch für kritisch hälst, dann ist bei dem Workshop echt zuviel Marketing gelaufen. MS will auch nur Dienstleistung generieren, indem sie vieles als kritisch und hochbrisant erklären, damit der Kunde das auf gar keinen Fall hinterher alleine selbstständig durchführen möchte ... sondern immer jemanden dazuruft/~kauft der das dann macht.

    Das ist nur ein DC, du hast noch einen 2ten. Da passiert nichts.
    Je größer die Umgebung wird, desto eher gehört metadata cleanup zum täglichen Brot. Da ist nichts kritisches dran, wenn du a) einen laufenden 2ten DC hast (keinen RODC :-) und b) ein in alternativer Umgebung vor 5 Minuten getestetes Backup.

    Die einzige Kritische Masse ist Zeit. Die ist aber bei 2 DCs in einer Site stressfrei. Der 2te läuft ja immer noch und läuft und läuft und läuft ...

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 12. Februar 2014 17:54
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Lieber Mark,

    ich bin für sowohl für Server 2003 MCSA, small Business Server  Zertifiziert und MCSA 2012 Server, also lass bitte Deine beleidigende Art, denn hier war nicht die Rede von Small Business Server. Ich bin seit Jahren für Backup Restore, früher im Systemhaus und inhouse, heute inhouse verantwortlich. Was Du schreibst ist einfach Müll!

    Fakt ist, Dani hatte Recht, weiterhin bringt ein Test nur etwas, wenn er das Szenario abbildet das man testen möchte, wofür er schon mal auch den ersten DC klonen müsste und das Environment entsprechend vor konfiguriert.

    Soviel zur Praxis.

    VG

    Heiko


    • Bearbeitet Talibaer Mittwoch, 12. Februar 2014 18:13 SBS
    Mittwoch, 12. Februar 2014 18:12
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Ihr alle und danke für die Stellungnahmen ...

    vielleicht noch ein paar infos:

    grundsätzlich war es mal ein 2003er DC hinzukam eben jener 2008er, den ich jetzt eben"umziehen" lassen möchte.

    ich hatte damals alle FSMO rollen vom 2003er auf den 2008er umgezogen was auch fehlerfrei klappte

    auf dem 2008er sind nur managementwerkzeuge für die domain drauf ( clustermanager / hyper-v-manager ) und ein lizenz-server für den terminalserver

    klar kann ich die neue hardware als neuen dc und danach den alten demoten... 

    aber ich hatte es eben auch - wie schon von euch erkannt - als test einer recovery situation gesehen....

    die eingangsgestellte frage war ja  : ist das verhalten des neu geklonten dc´s in einer abgeschotteten Umgebung ohne 2. dc normal ? 

    gruss

    juergen


    Mittwoch, 12. Februar 2014 19:10
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    Am 12.02.2014 19:12, schrieb Talibaer:

    [...] hier war nicht die Rede von Small Business Server.

    Nein, aber von dem Gebetsmühlenartigem Satz:
    Auf einen DC gibt es keine andere Software.

    Das ist in großen Umgebungen tatsächlich so, aber in den kleinen eben
    nicht. Mit diesem Ansatz entbindet sich Microsoft einfach nur jeglicher
    Verantwortung.
    der eine Grund ist Geld, im Sinne von Support und Gerichtlicher
    Streitwert, der andere ist: DCs müssen austauschbar bleiben,
    hauptsächlich für Betriebssstemupdates (Microsoft nennt sich selbst eine
    "Money driven Company"), warum sollte man sonst einen DC austauschen? Die gehen nicht kaputt.

    Austauschbarkeit, das ist die Erklärung, warum DC restore eine völlig
    unkritische Masse ist. Solange noch einer lebt, passiert nichts.

    "unsuccessful domain controller demotion" das heists nichts anderes als
    "kaputt", die Überschrift ist nur politisch korrekt.

    How to remove data in Active Directory after an unsuccessful domain
    controller demotion
    http://support.microsoft.com/kb/216498/en

    Was Du schreibst ist einfach Müll!

    Wenn ich backup/restore erfolgreich/gescheitert nicht schon viele Male
    gemacht hätte, würde ich dir Recht geben.

    Ich bin nicht bewusst persönlich beleidigend, aber die Boshaftigkeit ist viel besser geeignet auf die Dinge hinzuweisen, die einfach keine Angst machen sollten. Das AD ist an der Stelle das stabilste Konstrukt, was MS je gebaut hat.

    Ich habe in all den Jahren erst eine korrupte Datenbank auf einem DC
    gesehen, der Rest sind nur DNS und Replikationsfehler, die sich alle
    leicht korrigieren lassen.

    Du schreibst ja selber "FSMO ggfs. verteilen", das ist doch genau der Punkt, um den es mir geht: Was soll schon passieren, wenn es nicht geht?
    Dann werden halt die FSMO "geseized" und nicht "transfered", dann gibt es nen metadata cleanup. Fertig.

    Genau darum gehts, ich mach dasselbe wie du, nur mit dem Unterschied, das ich das (bewusst böse gesagt) nicht für hohe Kunst halte, sondern für einfache Handarbeit.

    [...] wofür er schon mal auch den ersten DC klonen müsste

    Och bitte, Cloning ist das einzige NoGo in dem ganzen Scenario, du möchtest doch, das er noch mit seinem 2ten DC reden kann.

    http://www.faq-o-matic.net/2006/08/04/warum-images-nicht-als-datensicherung-taugen/

    Lass dich nicht von mir ägern oder beleidigen, ich mach das nur, weil ich das viel spannender finde, als KB Artikel zu posten.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 12. Februar 2014 22:47
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    Am 12.02.2014 20:10, schrieb Juergen Ladrick:

    ist das verhalten des neu geklonten dc´s in einer abgeschotteten Umgebung ohne 2. dc normal ?

    Ja. Dein Rechner hat sein altes Netzwerk gespeichert anhand der Kombination von Default Gateway MAC Adresse und Subnetz, diese stimmt nicht mit der tatsächlichen Situation überein.

    Sonderfall Vista/2008: Ohne Std.Gatewayeintrag wird das Netzwerk nie erkannt.

    https://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx

    Speziell:
    HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 12. Februar 2014 22:47
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 12.02.2014 23:47, schrieb Mark Heitbrink [MVP]:

    Ja.

    kleiner Test: Änderen mal die IP und das Subnetz auf dem Dc in der VM.
    Nach meiner Theorie sollte es dann gehen :-)

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 13. Februar 2014 08:05
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich möchte mich nicht in Eure Diskussionen betreffend "wer hat nun die beste Zertifizierung etc" sondern Jürgen zu helfen...

    Ich bin nach wie vor der Meinung, dass DC's nur bei einem Ausfall der ganzen Domain oder eines Forest restored werden sollten. Einfach darum, weil so sicher weniger Probleme entstehen. Machbar ist es, das stimmt so aber auch..

    Zum Clonen von DC's, offiziell Unterstützt ab Hyper-V 2012R2 (DC muss als Guest auf diesem System laufen) und auch VMWare v.xxx (weiss nicht genau) hat angekündigt das Cloning zu unterstützen. Ganz kurz und ohne technisches geplänkel.... beim Cloning wird eine separate ID verwendet resp. beim "restore" des Clones wird diese ID überprüft...

    Gruss Dani

    Donnerstag, 13. Februar 2014 14:46
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Moin,

    Am 13.02.2014 15:46, schrieb dahawei:

    Zum Clonen von DC's, offiziell Unterstützt ab Hyper-V 2012R2 (DC muss
    als Guest auf diesem System laufen) und auch VMWare v.xxx

    Ja, aber nur im Idealfall, auf keinen Fall als pauschaler Freibrief.

    Ist Active Directory in Windows Server 2012 wirklich virtualisierungsfest?
    http://www.faq-o-matic.net/2013/09/11/ist-active-directory-in-windows-server-2012-wirklich-virtualisierungsfest/

    was am Ende bedeutet: Images sind keine Lösung für DCs, ausser sie werden als Single Restore wiederverwertet und nach cleanup kommen die fehlenden DCs wieder hinzu.

    a) Cloning ist und bleibt ein NoGo, auch wenn es "manchmal geht". An dem Tag wo ich es brauche kommt Murphy
    b) Restore in Prod kann zu einem Aufräumprozess führen.
    c) Neuer DC ist der einfachste aller Wege
    d) Swing Migration, wenn der neue wieder so heisen muss wie der alte ist auch nicht schneller als b) vor allen, wenn eben doch "x" Software auf dem alten DC lief, die wieder eingerichtet werden muss

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 13. Februar 2014 15:54
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Dani,

    das ist auch der Grund warum ich Dir außdrücklich Recht gegeben habe. Und bei mir stehen keine Titel, Zertifikate usw. in der Signatur. Aber wenn jemand unsachlich und beleidigend agiert, dann muss ich denjenigen auch zurechtweisen.

    Zum fachlichen nur noch soviel. Das Cloning was ich erwähnte ist nicht das Cloning von DC in Server 2012, sondern das man bspw. für Tests eine p2v copy oder eine Copy einer VM macht um dan ein gleichwertiges getrenntes Szenario für Tests hat, jedoch ohne Restore.

    Weiterhin ist auch aus meiner Sicht der so genannte Test von Jürgen völlig unsinnig, da er vorher alle FSMO Rollen verschoben hat und dann einen Restore macht. Dann kann er den Test auch lassen weil es seinen case nicht abbildet.

    Noch ein Wort zu den Einlassungen bezüglich Software usw. auf DC's. Es hat nicht nur finanzielle Gründe warum MS das nicht empfiehlt, sondern beim DC gibt es bspw. keine Lokalen Benutzerobjekte mehr und dies ist ein Grund das Software die bspw. solche Dinge erfordert garnicht installiert werden kann.

    Aber dies war alles nicht das Thema von Jürgen, weshalb ich auf die ersten Antworten verweise.

    Viele Grüße

    Heiko

    Donnerstag, 13. Februar 2014 16:11
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    Am 13.02.2014 17:11, schrieb Talibaer:

    Es hat nicht nur finanzielle Gründe warum MS das nicht empfiehlt,
    sondern beim DC gibt es bspw. keine Lokalen Benutzerobjekte mehr und
    dies ist ein Grund das Software die bspw. solche Dinge erfordert
    garnicht installiert werden kann.

    ich kann es ja nicht lassen:
    Eine Software mit diesem Problem interessiert Microsoft überhaupt
    garnicht, da sie überhaupt nicht mit dem MS Konzept konform geht.
    MS kann nicht die Verantwortung für schlechtprogrammierte Software übernehmen. Technik ist zweitrangig.

    Wenn sie etwas erlauben, müssen sie es supporten, Support ist am Ende wieder Geld.

    Sobald ich irgendeine Software auf den DC installiere ist diese mit großer Wahrscheinlichkeit nicht redundant verfügbar, wenn der DC weg ist. Sie ist nicht in der AD Replikation enthalten. Damit sind wir wieder beim Thema Austauschbarkeit und Ausfallsicherheit.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 13. Februar 2014 17:03
    |
  • Discussion
    Anmelden
    0
    Anmelden
    > technisches geplänkel.... beim Cloning wird eine separate ID verwendet
    > resp. beim "restore" des Clones wird diese ID überprüft...
     
    vmGenerationID... Erkennt die VM, daß sie aus einem Snapshot läuft,
    macht sie (wenn ich das grad noch richtig weiß) automatisch eine
    nichtautorisierende Wiederherstellung.
     
    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Donnerstag, 13. Februar 2014 17:18
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Sorry, aber das Du keine Ahnung hast wusste ich schon vorher, wie wärs mit SCDPM (made bei MS), es gibt genügend andere Printer Management von HP usw., aber mach einfach weiter. Du schwafelst nur rum, seit Server 2008 hab ich keinen DC mehr mit gui aufgestzt, wegen all den Vorteilen die das bringt. Aber egal...

    VG

    Heiko

    Donnerstag, 13. Februar 2014 17:48
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Am 13.02.2014 18:48, schrieb Talibaer:

    wie wärs mit SCDPM (made bei MS), es gibt genügend andere Printer Management von HP

    Findest du es nicht seltsam und irritierend, daß es Software gibt, die 15, bzw. 20 Jahre alte Authentifizierungsmechnismen ignoriert, die lokale Konten erzwingt, weil sie nicht gegen eine Domäne authentifizieren kann und dann behauptet sie wäre Enterprise tauglich?

    Das es solche Software gibt, streite ich ja garnicht ab. Bei DPM ist es ja sogar technisch begründet, aber bei einem Printer Management?
    In so einem Fall ist es immer noch eine schlechte Software, die das Anmeldekonzept ignoriert. Abgesehen von Sonderfällen, wie Zugriff auf Datarecovery, gibt keinen Grund in einer Software nicht beide Anmeldetypen zu berücksichtigen.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Freitag, 14. Februar 2014 08:42
    |