testperson

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.