8
RDWebclient - was läuft hier auf dem Webserver falsch?
Servus IIS-Admins.
Ich habe auf einem Terminalserver den RDWebclient installiert.
Dessen Startseite sollte die Browsersprache erkennen und die Buttons in angepasster Sprache anzeigen - tut sie aber nicht.
Ich zeige Euch einen zweigeteilten Screenshot, links, wie es aussieht (Produktivsystem) und rechts, wie es aussehen soll (Testsystem).
Ich kann das mit allen supporteten Browsern nachstellen und es tritt ebenso auf, wenn ich mich am Server zu localhost verbinde.
Hat jemand eine Idee, woran das liegen mag?
Ich habe auf einem Terminalserver den RDWebclient installiert.
Dessen Startseite sollte die Browsersprache erkennen und die Buttons in angepasster Sprache anzeigen - tut sie aber nicht.
Ich zeige Euch einen zweigeteilten Screenshot, links, wie es aussieht (Produktivsystem) und rechts, wie es aussehen soll (Testsystem).
Hat jemand eine Idee, woran das liegen mag?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5976789628
Url: https://administrator.de/forum/rdwebclient-was-laeuft-hier-auf-dem-webserver-falsch-5976789628.html
Ausgedruckt am: 12.04.2025 um 17:04 Uhr
8 Kommentare
Neuester Kommentar
Servus DWW,
scheint als fehlen das Übersetzungs-Resourcen für die eingestellte Sprache
Verschaff dir mal Zugang zu folgendem Verzeichnis:
Darin sollten Ordner in den Sprachen (en_US/de_DE/etc.) vorhanden sein in denen ein JSON File (strings.json) mit den Übersetzungs-Strings liegen. In diesem File liegt dann bspw. der Übersetzungsterm mit der Übersetzung in der jeweiligen Sprache
Grüße Uwe
scheint als fehlen das Übersetzungs-Resourcen für die eingestellte Sprache
Verschaff dir mal Zugang zu folgendem Verzeichnis:
C:\Program Files\RemoteDesktopWeb\Internal\Clients\hn2mzg0y.grf\content\assets\loc"ALL_RESOURCES_TAB_LABEL": "Alle Ressourcen", 
Hallo Uwe.
Diese Dateien sind auf beiden Systemen identisch vorhanden, Zugriffsrechte ebenso identisch.
Diese Dateien sind auf beiden Systemen identisch vorhanden, Zugriffsrechte ebenso identisch.
Schau mal ob in der Browser-JavaScript Konsole (F12) Fehler auftauchen. IIS Logs hast du geprüft?
1
In der Konsole kommt z.B.
Auf dem Server selbst kommt bei Eingabe von https://servername.dom.local/RDWeb/webclient/assets/loc/en-US/strings.js ... ein 404.3 not found
Detaillierte Fehlerinformationen:
Modul StaticFileModule
Benachrichtigung ExecuteRequestHandler
Handler StaticFile
Fehlercode 0x80070032
Angeforderte URL https://servername.dom.local:443/RDWeb/webclient/assets/loc/en-US/string ...
Physischer Pfad C:\Program Files\RemoteDesktopWeb\Internal\Clients\xktb2f1b.pf1\content\assets\loc\en-US\strings.json
Anmeldemethode Anonym
Benutzeranmeldung Anonym
Lasse ich den Browser diese json-Datei über control-O öffnen, funktioniert das.
IIS-Logs schaue ich mir noch an.
/RDWeb/webclient/assets/loc/en-US/strings.json:1
Failed to load resource: the server responded with a status of 404 ()
Failed to load resource: the server responded with a status of 404 ()
Auf dem Server selbst kommt bei Eingabe von https://servername.dom.local/RDWeb/webclient/assets/loc/en-US/strings.js ... ein 404.3 not found
Detaillierte Fehlerinformationen:
Modul StaticFileModule
Benachrichtigung ExecuteRequestHandler
Handler StaticFile
Fehlercode 0x80070032
Angeforderte URL https://servername.dom.local:443/RDWeb/webclient/assets/loc/en-US/string ...
Physischer Pfad C:\Program Files\RemoteDesktopWeb\Internal\Clients\xktb2f1b.pf1\content\assets\loc\en-US\strings.json
Anmeldemethode Anonym
Benutzeranmeldung Anonym
Lasse ich den Browser diese json-Datei über control-O öffnen, funktioniert das.
IIS-Logs schaue ich mir noch an.
IIS Log bei lokalem Zugriffsversuch:
2023-02-14 13:51:44 #serverIP# GET /RDWeb/webclient/assets/loc/en-US/strings.json - 443 - #serverIP# Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/110.0.0.0+Safari/537.36+Edg/110.0.1587.41 - 404 3 50 7
Yeehaww!
DIe Lösung ist: .json muss als mimetype zugeordnet werden wie folgt:
<mimeMap fileExtension=".json" mimeType="application/json" />
einfügen in C:\Program Files\RemoteDesktopWeb\Internal\Clients\xktb2f1b.pf1\content\web.config
Neuer Inhalt ist somit:
Anmerkung: Auf Server 2016 funktioniert das out-of-the-box. Unser 2016er war jedoch upgegradet von 2012R2 und da scheint es dieses Problem zu geben.
DIe Lösung ist: .json muss als mimetype zugeordnet werden wie folgt:
<mimeMap fileExtension=".json" mimeType="application/json" />
einfügen in C:\Program Files\RemoteDesktopWeb\Internal\Clients\xktb2f1b.pf1\content\web.config
Neuer Inhalt ist somit:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<defaultDocument>
<files>
<clear/>
<add value="index.html" />
</files>
</defaultDocument>
<staticContent>
<mimeMap fileExtension=".cer" mimeType="application/pkix-cert" />
<mimeMap fileExtension=".json" mimeType="application/json" />
</staticContent>
</system.webServer>
<location path="index.html">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN"/>
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
</configuration>Anmerkung: Auf Server 2016 funktioniert das out-of-the-box. Unser 2016er war jedoch upgegradet von 2012R2 und da scheint es dieses Problem zu geben.
OK, das war das Stichwort (Server Version 2016). Auf den neueren IIS ist der Mimetype in der DefaultSite schon vorhanden und wird vererbt. Am besten du setzt das gleich auf Site-Level statt nur in der Webconfig der Anwendung sonst fällt dir das irgendwann wieder auf die Füße 
.
.
Guter Tipp. Wie immer: vielen Dank, Uwe!
