Attack44

Beim IE ist es genau das gleiche Problem bzw. endet in den selben Fehlermeldung. Der DC0 FQDN ist explizit im lokalen Intranet eingetragen. Ja richtig, ist aber eine Testumgebung. Hm vielleicht liegt es daran und ich sollte einen eigenen ADFS Server aufsetzen und es so probieren?

Wir haben hier im Standort zwei AD Server (2K16) auf einem der beiden ist die ADFS Rolle installiert, insgesamt haben wir nur diesen einen ADFS(4.0) Server. Der ADFS Dienst wird nur intern verwendet (DC0.domain.local), folgende SPN's sind für adfs hinterlegt: - HTTP/DC0.domain.local/domain.local - HTTP/DC0 - HTTP/DC0.domain.local Die User-Agents sind aktuell wie folgt konfiguriert: In Firefox ist unter network.automatic-ntlm-auth.trusted-uris DC0.domain.local eingetragen. Ansonsten ist in den Internetoptionen DC0.domain.local bzw *.domain.local in "Lokales Intranet" eingetragen und "Automatische Anmeldung mit aktuellem Benutzernamen und Kennwort" aktiviert. Firefox 82.0.2 Google Chrome 86.0.4240.183 Microsoft Edge 86.0.662.63 Gruß Andreas

Sagen wir mal so, ich denke schon, ich habe verschiedene Einstellungen getätigt die man im Netz für die WIA findet, kann ich das im Browser "mitschneiden" ob dort die WIA funktioniert? Ich habe hier die aktuelle Version vom Chrome, Edge und Firefox im Einsatz bzw. getestet. Wenn ich auf dem AD FS nur die "Windows-Authentifizierung" aktiv habe, erhalte ich folgende Fehermeldung im Log: Heißt das, dass der Fehler im Browser liegt und die WIA aktuell nicht unterstützt? Andreas

@NorbertFe Kann man das mit den Entwicklertools der Browser prüfen ob die Daten weitergereich werden? Wir haben hier eine rdweb Seite für unsere Terminalserver Sammlungen da funktioniert die WIA, ich probiere das Ganze auch mit mehreren Browsern Chrome/Edge, Firefox. @Gipsy Ja die hatte ich angepasst, ich habe jetzt aber die von Deinem Link übernommen, da dort einige mehr drin waren. Leider ohne Erfolg. Gruß Andreas

Hallo, wir nutzen für eine Webanwendung SAML zur Authentifizierung, was auch ohne Probleme funktioniert, das ganze läuft über AD FS (Active Direcotry-Verbunddienste). Aktuell ist es so, das der Benutzer von der Webanwendung zur ADFS Login Seite weitergeleitet wird, nach der Anmeldung wird er dann zurück zur Webanwendung geleitet und ist angemeldet. Und nun wollte ich gerne, dass der Benutzer auf der ADFS Login Seite seine Login Daten nicht mehr initial eingeben muss, sondern automatisch über WIA angemeldet wird und damit habe ich ein Problem. Ich bekomme es nicht hin, das auf der ADFS Login Seite WIA funktioniert, ich habe schon mehrere Anleitungen durchgeforstet, alle ohne Erfolg. Hätte da jemand ein Tipp wo das Problem liegen könnte? https://support.classlink.com/hc/en-us/articles/360010601593-ADFS-Windows-Integrated-Authentication-WIA- Gruß Andreas

Ich habe das Problem nun gelöst bekommen, an den IGEL Thin-Clients müssen für die Datev Smartcards die Middleware auf "OpenSC" eingestellt sein und die Smartcards dürfen nicht in die RDP-Sitzung weitergeleitet werden. Sprich ich habe die USB-Weiterleitung für Smartcards deaktiviert. Nun werden sie ohne jegliche Fehler erkannt und das auch bei 2012R2. Gruß Andreas

Hast Du dazu nähere Infos? Wir hatten das jetzt mal weiter getestet, auf den Datev Terminalserver ist das Sicherheitspaket 6.1 installiert und probeweise haben wir hier ein Terminalserver mit 2016 mit dem Sicherheitspaket compact 6.41 versehen. Dort wird jetzt zumindest die Datev Smartcart ohne Probleme erkannt. Gruß Andreas

Wie meinst Du das genau? Die Sticks/SmartCards haben bei uns keine speziellen Berechtigungen an den Clients bekommen, es wurde nur in der RDP Datei eingestellt, dass SmartCards weitergeleitet werden sollen. Gruß Andreas

Wir haben hier Igel UD2 ThinClients im Einsatz. RemoteFX ist auch aktiviert, sprich die Weiterleitung von normalen USB-Sticks und Scannern und Kameras funktioniert auch bei normalen Benutzern. Gruß Andreas

Hallo, wir haben hier einen Terminalserver (2012 R2) wo die Benutzer auch mit DATEV arbeiten. Aktuell haben die Benutzer noch normale Windows 10 Clients wo dann nur eine RDP Sitzung geöffnet wird. Zudem haben die Benutzer eine "DATEV mIDentity compact" SmartCard welche sie für Datev benötigen. Aktuell wird die SmartCard in die RDP Sitzung durchgereicht und es funktioniert alles ohne Probleme. Nun wollten wir aber langsam auch in der Buchhaltung auf ThinClients umsteigen und da haben wir nun ein Problem mit der Datev SmartCard. Wenn sich nun der Benutzer über den ThinClient am Terminalserver anmeldet, wird auch die SmartCard durchgereicht, sprich ich sehe sie unter Geräte-Manager und Geräte und Drucker und alles ohne Ausrufezeichen oder sonst was, aber Datev wiederum sagt das er keine SmartCard finden kann. Zuerst kam natürlich die Vermutung auf, dass es am ThinClinet liegt, da es ja sonst bei den W10 Clients ohne Probleme Funktioniert. Aber das komische ist ja, die SmartCard wird ja korrekt in Windows angezeigt. Wenn ich mich jetzt aber als Administrator auf den ThinClient anmelde und eine Sitzung zum Terminalserver aufbaue funktioniert die SmartCard auch in Datev, also Datev zeigt mir alle Daten auf der SmartCard an. Nach weiterer Recherche bin ich auf folgende Fehlermeldung gestoßen, wenn man sich als Benutzer über den ThinClient anmeldet (siehe Anhang). Kann das vielleicht ein Rechteproblem sein? Gruß Andreas

Hallo, ich habe ein kleines Problem wo ich einen Denkanstoß bräuchte. :) Wir haben bei uns eine 2016 Terminalserver Farm wo man sich über IGEL Thin-Clients anmeldet/arbeitet. RemoteFX/USB-Weiterleitung ist aktiviert und verfügbar, dies funktioniert auch so ohne Probleme. Scanner, Kameras oder USB-Sticks werden erkannt und installiert, diese sind dann auch gut unter Geräte und Drucker zu sehen, aber ich habe das Problem, dass auch der richtig installiere USB-Stick der unter Geräte und Drucker angezeigt wird, keinen Laufwerksbuchstaben erhält und somit der Benutzer nicht zugreifen kann. Wenn ich nebenbei als Admin auf den Server schaue, sehe ich in der Datenträgerverwaltung auch kein weiteres Laufwerk. Ist der USB-Stick unter der Datenträgerverwaltung nur pro Benutzer sichtbar bzw. wie kann man es lösen, das der USB-Stick auch ein Laufwerksbuchstaben bekommt? Edit: Wenn ich mich als Admin über die Thin-Clients anmelde, wird dem USB-Stick ein Buchstabe zugewiesen. Gruß Andreas

Vielen Dank @testperson und @DocData, hier habt mir sehr geholfen.

Entweder habe ich es übersehen, aber der Link hilft mir nicht wirklich weiter. In den Bereitstellungeigenschaften finde ich den "DNS-Name für den RD-Verbindungsbrokercluster" (vs-rds.firma.local) und wenn ich mich über den versuche über RDP anzumelden lande ich direkt auf einen der Verbindungsbroker und nicht auf den Sitzungshost Servern. Gruß, Andreas

Hallo, ich habe ein kleines Problem bzw. eine Verständnisfrage bezüglich des Farmanmes einer RDS-Farm. Wir haben hier u.a. drei Sitzungshost Server und zwei Verbindungsbroker (Hochverfügbarkeitsmodus) im Einsatz, sagen wir mal, der RD-Verbindungsbrokercluster heißt vs-rds.firma.local. Wenn ich über einen WebAcces Server die .rdp Datei runterlade und starte, verbinde ich mich ordnungsgemäß, da besteht überhaupt kein Problem, DNS/Zertifikate sind alle soweit richtig eingerichtet. Aber wie mache ich das, wenn ich mich auf einen Desktop der drei Sitzungshost Server verbinden möchte, also nicht über die RemoteApp sondern auf dem Desktop eines Sitzungshosts (es spielt keine Rolle auf welche ich lande)? Wenn ich z.B. mich auf einen Sitzungshost direkt verbinden möchte, kommt ja folgende Meldung (siehe Anhang) und über "vs-rds.firma.local" versucht er sich direkt auf einen der Verbindungsbroker anzumelden. Was ist denn nun mit dem Farmnamen gemeint bzw. wie kann man das richtig konfigurieren? Gruß, Andreas

Den 1803 Client habe ich leider schon wieder gelöscht, weil ja eigentlich alles ging, naja ich werde mit 1803 nicht weiter probieren, da diese Version bei uns nichts zum Einsatz kommt. Komischerweise werde ich jetzt wieder nach einem Kennwort gefragt, wenn ich den Feed manuell hinzufügen möchte... Ich finde dieses Ding zu unausgereift, es ist an sich eine gute Idee, aber schlecht umgesetzt. Ich werde die RemoteApps den Usern auf anderen Wege zur Verfügung stellen, wo ich was das es dauerhaft funktioniert. Vielen Dank für Hilfe nochma. :)

Das hier ist ein W10 1809 System, ob das über die Aufgabenplanung funktioniert muss ich nochmal schauen, aktuell wollte er mir die Aufgabe über GPO am Client nicht eintragen. Aber wenn ich das direkt über PowerShell ausführe: Start-Process rundll32 -ArgumentList "tsworkspace,TaskUpdateWorkspaces2" oder %SYSTEMROOT%\System32\RUNDLL32 tsworkspace,TaskUpdateWorkspaces2 Läuft rundll32 ca. 20min und danach wird der selber Fehler wie oben ausgespuckt.

Ein Problem ist mit der Zeit jetzt doch noch aufgetaucht, die automatische Aktualisierung der RemoteApp- und Desktopverbindungen schlägt fehl (siehe Anhang). Ich habe gesehen, dass es daran liegen kann wenn der Benutzer keine lokalen Admin Rechte besitzt (was bei uns der Fall ist). Daraufhin habe ich das hier im Netz gefunden: https://social.technet.microsoft.com/Forums/de-DE/5205e5b7-bbce-4e4d-86a6-ffae778835d2/remoteapp-gpo-is-not-applying-for-users-without-local-admin-access?forum=winserverTS Ziemlich weit unten findet sich ein Beitrag von Prosvetov Roman der eine Lösung vorschlägt. Daraufhin habe ich die betreffenden Ordner/Aufgaben in der Aufgabenplanung gelöscht und das Script wurde angewendet, nur leider schlägt die Aktualisierung immer noch fehl. Startet man nun die Aktualisierung nun von Hand, läuft diese ohne Fehler durch.

Wie sagt man so schön, kaum macht man es richtig, funktioniert es. Kleine Ursache, große Wirkung. Vielen Dank für den Hinweis, so wie es aussieht funktioniert nun alles. :) Danke für die Hilfe.

So, das Problem ist jetzt nun "halb" gelöst, ich habe in der IIS Konfiguration noch etwas angepasst bzw. etwas aktiviert (siehe Anhang), nun kann ich unter "RemoteApp- und Desktopverbindungen" den Feed ohne Fehlermeldung/Passworteingabe hinzufügen. Aber aktuell habe ich noch das Problem, dass ich den Feed über die GPO nicht eingetragen bekomme, es wird folgender Fehler im Ereignisreicher abgelegt (siehe Anhang).

Ich hatte zum Test ein nacktes W10 1803 verwendet, der Client und der User waren in einer OU ohne Vererbung, genau das gleiche Spiel wie bei den anderen Clients/Versuchen. Es erscheint die Anmeldemaske mit der Info das die Anmeldedaten falsch sein. Es erscheint mir so, dass wenn ich auf die URL über "RemoteApp- und Desktopverbindungen" zugreife, er die Anmeldedaten nicht weitergibt. Ich habe mal versucht, den Netzwerkverkehr zwischen Client und Server mitzuschneiden, wenn ich die URL/Feed über den Browser aufrufe, kommt folgende Meldung: 401 - Nicht autorisiert: Zugriff aufgrund ungültiger Anmeldeinformationen verweigert. Die angegebenen Anmeldeinformationen berechtigen Sie nicht, dieses Verzeichnis oder diese Seite anzuzeigen. Und ddarauf folgt die Meldung dass ein Login erfolgt ist (über den Brwoser), gehe ich nun über "RemoteApp- und Desktopverbindungen" erscheint die obrige Fehlermeldung auch, aber es passiert nichts weiter (Anmeldemaske ist ja nun auf).

Bei mir nicht, ich habe hier jetzt ein neues 1803 System, endet leider mit derselben Fehlermeldung.

vorhergehende Ja habe ich, mit allem was man denke ich so macht, auch mit diesen SHA1-Zertifikatfingerabdrücken. Zuvor wo das Zertifikat noch nicht vorhanden war, konnte ich die Einrichtung unter RemoteApp- und Desktopverbindungen auch nicht abschließen, jetzt geht es ja, nur halt händisch. P.S. Auch wenn ich z.B. in der Anmeldemaske beim Anlegen des Feeds auf Anmeldedaten speichern klicke und es danach nochmal hinzufüge (nach vorhergenden entfernen), kommt als erstes die Meldung, dass die Anmeldedaten falsch sein (obwohl nun was unter Systemsteuerung -> Anmeldeinformationsverwaltung hinterlegt wurde).

Die Sicherheitseinstellungen sind so wie bei Dir im Bild eingestellt, ich hatte mal bei Sicherheitsstufe auf "Aushandeln" festgelegt, aber das hatte keine Auswirkung. Ja, der Testuser ist Admin. Hm dann schaue ich mal nach einem Win10 1803 wie es sich da verhält.

Die Standardverbindungs URL ist wie schon oben geschrieben in der Benutzerkonfiguration hinterlegt und zeigt auf den Server wo Web Access Rolle installiert ist, der Connection Broker hostet ja den Feed nicht, zumindest ist das jetzt meine Auffassung. Ach so, Du meinst die Sammlung, ja dort sind die entsprechenden User hinterlegt/berechtigt und Apps gibt es auch schon. Ich kann sie ja aus dem Browser per SSO starten und verwenden.

Meinst Du mit der erlaubten Gruppe/User unter Systemeingenschaften -> Remote -> Remotedesktop? Im Sitzungshost habe ich die entsprechenden Gruppen hinterlegt, beim Connection Broker nicht bzw. mal getestet und dann wieder rausgenommen. Die "Delegierung von Standardanmeldeinformationen" habe ich aktuell zum Test so eingestellt (siehe Bild), ich hatte zuvor auch die anderen Einstellungen aktiviert/zugefallen die dort zur Verfügung standen, leider ohne Erfolg. Den Feed habe ich unter "Benutzerkonfiguration/Windows-Komponenten/Remotedesktopdienste/RemoteApp- und Desktopverbindungen" hinterlegt. Ich habe hier aktuell nur W10 1809 zur Verfügung, wo es später auch funktionieren soll. In der Ereignisanzeige ist auch folgender Fehler abgelegt (siehe Foto), aber wie gesagt, kopiere ich mir die URL z.B. aus der Ereignisanzeige und trage sie unter "RemoteApp- und Desktopverbindungen" ein, erhalte ich darauf ein eine Anmeldemaske mit der Info das der/das Benutzername/Passwort falsch ist, gebe ich drauf meine Logindaten ein, wird alles erfolgreich eingerichtet.