Feb 05, 2020

7959

W2k16 Terminal Server - Remote Desktop WebClient CLIENTNAME abfragen

Hallo zusammen,

ich hab folgendes Problem.
Ich habe einen Windows Terminal Server 2016 mit dem installierten WebClient.

In einer Standard RDP Session mittels mstsc.exe kann ich folgende Variable mit Powershell abfragen.

$env:CLIENTNAME

In der Browser WebClient Session wird diese Variable nicht aufgelöst.
Hat jemand eine Idee wie ich meinen Clientnamen oder IP Adresse (Client NICHT Terminal Server) herausfinde?

$env:COMPUTERNAME liefert ja lediglich den Namen des Terminal Servers zurück

Vielleicht hat jemand eine Idee?

Please also mark the comments that contributed to the solution of the article

Content-Key: 543954

Url: https://administrator.de/contentid/543954

Printed on: April 24, 2024 at 23:04 o'clock

84 Comments

Latest comment

Hi,

Zitat von @joe2017:
$env:COMPUTERNAME liefert ja lediglich den Namen des Terminal Servers zurück

Ja, ist doch richtig. Du musst doch auch den Clientnamen abfragen.
$env:CLIENTNAME

E.

Edit:

In der Browser WebClient Session wird diese Variable nicht aufgelöst.

Oder reden wir von einem PS-Script, welches als LoginScript laufen soll?

Du hast verstanden, dass ich den RDWebClient verwende oder?

In der normalen RDP Session funktioniert die Abfrage. Die Anmeldung im Browser (Bsp. Firefox) über den RDWebClient liefert nichts zu dieser Variable. Ich habe ganz einfach mal die Powershell als RemoteApp in dem RDWebClient geöffnet und die Variable abgefragt. Leider ist die Abfrage leer.

Hi.

Das kann evtl. daran liegen, dass eine RemoteApp ein paar Dinge gar nicht startet, die eine Vollsitzung startet.
Darf ich fragen, was du damit bezwecken willst? Vielleicht habe ich dann eine bessere Idee.

Ich habe auf meinem Terminal Server ca. 100 Printer installiert.
Ich will mittels Powershell dem Benutzer seinen richtigen Standard Drucker zuweisen.

In einer normalen RDP Session funktioniert das soweit auch alles.
Ich frage meine Variable ($env:CLIENTNAME) ab und vergleiche diese mit meiner Config.txt
Hier stehen Clientnamen und die entsprechenden Druckernamen welchen ich anschließend als Standarddrucker setze.

Ich muss somit irgendwie an den Clientnamen kommen.
Evtl würde auch ein redirect von lokalen Laufwerken weiterhelfen. Hier eine txt mit dem CLIENTNAME abgelegt und diese über die Powershell abgefragt.

Der lokale Standarddrucker des Clients wird bei mir ohne jegliches Zutun in die Remoteapp umgeleitet und ist dort auch Standard. Du musst nichts tun, es sei denn, du verstellst vorher etwas.

Zitat von @joe2017:
Du hast verstanden, dass ich den RDWebClient verwende oder?

Ja, sicher. Und ich frage auch aus einem bestimmten Grund. Und Du hast mir jetzt bestätigt, dass es sich um ein LoginScript handelt.

In der Browser WebClient Session wird diese Variable nicht aufgelöst.

Niemals? Auch nicht später?

Aus meiner Erfahrung - allerdings mit Citrix oben drauf - kommt es nicht selten zu genau diesem Problem, dass während des Logins diese Variable noch nicht gesetzt ist. Wann das eintritt und wie oft, kann ich nicht sagen. Wenn man einen Desktop startet, dann ist diese aber spätestens vorhanden nachdem der Explorer-Prozess läuft. Deshalb könnte es eine Option sein, im Script eine Pause einzubauen und es später noch einmal zu versuchen. Dafür müssten die LoginScripte aber in jedem Fall asynchron ausgeführt werden (, falls Ihr das überhaupt abgeschaltet haben solltet).

Ich habe die Drucker nicht auf dem Client sondern dem Terminal Server installiert.

Ich habe evtl noch eine Idee wie ich an den Rechnernamen/IP kommen könnte.

Mit folgendem Befehl erhalte ich alle WebClient Verbindungen:

netstat -ot | findstr :443

Jetzt habe ich zwar die Computernamen die verbunden sind aber noch keine Zuordnung zu dem angemeldeten Benutzer.
Vielleicht hat jemand eine Idee wie ich das verknüpfen könnte?

ALs Idee von meiner Seite... Ich sehe zu der jeweiligen Verbindung die PID.
Vielleicht kann man abfragen welcher Benutzer diese PID verwendet?

ZUSATZ
Die PID bleibt leider immer die selbe, da alle Clients den selben Prozess verwenden.
Jedoch sehe ich eine Remoteadresse (ClientName:55743). VIelleicht kann man die Remoteadresse mit dem Benutzer verknüpfen?

Du brauchst keinen Drucker jemals auf dem TS zu installieren. Microsoft nennt das "easy print": der lokale Clientdrucker wird ohne Treibereinsatz auf dem Server durchgeschleift.

Nur wenn Du "easy print" abschaltest, wirst Du überhaupt Probleme bekommen. Per Default ist es jedoch an.

Zitat von @DerWoWusste:
Du brauchst keinen Drucker jemals auf dem TS zu installieren. Microsoft nennt das "easy print": der lokale Clientdrucker wird ohne Treibereinsatz auf dem Server durchgeschleift.

Das funktioniert aber nur dann, wenn der Client ein Windows OS hat, oder? Was ist bei ThinClients mit Linux, z.B. die von Igel?

Es wird schon einen Grund haben, weshalb ich meine Drucker nicht auf dem Client installiert habe.
Es sind wie bereits vermutet nicht nur Windows Clients welche auch die Webseite (RemoteDesktopServices) zugreifen.

Ich habe evtl. noch eine Idee.
Das zeigt mir die Verbindungen an.

netstat -ot | findstr :443

Das zeigt mir meine Session ID an.

(Get-Process -PID $pid).SessionID

Kann man nicht abfragen welche Verbindung welche Session ID verwendet?
Evtl. über den Remote Port?

Geht doch

bei mir wird hier nichts angezeigt?
Mein Client ist aber auch kein Win10 Client sondern ein Win8.1 Client.
in einer normalen RDP Session wird mir der Clientname abgezeigt.

Zitat von @joe2017:

bei mir wird hier nichts angezeigt?
Mein Client ist aber auch kein Win10 Client sondern ein Win8.1 Client.
in einer normalen RDP Session wird mir der Clientname abgezeigt.

Ist hier egal Windows 7, 8.1, W10 funktioniert auf allen Maschinen sowohl in RemoteApps als auch RD-Sessions, das hat aber nichts mit dem Client-OS zu tun sondern mit dem Server bzw. der RDWebClient Version.

Musst du wohl mal dein RD Webclient auf dem Server aktualisieren, hast du das schon getan?

Ich habe diese gerade erst auf einem frisch installierten W2k16 Server installiert.
Somit sollte eigentlich die neuste Version installiert sein.

Wie kann ich das abfragen bzw. updaten?

Klappt bei mir auch.
Alternativlösung für Dich:

reg query "HKEY_CURRENT_USER\Volatile Environment" /s /v clientname

Zitat von @joe2017:

Ich habe diese gerade erst auf einem frisch installierten W2k16 Server installiert.
Somit sollte eigentlich die neuste Version installiert sein.

Wie kann ich das abfragen bzw. updaten?

https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-se ...

@142232: das Ding braucht man gar nicht, ist bei mir nicht einmal installiert. Es geht nur um Anwendungsaufruf von https://serverFQDN/RDWeb
Edit: ok, wenn ich's mir recht überlege... er hat ja Linuxclients, da braucht er das Ding doch! Oder...?

@dww
Wenn die von Dir genannte Abfrage etwas liefern sollte, dann muss das doch auch als Variable angezeigt werden?

Da gebe ich Dir Recht, hier geht beides, konsequenterweise dürfte bei ihm dann nichts gehen, aber wer weiß.

Zitat von @DerWoWusste:

@142232: das Ding braucht man gar nicht, ist bei mir nicht einmal installiert. Es geht nur um Anwendungsaufruf von https://serverFQDN/RDWeb

Brauchen tut man es nicht zwingend, je nach Clientfähigkeiten.

Edit: ok, wenn ich's mir recht überlege... er hat ja Linuxclients, da braucht er das Ding doch! Oder...?

Nur wenn er keine Anwendung hat die *.rdp Files nutzen und damit eine RDP Session aufrufen kann.

Also die neuste Version (1.0.3) ist bereits installiert.
Und die Vatiable ist nur unter der mstsc RDP Verbindung verfügbar.

Was für eine Server Version hast du installiert? 2016/2019?

Ich habe gerade folgendes in der Registry festgestellt:
HKEY_CURRENT_USER\Volatile Environment\(Nr)

In der MSTSC RDP Session steht hier der Clientname.
In der WebClient RDP Session sthet hier KEIN Clientname!

Jetzt ist die Frage weshalb dieser nicht eingetragen wird?

Was für eine Server Version hast du installiert? 2016/2019?

Sowohl als auch, macht hier keinen Unterschied.

Jetzt ist die Frage weshalb dieser nicht eingetragen wird?

Jetzt ist die Frage wie und was hast du anschließend konfiguriert nach einer Originalinstallation, denn damit klappt es hier ja in einer cleanen best practice Umgebung.

Der Server befindet sich in unserer AD und erhält einige Policies.
Mir wäre jetzt keine Policy bekannt, welche derartige Einträge über den WebClient verhindern würde welche anderer Seits in der MSTSC RDP Session eingetragen werden?

https://support.microsoft.com/de-de/help/2509192/clientname-and-sessionn ...
https://www.google.de/search?q=rdp+app+does+not+fill+environment+variabl ...

Danke für den Tipp.
Die Enstellung im Windows Explorer wurde nicht verändert.

Ich werde noch verrückt. Ich finde nicht heraus, weshalb die Variable nicht bestückt wird?
Auch in meiner Testumgebung wird die Variable nicht in die Registry geschrieben?

Kann ich vielleicht doch über Umwege den Sessionname (RDP-Tcp#4) mit dem (netstat -ot | findstr :443) Clientname:Remoteport verknüpfen?
Gibt es über irgendeinen Umweg eine Verbindung womit ich den USERNAME mit dem CLIENTNAME oder IP verbinden kann.
Natürlich muss das alles mit User Rechten möglich sein

Ich habe heute noch mal folgendes getestet.

Powershell

import-module PSTerminalServices
Get-TSSession

Meine Ausgabe sieht wie folgt aus.

Server: localhost
IPAddress: 192.168.1.1
ClientName: Server01
WindowStationName: RDP-Tcp#8
UserName: DOMAIN\admin

Server: localhost
IPAddress: 0.0.0.0
ClientName:
WindowStationName: RDP-Tcp#9
UserName: DOMAIN\testuser

Auch hier wird keine IP Oder ClientName angezeigt?

Ich habe jetzt übrigens einen komplett neuen Windows Server 2016 aufgesetzt. Ich habe einen DC und die RDS Rollen installiert.
Auch hier wird in der Registry kein Wert zu der "HKCU\Volatile Environment\#\CLIENTNAME" angezeigt.
Das ist jetzt eine Installation ohne GPO´s und irgendwelche Einschränkungen.

Habt Ihr evtl einen W2k19 und es hat sich hierbei etwas verändert?

Anbei meine Installation für die WebClient Seite.

Install-Module -Name PowerShellGet -Force
# Powershell neustarten

Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage
Import-RDWebClientBrokerCert <vom RD Broker exportierte .cer-Datei>
Publish-RDWebClientPackage -Type Production -Latest

Set-RDWebClientDeploymentSetting -Name "SuppressTelemetry" $true  
Set-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" $true   

Zitat von @joe2017:
Habt Ihr evtl einen W2k19 und es hat sich hierbei etwas verändert?

Weiter oben sagtest Du noch, dass es keinen Unterschied zu 2016 machen würde.

Weiter oben hatte ich die Frage gestellt welchen Server der USER "serial" installiert hat. 2016/2019?
Er hatte geantwortet: Sowohl als auch, macht hier keinen Unterschied.

Das kam somit nicht von mir.

Zitat von @joe2017:
Das kam somit nicht von mir.

Lesen ist nicht so meine Stärke.

Ich möchte gerne mal wissen, was Ihr konfiguriert, damit die Variable %clientname% befüllt wird?
Ich habe wie gesagt alles neu clean installiert. Ohne zusätzliche Anpassungen. Muss man hierfür etwas spezielles erlauben?

Kann mir jemand bestätigen, dass bei Ihm die Variable ebenfalls befüllt wird?
Wichtig dabei ist, dass die Verbindung über einen Browser (https://FQDN/RDWeb/WebClient) aufgebaut wurde.
Über die MSTSC.exe wird der Eintrag immer erstellt.

@142232: Vielleicht könntest du mal prüfen was bei dir konfiguriert wurde damit der Eintrag in der Registry (HKCU\Volatile Environment\#\CLIENTNAME) befüllt wird? Könntest du bitte auch noch checken ob dies bei w2k16 und w2k19 der Fall ist. Ich hab aktuell leider keinen w2k19 Server.

Irgendwie muss man doch an die Information kommen?
Vielen Dank zusammen.

Ich habe hier auch sowohl einen 2016er als einen 2019er und die Verbindung wurde in meinen Tests über einen Browser aufgebaut.
Konfiguriert wurde nichts, dennoch ist die Variable nutzbar!

Der 2016er war mal ein 2012er (Upgegradet).
Der 2019er war mal ein 2012er (doppelt upgegradet)

Dann muss etwas spezielles konfiguriert sein.
In meinem Fall (Neuinstallation) ist die Variable nicht nutzbar.

Anderer Ansatz. Kommt man vielleicht über den Webserver (IIS) an die Information?
Ich frage mit einem Client die Webseite an. Somit kennt mein IIS den Client.
Anschließend melde ich mich an der Webseite (RDS) an.

Vielleicht kann man diese Informationen in Verbindung bringen?

Zitat von @DerWoWusste:

Ich habe hier auch sowohl einen 2016er als einen 2019er und die Verbindung wurde in meinen Tests über einen Browser aufgebaut.
Konfiguriert wurde nichts, dennoch ist die Variable nutzbar!

Dito. Eine App-Session ist nicht anderes wie eine normale TS Sitzung nur das eben nur die jeweilige App sichtbar ist, im Background ist es aber eine normale TS Sitzung und da wird auch das Profile-Environment ganz normal geladen.
Es müssen keinerlei Konfigurationen dafür vorgenommen werden!

Falsche Herangehensweise, wie DerWoWusste schon sagt, mappe den Usern ihre Drucker so wie es vorgesehen ist.

Zitat von @142232:
Falsche Herangehensweise, wie DerWoWusste schon sagt, mappe den Usern ihre Drucker so wie es vorgesehen ist.

Naja, das würde ich jetzt so nicht sagen. Viele Wege führen nach Rumänien.
Mich würde auch interessieren, warum diese Variable da nicht angezeigt wird. Das kann ihm ja auch später nochmal auf die Füße fallen, bei einer anderen Aufgabenstellung.

@joe2017
Wenn ich nicht gerade blind bin, dann hast Du mir diese Frage immer noch nicht beantwortet:

Zitat von @emeriks:

In der Browser WebClient Session wird diese Variable nicht aufgelöst.

Niemals? Auch nicht später?

Zitat von @emeriks:
Mich würde auch interessieren, warum diese Variable da nicht angezeigt wird. Das kann ihm ja auch später nochmal auf die Füße fallen, bei einer anderen Aufgabenstellung.

Na dann soll er halt mal die folgende Funktion in einer Test-Applikation ausführen und checken was ihm diese an Infos zurück liefert.
https://docs.microsoft.com/de-de/windows/win32/api/wtsapi32/nf-wtsapi32- ...

Ich würde den Fokus mal auf den Client legen, denke das es an ihm liegt das die Umgebungsvariable nicht gefüllt ist. Welche Browser verwendest du ?

Genau, das ist aktuell auch nur ein Beispiel mit dem Drucker. Ich habe parallel noch weitere Funktionen in welcher ich die Variable %clientname% benötige.

@emeriks
Entschuldige... Das hab ich wohl überlesen. Nein, die Variable wird nie befüllt. Auch nicht zu einem späteren Zeitpunkt.
Ich bin angemeldet, öffne die Registry und schaue in den Pfad... LEER
Ich öffne die CMD und frage die Variable ab... NICHTS

Wie gesagt. In der standard MSTSC Verbindung habe ich die Variable befüllt. Mit dem WebClient nie.
Auch nicht in einer frisch installierten Umgebung!
Auch nicht mit einem anderen Browser!
Auch nicht mit einem anderen Betriebssystem!

Vielleicht hat ja einer von euch eine VM in welcher er das Szenario mit einer neuen Installation testen kann?

Ich verwende aktuell einen Firefox Portable unter Windows 10. Ich habe das aber auch schon mit einem installierten FF und dem IE getestet.
Auch der Google Chrome zeigt kein Ergebnis.
Auch ein clean installierter Debian Client gibt die Variable nicht zurück.

Ich kann mir nicht vorstellen, dass dies bei euch in einer clean installierten Version funktioniert.
Ich hatte am Freitag einen neuen W2k16 aufgesetzt. Ohne GPO´s und ohne zusätzliche Einschränkungen.
Auch auf diesem wurde die Variable nicht befüllt.

Hat von euch jemand die Möglichkeit einer neuen Testinstallation?

Zitat von @joe2017:
Ich kann mir nicht vorstellen, dass dies bei euch in einer clean installierten Version funktioniert.

Ist aber so, siehst du ja oben an meinem geposteten Screenshot

Ich hatte am Freitag einen neuen W2k16 aufgesetzt. Ohne GPO´s und ohne zusätzliche Einschränkungen.
Auch auf diesem wurde die Variable nicht befüllt.

Hat von euch jemand die Möglichkeit einer neuen Testinstallation?

Meine Testumgebung wird regelmäßig auf einen cleanen Snapshot zurückgesetzt, das war auch bei meinen obigen Tests der Fall.

Ist das immer noch dein 2012 Upgrade auf 2016/2019?
Falls ja liegt es vielleich daran. Hast du die Möglichkeit einen neuen Server 2016 zu installieren und das Ganze zu testen?
Wie installierst du den Server? Was genau installierst du?

Vielleicht mache ich auch etwas falsch?

Meine Installationsschritte:

Install w2k16 Server
Install Microsoft Updates
Add Role DC & DNS
Promote DC
Remote Desktop Services Installation > Quick Start > Session Based
Add RD Gateway
Add RD License Server (per user)

Powershell

Install-Module -Name PowerShellGet -Force
Restart Powershell
Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage

Die folgenden Zertifikate sind nur für meinen Test.

$rootcert = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -DnsName "RootCA" -TextExtension @("2.5.29.19={text}CA=true") -KeyUsage CertSign,CrlSign,DigitalSignature
[System.Security.SecureString]$rootcertPassword = ConvertTo-SecureString -String "password" -Force -AsPlainText
[String]$rootCertPath = Join-Path -Path 'cert:\CurrentUser\My\' -ChildPath "$($rootcert.Thumbprint)"
Export-PfxCertificate -Cert $rootCertPath -FilePath 'C:\Path\RootCA.pfx' -Password $rootcertPassword
Export-Certificate -Cert $rootCertPath -FilePath 'C:\Path\RootCA.crt'
$testCert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "Server.domain.net" -KeyExportPolicy Exportable -KeyLength 2048 -KeyUsage DigitalSignature,KeyEncipherment -Signer $rootCert
[String]$testCertPath = Join-Path -Path 'cert:\LocalMachine\My\' -ChildPath "$($testCert.Thumbprint)"
Export-PfxCertificate -Cert $testCertPath -FilePath 'C:\Path\Server.domain.net.pfx' -Password $rootcertPassword
Export-Certificate -Cert $testCertPath -FilePath 'C:\Path\Server.domain.net.crt'

Import-RDWebClientBrokerCert 'C:\Path\Server.domain.net.crt'
Publish-RDWebClientPackage -Type Production -Latest
Set-RDWebClientDeploymentSetting -Name "SuppressTelemetry" $true
Set-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" $true
Zertifikat für alle RD Serviceses setzen ('C:\Path\Server.domain.net.crt')
Am Client Webseite öffnen (https://Server.domain.net/RDWeb/webclient/)

Tach auch.

Zitat von @joe2017:
Vielleicht mache ich auch etwas falsch?

Meine Installationsschritte:

Install w2k16 Server
Install Microsoft Updates
Add Role DC & DNS
Promote DC
Remote Desktop Services Installation > Quick Start > Session Based
Add RD Gateway
Add RD License Server (per user)

Terminal Server auf dem DC ???? JA eindeutig ein ziemlich schwerer Fehler!

Kann ich hier übrigens testweise bestätigen, hier funktioniert die Variable CLIENTNAME ebenfalls einwandfrei in der Server-Spielwiese (Aktueller Server 2016 mit allen Terminal Services Roles, aber natürlich separater DC VM!)

Gruß

Das ist mir auch klar das man keinen TS auf dem DC installiert. Das habe ich auch nur auf meiner Test VM am Freitag so installiert.
Ich war einfach faul und wollte mir die zweite VM sparen.

Aber wie gesagt, das war nur ein Test um meine GPO´s und sonstige Konfigurationen auszuschließen.

Wie öffnest du deine Remote Apps? Als .rdp file? Oder innerhalb des Browsers?

Zitat von @joe2017:

Das ist mir auch klar das man keinen TS auf dem DC installiert. Das habe ich auch nur auf meiner Test VM am Freitag so installiert.
Ich war einfach faul und wollte mir die zweite VM sparen.

Aber fern ab von einer "normalen" Produktiv-Umgebung!

Aber wie gesagt, das war nur ein Test um meine GPO´s und sonstige Konfigurationen auszuschließen.

Wäre für mich aber evt. ein Grund warum es offensichtlich nur bei dir nicht funktioniert. Auf DCs herschen ja von Haus aus strengere Sicherheitsrichtlinien als auf normalen Member-Servern.

Wie öffnest du deine Remote Apps? Als .rdp file? Oder innerhalb des Browsers?

Innerhalb des Browsers.

Dann werde ich diesen Test mit zwei getrennten VM´s noch mal testen. Ich melde mich noch mal.
Aber hast Recht, das könnte evtl auch ein Grund sein.

Du sagtest mit allen TS Rollen. Der Remote Desktop Virtualization Host ist bei mir nicht installiert. Der sollte hierfür aber nicht notwendig sein oder?

Zitat von @joe2017:
Du sagtest mit allen TS Rollen. Der Remote Desktop Virtualization Host ist bei mir nicht installiert.

Damit meinte ich nur die die für den WebClient laut Doku minimal nötig sind (SessionHost, Broker, Gateway,WebAccess).

Der sollte hierfür aber nicht notwendig sein oder?

Nein ist er nicht.

Also auch eine getrennte saubere Installation befüllt die Variable %clientname% NICHT!
@142970 hast du eine 2016 Neuinstallation durchgeführt? Oder ebenfalls ein Update von 2012? Ich befürchte fast, dass es etwas hiermit zu tun haben könnte.

Nachdem keiner eine aktuelle 2016 Neuinstallation durchführen kann/möchte, kann mir leider niemand bestätigen, dass es hiermit funktioniert.
Ich wüsste auch nicht, was ich während meiner Installation falsch machen könnte. Das ist eigentlich kein Hexenwerk.
Ich habe weiter oben auch den gesamten Ablauf beschrieben. Weiche ich von einer euren Installationen ab?

Zur Info, ich habe mich nicht nur mit einem Benutzer, sondern auch mit dem Domain Admin angemeldet. Somit sollte ich fehlende Berechtigungen ausschließen können.

Zitat von @joe2017:

Also auch eine getrennte saubere Installation befüllt die Variable %clientname% NICHT!

Dann machst du wohl irgendwo etwas falsch, hmmm grübel.

@142970 hast du eine 2016 Neuinstallation durchgeführt? Oder ebenfalls ein Update von 2012?

Clean Install.

Nachdem keiner eine aktuelle 2016 Neuinstallation durchführen kann/möchte, kann mir leider niemand bestätigen, dass es hiermit funktioniert.

Das tue ich hiermit

Hast du mal geprüft, ob meine Installation von deiner abweicht?
Schließlich kann ich auch nur die Installationsbeschreibung von Microsoft befolgen.
Ich wüsste nicht was in meinem Fall anders sein sollte?

Zitat von @joe2017:

Hast du mal geprüft, ob meine Installation von deiner abweicht?

Ja, Für Zertifikate wird eine AD CA benutzt.
Installation der RD Rollen statt quick, custom.

Schließlich kann ich auch nur die Installationsbeschreibung von Microsoft befolgen.
Ich wüsste nicht was in meinem Fall anders sein sollte?

Die Variable ist abhängig davon ob die jeweilige Anwendung überhaupt die Funktion zum Laden des Environments anstößt, tut sie das nicht ist auch die Variable leer. MS selbst bezeichnet die Umgebungsvariable CLIENTNAME aber schon selbst als deprecated, darauf setzen würde ich also generell schon nicht mehr.

Also ich habe jetzt sogar noch mal die RD Rollen nicht in der quick sondern der Standard Installation durchgeführt.
Meine Collection manuel erstellt und den explorer als test RemoteApp hinzugefügt.

Auf der Webseite (https://Server.domain.net/RDWeb/webclient/) angemeldet und den explorer (RemoteApp) gestartet.
Von hier aus die regedit und cmd gestartet und die VAriable geprüft.

Auch hier bleibt die Variable LEER. Ich weiß nicht was ich an der Installation noch anders machen soll.
Welche Apps hast du freigegeben?

Testest Du eigentlich immer als Admin oder auch als Nicht-Admin? Macht das möglicherweise einen Unterschied?

Wenn die Variable schon als veraltet gilt, gibt es doch sicher einen Nachfolger, bzw eine ander Möglichkeit um die Information abzufragen.
Vielleicht muss ich das Thema doch noch mal anders angehen.

Wie gesagt, man kann abfragen welche Clients verbunden sind.
Man kann auch abfragen welche Benutzer angemeldet sind.
Jedoch nicht welcher Benutzer welchen Client verwendet.

Zitat von @emeriks:

Testest Du eigentlich immer als Admin oder auch als Nicht-Admin? Macht das möglicherweise einen Unterschied?

Das macht leider auch keinen Unterschied

Zitat von @joe2017:
bzw eine ander Möglichkeit um die Information abzufragen.

Wie immer mit der Funktion die MS extra dafür bereitstellt
https://docs.microsoft.com/de-de/windows/win32/api/wtsapi32/nf-wtsapi32- ...

Wie genau kann ich das verwenden. Das Problem wird aber wahrscheinlich auch noch sein, dass ein Standard Benutzer keine erforderliche Rechte hierfür hat oder?

Zitat von @joe2017:

Wie genau kann ich das verwenden.

Mit jeder halbwegs vernünftigen Programmier- oder Skriptsprache. Win32 APIs sind allgemeine Programmierfunktionen die Windows bereitstellt.
Use PowerShell to Interact with the Windows API: Part 1

Das Problem wird aber wahrscheinlich auch noch sein, dass ein Standard Benutzer keine erforderliche Rechte hierfür hat oder?

Doch das ist kein Problem, Informationen über die eigene Session abzufragen kann auch ein stink normaler User.

Hast du eine Idee wie ich das mit Powershell abfragen kann.
Leier übersteigt das meine Kenntnisse.
Ich würde mich freuen wenn du mir hier einen Tipp geben kannst.

Dann belese dich dazu mal
Use PowerShell to Interact with the Windows API: Part 1

Sorry! Habs gerade gesehen. Das hab ich irgendwie überlesen.
Ich schau es mir gleich mal an.

Ich habe gerade einen interessanten Link gefunden:
WMI object to get current sessions with client name?

Das ist meine Rückmeldung:
DOMAIN\admin SessionID: 2 ClientName: TS-1
DOMAIN\test SessionID: 5 ClientName: n/a

Somit scheint das auch nicht zu funktionieren. Das gibt es doch alles nicht!

Könnte vielleicht sein, dass der IIS hier etwas blockiert und man zusätzlich etwas freigeben muss?

Servus zusammen,
Was ein riesen Thread, da konnte ich es mir nicht verkneifen mal rein zu schauen

.

Habe mit das Problem gerade mal angesehen. Wenn man die Verbindung über das RDP-File vornimmt stellt die Verbindung wie ja erwartet der eigene gerade verwendete Client her, Ergebnis ist das CLIENTNAME auch korrekt gefüllt íst.

Beim Verwenden des RD Webclients ist das so, dass der IIS die Rolle eines Proxies einnimmt, also für den User die Verbindung im Auftrag herstellt und ihm dann nur das Ergebnis im Browser präsentiert. Die RDP-Session sieht also nur den IIS als CLIENT nicht den Client des Users der über den Browser kommt. Da der IIS bei euren Installationen quasi von localhost die Verbindung aus aufbaut (Eure Server sind ja sowohl Broker, WebAccess als auch Sessionhost) wird auch die Umgebungs-Variable nicht erstellt, logisch wäre ja dann der IIS selbst. Eine Übergabe des Computernamens über den Browser ist hier seitens MS nicht vorgesehen, der Browser selbst stellt den der Webanwendung ja auch nicht zur Verfügung.

Kann ich hier so problemlos in einer Testumgebung auf einem Server 2016 als auch 2019 nachvollziehen. Hier wird die Umgebungsvariable ebenfalls wie beim TO nicht gefüllt.

Du könntest aber in eurer Domain in einem Log festhalten auf welchen Clients ein User gerade eingeloggt ist und das als Referenz heranziehen, z.B. nach diesem Schema
Anmeldestatus von Benutzern im Active Directory speichern

Grüße Uwe

Hallo Uwe,

vielen Dank für deine Ausführliche Info. Das erklärt natürlich einiges.
Das mit dem Log funktioniert leider nicht, da mein Client nicht zwingend Mitglied meiner Domain ist.
Hierbei handelt es sich nicht nur um Windows Clients sondern auch um Linux und Mobile Devices.

Hast du vielleicht noch eine Idee wie ich an den Client Namen kommen könnte?
Auf jeden Fall Daumen HOCH!

Vielleicht kann man diese beiden Abfragen doch miteinander verbinden?

netstat -ot | findstr :443
(Get-Process -PID $pid).SessionID

Du kannst dir die Info aus dem Eventlog holen

Oder du passt die Webpages des WebClient an, um die IP beim Login wegzuschreiben (Muss dann aber bei jedem Update korrigiert werden).

Yeah!!! Du bist der beste!

Genau das habe ich gesucht! Jetzt muss ich nur noch prüfen, ob der Benutzer (Domain User) diese Information auslesen darf.
Aber das hilft mir zu 99% weiter!

Zitat von @joe2017:
Genau das habe ich gesucht! Jetzt muss ich nur noch prüfen, ob der Benutzer (Domain User) diese Information auslesen darf.

Kannst du, aber mach das besser mit einem EventTrigger dem die Daten übergeben werden und schreibe die Daten in eine XML oder CSV und frage diese mit deinem Client ab das ist performanter.

Du meinst das ich für dieses Log ein Task hinzufüge und somit ein Programm (powershell script) starte.

Hast du zufällig schon eine Abfrage in Powershell geschrieben welche diese Informationen aus dem Log ausließt?
Angenommen es melden sich 5 Personen gleichzeitig an, darf ich ja kein Log überlesen. Es müssen dementsprechend alle Logs erfasst werden?

Aber das ist definitiv der bessere Weg!

Zitat von @joe2017:

Du meinst das ich für dieses Log ein Task hinzufüge und somit ein Programm (powershell script) starte.

Ja. Und dann den TaskTrigger per Notepad so anpassen das die Daten als Variablen im Tasktrigger direkt abrufbar sind, da es sich dabei um XML-Informationen handelt, sind die einzelnen Felder dann direkt ohne Skript abrufbar und können dem TaskTrigger-Skript direkt übergeben werden.
Wie das funktioniert, habe ich hier mal ausführlich demonstriert:
Powershell Skript zur Aufgabenüberwachung

Hast du zufällig schon eine Abfrage in Powershell geschrieben welche diese Informationen aus dem Log ausließt?

Nein, ist aber schnell gemacht

$result = Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" -FilterXPath 'Event[System[EventID=302]]'  
$result | %{
    [pscustomobject]@{
        Time = $_.TimeCreated
        Username = $result.Properties.Value
        Client = $result.Properties[1].Value
    }
}

oder direkt mit Filter auf den Username was dir den Clientname zurückgibt

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" -FilterXPath "Event[System[EventID=302] and UserData[EventInfo[Username='$env:USERDOMAIN\$env:USERNAME']]]" -EA SilentlyContinue | select -F 1 | %{$_.Properties[1].Value}  

Mit einem Eventtrigger Skript bräuchtest du obige Skript aber nicht, da dir dieser die IP und den Usernamen direkt übergeben würden(Siehe verlinkte Anleitung oben). Mit den Daten kannst du dann direkt deine Datenquelle updaten (ohne doppelte Einträge natürlich mit einem Compare-Object oder Where-Object)

Angenommen es melden sich 5 Personen gleichzeitig an, darf ich ja kein Log überlesen. Es müssen dementsprechend alle Logs erfasst werden?

Durch den Tasktrigger verpasst du ja keinen Eintrag und mit den Daten aktualisierst du einfach deine Datenquelle.

Du bist ja echt ein Fuchs!

Nur muss ich bei dem erstellen des Triggers angeben was ich ausführen möchte (Start Program, send an e-mail, display a message).
Man kann ja einfach auf das Log klicken und einen Task zu diesem Log hinzufügen.
Oder erstellst du die Trigger manuell?

Zitat von @joe2017:

Du bist ja echt ein Fuchs!

Das mit dem langen wuscheligen XXX nehme ich mal als Kompliment

Nur muss ich bei dem erstellen des Triggers angeben was ich ausführen möchte (Start Program, send an e-mail, display a message).

Dort wählst du ein Programm und gibst dann ein PS Skript an das deine übergebenden Parameter verwendet, schau dir oben verlinkte Anleitung an, dort steht genau wie du den Tasktrigger so anpasst das du dort die Variablen aus dem XML.Kontext des Events verwenden kannst.

Man kann ja einfach auf das Log klicken und einen Task zu diesem Log hinzufügen.
Oder erstellst du die Trigger manuell?

Hier würde es schon reichen auf EventID zu filtern da reicht es es per Klick zu machen und dann Trigger exportieren anpassen und wieder zu importieren. Wenn du etwas XPath beherrschst kannst du das natürlich auch manuell machen, sieh dir einfach mal den XPath-Filter in meinem zweiten Skript an.

Ja der war gut oder

Also wenn ich das richtig verstanden habe, benutzt du die ValueQueries um die Variable zu übergeben.

<ValueQueries>
        <Value name="ResultCode">Event/EventData/Data[@Name='ResultCode']</Value>  
</ValueQueries>

In deinen Beispiel fragst du wahrscheinlich den Name ab.

Wenn ich in meinem Beispiel die Message verwenden würde, erhalte ich natürlich die gesamte Zeile.
Beispiel Abfrage:

Get-WinEvent -LogName Microsoft-Windows-TerminalServices-Gateway/Operational | select Id, Message | Where-Object { $_.Id -Match '302' }  

The user "DOMAIN\test", on client computer "IP-Address", connected to resource "TS-2.DOMAIN.LOCAL"...

Oder verstehe ich das falsch?
Somit könnte ich diese in ein Array umwandeln und den User und IP in eine variable stecken.

Oder hab ich das falsch verstanden?

Also mein Task sieht wie folgt aus.

<?xml version="1.0" encoding="UTF-16"?>  
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">  
  <RegistrationInfo>
    <Date>2020-02-11T17:11:23.5169585</Date>
    <Author>EMS\administrator</Author>
    <URI>\Event Viewer Tasks\Microsoft-Windows-TerminalServices-Gateway_Operational_Microsoft-Windows-TerminalServices-Gateway_302</URI>
  </RegistrationInfo>
  <Triggers>
    <EventTrigger>
      <Enabled>true</Enabled>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Microsoft-Windows-TerminalServices-Gateway/Operational"&gt;&lt;Select Path="Microsoft-Windows-TerminalServices-Gateway/Operational"&gt;*[System[Provider[@Name='Microsoft-Windows-TerminalServices-Gateway'] and EventID=302]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>  
      <ValueQueries>
        <Value name="ResultCode">Event/EventData/Data[@Name='ResultCode']</Value>  
      </ValueQueries>
    </EventTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">  
      <UserId>S-1-5-21-xxx</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">  
    <Exec>
      <Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
      <Arguments>C:\test\ps_EventTrigger.ps1</Arguments>
    </Exec>
  </Actions>
</Task>

in meiner ps_EventTrigger.ps1 Datei hab ich lediglich eine Test Zeile.

echo $ResultCode >> 'C:\test\test.txt'  

Leider funktioniert das nicht. Hab ich irgendwas falsch verstanden?

Ja leider völlig falsch interpretiert, du musst natürlich wie im Link beschrieben die Value-Query für den Event natürlich anpassen, dort stehen die Daten ja in den XML-Pfaden
Event/UserData/EventInfo/Username
und
Event/UserData/EventInfo/IpAddress

Deswegen lautet das Task XML folgendermaßen (ausführenden User natürlich im Task später noch in der GUI anpassen)

<?xml version="1.0" encoding="UTF-16"?>  
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">  
  <RegistrationInfo />
  <Triggers>
    <EventTrigger>
      <Enabled>true</Enabled>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Microsoft-Windows-TerminalServices-Gateway/Operational"&gt;&lt;Select Path="Microsoft-Windows-TerminalServices-Gateway/Operational"&gt;*[System[Provider[@Name='Microsoft-Windows-TerminalServices-Gateway'] and EventID=302]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>  
      <ValueQueries>
         <Value name="USER">Event/UserData/EventInfo/Username</Value>  
         <Value name="IP">Event/UserData/EventInfo/IpAddress</Value>  
      </ValueQueries>
    </EventTrigger>
  </Triggers>
  <Actions Context="Author">  
    <Exec>
      <Command>powershell.exe</Command>
      <Arguments>-EP ByPass -File "C:\Script.ps1" -Username "$(USER)" -Ip "$(IP)"</Arguments>  
    </Exec>
  </Actions>
</Task>

Dieses ruft ein Powershell-Skript (C:\script.ps1) auf und übergibt die beiden Variablen als Parameter

Das Powershell-Skript das die Daten entgegen nimmt sieht dann beispielsweise so aus

param(
    [string]$username,
    [string]$ip
)

$datastorepath = "C:\temp\test.csv"  

if (Test-Path $datastorepath){
    [array]$csv = Import-CSV $datastorepath -Delimiter ";"  
    $entry = $csv | ?{$_.Username -eq $username} 
    if($entry){
        $csv | ?{$_.Username -eq $username} | %{$_.IP = $ip}
    }else{
        $csv += [pscustomobject]@{Username=$username;IP=$ip} 
    }
}else{
    $csv = [pscustomobject]@{Username=$username;IP=$ip} 
}

$csv | export-csv $datastorepath -NoTypeInformation -Delimiter ";" -Encoding UTF8  

jetzt kapische ?

@uwe:
Ich nutze ja den RD Webclient wie von dir beschrieben - warum wird mir die Variable angezeigt?

Zitat von @DerWoWusste:

@uwe:
Ich nutze ja den RD Webclient wie von dir beschrieben - warum wird mir die Variable angezeigt?

Kann ich nur mutmaßen ohne davor zu sitzen, eventuell eine bestehende getrennte Sitzung die vorher schon hergestellt wurde und vom Webclient dann nur noch inkl. Environment übernommen wird?!

Nein, definitiv nicht.

Hm., du nutzt aber schon den "modernen" Webclient ohne RDP-File Download oder? Ich glaube ich starte mal eine Umfrage unter meinen Kollegen, mal sehen was die Mehrheit von denen ergibt. Ich bin gespannt, vielleicht ergibt sich dann ein klareres Bild oder Zusammenhänge. In meinen Musterumgebungen kann ich es leider nirgendwo nachvollziehen, CLIENTNAME wird dort nicht gefüllt wenn ich den modernen Webclient nutze, egal ob von intern als auch extern.

Ach je... der moderne Client...
Da wir nur Windows als Clients haben, wird hier dieser Client gar nicht genutzt, sorry, ja, das wird der Unterschied sein. Dank seiner Igel ist er ja auf das Ding angewiesen.

Zitat von @DerWoWusste:

Ach je... der moderne Client...
Da wir nur Windows als Clients haben, wird hier dieser Client gar nicht genutzt, sorry, ja, das wird der Unterschied sein.

Hätte mich eigentlich auch schwer gewundert wie das hätte gehen sollen, denn irgendwie müsste ja der Rechnername über den Browser ausgelesen werden, und das ist ja aus Sicherheitsgründen schon nicht möglich, MS fackelt das ja zum Großteil alles über JavaScript ab.

Gut dann ist das geklärt.

Zitat von @colinardo:
Hätte mich auch eigentlich schwer gewundert wie das hätte gehen sollen, denn irgendwie müsste ja der Rechnername über den Browser ausgelesen werden müssen, und das ist ja aus Sicherheitsgründen schon nicht möglich, MS fackelt das ja zum Großteil alles über JavaScript ab.

Aber der Webserver könnte wenigstens weitergeben, von welcher IP-Adresse die Sitzung hergestellt wurde.

Zitat von @emeriks:
Aber der Webserver könnte wenigstens weitergeben, von welcher IP-Adresse die Sitzung hergestellt wurde.

Ja, das wäre eine Möglichkeit, aber eben Hostname ungleich IP ... sicher die könnte er auflösen "wenn" er denn nur wollte, würde aber zumindest von extern keine verlässlichen Ergebnisse liefern.

Zum Glück hat sich das noch geklärt. Ich hab langsam echt gezweifelt.

@uwe ich schau mir jetzt gleich dein Script an. Vielen Dank noch mal!

Hallo Uwe,

funktioniert einwandfrei.
Du bist der Beste.

German solved Question Batch, Shell Development

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments