ITCUB

@wznutzer: Das klingt doch vernünftig. Das heist ich würde das folgendermaßen aufbauen: Hinterm Reverse Proxy (NGinx) kommt 1 VM mit dem RDS Gateway + RDWeb + HTML5. Der greift dann auf eine VM mit RDS Broker mit Lizenzserver zu, der die User dann auf 2-3 VMs als RDS Host mit FSLogix Client verteilt. Das mit dem Azure MFA klingt auch ganz gut, da der Kunde sein AD mit Azure ADConnect syncronisiert und MS365 Dienste nutzt. Was NPS ist, weis ich leider nicht. Wäre es möglich mir eine Beschreibung zukommen zu lassen, wie man das einrichtet? MfG

Hallo, die User im lokalen Netz sollen den RDP Client von Windows nutzen (desktop Verknüpfung). Die externen User sollen über den ReverseProxy auf RD-WebAccess (evtl. HTML5) kommen und von da RDP aufrufen können. (so meine Vorstellung) Das mit dem SAN habe ich verstanden. Entweder ich habe ein Zertifikat für die Subdomain, welche genauso heist wie der DNS-Name der RDS-Farm, oder ein Wildcard Zertifikat. Da der NGinx Reverse Proxy LetsEncrypt Zertifikate für die eingerichteten Subdomains verwendet, die automatisch verlängert werden, stellt sich zusätzlich mir folgende Frage. Wie kann ich automatisiert diese Zertifikate der RDS Farm zu weisen, oder muss ich herausfinden, wie ich dem NGinx gekaufte Zertifikate zuweise? MfG

Hallo Allerseits. Ich möchte das Thema auch gerne aufgreifen und meine Frage als Neuling bzgl. RDS-Farm stellen. Im Rahme des Server 2012 Support Endes wollen wir bei unserem Kunden die 2x RDS-Broker/Session Host Lösung durch eine RDS-Farm mit FSLogix ablösen. Dafür haben wir schon mal in einer DMZ einen NGinx Reverse Proxy am laufen, weshalb sich die Frage stellt, ob ich dann noch einen RDS Gateway benötige. Ich würde mir die Farm so vorstellen: 1x RDS Broker + RDS Web (falls ich auf den Gateway verzichten kann) + RDS Lizenzserver 2x RDS Session Host + FSLogix Client Ist das so praktikabel und wie mache ich das am besten mit den Zertifikaten? Mfg ITCUB

Reverse Proxy in der DMZ ist schon eingeplant.

Das wäre ein Lösungsansatz für das Zertifikatsproblem und dürfte evtl. auch beim geplanten RDS-Farm Projekt mit RDS Gateway funktionieren. Vielen Dank erst einmal. Da gebe ich Ihnen grundsätzlich Recht. Leider kenne ich da niemanden, der damit Erfahrung hat und uns, als Systemhaus kostengünstig beraten, oder unterstützen kann. MfG

Mit dem Suffix haben wir nur die Benutzeranmeldung bzgl. MS365 vereinfacht. Mir geht es darum, das wir mehrere Serverdienste für den Zugriff von Außen auf HTTPS umstellen müssen und das mit der Zertifizierung über seine jetzige interne Domäne nicht funktionieren wird. Denn der Vorbetreuer hat eine öffentliche Domain für intern verwendet. Die gehört dem Kunden aber gar nicht.

Da, nach meinen Recherchen vom Umbenennen der Domäne abgeraten wird (darauf spielt wahrscheinlich cj_berlin an), habe ich mir vorgestellt die MS365 Domäne (Maildomäne) als Master für das lokale AD zu verwenden. Durch die Synchronisation mit dem Azure AD Connect kennen die sich doch schon, da muss doch eine Migration dahin machbar sein. Das mit dem intern. war nur eine Idee das lokale AD von der Cloud unterscheiden zu können. wenn das nicht nötig ist, kann ich darauf auch verzichten.

Hallo Allerseits. Wir haben bei einem unserer größeren Kunden eine alte lokale Domain "DOMAIN.DE", welche mit Azure AD Connect mit einem Azure AD von MS365 synchronisiert wird. Die lokale Domäne ist per Benutzerprinzipalname-Suffix mit der MS365 Exchange Online Domain (Maildomäne) verknüpft. Leider gehört dem Kunden die lokal verwendete "DOMAIN.DE" nicht und kann deshalb nicht für Zertifikate verwendet werden. Für eine einfachere Zertifizierung der unterschiedlichen Dienste und zum gerade ziehen der Altlasten möchten wir gerne die lokale Domain so migrieren, dass aus für das lokale AD aus "DOMAIN.DE" "intern.maildomäne" wird. Da wir die Domäne nicht neu machen wollen, möchten ich gerne wissen, wie man das am besten per Migration hinbekommen kann. Mit freundlichen Grüßen ITCUB