Figure 11.3 The full VDI implementation has many components to give a rich
capability set while being invisible to the end user.
The steps are as follows:
1 . Users need to find the remote desktops to which they can connect, which can be
desktop virtualization sessions (RDSH), published applications, and the VDI
sessions. While an RDP file can be created and deployed to users using various
methods, a more dynamic approach is to use the Remote Desktop Web Access role
service, which presents a browser-based list of available connections from which
the user can choose.
2 . To create the list of published applications and connections that are presented to
the user, the Remote Desktop Web Access server communicates with the Remote
Desktop Connection Broker, which has knowledge of the VDI pools, personal
desktops, and other published connections and applications through its own
communications with configured RemoteApp sources.
3 . To ascertain the exact access a user has, the Connection Broker communicates
with Active Directory, which also provides any personal desktop configurations.
4 . No matter what the exact method, be it Remote Desktop Web Access, RemoteApp,
and Desktop Connections, or a deployed RDP file, the users now have an RDP file
that can be used to initiate the connection. If the user is outside the corporate
network, a direct RDP connection would be blocked by most organizations’
firewalls. So, traditionally, the user would need to initiate a virtual private network
(VPN) secure connection or use DirectAccess. But you have an alternate solution
that does not require any end-user action or additional client-side software.
Windows Server 2008 introduced TS Gateway, which allows the RDP traffic to be
encapsulated in HTTPS (port 443) packets, which is the RD Gateway component.