PowerShell Remoting einrichten und absichern
Was Enable-PSRemoting tatsächlich anschaltet, wann sich eine dauerhafte Sitzung lohnt und wie du mit JEA eingrenzt, wer sich verbinden darf.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Es funktioniert, aber niemand weiß genau, was dabei offen steht
Der erste Kontakt mit Remoting sieht meist so aus: Ein Befehl soll auf zwanzig Servern laufen, jemand ruft Enable-PSRemoting mit dem Schalter -Force auf, und danach funktioniert es. Was dabei genau eingerichtet wurde, bleibt unklar, und die Frage stellt sich erst, wenn die Sicherheitsprüfung wissen will, welche Dienste laufen und welche Ports offen sind. Dann ist die Antwort meist ungefähr, und ungefähre Antworten führen an dieser Stelle zu pauschalen Verboten.
Auf Windows Server ist die Ausgangslage dabei komfortabler als vielen bewusst ist: Remoting ist dort standardmäßig aktiviert. Enable-PSRemoting braucht ihr also nur, um es auf anderen unterstützten Windows-Versionen einzuschalten oder um es wieder anzuschalten, nachdem es abgeschaltet wurde. Wer den Befehl trotzdem flächendeckend über alle Server jagt, ändert unter Umständen mehr als beabsichtigt, denn er hebt unter anderem die Einträge auf, mit denen einzelne Sitzungskonfigurationen ausdrücklich auf lokale Nutzung beschränkt waren.
Die dritte Schwierigkeit betrifft die Rechte. Remoting ist standardmäßig ein Werkzeug für Administratoren, und genau deshalb landet man schnell in einer unbequemen Lage: Jemand aus dem Anwendungsbetrieb soll auf zehn Servern zwei Befehle absetzen dürfen und bekommt dafür lokale Administratorrechte, weil das der schnellste Weg ist. Für dieses Problem gibt es seit Jahren eine vorgesehene Antwort, die nur selten genutzt wird, und sie heißt Just Enough Administration.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ein Aufruf, der die vier wichtigen Entscheidungen sichtbar macht
Die folgende Abfolge schaltet Remoting ein, öffnet eine dauerhafte Sitzung zu zwei Servern auf einem bestimmten Endpunkt, führt darin einen Befehl aus und räumt anschließend auf. Jeder Bestandteil steht für eine Entscheidung, die sonst stillschweigend getroffen wird.
Der Aufbau
Enable-PSRemoting -Force; $s = New-PSSession -ComputerName srv01,srv02 -ConfigurationName Betrieb -Credential $cred; Invoke-Command -Session $s -ScriptBlock { Get-Service W32Time }; Remove-PSSession $s - 01 Auf Windows Server meist überflüssig, und nicht harmlos
Enable-PSRemoting -ForceDer Aufruf startet Set-WSManQuickConfig, das den WinRM-Dienst startet, seinen Starttyp auf automatisch setzt, einen Listener für beliebige IP-Adressen anlegt und eine Firewall-Ausnahme für WS-Management einrichtet. Danach werden die Endpunkte angelegt, alle Sitzungskonfigurationen aktiviert, deren Sicherheitsbeschreibung für den Fernzugriff angepasst und der Dienst neu gestartet. Der letzte Teil ist der heikle: Dabei werden auch die Einträge entfernt, mit denen einzelne Endpunkte auf lokale Nutzung beschränkt waren. Auf Windows Server ist Remoting ohnehin standardmäßig aktiviert.
- 02 Der Unterschied zwischen einem Befehl und einem Ablauf
New-PSSessionEine mit New-PSSession erzeugte Sitzung bleibt bestehen, bis du sie schließt. Alles, was du darin ablegst, steht beim nächsten Aufruf wieder zur Verfügung, und genau das ist der Grund, sie zu benutzen: Du kannst Daten in einem Schritt sammeln und im nächsten weiterverarbeiten, ohne sie zwischen den Rechnern hin und her zu schicken. Für einen einzelnen Befehl ist Invoke-Command mit -ComputerName die einfachere Wahl, weil es die Verbindung selbst aufbaut und wieder abräumt.
- 03 Mehrere Ziele in einem Aufruf
-ComputerName srv01,srv02Der Parameter nimmt eine Liste, und PowerShell arbeitet die Ziele parallel ab. Für die Namensauflösung gilt dasselbe wie überall: Was hier steht, muss auflösbar sein, und für Kerberos muss es der Name sein, unter dem der Dienstprinzipal registriert ist. Verbindest du dich über eine IP-Adresse, fällt die Authentifizierung auf einen anderen Weg zurück und verlangt zusätzliche Konfiguration.
- 04 Der Endpunkt entscheidet über Befehle und Rechte
-ConfigurationName BetriebEine Sitzungskonfiguration ist der benannte Endpunkt, auf dem eine Sitzung landet. Ohne Angabe wird der voreingestellte Endpunkt für Administratoren benutzt. Ein eigener Endpunkt ist der Ort, an dem JEA greift, an dem festgelegt wird, welche Konten sich verbinden dürfen, und an dem PowerShell 7 seine eigenen Endpunkte anlegt. Diese heißen dort schlicht nach der Version, etwa PowerShell.7, und ohne diese Angabe landest du auf Windows PowerShell.
- 05 Die Frage, mit welchem Konto gearbeitet wird
-Credential $credOhne den Parameter wird das Konto der laufenden Sitzung benutzt. Mit ihm arbeitest du unter einem anderen Konto, was für getrennte Verwaltungskonten der übliche Weg ist. Für Domänenkonten wird über Negotiate Kerberos gewählt, für lokale Konten NTLM. In einer Arbeitsgruppe ist Kerberos nicht verfügbar, und dann kommt die Liste der vertrauenswürdigen Hosts oder ein Listener über HTTPS ins Spiel.
- 06 Der Aufruf in einer bestehenden Sitzung
Invoke-Command -Session $sMit -Session läuft der Block in der bereits geöffneten Sitzung statt in einer neu aufgebauten. Was zurückkommt, sind keine lebenden Objekte, sondern deserialisierte Abbilder: Ihre Eigenschaften sind vorhanden, ihre Methoden in der Regel nicht. Das ist der häufigste Stolperstein bei Skripten, die lokal funktionieren und über Remoting scheitern. Die Konsequenz daraus ist eine gute Faustregel: Verarbeite auf der Gegenseite und hol nur das Ergebnis zurück.
- 07 Aufräumen ist keine Kür
Remove-PSSession $sOffene Sitzungen laufen erst nach einer Leerlaufzeit von Haus aus 180 Sekunden ab, und in der Zwischenzeit belegen sie das Kontingent. Voreingestellt sind fünf gleichzeitige Remoteshells je Nutzer und 150 Megabyte Arbeitsspeicher je Shell. Ein Skript, das Sitzungen anlegt und liegen lässt, läuft deshalb nach wenigen Durchläufen in Fehler, deren Meldung auf ein Ressourcenproblem zeigt und nicht auf die eigentliche Ursache.
Wenn es nicht funktioniert
Das siehst du
Die Verbindung zu einem Rechner außerhalb der Domäne scheitert mit einer Meldung des WinRM-Clients, dass die Anforderung nicht verarbeitet werden konnte, und dem Hinweis auf die vertrauenswürdigen Hosts.
Warum
WinRM verlangt eine gegenseitige Authentifizierung. Die liefert Kerberos, und Kerberos gibt es nur in einer Domäne, nicht in einer Arbeitsgruppe. Fehlt sie, verweigert der Client die Verbindung, solange das Ziel nicht in der Liste der vertrauenswürdigen Hosts steht. Diese Liste ist ausdrücklich keine Authentifizierung: Microsoft weist darauf hin, dass die dort eingetragenen Rechner nicht authentifiziert werden und der Client ihnen Anmeldeinformationen schicken kann.
Was hilft
Das siehst du
Der Befehl läuft auf dem ersten Server, aber der Zugriff von dort auf eine Dateifreigabe oder einen zweiten Server scheitert mit einem Zugriffsfehler, obwohl das Konto dort berechtigt ist.
Warum
Das ist das Problem des zweiten Sprungs. Die Anmeldeinformationen, mit denen du dich am ersten Server angemeldet hast, werden von dort aus nicht weitergereicht, und für den nächsten Schritt steht deshalb keine gültige Identität zur Verfügung. Das ist kein Fehler, sondern gewollt, denn eine automatische Weitergabe würde bedeuten, dass jeder Server, auf dem du dich anmeldest, in deinem Namen weiterarbeiten kann.
Was hilft
Das siehst du
Enable-PSRemoting läuft in PowerShell 7 sauber durch, meldet aber, dass nur die Konfigurationen für PowerShell Core betroffen sind, und eine Verbindung landet danach trotzdem auf Windows PowerShell.
Warum
Mehrere PowerShell-Installationen können nebeneinander bestehen, und Enable-PSRemoting richtet immer einen Endpunkt für genau die Version ein, in der es ausgeführt wird. In PowerShell 7 entstehen dabei zwei Endpunkte, einer mit dem einfachen Namen nach der Hauptversion und einer mit der vollständigen Versionsangabe. Der voreingestellte Endpunkt einer Verbindung bleibt davon unberührt, und das ist weiterhin der von Windows PowerShell.
Was hilft
Das siehst du
Auf einem Arbeitsplatzrechner lässt sich Remoting nicht einschalten oder es funktioniert danach nur aus dem eigenen Netzsegment.
Warum
Auf Client-Versionen von Windows ist das Einschalten von Remoting normalerweise nicht erlaubt, wenn der Rechner in einem öffentlichen Netzwerkprofil ist. Der Schalter -SkipNetworkProfileCheck hebt diese Einschränkung auf, erzeugt dabei aber nur eine Firewall-Regel, die den Zugriff aus dem lokalen Subnetz zulässt. Auf Serverversionen greift dieser Schalter gar nicht, denn dort besteht die Regel für das lokale Subnetz ohnehin.
Was hilft
Das siehst du
Ein Skript, das lokal einwandfrei arbeitet, scheitert über Remoting an einer Methode, die es angeblich nicht gibt, oder liefert unvollständige Objekte zurück.
Warum
Was aus einer Remotesitzung zurückkommt, sind keine lebenden Objekte, sondern deserialisierte Abbilder. Die Eigenschaften sind vorhanden, die Methoden in der Regel nicht, weil der ursprüngliche Typ auf dem lokalen Rechner nicht rekonstruiert wird. Ein Aufruf wie das Anhalten eines Dienstes am zurückgegebenen Objekt scheitert deshalb, obwohl derselbe Code lokal funktioniert.
Was hilft
Das siehst du
Jemand aus dem Anwendungsbetrieb soll auf mehreren Servern zwei Befehle ausführen dürfen und bekommt dafür lokale Administratorrechte, weil sich sonst kein Weg findet.
Warum
Der voreingestellte Endpunkt für Remoting ist für Administratoren gedacht, und jede Berechtigung darauf ist eine sehr weitreichende. Microsoft beschreibt genau diesen Fall als Ausgangspunkt für JEA: Wer für eine eng umrissene Aufgabe hohe Rechte bekommt, öffnet damit einen Weg, über den sich Angriffe seitwärts durch die Umgebung bewegen können.
Was hilft
Fünf Entscheidungen, bevor Remoting flächendeckend genutzt wird
- 01 Ist Remoting schon an? Auf Windows Server lautet die Antwort in der Regel ja.
- 02 Ein Befehl oder mehrere aufeinander aufbauende Schritte? Davon hängt ab, ob du eine Sitzung brauchst.
- 03 Welcher Endpunkt soll benutzt werden, und wer darf sich darauf verbinden?
- 04 Liegt das Ziel in der Domäne? Sonst braucht es HTTPS mit Zertifikat statt vertrauenswürdiger Hosts.
- 05 Soll jemand ohne Administratorrechte arbeiten dürfen? Dann ist JEA der vorgesehene Weg.
Die Entscheidungen, die Remoting im Betrieb tragfähig machen
Sieben Punkte trennen eine Umgebung, in der Remoting kontrolliert genutzt wird, von einer, in der es nur irgendwie funktioniert. Keiner davon ist aufwendig, aber jeder muss einmal bewusst entschieden werden.
Feststellen, was schon an ist, statt pauschal einzuschalten
Prüfe zuerst mit Get-PSSessionConfiguration, welche Endpunkte auf einem Server vorhanden und aktiviert sind, und mit winrm enumerate winrm/config/listener, welche Listener laufen. Erst danach entscheidest du, ob überhaupt etwas geändert werden muss. Auf Windows Server ist die Antwort in der Regel nein, und ein pauschaler Aufruf von Enable-PSRemoting würde bestehende Einschränkungen aufheben.
Einmalige Befehle von dauerhaften Sitzungen trennen
Invoke-Command mit -ComputerName baut die Verbindung auf, führt den Block aus und räumt wieder ab. Für einen einzelnen Befehl auf vielen Servern ist das genau richtig. Sobald aber mehrere Schritte aufeinander aufbauen und Zwischenergebnisse auf der Gegenseite bleiben sollen, brauchst du eine dauerhafte Sitzung über New-PSSession, denn nur dort überlebt eine Variable den nächsten Aufruf.
Die Sitzungskonfiguration bewusst wählen
Der Endpunkt, auf dem eine Sitzung landet, entscheidet über die verfügbaren Befehle und die Rechte. Voreingestellt ist der allgemeine Endpunkt für Administratoren. Wenn auf einem Server PowerShell 7 zusätzlich installiert ist, existieren daneben eigene Endpunkte, die du mit -ConfigurationName ansprechen musst. Ohne die Angabe landest du auf Windows PowerShell, auch wenn du lokal in PowerShell 7 arbeitest.
Verschlüsselung und Authentifizierung nicht aufweichen
Der WinRM-Dienst lehnt unverschlüsselten Verkehr standardmäßig ab, Basic-Authentifizierung ist auf Dienstseite ebenfalls aus, und Kerberos sowie Negotiate sind an. Diese Voreinstellungen sind gut. Wer im Netz auf einen Fehler stößt und daraufhin unverschlüsselten Verkehr erlaubt oder Basic einschaltet, hat den Fehler nicht behoben, sondern zugedeckt.
Für Rechner außerhalb der Domäne einen echten Weg bauen
Kerberos ermöglicht gegenseitige Authentifizierung, funktioniert aber nur in einer Domäne. In einer Arbeitsgruppe bleibt entweder die Liste der vertrauenswürdigen Hosts, und deren Einträge werden ausdrücklich nicht authentifiziert, oder ein Listener über HTTPS mit einem Zertifikat. Für dauerhafte Verbindungen ist der zweite Weg der richtige, auch wenn er etwas Vorlauf kostet.
Eingrenzen statt aufmachen, mit Just Enough Administration
JEA ist die vorgesehene Antwort auf die Frage, wie jemand genau zwei Befehle ausführen darf, ohne Administrator zu sein. Du legst einen eigenen Endpunkt an, gibst darin die erlaubten Cmdlets, Funktionen und externen Befehle an, und die Sitzung arbeitet über ein temporäres, privilegiertes virtuelles Konto oder ein gruppenverwaltetes Dienstkonto. Die verbindende Person meldet sich dabei mit einem gewöhnlichen Konto ohne Administratorrechte an.
Sitzungen wieder schließen
Dauerhafte Sitzungen belegen auf der Gegenseite Ressourcen, und die sind begrenzt. Voreingestellt darf ein Nutzer fünf Remoteshells gleichzeitig öffnen, und jede Shell hat eine Speicherobergrenze von 150 Megabyte. Skripte, die Sitzungen anlegen und nicht wieder entfernen, laufen deshalb beim vierten Durchlauf in Fehler, deren Meldung nichts mit der Ursache zu tun hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was beim Einschalten tatsächlich passiert
Enable-PSRemoting ist kein Schalter, sondern eine Folge von Vorgängen. Zuerst läuft Set-WSManQuickConfig, das den WinRM-Dienst startet, dessen Starttyp auf automatisch setzt, einen Listener anlegt, der Anfragen auf beliebigen IP-Adressen entgegennimmt, und eine Firewall-Ausnahme für WS-Management einrichtet. Danach werden die Endpunkte für die laufende PowerShell-Version angelegt, sofern sie fehlen, alle Sitzungskonfigurationen aktiviert und ihre Sicherheitsbeschreibungen für den Fernzugriff angepasst. Zum Schluss wird der Dienst neu gestartet, damit die Änderungen greifen.
Der vorletzte Schritt verdient Aufmerksamkeit, weil er über das Einschalten hinausgeht. Dabei werden die Einträge entfernt, mit denen einzelne Sitzungskonfigurationen ausdrücklich für die lokale Nutzung reserviert waren. Wenn also jemand vor euch einen Endpunkt bewusst eingeschränkt hat, hebt ein pauschaler Aufruf diese Einschränkung auf. Das ist der beste Grund, den Befehl nicht routinemäßig über den ganzen Serverbestand laufen zu lassen, zumal PowerShell Remoting auf Windows-Server-Plattformen ohnehin standardmäßig aktiviert ist.
Die Ports sind seit WinRM in Version 2 festgelegt: 5985 für HTTP und 5986 für HTTPS. Es gibt zusätzlich Einstellungen für einen Kompatibilitätslistener auf 80 und 443, die aber standardmäßig ausgeschaltet sind. Auf Serverversionen legt Enable-PSRemoting Firewall-Regeln für private und Domänennetzwerke an, die den Fernzugriff erlauben, und für öffentliche Netzwerke eine Regel, die den Zugriff nur aus dem lokalen Subnetz zulässt. Auf Client-Versionen sind die Regeln für private und Domänennetzwerke weiter gefasst, und für öffentliche Netzwerke braucht es den Schalter -SkipNetworkProfileCheck.
Einzelne Befehle, dauerhafte Sitzungen und der interaktive Weg
Für einen Befehl auf vielen Rechnern ist Invoke-Command mit -ComputerName der richtige Weg. Der Aufruf baut die Verbindungen auf, führt den Skriptblock aus, sammelt die Ergebnisse ein und räumt wieder ab. Die Ergebnisse tragen dabei eine zusätzliche Eigenschaft mit dem Namen des Rechners, von dem sie stammen, was das Zusammenführen über viele Server hinweg deutlich vereinfacht. Für ein Skript, das auf mehreren Servern laufen soll und lokal vorliegt, gibt es den Parameter -FilePath, der die Datei überträgt statt sie auf jedem Server bereitstellen zu müssen.
Sobald mehrere Schritte aufeinander aufbauen, lohnt eine dauerhafte Sitzung. Eine mit New-PSSession erzeugte Sitzung behält ihren Zustand, und eine Variable, die du im ersten Aufruf setzt, steht im zweiten noch zur Verfügung. Das ist mehr als Bequemlichkeit: Es erspart, große Datenmengen erst zurückzuholen, lokal zu verarbeiten und wieder hinzuschicken. Der Preis ist, dass du die Sitzung selbst wieder schließen musst, weil sie sonst Kontingent belegt.
Enter-PSSession ist der dritte Weg und der für die Fehlersuche angenehmste. Der Aufruf öffnet eine interaktive Sitzung auf einem einzelnen Rechner, die Eingabeaufforderung wechselt auf dessen Namen, und alles, was du danach tippst, läuft dort. Beendet wird das mit Exit-PSSession. Für Automatisierung eignet sich dieser Weg nicht, für das Nachsehen an einem konkreten Server dagegen sehr gut. Und schließlich gibt es eine ganze Reihe von Cmdlets mit einem Parameter -ComputerName, die gar kein WinRM brauchen, weil sie über andere Verfahren arbeiten. Restart-Computer, Get-Service und Get-WinEvent gehören dazu.
Verschlüsselung, Authentifizierung und der Mythos vom Klartext
Die Vorstellung, Remoting über Port 5985 laufe unverschlüsselt, hält sich hartnäckig und ist so nicht richtig. Der WinRM-Dienst lehnt unverschlüsselten Verkehr standardmäßig ab, denn AllowUnencrypted steht auf false. In einer Domäne wird über Negotiate Kerberos gewählt, und die Nutzdaten werden auf dieser Ebene verschlüsselt, auch wenn der Transport HTTP heißt. Was HTTP an dieser Stelle nicht liefert, ist der Nachweis über die Gegenstelle auf Transportebene, und genau darum geht es beim Wechsel auf HTTPS.
Ein Blick auf die Voreinstellungen des Dienstes ist deshalb lohnend, bevor jemand daran dreht. Basic-Authentifizierung ist auf Dienstseite ausgeschaltet, zertifikatsbasierte Authentifizierung ebenfalls, CredSSP ebenfalls, Kerberos und Negotiate sind eingeschaltet. Das ist eine sinnvolle Grundhaltung. Jede Abweichung davon sollte einen Grund und ein Ablaufdatum haben, denn die üblichen Verdächtigen in Sicherheitsprüfungen sind genau diese vier Schalter.
Für Ziele außerhalb der Domäne bleiben zwei Wege. Der eine ist die Liste der vertrauenswürdigen Hosts, und dort gilt der Warnhinweis aus der Dokumentation wörtlich: Die eingetragenen Rechner werden nicht authentifiziert, und der Client kann ihnen Anmeldeinformationen schicken. Für einen einmaligen Vorgang mit einem eng gefassten Eintrag ist das vertretbar, für einen Dauerzustand nicht. Der andere Weg ist ein Listener über HTTPS mit einem Zertifikat, das der Client prüfen kann. Er kostet etwas Vorlauf für das Zertifikat und die Freigabe von Port 5986, dafür ist die Gegenstelle danach nachweisbar die, für die sie sich ausgibt.
Einschränken statt öffnen: Just Enough Administration
JEA beantwortet eine Frage, die in jedem Serverbetrieb regelmäßig auftaucht: Wie darf jemand eine eng umrissene Aufgabe erledigen, ohne dafür Administrator zu sein? Microsoft beschreibt dazu einen Fall, der vielen bekannt vorkommt. Der DNS-Dienst läuft auf demselben Rechner wie ein Domain Controller, die DNS-Zuständigen brauchen lokale Administratorrechte, um Probleme zu beheben, und dafür müsste man sie in eine sehr hoch privilegierte Gruppe aufnehmen. Damit hätten sie faktisch Kontrolle über die gesamte Domäne.
Der Ausweg besteht aus zwei Teilen. In einer Rollenfähigkeitsdatei steht, welche Cmdlets, Funktionen und externen Befehle zur Verfügung stehen sollen, und zwar ausdrücklich benannt statt pauschal freigegeben. In der Sitzungskonfiguration steht, welche Konten oder Gruppen diesen Endpunkt benutzen dürfen und welche Rollenfähigkeit für sie gilt. Der eigentliche Kniff liegt darin, unter welchem Konto die Sitzung anschließend arbeitet: entweder über ein temporäres, privilegiertes virtuelles Konto, das nur für die Dauer der Sitzung existiert, oder über ein gruppenverwaltetes Dienstkonto, dessen Kennwort niemand kennen muss.
Der dritte Ertrag ist die Nachvollziehbarkeit. JEA-Sitzungen lassen sich mit Mitschriften und Protokollen versehen, aus denen später hervorgeht, welche Befehle in einer Sitzung tatsächlich ausgeführt wurden. Das ist in zwei Richtungen nützlich: Es beantwortet Fragen nach einem Vorfall, und es beantwortet die Frage, welche Befehle in der Rollenfähigkeit fehlen, weil die Leute sonst mit ihrer Arbeit nicht weiterkommen. Wer JEA einführt, sollte deshalb mit einer eng gefassten Liste anfangen und sie anhand dieser Protokolle erweitern, statt umgekehrt vorsichtshalber viel freizugeben.
Dazu passende Kurse
Wenn wiederkehrende Handgriffe bei euch noch von Hand über mehrere Server laufen, sind PowerShell-Kurse für den Windows-Serverbetrieb der naheliegende nächste Schritt.
Wer Automatisierung über Windows hinaus denkt, findet in Kurse zur Automatisierung wiederkehrender Betriebsaufgaben den passenden Rahmen dafür.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Muss ich Remoting auf jedem Server einschalten?
Ist Remoting über Port 5985 unverschlüsselt?
Warum funktioniert der Zugriff auf eine Dateifreigabe aus einer Remotesitzung nicht?
Warum landet meine Verbindung auf Windows PowerShell statt auf PowerShell 7?
Wie erlaube ich jemandem zwei Befehle, ohne Administratorrechte zu vergeben?
Warum bricht mein Skript nach mehreren Durchläufen mit einem Ressourcenfehler ab?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
PowerShell im Serverbetrieb systematisch statt nebenbei lernen
In den PowerShell-Kursen bei cmt arbeitest du an mehreren Servern gleichzeitig, richtest Remoting selbst ein und lernst die Stellen kennen, an denen aus einem hilfreichen Werkzeug ein offener Zugang wird.
Passt dazu
- PowerShell führt das Skript nicht aus: Ausführungsrichtlinie und Signatur klären
- Vom Einzeiler zum wiederverwendbaren PowerShell-Modul
- WMIC und VBScript durch PowerShell ersetzen, bevor sie verschwinden
- Active Directory absichern: Tier-Modell, privilegierte Konten und saubere Delegierung