[English]Heute noch ein Beitrag für Administratoren von Domain Controllern. Falls jemand mit dem Gedanken spielt, einen Windows Server 2025 als Domain Controller (DC) in eine gemischte Umgebung aufzunehmen, lasst es. Durch die Aufnahme des neuen Windows Server 2025 DC in eine bestehende Struktur mit alten Windows Server DCs gibt es massive Probleme. Das Maschinenkennwort lässt sich nicht ändern und die Domänenanmeldungen fallen sporadisch aus. Es ist ein Bug in Windows Server 2025, der nicht öffentlich bestätigt ist, an dessen Behebung die Microsoft Produktgruppe aber arbeitet.
Ein Leserhinweis "da brennt der Helm"
Es war eine private Mitteilungen von Andy Wendel auf Facebook (danke dafür), die mich bewogen hat, den Beitrag hier zum Wochenende einzustellen. Vielleicht rettet es dem einen oder anderen Leser einige graue Haare. Andy schrieb mir: "Es gibt ein massives Problem in gemischten Umgebungen, wenn ein neuer DC2025 dazu kommt: Es brennt der Helm!" Wenn ich es richtig mitbekommen habe, gibt es in seinem Kundenkreis massive Probleme mit der Konstellation.
Mir klingelte nur im Hinterkopf, dass ich vor einigen Stunden in einem anderen Kontext obigen Tweet am Rande mitgenommen habe, der Probleme mit RC4-Verschlüsselung bei Windows Server 2025 und Windows 11 24H2 anspricht.
Windows Server 2025 DC macht Ärger in mixed Umgebungen
Andy Wendel hatte mich dann in seiner privaten Nachricht noch auf den reddit.com-Thread RC4 issues hingewiesen (wenn ich es beim Querlesen nicht falsch interpretiert habe, wird in diesem reddit.com-Thread etwas ähnliche angesprochen). Der Ursprungspost ist jetzt auch schon drei Monate alt (Mai oder Juni 2025). Die dort beschriebene Situation:
I am running a domain at 2016 functional level. Our DC's are 2022 and 2025 (we have 4). When we added the 2025 DC's, we start having random issues where our domain logins would randomly stop working on a given server.
Der Thread-Starter administriert mit Kollegen eine Domäne, die auf Funktionsstufe 2016 läuft. Inzwischen hat man vier Domain Controller mit Windows Server 2022 und Windows Server 2025 in dieser Domäne in Betrieb.
Maschinenkonten können Passwörter nicht zurücksetzen
Seit in dieser Domain Windows Server 2025 als Domain Controller aufgenommen wurde, gibt es nur noch Ärger. Der Thread-Starter schreibt, dass die Domänenanmeldungen (Domain Logins) plötzlich auf einem bestimmten Server nicht mehr funktionierten. Es gibt kein Muster, die Ausfälle treten zufällig auf verschiedenen Servern auf.
Der Betroffene schrieb dann, dass sich herausgestellt habe, dass die Maschinenkonten ihre Passwörter nicht zurücksetzen können. Mir fiel direkt mein Blog-Beitrag Windows Server 2025 Domain Controller: Trust Relationship mit Windows 11 geht verloren von Januar 2025 ein.
Workaround: Maschinenkonten-Passwörter manuell zurücksetzen
Der Thread-Starter gibt an, dass die vorübergehende Lösung darin bestehe, sich als lokaler Administrator beim problematischen Server anzumelden und den Befehl:
unter Angabe eines beliebigen DC und Verwendung von "-credential" (get-credential) zu verwenden. Damit erhält man eine Anmeldung als Domänen-Administrato, mit der das Maschinenpasswort in der Domäne zurückgesetzt werden kann.
Deaktivierung der RC4-Verschlüsselung: Weg ins Verderben
Weitere Untersuchungen haben laut Thread-Ersteller ergeben, dass das Problem auf eine GPO-Einstellung zurückzuführen ist, die die RC4-Verschlüsselung auf zwei der Domänencontroller deaktiviert. Recherchen des Betroffenen, in der Google und KI involviert waren, ergaben, dass eine globale Deaktivierung von RC4 als Wert in
msDS-supportedencryptiontypes
dazu führen sollte, dass die Konten bei Authentifizierungsanfragen keine RC4-Verschlüsselung mehr verwenden würde. Der Versuch, diese durchzusetzen, legte aber die komplette Domäne lahm. Dies konnte nur mit einer "haarsträubenden" ADSI-Sitzung, in der die GPO so repariert wurde, dass RC4 erneut zugelassen war, behoben werden. Nur dadurch konnte der Zugriff auf die Domäne wiederhergestellt werden.
Verratzt in einer gemischten Umgebung
Der Thread-Starter schrieb, dass er die Windows Server 2022 Domain Controller nicht auf Windows Server 2025 aktualisieren könne (dass sei in seinem Szenario keine Option). Andererseits könne er die Windows Server 2025, die als DC fungieren, auch nicht entfernen. Ein Lock-In in der "Hölle einer gemischten Umgebung" ist der er jetzt gefangen ist – Andy Wedel drückt es mit "da brennt der Helm" aus.
Im reddit.com-Thread hat sich dann am 26. September 2025 (als ich den Beitrag hier verfasste), ein weiterer Administrator gemeldet, der das Gleiche berichtete und das Verhalten bestätigte. Er hatte die Idee, die Passwortänderung der Maschinenkonten zu unterbinden.
Ein weiterer Administrator schrieb dazu, dass dies keine gute Idee sei, weil dies die Netzwerksicherheit vermindere und bestenfalls ein Notbehelf sei. Er sei nur durch Upgrade aller Domain Controller auf Windows Server 2025 aus diesem Schlamassel herausgekommen. Er schrieb:
I ended up upgrading the DC's to be all 2025 (Apparently the 2025 Kerberos database changed in 2025 which is why the problem happened).
Im Post gibt dieser Administrator detaillierte Hinweise, wie die Umstellung, speziell bei Verwendung von VMs in Hyper-V-Umgebungen, erfolgen sollte, um nicht Schiffbruch zu erleiden. Er schreibt, dass er gerade seinen Job durch diesen Mist verloren habe, weil er keine Dokumentation zu dieser Konfiguration hatte. Ein vorgeblich erfahrenere Kollege sagte ihm, dass "diese diese Konfiguration automatisch erfolge", was nicht zutraf. Dadurch hat das Unternehmen einen Tag Produktion verloren, was dann zur Kündigung führte. Aber das Upgrade aller DCs auf Windows Server 2025 habe das Problem mit dem Zurücksetzen des Maschinenkontopassworts gelöst.
Im Thread ist in verschiedenen Post noch die Rede, dass das alles ein Bug sei. Aber der Bug sei nicht behoben und auch nicht öffentlich bestätigt. Vor 10 Tagen merkte ein weiterer Poster an, dass der Fehler intern gemeldet wurde und die Produktgruppe an einer Beseitigung arbeitet. Er erhalte wöchentliche Status-Updates, aber Microsoft würde dies nicht auf der offiziellen Windows Server Release-Health-Statusseite als "Know Issue" kund tun.
Also gilt aktuell für gemischte DC-Umgebungen: "Finger weg von Windows Server 2025 als weiterer DC", denn das gibt Ärger.
Ähnliche Artikel:
Windows Server 2025 Domain Controller: Trust Relationship mit Windows 11 geht verloren
Windows Server 2025: Bug bei Schema Master Rolle des DC
Windows 11 24H2/Windows Server 2025 bekommt Updates vom WSUS nicht
Windows Server 2025: HPE ProLiant DL325-Server erzeugt IRQL_NOT_LESS_OR_EQUAL BSOD nach Juli 2025-Update
Windows Server 2025: Authentication Bypass mit Golden dMSA
Windows 11 24H2/Windows Server 2025 VM-Startprobleme nach Juli 2025-Update; Fix mit OOB-Update KB5064489
ReFS-Dateisystem: Fix für CPU/RAM-Auslastungs-Bug in Windows Server 2025 im August 2025?
MVP: 2013 – 2016
Windows Server 2025 "glänzt" doch seit Erscheinen mit immer neuen Bugs.
Zumindest als DC sollte man es derzeit nicht einsetzen.
Hier steht auch ein Upgrade auf Server 2025 an.
Aber bei der aktuellen Situation mit Server 2025 wird das zwar gekauft, aber dann das Downgraderecht in Anspruch genommen und Server 2022 zumindest bei den DCs installiert.
Wenn dann die ganzen Bugs in Server 2025 beseitigt sind, kann man immer noch auf Server 2025 aktualieren.
Und was RC4 angeht:
Es ist schon traurig, das man dieses Uralt-Verschlüsselung (stammt von 1987!) nicht abschalten kann, ohne das es Probleme gibt.
Bei TLS wurde die Verwendung von RC4 schon 2015 wegen erheblicher Sicherheitsmängel verboten!
Kerberos sollte man nur noch mit AES verwenden.
Und es ist schon traurig, das Kerberos nur veraltete Hashfunktionen, wie z.B. SHA1 und MD5 unterstützt.
Es wird Zeit, das auch SHA3 unterstützt wird und Standard wird.
Aus meiner Sicht wird hier die falsche Schlussfolgerung gezogen. In einer Active-Directory-Umgebung sollte im Jahr 2025 (eigentlich schon deutlich länger) kein RC4-basiertes Kerberos mehr notwendig sein. Vielmehr gehört es zu den Aufgaben der Admins dafür zu Sorgen, dass veraltete Verfahren wie RC4 und ähnliche Kompatibilitäts-Bremsklötze aus dem Netz verschwinden.
Denn ein Active Directory, in dem RC4-basierte Verfahren noch erlaubt sind, ist extrem anfällig für Kerberoasting-Angriffe. Ähnliches gilt auch für andere veraltete Einstellungen und Verfahren in Windows-Umgebungen: auch diese verhindern, dass die Sicherheit im Active-Directory-Umfeld erhöht werden kann, so dass das Active Directory (und damit alle angeschlossenen Server) nicht gleich bei dem erstbesten Angriff von einer Ransomware-Bande übernommen werden kann.
Daher wird nicht nur von Microsoft schon seit Jahren gepredigt, die Geräte und Konten, die noch RC4 benötigen, zu identifizieren und dafür zu sorgen, dass sie entweder verschwinden oder so angepasst werden, dass sie AES-basierte Anmeldeverfahren unterstützen. Denn Geräte, die nur RC4-basiertes Kerberos können, sind wirklich uralt. Selbst PCs mit Windows 7 haben in einem Active Directory bereits Kerberos mit AES unterstützt. Da reden wir also von über 15 Jahre alten Systemen. Ähnliches gilt für den oben angesprochenen NetApp-Speicher. Seit der Ontap-Version 9.12 von Netapp wird AES-basiertes Kerberos unterstützt und seit Version 9.13 ist es sogar defaultmäßig aktiv. Diese Versionen sind schon über zwei Jahre alt (Mitte 2023). Daher ist es in den allermeisten Fällen einfach nur eine schlechte Ausrede, wenn man so tut, als könne man (mit etwas Vorbereitung) nicht auf RC4-basiertes Kerberos in seinem Active Directory verzichten.
Wir haben unsere Exchange-Server in einer anderen Domäne, ohne Trusts. In der Konstellation kann man auf den Workstations nicht auf ausgehendes NTLM verzichten, Kerberos klappte bisher nicht. Die Konstellation haben wir schon über 20 Jahre so, weil schon immer bekannt war, und es hat sich immer wieder durch neue Sicherheitsupdates bestätigt, dass man die Exchange-Server einfach durch entsprechend präparierte Mails abschießen kann. Die damaligen Architekten unserer Landschaft haben damit verhindern wollen, dass wenn sowas passiert, dass dann nicht gleich das ganze Office-Netz mit kompromittiert wird. Bisher hats geklappt, mir ist aber auch nicht bekannt, ob jemals ein Exchangeserver auf die Weise abgeschossen wurde. Der zweite Nachteil der Choose ist, dass die Benutzer alle 3 Jahre ein komplexes 30 Zeichen langes Passwort für den Exchange-Zugriff mal wechseln müssen… Backup und HyperV sind auch in solche Exklaven ausgelagert.
Wenn man sich über grundsätzliche Strukturen beim Active Directory Gedanken macht, ist es übrigens wichtig, dass es sich nicht nur um eine separate Domäne handelt, sondern diese auch in einen separaten Forest ("Gesamtstruktur") untergebracht ist. Denn zumindest gewiefte Angreifer können aus der Kompromittierung einer Domäne heraus auch sehr wirksam andere Domänen innerhalb der gleichen Gesamtstruktur angreifen und übernehmen. Unter anderem deshalb hat Microsoft im Rahmen von Verbesserungen zur AD-Sicherheit (Tiering-Modell und Co.) auch einmal empfohlen, alle Konten mit Admin-Berechtigungen in einem separaten Forest zu betreiben ("Red Forest"), so dass diese nicht so leicht kompromittiert werden können, wenn ein Angreifer seine Berechtigungen in der "echten" Domäne (und Gesamtstruktur) erweitert. Aber das sind natürlich auch alles Empfehlungen zur AD-Sicherheit, die sich vor allem an große Unternehmen mit entsprechend großen IT-Abteilungen und IT-Budgets richten, die es sich leisten können, solche Parallelstrukturen mit "unproduktiven" Servern zu betreiben. Dagegen ist das Deaktivieren von RC4-basiertem Kerberos in einer Active-Directory-Umgebung eine Maßnahme, die eigentlich überall umgesetzt werden kann und sollte, auch bei Unternehmen mit "nur" ein paar Dutzend Mitarbeitern.
Noch einmal etwas anderes ist die Frage, ob man es schafft, komplett auf NTLM-Anmeldungen zu verzichten und alle Dienste in dem Active Directory auf sichere Kerberos-basierte Anmeldeverfahren umzustellen. Das kann, je nach den Umständen der AD- und sonstigen Netz-Umgebung, sehr schwierig werden und daher arbeitet Microsoft ja auch schon eine Weile daran, für bestimmte Szenarien die Kerberos-Anmeldung zu ermöglichen, in denen diese bisher nicht möglich ist.
Und letztlich ist das alles aus Microsoft-Sicht sowieso Schnee von gestern, die Zukunft liegt aus deren Sicht bekanntlich in Entra ID und somit in der Verlagerung von Anmeldevorgängen in die Microsoft-Cloud. Das On-Premises-AD ist in der Betrachtung nur noch "legacy"-Kram, der mitgeschleppt wird.
Schon vor längerer Zeit hat Microsoft einen Guide veröffentlicht, wie man die Protokollierung von NTLM-Ereignissen einschaltet.
Dann muß man nur im Ereignisprotokoll des DCs nachsehen, ob da NTLM-Ereignisse protokolliert werden.
Wenn da längere Zeit keine Einträge vorhanden sind, weiß man, das NTLM nirgends mehr verwendet wird und kann dann NTLM abschalten.
Wenn ich schreibe, "separat", dann meine ich separat.
Richtig, da kann ich nur zustimmen. RC4 gehört definitiv deaktiviert! Wir hatten das ungefähr vor 6 Jahren gemacht und es zog sich ca. 1 Jahr, bis wir es vollständig deaktiviert hatten. Unsere Umgebung hat ca. 800 Server und 9000 Clients.
Ansonsten schreibt Microsoft doch klar im Changelog, dass RC4 nicht mehr supporter wird. Habt ihr das vor dem Update nicht geprüft?
https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
Kerberos changes for Algorithms used for Ticket Granting Tickets: The Kerberos Distribution Center will no longer issue Ticket Granting Tickets using RC4 encryption, such as RC4-HMAC(NT).
Ich kann das Problem bestätigen. Betroffen scheinen aber aktuell nur Member Server 2025. Soweit ich das bisher gesehen habe, gibt es keine spezielle Einstellungen/GPO welche RC4 explizit aktivieren oder deaktivieren würde.
Wir verwenden mehrere DCs mit Server 2019 und Server 2025. Spricht ein Member Server 2025 den DC 2025 an funktioniert die Kerberos Ticket Erstellung nicht. Ein Login am Member-Server mit einem neuen AD-Konto welches sich noch nie am Server angemeldet hat ist dann nicht möglich, nur AD-Konten welche sich schon einmal angemeldet haben funktionieren (Cache?).
Sobald der Server wieder mit einem DC 2019 kommuniziert (das ändert der Member-Server willkürlich, bzw. im normalfall bei einem Neustart) klappt der Login wieder einandfrei.
Wir hatten Anfang des Jahres identische Probleme mit den Konten und haben deswegen die W2K25 DCs wieder entfernt.
Schon lustig den Umgang mit ADSI als haarsträubend zu bezeichnen und nicht in der Lage zu sein ein DC ordentlich zu entfernen und das als AD Admin…
Von der Problematik mit 2025 als DC habe ich schon öfters gelesen, aber bisher nicht mit einer so ausführlichen Anaylse. Deswegen haben wir bisher 2025 nur als normale Member-Server. Für einen DC muss der erst noch reifen, ein Käse muss auch erstmal liegen bis er schmeckt. Ich hätte zwar gerne ein paar neue Features des 2025er Domainlevels, aber Stabilität ist wichtiger. Wäre Mist, wenn der Laden wegen den Experimenten von Microsoft still stehen würde.
Einige Nutzer mit neuinstallierten 24h2 Clients können plötzlich auf bestimmte Serverfreigaben (Essentials 2016) nicht mehr zugreifen. (fehlende Rechte). Was noch bis mittags problemlos funktionierte, aüßert sich nun dadurch, das die entsprechenden Benutzer schlicht nicht mehr in den Freigaben auf dem Server
aufgeführt sind und neu eingetragen werden müssen…..
Was 2016 essentials nicht EOS?
Nein.
Lt. Microsoft Lifecycle-Seite bekommen alle Server 2016-Editionen, also egal ob Essentials, Standard oder Datacenter gleich lange Support und Updates.
Danke für den Thrad, ich meine das auch in der Facebook Gruppe gesehen zu haben. Dort hatte jemand ein ähnliches Problem nach der Installation von 2025 als DC. Allerdings habe ich es nicht weiter verfolgt da war noch er einmal Neuinstallation des DC falls da was defekt gewesen ist. Trotzdem bestärkt das wieder leider immer lange warten bis man die nächste Version von Windows produktiv einsetzen kann. gefühlt hat es ewig gedauert bis beim patchday nicht mehr stand nur bei 2022 :)
mich würde noch interessieren ob das ein generelles Problem ist, weil ich dachte man kann rc4 über gpo ausschalten. aber es liest sich irgendwie so das genau das nicht kompatibel ist wenn man das macht weil es in 2025 nicht vorhanden und man es deswegen nicht deaktivieren kann irgendwie.
Danke für den Hinweis zur Problematik.
Trotzdem verwundert es.. dass anstatt win2025 zu entfernen jemand versucht zuerst rc4 kaputt zu machen.
das richtige vorgehen, wäre in der GPO Domain Richtlinie AES für Kerberos zu erlauben. Und zu warten bis alle Clients das übernommen haben.
https://www.msxfaq.de/windows/kerberos/kerberos_rc4_abschaltung.htm
Genau erstmal parallel laufen lassen und identifizieren wo RC4 noch genutzt wird. Alte Konten ggf. zum Passwortwechsel zwingen.
Wir hatten ebenso das Verhalten in einer gemischten Umgebung, und wunderten uns das ein paar Tage nach der Inbetriebnahme keine Anmeldungen am RDS Server mehr möglich waren. Bei diesem Kunden brannte der Baum und wir mussten zeitnah eine Lösung finden. Wir haben die DCs 2025 entfernt und auf eine ältere Windows Version die DCs umgestellt. Danach funktionierte die Domäne wieder einwandfrei. Wir hatten nach längerer Recherche einen englischen Forumseintrag gefunden der dieses Verhalten beschrieb. Auch dort wurden die DCs 2025 entfernt. Seit der Rolle rückwärts funktioniert die Domäne einwandfrei. Wir warten nun, was bei MS dazu passiert und würden dann die DCs erneut auf 2025 umstellen.
Ich bin es echt leid für MS die Feuerwehr zu spielen. Die kommen einfach nicht ihrer Arbeit nach.
Netzwerksicherheit: Beschränken von NTLM: Remoteserverausnahmen für die NTLM-Authentifizierung hinzufügen
Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren Aktiviert
DES_CBC_CRC Deaktiviert
DES_CBC_MD5 Deaktiviert
RC4_HMAC_MD5 Deaktiviert
AES128_HMAC_SHA1 Aktiviert
AES256_HMAC_SHA1 Aktiviert
Künftige Verschlüsselungstypen Aktiviert
Netzwerksicherheit: Lokalem System die Verwendung der Computeridentität für NTLM erlauben Aktiviert
Netzwerksicherheit: Zurückgreifen auf NULL-Sitzung für lokales System zulassen Deaktiviert
Andy Wendel liest hier mit – ich schätze, er wird Rückmeldung geben, wenn das bei seiner Kundschaft das Problem löst ;-).
Yepp….😎
Hallo Micha,
leider ist es nicht so einfach.
Also zuerst einmal die Frage: Wohin verknüpft Du die GPO?
Nur DCs? Nur Clients (Server und Clients) oder global?
Denn ohne das zu posten, macht ein reinknallen der GPO-Settings hier wenig Sinn.
(Mir braucht man das nicht sagen, sondern den geneigten anderen Lesern… ;-) )
Davon ab, macht gerade das deaktivieren von RC4 alles kaputt, wenn der erste DC2025 dazukommt.
Und es ist weitaus aus komplexer:
Aus Reddit:
Did you by chance set HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC | DefaultDomainSupportedEncTypes on DCs?
For 2025, for now, that is superseded by this location, HKLM\Software\Microsoft\CurrentVersion\Policies\System\Kerberos\Parameters | DefaultDomainSupportedEncTypes
A value of 0x1C will do both AES 128/256 and RC4
Es sind eben neuere Werte unter DefaultDomainSupportedEncTypes (!), und eben nicht ms-DS-Supported-Encryption-Types:
https://learn.microsoft.com/de-de/windows/win32/adschema/a-msds-supportedencryptiontypes
Wir sind dran….
Andy
Die Einstellungen beziehen sich erst mal auf Clients, da man RC4 ja aus Sicherheitsgründen deakvtieren sollte. Wenn man natürlich in seinter umgebund noch Systeme hat die nur RC4 können sollte man das natürlich nicht deaktvieren. Die Domaincontroller sollten aber davon nicht betroffen sein. Deshalb wäre die Frage hast du alte Systeme in deiner Umgebung die RC4 benötigen ja oder nein?
Mir platzt auch gerade der A… !!!
Mein Plan: Serverumzug von Server 2019 auf Server 2025 Standard.
Danach Exchange Umzug auf SE.
Nachdem ich die FSMO-Rollen und Postfächer umgezogen hatte muss die Replikation aufgehört haben da ich nach einem halben Tag massive Probleme mi Exchange SE bekam mit "…konnte keinen Domänencontroller finden…".
Nach ewigen Suchen habe ich die Diagnose: Schema-Mismatch was bedeutet: der neue Server hat die FSMO-Rollen und der Alte den Exchange im Schema.
Keine Chance eine Synchronisation zu erzwingen…
Nun habe ich 2 AD´s die ich beide brauche (1x FSMO, 1x Exchange).
Katastrophe! Danke Kleinweich!
warum kein Schema prepare laufen lassen?
Kann ich so zu 100% bestätigen. Die Problematik und auch der Workaround treffen bei uns exakt zu. Manchmal können sich die Nutzer nicht mal nach einer Desktopsperre wieder einloggen. Da waren unsere Vermutungen für die Ursache dieses Schlamassels also richtig. Danke für die Bestätigung.
Ist es grundsätzlich möglich, einen Domänencontroller – sei es den neuen 2025 oder auch einen älteren2016/2019 – testweise in eine eigene Site ohne zugeordnetes Subnetz zu verschieben, um ihn für Clients (einschließlich Exchange) im Hinblick auf Kerberos-Anmeldungen unsichtbar zu machen?
Die Idee dahinter wäre, gezielt zu testen, ob die beobachteten Authentifizierungsprobleme durch den Mischbetrieb von Server 2019- und Server 2025-DCs verursacht werden.
Voraussetzung ist natürlich, dass die jeweilige Umgebung dies hergibt, d. h. die FSMO-Rollen müssen zuvor bei Bedarf auf einen anderen DC verschoben werden, sodass die Funktionsfähigkeit des AD nicht beeinträchtigt wird.
Ja, Sites = Subnetz = Firewall. Zudem kann die Replikation explizit angehalten werden
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/turn-on-that-scary-dc/258950
Ich wundere mich gerade, dass ich anscheinend keine Probleme damit habe. Bei mir laufen 2x 2016 DCs und ein neuer 2025 DC, ohne Probleme.
Ich kann jetzt nur vermuten, es liegt an der Hybridumgebung mit O365. Ein 2016 DC ist ständig mit der Onlineumgebung verbunden und synchronisiert die Passwörter.
Das Problem sind nach meinem Stand 2025 Member Server in dieser Konstellation bzw dann wenn sie mit dem 2025 sprechen und ihr Computerkennwort versuchen zu erneuern. Schlimmer wirds wenn man die sec baselines angewendet hat die rc4 deaktivieren :)
Kein DC spricht direkt mit O365, das macht EntraID Connect wenn denn..
Nach Information von Netapp ist das Problem mit den Maschinenkonten in Server 2025 DCs mit dem September-Update behoben worden. Bei Netapp gibt es dazu sogar eine KB.
Hallo zusammen,
wir haben auch einen Mischbetrieb Server 2025 DC + andere 2016 DCs und treten in die gleichen Fehler wie zuvor erwähnt. Leider kann ich bestätigen auch nach einspielen der Updates aus dem September bleiben die Fehler bestehen. Gibt es den schon neuere Informationen, ob Microsoft das offiziell fixen wird?
Ich habe nichts gehört und Andy hat auch keine Rückmeldung gegeben, dass er mit den in den Kommentaren beschriebenen Workarounds weiter gekommen wäre.
Hi Richard,
sorry für die späte Rückmeldung.
Ich war 1,5 Wochen erkrankt…
Aktuelle Tests zeigen nur, das aktuell nur funktioniert, alle DCs auf 2025 zu fahren oder alle 2025er DCs in einer gemischten Umgebung zu demoten.
Das ist immer noch der aktuelle Stand.
Melde mich, wenn ich mehr/genaueres weiß oder sich etwas bei MS tut,
beste Grüße,
Andy
Hi Andy,
vielen Dank für die Information.
In dem Fall bleibt uns nichts anders möglich als den 2025 zu demoten.
Grüße
Richard
Mal eine Frage in die Runde:
Was passiert, wenn man die alten DC's rausnimmt? Ist dann das Problem weg oder landet man dann im Totaldesaster?
Danke und viele Grüße
Tom
Hallo zusammen,
das würde mich auch interessieren. Wenn ich zwei DC 2016 habe und die mit zwei neuen 2025 Server ablösen möchte. Oder lieber 2022 Server nutzen?
So wie ich das beobachtet habe, ist nur ein DC 2025 als Ergänzung nicht unbedingt ein Problem. Es muss dazu auch noch Member mit 2025 oder 24H2 (wo auch LTSC 2025 dazugehört) und neuer kommen. Ab dann tauchen die Phänomene verzögert in Erscheinung.
Und ja, es klappt was ich in den Kommentaren gelesen habe. Wird der DC 2025 nicht erreicht, aufgelöst oder sonst wie vom passenden Member nicht erreicht, dann klappt z.B. Anmeldung. Kommt der DC 2025 wieder dazu, dann scheitert es.
Lösung ist DC 2025 zurück zustufen als Member oder die anderen auf DC 2025 zu bringen. Vorsicht dann aber mit Schema Erweiterungen. Diese sollten vorher passieren solange ein DC 2016 bis 2022 der Schema Master ist.
Sollte eigentlich nur im Zusammenhang mit Exchange Server SE passieren. Da dann das Schema-Update vorher ausführen lassen.