Ich habe mir in den letzten Tagen den Kopf darüber zerbrochen. Ich habe einen Server 2012-Remotedesktop wie folgt eingerichtet:
- 1 Gateway-Server
- 1 RD Web Access-Server
- 1 Session Broker, der gleichzeitig Session Host ist
- 1 Zusätzlicher Sitzungshost
Ich verwende Remote-Apps, um Anwendungen statt Desktops zu veröffentlichen. Ich habe ein Wildcard-Zertifikat für die externe Domäne, das für das Gateway und den Webzugriffsserver einwandfrei funktioniert. Das Problem liegt bei den Sitzungshosts, die mir einen Zertifikatsfehler melden, da Verbindungen zum internen Namen (einer .local-Adresse) hergestellt werden, der offensichtlich nicht mit dem externen Zertifikat übereinstimmt.
Ich habe eine DNS-Zone für den externen Namen in dieser Domäne eingerichtet, sodass Maschinen anhand interner oder externer Namen aufgelöst werden können.
Ich habe einige Fortschritte gemacht, indem ich die Schritte befolgt habeHier, und jetzt funktioniert alles einwandfrei, wenn ich nur den Sitzungshost aktiviert habe, der auch der Broker ist. Sobald ich den zweiten Sitzungshost hinzufüge, erhalten alle an diesen gerichteten Anfragen den Zertifikatsfehler. Verbindungen zum ersten Sitzungshost funktionieren weiterhin einwandfrei.
Kennt jemand eine Möglichkeit, Anfragen an den externen Namen des Sitzungshosts zu richten?
Antwort1
Die einzige Lösung, die ich dafür gefunden habe, besteht darin, Session Broker HA zu konfigurieren (obwohl wir nur einen Broker haben) und den DNS-Round-Robin-Namen auf einen (externen) Hostnamen festzulegen, den Sie im Zertifikat haben. Denken Sie daran, dass Sie hierfür SQL benötigen und dass Sie nach der Aktivierung nicht mehr in den Nicht-HA-Modus zurückkehren können.
Antwort2
Was passiert, wenn Sie das Zertifikat für den defekten Server löschen und ein zweites (lokales) Zertifikat vom Broker an die Hosts ausstellen? Das ist dem SSL-Problem mit Load Balancern ziemlich ähnlich.