Server 2012 - Remoteapp / RDP Gatewayserver bzw. Remotecomputer intern

[mcdaniels 22]

Hallo liebe MS-Pros!

 

Ich beschäftige mich zur Zeit mit -für mich- absolutem Neuland. Unter Windows Server 2012 habe ich die Terminalservices (Remotedienste) installiert. Das ganze läuft auf nur einem 2k12 Server in einer VM (Testumgebung).

 

Der Server ist als Domänencontroller konfiguriert und hat die IP 10.0.0.200.

 

Wenn ich vom internen Netz aus auf https://10.0.0.200/RDWeb zugreife klappt alles problemlos. Komme ich jedoch von extern (sprich von einem PC der über das Internet "hereinkommt") habe ich das Problem, dass mein lokaler FQDN des Server vom externen PC nicht aufgelöst werden kann. (weil dieser natürlich nix von der internen Konfiguration weiß).

 

Gesucht wird dann nämlich der "interne" FQDN: srv-ts.home.local (Siehe Anhang) und die Remoteapp kann nicht aufgerufen werden. Wie muss man soetwas konfigurieren, dass es funktioniert? Braucht man für den RD-Gateway einen FQDN der per öffentlichen DNS aufösbar ist?

 

Ich habe wohl auch noch ein Verständnisproblem: Gibt es bei Server 2012 den klassischen Remote Desktop nicht mehr? Dh. kann man sich nicht einfach des Programmes "Remotedesktopverbindung unter Windows 7 bedienen?

 

Wird hier alles nur noch per Remoteapp gelöst?

 

Vielen Dank!

 

LG

Daniel

[Kr99 11]

Hallo,

 

die klassiche Remotedesktop Verbindung existiert noch. Jedoch auf max. 2 gleichzeitige Admin Anmeldungen begrenzt.

 

Wenn normale User sich anmelden sollen, dann wird RemoteApp benötigt bzw. die User-Variante von RemoteDesktop.

 

Experementiere auch seit einigen Monaten mit dem RDweb und den RemoteApps herum.

 

Anbei meine aktuelle Konfiguration die eine Verbindung von Non-Domain Clients über das Internet auf die RemoteApps ermöglicht.

 

1x DC intern

1x TS Gateway extern (Gateway mit FQDN .de Domain)

1x TS Server intern

 

mfg

 

Kr99

[mcdaniels 22]

Hallo,

danke für deine Antwort. Also muss der Gateway dann doch von aussen per FQDN auflösbar sein. Das ist wohl "mein" Knackpunkt.

 

Danke nochmal!

 

LG

Daniel

[mcdaniels 22]

Nachsatz: Aus Sicherheitsgründen wäre es wohl vorzuziehen, das ganze über ein VPN abzuwickeln. Wenn man hier zb. ein Site to Site VPN aufzieht, dann könnte man grundsätzlich nur einen Server für die "Remotedienste" nutzen. Da sich hier dann ja - je nach Konfiguration - auch alles in einer Domäne abspielt bzw. abspielen kann.

bearbeitet 25. April 2014 von mcdaniels

[Dukel 436]

Das Gateway ist die Komponete, die in die DMZ gehört. Diese muss dann natürlich im Internet erreichbar sein.

[Daniel -MSFT- 129]

Deine Aussagen im ersten Posting und die folgenden Antworten sind fast komplett alle falsch. Deine Fehlermeldung bezieht sich darauf, dass der externe Client dem Zertifikat nicht vertraut, mit dem die RemoteApp signiert ist. VPN brauchst Du bei RD Gateway gerade nicht, deswegen machst Du ja RD Gateway und tunnelst RDP in SSL mit Preauthentication. Selbstverständlich gibt es 'normalen' Zugriff auf einen Terminal Server, auch unter 2012. RemoteApps sind optional. Das Gateway muss den internen Servernamen auflösen können, nicht der externe Client. Dr muss nur zum Gateway kommen können.

 

Schreib doch mal auf, was Du eigentlich genau erreichen willst. Schau in die Serverhilfe und TechNet und lies Dich in Remote Desktop Technologien ein. Mach die virtuellen Trainingslabs http://technet.microsoft.com/en-us/library/hh831754.aspx und http://technet.microsoft.com/en-us/library/hh831610.aspx und http://technet.microsoft.com/en-us/library/hh831442.aspx und http://technet.microsoft.com/en-us/library/jj134160.aspx

 

Have Fun!

Daniel

[mcdaniels 22]

Hallo Leute,

danke für eure Antworten und die Korrektur meiner falschen Annahmen.

 

@Daniel: Das ganze ist ein Testaufbau, da ich -wie erwähnt- eigentlich null Erfahrung mit dieser Thematik habe. (Man will ja etwas dazu lernen).

 

Was ich grundsätzlich erreichen will: um die 10 Remote User sollen per Terminalservices eine Anwendung nutzen / auf Files zugreifen.  Optimalerweise NICHT per Remoteapp, sondern mittels "normalem" Zugriff auf den Terminalserver. Für die Realisierung dieser Terminalserverlösung sollen so wenige Server wie möglich verwendet werden.

 

D.h.  externe User -> Firewall -> RD-Gatewayserver in DMZ  -> RD-Server / interne AD Domäne im LAN

 

In der Testumgebung hatte ich es so konfiguriert, dass ein 2k12 Server "alles" war. Sprich AD DS, DNS und RD Gateway, "Terminalservices". Der Server hatte allerdings eben eine "interne" IP 10.0.0.200 und die Domäne home.local .

 

Per Portforwarding habe ich dann Port 443 auf die IP 10.0.0.200:443 "umgebogen". Der Aufruf von RDWEB erfolgte über meine offizielle IP/rdweb.

 

So gesehen hätte dann aber das Gateway den internen Servernamen auflösen können müssen, oder? (ist ja alles auf einem Server...).

 

Edit: Ich bekomme u.a. auch eine Fehlermeldung, dass die Remotedesktop-Gatewayserveradresse nicht erreichbar ist, sobald ich eine Remoteapp angestartet habe und mich authentifiziert habe.

 

EDIT2: Problem gelöst! (Hab das jetzt mit einer meiner offiziellen IPs + FQDN versucht und erst jetzt gesehen, dass ich ja den FQDN des RD-Gatewayserver überschreiben kann.. Sorry!!)

 

LG

Daniel

bearbeitet 25. April 2014 von mcdaniels

[Daniel -MSFT- 129]

Hi Namensvetter,

 

schau Dir doch bitte die Labs an, die ich Dir verlinkt habe, bevor Du weiter Dein 'Ich klick mich durch'-Adventure weiterverfolgst

[mcdaniels 22]

Hey,

ich werd mir die Labs ganz sicher ansehen. Ja, es ist/war ein bisschen ein "ich klick mich durch" Adventure :-). Dennoch hab ich jetzt etwas mehr von der Thematik verstanden.

 

Mitglieder der Domäne  -> JA

Firmenrechner -> JA (ausschließlich Desktop-PC) kommen "nur" über einen Zugang, keine Heimarbeit oder dgl.

Lizenzierung -> Per Maschine

Office -> Ja -> Volumenlizenz (Open)

 

Im Allgemeinen geht es um eine Standortvernetzung. Allerdings habe ich das Problem, dass von den zuerst vom Anbieter versprochenen 16Mbit (up/down) eigentlich nur noch 2Mbit "übrig" geblieben sind und es keine andre Alternative gibt. Das ist auch der Grund, weshalb ich auf die Terminalservices gekommen bin.

 

Nachdem sowohl bei Standort A als auch bei Standort B idente Hardwarefirewalls vorhanden sind, hatte ich ursprünglich an ein Site 2 Site VPN gedacht. Hiermit habe ich bereits gute Erfahrungen gemacht. Die Clients könnten hier recht einfach an die Domäne angebunden werden.

 

Wäre es nicht auch eine Variante, zwischen den 2 Standorten den VPN Tunnel aufzubauen und den "Terminalserver" direkt in der internen Domäne zu lassen?

 

Die "Aussenstellenclients" wären dadurch ebenso in dieser Domäne und kämen problemlos zum "Terminalserver".

 

LG und vielen Dank!

 

PS: Ich habe betr. Terminalserverangelegenheiten auch eine Firma "bei der Hand". Allerdings würde ich mich dennoch gerne ein wenig damit auskennen ;)

 

Daniel

bearbeitet 25. April 2014 von mcdaniels

[Daniel -MSFT- 129]

Was für eine Leitung hast Du genau an Standort A und B? 16 MBit klingt nach ADSL. Feste IPs?

[mcdaniels 22]

Hi,

ja habe feste IP Adressen. Das nennt sich Business Zugang eines hiesigen großen Provider basiert auf SDSL.

 

Standort A: 20/20 Anbindung auf LWL-Basis (ins Internet)

Standort B: 2/2 SDSL

 

 

Aber wie man es auch wendet und dreht 2Mbit scheinen mir recht zäh...

 

 

 

LG

Daniel

bearbeitet 26. April 2014 von mcdaniels

[NeMiX 76]

Wenn du VPN machst, kannst du dir das RD Gateway "sparen" falls du keine User hast die ohne VPN auf den TS kommen sollen. Du solltest aber deine Anforderungen vorher schärfer wo es hingehen soll. Auch mit 2Mbit SDSL können 10 User auf Files/Exchange zugreifen wenn man passend QoS an der Firewall macht. Nur mal als Denkanstoß, auch wenn ich ein Freund von RDS/Citrix bin.

 

Den "klassischen" Terminalserver gibt es natürlich immer noch, einfach die Rolle Remote Desktop Session Host

 installieren (das wurde bestimmt in den Labs von Daniel erwähnt ;) ).