testperson

An der Stelle könnte man darüber nachdenken, an den Hyper-V Hosts - losgelöst ob Domain / Workgroup - per Windows Firewall eine Deny In- / Outbound Regel zu erstellen, die eben die IP Range(s) der Workloads / restlichen Systeme abdeckt. Auf den restlichen Systemen wird das Ruleset dann einfach "umgekehrt" implementiert. Zwischen Hyper-V Hosts und Veeam Server bzw. ggfs. zwischen Veema Server und Workloads müsstest du dann etwas granularer rangehen. Bzw. auch wenn die Hosts in der Domain sind.

Hi, ich würde - losgelöst von Workgroup / Domain - ASAP "Gründe" beseitigen. Die Frage wäre, ob man den Admin Approval Mode nicht generell auch für den Built-In Admin aktiviert (User Account Control Admin Approval Mode for the Built-in Administrator account - Windows 10 | Microsoft Learn). Gruß Jan

Du hast ja auch eine "New-DynamicDistributionGroup" erstellt und keine "Get-DistributionGroupMember". Siehe: View members of a dynamic distribution group | Microsoft Learn

OT: Einfach zwei, drei Mal am Tag laufen lassen Update-MgGroup -GroupId <Id> -MembershipRuleProcessingState Paused Start-Sleep -Seconds 5 Update-MgGroup -GroupId <Id> -MembershipRuleProcessingState On (Bei dynamischen Gruppen für Autopilot Geräte bzw. fürs Deployment Profil kann ich mal noch nicht über langsame Updates der Mitglieder klagen.)

Dann wirst du mit nem RecipientFilter auf "EmailAddresses" filtern müssen, sofern das machbar ist oder eben meinen Ansatz wählen. Wo klemmt es denn bei deinem bisherigen Ansatz?

Ich wäre skeptisch, ob MSFT Webcast irgendwas mit Microsoft zu tun hat.

Hi, falls es nicht zwingend "dynamisch" sein muss, lass doch zwei, drei Mal am Tag ein PowerShell Script per Scheduled Task drüber laufen, das dir die Gruppen baut, wie du sie gerne hättest. Damit bist du vermutlich flexibler. Bzw. schreibe dir mit diesem "Helper Script" die entsprechende Domain in ein Custom Attribut, welches du dann für den Filter hernimmst. Was soll den mit Usern passieren, die beide Adressen haben? Gruß Jan

Wer braucht schon die Hersteller Doku (Create a workgroup cluster in Windows Server | Microsoft Learn) wenn es Youtube Videos gibt.

Hi, was hast du denn da eingetragen und was kommt auf den Nodes an? Nutzt du den Built-In Administrator oder nutzt du individuelle Accounts auf den Nodes? Gruß Jan

Vielleicht hat es jemand vergessen oder eher verdrängt. 25 Jahre Windows Millenium Edition: Millennium-Ausgabe von Windows ist 25 Jahre alt | heise online 🥳

Hi, du könntest einen eigenen DNS fürs Workgroup Cluster bereitstellen, wo die Hosts dann eben dynamisch registrieren bzw. updaten dürfen. (Oder du erstellst auf dem bestehenden DNS eine neue Zone, in der unsichere Updates erlaubt sind.) Gruß Jan

"Downgrade Recht" wären die Zauberworte. Im Worst-Case brauchst du nur einen 2019er Key, den du aber auch als "Downgrade Kit" nachordern können solltest. Sofern die auf deine Anfragen nicht antworten, wende dich doch mal an den Vertrieb oder die GF dort. Notfalls musst du das bei euch halt an die GF "eskalieren", dass die dort mal nachhören. Wenn aber niemand will und alle nur den einfachen Weg gehen, dann kann man euch wohl nicht helfen.

Jetzt bist du bei "testweise" zuletzt war es dein produktives System. Ich würde - sofern die original Systeme noch laufen - einfach in einem Klon / Restore ohne Netzwerk direkt In-Place auf 2022 oder eben 2025 gehen bzw. testen, ob das klappt. Die andere Überlegung wäre, einfach auf 2019 zu bleiben. _Warum_ soll es denn unbedingt neuer werden? Jetzt von 2016 wegmigrieren, ja, macht Sinn. Da ist im Januar 2027 Support Ende*. Mit 2019 bist du schon im Januar 2029. Da ist so viel Zeit, dass alles sauber zu planen und nach und nach in geordneten Bahnen auf neue VMs zu migrieren. Da sollte sogar noch genug Zeit sein, zu hinterfragen, ob man weiterhin mit "Frickel Soft" arbeitet oder eben eine neue Software einführt. Wie stellt Ihr euch denn Support vor, wenn mit "Frickel Software" wirklich mal die Hütte brennt und Ihr wirklich Support braucht? *) Selbst bis Januar 2027 _sollte_ mehr als genug Zeit sein, die Software sauber auf neue Systeme zu migrieren.

Doch, das _sollte_ gehen. Aber es kann sicherlich nicht schaden, sich das _vor_ dem Kauf vom Distributor / CSP bestätigen zu lassen.

Möchtest du ESU als OEM Lizenz kaufen? Oder möchtest du ein OEM lizenziertes Windows 10 mit ESU betreiben? Warum überhaupt ESU oder 0patch? Werden die genutzten Applikationen denn unter ESU / 0patch supportet? (Das Win 10 Support Ende kam jetzt aber auch urplötzlich und überraschend um die Ecke. ;-))

Hi, an der Stelle wirst du halt nach dem Kauf der ESU Lizenz(en) deinen (ESU) Produkt Schlüssel finden. Du bekommst ESU nur per CSP Subscription oder halt per Volume Licensing. (Wenn wir "Personal" / "Home" ausblenden.) Der Rest (https://learn.microsoft.com/en-us/windows/whats-new/enable-extended-security-updates#install-and-activate-the-esu-key) ist (AFAIK) unabhängig vom Lizenzkanal. Gruß Jan

Wo ist das Problem? Neue VM installieren, als Member in die Domain aufnehmen und zum DC hochstufen. Eventlogs prüfen und wenn alles ok ist, FSMO Rollen übertragen. "Frickel Support / Consulting" anrufen und einen Migrationstermin ausmachen. Dabei abklären, wer welche Aufgaben zu erledigen hat. Jo, weils da gerade "so gut" läuft. *SCNR*

Wo läuft der denn jetzt gerade? Und vielleicht wäre der Exchange ja in Exchange online besser aufgehoben. Du findest ja immer weiter Dinge, die nicht für einen Weiterbetrieb dieses Servers sprechen bzw. gegen ein In-Place Upgrade sprechen. Beiß einfach in den sauren Apfel und mach jetzt einen Cut. Investiere die Zeit lieber in ein neues Konzept.

Hi, klingt danach, als wärst du auf der Suche nach einem DNS Server. Vielleicht macht es mehr Sinn, die User zu den Daten zu holen anstatt die Daten zu den Usern. Kannst du die Anwendung(en) nicht per Terminalserver bereitstellen? Gruß Jan

Hier ist ein ganz gutes Projekt bzw. eine Übersicht dazu: LOLBAS Ein Ansatz für die Firewall: GitHub - eneerge/Powershell-Firewall-Block-LOLbins (Das solltest du dir aber recht genau ansehen, überarbeiten und testen. Das Profil "Any" würde ich spontan für too much halten in Domänen Umgebungen.)

Der Fix wird im September Patchday nochmal(?) erwähnt: September 9, 2025—KB5065426: Update for Windows Server 2025 (OS Build 26100.6584) - Microsoft Support (Oder es war noch nicht komplett gepatched. :))

Hi, teste es in der PowerShell einmal mit dem Parameter "-ImportPath (und -Password)", wo dann das pfx liegt. Laut Set-RDCertificate (RDMgmt) | Microsoft Learn: HTH Jan

OEM ist leider nicht gleich OEM. Bei den OEMs kann es auch auf den Hersteller ankommen, von dem die OEM ist bzw. kann OEM AFAIK auch ROK sein. Nur weils gleich heißt ist es in dem Fall nicht identisch. Was hält denn der Server alles für Rollen / Software? Jetzt kommt ja auch noch Exchange ins Boot. Wo läuft denn der Exchange Server? Meine Frage nach dem "Warum unbedingt weiter auf 2022 / 2025" zielt darauf ab, jetzt erstmal ein Päusschen zu machen und alle beteiligten an einen Tisch zu holen und mal zu sagen: "Haaalt Stopp!". Dann könnte man ja über so Dinge wie "Budget", "Konzept", etc. reden und nahelegen, dass man hier was _sinnvolles_ machen sollten.

Hi, was spricht dagegen, den obigen Inhalt in eine *.reg zu schreiben, zu importieren und dann nachzusehen? ;) Es sind aber Hex Werte. Gruß Jan

Hi, evtl. hilft es ja, dir die Schritte mitzuteilen. Das ist aber schon was her: Den neuen Windows Server 2008 R2 als Member in die 2003er Domain aufnehmen adprep (liegt auf dem Installationmedium im Ordner support\adprep) auf dem Windows Server 2008 R2 Domain Member ausführen adprep.exe /forestprep adprep.exe /domainprep adprep.exe /domainprep /gpprep 2008 R2 zum DC hochstufen dcpromo.exe Das _sollte_ es _erstmal_ gewesen sein. Gruß Jan