[2012] 1x Domain controller & 2x Terminal server

[mydogisgone]

Op het moment ben ik bezig om een Domain controller in te richten icm 2 terminal servers.
Alle 3 gebaseerd op Server 2012 Standard.

Nu loop ik eigenlijk tegen een aantal vragen aan en hoop dat jullie me kunnen helpen? Aangezien ik op internet niet echt een concreet antwoord kan vinden.

Namelijk:

Op welke servers moet ik de Terminal services installeren?
Ik dacht namelijk zelf zo:

Domain controller: RD-Connection broker, RD-Sessiehost, RD-webtoegang, Rd-licentieverlening

Terminal server 1: RD-Gateway
Terminal server 2: RD-Gateway

Gaat er om dat de users inloggen op de RDweb via een SSL verbinding binnen internet explorer en daar automatisch de juiste terminal server te zien krijgen. Dit door middel van policy's.

Doe ik het op deze manier dan juist of moet ik het anders indelen?
Zo als ik het nu schrijf zou alle communicatie om een sessie te starten toch via de Domain controller lopen?

Hopelijk kan iemand mij een klein beetje meer duidelijkheid verschaffen? eventueel via een diagram?

[Linke Loe]

De servers waar gebruikers daadwerkelijk op inloggen, moeten de session host role krijgen. Op je domain controller zou je de licensing role en de connection broker kunnen installeren en de web interface en gateway installer je op een aparte webserver, het liefst in een DMZ.

Web interface en gateway absoluut niet op je domain controller, aangezien dit de rollen zijn waar gebruikers vanaf het Internet verbinding mee maken. Je wil natuurlijk niet je domain controller blootstellen aan het Internet.

Even terzijde vraag ik me wel af hoe je omgeving er uit ziet verder. Als je netwerk groot genoeg is voor twee domain controllers, waarom dan maar één domain controller?

[Question Mark]

Waarom twee RDS servers eigenlijk? Kun je die load niet op één wat zwaardere server kwijt?

(aangezien je maar één DC neerzet doe ik even de aanname dat beschikbaarheid niet erg belangrijk is).

Overigens is er meer dan voldoende informatie op het web te vinden over het opzetten van RDS, bijvoorbeeld:

Test Lab Guide: Remote Desktop Services Publishing

[ Voor 37% gewijzigd door Question Mark op 06-02-2014 14:19 ]

[mydogisgone]

Linke Loe schreef op donderdag 06 februari 2014 @ 14:03:
De servers waar gebruikers daadwerkelijk op inloggen, moeten de session host role krijgen. Op je domain controller zou je de licensing role en de connection broker kunnen installeren en de web interface en gateway installer je op een aparte webserver, het liefst in een DMZ.

Web interface en gateway absoluut niet op je domain controller, aangezien dit de rollen zijn waar gebruikers vanaf het Internet verbinding mee maken. Je wil natuurlijk niet je domain controller blootstellen aan het Internet.

Even terzijde vraag ik me wel af hoe je omgeving er uit ziet verder. Als je netwerk groot genoeg is voor twee domain controllers, waarom dan maar één domain controller?

Oke dat is vrij logisch inderdaad. Ik wil inderdaad mijn domain controller niet blootstellen aan het internet.

De omgeving is niet bij ons gehost. Is namelijk bij een datacenter gehost. Er wordt maar 1 domain controller gebruikt ivm kostenbesparing. (heb het helaas zelf niet bedacht)

Moet ik dan voor elke ts een aparte link naar het internet maken voor RDweb? Of kan ik dit wel combineren? Dus 1 Rdweb zeg maar voor 2 TS'en?

Ik heb namelijk op het moment een adres zoals cloud.xxxxxx.nl

Question Mark schreef op donderdag 06 februari 2014 @ 14:16:
Waarom twee RDS servers eigenlijk? Kun je die load niet op één wat zwaardere server kwijt?

(aangezien je maar één DC neerzet doe ik even de aanname dat beschikbaarheid niet erg belangrijk is).

Gaat hier om 2 verschillende partijen die gescheiden van elkaar moeten gaan werken.

[ Voor 13% gewijzigd door mydogisgone op 06-02-2014 14:19 ]

[Craven]

Question Mark schreef op donderdag 06 februari 2014 @ 14:16:
Waarom twee RDS servers eigenlijk? Kun je die load niet op één wat zwaardere server kwijt?

(aangezien je maar één DC neerzet doe ik even de aanname dat beschikbaarheid niet erg belangrijk is).

Het klinkt als een testomgeving. Maar als ik de keuze heb uit 2 DC's en 1 RDS of 1 DC en 2 RDS is de keus snel gemaakt. Een DC is een stuk stabieler dan een RDS bak. RDS is ook iets wat je met enige regelmaat een reboot wil geven (afhankelijk van de applicaties erop). Dus 2 RDS servers vind ik het over het algemeen wel een minimum.

Edit:
geen testomgeving dus maar dan zou ik alsnog dit aanhouden. Liever 2 RDS bakken die je gefaseerd kan rebooten om uptime te garanderen.

Edit2: heb je ook nog nagedacht over hoe je hier beheer op wilt gaan uitvoeren overigens? Je draait dit virtueel hoop ik? Zo nee, wat ga je doen als een RDS bak affikt? Bij de DC is het sowieso einde verhaal. Maar je wilt op afstand toch graag wat disaster recovery kunnen doen.

[ Voor 25% gewijzigd door Craven op 06-02-2014 14:24 ]

[Question Mark]

Craven schreef op donderdag 06 februari 2014 @ 14:20:
[...]

Het klinkt als een testomgeving. Maar als ik de keuze heb uit 2 DC's en 1 RDS of 1 DC en 2 RDS is de keus snel gemaakt. Een DC is een stuk stabieler dan een RDS bak. RDS is ook iets wat je met enige regelmaat een reboot wil geven (afhankelijk van de applicaties erop). Dus 2 RDS servers vind ik het over het algemeen wel een minimum.

Edit:
geen testomgeving dus maar dan zou ik alsnog dit aanhouden. Liever 2 RDS bakken die je gefaseerd kan rebooten om uptime te garanderen.

Ligt compleet ook aan je overige infrastructuur. Een RDS bevat geen gebruikersdata en is dus veel sneller en simpeler te restoren dan een DC met dynamische data (gebruikerswachtwoorden bv). Vanuit die optiek zou ik liever mijn dynamische data dubbel willen hebben dan een statische RDS server...

Maar de grote voorkeur is uiteraard beide dubbel...

[Craven]

Ja ik ben ook misschien wat partijdig omdat ik voornamelijk SBC/VDI beheer. AD beheer is niet mijn ding.

[Linke Loe]

mydogisgone schreef op donderdag 06 februari 2014 @ 14:18:
[...]


Oke dat is vrij logisch inderdaad. Ik wil inderdaad mijn domain controller niet blootstellen aan het internet.

De omgeving is niet bij ons gehost. Is namelijk bij een datacenter gehost. Er wordt maar 1 domain controller gebruikt ivm kostenbesparing. (heb het helaas zelf niet bedacht)

Moet ik dan voor elke ts een aparte link naar het internet maken voor RDweb? Of kan ik dit wel combineren? Dus 1 Rdweb zeg maar voor 2 TS'en?

Ik heb namelijk op het moment een adres zoals cloud.xxxxxx.nl


[...]


Gaat hier om 2 verschillende partijen die gescheiden van elkaar moeten gaan werken.

Zoals al eerder aangegeven is hierover genoeg te vinden op Internet. Na het installeren van de RDS rollen vertelt de server manager je precise wat je moet doen...

Als het om 2 verschillende partijen gaat, snap ik al helemaal niet waarom er maar 1 domain controller staat. Hoe kun je gescheiden van elkaar werken, als je in hetzelfde AD domein en forest zit?

[Oogje]

Linke Loe schreef op donderdag 06 februari 2014 @ 15:58:
[...]


Als het om 2 verschillende partijen gaat, snap ik al helemaal niet waarom er maar 1 domain controller staat. Hoe kun je gescheiden van elkaar werken, als je in hetzelfde AD domein en forest zit?

Dit dus.....en afgezien van bovenstaande, in de genoemde setup is het juist dat de TS load verdeeld wordt over 2 servers. Dat is dus niet gescheiden houden.

En niet om lullig te doen, maar zou je voor het design niet beter een consultant inhuren die van de hoed en de rand weet? Ik heb niet de indruk dat je de materie in zoverre beheerst dat je zo'n soort omgeving ff opzet. Dat voorkomt veel ellende imho.

[ Voor 20% gewijzigd door Oogje op 06-02-2014 17:19 ]

[ro3lie]

mydogisgone schreef op donderdag 06 februari 2014 @ 13:52:
Op het moment ben ik bezig om een Domain controller in te richten icm 2 terminal servers.
Alle 3 gebaseerd op Server 2012 Standard.

Nu loop ik eigenlijk tegen een aantal vragen aan en hoop dat jullie me kunnen helpen? Aangezien ik op internet niet echt een concreet antwoord kan vinden.

Namelijk:

Op welke servers moet ik de Terminal services installeren?
Ik dacht namelijk zelf zo:

Domain controller: RD-Connection broker, RD-Sessiehost, RD-webtoegang, Rd-licentieverlening

Terminal server 1: RD-Gateway
Terminal server 2: RD-Gateway

Gaat er om dat de users inloggen op de RDweb via een SSL verbinding binnen internet explorer en daar automatisch de juiste terminal server te zien krijgen. Dit door middel van policy's.

Doe ik het op deze manier dan juist of moet ik het anders indelen?
Zo als ik het nu schrijf zou alle communicatie om een sessie te starten toch via de Domain controller lopen?

Hopelijk kan iemand mij een klein beetje meer duidelijkheid verschaffen? eventueel via een diagram?

Ik zou me toch nog wat meer verdiepen in de theorie alvorens iets uit te rollen. Toch hierbij een voorstel voor je ideale situatie..

DC-01 - Domain controller
DC-02 - Domain controller
RDS-00 RDS ConnectionBroker, RDS WebAccess, RDS Gateway, RDS Licensing
RDS-01 RDS Host
RDS-02 RDS Host
FS-01 File Server voor je algemene bestanden, user disks, etc..
Meest ideale situatie heb je nog wat extra servers voor het scheiden van meerdere rollen, weet niet hoe je zit met je mail, printers, applicatie servers ed...

Toewijzen van de juiste terminal server op de RDS Webportaal doe je middels de server pool die je aanmaakt. Afhankelijk of je gebruik maakt van RemoteApp of RemoteDesktop.. Als je gaat voor load balancing plaats je beide servers in een serverpool en krijg je één snelkoppeling.

Andere optie zijn 2 aparte serverpools met ieder 1 host, afhankelijk van de rechten die je koppelt op de serverpool krijgt een gebruiker toegang of niet.

Voor de RDS WebAccess/Gateway kan je deze in je netwerk plaatsen. Poort 443 openzetten voor je SSL verbinding moet voldoende zijn.

Even een andere vraag:
Om hoeveel gebruikers gaat het? Als je maar 3 servers mag inrichten lijkt me dat je geen grote omgeving hebt. 2 RDS servers is dan al veel.

[ Voor 3% gewijzigd door ro3lie op 06-02-2014 18:03 ]

[alt-92]

Linke Loe schreef op donderdag 06 februari 2014 @ 15:58:

Als het om 2 verschillende partijen gaat, snap ik al helemaal niet waarom er maar 1 domain controller staat. Hoe kun je gescheiden van elkaar werken, als je in hetzelfde AD domein en forest zit?

Hoe denk je dat een Shared Hosting omgeving werkt?
Je kan een multi-tenant model hanteren zoals dat ook in o365 gebeurt, elke Entity een eigen separaat gedelegeerde OU.

[Linke Loe]

alt-92 schreef op donderdag 06 februari 2014 @ 20:40:
[...]

Hoe denk je dat een Shared Hosting omgeving werkt?
Je kan een multi-tenant model hanteren zoals dat ook in o365 gebeurt, elke Entity een eigen separaat gedelegeerde OU.

Daar heb je inderdaad gelijk in... Uiteraard maak je dan het onderscheid door in te loggen met een user principle name in de vorm van een e-mailadres. Het ziet er echter niet naar uit dat het om een dergelijke omgeving gaat...

[ro3lie]

Linke Loe schreef op donderdag 06 februari 2014 @ 21:54:
[...]

Daar heb je inderdaad gelijk in... Uiteraard maak je dan het onderscheid door in te loggen met een user principle name in de vorm van een e-mailadres. Het ziet er echter niet naar uit dat het om een dergelijke omgeving gaat...

Verschillende locaties is niks mis mee voor je omgeving. Echter zou ik dan wel goed kijken hoe je de rollen verdeeld. Niet dat al je data over die lijn zit te harken

Voorkeur is dan ook wel een DC per locatie en opletten dat ze goed blijven synchroniseren met elkaar. Als je tombstone is verlopen heb je ook leuke issues

[mydogisgone]

ro3lie schreef op donderdag 06 februari 2014 @ 18:00:
[...]


Ik zou me toch nog wat meer verdiepen in de theorie alvorens iets uit te rollen. Toch hierbij een voorstel voor je ideale situatie..

DC-01 - Domain controller
DC-02 - Domain controller
RDS-00 RDS ConnectionBroker, RDS WebAccess, RDS Gateway, RDS Licensing
RDS-01 RDS Host
RDS-02 RDS Host
FS-01 File Server voor je algemene bestanden, user disks, etc..
Meest ideale situatie heb je nog wat extra servers voor het scheiden van meerdere rollen, weet niet hoe je zit met je mail, printers, applicatie servers ed...

Toewijzen van de juiste terminal server op de RDS Webportaal doe je middels de server pool die je aanmaakt. Afhankelijk of je gebruik maakt van RemoteApp of RemoteDesktop.. Als je gaat voor load balancing plaats je beide servers in een serverpool en krijg je één snelkoppeling.

Andere optie zijn 2 aparte serverpools met ieder 1 host, afhankelijk van de rechten die je koppelt op de serverpool krijgt een gebruiker toegang of niet.

Voor de RDS WebAccess/Gateway kan je deze in je netwerk plaatsen. Poort 443 openzetten voor je SSL verbinding moet voldoende zijn.

Even een andere vraag:
Om hoeveel gebruikers gaat het? Als je maar 3 servers mag inrichten lijkt me dat je geen grote omgeving hebt. 2 RDS servers is dan al veel.

Het gaat om 7 gebruikers voor 1 terminal server en 14 voor de andere. Niet heel veel. Het is trouwens niet lokaal gehost. Maar bij een datacenter.

[Question Mark]

En wat wil je precies scheiden waardoor het niet op één systeem kan?

Door de security goed in te stellen kan ik partijen gescheiden houden. Afwijkende onderhoudswindows zou in mijn ogen dan ook de enige issue zijn om te kiezen voor twee systemen.

[Razwer]

Craven schreef op donderdag 06 februari 2014 @ 14:20:
[...]
Een DC is een stuk stabieler dan een RDS bak.

Craven schreef op donderdag 06 februari 2014 @ 14:25:
Ja ik ben ook misschien wat partijdig omdat ik voornamelijk SBC/VDI beheer. AD beheer is niet mijn ding.

Dat soort basis kennis/principes als wat Question Mark zegt zou je toch minimaal moeten bezitten als je VDI etc. doet. Elke IT-er behoort zulke kennis te bezitten. Maargoed, zonder n00bs zijn er geen pro's...

mydogisgone schreef op vrijdag 07 februari 2014 @ 08:51:
[...]


Het gaat om 7 gebruikers voor 1 terminal server en 14 voor de andere. Niet heel veel. Het is trouwens niet lokaal gehost. Maar bij een datacenter.

Zet lekker 1 bak in als RDS en gooi het hele feest er op. RDG, RDWeb, Broker etc.
Afhankelijk van je specs kun je prima met een gebruiker of 30 op een TS. Hangt natuurlijk beetje af van de apps maar over het algemeen moet dat lukken.
Zet je 2e bak in als DC

het ideaal plaatje is al geschetst door ro3lie, al mist hij daar de HA broker en zou je rdweb/rdg ook load balanced willen hebben (2e RDG bak)

[ Voor 3% gewijzigd door Razwer op 07-02-2014 14:03 ]

[Craven]

Razwer schreef op vrijdag 07 februari 2014 @ 14:01:
[...]

En bedankt. Jij denkt dus dat de gemiddelde RDS bak stabieler is dan een DC? Ik ben het met question mark eens dat een DC meer impact heeft als hij down gaat maar qua stabiliteit zal een RDS bak toch echt het onderspit delven. En dan niet vanwege de serverrol maar vanwege de applicatiemeuk die erop staan. Dertig man die de hele dag in (slechte geprogrammeerde) clientapplicaties aan het werk zijn wil nog wel is een slecht effect hebben op je stabiliteit.

Razwer schreef op vrijdag 07 februari 2014 @ 14:01:
[...]
Dat soort basis kennis/principes als wat Question Mark zegt zou je toch minimaal moeten bezitten als je VDI etc. doet. Elke IT-er behoort zulke kennis te bezitten. Maargoed, zonder n00bs zijn er geen pro's...

De backup en restore mogelijkheden van een Active Directory zijn inderdaad wel erg belangrijk om te weten op het moment dat je specialiseert in applicatie deployment/ SBC en VDI...

Excuse me for making a mistake...

[mydogisgone]

Question Mark schreef op vrijdag 07 februari 2014 @ 09:21:
En wat wil je precies scheiden waardoor het niet op één systeem kan?

Door de security goed in te stellen kan ik partijen gescheiden houden. Afwijkende onderhoudswindows zou in mijn ogen dan ook de enige issue zijn om te kiezen voor twee systemen.

Dat klopt, maar mocht de RDS een herstart moeten hebben dan heeft het 2e partij er ook last van. Dat is een beetje het punt.

Razwer schreef op vrijdag 07 februari 2014 @ 14:01:

Zet lekker 1 bak in als RDS en gooi het hele feest er op. RDG, RDWeb, Broker etc.
Afhankelijk van je specs kun je prima met een gebruiker of 30 op een TS. Hangt natuurlijk beetje af van de apps maar over het algemeen moet dat lukken.
Zet je 2e bak in als DC

het ideaal plaatje is al geschetst door ro3lie, al mist hij daar de HA broker en zou je rdweb/rdg ook load balanced willen hebben (2e RDG bak)

Opzich natuurlijk wel te doen, maar mocht er in de toekomst uitgebreid worden? Dan is het handig om er dan een 2e RDS bij te zetten en deze in te zetten voor loadbalancing? Of heb ik het dan helemaal verkeerd?

[ Voor 25% gewijzigd door mydogisgone op 07-02-2014 18:51 ]

[Razwer]

Craven schreef op vrijdag 07 februari 2014 @ 14:48:
[...]

En bedankt. Jij denkt dus dat de gemiddelde RDS bak stabieler is dan een DC? Ik ben het met question mark eens dat een DC meer impact heeft als hij down gaat maar qua stabiliteit zal een RDS bak toch echt het onderspit delven. En dan niet vanwege de serverrol maar vanwege de applicatiemeuk die erop staan. Dertig man die de hele dag in (slechte geprogrammeerde) clientapplicaties aan het werk zijn wil nog wel is een slecht effect hebben op je stabiliteit.

Aannames. Ik ben zowel AD als RDS specialist bij mij op werk. Doordat meer mensen meer aanloggen op RDS bakken dan op AD controllers (logisch) is de kans wel groter dat een RDS problemen kan krijgen ja, maar de denkwijze die je er op na houd is fout en sla je de plank volledig mis. Zonder AD werkt je RDS ook niet. Zonder RDS werkt je AD prima. Bij Windows based networking is AD je fundament. Dit stabiel neerzetten (redundant), juist configureren en op de juiste manier gebruiken is essentieel voor stabiliteit van de rest van jouw omgeving. Daar moet de hoogste prioriteit in zitten
Ik zei niet dat jouw opmerking onjuist was, ik vond het een minder intelligente opmerking gezien de gemotiveerde denkwijze die je er op nahoud.
Verder is een RDS redelijk stabiel te houden (OS level) door bijvoorbeeld, maar niet gelimiteerd tot, Application Virtualization te gebruiken.

[...]

De backup en restore mogelijkheden van een Active Directory zijn inderdaad wel erg belangrijk om te weten op het moment dat je specialiseert in applicatie deployment/ SBC en VDI...

Excuse me for making a mistake...

De gehele werking van AD is handig om te weten gezien veel applicaties leunen op functionaliteit hier van. Bedenk DNS, LDAP queries, extended attributes, site awareness, etc. Nog een niveau verder is misschien wel de storage laag die je bij je applicaties gebruikt. Misschien (en hopelijk voor jou) gebruik je hier DFS Namespaces voor. Dit leunt ook weer op AD.
Roaming profiles/folder redirection, drivemaps, GPO's. Allemaal AD gerelateerd en eventueel ook weer effect hebbend bij applicaties (redirection van %APPDATA% bijvoorbeeld).

Niet zo op je geslachtsdeel getrapt voelen als iemand je tekortkomingen bloot legt. Ik neem aan dat je op GoT zit om af en toe iets te leren. De guru uithangen kun je beter doen op Technet Social