6
Berechtigungen für GetSessions usw. in PowerShell-Remoting
Um nicht immer eine (freie) RDP-Anmeldung und ein Citrix-GUI zu bemühen, will ich uns eine Möglichkeit des PowerShell-Remoting schaffen.
Vorteile
Nachteile
Schritte dahin:
Sieht aus wie eine .NET-Exception, also ist GetSessions wohl eine vom Cmdlet oder Modul-dll gerufene Methode aus dem .NET-Framework.
Später will ich natürlich auch die anderen Funktionen aus dem Modul ausführen:
Welche Rechte brauche ich auf den Terminalservern, um diese Methoden anwenden zu dürfen? Welches Assembly enthält GetSessions, welchen security groups auf welchen Servern muss ich mich hinzufügen?
Vorteile
- Die Zahl der PS-Remote-Sessions ist m.W. nicht künstlich, lizenzrechtlich beschränkt.
- Geht schnell.
Nachteile
- Nicht jeder kann damit umgehen, es gibt erstaunlich viele Mausklicker unter den Admins.
- Es gibt manchmal Berechtigungsprobleme, so auch hier.
Schritte dahin:
- Terminalservices-Befehle gesucht, keinen Hinweis im Netz auf Core-Lösungen (Cmdlets, Zugriff auf statische .NET-Methoden o.ä.) gefunden. Dafür dies: https://psterminalservices.codeplex.com/
- psterminalservices auf einem Terminalserver in Modules-Ordner entpackt, Import-Module, läuft.
- PowerShell-Profile ergänzt um
Import-Module PSTerminalServices
function Get-TsSessionByUserName
{
for ($i = 1; $i -le 8; $i++)
{
$strTsSvr = "TS00$i"
"Get-TSSession -ComputerName $strTsSvr -UserName $($args)"
Get-TSSession -ComputerName $strTsSvr -UserName $($args)
}
}- Test in PowerShell lokal erfolgreich:
Get-TsSessionByUserName user
Get-TSSession -ComputerName TS001 -UserName user
Get-TSSession -ComputerName TS002 -UserName user
Server SessionID State IPAddress ClientName WindowStationName UserName
------ --------- ----- --------- ---------- ----------------- --------
TS002 25 Active ... ... ... domain\user
Get-TSSession -ComputerName TS003 -UserName user
Get-TSSession -ComputerName TS004 -UserName user
TS004 11 Disconnected domain\user
Get-TSSession -ComputerName TS005 -UserName user
Get-TSSession -ComputerName TS006 -UserName user
Get-TSSession -ComputerName TS007 -UserName user
Get-TSSession -ComputerName TS008 -UserName user- Erfolgreich Sitzung von entferntem Rechner geöffnet:
Enter-PSSession TS006 - Get-TSSession user: Erfolgreich / ohne Fehler -> Das Modul ist verfügbar.
- Da das lokale Profil nicht ausgeführt wird und mir der Aufwand für ein remote profile nur für diese Mini-Function zu groß ist, gebe ich zum Test ein oder definiere die function vor der Verwendung in der Sitzung. Und erhalte folgende Fehlermeldung:
Get-TSSession -ComputerName TS001 -UserName user
Exception calling "GetSessions" with "0" argument(s): "Zugriff verweigert"
+ CategoryInfo : NotSpecified: (:) , MethodInvocationException
+ FullyQualifiedErrorId : Win32ExceptionSieht aus wie eine .NET-Exception, also ist GetSessions wohl eine vom Cmdlet oder Modul-dll gerufene Methode aus dem .NET-Framework.
Später will ich natürlich auch die anderen Funktionen aus dem Modul ausführen:
CommandType Name ModuleName
----------- ---- ----------
Function Disconnect-TSSession PSTermina...
Function Get-TSCurrentSession PSTermina...
Function Get-TSProcess PSTermina...
Function Get-TSServers PSTermina...
Function Get-TSSession PSTermina...
Function Send-TSMessage PSTermina...
Function Stop-TSProcess PSTermina...
Function Stop-TSSession PSTermina...Welche Rechte brauche ich auf den Terminalservern, um diese Methoden anwenden zu dürfen? Welches Assembly enthält GetSessions, welchen security groups auf welchen Servern muss ich mich hinzufügen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 335125
Url: https://administrator.de/forum/berechtigungen-fuer-getsessions-usw-in-powershell-remoting-335125.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
6 Kommentare
Neuester Kommentar
Btw. native CMDLets gibt es dafür schon !
Remote Desktop Cmdlets in Windows PowerShell
Remote Desktop Cmdlets in Windows PowerShell
Hi elchapo,
danke, meinem Computeraccount Full control auf dem entfernten Server geben, das probier ich mal aus. Auch wenn die dort diskutierte Situation eine andere ist. Aber wer weiß.
OK, ab 2012 gibt es native Remote-Desktop-Cmdlets. Der Kunde hat die 9 Jahre bis 2012 noch nicht aufgeholt. Aber gut zu wissen ...
danke, meinem Computeraccount Full control auf dem entfernten Server geben, das probier ich mal aus. Auch wenn die dort diskutierte Situation eine andere ist. Aber wer weiß.
OK, ab 2012 gibt es native Remote-Desktop-Cmdlets. Der Kunde hat die 9 Jahre bis 2012 noch nicht aufgeholt. Aber gut zu wissen ...
Full control über was? Aber egal, die Situation ist eh eine andere. Verbinde ich mich per RDP auf einen der TS... und führe dort lokal meine kleine Abfrageschleife aus, dann läuft das ohne Fehler. Also, das implizite Remoting des PowerShell-Cmdlets funktioniert. Was PowerShell nicht zulässt, ist das verkettete Remoting: Ich öffne eine PowerShell-Remote-Verbindung auf irgendeinen TS... und führe meine Abfrage aus: Ich erhalte nur von dem Rechner die Daten, mit dem ich primär verbunden bin. Implizites Remoting über eine interaktive PowerShell-Sitzung, das ist ihm zu viel.
Jetzt wollte ich versuchen, eine implizite PowerShell-Sitzung in eine lokale zu importieren. Das wäre ja wohl der PowerShell-Weg. Da kriege ich auch eine Fehlermeldung:
(ts01 ist in Wirklichkeit ein FQDN.) Eine interaktive PS-Remoting-Sitzung auf ts01 lässt sich aber öffnen, Remoting ist grundsätzlich erlaubt. Also es läuft wohl darauf raus, dass ich entweder eine RDP-Sitzung auf irgendeinen TS... öffne und dort mit dem Citrix-GUI oder meinem Modul arbeite (dazu müsste ich es aber auf jedem Terminalserver bereitstellen, kann ich ja), oder ich öffne eine interaktive PS-Remoting-Sitzung auf jede der TS...-Maschinen. Um in jeder meine Suche nach der Sitzung einzeln abzusetzen. Das ist ein bisschen mühsam, aber um ein Kundenproblem zu lösen, müsste ich das im Zweifel tun. Schade.
PS-Remoting kann in vielem RDP ersetzen und ergänzen, aber das hier funktioniert nicht ganz so elegant, weil es verschachteltes Remoting wäre.
Jetzt wollte ich versuchen, eine implizite PowerShell-Sitzung in eine lokale zu importieren. Das wäre ja wohl der PowerShell-Weg. Da kriege ich auch eine Fehlermeldung:
New-PSSession : [ts01] Connecting to remote server ts01 failed with the following error message : The WinRM client received an HTTP bad request status (400), but
the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:15
+ $SessionTs1 = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : -2144108175,PSSessionOpenFailedPS-Remoting kann in vielem RDP ersetzen und ergänzen, aber das hier funktioniert nicht ganz so elegant, weil es verschachteltes Remoting wäre.
Man kann das was in einer Remote-Session möglich ist einschränken. Per Default ist nicht alles in einer solchen Session erlaubt. Das lässt sich anpassen indem man in der Config einen Parameter auf FullLanguage anpasst:
http://blogs.microsoft.co.il/scriptfanatic/2011/08/22/get-full-control- ...
Btw. sollte man natürlich eher mit Invoke-Command arbeiten statt interaktiv mit enter-pssession!
http://blogs.microsoft.co.il/scriptfanatic/2011/08/22/get-full-control- ...
Btw. sollte man natürlich eher mit Invoke-Command arbeiten statt interaktiv mit enter-pssession!
https://cruisinit.wordpress.com/2017/04/28/mit-terminal-server-sessions- ...
Meinen eigenen Beitrag kann ich nicht als »Zur Lösung beigetragen« markieren.
Hi password, danke für den Lesetipp, das schau ich mir auf jeden Fall an.
Meinen eigenen Beitrag kann ich nicht als »Zur Lösung beigetragen« markieren.
Hi password, danke für den Lesetipp, das schau ich mir auf jeden Fall an.
