Mister_M

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

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.

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

Ah okay - vielen Dank. Da diese Ereignisse bei mir nicht zu finden sind, muss ich wohl erstmal die Überwachungsrichtline in den GPPs aktivieren.... Vielen Dank erstmal

Halo zusammen, kann man irgendwo herausfinden, wer bzw. von welchem Computer aus ein AD-Benutzerkennwort geändert wurde? Bei einer Kennwortfalscheingabe wird ja ein Event generiert in dem auch der Computername drin steht von wo aus das falsche Kennwort eingegeben wurde. Gibt es das auch bei erfolgten Kennwortänderungen? Vielen Dank Mister_M

Also über gpresult sehe ich auch nur, das meine GPO welche den Chrome startet, abgelehnt wurde, was ja auch korrekt ist. Eingestellt in der Richtlinie habe ich das ganze über "Benutzerkonfiguration\Richtlinen\AdmVorlagen\System/Anmelden\Diese Programme bei der Benutzeranmeldung ausführen". Aber, wie gesagt, diese Richtlinie scheint nicht zum Tragen zu kommen, trotzdem startet der Chrome sich. Sodele, ich hab jetzt mal per Hand den Eintrag aus der Registry gelöscht den die GPO wohl angelegt hat (Screenshot oben). Jetzt scheint es zu gehen...

Hallo zusammen, ich habe bei einem User das Problem das beim Anmelden immer der Chrome gestartet wird. Es gibt zwar bei uns eine Gruppenrichtline die den Chrome beim Anmelden startet, diese wird aber bei dem bestimmten User nicht angwendet, setht auch auf dem DC in den "Gruppenrichtlinienergebnissen" unter "Abgelehnte Gruppenrichtlinienobjekte" so drin. Mittels "autoruns" habe ich aber rausgefunden das der Chrome doch über eine Gruppenrichtline gestartet werden muss. Kann ich irgendwie herausfinden welche Richtlinie genau das Programm startet? Kleine Ergänzung was ich grade noch herausgefunden habe: Mittels RSoP habe ich bei dem bestimmten Users nichts gefunden, bei einem anderen User bei dem die Chrome Richtline angewendet wird, steht auch unter "Benutzerkonfiguration\Administrative Vorlagen\System\Anmelden" der entsprechende Eintrag drin, so wie es sein sollte. Grüße Mister_M

Hallo Pi314, bin grade über Deinen Beitrag gestolpert weil wir unter Exchange 2016 ein ähnliches Problem haben. Weisst Du noch ob/wie Ihr das Problem gelöst habt? Grüße Mister_M

Die Sache ist halt extrem komisch. Ohne RDS_Zeug ist der Speed Top. Nach den RDS-Rollen geht der Speed bei den ersten beiden Benchmarks auf 360 & 200, bei dem dritten auf 400 und die beiden letzten auf 400 runter. Dann (erst) habe ich die Energieeinstellung auf "Höchstleistung" gestellt damit ich die oberen Benchmarks bekomme. Ich schau mir mal den Beitrag von "Jan" an, ob das bei uns zutrifft. Es geht mehr um das Verständnis warum die RDS-Rolle so einen Einfluss auf die Geschwindigkeit hat ohne da schon User angemeldet sind.

Nein, auf dem TS läuft nur der ERP-Client. Dei Leute haben sich beschwert als ich bei den ersten beiden Benchmarks 200 MBps und bei den unteren drei 400 hatte. Das konnte ich lösen indem ich die Energieeinstellung auf "Höchstleistung" gesetzt habe. Mich interessiert vor allem warum die RDS Rolle den Server so extrem ausbremst, vor allem bei den drei unteren Benchmarks.

Hallo zusammen, ich habe ein relativ massives Geschwindigkeitsproblem auf meinem Terminalserver (Server 2016 Standard). Mittlerweile habe ich die "Ursache" gefunden, aber ich hätte gerne noch die Lösung dazu, hoffe Ihr könnt mir helfen. Ohne installierte RDS-Rollen ist die Geschwindigkeit in unserem ERP-System normal, das spiegelt auch der erste Screensshot wieder. Sobald ich die RDS Dienste installiere (habe es jetzt mal aufgesplittet, erst den Lizenzserver, dann den Host), geht die Geschwindigkeit in den Keller. Habe das mit dem Programm "Diskspeed" messen können. Die Voraussetzungen sind alle die gleichen, es ist kein anderer User angemedlet etc. Warum geht die HDD Geschwindigkeit (es sind übrigens Server SSDs verbaut) so in den Keller? Grüße Mister_M

Also, hier wie versprochen mal die Screenshots: Der Client/User bekommt die GPO auf jeden Fall ab. Ich werde mich dann jetzt mal mit dem debug logging beschäftigen ob ich da was rauslesen kann.

Haken bei standarddrucker ist gesetzt, die Druckerverwaltung muss ich ja nicht deaktivieren, da Win7. Screenshots setze ich mal am Montag rein

Aktuell habe ich nur Win7 Maschinen die diese GPO bekommen, es ist egal ob ich mich gleich anmelde oder nach zwei Stunden.

Ich habe alle drei Varianten (Erstellen, Ersetzen, Aktualisieren) versucht, ändert nichts am Verhalten das der Drucker zwar verbunden wird, aber eben nicht als Standard definiert. Daher kann ich auch eine noch nicht hergestellte Netzwerkverbindung als Fehler ausschließen, auch wenn ich den User abmelde, und wieder anmelde, gibt es keinen Standarddrucker. Im Eventlog habe ich keinen Eintrag gefunden der mir erklären würde, warum der Standarddrucker nicht gesetzt wird. Es ist übrigens egal, welchen Drucker ich versuche als Standarddrucker zu setzen. Schiebe ich den User in eine andere Druckergruppe im AD damit er einen komplett anderen (Standard)Drucker bekommt, bekommt er den Drucker, aber - wieder ohne Standard. Es ist fast wie verhext. Wenn "Martin" da was zu sagen kann, wäre das natürlich auch klasse... Da will man ein Problem lösen, und schafft sich drei neue.....