Apr 29, 2022

3758

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 2642377815

Url: https://administrator.de/contentid/2642377815

Printed on: April 27, 2024 at 19:04 o'clock

20 Comments

Latest comment

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

Zitat von @lcer00:
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...

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

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 ...

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!

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.

Zitat von @colinardo:

Gibt es sonst noch einen Ort, wo man dem Problem Log-technisch auf die Schliche kommen kann?

Im Servicing "Setup" Eventlog.

OK, da dann hatte ich dort schon geguckt. Da steht leider überhaupt nichts...

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

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.

winrm g winrm/config
winrm e winrm/config/listener

Grüße

lcer

Hallo

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.

winrm g winrm/config
winrm e winrm/config/listener

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):

 Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 7200000
        MaxConcurrentUsers = 2147483647
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 2147483647
        MaxMemoryPerShellMB = 2147483647
        MaxShellsPerUser = 2147483647

Neuer Server mit dem Problem:

Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 7200000
        MaxConcurrentUsers = 10
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 25
        MaxMemoryPerShellMB = 1024
        MaxShellsPerUser = 30

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

Hallo,

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%14

Gruß

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.

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.

Zitat von @colinardo:
Schau mal in die folgenden Eventlogs:

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.

(Des weiteren beachte auch eventuelle "sticky" rules im GPO Cache des Servers.)

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,

Zitat von @colinardo:

Hast du zufällig eine Gruppenrichtlinie in der FolderRedirection konfiguriert ist? Wenn ja nehme die mal raus.

(Des weiteren beachte auch eventuelle "sticky" rules im GPO Cache des Servers.)

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.

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,

Zitat von @colinardo:
All Install/ Remove Roles Fail on Server Manager

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

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.

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.

German Question Windows Server Microsoft

Hotly discussed

End of availability for classic Teams clientDani