testperson

Danke für die Antwort. Das Script hilft hier leider nicht. Ich habe gerade testweise das PowerShell Modul installiert und mir die Konfiguration vor dem Klick auf "Check for updates" angesehen und danach: # Vorher: ServiceID IsManaged IsDefault Name --------- --------- --------- ---- 8b24b027-1dee-babb-9a95-3517dfb9c552 False False DCat Flighting Prod 855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod) 9482f4b4-e343-43b6-b170-9a65bc822c77 False True Windows Update #Nachher: ServiceID IsManaged IsDefault Name --------- --------- --------- ---- 7971f918-a847-4430-9279-4a52d1efe18d False True Microsoft Update 8b24b027-1dee-babb-9a95-3517dfb9c552 False False DCat Flighting Prod 855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod) 9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update Clever wie ich bin, habe ich vorher natürlich keinen Snapshot gemacht und werde die VM dann mal neu deployen..

Hi, zu 1) Das könnte auch ein Thema für eine Cyberversicherung sein. Gruß Jan

Nein. Viel Erfolg.

Hi, du hast den Lösungsansatz doch schon selber gefunden: boote den RDSH "notfalls" jede Nacht durch. Gruß Jan

Hi, hat jemand eine Idee, wie ich per Script eine Windows Update Suche starten kann? Mit "wuauclt" und "UsoClient" funktioniert es leider nicht. Klicke ich händisch auf "Updates suchen" oder warte ab, bis WU von alleine getriggert hat, funktioniert das CMDlet direkt. Hintergrund ist, dass ohne vorherige Suche(?) das CMDlet Install-Language die Sprache anscheinend nicht laden kann. Auf das PowerShell Modul "PSWindowsUpdate" würde ich - wenn möglich - gerne verzichten. Danke und Gruß Jan

Was mich hier generell daran verwirrt: Hyper-V so grob aus 2008 Pre-Windows 2000 Compatible Access Aber auch damit werde ich leben können. ;)

Ja, mit den o.g. Ausnahmen läuft er. ;) "Kerberos only" konnte der Cluster nach einem Shutdown nur per Powershell gestartet werden. Die Failover Cluster MMC scheint noch etwas an NTLM zu hängen, würde mich aber auch nicht wundern. Auf meiner Agenda steht derzeit noch ein Test, wie sich alles mit dem Windows Admin Center verhält. Beide Clusterknoten haben auch problemlos das In-Place Upgrade über Windows Update mitgemacht. BTW.: Auf frisch installierten Systemen mit der Build 26063 ist Copilot überall "aktiv".

Die Shared Nothing Livemigration von einem Managementserver / -client funktioniert nicht mehr: Move-VM : Virtual machine migration operation failed at migration source. Failed to establish a connection with host ... : No credentials are available in the security package (0x8009030E) ... (Komplette Fehlermeldung findet sich hier: Why Hyper-V Live Migrations Fail with 0x8009030E - Microsoft Community Hub) In der Umgebung gibt es mehrere Hyper-V Hosts, die nicht im Cluster sind. Wie das mit der "normalen" Livemigration im Cluster aussieht, teste ich "die Tage".

Hätte ich mich doch nur dafür entschieden, anstatt heute den Tag damit zu verbringen Dinge über TGGAU (Token-Groups-Global-and-Universal) und die "Windows Authorization Access Group" zu lernen... Bzw. welche Auswirkungen es auf die Live Migration hat, wenn man die "Authenticated Users" aus der "Pre-Windows 2000 Compatible Access" Gruppe entfernt.

Hi, warum keine moderne Cloudlö... ;) vielleicht ist ja ein M365 Plan vorhanden, der Intune inkludiert bzw. wäre Intune ein Ansatz anstelle des WSUS. Gruß Jan

Hi, erstelle notfalls einfach drei Host Zones. Also je eine Zone mit dem kompletten FQDN "Server1.firmendomain.de", "Server2.firmendomain.de", "Server3.firmendomain.de" und lege dort einen A Record nur mit IP Adresse und ohne Namen an. Bzw. per dnscmd: dnscmd . /zoneadd Server1.firmendomain.de /dsprimary dnscmd . /recordadd Server1.firmendomain.de . A 172.29.x.x Gruß Jan

Moin Da in der Diskussion einmal Teamviewer angesprochen wurde: Teamviewer: Sicherheitslücke im Client ermöglicht Rechteausweitung | heise online VG Jan

Hi, ist auf den beiden Clients irgendwas aktiv (Virenscanner) / vorgeschaltet, was SSL aufbricht bzw. dem Client ein anderes Zertifikat unterjubelt? Gruß Jan

Ich würde hier nach dem Sinn fragen. Für mich würde hier nur folgendes Sinn machen: Alle externen User (Home Office, Roadwarrior, ...) müssen sich per MFA authentifizieren Alle User (extern und intern) müssen sich per MFA authentifizieren (Aber, ja es ist ebenfalls möglich, User aus der MFA auszuklammern bzw. nicht "enrollte" User zugreifen zu lassen. Sinn macht das für mich aber nicht.) Wenn es nur um MFA für RDS geht, wäre eine weitere Frage, wie melden sich die User am PC an und worauf könnten die User vom PC theoretisch (und praktisch) zugreifen?

Hi, DUO ist generell echt gut. Ich kann dir aber nur raten, nimm einen Paid Plan, der sich mit $3 pro User - in meinen Augen - mehr als im Rahmen hält. Im Free Plan ist kein Active Directory Sync enthalten. Zusätzlich wäre im Konzept ein "Break the Glass Admin" hilfreich. :) Ansonsten: Eset Secure Authentication Server RCDevs OpenOTP Server ManageEngine AD Self Service Plus Gruß Jan

Im Moment gibt es da für mich wichtigere "Baustellen". Ich würde dich aber glatt im Hinterkopf behalten. ;)

Da muss jetzt aber erstmal noch ne Menge - zumindest vermutlich für 30 Tage - Wasser den Rhein runter fließen bis der Worst Case mich "motiviert". Es gibt im Moment genug andere Schauplätze.. Fürs Erste habe ich Vollzugriff erteilt, Install-ADServiceAccount und Vollzugriff entfernt. ;)

In Teilen vielleicht bspw.: Qualys VMDR - Vulnerability Management Tool | Qualys? Zumindest zum Filtern, was für die eigene Umgebung relevant ist?

Ich habe es zumindest gerade auf einem Windows Server 2019 ausgeführt (mit Vollzugriff für den ausführenden User auf das sMSA Objekt).

Die beiden CVEs (CVE-2024-21412 (Microsoft Windows Internet Shortcut Files Security Feature Bypass Vulnerability) / CVE-2024-21351 (Microsoft Windows SmartScreen Security Feature Bypass Vulnerability)) behandeln AFAIK das für SmartScreen.

Das definitiv. Ich war nach deinem Einwand leicht verunsichert und habe es mir eben angesehen. Da der Lizenzierungsserver am 10.10.23 installiert wurde, war es auch gerade erst knapp über die Grace Period von 120 Tagen. ;) (Ich hätte allerdings auch gesagt, dass das schon seit 2012 oder 2016 bzw. fast schon immer so ist (seit dem ich intensiver mit Terminalservern zu tun habe).)

Hi, grobe Spekulation meinerseits: Der User öffnet die HTML Seite im Browser und soll nach 0 Sekunden einen Refresh auf "file://<IP>/ mcqef/yPXpC.txt" machen. Dann ist dort vermutlich ein präparierter Samba/Filer für einen entsprechenden Exploit (etwas aktuelles à la CVE-2020-0796 / WannaCry) und dann geht es weiter. Vielleicht spielt da dann auch CVE-2024-21412 und CVE-2024-21351 noch rein. In einer Sandbox die Textdatei mal laden. :) Gruß Jan

Ich hätte _vor_ deinem Einwand hoch und heilig geschworen, dass es schon immer so war, dass der RDLic >= neuestem RDSH OS sein muss. Was davon ist denn tatsächlich "Terminalserver-relevant"? Ist auf dem Terminalserver nur die Remote Desktop Session Host Rolle installiert und es gibt weitere Server mit den Rollen Remote Desktop Web Access, Remote Desktop Gateway und/oder Remote Desktop Session Broker?

Hi, gibt es irgendwo eine Übersicht für die möglichst minimalen Rechte, die der User auf den MSA delegiert haben muss, um diesen installieren zu können? Laut (Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting | Microsoft Learn) soll es "Modify" sein. Mit den Rechten "Read" / "Write" funktioniert es jedenfalls nicht. Sobald ich "Full Access" delegiere gehts. ;) Hat jemand zufällig einen Link oder eine Übersicht zu den minimalen Rechten? Vielen Dank und Gruß Jan

Hi, wie groß ist denn die Farm? Evtl. ist es schneller kurz und schmerzlos die RDS Bereitstellung neu zu machen. BTW.: Ich habe hier einen Windows Server 2022 RDLic mit ausschließlich Windows Server 2022 RDS User CALs und der stellt seit Oktober 2023 sowohl 2019er wie auch 2022 CALs aus. Gruß Jan