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.
Kleiner Nachtrag, nur für den Fall, dass das noch nicht bekannt gewesen sein sollte. Der Parameter /log allein reicht nicht. Das vollständige Kommando zum Protokollieren ist
msiexec.exe /i setup.msi /log eine_logdatei.log
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…
Genau, es gillt: Ein DC ist ein DC ist ein DC ist ein DC ist ein DC …
Und darüber hinaus gillt: Eine Anwendung, ein Dienst, ein Server. Vorteil: Fällt mal ein System aus, kann man die anderen immer noch nutzen.
Ich kenne die Konfiguration der Hardware nicht, sinnvoll wäre aber sicher gewesen, auf dem Blech einen Hypervisor zu installieren, Hyper-V, Proxymox, ESXi (wer sichs leisten kann), whatever, und darauf die einzelnen Rollen als separate VMs. Hyper-V als Enterprise/Datacenter-Version hätte den Charme, dass er eine große Anzahl Lizenzen für Windows-Server-VMs schon intus hat… (man sollte aber idealerweise 2 haben, damit einer auch mal ausfallen darf, während ein wichtiger Kunde einen lukrativen Großauftrag platzieren möchte…)
Wahrscheinlich musste gespart werden, das rächt sich aber sobald das Blech mal ausfällt.
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.
Also ich habe gestern gerade einen 2016er Server (Desktop!) installiert – da ist weder ein Microsoft Store, noch XBOX, Gaming oder Windows Feedback drauf. Und auch auf einem 2019er nicht.
Gerade mal eine 2025er installiert – kein XBOX, kein Game, Kein Store – nur Feedback-Hub.
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.
Mit welchen ISO des Servers (Build 26100.????) wird das installiert?
Es gab auch mit Windows 11 ISOs so einige Macken.
Ist das vor oder nach Updates – und wenn ja mit welchen Stand?
Kann ja mal wieder überall herkommen – Patches wären auch nicht auszuschließen.
Gibt es hierzu ein bisschen Input?
Wir haben das gleiche Problem. Kunde hat Terra Server mit HyperV. Dort funktioniert Systemseitig alles ohne Probleme. Jede Installation usw. Dann virtuell einen 2025 als Domain Controller und bämm. Trend lässt sich nicht sauber installieren, Lohn Buchhaltungssoftware Probleme, Deinstallation über Systemsteuerung nicht mehr möglich. Noch nie solche massiven Probleme gehabt. Wir werden den Server neu mit 2022 installieren.
Ich weiß ja nicht, ob die reflexartigen Kommentare "Auf einem DC darf nix anderes laufen" an dieser Stelle hilfreich sind. Sachlich korrekt, aber ähnlich zielführend wie "Nimm doch Libre Office", wenn jemand ein Problem in Word hat.
Mal abgesehen davon, dass MS obigen Grundsatz mit SBS/Foundation jahrelang anders propagiert hat, begegnen einem in der Praxis gerade bei kleinen Kunden doch "spezielle" Anforderungen. Wie eine WaWi, die auch bei nur 2 Client-PCs gern ein AD hätte, kombiniert mit einem Kunden, der den alten "XP-Server" ohne Plattenspiegelung für immer noch ausreichend hält. Ich beneide ja jeden hier, der technische Musterlösungen durchsetzen kann, aber die Praxis kleiner IT-Dienstleister sieht oft anders aus.
Zum Thema "Das Netzwerkprofil sei wie aktuell üblich nur privat und kein Domänennetz" ein schneller Hinweis: Das kommt halt durch diese single-Server-Konfiguration ohne 2. DC/DNS. Unter Server 2019 reichte es noch, den NlaSvc neu zu starten, damit der DC sein Netzwerk erkennt. Seit 2022 klappt das nicht mehr, da kann man sich mit diesem Powershell-Sript behelfen, das einmal IPv6 vom Adapter entfernt und gleich wieder anbindet:
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
Enable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
Dann in der Aufgabenplanung einen Task einrichten mit 1 Min. Verzögerung, Trigger "Nach Systemstart":
Programm: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Parameter: -command "c:\batches\ipv6aus-an.ps1"
(wobei der Pfad zur ipv6aus-an.ps1 auf das obige Script verweist)
Ja ja, ich weiß: Gefrickel. Aber siehe oben. Theorie und Praxis sind nur in der Theorie identisch. Wer's all zu furchtbar findet, kann bitte wegschauen.
Mit dem MSI-Phänomen hat das vermutlich nichts zu tun, ich wollte dies nur flugs erwähnt haben, da der Absatz mir aufgefallen war.
Ja, es gab früher den SBS.
Aber den hat Microsoft nicht ohne Grund eingestellt.
Denn er hat selbst den Best Practices von Microsoft widersprochen.
Microsoft selbst hat damals gesagt:
Sharepoint und Exchange NICHT auf einen DC installieren, wird nicht supportet.
Und mit dem SBS haben die genau das getan: Sharepoint und Exchange auf einen DC installiert.
Dementsprechend gabs mit dem SBS sehr deutlich mehr Probleme als mit dem normalen Server.
Damals waren die Foren voll von Beiträgen wegen Problemen mit dem SBS.
Das war schlicht ein krankes Produkt.
Ach wie gut, dass Microsoft alle kranken Produkte eingestellt… ach ne, warte. Der Rest, den Microsoft in petto hat ist immer noch krank. Sorry. MS Server sind nur gefrickel. Ich wunder mich ja immer, wie sehr die Leute Linux mit ihrer Kommandozeile verteufeln, aber Microsoft Produkte einer stetigen Palette ungefixter Bugs und ohne klare Fehlermeldung oder Log Dateien toll finden.