Jump to content

WinRM auf DCs


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

Hallo.. ich habe hierbei folgendes Problem:

 

1) Alle Serversysteme lassen sich zB über Enter-PSSession -ComputerName fqdn -UseSSL erreichen.

 

2) Alle Clientsysteme, die die gleichen Einstellungen besitzen wie o.g. Server (eingehend HTTPS:5986, Zertifikat, winrm quickconfig -transport:https, etc) liefern über

Enter-PSSession -ComputerName fqdn -UseSSL die ErrorID: CreateRemoteRunspaceFailed

Eine reine HTTP-Verbindung über Enter-PSSession -ComputerName fqdn funktioniert.

 

Bisher habe ich keine Erklärung gefunden, was bei den Clients der Unterschied ist. Hat hier jemand ne Idee?

 

 

Link to post

Hallo Martin,

 

ich habe alles nach og Anleitung gemacht und in der CA sieht man die ausgestellten WinRMSSL-Zertifikate von den Servern und Clients. Bis auf den fqdn sind die ja analog.

Unterscheiden sind per default Memberserver und Client was das CA-Chain-Vertrauen angeht? Wie kann ich das prüfen? Ich habe hier Server und Clients nicht unterschiedlich behandelt.

Enter-PSSession : Beim Verbinden mit dem Remoteserver "FQDN" ist folgender Fehler aufgetreten: WinRM kann den Vorgang nicht abschließen. Überprüfen Sie, ob der
angegebene Computername gültig, der Computer über das Netzwerk erreichbar und eine Firewallausnahme für den WinRM-Dienst aktiviert ist und den Zugriff von diesem Computer zulässt.
Standardmäßig wird der Zugriff auf Remotecomputer innerhalb desselben lokalen Subnetzes von der WinRM-Firewallausnahme für öffentliche Profile eingeschränkt. Weitere Informationen
finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ Enter-PSSession -ComputerName FQDN -UseSSL
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (FQDN:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

..das ist die Meldung beim Verbindungsversuch.

 

-FQDN ist erreichbar

-WinRM aktiviert

PS C:\WINDOWS\system32> winrm quickconfig -transport:https
Der WinRM-Dienst wird auf diesem Computer bereits ausgeführt.
WinRM ist bereits für die Remoteverwaltung auf diesem Computer eingerichtet.

-FW-Ausnahme auf tcp/5986 eingehend eingetragen

 

 

 

Link to post

okay....obwohl winrm eingerichtet und eingehend/5986 aktiv ist, scheint es ein Problem zwischen FW und dem HTTPS-Listener zu sein.
manuell funktioniert es ...aber als GPO nach dem howto scheint dies das Problem zu sein..ich bin etwas überfragt

 

-> also die FW-Regel wird sauber eingetragen, aber netstat zeigt keinen Port 5986, obwohl winrm quickconfig durchläuft... das scheint das Problem zu sein!

 

Ideen?

Edited by al3x
Link to post

Es funktioniert bei einem Client, wenn man die Einstellungen bzgl Portfreigabe, winrm etc vornimmt.

Knüpfe ich aber eine GPO lt. Anleitung an die OU, wird die Portfreigabe zwar erstellt und auch winrm ist aktiv, aber der port ist nicht offen - trotz angezeigter Freigabe.

 

Nehme ich den Rechner aus der OU, komplett ohne GPO, und setze eine lokale Portfreigabe, dann muss der HTTPS-Listener neu initialisiert werden...verschiebe ich dann den Rechner wieder in die OU und lösche die lokale Freigabe wieder, dann greift wieder die Freigabe über die GPO und der Port bleibt auch offen. Ich kann das aber nicht für jeden Client einzeln machen :cry3:

Ich habe in der OU 6 "Firewall-GPOs", die jeweils für sich einen oder mehrere sep. Ports freigeben (je nach Anwendung)..dachte schon ob es irgendwie an der Reihenfolge der GPOs liegt, finde aber nix Widersprüchliches.

 

 

bei allen GPOs ist eingestellt:

 

  • Richtlinien / ../ Sicherheitseinstellungen / eingehende Regeln -> jeweilige Ports definiert
  • AdminVorlagen / Windows Defender / Domänenprofil -> WindowsDefender - Alle Netzwerkverbindungen schützen = aktiviert

da die Ports ja immer unterschiedlich sind, dürfte sich ja auch nix überschneiden!?

Link to post

Kann es sein, daß WinRM zu schnell startet? Wenn das versucht den Listener zu erstellen, bevor die FW aus der Boot Protection raus ist, bleibt der Port zu. Kannst mal versuchen, WinRM auf delayed autostart umzustellen.

Wobei das nicht dazu paßt, daß http geht und https nicht - dann wäre ich raus :-(

Link to post

..hab ich probiert, hilft aber nix, wenn wird immer nur ein https-listener auf 443 erstellt.

Ich werde wohl die policy mal komplett neu machen.

Macht es Sinn die rules immer  von autarken Clients zu exportieren und dann in eine GPO zu importieren oder kann man Regeln auch ohne Bedenken direkt auf einem Server in einer GPO festlegen?

Link to post
vor 35 Minuten schrieb al3x:

Macht es Sinn die rules immer  von autarken Clients zu exportieren und dann in eine GPO zu importieren

Meiner Meinung nach ja, auch wenn wir es selbst nicht immer so handhaben. Den Grund für das „Warum“ hast du gerade selbst erlebt. Das Gleiche habe ich schon mit dem einer RDP-Rule erlebt. Deshalb versuchen wir die Builds immer für alle gleich zu ziehen. 

 

 

Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...