Server Core mit PowerShell statt cmd.exe starten


    Tags: ,

    Windows Server CoreNach dem Logon an der Konsole von Server Core startet standard­mäßig der alte Kommando­inter­preter. In der Regel wird man aber die fort­ge­schrittenen Fähig­keiten von PowerShell bevor­zugen. Dieses Verhalten kann man per Registry-Key oder GPO ändern, wobei das Targeting jedoch nicht ein­fach ist.

    Auch wenn man Server Core in der Regel remote verwalten wird, gibt es immer wieder Fälle, wo man Aufgaben an der Konsole erledigen muss. PowerShell muss man dann nach dem Logon immer manuell starten, weil das OS per Voreinstellung die alte Eingabe­aufforderung öffnet.

    Will man diese Vorgabe interaktiv ändern, dann passt man den Schlüssel Shell in der Registrier­datenbank unter "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" an. Er enthält unter Server Core nicht wie erwartet die Zeichenkette "cmd.exe", sondern "explorer.exe". Diese ersetzt man durch "PowerShell.exe":

    Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' `
    -Name Shell -Value "powershell.exe"

    Nachdem sich regedit.exe auch unter Server Core ausführen lässt, könnte man den angegebenen Wert auch über die GUI ändern.

    PowerShell über den zuständigen Registry-Schlüssel als Standard festlegen

    Shell über GPO festlegen

    Verwaltet man viele Server und möchte PowerShell überall als Default setzen, dann bieten sich dafür die Gruppen­richtlinien an. Dort stehen zwei Optionen zur Verfügung:

    • Benutzer­definierte Benutzer­oberfläche unter Benutzer­konfiguration => Richtlinien => Administrative Vorlagen => System. Eine Entsprechung dafür unter Computer­konfiguration gibt es nicht, so dass man auf diesem Weg die Shell nur für die ausgewählten User ändert.
    • Einsatz der Group Policy Preferences (GPP), um in den oben genannten Registry-Schlüssel den Wert "powershell.exe" zu schreiben. Diese Änderung wirkt sich dann auf alle Benutzer der betreffenden Rechner aus.

    Registry-Schlüssel für die Standard-Shell über GPP ändern

    In beiden Fällen muss man sich überlegen, wie man das GPO auf Server Core beschränkt. Wendet man es auf Server mit Desktop Experience an, dann verschwindet der Windows Explorer und man erhält die bloße Kommando­zeile.

    Die GPP erweisen sich mit der Zielgruppen­adressierung als wesentlich flexibler. Hier ließe sich einfach dieser Registry-Schlüssel auswerten, um eine Core-Installation zu identifizieren:

    (Get-ItemProperty 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion').InstallationType

    Hat er den Wert "Server Core", dann sollte das GPO ausgeführt werden.

    Alternativ könnte man alle Server, die PowerShell nach dem Logon starten sollen, in eine AD-Gruppe aufnehmen und dann ihre Mitgliedschaft im GPO abfragen.

    WMI-Filter für normales GPO

    Schwierig wird es jedoch, wenn man die Einstellung unter den administrativen Vorlagen vornimmt und für das GPO dann einen WMI-Filter finden möchte, der nur auf Server Core zutrifft.

    Während es dafür bis Server 2012 R2 noch geeignete Abfragen gab, ist die Core-Installation seit Server 2016 der Standard und die GUI ist nur mehr ein optionales Feature.

    Daher kann man zwar relativ leicht verifizieren, ob die Desktop Experience installiert ist, etwa mit dieser Abfrage:

    Get-CimInstance -Query 'SELECT * FROM Win32_OptionalFeature WHERE name = "Server-Gui-Mgmt_onecore"'

    Eine installierte Desktop Experience lässt sich über WMI leicht verifizieren.

    Umgekehrt besitzt die Core-Installation jedoch keine Eigenschaft, die man über WMI ermitteln könnte, aber die in der GUI-Variante nicht existiert. Bedingung für einen WMI-Filter ist aber eine Query, die nur für Server Core das Ergebnis TRUE liefert.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Wolfgang Sommergut

    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Verwandte Beiträge

    Weitere Links