RDP Verbindung schlägt nach reboot fehl (Server 2019 Sitzungssammlung)

[KistersSolutions 2]

Hallo zusammen,

folgendes Szenario, ein RDP Sitzungssammlung (Server 2019) bestehend aus 3 Servern wurde aufgrund von Windows Updates neugestartet.

Nach diesem neustart der Server erhalten alle Windows 10 Clients folgende Meldung:

 

 

Die RDP Dienste laufen auf allen Servern, die Anmeldung auf die Console über mstsc /admin ist auch möglich.

Die User haben weiterhin die entsprechenden rechte. Auch wenn ich die Sicherheitsstufe auf RDP stelle oder auf aushandeln und

die Verschlüsselungsstufe auf niedrig ist keine Verbindung mehr möglich.

 

Ich habe schon diverse Support Artikel gelesen allerdings brachte keine den gewünschten Erfolg.

 

 

bearbeitet 20. Juli 2021 von KistersSolutions

[Nobbyaushb 1.484]

Ist der Server noch in der Domäne?

 

Das passiert neuerdings gerne wieder mal nach einem reboot, das der in einem öffentlichen LAN landet und somit die Firewall die Verbindung blockt.

 

IPv6 aus und wieder an oder den Dienst NLA neu starten behebt das Problem, wir machen das mittlerweile per geplantem Task nach reboot

 

[KistersSolutions 2]

vor 3 Stunden schrieb Nobbyaushb:

Ist der Server noch in der Domäne?

 

Das passiert neuerdings gerne wieder mal nach einem reboot, das der in einem öffentlichen LAN landet und somit die Firewall die Verbindung blockt.

 

IPv6 aus und wieder an oder den Dienst NLA neu starten behebt das Problem, wir machen das mittlerweile per geplantem Task nach reboot

 

Hi,

ja alle drei Servern sind auch Domänen Member, beides Tips haben aber leider nicht geholfen.

Weitere ideen?

 

Gruß Tim

[tsaenger 13]

Guten Abend

ich habe ähnliches Problem und ein Ticketbei ms eröffnet. momentanstellte ich fest das ich auf dem sessionhost den rdp-dienst beenden musste. Anschließend musste ich mich 2 mal über hyperV anmelden. Beim ersten mal werde ich direkt wieder abgemeldet. beim 2 mal klappt es und die user können wieder arbeiten. Das ist keine Lösung und ich hoffe MS findet das Problem.  Sindfast 3 Wochen schon dran.

Grüße Tobias

 

[Weingeist 159]

Ist echt ein Problem. War zwischenzeitlich mal weg, dann kam es vermehrt mit VM's wieder und aktuell ist es wieder Up To date

 

- Zwischenzeitlich hat es mal oft geholfen einfach den nla auf "automatisch verzögert" statt "automatisch" zu stellen. Klappt aber nicht immer und nicht auf jeder Maschine.

- Meisten hilft es nla neu zu starten sobald die Maschine oben ist (wie bereits genannt wurde)

- Hilft es nicht nla neu zu starten, muss Netzwerkadapter aktiviert und wieder deaktiviert werden (auf neueren OS relativ easy per Powershell zu automtisieren)

 

Meine Vermutung geht so in Richtung von nicht aufgeräumten Netzwerkadaptern, Treiberprobs oder Load-Reihenfolge, insbesondere nach bestimmten Updates. Bei den Treibern/Firmware habe ich das insbesondere bei Intel-Karten festgestellt. Auf einer physischen Maschine hatte ich auch schon AMT in Verdacht das während dem Boot den Adapter blockiert und Windows ihn nicht genügend schnell bekommt oder so.

Auf Neuinstallierten VM's tritt es normal nicht auf - meist bis zur Einspielung von bestimmten Updates.

Hatte mir mir mal spasseshalber die Mühe genommen auf einer Maschine alles rauszukicken was irgendwie auffindbar war bezüglich Netzadapter. Sämtliche GUID's in der registry zu durchforsten usw. Danach war das Problem auf dieser Maschin weg und kam auch nicht wieder.

ABER: das müsste auf den Netzwerkkartenanbieter, das Gerät selbst usw. angepasst werden. Alles ziemlich unbrauchbar für die Automation. Und ob das aktuell auch tut weiss ich nicht, vor ein paar Jahren war es ein ganz bestimmtes Update welches den Ärger auf VM's reproduzierbar verursacht hat weil irgendwie Netzwerkadapter neu eingeladen  wurden aber der Alte nicht sauber entfernt (bekamen auch neue MAC's)