To do this, we need to have two servers. The first server is the RDS server, while the second server is the Hyper-V server. The RDS server will now act as a authenticating gateway and relay for the Hyper-V server.
The advantage of this is that any computer that is XP SP3 and above can run things from the Hyper-V server that require more powerful hardware. This also allows greater administrative control and security.
You can also quickly reset the Hyper-V machines to snapshots. This is good for training environments or campus settings where machines must be restored to its original state everyday. You can also use web-access to distribute the virtual desktops wherever the user is.
VDI stands for Virtual Desktop Infrastructure. VDI has been used throughout computer history (recall dumb terminal and mainframe) but not as elegantly as we have it now.
We first create a RDS with Remote Desktop Session Host. The Session Host is the one that takes care of connectivity. The Session Host should also have the Connection Broker, the Gateway and the Web Access features installed.
Network Level Authentication is to enforce authentication before they reach the login screen. If NLA is disabled, they would be able to first Remote Desktop into the Session Host before being asked for credentials.
Licensing mode is usually left blank for home users. This would allow us 120 days of trial usage.
Next we would have to configure who is allowed to connect to the Session Host. It is a good idea to keep the Administrators group in the list. You can add both Groups or individual Users.
A new screen is the Client Experience. We can have a few choices here to choose how full a Windows 7 experience we would like for our clients. The choices can be seen in the following screenshot, which includes AV Playback, Audio Recording Redirection and Desktop Composition (Aero Interface). Audio Recording Redirection allows to record from the client which pushes the sound to the RDS machine.
SSL Certificates, as said before, requires a PKI to run fully. In a test environment without a PKI, it is recommended to use a self-signed certificate. RD Gateway needs a valid certificate to function properly.
Similar to users allowed to connect to a Session Host, you'll need to define those allowed to connect to the gateway.
TS_CAP and TS_RAP has now been renamed to RD CAP and RD RAP. Connection Authorization Policies (CAPs) allows us to decide which users can connect to the Gateway server. You can also use smart cards for authentication.
Resource Authorization Policies define what computers can be actually Remote Desktop'ed into. In a test environment, it is common to select "All computers".
NPS is Microsoft 2008's implementation of Radius. It was previously known as IAS. The usage is quite similar. You do not necessarily have to configure this for RD to work, but it's good practice to put good restrictions in place.
In the Hyper-V server, we would have to install Remote Desktop Services as well, but this time, we need to install the Remote Desktop Virtualization Host to allow Session Hosts to retrieve VM feeds from it.
We do have to do some configurations before RDS can work. Note that each Hyper-V machine can only be used by one user at one time. Note that we should name VMs with its exact FQDN to be able to make them available. We now need to prepare the VM before it can be used by users through RDS.
First, we need to make sure that the machine is set to allow remote desktop connections. We set it through My Computer > Properties > Advanced System Settings. From here, we need to also select the users allowed to remotely connect to this computer.
We now need to make use of the wmic (Windows Management Instrumentation Command-line) to add permissions for the Hyper-V machine:
wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp" CALL AddAccount "google\machine$",1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='google\\machine$'" CALL ModifyPermissions 0,1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='google\\machine$'" CALL ModifyPermissions 2,1
wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='google\\machine$'" CALL ModifyPermissions 9,1
Net stop termservice
Net start termserviceReplaced the underlined with the Hyper-V machine's domain and name (the Hyper-V Host, not the VM). We now need to enable Remote RPC from the registry. From the VM, browse to:
HKLM/SYSTEM/CurrentControlSet/Control/Terminal ServerLook for the AllowRemoteRPC and set it to 1. After that, we need to add the exception into Firewall for Remote Service Management. We only need to allow Domain.
We're done with the client now. At this point, we'll need to configure the RD Connection Broker to work with Personal Desktops.
On the next page, we'll need to specify the Session Host. Since we're on the same system, we can simply type in this machine's FQDN. The same needs to be done for Web Access server.
After that, we can assign users to specific machines.
Right now there would be a problem with the Web Access as we're using a self-signed certificate. So now we'll have to add RD sources into the Web Access. To do this, we need to log into Web Access with a Domain Admin account.
Once we're in, we can specify the source. We want to use the RD Connection Broker as the source, so select the source and type in the machine's FQDN.
No comments :
Post a Comment