Kurze Warnung an Administratoren, die für Windows Server 2025 verantwortlich sind, mit der Installation des Sicherheitsupdates KB5072033 von Dezember 2025 Vorsicht walten zu lassen und ggf. noch etwas zu warten. Mir liegen Berichte vor, dass das Update den Start von Drittanbieter-Diensten (auf DCs) verhindert. Es lässt sich auch keine Software mehr installieren oder deinstallieren.
Windows Server 2025 Update KB5072033
Das kumulative Update KB5072033 wurde zum 9. Dezember 2025 für Windows 11 24H2/25H2 sowie für Windows Server 2025 freigegeben (siehe Patchday: Windows 10/11 Updates (9. Dezember 2025) und Patchday: Windows Server-Updates (9. Dezember 2025)).
Im Supportbeitrag heißt es, dass das Update einige Sicherheitsfixes und Qualitätsverbesserungen enthält. Dazu gehört auch, dass der AppX-Bereitstellungsdienst (Appxsvc) in den Automatischen Starttyp verschoben wurde, um die Zuverlässigkeit in einigen isolierten Szenarien zu verbessern. Ich hatte im Blog-Beitrag Windows Server 2025: KB5072033 setzt AppX Deployment Service-Starttyp auf "Automatisch" über dieses Problem berichtet.
Windows Server 2025: Drittanbieter-Dienste starten nicht mehr
Blog-Leser Christian S. hat mich zum 15. Januar 2026 am späteren Abend per Mail kontaktiert (danke dafür) und berichtete von Problemen. Er schrieb, dass in seinem Unternehmen gerade immer mehr seiner Kunden auftauchen, bei bei denen unter Windows Server 2025 als Domain Controller (DCs) Drittanbieter-Dienste nicht mehr starten. Das hat den Nachteil, dass sich keinerlei Software mehr installieren oder deinstallieren lässt.
Christian gibt an, Problem zum 15. Januar 2025 nachgestellt zu haben. Auch in seiner Umgebung tritt dieses Problem unter Windows Server 2025 zuverlässig auf, seit KB5072033 installiert wurde.
Der Blog-Leser wies mich auf den drei Monate alten Beitrag Server 25 Domain Controller UAC issues auf reddit.com hin. Dort beschreibt ein Administrator exact das Szenario, dass auf einem System mit Windows Server 2025, der als Domain Controller (DC) fungiert, keine Software installiert oder deinstalliert werden könne.
Es soll nur bei Domain Controllern auftreten (verifiziert, da ein DC herabgestuft wurde und dann alles wieder funktionierte). Das Abschalten der UAC löste laut Benutzer das Problem. Das ist aber sehr unschön. Das wird durch einen zweiten Poster auf reddit.com bestätigt.
Mögliche Ursachen
Ich hatte hier im Blog den Beitrag Windows Server 2025: Probleme mit MSI-Installationen im Betrieb als DC? mit einem ähnlichen Problem diskutiert. Dort war das Produkt Splashtop die Ursache.
Ergänzung: Inzwischen ist in obigem Fall eine überraschende Lösung aufgetaucht, die in diesem Kommentar angerissen wird. Dritteanbieter-Dienste sollten verzögert gestartet werden. Im aktuellen Fall hat sich wohl ein solcher Dienst aufgehangen und die Folgefehler verursacht. Hat die Schwarmintelligenz der Leserschaft also wieder einmal geholfen, einen Fall zu lösen.
Ähnliche Artikel:
Microsoft Security Update Summary (13. Januar 2026)
Patchday: Windows 10/11 Updates (13. Januar 2026)
Patchday: Windows Server-Updates (13. Januar 2026)
Patchday: Microsoft Office Updates (13. Januar 2026)
Patchday: Windows 10/11 Updates (9. Dezember 2025)
Patchday: Windows Server-Updates (9. Dezember 2025)
Windows 11 25H2: AppX Deployment Service macht mit KB5072033 Probleme
Defender-Problem nach Windows Update KB5072033 – Get-MPComputerStatus leer
Windows Server 2025: KB5072033 setzt AppX Deployment Service-Starttyp auf "Automatisch"
Windows Server 2025: Bug bei Schema Master Rolle des DC
Windows Server 2025: Bug bei Schema Master Rolle des DC bestätigt
Windows Server 2025: Probleme mit MSI-Installationen im Betrieb als DC?
Windows Server 2025 als DC: Finger weg, bei gemischten Umgebungen (RC4-Problem)
Windows 11/Server 2025: RemoteDesktop-App-Probleme nach Update
Windows Januar 2026-Updates verursachen Verbindungs- und Authentifizierungsfehler
Windows 11 24H2/25H2: Citrix Director / Remote Assist funktioniert mit KB5074109 nicht mehr
MVP: 2013 – 2016
Das Problem ist unschön, aber sollte in der Praxis eigentlich nicht auftreten, denn:
1. Ein DC ist ein DC ist ein DC.
D.H., auf einem DC sollte man mit Ausnahme des DNS-Servers keinerlei sonstige Software installieren.
2. Windows Server 2025 macht als DC immer noch Ärger, daher sollte man derzeit Server 2025 nicht als DC einsetzen.
Man kann statt dessen Server 2022 nehmen, denn bei Windows Server gibt es ein Downgraderecht, d.h. mit einer Windows Server 2025-Lizenz kann man auch Server 2022, 2019, 2016, 2012R2, etc. nutzen. Die CALs für Server 2025 gelten auch für die vorherigen Versionen.
Und was ist mit Third-Party-Software wie Backup, Patching, Überwachung, ggf. Antivirus-Programm?
Auch nicht installieren??
*Kopf -> Wand*
Die einzig von Microsoft unterstützte Backupmöglichkeit für DCs ist das Windows Backup und das ist ja mit drin. Einen virtualisierten DC sichert man doch auch fast immer direkt über das Hostsystem, wüsste nicht warum man das anders machen sollte. Ich weiß ehrlich gesagt nicht was der Virenscanner auf einem DC sollte. Wenn ich den nur als DC einsetze und nicht noch darauf irgendwas anderes mache wie mit dem Browser rumsurfen ist das Problem eigentlich auch nicht wirklich existend. Bei mir kommt nichts auf einen DC das ich nicht vorher irgendwie getestet habe, DCs sind das wichtigste in der AD und genau so behandle ich sie auch!
Ich stimme daher R.S. zu ein DC ist ein DC da kommt nichts an zusätzlicher Software drauf!
Ich wüsste allerdings gerne was mit dem AD-Sync Client von Entra ID ist :P
Entra Connect soll grundsätzlich nicht auf einem DC bereitgestellt werden.
Ein DC ist ein DC, ist ein DC.
Hinsichtlich Virenschutz kommt es drauf an. Threatdown bspw. gibt konkret an, welches Sicherheitsmodul auf einem DC verwendet werden darf und welches nicht.
Danke für den Hinweis bezüglich Entra Connect, tatsächlich habe ich das noch nie selbst installiert und auf den Infrastrukturen die ich gesehen und übernommen habe wars immer auf dem, habe das daher nie groß hinterfragt.
Nach dem CrowdStrike Debakel kommt mir grundsätzlich keine Drittanbieter Sicherheitssoftware auf den DC. Jede Software bringt neue Lücken und damit Risiken. Risikolose IT gibt es halt nicht, welche Risiken eingegangen werden sollen muss halt jeder für sich selbst entscheiden! Sag ja nicht da meine Einstellung die einzig Richtige oder gar die Beste ist.
Wo steht das geschrieben, das Windows Backup das einzige unterstütze ist? Veam z.b. liefert mir viel mehr granulare Restore-Möglichkeiten, als es ein Windows Backup kann. (Ganz oder gar nicht vs. einzelne Teile bis hin zu gelöschten DNS Records.)
Virenscanner gehört überall drauf, auch auf einen DC. Gut, am besten Defender for Indentity.
Und eine Überwachungssoftware der Dienste ist vielleicht auch nicht schlecht bei DCs. Third-Party-Patching Software ist evtl. auch was besser, wenn es um den Rollout geht.
Von daher möchte ich diesen gewagten Thesen hier widersprechen.
Klar funktioniert Veeam, wird aber offiziell nicht von Microsoft unterstützt ;)
Ich würde einen DC nur wiederherstellen wenn er der einzige im Netzwerk ist. Ich würde aber keine Netzwerke mit nur einem DC betreiben.
Ein Virenscanner gehört m.E. nicht überall drauf, ein Hyper-V ist auch sowas auf dem ein Drittanbieter Virenscanner nichts zu suchen hat! Wobei ich auch keinen Hyper-V einsetzen wollte aber das ist ein anderes Thema.
Ich fände es auch schön wenn man nicht gleich abwertend von gewagt sprechen würde nur weil man eine andere Meinung hat! jede Software kann Lücken haben und damit neue Probleme erzeugen m,uss jeder für sich abwägen welche Risiken er eingehen möchte.
Moderne AVs erkennen die HyperV Rolle und "sind dann ganz vorsichtig" (die VM Disks werden nicht mehr gescannt usw.). Also, das geht schon. Und man sollte. Auf einem DC sollte auch der Agent vom SIEM und Monitoring laufen, vielleicht noch Softwareinventarisierung, Schwachstellenscanner, um mehr über den Zustand des DCs zu erfahren. Und dann gibts da noch AD-Audit-Tools, Netwrix, Varonis, irgendwas von Solarwinds, ManageEngine, …, auch die müssen sich mit Diensten auf den DCs einnisten. Ja, mehr Monitoring als der DC sonst tut, aber NIS2, Kritis, usw. zwingen größere Unternehmen dazu.
Dienste einer VM lassen auch auch extern überwachen.
Macht ja sogar der bei Server mitgelieferte Servermanager vor.
Diese Überwachungssoftware muss also nicht auf einem DC laufen!
Eine Sicherheitslösung muss schon auf einem DC installiert sein. DCs sind die Kronjuwelen, da will jeder Angreifer hin, oder nicht?
ja, aber du integrierst eher Software, die auf der Replikationsschnittstelle mitliest: Semperis, Tenable, Symantec whatever.
also praktisch nicht auf dem DC, sondern ein MitM zwischen den DCs
auf dem DC bringt ein Virenscanner überhaupt nichts. du musst sowieso alles AD relevante excluden, da dir das AD sonst sterben kann. trendmicro hat Mal die ntds.dit in Quarantäne geschoben, das war ein Spaß :-S
https://support.microsoft.com/en-us/topic/virus-scanning-recommendations-for-enterprise-computers-that-are-running-windows-or-windows-server-kb822158-c067a732-f24a-9079-d240-3733e39b40bc
Ein Core DC mit Applocker, Defender und mindestens der MS DC Baseline ist "sicher genug". die angreifbaren Türen müssen offen sein, er ist nun Mal ein DC
Applocker auf einem DC? Spannend! Da musst du dem Applocker schon ein sehr spezielles Regelwerk geben. Denn Applocker nimmt explizit (lokale) Admins aus seinem Regelwerk heraus. Und jeder User, der direkt auf einem DC angemeldet ist, ist doch Domain-Admin.
richtig. es ist nicht das Applocker Regelwerk mit Standard Regeln. Core Installation und Applocker verhindern, das jemand als Admin lokal arbeiten möchte.
sehr einfach umzusetzen.
Applocker kann auch die Admin-Konten kontrollieren. das kann/sollte man am Client ebenfalls so konfigurieren.
erlaubt ist pauschal nur das System.
Ein Recht auf Downgrade besteht z. B. nur beim Kaf einer Open oder CSP Lizenz. Eine OEM bringt das Recht nicht mit.
Und der Aussage, auf DCs kommt keine Drittanbieteranwendung, kann man wohl auch widersprechen.
Selbstverständlich sollte dort kein Veeam, Hyper-V (alles schon gesehen) oder ähnliches laufen, aber Schnittstellen-Anwendungen kommen so gut wie immer vor.
als Zusatz:
und wenn das Downgrade Recht besteht, musst du eine gültige alte Lizenz haben. die wird nicht mitgeliefert.
aus MS Sicht ist der einzige Grund für ein Downgrade eine homogene IT Struktur in der alte Server stehen.
aus MS Sicht schränkt man sich ja selber ein, wenn man nicht das neue nutzt, das man bezahlt hat.
Hallo
obwohl es absolut keinen Sinn macht, habe ich mir die Sache einmal angeschaut.
KB5072033 ist bei mir vom 6.1.2026 – Vielleicht ist der Fehler ja mit KB5073379 vom 13.1.2026 behoben, denn bei mir tritt der Fehler nicht auf.
Windows Server 2025 24H2 Build 26100.32230
Ich habe testweise einmal VLC ist eine .exe Installationsdatei und Libre Office ist ein MSI File problemlos installiert.
Natürlich habe ich danach beide Programme wieder deinstalliert
Mein Kategorie für den Artikel – Maße statt Klasse :-(
Übrigends 2025 DC´s machen nur in Verbindung mit 2022 / 2019 DCs Probleme.
Meine 2 2025er DC´s laufen fehlerlos.
Keine Ahnung von was hier die Rede sein soll. Habe testweise gerade Notepad++ und Firefox auf einem 2025 DC problemlos installieren können.
Meine 2025er DCs auch. Und ich kann Deine Aussage bestätigen, dass die 2025er DCs nur Probleme machen, wenn zusätzliche, ältere DCs im Netz sind. Dann sind die Probleme nach spätestens 1 Monat allerdings extrem. Keine Anmeldung mehr möglich ist dann nur eines der Probleme….
Nur mal so ins Blaue geraten:
– Zusammenhänge mit dem MotW?
– Zusammenhänge mit dem Smartscreen Filter?
Es gibt Kombinationen mit MotW und Smartscreen Filter nicht verfügbar, bei denen ein Start von Programmen unmöglich wird.
Ich kann es auch nicht testen, unsere DCs laufen auf Server 2022.
In kleineren Unternehmen mit nur einem Server wird der DC oft auch als App-Server genommen. Die zweite VM ist dann oft ein RDSH.
KB5073379 löst das Problem nicht
Zusatzinfo: Bei uns waren es alles Hyper-Vs. Splashtop oder ahnliches waren nicht installiert. Selbst C++ Runtimes ließen sich nicht installieren
Zu: In kleineren Unternehmen mit nur einem Server wird der DC oft auch als App-Server genommen. Die zweite VM ist dann oft ein RDSH.
Um 800€ für die zweite Lizenz zu sparen so einen Murks machen? So was würde ich als Admin gar nicht anfassen bzw. wenn dann nur um das direkt umzubauen! Das weiß man doch das einem das irgendwann auf die Füße fällt und das ist dann fast immer Freitag Mittag, an Heilig Abend oder am Tag vorm Urlaub. Nee nee so was mach ich nicht mehr!
Zumal man auf einem DC keine lokalen Benutzerkonten mehr hat was mit einigen Apps Probleme macht. Also nein ich habe das noch nie selber gemacht und kann daher auch gar nicht aus Erfahrung sprechen ;)
Natürlich ist das nicht sinnvoll oder Best Practise. Es ist aber nun mal gängige Praxis in kleinen Umgebungen.
Und es bleibt ja nicht bei 800 €. Bei dritter VM brauch ich evtl. größere Hardware mit mehr RAM und Cores.
Die RAM- und Festplattenpreise haben sich gerade teilweise verdreifacht.
Die meisten Systemhäuser würden das bestimmt auch lieber anders machen. Aber die Kunden wollen/können es teilweise nicht zahlen.
Naja, man braucht keine 800,- € in die Hand zu nehmen.
Server Datacenter bei einem Gebrauchthändler kaufen und man kann beliebig viele VMs installieren.
Und da gibts Datacenter für deutlich unter 800,- €.
Es gab da vor Jahren mal den SBS, da war es völlig normal und auch absolut fehlerfrei möglich, selbst einen Exchange auf dem DC am Laufen zu haben!
Einen DC für ALLES Mögliche zusätzlich zu verwenden ist technisch also im Prinzip überhaupt kein Problem.
Ob es Sinnvoll ist, ist eine völlig andere Frage. Das es mittlerweile zuweilen technisch verhindert wird bestimmte Dinge damit zu machen ist auch eher deshalb so, weil es so "gewollt" ist aber nicht weil es nicht laufen würde.
Den SBS hatten wir auch mal.
Das ist eine Krücke!
Die Ereignisanzeige war ständig vollgemüllt mit Fehler-Ereignissen.
Das trat nur auf einem SBS auf und Microsoft hat das auch bestätigt.
Und lt. Microsoft sollte man all diese Meldungen ignorieren.
Und schon damals hat Microsoft davon abgeraten, so ein Kontrukt zu mchen, obwohl sie es selbst angeboten haben.
Und folgerichtig hat Microsoft den Murks dann mit Server 2012 beerdigt.
Boah, SBS-Krücke! Hab sowas mal eingerichtet, müsste 2003 oder 2008er oder sowas gewesen sein, und dann war ich sehr regelmäßig bei dem Kunden, weil Updates nicht durchgelaufen sind, vor allem die notwendigen Exchange-Updates haben jedes Mal gemuckt.
Ja der SBS war aber auch immer gut für ungeplante Überstunden so gut hat der funktioniert :D
Nicht alles was irgendwie funktioniert, funktioniert auch gut.
Kann ich nicht bestätigen. In der Regel haben die SBS die ich hatte geschnurrt wie ein Kätzchen. Der einzige Ärger waren die Datenbankgrößen Beschränkungen vom Exchange wenn man nicht aufgepasst hat. Aber sonst?
richtig. was man (ich) von Olli lernen musste: wenn es einen Assistenten gibt, muss man ihn benutzen.
wer den SBS wie einen normalen Server betrieben hat (wie ich und viele andere), hatte Probleme.
das Ding war ein vielen Stellen mit einer Erwartungshaltung gebaut, die nur erfüllt wurde, wenn die Assistenten genutzt wurden, die haben die Struktur entsprechend gebaut.
Ich erinnere mich dunkel nur an den MS POP3 Collector für Exchange (keine Ahnung mehr wie der richtig hieß). War war strukturell sowas von kaputt schon seit NT4 SBS Zeiten, dass ich damals den Popbeamer von einem damals unbekannten Österreicher gekauft habe. Der hat sich in den laufenden Jahren eine goldene Nase mit dem Tool gemacht,
Nein, der SBS war strukturell kaputt… schon seit NT4 Zeiten. Ich sag nur Pop3 Connector. Ab 2008 auf damals zeitgemäßer Hardware kaum mehr sauber zu betreiben. Ich durfte mal ein AD migrieren. Es war besser alles von scratch auf neu einzurichten als den Murcks weiter am Leben zu erhalten.
sehe ich anders. apropos POP3, es ist ein Exchange, der bekommt Post, der holt keine ab. Fehlkonfiguration des Admins. feste IP und mx record waren auch zu 2003 Zeiten kein Zauberwerk ;-)
Mir schon klar, aber es war eine von Microsoft vorgeschlagene, per Assistent einrichtbare Lösung. Kein Wunder, dass dieses so eingerichtet wurde.
Du willst nicht wissen, was MS da für krudes Zeug allein mit den Headern veranstaltete, damit alles halbwegs (schlecht) mit Weiterleitungen CC und BCC funktionierte.
Du vergißt den Kontext. Das war noch eine andere Zeit, damals ™ vor ca. 25-30 Jahren.
Einen POP gab's nur in großen Städten. T-Interconnect von der Telekom für monatlich 1000,- DM/ später Euro. Die goldene Zeit der ISDN Kanalbündelung. Server und Clients hingen überwiegend PPPoE direkt am Netz. Als ich damals mit fli4l oder SUSE 6.3 Linux-Routern ankam wurde ich schräg angeschaut, warum ein extra Gerät, wenn alles auch so klappt?
Die ersten SBS in meiner Hand waren NT4 basiert mit dem MS Proxy Server 2.0, der später von MS wegen Erfolg aus dem Paket ausgekoppelt hat und extra preispflichtig zum ISA-Server machte.
Es war eine andere Zeit, keine bessere, kein alter weisser Mann erzählt von damals. Wir (und damit meine ich auch mich) waren da noch recht naiv. Hier meine Verarbeitung dazu:
https://blog.jakobs.systems/blog/20250712-vom-messdiener-zum-ketzer/
Ein einziger DC ist bei KMU nicht unüblich. Falls es eine dominante Fachanwendung gibt, sind da auch mal ein paar Schnittstellendienste und ein SQL-Server drauf.
Wenn man die nicht unterstützten Szenarien von Microsoft und Fachanwendungen zusammennimmst, darf man dann manchmal garnichts mehr ;-) Z.B. Fachanwendung schließt Snapshots bei Hyper-V aus oder ist nur freigegeben mit einer bestimmten Antiviruslösung auf dem Client.
Die Risikoabwägung bei Auftrennung der Dienste und Anzahl DC hat man zu machen. Angesichts der Qualitätskontrolle bei Windowsupdate erscheint der Einsatz von Windows mittlerweile das größte Risiko. Die Monopolstellung mancher Fachanwendungen und deren Altlasten kommt noch dazu.
Ein einziger DC…. da gibt es eigentlich nur noch Seppuku zur Wiederherstellung der Ehre oder der Gesichtswahrung.
Brennen mögen solche Netze, die Firmen bitte wochenlang handlungsunfähig sein.
wenn UAC abschalten ein Workaround ist, dann kann man damit leben. die UAC steht auf einem Server sowieso zur Diskussion
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/disable-user-account-control
(…) Under certain constrained circumstances, disabling UAC on Windows Server can be an acceptable and recommended practice.
100% das mit der UAC (und grundsätzlich allen anderen nicht benötigten Diensten auf einem Server, und damit meine ich ausdrücklich MS Zeugs). Da haben wohl einige Ihre Server nicht gehärtet.
Es bleibt aber trotzdem ein Klops von Microsoft. Mal wieder, weil die eine Hand nicht weiß, was die andere tut und offensichtlch niemand den Murcks testet, den die raushauen.
Ausbaden dürfen es andere…
von einer Qualitätskontrolle kann man nicht mehr sprechen. man wundert sich ja, wenn es keine Probleme gibt. die Erwartungshaltung am Patchday hat sich um 180° gedreht
BTW.: Ist das nicht erst seit dem Dezember Patchday. Das ist seit der RTM.
Hier hilft es i.d.R. die Dienste der 3rd Party von "Automatisch" auf "Automatisch (verzögerter Start)" zu konfigurieren.
Das war tatsächlich ein guter Hinweis. Ein einziger Dienst hat sich beim Starten so weggehangen, dass er die kompletten C++ Komponenten und alles was darauf basiert, blockierte. Dies führte dazu, dass nichts mehr ging.
Ich kann das Problem auch nicht nachvollziehen. Wir haben u.a. den SCOM Agent auf den DCs installiert, welcher sich problemlos installieren oder updaten lässt. Die meisten DCs sind Server 2025, es gibt aber auch noch einige Server 2022 DCs.