WinRM - Windows Remote Management

WinRM 2 und PowerShell 2 gehören zusammen und sind bei Windows 7 und Windows 2008 R2 Server per Default eingebaut. für Windows XP SP2, 2003 SP2, 2008 und Vista SP1 ist dies ein separater Download.

Beachten Sie dazu auch die eigene Seite zu Exchange Remote PowerShell PSRemote.

968929 Windows Management-Frameworks (Windows PowerShell 2.0, WinRM 2.0 und BITS 4.0)

EMTshooter http://blogs.technet.com/b/exchange/archive/2010/12/07/457139.aspx
Troubleshooting the Exchange Management Shell  http://technet.microsoft.com/en-us/library/dd351136.aspx
Troubleshooting Exchange 2010 Management Tools startup issues http://blogs.technet.com/b/exchange/archive/2010/02/04/453946.aspx

eBook Update: Layman’s guide to PowerShell 2.0 remoting
http://www.ravichaganti.com/blog/?p=1780

WinRM ist eine Grundfunktion, die in Windows 2008 erstmals mit gekommen ist ein Management von Windows Servern mit entsprechenden Webservices erlaubt. WinRM macht also das, was auch per WMI und RPC aus der Ferne möglich ist mit dem unterschied, dass es keine proprietären RPC-Aufrufe über TCP sind, sondern über HTTP Port 80 oder 443 abgewickelt werden. Man kann zusätzliche Listener konfigurieren, die dann per Default auf den Ports 5985 HTTPS 5986 Verbindungen annehmen. für die Verwaltung "über das Internet" reicht also genau ein Port und selbst über Proxy-Server ist eine Verbindung meist möglich. Wenn Sie Exchange 2010, die Ansätze zu Cloud" und RBAC schon gesehen haben, dann wissen sie, warum diese Schnittstelle wichtig ist. Die Koexistenz mit anderen Anwendungen (z.B. IIS) , die auf Port 80 oder 443 laufen, ist über entsprechende "Helper" sichergestellt.

WinRM über Windows Update

Ende November 2009 hat sich ein Windows Update auf meinen Servern gemeldet, was man wohl eher als Softwareverteilung bezeichnen kann. Aus leisen Pfoten schleicht sich da einfach mal die PowerShell 2.0 und WinRM 2.0 auf einen Windows 2003 Server.

Hier der Link zum KB-Artikel:

  • 968930 Description of Windows Management Framework Core

Da wird es Zeit sich auf dieser Seite mit dem Thema WinRM zu beschäftigen:

WinRM Fehler

Zugegeben, meinen ersten Kontakt mit WinRM hatte ich durch die Installation von Exchange 2010 und dem ersten Start der MMC nach dem Reboot des Servers. Statt der erwarteten KonfigurationsMöglichkeiten begrüßte mich folgende Fehlermeldung:

Und auch der Wechsel zur PowerShell macht es nicht leichter:

Um es kurz zu machen: Wenn man das Kennwort des lokalen Administrator und des Domänenadministrators gleich wählt, dann bemerkt man bei einer Anmeldung auf einem Member Server nicht immer, wenn man sich "lokal" anmeldet. Aber die Fehlermeldung ist doch aufschlussreich, weil Sie die verschiedenen Fehlerquellen aufzählt, nur leider nicht meine. Es hat mir aber bei der Fehlersuche geholfen, das System besser zu verstehen. Aber es gibt noch weitere Fehler, von denen einige schon so trivial sind, dass man gar auf den ersten Blick drauf kommt aber . Hier eine Liste:

  • Lokaler Admin
    Wie sie bereits gelesen haben, fällt es nicht sofort auf, wenn der lokale Admin das gleiche Kennwort wie der Domänenadministrator hat. Prüfen Sie wirklich, ob sie den richtigen Benutzer gestartet haben.
  • UserAccountControl
    Selbst wenn Sie richtig angemeldet sind, kann ihnen Windows immer noch mit uAC einen Strich durch die Rechnung machen. Auch die PowerShell kann man "Als Administrator ausführen..."
  • Proxy
    Die Kommunikation zwischen lokaler PowerShell und dem entfernten Server erfolgt per HTTP(S). Hier kann eine falsche Proxy-Konfiguration natürlich auch schon störend sein. Wenn der Client selbst die Anfragen nicht "lokal" zuweist oder der Proxy den Weg nach innen nicht kennt und vielleicht das verwendete Authentifizierungsverfahren nicht unterstützt, wird der Client den Server nicht finden. Die aktuellen Einstellungen können Sie mit NETSH anzeigen lassen.
netsh winhttp show proxy
  • Zeitzone/Zeit
    Normalerweise holt sich ein Member Server die uhrzeit von den DCs. Das macht er aber nur, wenn der neu installierte Server nicht allzu weit von der aktuellen Zeit weg ist. NTP korrigiert Sekunden, Minuten und Stunden aber keine falschen Tage. Wenn die uhren nicht übereinstimmen, dann sehen Sie das an der Fehlermeldung. Ich habe mindestens einmal die uhr korrigiert und übersehen, dass auch der tag falsch war.
  • Zertifikat
    Zertifikate können ablaufen oder (wenn das Datum bei der Anforderung in der Zukunft lag) noch gar nicht gültig sein. Prüfen Sie daher einfach mal das installierte Zertifikat, die Bindung und natürlich ob der Client auch dem Zertifikat vertraut
  • Firewall/Virenscanner
    Es wäre nicht das erste Mal, dass eine Firewall die Verbindung unterbindet.
  • kein Remoting
    Per Default erlaubt WinRM nur ein Zugriff von "Localhost". Prüfen Sie also, ob sie beim Zugriff aus der Ferne auch diese Option entsprechend aktiviert haben, z.B. mit:
Enable-PSRemoting
  • Invalid Content-Type-Fehler
    Einmal hat WinRM auch eine Exchange 2010 Installation gestört, weil es als HTTP-Filter irgendwelche andere Funktionen gestört hat. Welcher Fehler es genau war, konnte nicht ermittelt werden. Eine Deinstallation von WinRM und Neuinstallation hat dieses Problem dann gelöst.

Vielleicht möchten Sie aber auch etwas genauer wissen, was WinRM mit ihrem Server anstellt. Dann lesen Sie einfach etwas weiter

WinRM konfigurieren

Wie jeder Administrator gilt in dem Fall mein erster Blick dem Eventlog und bei mir habe ich folgenden Eintrage gefunden:

Log Name: System
Source: Microsoft-Windows-WinRM
Event ID: 10149
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Description:
The WinRM service is not listening für WS-Management requests.

User Action
If you did not intentionally stop the service, use the following command to see the WinRM configuration:

winrm enumerate winrm/config/listener

Der Eintrag belegt aber zumindest, dass der Dienst dazu vorhanden und gestartet ist:

Nun ist es ja nicht so, dass Exchange und andere Verwaltungstools zwingend über WinRM mit dem Server sprechen müssten, aber ich würde schon gerne den Server dann auch über das LAN verwalten wollen. für die Konfiguration von WinRM habe ich aber noch keine GUI gefunden. Eine nackte Kommandozeile ist erforderlich. Über folgende Befehle kann ich mir die Konfiguration insgesamt oder auch nur die Listener anzeigen lassen

winrm get winrm/config
winrm enum winrm/config/Listener

Ok die Konfiguration sieht erst mal nicht spektakulär aus aber bei den Listener war bei mir kein Eintrag. Demnach dürfte mein Server kein Anfragen über die HTTP/HTTPS-Schnittstellen angenommen haben. Nach kurzen Stöbern im Internet und MSDN waren die beiden Befehlszeilen für das Anlegen der Listener schnell ermittelt.

C:\>winrm create winrm/config/listener?Address=*+Transport=HTTP
ResourceCreated
    Address = http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
    ReferenceParameters
        ResourceURI = http://schemas.microsoft.com/wbem/wsman/1/config/listener
        SelectorSet
            Selector: Address = *, Transport = HTTP

C:\>winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="HOST";CertificateThumbprint="XXXXXXXXXX"}
ResourceCreated
    Address = http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
    ReferenceParameters
        ResourceURI = http://schemas.microsoft.com/wbem/wsman/1/config/listener
        SelectorSet
            Selector: Address = *, Transport = HTTPS

Für die Konfiguration eines HTTPS-Listeners ist natürlich das Zertifikat im Computerspeicher und die Angabe des "Thumprint erforderlich". Beachten Sie dabei, dass der Hostname auch im Zertifikat vorhanden sein muss. Zwar liefert der Befehl selbst schon eine Fehlermeldung, wenn etwas nicht passt, aber eine Kontrolle schadet nie:

C:\>winrm enum winrm/config/Listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.100.8, ::1, fe80::e0:0:0:0%13, fe80::88e0:5
f25:ec62:97c8%11

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = NAWEX001
    Enabled = true URLPrefix = wsman
    CertificateThumbprint = ab9445a0362a67393f60531e591479313e555e65
    ListeningOn = 127.0.0.1, 192.168.100.8, ::1, fe80::e0:0:0:0%13, fe80::88e0:5
f25:ec62:97c8%11

Sie sehen so auch die IP-Adressen auf die sich WinRM registriert hat und dass auch IPV6 möglich ist. Wer nun gedacht hat, er könne sich schon über das LAN auf den Server verbinden, der irrt, zumindest wenn es sich um Windows 2008 handelt. Die Windows Firewall verhindert dies zuverlässig, so dass Verbindungen nur von "Localhost" möglich sind.

Aber auch hier können Sie per Kommandozeile diese Löcher bohren lassen:

C:\>winrm quickconfig
WinRM already is set up to receive requests on this machine.
WinRM is not set up to allow remote access to this machine für management.
The following changes must be made:

Enable the WinRM firewall exception.

Make these changes [y/n]? y

WinRM has been Updated für remote management.

WinRM firewall exception enabled.

C:\Users\Administrator>winrm quickconfig
WinRM already is set up to receive requests on this machine.
WinRM already is set up für remote management on this machine.

Damit sollte in den meisten Fällen bezogen auf den Server die Konfiguration durchgeführt worden sein.

WinRM, Basic Auth und Office 365

Manchmal sehen Sie folgenden Fehler, z.B. bei Nutzung der Teams Online PowerShell:

Set-CsOnlinePstnUsage: Connecting to remote server api.interfaces.records.teams.microsoft.com failed 
with the following error message : The WinRM client cannot process the request. 
Basic authentication is currently disabled in the client configuration. 
Change the client configuration and try the request again. 
For more information, see the about_Remote_Troubleshooting Help topic.

Hier versucht die PowerShell per "BasicAuth" eine Anmeldung durchzuführen, was bei WinRM in der Standardeinstellung nicht aktiv ist. Dies können Sie über die Registrierung aktivieren

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client]
"AllowBasic"=dword:00000001

Die Einstellung können Sie auch per Gruppenrichtlinie auf mehrere Systeme verteilen.

Beachten Sie, dass es die Einstellung auf dem Client als auch auf dem Server gibt. Schauen Sie sich genau die Fehlermeldung an, an welcher Stelle es "knirscht". Oft ist es der "Server", weil ihr Client kein NTLM oder Kerberos machen kann. Es gibt aber auch Situationen, in denen ein lokalen Modul die lokale WinRM-Instanz als "Proxy" zum Zugriff auf andere Dienste nutzt. Dann kann die Einstellung lokal fehlen.

Testen und Nutzen mit WinRS

Passend zum Programm WinRM zur Verwaltung gibt es mit WinRS (remote Shell) eine Möglichkeit, beliebige Befehle auf dem entfernten System ausführen zu lassen. Das Programm ist sogar auf einem Windows 7 per Default mit enthalten. Damit lässt sich per WinRM einfach so ein "Remote Command" auf dem anderen Server ausführen. Hier mal ein Beispiel, dass ich einfach ein "DIR" auf einem Server ausgeführt habe. Da ich als "User" auf meinem Windows 7 Notebook natürlich keine Berechtigungen hatte, habe ich explizit Benutzername und Kennwort angegeben.

Übrigends werden diese Vorgänge sehr genau im Windows Eventlog protokolliert. Alle Events sind in Windows 2008 in einer eigenen Ansicht zu finden.

Alternativ ist eine Filterung auf die Quelle "Microsoft-Windows-WinRM" möglich. Hier die Logs des obigen Beispielt mit dem "DIR" per remote Command. (Von unten nach oben lesen, d.h. älteste Meldung ist unten, wie beim Eventlog üblich)

Level EventID Task Category Beschreibung

Information

132

Response handling

WSMan operation CreateShell completed successfully

Information

83

Request handling

Leaving the Plugin für operation Shell

Information

143

Response handling

Received the response from Network layer; status: 200 (HTTP_STATUS_OK)

Information

134

Response handling

Sending response für operation CreateShell

Information

82

Request handling

Entering the Plugin für operation Shell with a ResourceURI of <http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd>

Information

81

Request handling

Processing client request für operation CreateShell

Information

193

User authorization

The authorization of the User was done successfully

Information

192

User authorization

Authorizing the User

Information

169

User authentication

User NAWEX001\Administrator authenticated successfully using NTLM authentication

Error

129

Response handling

Received the response from Network layer; status: 401 (HTTP_STATUS_DENIED)

Information

166

User authentication

The chosen authentication mechanism is Negotiate

Information

80

Request handling

Sending the request für operation CreateShell to destination machine and port localhost:47001

Information

166

User authentication

The chosen authentication mechanism is Negotiate

Information

11

WSMan API call

Creating WSMan shell with the ResourceUri: http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd

Information

31

WSMan Session initialize

WSMan Create Session operation completed successfuly

Information

6

WSMan Session initialize

Creating WSMan Session. The connection string is: localhost:47001/wsman

Information

29

WSMan API Initialize

Initialization of WSMan API completed successfuly

Information

2

WSMan API Initialize

Initializing WSMan API

Damit wird es nun auch einfacher nachvollziehbar, wer wann WinRM genutzt hat, aber leider nicht genau den Befehl. Wünschenswert ist aber schon, dass mehr Produkte WinRM nutzen und der direkte Zugriff per LDAP, RemoteRegistry, RPC und WMI auf verschiedene Funktionen unterbleibt. Exchange 2010 spielt hier mit RBAC wieder den Vorreitergehen, damit die Administrator keine direkten Berechtigungen mehr auf die Konfigurationsspeicher benötigen, sondern nur den Befehl per WinRM an die Services übermittelt, die dann nach Prüfung und administrativen Rollen die Anforderung mit ihren eigenen Berechtigungen umsetzen.

WinHTTP-Proxy und WinRM und SSL

Eine möglicher Kommunikationsweg zwischen Client und WinRM-Service ist HTTP bzw. HTTPS. Entsprechend kann es sein, dass der Client versucht über einen Proxy mit dem WinRM-Service zu kommunizieren.

Beim Weg über einen Proxy unterstützt WinRM z.B. kein HTTP sondern nur HTTPS und auch die Anmeldung per NTLM oder Basic unterliegt gewissen Einschränkungen bei der Nutzung über Proxies oder direkt.

Das sehen sie auch in einer Fehlermeldung beim Start der Exchange PowerShell oder GUI, die eben darauf hinweist, dass die Zugriff über einen Proxy gehen und WinRM dann SSL erfordert. Das funktioniert eben nicht, wenn der WinRM-Server nicht per SSL erreichbar ist. Wenn der Proxy nicht auflösbar ist, dann kann die Fehlermeldung sogar irreführend sein:

Hier wird der Exchange Server nicht gefunden, sondern der Proxy Server. Bei solchen Fehlern sollten sie also direkt einmal die Proxy-Konfiguration überprüfen. Relevant ist die Proxy Konfiguration des "Computers" und nicht die des angemeldeten Benutzer. Daher müssen Sie mit NetSH die Konfiguration anzeigen und gegebenenfalls ändern.

Hier die relevanten Befehle:

# Eintragen des Proxy und Ausnahmen
netsh winhttp set proxy proxy.msxfaq.net:8080 bypass-list="*.msxfaq.net"

# Import der Einstellungen aus dem aktuellen IE nach LocalSystem
netsh winhttp import proxy source=ie

# Anzeige der aktuellen Einstellungen
netsh winhttp show proxy

# Entfernen des Proxy
netsh winhttp reset proxy

Wenn die Konfiguration nicht vorgegeben wird, dann kommt die "Automatische Konfiguration" zum Tragen

Weitere Links