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

Gut, dass du die Rückmeldung gibst. Und schade, dass es immer wieder nötig ist dieses Verzeichnis zu räumen um dem Update Dienst auf die Sprünge zu helfen. Immerhin ist es heutzutage etwas weniger / seltener nötig als bei alten Servergenerationen.

Ja, ihr habt sicher Recht, die Welt ist nicht schwarz-weiß. Ich denke jedoch mit meiner Beschreibung konnte ich klar machen, das mir ein persönlicher und partnerschaftlicher Kontakt wichtig ist. Danke für eure Statements und direkte Nachrichten. Gerne können mehr Vorschläge hier (oder DM) genannt werden.

Moin Leute, ich weiß, diese Anfrage ist etwas ab vom typischen MS Server Thema und technischen Fragen. Jedoch seid ihr einfach meine bester Quelle für Fragen rund um MS Server. Wir betreiben ca. 180 Windows Server, 2 AD Forests, eine große RDS Farm, Exchange. Dafür brauchen wir einen Dienstleister mit dem wir eine dauerhafte Beziehung mit einem Support Vertrag aufbauen können. Dieser Dienstleister soll zu einem Partner werden, der unsere Umgebung gut kennt. Daher suche ich explizit nicht nach einem großen, anonymen Konzern, dann könnte ich das auch bei MS direkt einkaufen. Könnt ihr mir Tipps geben für richtig gute Firmen mit denen ihr positive Erfahrungen gemacht habt? Viele Grüße Stefan

Moin, wieder mal eine Spezialfrage. Ich baue etwas zur Prüfung und Dokumentation der Farm Konfig was technisch auch schon gut funktioniert. Nun wollte ich das als Task für einen Service Account einrichten und scheitere an Berechtigungen. Ich versuche auf dem RD Connectionbroker per get-RDSessionCollectionConfiguration Informationen auszulesen. Dies darf aber scheinbar ein normaler User nicht. Ist ja auch okay. Wer kann mir ein Tipp geben, an welcher Stelle das gesteuert wird? Viele Grüße Stefan

Moin, klar darf man... Wir hatten nur noch angestaubtes Wissen zur alten Citrix PS 4.5. Haben dann 2016 mit mehreren Partnern die neueren Versionen von Citrix angesehen und einen Vergleich mit RDS gezogen. Damals bot RDS alles was wir brauchten und ersparte uns komplettes neu lernen und halt auch einfacheren Betrieb durch weniger Software die verwaltet und gepflegt werden muss. Insgesamt sehe ich das weiterhin auch als richtig an, jedoch ist es tatsächlich sichtbar, dass RDS ohne Citrix Lücken hat. Diese versuchen wir nun zu schließen.

Jupp, sorry wollte möglichst viele erreichen mit meiner Frage... Citrix haben wir gerade vor ein paar Jahren abgelöst... deine beiden anderen Tipps sehe ich mir an, danke

Moin zusammen, sollte es das Thema hier bereits geben und ich habe es trotz Suche übersehen, verzeiht bitte und gebt mir gerne einen Hinweis auf den Thread. Wir betreiben eine recht stattliche RDP / RDS Farm für Desktops und Sessions (RDSH). Es sind 2 Broker, 2 RDWeb, RDGW, und 48 Terminalserver in 7 Sammlungen. (Noch basiert das ganze leider auf Windows Server 2012 R2.) Nun haben wir immer öfter betrieblich Lücken Fehler schnell zu entdecken und unsere (externen) Kunden erwarten auch immer mehr Monitoring (zu Recht). Unser Monitoring System basiert auf Nagios bzw. Icinga. Eine Überwachung der TS auf dem RDP Port haben wir bereits, jedoch umgeht dies die Farm einer echten Anmeldung mit RDWeb und den Connection Brokern. Primär benötige ich vor allem eine Möglichkeit das RDWeb zu prüfen auf: wird die Seite geladen und dargestellt (hier haben wir bislang einen einfachen http-Check) ist eine Anmeldung möglich werden erwartete RemoteApp Icons dargestellt Optimal wäre natürlich ein Check, der sogar eine Anmeldung, also das Starten einer RemoteApp simuliert! Ich bin grundsätzlich für alle Tipps dankbar etwas in einer Terminalserver Farm überwachen zu können! Ob nun Ideen für Icinga oder Skripte, Tools auch kostenpflichtig ist erstmal egal Viele Grüße Stefan

Moin Martin, klasse, danke ist komplett geblockt soweit ich weiß, bin ja nicht aus dem Netzwerkteam . Das werden wir mal ausprobieren. Nur, bleiben die LW dann ja getrennt, wenn der Client später nach Updates wieder compliant ist und nicht neustartet, richtig? Ist auch für Drucker in unserer Terminalserver Farm eine coole Idee.

Ist Cisco, die interessieren sich dann ja nicht für Folgeprobleme, wenn ein Client nicht an den Fileserver kommt und der User gerne Laufwerke hätte... Nachtrag: Ich habe in der GPO bei den GPP zu den Laufwerkszuordnungen jetzt "Elementverarbeitung in dieser Erweiterung bei Fehler stoppen" aktiviert, damit läuft die Anmeldung wieder ausreichend schnell

Moin, wir evaluieren gerade ein NAC System. Dabei ist aufgefallen, dass die Useranmeldung sehr lange dauert wenn ein Client nicht compliant ist (etwa weil der Defender nicht läuft). Das ist auch soweit nicht ganz verwunderlich, da in diesem Zustand der Zugriff auf den Fileserver unterbunden ist, somit sind die Laufwerkszuordnungen in der GPO nicht möglich. Wenn wir testweise den Rechnern in diesem Zustand Zugriff auf den FS geben ist die Anmeldung wieder schnell. Habt ihr einen Vorschlag, was wir da tun können um die Anmeldeverzögerung zu reduzieren? Kann man das drive mapping da irgendwie aussetzen?