20
Server 2019: Serverrollen können nur per PowerShell installiert werden
Hallo zusammen,
ich habe folgendes Problem: Auf einem frisch installierten Server (Win 2019) kann ich aktuell keine Rollen über die GUI (Server-Manager) hinzufügen. Jeder beliebige Versuch, eine Rolle zu installieren, ergibt sofort das beigefügte Fehlerbild (hier am Beispiel der Netzwerkrichtliniendienste). Merkwürdig ist dabei, dass die Installation per PowerShell hingegen ohne Probleme funktioniert und auch durchläuft.
Habt ihr da eine Idee? In der Ereignisanzeige habe ich erst einmal unter "System" oder "Anwendung" nichts Auffälliges finden können. Gibt es sonst noch einen Ort, wo man dem Problem Log-technisch auf die Schliche kommen kann?
Viele Grüße
Michael
ich habe folgendes Problem: Auf einem frisch installierten Server (Win 2019) kann ich aktuell keine Rollen über die GUI (Server-Manager) hinzufügen. Jeder beliebige Versuch, eine Rolle zu installieren, ergibt sofort das beigefügte Fehlerbild (hier am Beispiel der Netzwerkrichtliniendienste). Merkwürdig ist dabei, dass die Installation per PowerShell hingegen ohne Probleme funktioniert und auch durchläuft.
Habt ihr da eine Idee? In der Ereignisanzeige habe ich erst einmal unter "System" oder "Anwendung" nichts Auffälliges finden können. Gibt es sonst noch einen Ort, wo man dem Problem Log-technisch auf die Schliche kommen kann?
Viele Grüße
Michael
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2642377815
Url: https://administrator.de/forum/server-2019-serverrollen-koennen-nur-per-powershell-installiert-werden-2642377815.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
wirklich frisch installiert? Das kann vorkommen, wenn man IIS deinstalliert und dabei den zuvor installierten Windows-Prozessaktivierungsdienst nicht auch entfernst.
Was kommt denn als Fehlermeldung?
Grüße
lcer
wirklich frisch installiert? Das kann vorkommen, wenn man IIS deinstalliert und dabei den zuvor installierten Windows-Prozessaktivierungsdienst nicht auch entfernst.
Was kommt denn als Fehlermeldung?
Grüße
lcer
Zitat von @lcer00:
wirklich frisch installiert? Das kann vorkommen, wenn man IIS deinstalliert und dabei den zuvor installierten Windows-Prozessaktivierungsdienst nicht auch entfernst.
wirklich frisch installiert? Das kann vorkommen, wenn man IIS deinstalliert und dabei den zuvor installierten Windows-Prozessaktivierungsdienst nicht auch entfernst.
Ja, wobei ich zuvor nur einige Rollen (u. a. IIS) per PowerShell installiert (also nicht deinstalliert!) habe. Als ich nun per GUI weitere Rollen hinzufügen wollte, kam es genau zu diesem Fehler.
Was kommt denn als Fehlermeldung?
Nichts spezifisches. In der GUI des Server-Managers erscheint der Laufbalken (ungefüllt; "Installation wird gestartet") und kurz danach erscheint das rote "X" mit dem Hinweis "Featureinstallation" (siehe Screenshot oben). Eine weitere Fehlermeldung erscheint leider nicht.
Gruß
Michael
Moin...
na dann lösche die kiste, und mach es neu... das würde ich nicht zuverlässig ansehen!
Frank
auf einem frisch installierten Server (Win 2019)
na dann lösche die kiste, und mach es neu... das würde ich nicht zuverlässig ansehen!
Frank
1
sind da vielleicht die 128 Tage rum?
Servus,
wo läuft die Installation genau VM/Blech? Wenn VM welcher Hypervisor mit welchen VM-Settings? Insbesondere evt. Sharing-Einstellungen mit dem Host.
Schau dazu mal in folgende beiden Threads
https://social.technet.microsoft.com/Forums/en-US/e5ee79fb-7e71-41c2-aa2 ...
https://docs.microsoft.com/en-us/answers/questions/427362/red-x-appearin ...
Grüße Uwe
wo läuft die Installation genau VM/Blech? Wenn VM welcher Hypervisor mit welchen VM-Settings? Insbesondere evt. Sharing-Einstellungen mit dem Host.
Schau dazu mal in folgende beiden Threads
https://social.technet.microsoft.com/Forums/en-US/e5ee79fb-7e71-41c2-aa2 ...
https://docs.microsoft.com/en-us/answers/questions/427362/red-x-appearin ...
Gibt es sonst noch einen Ort, wo man dem Problem Log-technisch auf die Schliche kommen kann?
Im Servicing "Setup" Eventlog.Grüße Uwe
Hallo!
Ich werde die Kiste dann jetzt mal platt machen und neu aufsetzen. Ist vermutlich schneller.
Trotzdem danke allen!
Zitat von @Vision2015:
na dann lösche die kiste, und mach es neu... das würde ich nicht zuverlässig ansehen!
Ja, das war mein Ansatz, wenn keine Lösung gefunden wird.na dann lösche die kiste, und mach es neu... das würde ich nicht zuverlässig ansehen!
Zitat von @colinardo:
OK, da dann hatte ich dort schon geguckt. Da steht leider überhaupt nichts... Gibt es sonst noch einen Ort, wo man dem Problem Log-technisch auf die Schliche kommen kann?
Im Servicing "Setup" Eventlog.Ich werde die Kiste dann jetzt mal platt machen und neu aufsetzen. Ist vermutlich schneller.
Trotzdem danke allen!
Hallo zusammen,
so, doch noch nicht gelöst, aber zumindest einen Schritt weiter: Offenbar scheint das Problem an einer GPO zu liegen, denn auch bei einer frischen Neuinstallation trat das Problem wieder erneut 1:1 auf, d. h., sofort nach dem Anklicken auf "Installieren" erscheint das o. a. Rollenbild. Wenn ich den Server nun testweise wieder aus der Domäne entferne, klappt alles, wie es soll. Genau andersherum lässt sich der Fehler reproduzieren, wenn ich den Server wieder in die Domäne (hier: 2012 R2-Umgebung) integriere.
Es ist nur sehr strange, dass die Installation von Rollen und Features wiederum per PowerShell funktioniert - egal ob als Domänenmitglied oder auch nicht. Habt ihr da eine Idee, welche Einstellung dazwischenfunken könnte? Mangels Log gestaltet sich das ja, wie die Nadel im Heuhaufen zu finden.
Viele Grüße
Michael
so, doch noch nicht gelöst, aber zumindest einen Schritt weiter: Offenbar scheint das Problem an einer GPO zu liegen, denn auch bei einer frischen Neuinstallation trat das Problem wieder erneut 1:1 auf, d. h., sofort nach dem Anklicken auf "Installieren" erscheint das o. a. Rollenbild. Wenn ich den Server nun testweise wieder aus der Domäne entferne, klappt alles, wie es soll. Genau andersherum lässt sich der Fehler reproduzieren, wenn ich den Server wieder in die Domäne (hier: 2012 R2-Umgebung) integriere.
Es ist nur sehr strange, dass die Installation von Rollen und Features wiederum per PowerShell funktioniert - egal ob als Domänenmitglied oder auch nicht. Habt ihr da eine Idee, welche Einstellung dazwischenfunken könnte? Mangels Log gestaltet sich das ja, wie die Nadel im Heuhaufen zu finden.
Viele Grüße
Michael
Hallo,
Der Servermanager steuert die Rolleninstallation per winrm. Das kann man sehen, wenn man das Instllatopnssktipt exportiert.
Ich tippe da auf ein Problem mit winrm. Vergleich mal die winrm-Config auf dem Server und auf einem anderen donänenserver, bei dem das funktioniert.
Grüße
lcer
Der Servermanager steuert die Rolleninstallation per winrm. Das kann man sehen, wenn man das Instllatopnssktipt exportiert.
Ich tippe da auf ein Problem mit winrm. Vergleich mal die winrm-Config auf dem Server und auf einem anderen donänenserver, bei dem das funktioniert.
winrm g winrm/config
winrm e winrm/config/listenerGrüße
lcer
Hallo
Habe mal einen Vergleich gemacht, jedoch keine Unterschiede festgestellt; einzig mittels winrm g winrm/config ergibt sich ein kleiner Unterschied im Detail:
Funktionierender Server (2012 R2):
Neuer Server mit dem Problem:
Die Einstellungen sind auf beiden Maschinen nicht per GPO konfiguriert und daher offenbar vom Standard her unterschiedlich. Aber selbst, wenn ich die Einstellungen auf dem neuen Server entsprechend angleiche, tritt der Fehler auf.
Ich habe jetzt mal beide Maschinen in die gleiche Gruppe gelegt, sodass auch die gleichen GPOs gezogen werden. Leider ohne Erfolg dahingehend, dass der Fehler weiterhin auftritt.
Gruß
Michael
Zitat von @lcer00:
Ich tippe da auf ein Problem mit winrm. Vergleich mal die winrm-Config auf dem Server und auf einem anderen donänenserver, bei dem das funktioniert.
Ich tippe da auf ein Problem mit winrm. Vergleich mal die winrm-Config auf dem Server und auf einem anderen donänenserver, bei dem das funktioniert.
winrm g winrm/config
winrm e winrm/config/listenerHabe mal einen Vergleich gemacht, jedoch keine Unterschiede festgestellt; einzig mittels winrm g winrm/config ergibt sich ein kleiner Unterschied im Detail:
Funktionierender Server (2012 R2):
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647Neuer Server mit dem Problem:
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 10
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 25
MaxMemoryPerShellMB = 1024
MaxShellsPerUser = 30Die Einstellungen sind auf beiden Maschinen nicht per GPO konfiguriert und daher offenbar vom Standard her unterschiedlich. Aber selbst, wenn ich die Einstellungen auf dem neuen Server entsprechend angleiche, tritt der Fehler auf.
Ich habe jetzt mal beide Maschinen in die gleiche Gruppe gelegt, sodass auch die gleichen GPOs gezogen werden. Leider ohne Erfolg dahingehend, dass der Fehler weiterhin auftritt.
Gruß
Michael
Hallo,
und sind die Listener Korrekt?
Grüße
lcer
und sind die Listener Korrekt?
Grüße
lcer
und sind die Listener Korrekt?
Da steht zumindestens bei beiden Maschinen der gleiche Inhalt drin (natürlich mit Ausnahme der IP):
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.20.1.206, 127.0.0.1, ::1, fe80::7c0b:3cc1:c8bd:756f%14Gruß
Michael
Schau mal in die folgenden Eventlogs:
Und lass mal zusätzlich Process Monitor laufen während du ein Feature installierst.
Wieso ist der Beitrag gelöst? Bitte dann auch noch die Lösung hier posten, merci!
Grüße Uwe
p.s. Wäre schön gewesen wenn du meine anderen Fragen zu Beginn auch noch beantwortet oder zumindest Stellung dazu bezogen hättest.
Und lass mal zusätzlich Process Monitor laufen während du ein Feature installierst.
Wieso ist der Beitrag gelöst? Bitte dann auch noch die Lösung hier posten, merci!
Grüße Uwe
p.s. Wäre schön gewesen wenn du meine anderen Fragen zu Beginn auch noch beantwortet oder zumindest Stellung dazu bezogen hättest.
2
Hallo,
heute noch einige Tests gemacht, aber irgendwie komme ich nicht weiter. Ich benutze derzeit zum Testen die Grundinstallation mit allen Updates nach Windows Update 2022-04. Nach wie vor das absolut reproduzierbare Problem: Wurde die Maschine in die Domäne aufgenommen, können über den Server-Manager keine Updates installiert werden - der Installationsfortschritt springt innerhalb von einer Sekunde direkt auf "Fehler". Nehme ich die Maschine wieder aus der Domäne heraus, dann funktioniert alles, wie es soll.
Testweise habe ich die neue Maschine in eine OU genommen, bei der die Vererbung von Gruppenrichtlinien auf Maschinenebene vollständig ausgeschaltet ist: Gleiches Fehlerbild.
Das Protokoll ...DeploymentProvider ist soweit unauffällig. Die erfolgreich Aktionen werden dort geloggt, nicht jedoch die Fehlerfälle.
Im Protokoll ...ManagementProvider gibt es in der Tat diverse Einträge, die bei der Domänenmitgliedschaft und dem Versuch, eine Rolle zu installieren, generiert werden:
Dort kann ich auch nichts Auffälliges erkennen. In beiden Fällen (mit und ohne Domäne) werden diverse Fehler protokolliert, aber letztendlich klappt es, die Rollen ohne Domänenmitgliedschaft zu installieren.
Habt ihr noch eine Idee?
Gruß
Michael
heute noch einige Tests gemacht, aber irgendwie komme ich nicht weiter. Ich benutze derzeit zum Testen die Grundinstallation mit allen Updates nach Windows Update 2022-04. Nach wie vor das absolut reproduzierbare Problem: Wurde die Maschine in die Domäne aufgenommen, können über den Server-Manager keine Updates installiert werden - der Installationsfortschritt springt innerhalb von einer Sekunde direkt auf "Fehler". Nehme ich die Maschine wieder aus der Domäne heraus, dann funktioniert alles, wie es soll.
Testweise habe ich die neue Maschine in eine OU genommen, bei der die Vererbung von Gruppenrichtlinien auf Maschinenebene vollständig ausgeschaltet ist: Gleiches Fehlerbild.
Das Protokoll ...DeploymentProvider ist soweit unauffällig. Die erfolgreich Aktionen werden dort geloggt, nicht jedoch die Fehlerfälle.
Im Protokoll ...ManagementProvider gibt es in der Tat diverse Einträge, die bei der Domänenmitgliedschaft und dem Versuch, eine Rolle zu installieren, generiert werden:
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-Containers-CCG/Admin [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Das System kann die angegebene Datei nicht finden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-RemoteDesktopServices-RemoteFX-VM-Kernel-Mode-Transport/Debug [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Der angegebene Ressourcentyp wurde nicht in der Image-Datei gefunden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-SPB-HIDI2C/Analytic [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Das System kann die angegebene Datei nicht finden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-SystemSettingsThreshold/Debug [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Das System kann die angegebene Datei nicht finden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-SystemSettingsThreshold/Diagnostic [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Das System kann die angegebene Datei nicht finden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: Microsoft-Windows-SystemSettingsThreshold/Operational [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Das System kann die angegebene Datei nicht finden.].
Fehler beim Öffnen der Metadaten des besitzenden Anbieters für den Kanal: NIS-Driver-WFP/Diagnostic [hResult = Beim Ausführen der Funktion ist ein Fehler aufgetreten., hLastResult = Der angegebene Ressourcentyp wurde nicht in der Image-Datei gefunden.].Und lass mal zusätzlich Process Monitor laufen während du ein Feature installierst.
Dort kann ich auch nichts Auffälliges erkennen. In beiden Fällen (mit und ohne Domäne) werden diverse Fehler protokolliert, aber letztendlich klappt es, die Rollen ohne Domänenmitgliedschaft zu installieren.
Habt ihr noch eine Idee?
Gruß
Michael
- Hast du zufällig eine Gruppenrichtlinie in der FolderRedirection konfiguriert ist? Wenn ja nehme die mal raus.
- Welche Rechte besitzt der User der den Server-Manager bei Domain-Membership öffnet, lokal als auch in der Domain?
- Benutze mal einen neu angelegten Domain-Account mit lokalen Admin-Rechten am Server.
- Ist die UAC zufällig auf dem Server an?
- Schau auch mal ins CBS.log
Dort kann ich auch nichts Auffälliges erkennen.
Und uns lässt du im Regen stehen? Wenn dir nichts auffällt eventuell doch uns 
.All Install/ Remove Roles Fail on Server Manager
Hi,
Ja, die gab es ursprünglich, aber hatte ich ja gemeinsam mit den übrigen GPOs deaktiviert. Dabei finden auch tatsächlich auf der Maschine keine Umleitungen (z. B. Home-Verzeichnis) mehr statt.
Was meinst du mit "Rechten"? Der Domänenbenutzer ist den Rollen "Domänen-Admin", "Organisations-Admin", "Domänen-Benutzer" und "Schema-Admins" zugeordnet.
Der Benutzer innerhalb der Arbeitsgruppe ist der Gruppe "Administratoren" zugeordnet.
.
Nun ja, da sind nur ein paar Info-Logs drin, wenn es funktioniert hat. Aber eben keine Fehler, Warnungen oder sonstige Katastrophen...
Hier wird nichts geloggt, wenn der Fehler auftritt.
Zitat von @colinardo:
- Hast du zufällig eine Gruppenrichtlinie in der FolderRedirection konfiguriert ist? Wenn ja nehme die mal raus.
Ja, die gab es ursprünglich, aber hatte ich ja gemeinsam mit den übrigen GPOs deaktiviert. Dabei finden auch tatsächlich auf der Maschine keine Umleitungen (z. B. Home-Verzeichnis) mehr statt.
* Welche Rechte besitzt der User der den Server-Manager bei Domain-Membership öffnet, lokal als auch in der Domain.?
Was meinst du mit "Rechten"? Der Domänenbenutzer ist den Rollen "Domänen-Admin", "Organisations-Admin", "Domänen-Benutzer" und "Schema-Admins" zugeordnet.
Der Benutzer innerhalb der Arbeitsgruppe ist der Gruppe "Administratoren" zugeordnet.
Dort kann ich auch nichts Auffälliges erkennen.
Und uns lässt du im Regen stehen? Wenn dir nichts auffällt eventuell uns .Nun ja, da sind nur ein paar Info-Logs drin, wenn es funktioniert hat. Aber eben keine Fehler, Warnungen oder sonstige Katastrophen...
Schau auch mal ins CBS.log
Hier wird nichts geloggt, wenn der Fehler auftritt.
Benutze mal einen vollkommen neu angelegten Domain-Account mit lokalen Admin-Rechten am Server.
p.s. Siehe Ergänzungen im Kommentar oben.
Irgendwie werde ich das Gefühl nicht los das du keine Lust auf unsere Hilfe hast da du uns jegliche handfesten Logs S. auf W. verweigerst und uns ins Blaue raten lässt, das macht so einseitig ehrlich gesagt wenig Sinn
.
p.s. Siehe Ergänzungen im Kommentar oben.
Hier wird nichts geloggt, wenn der Fehler auftritt.
Das da nichts steht kann nicht sein!Irgendwie werde ich das Gefühl nicht los das du keine Lust auf unsere Hilfe hast da du uns jegliche handfesten Logs S. auf W. verweigerst und uns ins Blaue raten lässt, das macht so einseitig ehrlich gesagt wenig Sinn
.
Hi,
Hatte diesen Hinweis vor meinem letzten Post nicht gesehen. Daher gleich mal getestet und was soll ich sagen: Auf dem ersten Blick funktioniert es. Heißt also: Ich habe einen neuen Benutzer mit den gleichen Rechten angelegt und damit scheint es zu funzen. Zumindest ergibt dies auch ein erster Test, nachdem ich die GPOs wieder reaktiviert habe...
Dann ist die Neueinrichtung eines Admin-Accounts definitiv die schnellere Alternative, das ganze zum Laufen zu bringen!
Viele Dank für's Finden!
Hatte diesen Hinweis vor meinem letzten Post nicht gesehen. Daher gleich mal getestet und was soll ich sagen: Auf dem ersten Blick funktioniert es. Heißt also: Ich habe einen neuen Benutzer mit den gleichen Rechten angelegt und damit scheint es zu funzen. Zumindest ergibt dies auch ein erster Test, nachdem ich die GPOs wieder reaktiviert habe...
Dann ist die Neueinrichtung eines Admin-Accounts definitiv die schnellere Alternative, das ganze zum Laufen zu bringen!
Viele Dank für's Finden!
Hallo,
nun ja, nachdem gestern das Anlegen eines weiteren Benutzers das Problem gelöst hat, kommt es auch heute wieder zum gleichen Fehler, nachdem die Maschine wieder auf den Initial-Zustand zurückgesetzt wurde (frische Installation) und mit dem neuen Nutzer versucht wurde, Rollen zu installieren. Es ist mir ein Rätsel.
Gruß
Michael
nun ja, nachdem gestern das Anlegen eines weiteren Benutzers das Problem gelöst hat, kommt es auch heute wieder zum gleichen Fehler, nachdem die Maschine wieder auf den Initial-Zustand zurückgesetzt wurde (frische Installation) und mit dem neuen Nutzer versucht wurde, Rollen zu installieren.
Es ist mir ein Rätsel.Gruß
Michael
Update:
Ich konnte jetzt mal halbwegs nachvollziehen, wann der Fehler auftritt bzw. wie ich ein Auftreten des Fehlers per Workaround beheben kann. Fakt ist, der Fehler tritt, wie schon weiter oben vermutet, im Userkontext auf, offenbar getriggert durch eine GPO-Einstellung. Deaktiviere ich bei der erstmaligen Anmeldung eines Nutzers die Übernahme der GPOs, so tritt der Fehler nicht auf. Werden danach die GPOs wieder aktiviert, so tritt der Fehler reproduzierbar auf. Allerdings tritt der Fehler dann auch weiterhin auf, wenn die GPOs im Nachgang wieder deaktiviert werden.
Ich werde das Thema der "Ordnerumleitung" jetzt in einem ersten Schritt noch mal weiter unter die Lupe nehmen.
Ich konnte jetzt mal halbwegs nachvollziehen, wann der Fehler auftritt bzw. wie ich ein Auftreten des Fehlers per Workaround beheben kann. Fakt ist, der Fehler tritt, wie schon weiter oben vermutet, im Userkontext auf, offenbar getriggert durch eine GPO-Einstellung. Deaktiviere ich bei der erstmaligen Anmeldung eines Nutzers die Übernahme der GPOs, so tritt der Fehler nicht auf. Werden danach die GPOs wieder aktiviert, so tritt der Fehler reproduzierbar auf. Allerdings tritt der Fehler dann auch weiterhin auf, wenn die GPOs im Nachgang wieder deaktiviert werden.
Ich werde das Thema der "Ordnerumleitung" jetzt in einem ersten Schritt noch mal weiter unter die Lupe nehmen.
wenn die GPOs im Nachgang wieder deaktiviert werden.
Ein Hinweis auf eine "tattooing policy" die nach deaktivieren im Userprofil erhalten bleiben wenn man sie nicht mehr anwendet, und folder redirection ist eine davon (Hatte ich oben ja schon genannt). Alle Settings die außerhalb der "Policy"-Pfade in der Registry etc. angewendet werden sind permanent und werden bei deaktivieren der Policy nicht zurückgenommen und verschwinden natürlich wenn du ein neues Konto anlegst. Schau also vornehmlich bei den "Einstellungs" Policies (GPP) und nicht den Richtlinien.
