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 das Konfigurieren 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?
Ergänzung: Inzwischen scheint die Ursache klar – das Produkt Splashtop ist involviert – siehe Windows Server 2025: Splashtop macht Probleme mit MSI-Installationen.
Ä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.
Server 2025 Enterprise. Kannst du mir da Bezugsquellen nennen?
Datacenter auf dem Wortmann Server?
Also die Kunden die ich kenne, kaufen die Wortmann Kisten, weils billig ist und nicht weil man so viel Geld rumliegen hat, dass der Datacenter Server für 5K+ eine Option ist.
Im Kern aber richtig.
Wenn das Budget klein ist Host nur mit HyperV. 2 VMs stricken DC und Applikation / Dienste.
Sicherung mit Veeam Community. Gut ist.
In so kleinen Dimensionen/Umgebungen kann ich nicht denken…
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.
Also was mir gerade so einfällt:
Auf einem DC gibt es ja keine lokalen Benutzerkonten mehr, diese Lektion musste ich vor etlichen Jahren auf die harte Tour lernen als ich versucht habe einen MSSQL-Server auf einem DC zu installieren ;) Dazu ist diese Single DC Situation auch schon immer etwas problembehaftet. Ich meine eine Installation als Domain-Admin auszuführen ist auch nicht unbedingt die beste Idee, ich kann nur nicht mehr sagen warum.
Ich würde mal schauen ob das Computerkonto des DCs (nicht nur System) auf den Ordner in dem die Installationsdatei liegt entsprechend Zugriff hat. Ich würde mal ausprobieren ob die Benutzerkontensteuerung vielleicht irgendwie mit reinspielt und diese komplett deaktivieren.
Ich erinnere mich das ich vor Jahren in einer Single DC Situation immer wieder komische Probleme hatte, während des Starts des DCs ist dann ja auch kein anderer DC und DNS vorhanden. Der DC hat das Netzwerk nach dem Start auch nicht als Domänennetzwerk erkannt. Abhilfe hat nach dem Start des DCs dann nur der Neustart des Dienstes NLA (Network Location Awareness) gebracht. Ich weiß nicht ob das auf einem aktuellen Server System noch von Relevanz ist aber schaden kann der Test ja eigentlich kaum :)
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. ;)
NO DHCP on DC lese ich zum ersten mal und mache ich persönlich in den Umgebungen wo Windows DHCP spielt, bei keinem Kunden.
DHCP Rolle ist seit NT4 typischerweise auch mit auf dem/den DC (s) bei meinen Installationen.
Der Link von Dir ist aber aber valide und durchaus nachvollziehbar.
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?
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.
Log-Dateien gibts bei Windows genug.
Aber per Default sind die meisten Logs deaktiviert, weil nämlich die Logs sehr sehr schnell sehr sehr groß werden.
Bei einer mittleren Firma und vollem Logging würden schnell mehrere GB an Logs pro Tag zusammenkommen!
Und die Performance des Systems würde auch leiden, weil das System viel Leistung auf das Protokollieren und schreiben der Logs aufwenden muß.
Lach, und da sage einmal jemand "Linux sei gefrickelt".
Es hat ja bereits jemand anders genannt. Ein HV mit einer VM als DC und einer anderen VM als Applicationsserver hätte nicht geschadet.
Gerade als IT Systemhaus oder IT-Dienstleister hat man (sollte man) fertige ISOs, Skripte und GitRepos parat haben, dass sowas automatisiert und standardisiert macht, ohne Mehrarbeit zu produzieren. Im Gegenteil. Solche etablierte Standards helfen künftig den eigenen Mitarbeitern, sich später vor Ort schneller zurecht zu finden.
Ach ich Dummerchen, ich vergesse immer, dass die typischen Klicki-Bunti-Windows-IT Systemhäuser und Dienstleister nach Zeitaufwand bezahlt werden. Die haben gar kein Incentive, gute Arbeit zu machen und Kunden Lösungen dahinzustellen, die auch in 10 Jahren noch funktionieren.
Was ist mit
– Guest Tools der Virtualisierungslösung?
– EDR / XDR Agents?
– Monitoring Agents?
die durchaus ihre Berechtigung auf einem DC haben und auch dieses Problem mit sich bringen können?
Und auch diese können automatisiert ausgerollt werden sofern man XDR/EDR Schlangenöl wirklich braucht.
Was soll Dein Einwurf bezwecken?
Da geht es um dein (und auch die anderen, die zwar im Grunde korrekt ins "DC ist DC ist DC" Horn tröten)
-> Es hat ja bereits jemand anders genannt. Ein HV mit einer VM als DC und einer anderen VM als Applicationsserver hättenicht geschadet. <-
Es ist aber auch toll, dass das Schlangenöl automatisiert ausgerollt werden kann.
Wie steht es um einen Zabbix oder Wazuh Agent bzw. die XenTools? Können vermutlich auch automatisiert ausgerollt werden, oder? XenTools bescheren einem dieses Problem zum Beispiel.
Es geht nicht um die Automatisierung / Templates / etc. da hast du vollkommen Recht und ich bin 100% bei dir.
>>Die haben gar kein Incentive, gute Arbeit zu machen und Kunden >>Lösungen dahinzustellen, die auch in 10 Jahren noch funktionieren.
Das kann ich so unterschreiben. Für eine perspektivische Planung und Konzeption will keiner Verantwortung übernehmen.
für alle die schreiben, man installiert nix auf dem DC :
die M$ ADMX Vorlagen gibt es als msi …
Du bist doch Windows Admin, oder?
Und Du kannst nicht in ein MSI Paket reinschauen und diese einzeln rausnehmen und in die richtigen Verzeichnisse verschieben?
Kann ich nicht bestätigen. Habe selbst zu Testzwecken mehrfach einen DC eingerichtet egal ob unter Windows Server 2025 Standard oder Data Center, MSI Installationspakete ließen sich immer installieren.
Windows ISOs waren immer die neusten aus der Visual Studio Enterprise Subscription.
Test-Installation vom "RustDesk" (ja, auch Fernwartungssoftware benötigt man auf einem DC) als MSI war auf einem Nicht-Wortmann-Bare-Metal-Windows-Server-2025-DC erfolgreich. Auch die Deinstallation zeigte keine Auffälligkeiten.
Wie wäre es mit Remote Desktop? Also RustDesk am besten noch übers Internet käme mir sicher nicht auf einen DC. Wenn ich einen DC von außen fernwarten will dann nur mit VPN und RDP!
Ich kann es bestätigen.
Selbes Fehlerbild.
Sobald man den DC wieder hinabstuft ist es wieder möglich.
(hilft halt nichts wenn man einen DC benötigt)…
Auch zufällig ein Terra Server, mit Terra ISO installiert?
Ja ist ein Terra Server.
Nein nicht mit Terra ISO installiert
Hi!
Ich hab im Homelab einen 2025er Server (oder soll ichs Windows 11 mit Servermanager nennen?), der als MGMT Server dient.
Ich promote den mal zum DC und übertrage ihm alle Rollen.
Läuft auf einem HP DL20 Gen9 unter ESX 8.
Gebe dann Bescheid :-)
LG
Soeben, getestet – kann es nicht nachstellen.
Server 2025 Standard (Eval) zum PDC gemacht, kein Fehler bei Installation zB. von Rustdesk. Server ist aktuell ein Build 26100.2033
Hi!
Kann ich in 2 Test Umgebungen nachvollziehen. Die DCs sind Hyper-V VMs.
Nur DC Rolle. Nicht mal DNS, DHCP und NTP.
Installiert mit MSDN ISO.
Ging mit dem Februar Patchday los. Version ist 26100.3194
Als Test MSI wird die Citrix GPO Erweiterung verwendet.
Hallo Mirtelo,
ja auf dem Windows Patchstand bin ich auch 26100.3194, habe jetzt ein weiteres System nicht nur der Terra Server.
Jetzt einen Windows Server 2025 Standard (Hyper-V VM) gleiches Problem, hier updatet sich unser ninjaRMM Agent nicht mehr, sonst ist hier außer dem FortiClient nichts drauf.
Deinstallation von KB5051987, danach 26100.2894. Problem besteht aber weiterhin, also kein direkter zusammenhang mit dem Februar Patch.
msiexec /i "C:\Users\Administrator\Downloads\meineDatei.msi" /L*V "C:\Logs\Installationslog.log"
Windows Installer-Protokollierung(Manuelle Aktivierung):
Öffnen Sie die Registrierung (Regedit.exe) und erstellen Sie den folgenden Unterschlüssel und Schlüssel:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Erstellen Sie einen neuen Reg_SZ-Wert mit dem Namen Logging und setzen Sie die Daten auf voicewarmupx.
Die Buchstaben im Wertfeld können in beliebiger Reihenfolge sein und aktivieren verschiedene Protokollierungsmodi:
v – Ausführliche Ausgabe
o – Nachrichten außerhalb des Speicherplatzes
i – Statusmeldungen
c – Anfängliche UI-Parameter
e – Alle Fehlermeldungen
w – Nicht tödliche Warnungen
a – Starten von Aktionen
r – Aktionsspezifische Datensätze
m – Nicht genügend Arbeitsspeicher- oder fatale Ausgangsinformationen
u – Benutzeranforderungen
p – Terminaleigenschaften
+ – An vorhandene Datei anhängen
x – Zusätzliche Debugging-Informationen
Des weiteren habe ich in der Protokolldatei folgenden Eintrag gefunden:
MSI (s) (5C:30) [08:57:11:381]: Machine policy value 'DisableMsi' is 1
Der Wert sollte hier liegen:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Er ist nicht da!!!
Ich habe den Wert angelegt DisableMsi REG_DWORD "0"
Neustart Server, der Installer Dienst hat sich ja wieder abgeschossen.
Erneutes Ausführen der msi:
Logdatei, hört einfach auf, wie als wäre er gecrasht:
MSI (s) (F4:1C) [09:07:38:741]: RESTART MANAGER: Session opened.
MSI (s) (F4:1C) [09:07:38:741]: Engine has iefSecondSequence set to true.
MSI (s) (F4:1C) [09:07:38:741]: TRANSFORMS property is now:
MSI (s) (F4:1C) [09:07:38:741]: PROPERTY CHANGE: Deleting SOURCEDIR property. Its current value is 'C:\Users\Administrator\Downloads\'.
MSI (s) (F4:1C) [09:07:38:741]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'.
MSI (s) (F4:1C) [09:07:38:745]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming
MSI (s) (F4:1C) [09:07:38:745]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\Favorites
MSI (s) (F4:1C) [09:07:38:747]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Network Shortcuts
MSI (s) (F4:1C) [09:07:38:747]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\Documents
MSI (s) (F4:1C) [09:07:38:749]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
MSI (s) (F4:1C) [09:07:38:749]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Recent
MSI (s) (F4:1C) [09:07:38:751]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\SendTo
MSI (s) (F4:1C) [09:07:38:751]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Templates
MSI (s) (F4:1C) [09:07:38:751]: SHELL32::SHGetFolderPath returned: C:\ProgramData
MSI (s) (F4:1C) [09:07:38:753]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\AppData\Local
MSI (s) (F4:1C) [09:07:38:753]: SHELL32::SHGetFolderPath returned: C:\Users\Administrator\Pictures
MSI (s) (F4:1C) [09:07:38:755]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools
MSI (s) (F4:1C) [09:07:38:757]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\S
Weiterer Tippp von Thomas Jakob früher in dieser Unterhaltung:
# Deaktivieren der MSI-Überprüfung
Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\Software\Policies\Microsoft\Windows\Installer" -ValueName "AlwaysInstallElevated" -Type DWORD -Value 0
# Deaktivieren der Überprüfung von Zertifikatsperrlisten (CRLs)
Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings" -ValueName "CertificateRevocation" -Type DWORD -Value 0
# Deaktivieren der Online-Zertifikatsüberprüfung
Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot" -ValueName "DisableRootAutoUpdate" -Type DWORD -Value 1
# Deaktivieren der Überprüfung von Zertifikaten in Internet Explorer
Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -ValueName "CertificateRevocation" -Type DWORD -Value 0
# Erzwingen der Aktualisierung der Gruppenrichtlinien
gpupdate /force
Gleiches Problem.
Im Log kommt er einen Buchstaben weiter:
MSI (s) (F4:D0) [09:20:34:151]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools
MSI (s) (F4:D0) [09:20:34:151]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\St
Auch den Einwand bzgl. Domänennetz als Skript umgesetzt.
# Deaktivieren der IPv6-Bindung für alle Netzwerkadapter
Get-NetAdapter | ForEach-Object {
Disable-NetAdapterBinding -Name $_.Name -ComponentID ms_tcpip6
}
# Aktivieren der IPv6-Bindung für alle Netzwerkadapter
Get-NetAdapter | ForEach-Object {
Enable-NetAdapterBinding -Name $_.Name -ComponentID ms_tcpip6
}
Bin noch auf der Suche.
Moin in die Runde.
Gerade mal nach gelesen, Essentials darf nicht virtualisiert werden und hat auch Einschränkungen bei den Cores der CPU oder mit deutschen Worten, am falschen Ende gespart. Natürlich gehört auf einen DC nur AD, DCHP, DNS NTP und DFS und nix weiter. Mit der normalen Standartversion hätte man das Blech bis zu 16 Kernen sowie 2 virtuelle Maschinen lizensiert. Einer DC der andere Apps oder was auch immer.
Ist der Ordner C:\TEMP vorhanden? Nach einem Domainbeitritt oder auch als DC will der nämlich dorthin standardmäßig die MSI Pakete entpacken. Ist der nicht vorhanden kommt es auch zu dem beschriebenen Fehlerbild.
Ich kann es gerade nicht validieren, möchte nur ein altes Thema an der Stelle aufwärmen –
https://www.windows-faq.de/2016/12/23/diese-app-kann-nicht-geoeffnet-werden-windows-10-administratorkonto/
Nur ein Schuß ins Blaue, wenn es nicht hilft, macht bitte keinen Elefanten daraus.
Auf X gab es noch folgenden Hinweis, den ich mal einstelle:
Kann ich so nicht bestätigen, hilft leider nicht bei der MSI Installation.
Guten Morgen,
schade, dass hier so viele unnütze Kommentare erstellt werden.
Ich kann das definitiv bestätigen. Habe gestern das gleiche Problem mit einem Terra 3000er Server gehabt. Vorinstalliertes Essentials 2025 ISO zum DC angehoben. Danach war es nicht mehr möglich MSI Pakete zu installieren.
Werde ein MS Ticket erstellen und sollte ich eine Lösung erhalten, diese hier posten.
Danke für das Feedback. Bzgl. der "unnütze Kommentare" sitze ich als Betreiber zwischen allen Stühlen, wo lösche ich, wo nicht und hoffe, dass einige Leser sich einfach irgendwann mal berappeln und die Kommentierung lassen – na ja, die Hoffnung stirbt zuletzt …
Ich versuche grad den Fehler zu reproduzieren. Es wäre interessant, ob der Leser auch Servereye, und wenn ja, auch mit Smartupdates einsetzt?
Wir haben das Phänomen nun auch an zwei Systemen. Der eine Server läuft auf einem Blech und der andere virtualisiert.
Viele Grüße
Marc
Hi Marc,
noch zu deiner Frage, wir nutzen kein servereye, Problem tritt auch unabhängig von von Hardware oder VM auf.
Wir nutzen hier ninjaRMM.
LG
Moin,
bei uns das gleiche, 2025 Essentials. Es ist nicht möglich Software zu installieren oder zu deinstallieren. z.B. MDaemon läuft nicht, wir mussten nun das AD herunterstufen, damit die MA arbeiten können.
Das installieren von Serverrollen läuft problemlos durch.
Was mir jedoch auffällt, der Server wurde am Montag vorinstalliert, am Freitag ausgeliefert. Am Samstag lief noch alles, am Sonntag dann das Problem. Updates oder andere Software wuden nicht installiert.
Hi Leon,
das kann ich bestätigen. Wir haben die zwei betroffenen Systeme auch vorinstalliert. Bei dem einen haben wir den DC migriert (Hyper-V virtualisiert) und den anderen Server (Terra Mini-Server) komplett neu vorbereitet. Die Systeme ließen sich problemlos einrichten, bis man dann plötzlich keine MSI Pakete mehr installieren konnte.
Leider habe ich von Seiten MS noch keine Rückmeldung.
Hallo in die Runde,
ich habe inzwischen auch noch weitere Systeme unabhängig ob Terra Server, Broadcom VM oder Hyper-V. Zum Glück ist ist es bei mir nicht kritisch, da in der Regel der DC leer ist, jedoch habe ich auch noch keine Lösung gefunden, versuche gerade nicht über MS sondern über einen Softwarehersteller für RMM Software ggfls. zu einer Lösung zu kommen, da die Installation fehlschlägt.
Ich würde mich sehr über Updates freuen, sobald jemand neue Informationen hat.
Den Weg über MS muss ich dann aber auch zeitnah gehen.
LG
Ich betreibe in einem sehr kleinen Betrieb auch einen DC, auf welchem parallel weitere Dienste und Software (u.A. eine zentrale Backup Lösung) laufen. Nach dem Upgrade auf Server 2025 traten Ende 2024 zunächst keine Probleme auf. Erst bei einem Regelbesuch zwecks Wartung (Februar) lief die Backup Lösung (Veeam Backup & Replication) nicht mehr. PostgreSQL 15 versagt auch den Dienst (Dienst verweilt im Status 'Starting'). MSIs lassen sich nicht mehr installieren.
Nach Deinstallation von zwei nicht produktiv relevanten Software-Paketen auf dem DC schien zunächst wieder alles zu laufen. Am darauf folgenden Tag trat aber das alte Fehlerbild wieder zu Tage.
Zum Glück sind geschäftskritische Anwendungen nicht betroffen; auf Dauer ohne Backup zu fahren stellt logischerweise aber keine Option dar.
Ich hoffe auf schnelle Nachbesserung seitens MS.
Hallo an die Runde,
ich kann das ganze ebenfalls bestätigen und wir benötigen dringend eine Lösung für das Problem.
HyperV Maschine von Dell.
2025 Standard VM (nicht essentials) Version 10.0.26100 Build 26100.
(ISO von Feb 25)
Sobald man die VM als DC hochstuft, wird kein MSI-Paket mehr installiert.
Im Ereignislog wird nur der Start der Transaktion geloggt.
In der Log Datei kommt kein Fehler. Die Relevanten Zeilen sind folgende:
MSI (s) (70:58) [16:44:03:733]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Templates
MSI (s) (70:58) [16:44:03:735]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts
MSI (s) (70:30) [17:15:3Installer is no longer responding.
Installer is no longer responding.
Installer is no longer responding.
Hallo Zusammen,
wir konnten das Problem gestern beheben, indem wir alle FSMO Rollen auf den zweiten DC verschoben haben, danach Neustart des ersten DCs und MSI Installationen waren sofort wieder möglich. Das kuriose ist, dass auf dem zweiten DC auch nach Neustart weiterhin MSI Installationen möglich sind… Vielleicht holft das ja dem einen oder anderen.
Splashtop scheint der Übeltäter zu sein in manchen Fällen, teste das gleich
https://techcommunity.microsoft.com/discussions/windowsserver/windows-server-2025-dc-wont-install–uninstall-msi-packages-nic-domain-category-/4393495
Das Deaktivieren des Splashtop Remote Service und das Beenden von 2 festhängenden Splashtopremoteservice Prozessen durch Neustart, lassen nun wieder MSI Installationen zu.
Können wir hier bestätigen.
Guten Morgen,
leider nutzen wir kein Splashtop. Das scheint somit nicht das einzige Problem zu sein.
Ich bin seit knapp einer Woche mit dem MS Support an der Problemlösung. Leider haben wir bis jetzt noch nicht die Lösung gefunden. Heute will sich der technische Leiter der MS Supportabteilung mit mir in Verbindung setzen. Sobald ich eine Lösung habe, melde ich mich.
Danke – interessante Information – kann Remote Desktop mit reinspielen?
Hallo in Die Runde, ich hatte das gleiche Problem mit dem Server 2025 Essential
Ich habe RDP Zugriff auf dem Server eingeschaltet gehabt und konnte keine MSI Programme installieren, jetzt habe ich den RDP Zugriff wieder ausgeschaltet und konnte z.B. Adobe Reader installieren.
Testet es mal.
Ich werde es auch weiter beobachten und mich nochmal melden.
Update
Bis jetzt konnte ich auf dem Server Programme installieren ohne das ein Problem bei der Installation auftrat.
Moin Ronny,
besten Dank für die Info. Leider führt das bei meinen Servern nicht zum Erfolg.
Das deaktivieren oder aktiveren von RDP führt leider zu keiner Änderung.
Leider bekomme ich auch von Seiten MS Support nur wenig bis schlechte Rückmeldung.
VG
Marc