Ich stelle mal eine Beobachtung hier im Blog ein, die ein Blog-Leser beim Vorbereiten eines Wortmann Terra Server mit Windows Server 2025 Standard (Essentials Key) gemacht hat. Sobald der Server 2025 mit einer Rolle als Domain Controller versehen wurde, gab es Probleme mit der Installation von .msi-Dateien. Der Leser hat einiges getestet, es scheint, dass Windows Server 2025 im Betrieb als Domain Controller möglicherweise noch ein Problem hat.
Anzeige
Das Szenario des Lesers
Es war eine E-Mail, die mit dem Betreff "Probleme mit DC 2025" und dem Text "Ich weiß nicht, ob es bereits ein vorhandenes Problem ist oder nicht, jedoch würde ich gerne auf folgende Problematik hinweisen." begann. Der Hintergrund: Blog-Leser Leon B. hat vor einigen Tagen einen Wortmann Terra Server in Betrieb genommen und dort Windows Server 2025 Standard (Essentials Key) installiert und konfiguriert.
Wortmann Terra Server
Die Installation und Konfigurierung erfolgte ohne Probleme. Auch die Installation von Software über MSI- und EXE-Dateien erwies sich zu diesem Zeitpunkt noch als problemlos.
Als Domain Controller macht Server 2025 Probleme
Der Leser war der Meinung, dass er den Windows Server 2025 Standard noch als Domaincontroller abrunden müsse, da man (selbst bei nur 5 Benutzern eine schöne Verwaltung mit DFS Namespaces, DHCP, DNS, haben wollte). Dieser Einrichtungsschritt war auch problemlos durchführbar.
Anzeige
Die böse Überraschung kam, dass der Leser im Anschluss weitere Anwendungen auf dem System installieren wollte. Das funktionierte schlicht nicht mehr, der Leser hat festgestellt, dass der Windows-Installer Dienst auf dem DC 2025 nicht mehr funktioniert.
Sobald er eine msi-Datei zur Installation einer Software ausgeführt, erscheint zwar das Fenster "Installation wird vorbereitet", und im Task Manager sind zwei msiexec.exe Prozesse zu sehen. Der eine msiexec.exe davon gehört zur eigentlichen Installationsdatei, der zweite Eintrag erscheint mit den Startparametern msiexec.exe /V und gehört zum System.
Dabei bleibt es auch, schreibt der Nutzer, selbst nach 30 Minuten Wartezeit. Seinen eigenen Installationsprozess, der als Administrator ausgeführt wurde, konnte er im Task-Manager beenden. Aber der Stammdienst msiexec.exe /V , der vom System als Installer-Dienst gestartet wird, lässt sich weder per task kill /F o.ä. abschießen. Es kommt der Fehler "Zugriff verweigert", da der Dienst mit Systemrechten läuft.
Das Netzwerkprofil sei wie aktuell üblich nur privat und kein Domänennetz. Die Clients haben erfolgreiche Kerberos Auth, also eigentlich läuft alles, bis auf das Installer-Problem, merkt der Leser an.
Aufwendiger Test – diffiziles Fehlerbild
Der Leser hat dann den Server neu gestartet. Nach dem Neustart hat der Leser erneut versuchte, eine weitere Installation auszuführen und lief auf den beschriebenen Fehler. Die Installation über eine EXE-Datei stellt laut Aussage möglicherweise (bedingt) keine Probleme dar. Denn der Adobe Reader DC konnte auch nicht installiert werden. Der Leser vermutet aber, dass wahrscheinlich eine MSI-Installation o.ä. im Hintergrund läuft.
Bis der Leser das obige Fehlerbild herausgefunden hatte, musste er den Server zwischenzeitlich komplett per Microsoft ISO neu installieren. Denn er hat erst im zweiten Schritt festgestellt, dass das Problem ausschließlich an der Rolle als Domaincontroller liegt.
Nachdem dies klar war, hat er im zweiten Durchlauf die Rolle als Domain Controller hinzugefügt und beim Test wieder das obige Fehlerbild vorgefunden. Im nächsten Schritt hat er das System wieder herabgestuft und die kleine Domäne gelöscht. Nach dem Neustart von Windows Server 2025 und anmelden mit den lokalen Admin-Konto war es dem Blog-Leser sofort möglich, msi-Anwendungen zu installieren.
Es hängt also irgendwie mit der Funktion als Domain Controller zusammen. Die üblichen Versuche zur Reparatur einer Installation mittels sfc /scannow und DISM hatten keinen Erfolg, es wurden auch keine Fehler gefunden. Frage: Hat jemand das Gleiche beobachten können oder kann das bestätigen?
Ähnliche Artikel:
Windows Server 2025 vorgestellt
Microsoft zur Zukunft von Windows Server 2025 Hyper-V
Windows Server 2025 und Active Directory "Next Level"
Windows Server 2025: Leistungsbooster für Hyper-V
Microsoft zur Zukunft von Windows Server 2025 Hyper-V
Windows Server 2025 und Active Directory "Next Level"
Probleme mit Windows 11 24H2/Windows Server 2025
Windows Server 2025 LTSC zum 1. November 2024 freigegeben
Windows Server 2019/2022: (Auto-)Upgrade auf Windows Server 2025 angeboten
Windows Server 2025: Kritische Lizenzänderungen?
Windows Server 2025: Unvollendet und buggy?
Windows Server 2025: iSCSI "Boot Device inaccessible" gefixt
Anzeige
Wurden verschiedene MSIs getestet? Tritt das bei jedem MSI auf?
Falls noch nicht passiert, würde ich mal die Protokollierung via msiexec.exe /log eine_logdatei.log benutzen, um möglicherweise der Ursache näherzukommen.
Klingt nach Standard GPOs und dem Versuch, MSIs zu verifzieren, CRLs online zu holen etc.
Was sagen die EventLogs? Warum zum Teufel installiert man einen Adobe Acrobat auf einem Server? Und wenn der Rechner nur ein DC sein soll, warum nicht ein Windows Core und der Rest von einem Admin-Rechner aus? Aber ich muss ja nicht alles verstehen…
Mal mit einem Konto ausprobiert das nicht Administrator heißt?
Guten Morgen in die Runde,
@Dalai ja betrifft alle msi`s unabhängig von der Herkunft auch bspw. das RMM Tool lässt sich nicht installieren.
/log werde ich testen und mal schauen ob etwas interessantes drinnen steht.
@Thomas
leider nein, das hatte ich geprüft. Eventlogs keine Einträge. Werde am Wochenende noch mal eine VM Installation vornehmen und das Szenario nachspielen.
Wie gesagt 5 User mini Server / Essentials, da geht kein Core und Admin PC.
@Simon
ja auch getestet, aber der User war dann in der Dom-Adm Gruppe.
Vielen Dank schon Mal für den Input!
Was für Dienste laufen denn sonst noch auf dem System? Bei recht kleinen Kunden, wo dann bspw. noch andere Software auf dem DC läuft, beobachten wir ähnliches.
Bei uns hat dann die Software einen Dienst eingerichtet und diesen mit Start "Automatisch" eingerichtet. Hier half es den Dienst auf "Automatisch (Verzögerter Start)" zu konfigurieren.
Wir stellen dann zusätzlich fest, dass der Server nicht mehr von außen per PRTG (SNMP / WMI) zu erreichen ist und auch andere Dienste gar nicht mehr starten bzw. nicht neu gestartet werden können.
DC ist DC ist DC und nix anderes, oder wie war das?
Ich wüsste kein noch so kleines Anwendungsszenario wo eine Essentials Lizenz wirklich ausreichen würde. Standard Lizenz, Hyper-V + DC + File/Anwendung/Print.
5 User glücklich. Läuft.
So ist es.
Ein DC ist ein DC.
Darauf wird keine Software installiert, außer der, die für einen DC nötig bzw. sinnvoll ist (wie z.B. DNS, DHCP, NTP).
Selbst so etwas wie Printserver richtet man NICHT auf einem DC ein.
Printserver, Terminalserver, Hyper-V-Rolle, etc. und auch Softwareinstallation auf einem Server nur auf einem Member-Server, NIE auf einem DC!
Daher finde ich das Verhalten des DCs bei dem Versuch, Software zu installieren, genau richtig.
Der Ehrenrettung des Posters:
Was haben XBox und Game-Services auf einem Server zu suchen? Oder ein Tablet-Modus? Oder XPS/PDF Drucker? oder Windows-Feedbacks, Designs aus dem Windows-Store?
Bei jedem Windows Klicki-Bunti Server (nicht Core) per Default dabei.
Wenn wir schon dabei sind gehört der DHCP ebenso genau _nicht_ auf den Domain Controller: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/disable-or-remove-the-dhcp-server-service-installed-on-any-domain-controllers
Zusätzlich sollte man dann ggfs. noch bedenken, dass so ein Tier 0 System in einer eigenen Tier 0 Virtualisierung oder gleich auf Blech läuft. ;)
Ich kann es nicht final beurteilen – aber spätestens wenn irgend etwas zur Protokollierung oder Funktionserweiterung für den DC per .msi-Installationsdatei benötigt wird, kommst Du mit deiner Haltung vor der berühmten Wand an, wo es halt nicht weiter geht.
Die Aussage war, dass der Windows Installer bei MSIs mutmaßlich kaputt ist. In dieser Hinsicht sind Hinweise zur weiteren Diagnose sicherlich zielführend – die Feststellung "auf dem DC installiert man nichts" hilft imho nicht. Es gibt doch drei Szenarien:
a) Es ist Einzelfall-Verhalten und kann von Dritten nicht verifiziert werden – möglicherweise, weil es an der speziellen Hardware hängt.
b) es ist by-design und es gibt eine klare Erklärung dafür (kenne ich aber nicht und die Fehlerbeschreibung spricht dagegen).
c) Es ist ein Bug, der korrigiert gehört
Oder sehe ich das Ganze mal wieder falsch – hab ja von dem Zeugs Null Ahnung, aber ganz viel Meinung.
Das gleiche Fehlerbild hatte ich auch schon. Da lag es aber daran, das XenTools hängen geblieben sind. Dies resultierte darin, dass ein Dienst ewig im "Starting" Modus verblieb. Dies verhinderte, dass andere Task Scheduler Tasks oder Dienstaktionen verhindert wurden. Somit konnte auch der Windows Installer Dienst nicht mehr starten. Die Lösung war ein Verzögerter Start der XenTools auf einem DC Server 2025.
Referenz: https://xcp-ng.org/forum/topic/9720/windows-server-2025-on-xcp-ng/52
Vielleicht ist es etwas ähnliches :)
Danke für die Information – der Betroffene liest hier mit – wobei imho keine XenTools oder Zusätze auf dem neu aufgesetzten Server installiert waren.