Jump to content

Pipeline

Members
  • Gesamte Inhalte

    296
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Pipeline

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

     

    vor 17 Minuten schrieb Nobbyaushb:

    Wir hatten in unserer viel kleineren Umgebung 5 DC‘s…

    Interessant, warum denn sogar fünf? Ist das nur wegen der Pferde vor der Apotheke oder hat das technisch einen konkreten Vorteil?

     

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

    Am 26.3.2024 um 16:38 schrieb Nobbyaushb:

    60 Server laufen alle als VMs oder sind physische dabei?

    Alles Windows oder Mix?

    Bei 300 Usern würde ich wohl einen weiteren DC vorhalten...

    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.

     

    Am 26.3.2024 um 16:38 schrieb Nobbyaushb:

    Aus einem Wiederherstellungs-Szenario bzw. Desaster-Recovery entsteht ein Backup-Szenario

    Wie lange darf es dauern, bis was wieder einwandfrei funktioniert

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

     

    Am 27.3.2024 um 07:10 schrieb NilsK:

    Billige Client-Hardware ist nur als Notlösung geeignet

    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.

     

    vor 22 Stunden schrieb Squire:

    Wenn Und du eh ein Backup RZ hast ... was spricht denn gegen einen weiteren DC dort? Oder wenn der nicht gewünscht wird, warum keine Replikat-VM der bestehen DCs zu dem zweiten Hyper-V

    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

     

  3.  

    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.

    vor 4 Stunden schrieb cj_berlin:

    Tools, die auch "Cyber-geschädigte" ADs recovern können

    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 :

    vor 3 Stunden schrieb NilsK:

    vom Recovery her denken

    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

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

     

  5. Am 8.2.2024 um 14:54 schrieb u0679:

    Es war tatsächlich ein Fehler in der Replikation zwischen den DCs, der nicht aufgefallen war.  Nach Beseitigung des Fehlers hat es einwandfrei geklappt. 
    Sorry für die verspätete Rückmeldung. 

     

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

     

  6. vor 3 Stunden schrieb cj_berlin:

    Vermutlich weil der DC sie nicht erreichen kann. Trage Deine eigenen externen Forwarder als Root ein und lösche die offiziellen, dann sollte Ruhe sein - solange Deine Forwarder die Root-Zone auflösen können.

    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

  7. Am 5.12.2023 um 07:19 schrieb cj_berlin:

    Moin,

    nein, da muss man nichts aufräumen. Du hast dringlichere Aufgaben in Deiner Infrastruktur. Den Haken bei "Use root hints if forwarder is not available" rausnehmen und/oder die Linux-DNS als Root Hints eintragen und glücklich sein.

    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.

  8. vor 1 Stunde schrieb mzaplata:
     

    Hallo,

     

    hab jemand eine Idee wie und ob man per GPO das Autoplay nur für bestimmte Geräte erlauben kann? Für alle anderen soll es deaktiviert bleiben.

     

    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

  9. Am 13.12.2023 um 10:35 schrieb Nobbyaushb:

    Ich finde dein Verhalten komisch, erst fragst du rum, man sendet eine PM und bittet um Kontaktinformationen und dann nix mehr?

    Ziehe mein Angebot zurück...

    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.

    Am 4.12.2023 um 16:51 schrieb zahni:

    Wenn man einen EA-Vertrag abschließt, bekommt man normalerweise einen sog. LAR zugewiesen.

    Ja mag sein, für den Einstieg in einen EA sind wir zu klein

  10. vor einer Stunde schrieb cj_berlin:

    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?

     

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

     

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

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

     

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

  15. vor 5 Stunden schrieb cj_berlin:

    Jupp, sorry wollte möglichst viele erreichen mit meiner Frage...

    vor 6 Stunden schrieb testperson:

    Hi, zum Einen könntest du mal einen Blick auf Citrix bzw. Citrix Virtual Apps & Desktops werfen, da wäre schonmal ein deutlich besseres Monitoring (und sicherlich noch weitere sehr nette Benefits) dabei und zum Anderen bzw. zur eigentlichen Frage könntest du bspw. bei Control Up oder auch Goliath Technologies was zum Monitoring finden.

    Gruß

    Jan 

    Citrix haben wir gerade vor ein paar Jahren abgelöst... deine beiden anderen Tipps sehe ich mir an, danke

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

    1. wird die Seite geladen und dargestellt (hier haben wir bislang einen einfachen http-Check)
    2. ist eine Anmeldung möglich
    3. 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

     

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

     

×
×
  • Neu erstellen...