cj_berlin

Moin, was @NorbertFe sagt. Eine Migration aus Chaos-Bereinigungsgründen würde ich nur erwägen, wenn ich ohne Koexistenz auskomme, also Big Bang. Dann brauchst Du auch keinen ADMT, da Du ohne Koexistenz ja auch keine SIDHistory und auch keine laufende Passwort-Synchronisation brauchst. Das geht aber nur, wenn alle Anwendungen mitspielen, inklusive solcher, die augenscheinlich "nur" im Benutzerprofil wohnen. Was Du deshalb vermutlich brauchst, ist sowas wie USMT. Sobald sich jedoch herausstellt, dass eine vom Business akzeptierte Migration nur über eine Koexistenz geht, schwindet der Kreis der stichhaltigen Gründe für eine Migration eigentlich auf nur zwei: Politik: Die Domain-Namen verweisen auf die ehemalige Muttergesellschaft oder auf den rausgedrängten Mitgründer und müssen verschwinden. Security: Es ist mit Sicherheit bekannt, dass ein Backup eines Domain Controllers entwedet wurde, und damit ist alles, was durch DPAPI geschützt ist, sofort angreifbar. Useraccounts neu anlegen geht mit 3-10 Zeilen PowerShell, und da ist es egal, obs 10, 100 oder 10.000 sind.

Genau. Das wäre genau so ein Fall, wo Du Exchange nicht brauchst, weil jede andere Mail-Schleuder besser geeignet und billiger wäre und weniger Infrastruktur benötigt.

Moin, es gibt theoretisch die Möglichkeit, Exchange mit Device-CALs zu lizensieren. Aber das sind Szenarien, wo man Exchange vermutlich nicht wirklich braucht. Wenn alle Personen, die Exchange nutzen (inklusive des Praktikanten, der ab und zu mal am MFP Dokumente einscannt, ohne dass er ein Postfach besitzt), eine User CAL haben, kannst Du so viele Geräte mit Exchange-Zugriff haben, wie Du möchtest, inklusive VMs, Shared Mailboxes usw.

Moin, wenn es Dir nur ums Hinzufügen (also: nicht ums Entfernen) von Mitgliedern geht, kannst Du die "Restricted Groups" GPO statt GPP verwenden, da musst Du allerdings die gewünschte lokale Gruppe in allen verwendeten Sprachen erfassen. FInde ich persönlich ungünstig, aber wenn die Beschreibung wirklich wichtig ist, muss man halt Opfer bringen Ansonsten, GPP, ILT-Filter nach Sprache, und halt mehrfach pflegen. Auch ungünstig, aber wie oft passiert das schon, dass man an der Stelle etwas ändern muss... Oder überall die englische Beschreibung reinballern und gut ist.

Moin, VDA braucht es nur, wenn der Citrix-Desktop auf einem Client-Windows läuft. Und wenn dem so wäre, bräuchtest Du keine RDS-CAL. Da bei Dir Server-Worker im Einsatz ist, ist mit der RDS-CAL der Zugriff lizenziert.

Hast Du das mal mit SYSTEM, also psexec -s versucht? Es ist ja alles Registry, somit an Zgriffsrechte gebunden...

@daabm von der Vererbung der GPOs habe ich doch gar nicht gesprochen, die wäre hier m.E. auch vollkommen wurscht, solange GPO und GPP beide ankommen... Und dann geht es tatsächlich um die Verarbeitung der CSEs, aber halt nur von zwei konkreten... Und sobald die Restricted Groups einmal verarbeitet wird, überschreibt sie alles, wenn es dort im oberen Teil gesetzt ist, unter "Mitglieder dieser Gruppe sind:"

Hab's für euch aufgeschrieben: https://it-pro-berlin.de/2026/03/windows-dns-conditional-forwarders-and-recursion/ Was der Client macht, sollte mit Recursion nichts zu tun haben...

Aber die *Funktion* der Conditional Forwarder basiert nicht auf Rekursion. Die Rekursion, die man für sie einstellen kann, ist eigentlich schädlich, denn die besagt ja, dass man globale Forwarder oder Root Hints fragen soll, wenn der Conditional Forwarder die Anfrage nicht beantworten kann! Vielleicht sollte ich darüber bloggen

Ich habe die PMs gefragt, mal sehen, ob was zurück kommt. Aber *eigentlich* ist es ja schnell getestet Tatsächlich kann man die Rekursion sogar für Conditional Forwarder individuell einstellen, und das überschreibt die Server-Einstellung: https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverconditionalforwarderzone?view=windowsserver2025-ps#-userecursion Das ganze wird durch den Registry-Wert "ForwarderSlave" gesteuert, und der Default-Wert ist "0" (ja, Rekursion benutzen). Das könnte auch der technische Grund sein, warum die globale Deaktivierung der Rekursion die Conditional Forwarder nicht beeinflusst...

Moin, der DL irrt. Conditional Forwarders sind nicht von der Rekursion betroffen. Sie sind ja technisch quasi nur Slave-Zonen ohne Zonefile.

Moin, nach allem, was bisher bekannt ist, und ich hatte auch schon versucht, die Uhr nach vorne zu stellen, kannst Du das Update auch in 2027 noch vornehmen. Im Bereich PK + KEK wird auf die Zeit eh nicht geachtet, denn zur Einschaltzeit ist die gute Uhr ja nicht garantiert, aber auch im weiteren Boot-Prozess wird nur das Vertrauen geprüft und nicht die Gültigkeit. Was halt nach Ablauf nicht mehr regulär geht, ist eine neue Signatur zu erzeugen. Aber auch das kann mit verdrehter Uhr umgangen werden.

Normalerweise nicht, aber Firmware wurde ja auch nur von Menschen* geschrieben. Es kann also passieren, dass irgendwas beschädigt wird. Manche UEFI-Varienten haben sogar ein Fallback-Verhalten für Secure Boot, wonach sie automatisch die Default Stores probieren, wenn die Verifizierung mit den Runtime Stores fehlschlägt. * heutzutage muss man ja sagen, "oder, schlimmer noch, NICHT von Menschen"

Moin, wenn die Restricted Groups-GPO die Mitgliedschaften im oberen Bereich pflegt, sind sie verbindlich und Du hast verloren. Wenn sie im unteren Feld gepflegt sind, müsste man schauen, das muss eigentlich gehen.

Wenn das EFI auf Default ohne 2023er PKI geht und Windows einen Boot Manager hat, der nur 2023-signiert ist (sagen wir mal, so Mitte 2027, nach einem Boot Manager-Sicherheitsupdate), wird Windows nicht booten. Obs tragisch ist, ist dann individuell zu bewerten