Terminal Server voor hosting

[eatsoup]

Hoi Tweakers,

Ik ben bezig met het opzetten van een test voor hosted Terminal Server, en loop tegen een aantal dingen aan.

-Is het mogelijk om meerdere bedrijven in te laten loggen (zeg maar user1@bedrijf1 en user1@bedrijf2) zonder gebruik te maken van meerdere domain controllers?
-Wat is de beste manier voor het dichtzetten van de Terminal Server, dit kan natuurlijk via een standaard group policy met meerdere OU's, maar ik zie door de bomen het bos niet meer. Is hier geen makkelijkere manier voor? Misschien 3rd party tools, of een ADM template?

Alvast bedankt voor jullie reacties


-edit-
Keywords die gebruikt zijn voor het zoeken naar group policy:
Terminal server 2008 lockdown, 2008 terminal server gpo template, 2008 terminal server ADM template.
Keywords die gebruikt zijn voor het zoeken naar inloggen:
oa: multiple domains single domain controler, weet voor de rest even niet meer wat nog meer

[ Voor 21% gewijzigd door eatsoup op 18-09-2013 10:33 ]

[Schnoop]

-Is het mogelijk om meerdere bedrijven in te laten loggen (zeg maar user1@bedrijf1 en user1@bedrijf2) zonder gebruik te maken van meerdere domain controllers?

Ja. Door middel van forests.

-Wat is de beste manier voor het dichtzetten van de Terminal Server, dit kan natuurlijk via een standaard group policy met meerdere OU's, maar ik zie door de bomen het bos niet meer. Is hier geen makkelijkere manier voor? Misschien 3rd party tools, of een ADM template?

Wat bedoel je precies met dichtzetten?

[Trommelrem]

Schnoop schreef op vrijdag 13 september 2013 @ 15:10:
[...]

Ja. Door middel van forests.

Dan heb je toch alsnog meerdere DC's nodig?
Volgens mij wil TS een VDI aanbieden op een minimaal aantal servers in Azure ofzoiets. Kan, maar bij een basisconfig moet er wel een vertrouwensrelatie zijn tussen de verschillende bedrijven die er op inloggen.

[DennusB]

Zet er dan iets op als deepfreeze ofzo, dan is alles na een reboot (gepland) weer terug in de oude staat!

[Schnoop]

Trommelrem schreef op vrijdag 13 september 2013 @ 15:24:
[...]


Dan heb je toch alsnog meerdere DC's nodig?
Volgens mij wil TS een VDI aanbieden op een minimaal aantal servers in Azure ofzoiets. Kan, maar bij een basisconfig moet er wel een vertrouwensrelatie zijn tussen de verschillende bedrijven die er op inloggen.

Je zult inderdaad wel meerdere (eventueel virtuele) servers moeten maken, oftewel 1 per domein. Maar met deze techniek kunnen dus wel op de TS meerdere domeinen gebruikt worden om in te loggen.

En betreffende "afschermen". Zolang niemand op de TS administrator hoeft te zijn kun je zaken in theorie afschermen. Als je toch 1 server hebt zou ik er gewoon 2 virtuele machines op zetten met ieder een DC + TS. Scheelt je een hoop gedoe.

Als je niet met virtualisatie wil werken moet je alsnog 2 servers hebben voor de forests en kom je op het zelfde principe uit.

[redfoxert]

Ik geef je een paar tips:

Citrix Provisioning
AppSense

Het delen van een enkele TS voor meerdere bedrijven zou ik afraden vanwege diverse redenen waaronder: Security, Wensen en Eisen van de klanten. Als je het al wel wilt doen dan eerder een generiek domein waarin iedereen een eigen account krijgt.

[The Realone]

Een enkel domein en dus 1 DC voor alle gebruikers is perfect mogelijk, maar zo'n oplossing staat of valt met hoe jij het inricht en reguleert. Hetzelfde geldt eigenlijk voor de TS, dit kan in theorie best 1 server zijn voor verschillende klanten, maar de vraag is je dit wil. Het brengt namelijk weer een hoop extra werk met zich mee qua scheiding. Aan de andere kant, als zij enkel gebruik maken van een webbrowser en MS Office om maar wat te noemen, dan is dit ook niet zo'n probleem.

[redfoxert]

The Realone schreef op vrijdag 13 september 2013 @ 15:45:
Aan de andere kant, als zij enkel gebruik maken van een webbrowser en MS Office om maar wat te noemen, dan is dit ook niet zo'n probleem.

Ik kan met een Excel sheet met een bult regels en kolommen een dikke TS server op zijn knieen krijgen. Door gebruik te maken van VLOOKUPs in veel van die kolommen gebruikt Excel daardoor alle beschikbare cpu resources. Dit is standaard en niet middels een policy oid in te stellen.

Dus lijkt me wel een probleem, zeker als je maar 1 server hebt

[ Voor 6% gewijzigd door redfoxert op 13-09-2013 16:10 ]

[eatsoup]

Alvast bedankt voor jullie reacties,

Het is me duidelijk dat ik, voor nu in ieder geval, met een enkele DC ga werken.
Voor de rest nog tips over de Group Policy?

[Turdie]

eatsoup schreef op vrijdag 13 september 2013 @ 16:47:
Alvast bedankt voor jullie reacties,

Het is me duidelijk dat ik, voor nu in ieder geval, met een enkele DC ga werken.
Voor de rest nog tips over de Group Policy?

Er zijn standaard termplates van Microsoft voor high-secure servers, die zou ik gebruiken. Anders moet je ieder security setting handmatig afgaan, dat is al op basis van ervaring en best-practice. Hiemee kun je een template importeren en eventueel GPO settings aanpassen waarvan jij wil dat ze meer/minder secure zijn.

Security Compliance Manager (SCM)

Ik zou zelf niet direct voor terminal server access kiezen, maar voor RemoteApps die onderdeel zijn van Remote Desktop Services. Dan klikt een klant gewoon op een soort website waar zijn applicatie aan en wordt die gepresenteert aan de gebruiker.Dan biedt je alleen de applicatie aan, en heeft de klant geen toegang tot het host-os.

Daarnaast kun je klanten krijgen die verantwoordeing moet afleggen aan bepaalde security standaarden en een eigen teminal server gaan eisen of erg strikt zijn in hun eigen security beleid.

Een ook ga je terminal server/rdp verkeer over een WAN verbinding sturen, waar de latency hoog kan zijn, dus houdt daar ook rekening mee, anders krijgt een klant een schokkerige ervaring in zijn sessie. En dan kan ik je garanderen dat je klant bij jouw aan de lijn hangt. Op de meeste WAN verbindingen heb je qua latency geen invloed, tenzij je een heel dure WAN verbinding koopt.

Maar tegenwoordig kun je in Azure ook Remote Desktop hosten, wellicht is dat een optie voor je (moet je wel een SPLA licentie agreement hebben)
Remote Desktop Services are now allowed on Windows Azure

[ Voor 66% gewijzigd door Turdie op 13-09-2013 17:58 ]

[Trommelrem]

eatsoup schreef op vrijdag 13 september 2013 @ 14:58:
-Is het mogelijk om meerdere bedrijven in te laten loggen (zeg maar user1@bedrijf1 en user1@bedrijf2) zonder gebruik te maken van meerdere domain controllers?

UPN suffix.

[The Realone]

redfoxert schreef op vrijdag 13 september 2013 @ 16:09:
[...]


Ik kan met een Excel sheet met een bult regels en kolommen een dikke TS server op zijn knieen krijgen. Door gebruik te maken van VLOOKUPs in veel van die kolommen gebruikt Excel daardoor alle beschikbare cpu resources. Dit is standaard en niet middels een policy oid in te stellen.

Dus lijkt me wel een probleem, zeker als je maar 1 server hebt

Dus dan maar 1 TS per persoon om dit soort extreme gevallen te tackelen?
Beetje hetzelfde verhaal als shared webhosting, als 1 gebruiker het voor elkaar krijgt de webserver op z'n knieën te krijgen is iedereen daarop de lul. Wil je dat niet, betaal je extra.

[Turdie]

The Realone schreef op vrijdag 13 september 2013 @ 18:06:
[...]


Dus dan maar 1 TS per persoon om dit soort extreme gevallen te tackelen?
Beetje hetzelfde verhaal als shared webhosting, als 1 gebruiker het voor elkaar krijgt de webserver op z'n knieën te krijgen is iedereen daarop de lul. Wil je dat niet, betaal je extra.

Nee, WSRM configureren. Windows Server Resource Manager, dan kun je instellen hoeveel CPU en Memory een sessie mag gebruiken (percentage of absoluut aantal).

[ Voor 8% gewijzigd door Turdie op 13-09-2013 18:56 ]

[Remco]

eatsoup schreef op vrijdag 13 september 2013 @ 16:47:
Voor de rest nog tips over de Group Policy?

Zoals eerder al gemeld kijk eens naar Appsense of Res Workspace.

[Rupie]

eatsoup, wat heb je zelf al opgezocht om antwoord te krijgen op je vragen? Ik zie je alleen een paar vragen dumpen zonder aan te geven waar je zelf al over nagedacht hebt? We verwachten wel een beetje eigen inzet he!

[johnkeates]

eatsoup, gezien je type vragen zit ik te denken dat het een vrij gevaarlijke situatie wordt als je dit gaat opzetten voor een real-world productie systeem... is dit een studieopdracht of gaat dit daadwerkelijk gebruikt worden?

[ARKO]

Er is een hele makkelijke manier om gebruikers in te laten loggen met [e-mail], dit kan door een user principal name in te stellen. Dit is wat Microsoft zelf gebruikt voor bijvoorbeeld Exchange multi tenant omgevingen.

Er zijn twee manieren om een user principal name in te stellen:
1. Via adsi edit, de user openen en te zoeken naar: UserPrincipalName
2. Via Powerstell set-useraduser: http://technet.microsoft.com/en-us/library/ee617215.aspx

Als je hierna je user opent via de normale active directory console, dan zie je ook staan bij "user logon name" je primary domain en het domain dat je bij UserPrincipalName hebt gebruikt.

Op deze manier kan je één domain draaien, daarnaast moet je dan zoeken naar mogelijkheden om er voor te zorgen dat users enkel directory gegevens kunnen opvragen uit hun eigen OU. Dit is mogelijk, echter weet ik even niet meer direct hoe en zal je dit even moeten uitzoeken. (het kan niet simpelweg bij GPO's)

[Wim-Bart]

johnkeates schreef op vrijdag 13 september 2013 @ 21:34:
eatsoup, gezien je type vragen zit ik te denken dat het een vrij gevaarlijke situatie wordt als je dit gaat opzetten voor een real-world productie systeem... is dit een studieopdracht of gaat dit daadwerkelijk gebruikt worden?

Inderdaad, levensgevaarlijke situatie wanneer je niet alles doortest en extreem dicht gooit. Je hebt namelijk meer nodig dan alleen een TS en een DC.

Even wat wenken:
1. Je moet C: afschermen voor toegang, want anders kan met bij data op C:, bijvoorbeeld in software omgevingen van andere klanten, dus moet je werken met redirected folders voor de user data en dus heb je een NAS nodig of een fileserver voor home drives en bedrijfsdata.
2. Hoe zit het met BACKUP, en backup is dus TAPE of een variant in de cloud van klanten data;
3. Wat wordt je patchbeleid voor software updates, want lullig als klant A een site nodig heeft die maximaal Java 1.7 ud 23 mag en een andere klant weer 1.7 ud 40 vereist.
4. Hoe is de juridische aansprakelijkheid als klant a bij gegevens van klant b komt, reken maar op, ze komen bij de beheerder.
5. Wat is je sizing, ik lees niks over aantal gebruikers, wat hun gebruik-profiel is.
6. Ik mis strategie in aanbieden van sessies, is het full desktop, zijn het remote apps.
7. Waar staat je connection broker, op de server zelf of op een andere server,

En dat zijn nog maar de basis zaken. Er is veel meer waar je over na moet denken. Zoals, waar zit de mail, hoe bied je dit aan. En het belangrijkste: Licenties.

Om even kort door de bocht te zijn. Licentietechnisch mag het niet, of je moet SPLA gaan doen.

[Dennism]

Ik vraag me een klein beetje of TS geen troll of scholier is........zoiets op willen zetten en dan met deze vragen komen....... Recipe for disaster naar mijn mening als dit moet leiden tot een live productie omgeving.

Qua vragen:

1. Zet een goed forest op, en zet meerdere DC's in. Je wil echt niet je DC als SPOF hebben per domain.
2. Zet meerdere terminalservers in, ook deze wil je niet als SPOF hebben. O.a. Citrix Provioning Server is hier heel erg geschikt voor om meerdere TSén van dezelfde image te laten starten. Al weet ik niet zeker of deze nog los verkrijgbaar is buiten XenApp om.
3. Uitrollen van de user omgeving: Res Workspace manager of Appsense.

Verder zie de vragen van Wim-Bart. Al vind ik een NAS in deze situaties niet echt geschikt, tenzij je echt een minimaal aantal aan users hebt (al kan dit ook mijn slechte ervaring zijn met NAS'sen in een productie omgeving, in een lab doen ze het altijd goed, echter in productie is mijn ervaaring dat relaties bij een NAS altijd komen met klachten over traagheid). Een goede minimaal dubbel uitgevoerde SAN (ook storage wil je absoluut niet als SPOF hebben) heeft bij hosted omgevingen altijd mijn voorkeur.

De backups daarintegen kunnen wel weer prima op een enterprise NAS, daar tapes in een hosted omgeving vrij lastig zijn, tenzij je met een dure robot gaat werken en ook de capaciteit houd niet over wil je binnen een redelijk budget blijven.

[Rolfie]

Dennism schreef op zondag 15 september 2013 @ 05:58:
Ik vraag me een klein beetje of TS geen troll of scholier is........zoiets op willen zetten en dan met deze vragen komen....... Recipe for disaster naar mijn mening als dit moet leiden tot een live productie omgeving.

[Wim-Bart]

Dennism schreef op zondag 15 september 2013 @ 05:58:
Ik vraag me een klein beetje of TS geen troll of scholier is........zoiets op willen zetten en dan met deze vragen komen....... Recipe for disaster naar mijn mening als dit moet leiden tot een live productie omgeving.

Dat gevoel heb ik ook, alleen al een single customer omgeving is al complex wanneer je dit goed moet opzetten en ben je al flink bezig om dit goed in te regelen qua beveiliging. En wanneer je meerdere klanten wil gaan bedienen dan wordt het helemaal complex. Ik heb wel meerdere ontwerpen gemaakt voor een dergelijke omgeving, maar daarbij waren alle bedrijven onderdeel van de zelfde holding en wordt er gewerkt met een forrest en meerdere DC's en staat de RDS omgeving in een Resource Domein onderdeel uitmakend van het forrest. Maar 1 DC, met diverse klanten er op, met ieder een ander beveiligingsbeleid. Pffffff.

Ik ben het met je eens, dit is heading voor disaster gezien alle vragen. En een hele dure aansprakelijkheidsverzekering

[Trommelrem]

Wat een onzin over die complexe omgevingen. Als TS gewoon een simpele remote desktop omgeving wil aanbieden aan bijvoorbeeld drie klanten die een vertrouwensrelatie met elkaar hebben en alleen MS Office gebruiken, dan kun je prima met UPN werken zonder speciale policies. Zolang de TS niet meldt wat de klanten van elkaar zijn, denk ik niet dat we met complexe omgevingen moeten gaan smijten.

[Wim-Bart]

Complexiteit zit hem niet in de techniek, de techniek is zo simpel als wat. Maar de complexiteit zit voornamelijk in Licenties, aansprakelijkheid, omgaan met security, sla's, beschikbaarheid.

Een TS-omgeving stelt niks voor, kwestie van capaciteitsplanning, goed beleid inregelen, de juiste hardware sizing en de juiste implementatie van de software. Op zich veelal next next finish. Maar daarmee ben je er niet.

Maar zodra ik al ADSIEdit lees of om even een .inf file in een GPO handmatig aan te passen, of een non supported fix in AD Schema uit te voeren, dan vraag ik me af waarmee "professionals" bezig zijn.

[eatsoup]

Jammer dat er meteen door de meeste zo denigrerend gereageerd wordt. Zoals ik in de TS al aangaf ben ik bezig met een test om te kijken wat de mogelijkheden zijn.

@rupie
Natuurlijk ben ik eerst gaan zoeken naar antwoorden op mijn vraag. Echter kon niets vinden vandaar dat ik de specifieke vragen hier stel. Ik vraag toch niet om de configuratie van de terminal server?

Ik stel 2 specifieke vragen 1 over Group Policy, 1 over meerdere / enkele DC's
Blijkbaar kan dit met UPN, en blijkbaar is dit niet zo'n hele simpele vraag, anders hadden de eerste 8 reacties hier ook wel iets over gezegd..

@shadowman12 @trommelrem @ARKO.nu
Dank voor jullie reacties, ik ga hier weer verder mee stoeien

Ik ben geen trol en geen scholier meer, maar omdat ik over dit onderwerp wat minder verstand heb, moet ik het maar helemaal links laten liggen? En er vooral nooit aan beginnen. Stel je voor, je zou wat leren...

[Question Mark]

eatsoup schreef op dinsdag 17 september 2013 @ 15:03:
Ik ben geen trol en geen scholier meer, maar omdat ik over dit onderwerp wat minder verstand heb, moet ik het maar helemaal links laten liggen? En er vooral nooit aan beginnen. Stel je voor, je zou wat leren...

Je hoeft helemaal niks links te laten liggen hoor, we kunnen alleen niet ruiken wat je zelf allemaal al geprobeerd hebt. Geef in het vervolg even in een topicstart aan wat je zelf al geprobeerd hebt en waar je al op gezocht hebt (of beter nog, pas deze even aan).

Dat gezegd hebbende... ik ben wel heel erg benieuwd waar de omgeving aan moet voldoen. Prima dat je nu een test bouwt, maar elke VDI-achtige is anders en kent specifieke wensen. Waar moet deze aan voldoen?

Even wat vragen:

• Wat is de gewenste beschikbaarheid?
• Hoeveel users en hoe is de spreiding van gebruik over de dag?
• Welke applicaties gaan ze gebruiken?
• Welke data gaat waar opgeslagen worden?
• Wat zijn de eisen en wensen omtrent disaster recovery?
• Waarom kies je voor een Terminal Server en geen VDI oplossing?
• Etc.

Pas als dergelijke inzichten verkregen zijn, kan pas over techniek nagedacht worden. Zoals Wim-Bart in "Terminal Server voor hosting" al aangaf, techniek is niet het meest spannende, de invulling van randvoorwaarden en een goed stuk verwachtingsmanagement bepalen het succes van het project.

[eatsoup]

Je hoeft helemaal niks links te laten liggen hoor, we kunnen alleen niet ruiken wat je zelf allemaal al geprobeerd hebt. Geef in het vervolg even in een topicstart aan wat je zelf al geprobeerd hebt en waar je al op gezocht hebt (of beter nog, pas deze even aan).

Dat gezegd hebbende... ik ben wel heel erg benieuwd waar de omgeving aan moet voldoen. Prima dat je nu een test bouwt, maar elke VDI-achtige is anders en kent specifieke wensen. Waar moet deze aan voldoen?

De beginpost is aangepast.

Even wat vragen:

• Wat is de gewenste beschikbaarheid?
  In principe nagenoeg 100%
• Hoeveel users en hoe is de spreiding van gebruik over de dag?
  Een klant heeft me gevraagd om mee te denken over een oplossing, dit zou gaan om +/- 10 gebruikers.
• Welke applicaties gaan ze gebruiken?
  MS Office en een administratiepakket.
• Welke data gaat waar opgeslagen worden?
  Hier moet nog over nagedacht worden, maar ivm HA zal dit een SAN-achtige oplossing worden.
• Wat zijn de eisen en wensen omtrent disaster recovery?
  Nog niet met de klant over gehad, maar dit zal waarschijnlijk DMV een failover cluster naar ander datacenter.
• Waarom kies je voor een Terminal Server en geen VDI oplossing?
  De reden dat ik niet voor VDI wil gaan, is de beheersbaarheid, daarnaast is het voor mij juist de uitdaging om alles gescheiden in de TS te hebben.
• Etc.

Pas als dergelijke inzichten verkregen zijn, kan pas over techniek nagedacht worden. Zoals Wim-Bart in "Terminal Server voor hosting" al aangaf, techniek is niet het meest spannende, de invulling van randvoorwaarden en een goed stuk verwachtingsmanagement bepalen het succes van het project.

Nogmaals, ik ben het niet aan het uitrollen, ik ben vooralsnog bezig met kijken wat de mogelijkheden zijn.
Over HA en Disaster recovery zal zeker nagedacht worden, maar daar is het nu nog te vroeg voor.

[Question Mark]

eatsoup schreef op woensdag 18 september 2013 @ 10:43:
Over HA en Disaster recovery zal zeker nagedacht worden, maar daar is het nu nog te vroeg voor.

Daar ben ik het helaas niet mee eens.... Dit zal vanaf moment 1 meegenomen moeten worden. Je wilt (bijna) 100 procent beschikbaarheid, maar wilt geen gebruik maken van meerdere DC's.... That does not compute...

Verder heb je het nu ook ineens over een failover cluster... Waarvoor? Welke diensten gaat dit cluster aanbieden....

Begrijp mijn posts niet verkeerd hoor (ik weet dat het wellicht kritisch over kan komen), maar het is een prima idee dat je aan het kijken bent welke opties er allemaal zijn, maar voor het kijken naar een juiste oplossing voor je klant ben je niet gestructureerd bezig. Haal eerst de eisen en wensen boven water, en ga dan een aantal opties uitwerken (en evt. testen om wat extra kennis op te doen), om te kijken welke optie voor de klant het beste is.

Aangeven dat je voor een RDS oplossing gaat (terminal server) omdat het je voor jezelf wel een leuke uitdaging lijkt is natuurlijk iets waar je klant niets mee te maken heeft. Verder hangt het voordeel van beheersbaarheid sterk af van de inrichting en tooling. Domweg zeggen dat het een RDS-server beter beheersbaar is, is veeeeel te kort door de bocht... It all depends...

[unaco]

Ik wil geen spelbreker zijn maar als je het wiel nog uit moet gaan vinden krijg je het je klant nooit verkocht.
Initiele investering die gedaan zal moeten worden voor een dergelijke omgeving is redelijk en er is geen realistische ROI voor 10 gebruikers.

Vervolgens moet je goed voor ogen hebben welke licentie structuur van Microsoft je wilt gaan gebruiken.
Om compliant te zijn heb je niet heel veel keus:

Jouw hardware hosted diensten aanbieden = SPLA licenties
Hardware klant inc. HA / FO Cluster = OLP of OLV indien er sprake is van meerdere entiteiten.

Office 365 is irritant en geen optie i.v.m. de applicatie server tenzij het administratie pakket webbased kan.

Al me al, als jij echt je Eigen ervaring op wilt doen met RDS dan spreek je met de klant af dat ze zelf de initiele investering doen met de nadelen die daarbij horen (onderhoud, afschrijving, updates, subscripties, backup etc).

Vervolgens de redundant omgeving onderbrengen in een Datacenter en een fee per maand berekeken voor jouw diensten.

[Trommelrem]

unaco schreef op woensdag 18 september 2013 @ 11:58:
Ik wil geen spelbreker zijn maar als je het wiel nog uit moet gaan vinden krijg je het je klant nooit verkocht.
Initiele investering die gedaan zal moeten worden voor een dergelijke omgeving is redelijk en er is geen realistische ROI voor 10 gebruikers.

Maar een VDI hosten in bijvoorbeeld Windows Azure kan wel een realistische ROI hebben.

[unaco]

Yes maar dat wil de TS niet en dit is een compleet andere setup en kostenafrekening. Ben zelf overigens wel te spreken over een dergelijke oplossing voor MKB - > schaalbaar, goed te integreren in andere applicaties en kosten efficient.

[Verwijderd]

Hallo Tweakers,

Ik heb een enquete online en ik zou graag willen dat jullie deze invullen.
De enquete is anoniem.

Modbreak:

KNIP. Niet zomaar zonder toestemming vooraf enquêtes spammen ajb. Zie ook Het algemeen beleid #verbodenspam dat je bij aanmelden zult hebben gezien.

Alvast bedankt!

[ Voor 48% gewijzigd door F_J_K op 26-09-2013 13:07 ]