Mister_M 0 Geschrieben 7. April Melden Geschrieben 7. April Hallo zusammen, wir haben ein sehr merkwürdiges Problem und bisher noch keine Lösung dazu finden können, vielleicht hat einer von Euch noch eine Idee. Ich skizziere mal kurz die Umgebung und seit wann das Problem auftritt. Seit mehreren Jahren haben wir schon einen Terminalserver (Server 2022) als Blechkiste erfolgreich am laufen, die User haben sich immer direkt mit der IP der Kiste verbunden, noch nie Probleme damit gehabt. (ca 30 User insgesamt) Letztes Jahr wurde dann eine neue Bleckiste angeschafft da immer mehr User auf den TS mussten und die Performance des bisherigen TS dafür nicht mehr ausgereicht hat. Auf dem neuen Server läuft Windows Server 2025, auch hier konnten sich die User immer ohne Probleme verbinden. Ein Teil der User sitzt in unseren Außenbüros, an den "lokalen" Rechnern melden sich die User ganz normal mit Ihrem AD-Account an, und dann mittels Desktopverknüpfung gehen sie auf den TS. Die User die von zu Hause aus arbeiten, haben von uns Laptops bekommen die in der Domäne sind, die User melden sich aber an dem Laptop mit einem lokalen Benutzer an (dieser hat nichts mit dem Domänenuser zu tun), starten eine VPN Verbindung und dann mittels Desktopverknüpfung die Terminalserververbindung. Hier geben Sie in den Verbindungsdetails ihren Domänenbenutzer und das persönliche Kennwort ein. Ganz normale Kerberos-Verbindung ohne Zertifikat etc. Unser Systemhaus meinte dann, das es performanter und ausfallsicherere sei, wenn man auf der neuen Blechkiste nicht direkt arbeitet, sondern dort mittels Hyper-V zwei virtuelle TS installiert und dann mit einem RDS-Broker die Verteilung der User auf die einzelnen TS managen lässt. Wir haben also den "alten" TS (mit Server 2022), und die beiden neuen virtuellen TS (Server 2025) in den RDS-Pool aufgenommen. Das klappt soweit auch, die User melden sich an, der Broker entscheidet auf welchen TS der User landet. Allerdings haben wir das Problem das seit dem wir das mit dem RDS-Broker machen, am Tag 2-3 User die Meldung bekommen "0x0 - ein interner Fehler ist aufgetreten" sobald sie sich mit dem TS verbinden wollen. Wir haben bisher schon folgendes herausgefunden: 1. Der Fehler tritt erst auf seitdem wir den RDS-Broker verwenden 2. Der Fehler tritt nur auf wenn die User sich mit den 2025er TS verbinden, wir haben testweise mal nur die Anmeldung an dem 2022er erlaubt, da kam niemals die Meldung 3. Der Fehler tritt immer nur bei Usern auf die über die Laptops sich verbinden wollen 4. Der Fehler tritt nicht immer auf, es sind auch immer andere User davon betroffen 5. Wenn der Fehler auftritt, und der User ein paar Minuten wartet, geht es meistens dann irgendwann. Was haben wir bisher schon probiert? Mittels GPO auf den TS "Client connection encyrption level" auf "Client compatible" gestellt Die Option "Verbindung nur von Computern zulassen auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird", deaktiviert Auf dem Client-Notebook finden wir zu dem Zeitpunkt folgenden Fehler: Wenn jemand noch eine Idee haben sollte, gerne her damit.... Wir sind mittlerweile am verzweifeln und wissen nicht was wir noch tun sollen, ausser das wir das Konstrukt mit dem RDS-Broker wieder rausnehmen und die USer sich "direkt" auf den TS verbinden. Vielen Dank und Grüße Mister_M
testperson 1.997 Geschrieben 7. April Melden Geschrieben 7. April Hi, was findet sich auf dem Broker und Terminalserver zu diesem Zeitpunkt im Eventlog unter Anwendungs- und Dienstprotokolle -> Microsoft -> Windows-TerminalServices -> SessionBroker / SessionBroker-Client -> Admin/Client. Generell halte ich gemischte Betriebssysteme der Session Hosts (2022 / 2025) in einer Sammlung für suboptimal. Gruß Jan
Mister_M 0 Geschrieben 7. April Autor Melden Geschrieben 7. April (bearbeitet) Hallo Jan, sowohl auf dem Broker als auch auf dem TS sind in dem Protokoll keinerlei Einträge zu finden! Auf dem Client ist wieder der Netlogon-Fehler zu finden, zu dem Zeitpunkt war der User aber schon mit VPN verbunden, das habe ich im Log-File gesehen: Kann das die Ursache für das Problem sein? Dagegen spricht aber ja, das dass Problem erst seit dem RDS-Broker-Konstrukt auftritt und auch nur wenn der User sich mit dem 25er Server verbinden will.... Ja, eigentlich will ich ja auch nur noch die 2025er Server in Betrieb haben, aber solange das Problem nicht gelöst ist, muss der alte Server noch durchhalten. bearbeitet 7. April von Mister_M
Sunny61 853 Geschrieben 7. April Melden Geschrieben 7. April Wenn man via sich via IP zu Systemen verbindet, wird AFAIK KEIN Kerberos verwendet. Schau dir auch mal diesen Artikel an: https://www.gruppenrichtlinien.de/artikel/rdp-ohne-ntlm-richtlinien-und-verhaltensweisen-zur-reduktion-von-ntlm vor 2 Stunden schrieb Mister_M: Der Fehler tritt immer nur bei Usern auf die über die Laptops sich verbinden wollen Weshalb auf den Domänen Laptops keine Domänenuser verwenden? Es spricht nichts dagegen. Eine einmalige Anmeldung des Users am Laptop gegen den DC, ab dann kann das Gerät offline sein. Wie im o.g. Artikel zu finden ist, immer mit dem FQDN innerhalb der Domain arbeiten.
Mister_M 0 Geschrieben 8. April Autor Melden Geschrieben 8. April Hallo Sunny61, das wäre doch schonmal ein Hinweis... Wir schauen das wir bei den Geräten jetzt mal anstelle der IP-Adresse den FQDN verwenden... Sobald es was neues gibt, melde ich mich hier....
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden