RDS + Connectionbroker + Sessionhost omgeving

Status
Niet open voor verdere reacties.
D

djbosanac

Gebruiker
Lid geworden
13 aug 2008
Berichten
293
Beste alle,

Ik heb een vraag omtrent de nieuwe RDS wat vroeger de terminal server was.
Heb al veel tutorials gevolgd maar met weinig resultaat. Laatst nog http://www.concurrency.com/blog/rds8-standard-3-node-remoteapp-deployment-on-windows-server-2012/ gevolgd.

Alleen ik kom er niet uit, weet niet waar het fout gaat.

Hoe ziet mijn situatie eruit?
Ik heb 5 servers
Server 1= RDS-DC / AD-DS
Server 2= Connection-broker1
Server 3= Sessionhost1
Server 4= Sessionhost2

Vanaf server 2 t/m 4 zijn als memberserver toegevoegd aan me RDS-DC.
Ik heb wil nu dus gaan inloggen lokaal met een cliënt maar ik krijg error dat de server niet veilig is (certificaten issue) echter heb ik gewoon eigen certificaten aangemaakt. (Untrusted / Ok) Maar alsnog kan ik niet inloggen.
 
Niet helemaal duidelijk wat de precieze melding over het certificaat is en wat je doet zodra de certificaten melding ontstaat.
In ieder geval vermoed ik dat je hetzelfde certificaat dat je op de Connection-Broker hebt geïnstalleerd ook op de andere RDS-servers zou moeten hebben.

Kijk eens hier voor links, plekken om te kijken/controleren, en kijk zeker ook in de commentaren.
En mogelijk bevat ook deze link nuttige informatie voor je.

Is verder koffiedik kijken met zo weinig informatie.

Tijs.
 
Laatst bewerkt:
Ik zal even het verduidelijken ME HELE situatie.

Ik werk in VMware Workstation 10.0.1
Daar heb ik nu 4 lokale servers draaien nog met ieder een eigen rol binnen de RDS omgeving.

Server 1 dient als Domain controller + AD-DS
Server 2 dient als connection broker/ en gateway <- deze moet de drukte beheren en over de 2 sessiehosts gaan verdelen.
Server 3 dienst als sessiehost1
Server 4 dient als sesssiehost2

2rg2f5s.png

Heb via een create an self-sign certificate alle certificaten aangemaakt en toegepast.

e9b0ic.png

Dit is de foutmessage wat ik krijg. Echter krijg ik dit ook wanneer ik via de exteren bureaublad wil inloggen krijg ik deze error.
 
Ik krijg sterk het idee dat het certificaat niet rds1.jhc-ict.local dekt! Dat is een ander probleem dan dat het untrusted is. Dat het untrusted is zou er nog achteraan kunnen komen, maar eerst moet het certficaat de betroffen server dekken!
Oftewel denk ik dat het certificaat verkeerd is.

Geef eens alle informatie van dat certificaat.

Tijs.
 
Ik vermoed dat dit een vervolgvraag is op die je hier al gesteld hebt.
 
jackall zei:
Ik vermoed dat dit een vervolgvraag is op die je hier al gesteld hebt.
Klik om te vergroten...

@jackall: Die andere link is wel RDS gerelateerd, maar gerelateerd aan lidmaatschap van de Remote Desktop Users globale groep in het domein (+ evt. policies omtrent RDS en "lokaal inloggen" op de RDS-servers).
Er is dus geen (directe) relevantie met de huidige vraag.

Tijs.
 
2yzijyr.png

152cpra.png

eqoygi.png


Ik heb hier even de certificaat weergeven.
Hopelijk bedoel je dit, of iets anders....

Het kan zijn dat ik het op de verkeerde heb toegepast.
Uhm volgens een tutorial moest je het op de RDS-broker toevoegen.
En via de broker moest je dan inloggen. Maar voor remoteAPPS log je weer in via je dc fqdn/RDWEB dus ik weet niet :(
 
Laatst bewerkt:
Het gaat mij (nu) om de Details van het certificaat.
Geef alle onderdelen daarvan, waarbij je alleen de leesbare velden geeft [de vingerafdruk bijv. laat je achterwege.]

Tijs.
 
hallo,

kan je me uitleggen welke onderdelen daarvan? QUA certificering weet ik niet echt zoveel.
En hoe je zulke certificaten het beste open kan maken om te kijken ??
 
In posting #7 had je de informatie al in beeld, (tabblad Details van het certificaat; ik wil de inhoud van elk veld), alleen zie je zo maar 1 onderdeel van de Details, dus die moet ik alle onderdelen van Details hier uitgeschreven zien (of in schermafdruk etc., als ik de informatie maar zie).
Dus even alle onderdelen van Details langslopen (Uitgebreid sleutelgebruik, Alternatieve naam voor onderwerp etc.) én die even laten zien, waarbij ik (o.a.) NIET geïnteresseerd ben in de Identificatie van de onderwerpen, Vingerafdruk, Openbare sleutel etc., omdat die puur hexadecimale gegevens bevatten.
Nu heb ik niets om mee te werken/om naar te kijken.

En over certificaten leren, daar kun je voor bij Microsoft, Google en (mogelijk) Youtube terecht. Of koop een boek.

Tijs.
 
Laatst bewerkt:
Vlgs. mij staan 2x precies dezelfde detail-velden in jouw schermafdrukken (dus bijlage 1 en 5 zijn gelijk, 2 en 6 zijn gelijk etc.)
Ik mis dus nog andere detail-velden (er staat een schuifbalk aan rechterkant, die moet nog naar beneden voor nog meer detail-velden).

Tijs.
 
 
Nogmaals vermeld: Ik heb het idee dat het bereik van de certificaten te klein is, dus dat enkele server(s) die je ermee wilt authenticeren er niet mee zijn gedekt en (dus) op de client computers een foutmelding opleveren.

Ik zal kijken of ik vanavond of morgen er naar kan kijken.

Tijs.
 
Je moet beter lezen:
Het gaat er niet om of je ze op voldoende servers toegevoegd hebt, maar het bereik van het certificaat zelf.
Oftewel: Komen de (DNS-)namen van de servers waar je 'm toegevoegd hebt wel voor in het certificaat (al dan niet via een wildcard)? En bedenk dat dan niet alleen interne DNS maar (evt.) ook publieke DNS kan zijn en NETBIOS namen!

Dus (zo even als voorbeeldje), je hebt 1 certificaat:
Stel je hebt 3 servers (server-01, server-02, server-03), je hebt interne dns windowsdomein.local en externe dns zwavelzuur.nl (met je a-records: mailserver (=server-01), webserver (=server-02) en ftpserver (=server-03))
dan moet in het certificaat gedekt zijn (als public name):
server-01
server-02
server-03
server-01.windowsdomein.local
server-02.windowsdomein.local
server-03.windowsdomein.local
mailserver.zwavelzuur.nl
webserver.zwavelzuur.nl
ftpserver.zwavelzuur.nl

Dát is wat ik bedoel met bereik van het certificaat.

Tijs.
 
Laatst bewerkt:
Als ik even kijk naar de certificaat. en ik ga er vanuit alternatieve naam dat het me dns moet zijn.
Dan is die inderdaad fout qua naam want dan staat er rds1.pfx als naam.

want op de post hiervoor heb ik laten zien dat ik door de hand van een zelf gemaakte certificaat het allemaal naar rds1.pfx is gegaan.
Betekend dat ik qua naam dus rds-broker1.jh-ict.local.pfx naam moet bevatten of?

wanneer ik naar me certificaten manager ga, en ik ga naar trusted certificates dan zie ik ook alle aangemaakte certificaten niet die ik heb gemaakt tijdens de RDS installatie.
Terwijl je vinkje moet aanvinken dat het certificaat onder trusted wordt gezet onder root.

http://gyazo.com/918c59e615855ddac981d2593e606c29

nu staat het allemaal zo kan eventueel de certificaat aanpassen.....
 
Laatst bewerkt:
Beste dnties,

Ik heb het anders aangepakt ik werd er helemaal mesjogge van.
Heb alle servers weggegooid en ben alles opnieuw aan het installeren.

heb nu een 5 tal servers zoals eerst alleen met WA (web access) als extra server ipv op een andere server.
Wat ik heb aangepast is alleen ipv via een gateway heb ik gewoon een DNS AANGEMAAKT MET DAAR 2X dezelfde naam (a record) met de ip's van beide sessionhost servers.
Nu wanneer ik wil inloggen op een externe bureaublad werkt het meteen.

echter wanneer ik in een rds omgeving ben en ik wil me remote apps opstarten dus in mijn geval rds-sh.boneros.local/RDWEB opent die het niet :(
En hoe kan je zien dat de conntection-broker ook daad werkelijk het verdeeld over 2 servers
???
 
Laatst bewerkt:
Is niet zo ingewikkeld: Als de DNS-server round-robin doet (en dat is standaard het geval) wordt afwisselend (het ip-adres van) RDP-server1 en RDP-server2 als session host server geselecteerd door de RDS-broker.

Overigens staat hier een checklist hoe RDP/RDS geconfigureerd moet worden en hoe je kunt controleren of het goed is ingericht.
En jouw verhaal van 2x (met verschillende ip-adressen) de RDS session hosts toevoegen wordt er ook in genoemd, en linkt naar deze link.
To configure DNS, you must create a DNS host resource record for each RD Session Host server in the farm that maps the RD Session Host server’s IP address to the RD Session Host server farm name in DNS.
Klik om te vergroten...

Zover ik kan nagaan doet de RDS Broker dus geen échte load balancing, maar realiseert het op basis van wat round-robin DNS als ip-adres aangeeft om de gevraagde sessie mee te verbinden.
Als je het wilt checken: Maak meerdere RDP sessies met de farm tegelijk en bekijk met tsadmin.exe / tsadmin.msc de session hosts, waarbij je zou moeten zien dat beide server (ongeveer) evenveel sessies hosten.

Tijs.
 
Laatst bewerkt:
bedankt voor de informatie.
Ik zie dat het inderdaad niet echt een load-balacing was maar dacht proberen waard.
Echter op welke server moet ik die tsadmin.exe gaan uitvoeren de commando want op me DC krijg ik dat die niks kan vinden qua commando.
Of moet het in een cmd ????
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan