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?
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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 543954
Url: https://administrator.de/forum/w2k16-terminal-server-remote-desktop-webclient-clientname-abfragen-543954.html
Ausgedruckt am: 10.04.2025 um 21:04 Uhr
84 Kommentare
Neuester Kommentar
Hi,
Ja, ist doch richtig. Du musst doch auch den Clientnamen abfragen.
$env:CLIENTNAME
E.
Edit:
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?
Ja, sicher. Und ich frage auch aus einem bestimmten Grund. Und Du hast mir jetzt bestätigt, dass es sich um ein LoginScript handelt. 
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).
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).
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?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.

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.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.
Musst du wohl mal dein RD Webclient auf dem Server aktualisieren, hast du das schon getan?

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 ...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?
@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...?
Edit: ok, wenn ich's mir recht überlege... er hat ja Linuxclients, da braucht er das Ding doch! Oder...?

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.@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...?
Nur wenn er keine Anwendung hat die *.rdp Files nutzen und damit eine RDP Session aufrufen kann.
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.
Weiter oben sagtest Du noch, dass es keinen Unterschied zu 2016 machen würde.
Lesen ist nicht so meine Stärke. 

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.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!
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.Falsche Herangehensweise, wie DerWoWusste schon sagt, mappe den Usern ihre Drucker so wie es vorgesehen ist.
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.

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.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.
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 ?

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 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?
Meine Testumgebung wird regelmäßig auf einen cleanen Snapshot zurückgesetzt, das war auch bei meinen obigen Tests der Fall.Auch auf diesem wurde die Variable nicht befüllt.
Hat von euch jemand die Möglichkeit einer neuen Testinstallation?

Tach auch.
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ß
Zitat von @joe2017:
Vielleicht mache ich auch etwas falsch?
Meine Installationsschritte:
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ß

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!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.
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.
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).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?
Nein ist er nicht.
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.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?
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 
Ja, Für Zertifikate wird eine AD CA benutzt.
Installation der RD Rollen statt quick, custom.
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.Ich wüsste nicht was in meinem Fall anders sein sollte?

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

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
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.
Dann belese dich dazu mal
Use PowerShell to Interact with the Windows API: Part 1
Use PowerShell to Interact with the Windows API: Part 1
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
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
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.Genau das habe ich gesucht! Jetzt muss ich nur noch prüfen, ob der Benutzer (Domain User) diese Information auslesen darf.
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.Du meinst das ich für dieses Log ein Task hinzufüge und somit ein Programm (powershell script) starte.
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
}
}
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}
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.
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.Oder erstellst du die Trigger manuell?
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-PfadenEvent/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><QueryList><Query Id="0" Path="Microsoft-Windows-TerminalServices-Gateway/Operational"><Select Path="Microsoft-Windows-TerminalServices-Gateway/Operational">*[System[Provider[@Name='Microsoft-Windows-TerminalServices-Gateway'] and EventID=302]]</Select></Query></QueryList></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>
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 ?
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?!@uwe:
Ich nutze ja den RD Webclient wie von dir beschrieben - warum wird mir die Variable angezeigt?
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.
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.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.
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.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.
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.Aber der Webserver könnte wenigstens weitergeben, von welcher IP-Adresse die Sitzung hergestellt wurde.