5 Troubleshooting

siehe auch: Technet: about_Remote_Troubleshooting

Vor einer Überprüfung der Verbindung kann man versuchen eine Remoteverbindung (siehe 3.1.6 eine Remotesession mit "new-pssession <Clientname> -usessl" erstellen) herzustellen. Wenn dies funktioniert, kann man sich dieses Kapitel natürlich sparen.

Kommt keine Remoteverbindung zustande, so kann dies mehrere Ursachen haben

5.1 Problem mit dem WinRM-Dienst

5.2 Problem mit der Firewall

5.3 Problem mit dem SSL-Zertifikat

5.4 Problem mit der Sessionkonfiguration

5.5 Prüfen des WS-Man

5.6 Module PsDiagnostics

5.1 Problem mit dem WinRM-Dienst

Um die Konfiguration am remoteRechner zu überprüfen, gibt es eine ganze Reihe von Möglichkeiten.


Beispiel 1: Schnelltest am RemoteRechner, ob Remoting enabled ist.

Enter-PSSession -ComputerName localhost

#Ausgabe

PS C:\Powershell\MyScripts> enter-pssession -computername localhost
[localhost]: PS C:\Users\blub.DOM1\Documents>

Wenn Remoting aktiviert ist und funktioniert, sollte etwa diese Ausgabe erscheinen.

Beispiel 2: Fehlermeldung am lokalen Rechner, wenn der WinRM-Port nicht offen oder kein passender Listener konfiguriert ist

New-PsSession dom1win7.dom1.intern -usessl

#Ausgabe

[dom1win7.dom1.intern] Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann den
Vorgang innerhalb der angegebenen Zeit nicht abschließen. Überprüfen Sie, ob der Computername gültig, der Computer über
 das Netzwerk erreichbar und eine Firewallausnahme für den Windows-Remoteverwaltungsdienst aktiviert ist. Weitere Infor
mationen finden Sie im Hilfethema "about_Remote_Troubleshooting".


Beispiel 3: Anzeige der WinRM-Konfiguration
Ausführen mit Administratorrechten

winrm get winrm/config  
#oder
Winrm get schemas.microsoft.com/wbem/wsman/1/config
#Ausgabe
Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts = *
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint = 46 17 1c 53 ea a7 b7 a7  f6 de d7 e2 bc e9 fd 2f85 2c 4c 12
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5

 

Beispiel 4: Abfrage der Listenerkonfiguration
Diese Prüfung finde ich persönlich am übersichtlichsten. In den Zeilen, die mit "Listener" beginnen, kann man erkennen, ob die Konfiguration über GPO oder über lokale cmdlets (dann gibt es keine weiteren Angaben) durchgeführt wurde.

winrm enumerate winrm/config/listener
Listener [Source="GPO"]
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 4.11.129.127, 127.0.0.1, ::1, 2002:2c6:817f::2c6:817f, fe80::200:5efe:4.11.129.127%12

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 4.11.129.127, 127.0.0.1, ::1, 2002:2c6:817f::2c6:817f, fe80::200:5efe:4.11.129.127%12

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTPS
    Port = 443
    Hostname = Dom1Win7.Dom1.intern
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = 46 17 1c 53 ea a7 b7 a7  f6 de d7 e2 bc e9 fd 2f85 2c 4c 12
    ListeningOn = 4.11.129.127, 127.0.0.1, ::1, 2002:2c6:817f::2c6:817f, fe80::200:5efe:4.11.129.127%12

Wenn der Listener lokal mit "enable-psremoting" oder "set-wsmanquickconfig" konfiguriert ist, kann man sich diese Einstellungen auch in der lokalen Registry betrachten. (siehe Kapitel 1.2.1)

5.2 Problem mit der Firewall

Zur Kontrolle der physikalischen Netzverbindung benütze ich den kostenlosen Portscanner von Microsoft, erhältlich im Micorosoft Download Center: PortqueryV2

Nach dem Entpacken kann man dieses Tool ohne Installation in der Commandline (nicht in Powershell!) aufrufen und mit

portqry -n dom1win7.dom1.intern -e 5985
portqry -n dom1win7.dom1.intern -e 5986
#Ausgabe

....
TCP port 5985 (unknown service): LISTENING

...
TCP port 5986 (unknown service): NOT LISTENING

prüfen, ob die Verbindung offen ist. Wenn die Listener am Zielsystem konfiguriert sind, müssen die Portquery-Befehle ein "Listening" zurückliefern.

Liefern die Befehle "Filtered" zurück, ist die Verbindung auf diesen Ports blockiert. Wenn sich zwischen lokalem und RemoteRechner keine weitere Firewall befindet, hilft es wahrscheinlich, die Windowsfirewall beispielsweise über die Grouppolicy "Windows Firewall mit erweiterter Sicherheit" mit einer eigenen Regel für die Ports 5985 und 5986 zu öffnen.

Anstelle des MS-Tools portqry.exe kann man auch das Tool SimpleTCPCheck.exe verwenden, das ich in VB geschrieben habe. Downloaden inklusive Quellcode kann man es im  hier im MCSEBoard. Der Vorteil liegt in der einfachen Bedienbarkeit, der kurzen Ausgabe und der Möglichkeit mehrere Ports auf einmal zu prüfen.

SimpleTCPCheck 192.168.178.100 5985 5986
#Ausgabe
110

die erste 1 oder 0 bedeutet, ob der Client per ICMP (Ping) erreichbar ist, die übrigen 0-er und 1-er zeigen an, ob die Ports erreichbar sind.
 

5.3 Problem mit dem SSL-Zertifikat

Ein Zertifikatsproblem kann zum Beispiel vorliegen, wenn

  • keine Sperrlisteninformationen abgefragt werden können (häufigste Ursache)
  • das Zertifikate gesperrt wurde
  • das Zertifikat abgelaufen oder ungültig ist
  • Probleme mit der Zertifikatskette vorliegen

Diese Faktoren lassen sich am besten über das CommandlineTool certutil überprüfen.

Weiter kann es auch sein, daß das Zertifikat nicht die notwendigen Eigenschaften enthält, um für eine SSL-Verbindung genutzt werden zu können.

Der erste Schritt ist das von "Set-WsManQuickConfig -usessl" verwendete Zertifikat zu identifizieren. Dazu dient der eindeutige Fingerabdruck "Thumbprint" eines jeden Zertifikakts.
Mit den Befehlen aus Kapitel 5.1 weiter oben, oder bei lokaler Konfiguration auch direkt aus der Registry Kapitel 1.2.1 [Beispiel 3], kann der verwendete Fingerabdruck bestimmt werden.

Der zweite Schritt besteht darin, die auf dem Rechner vorhandenen Zertifikate zu öffnen und dasjenige Zertifikat mit dem passenden Fingerabdruck zu identifizieren. In den Kapiteln 3.2.3 Zertifikat beantragen und 3.2.4 Untersuchen des Zertifikats habe ich dies beschrieben.

Hat man das richtige Zertifikat gefunden, so muss als Letztes das Zertifikat mittels rechter Maustaste -> "alle Aufgaben" -> "Exportieren" in eine Datei ssl.cer gespeichert werden (ohne private Schlüssel, im Base64 Format).


Auf Kommandline(!) erfolgt die Prüfung jetzt durch

certutil -verify c:\temp\ssl.cer
#Ausgabe gekürzt

Aussteller:
    CN=Dom1-CA01
    DC=Dom1
    DC=intern
Antragsteller:
    CN=Dom1Win7.Dom1.intern
Zertifikatseriennummer: 19dae87d000000000035

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 1 Days, 58 Minutes, 17 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 1 Days, 58 Minutes, 17 Seconds
.....

Exclude leaf cert:
  8f 7a 51 25 c8 b6 74 f9 b6 1a 07 f2 41 08 2b 02 36 15 89 66
Full chain:
  a4 28 4a 2d 5f 24 d7 87 a5 21 e3 16 0d 11 e5 0b 07 a0 ff cf
------------------------------------
Verfizierte Ausstellungsrichtlinien: Kein
Verfizierte Anwendungsrichtlinien:
    1.3.6.1.5.5.7.3.1 Serverauthentifizierung
    1.3.6.1.5.5.7.3.2 Clientauthentifizierung
Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlossen.
CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

das Ergebnis sollte etwa so aussehen und keine Fehler enthalten.


Treten Fehler auf, die man auf die Schnelle nicht beheben kann, so lassen sich Prüfungen wie der CRL-Check oder die Rootzertifikatsprüfung über Optionen des cmdlets New_WSManSessionOption unterdrücken: siehe Technet: New-WSManSessionOption
 

5.4 Problem mit der Sessionkonfiguration (Zugriff verweigert)

Erscheint beim Erstellen einer Remoteverbindung diese Fehlermeldung in der Ausgabe

New-PsSession dom1win7.dom1.intern
#Ausgabe
[dom1win7.dom1.intern] Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Zugriff verweigert

so fehlen Berechtigungen auf einer Sessionkonfiguration. Diese können beispielsweise mit "Enable-PsRemoting" gesetzt werden. Die Ursache war eventuell ein "Disable-PsRemoting".
Manchmal benötigt der betroffene Rechner bei '"Zugriff verweigert" auch einen Reboot, insbesondere wenn "Enable-PsRemoting" selbst die Fehlermeldung bringt.

 

5.5. Prüfen des WS-Man

Beispiel 1: cmdlet Test-WsMan

Test-WsMan
#Ausgabe

wsmid           : schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 2.0

Die Eigenschaft ProductVersion sieht auf den ersten Blick fehlerhaft aus, scheint aber so zu stimmen.

Ich hatte bisher mit dem WsMan noch keine Probleme.
 

5.6 Module PsDiagnostics

Beispiel 1: Functionen des Moduls psdiagnostics anzeigen

Import-Module psdiagnostics
Get-Command -module PsDiagnostics -verb *
#Ausgabe

CommandType     Name
-----------     ----
Function        Disable-PSTrace
Function        Disable-PSWSManCombinedTrace
Function        Disable-WSManTrace
Function        Enable-PSTrace    
Function        Enable-PSWSManCombinedTrace
Function        Enable-WSManTrace
Function        Get-LogProperties
Function        Set-LogProperties
Function        Start-Trace
Function        Stop-Trace

Es wird beispielsweise unter %windir%\system32\wsmtraces.log nach "Enable-WSManTrace" ein Log geschrieben. Leider war dieses Log für mich nicht lesbar.
Wenn jemand eine Quelle zur Auswertung der Logs kennt, würde mich das sehr interessieren.