Pipeline

wir haben in den RZ jeweils die selben Netzbereiche, daher gibt es nur eine AD Site

Wir haben in beiden RZ je einen DC. Bislang wuppen die sehr gut den Workload. Trotzdem überlegen wir zusätzlich einen DC in unserem VM Cluster laufen zu lassen. Interessant, warum denn sogar fünf? Ist das nur wegen der Pferde vor der Apotheke oder hat das technisch einen konkreten Vorteil?

Moin, erneut vielen Dank für eure Gedanken, Meinungen und Erfahrungen. Auf einige Punkte möchte ich eben eingehen, da ich meine Ausgangslage scheinbar schlecht beschrieben habe. Zunächst weil ich teils andere Begriffe verwende als im HyperV, wir nutzen den XenServer (Citrix) als Hypervisor. Es sind bis auf einen Server nur noch VMs bei uns (außer die Hosts ). Wilder Mix aus insgesamt 460 VMs, Windows und Linux, sogar mehr Linux, mit dem AD verbunden davon ca. 140 Wir haben natürlich nicht nur einen DC, und die laufen entkoppelt auf separaten Hosts die nicht im Virtualisierungs-Cluster sind und nicht vom AD abhängig sind. Schöne Sichtweise und bestärkt mich diese Fragen nach dem Gedankenspiel dann auch praktisch zu erproben. Denn ja, die Frage der Dauer ist spannend, da ich aber eh nicht weiß welchen Vorfall wir erleiden immer nur ein Baustein. Wir werden im Ende dann ja auch verschiedene Restore Wege haben. Und in dem Szenario ist erstmal entscheidend, dass ein Weg überhaupt funktioniert. Der schnelle wird dann vermutlich der mit der DR Kopie sein. Unsere VM-Backups liegen neben dem aktiven Datenbestand und dann erste Kopie in einem zusätzlichen separaten Storage, dann noch in der klassischen Datensicherung die separiert ist und schlussendlich auch noch per Tape gesichert und im Bunker ausgelagert wird. Wir haben da schon eine Menge an Sicherungen. Nur der unabhängige Restore des AD wurde halt bislang dann nicht hinterfragt... Nein, nein. Das wird bei uns nicht mal als Notlösung in Betracht gezogen. Wir stellen uns da richtige Serverhardware hin. Unsere Kunden rufen per Haftbarhaltung so schnell große Summen bei Störungen auf, da ist der Preis für ein paar Server mehr in Relation komplett zu vernachlässigen. Gar nichts, siehe oben, wir haben einen zweiten ich denke hier das Szenario durch, beide DC und die Hosts sind schrott. Meine DR Kopie entspricht einem Replikat. Grüße Stefan

Vielen Dank für eure Antworten! Ihr seid super. Ja ich wollte da gar nicht den Eindruck erwecken meine Idee ist neu, nur findet man hauptsächlich Anleitungen die entsprechend etwas komplexere weil differenziertere Wiederherstellungen beschreiben. Ich habe jetzt hier nur diesen einen Fall beschrieben. Natürlich fahren wir mehrgleisig und wollen mehre Möglichkeiten zur Hand haben da ja nie vorher bekannt ist welchen Vorfall man erlebt. File- und Systemstate Backup ist vorhanden, bislang nur mit Backup Software. Ich werde das onboard Windows Backup ergänzen. Das mit dem "da gabelt sich der Weg" ist genau der Kern, ja. Der Cyber-Vorfall ist sicherlich sehr eklig, weil in der Regel (zu) lange unklar und das Vertrauen verloren ist. Die DR Kopie ist hier nur ein Mittel die komplett ohne Abhängigkeiten nutzbar ist. Danke für den Tipp, war mir noch gar nicht untergekommen. Und @NilsK ja, "einfach" endet dann bei einem echten Vorfall und dem nötigen Restore. Ich finde deine Formulierung : richtig gut, schön griffig und trifft den Punkt. Daher werde ich versuchen eine gute Testumgebung einzurichten und Restore Varianten zu testen. Jedoch kenne ich die Herausforderung zu einer guten Testumgebung, diese muss halt "mit Leben gefüllt" werden sonst hat das keine Aussagekraft. Und für umfangreiche Testumgebungen in denen auch Testbetrieb läuft sind wir mit unseren Admin-Ressourcen zu knapp. Gruß Stefan

Moin zusammen, ich weiß, AD bzw. DC Restore ist ein oft diskutiertes Thema. Ich habe dazu auch eine Menge gelesen. Doch ich möchte hier einmal kurz unser Gedankenspiel (Szenario) für einen Notfall beschreiben und eine ganz provokant simple Lösung von euch bewerten lassen. Denn alles was ich gelesen habe ist aufwändig und bringt diverse Voraussetzungen mit. Ich vermute, da sich nur Admins mit großen komplexen ADs diese Gedanken machen gibt es auch nur entsprechende Anleitungen. Szenario: Vorab: nur zwei DCs und diese sind virtuell Kein MS Exchange AD ist recht klein und simpel: nur eine Domain nur ein Forest, ca. 300 User, 60 Server, 350 Client PCs, 30 GPOs, sehr seltene Änderungen (höchstens mal neue User) alle FSMO Rollen auf einem DC, beide DC sind auch GC DNS ist AD integiert und beide DC sind als DNS auf den Servern und Clients hinterlegt Notfall tritt ein: DCs schrott (warum auch immer, nur mal angenommen, komplett schrott und nicht startfähig) Hypervisor Pool/Cluster Umgebung auch komplett schrott Idee für schnellen, simplen Restore: Auf einem gesonderten (eigenständigen) Hypervisor Server im Backup RZ gibt es aus der Virtualisierung Disaster Recovery Kopie des ersten DC Diese Kopie wird wöchentlich neu erstellt Es bleiben z.B. sechs Kopien als Historie liegen (um auch weiter zurück zu kommen, falls etwa ein Ransomware Angriff erst nach einigen Wochen entdeckt wird) Im Disasterfall wird eine der Kopie Versionen auf dem extra Server gestartet Der ältere Stand wird aufgrund der geringen Änderungsrate in Kauf genommen Einige Computerkonten und Userkonten werden abgelaufene Passwörter haben, wird dann halt individuell behandelt RID Konflikte erwarte ich nicht, da nur ein DC im Restore, der zweite wird anschließend im AD bereinigt und ein neuer zweiter DC aufgesetzt und hochgestuft Was meint ihr dazu? Übersehe ich was? Denke ich mir das zu einfach? Bin gespannt auf eure Hinweise und Gedanken. Viele Grüße

Okay super, danke für die Rückmeldung. Das heißt, das eigentliche Inplace Upgrade auf 2019 hat sauber funktioniert? Wir stehen auch davor...

Und? Ging das Heraufstufen dann noch? Wie ist die Situation ausgegangen?

ja, aber genau das habe ich ja gemacht und dann entdeckt, dass die Einträge in der cache.dns und im AD, wie in dem von dir verlinkten Artikel, noch aufgeführt sind und daher der BPA meckert

Hm, ja habe ich so. Warum dann der BPA eine Warnung für jeden der im AD als Internet DNS Root hinterlegten Server wirft ist mir dann unklar.

ja, etwa per WMI Filter: select * from Win32_OperatingSystem where Version like "10.%" and (ProductType="1") Das sind dann nur Windows 10 Clients, keine Server. Hier geht es jetzt nur im den Filter, die entsprechende Einstellung in der Richtilinie für Autoplay musst du dann entsprechend setzen

Ja ich kann mich hier nur anschließen, die Latenz ist da besonders wichtig. 19 ms Latenz ist super, bis 50 ist alles gut zwischen 50 und 100 ist okay, ab 120 wird es in der Bedienung nervig für die User

Klar, du könntest das per Gruppe mit den Rechnern filtern. Entweder in der Sicherheitsfilterung, per WMI Filter, oder ganz detailliert in der Zielgruppenadressierung. Je nach Anwendungsfall und GPO / OU Struktur

Hi Norbert, sorry, ich war hier einige Tage im Stress und musste das WE durcharbeiten, da wir Ärger mit unserem Storage hatten. Ich weiß, dass ist keine gute Art hier im Forum zu kommunizieren, tut mir leid. Ja mag sein, für den Einstieg in einen EA sind wir zu klein

Wow, danke, das war flott. Tatsächlich, in der cache.dns stand es noch drin, und im AD auch. Jedoch verstehe ich das nicht "Do not use recursion for this domain" das gibt es so auf dem Forwarders Tab beim Windows Server 2016 nicht. Dort heißt es "use root hints if forwarders are not available", und das bezieht sich auf den DNS Server und nicht auf die Domain. Hm. Und nun wundere ich mich schon sehr, es kann doch nicht üblich sein, dass man manuell auf internen DCs per ADSI Edit unter DC=RootDNSServers,CN=MicrosoftDNS,CN=System,... aufräumen muss. Ist unser Setup so fern ab vom Standard, oder übersehe ich etwas?

Moin zusammen, auf unseren DC (Windows Server 2016) nutzen wir DNS nur intern, für externe Auflösung haben wir Linux DNS Server in der DMZ. Da die DCs nicht durch die Firewall an die Internet Root DNS Server kommen habe ich die Root hints entfernt. Auch der BPA meldet diese Warnung: "DNS: Root hint server <IP address> must respond to NS queries for the root zone " für alle Standard-Root DNS Server: https://go.microsoft.com/fwlink/?LinkId=188803 Nach dem Entfernen über die DNS MMC merkte ich nächsten Tag, dass die Einträge wieder da sind. Also: Get-DnsServerRootHint | Where-Object {$_.NameServer.RecordData.NameServer -like "*.Root-Servers.net."} | Remove-DnsServerRootHint -Force Sieht erstmal gut aus, aber auch da kommen die nach einer Weile wieder. Wie entferne ich die überflüssigen, nicht erreichbaren Einträge und belasse nur unseren Forwarder drin? Ich würde auch gerne den Check vom Best Practices Analyzer frei von Warnings bekommen. Grüße Stefan Edit: @Mods: bitte das Thema nach Active Directory verschieben