[server 2012] Problemen met gpp en het mappen van drives

[Vijfje5]

Kan iemand mij helpen met het volgende probleem?

Situatie:
1x DC (Windows Server 2012 R2) met RD-gateway, RD-Licensing, RD-Web.
1x TS (Windows Server 2012 R2) met RD-Connection Broker, RD-Sessionhost.

Het probleem:
Als ik rechtstreeks RDP (3389) naar de TS als gebruiker, gaat alles goed. Hier krijg ik netjes de gemapte drives te zien.

Maar als ik via de RDWEB verbind, krijg ik de drives die ik via gpp het opgegeven niet te zien. Tevens wordt er ook ineens een 2e sessie gemaakt terwijl de optie single session per user is opgegeven in GPO.

Ik heb alle logs gecontroleerd, hier is niets in te vinden.

[Razwer]

remoteapp is een ander soort sessie dan full desktop dus logisch dat die sessie niet word meegenomen.
verder, hoe map je de drives? GPO prefs? zou gewoon moeten werken. remoteapp en full desktop rds werkt precies hetzelfde.
Hoe heb je de gpo prefs gescoped? als je de GPO in user policy zet en scoped op het computer object van je sessionhost moet je wel loopback processing aanzetten. Dat is de recommended way voor RDS deployments.

waarom heb je btw je broker op je sessionhost? niet super handig...
Beter zet je de broker apart of op je gateway bak.
verder zou ik rdweb en rdgateway niet op een DC plaatsen gezien je dit aan internet hangt. Het is een stuk idealer als je een extra bak deployed hier voor.

[ Voor 56% gewijzigd door Razwer op 23-01-2014 13:05 ]

[Semt-x]

Kleine kanttekening; "Dat is de recommended way voor RDS deployments."
Dat klopt als de gebruikers ook op desktops inloggen EN tegenlijk die drivemapping op desktops expliciet niet nodig hebben of niet mogen hebben.

Loopback is bedoeld om user instellingen voor terminal servers te kunnen laten afwijken ten opzichte van user instellingen op desktops.
Bijvoorbeeld, als je in een GPO een user instelling zet waarin expliciet staat dan de shutdown knop getoond moet worden. Vervolgens logt die user in op een terminal server, wordt de shutdown knop van de terminal server zichtbaar en kan die user de terminal server uitzetten.
Om dit te voorkomen is de loopback toegevoegd. zodat je specifieke user instellingen in een terminal server sessie kan aanpassen tov desktop sessie.

In de situatie die TS schetst, haal ik niet dat de geburikers naast Termina Server ook desktops gebruiken. en dat drivemappings niet op die desktops gemaakt mogen worden. Als een van beide voorwaardes niet opgaat is Loopback niet nodig.
Loopback heeft met groot aantal GPO's een enorme impact op je snelheid warmee GPO's worden door gevoerd. Ik ben altijd voorzichtig met Loopback.

Ervan uitgaande dat de gebruikers alleen terminal server gebruiken. Zou ik de drivemapping in de user GPO zetten en loopback niet gebruiken. Als je het al moet gebruiken, begin met 'Replace' mode, en NIET Merge! Merge is nog veel "duurder".

[Razwer]

Merge lost alleen wel de issues op die jij schetst waar de TS tegenaan zou kunnen lopen mocht hij users hebben met desktops of meerdere farms met andere instellingen. Verder de de "cost" van loopback, zoals als jij het schetst, een stuk lager dan je doet lijken. Het is ook afhankelijk van het aantal GPO's wat je applied en wat ze mee dragen.
Ik beheer duizenden RDS machines, allemaal met loopback geconfigureerd (ik werk voor een cloud boer).

Hoe dan ook wil je GPO scheiden van je desktops/andere farms omdat er altijd wel een uitzondering is. Is die er niet ben je iig voorbereid mocht dat er in de toekomst wel komen.

In die gevallen kan merge een gevaar zijn afhankelijk van de instellingen die meegegeven worden aan de desktop/andere farms vs de terminal server/farm die je scoped.
Hier wat meer over loopback processing: http://blogs.technet.com/...cle-back-to-loopback.aspx

belangrijkste stuk

User Group Policy loopback processing is a computer configuration setting.
Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value. In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.
Merge mode applies GPOs linked to the user object first, followed by GPOs with user settings linked to the computer object.
The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.
Replace mode completely skips Group Policy objects linked in the path of the user and only applies user settings in GPOs linked in the path of the computer. Use replace mode when you need to disregard all GPOs that are linked in the path of the user object.

[ Voor 56% gewijzigd door Razwer op 23-01-2014 15:03 ]