Remote Desktop Services | TechMike2KX's Blog

Since last summer Microsoft has allowed Remote Desktop Services running on Windows Azure. Do note this is not to be confound with an RDS session, which is merely for remote administration purposes. The thing I’m talking about is remote application provisioning and application virtualization. This would make a great alternative for Citrix environments. Or even just fun to play around with. J Now the thing on RDS and RemoteApp is that it can be installed in 2 flavours. With several roles and features there’s some things we need to keep in mind before we start unstalling this “little gem”. on a sidenote, this is only allowed, for now under SPLA licensing terms. More info on that can be found here: http://blogs.msdn.com/b/luispanzano/archive/2013/07/15/remote-desktop-services-are-now-allowed-on-windows-azure.aspx and http://www.windowsazure.com/en-us/pricing/licensing-faq/

Step 1 : Requirements

First of all Remote Desktop Services needs Active Directory as a basis for authentication and management. Typically you will run this setup on prem unles you want to go in a hosted application / SaaS like mode, but this would mean a lot of additional management and overhead. This means that you either need to provide a new AD or make sure you can reach an AD at your disposal. For practical matters and playing around I installed a new AD (and anything else RDS related afterwards) in a single VM on Windows Azure. Do note (and as always, this is something people tend to forget easily!!!) that, when you create an AD in Widnows Azure you need to add itself as DNS. The only way this can be achieved so far is by means of PowerShell. If you don’t do it this way, well basically you will lose your machine once it gets rebooted (and trust me it will reboot at one point in time).

 1 #Specify my DC's DNS IP (127.0.0.1)
 2 $myDNS = New-AzureDNS -Name 'myDNS' -IPAddress '127.0.0.1'
 3 $vmname = 'MYVMNAME'
 4 # OS Image to Use
 5 $image = 'availablewindowsserverimage.us-127GB.vhd'
 6 $service = 'MYVMSERVICE'
 7 $AG = 'MYAFFINITYGROUPNAME'
 8 $vnet = 'MYVNETNAME'
 9 #VM Configuration
10 $MyDC = New-AzureVMConfig -name $vmname -InstanceSize 'Medium' -ImageName $image |
11     Add-AzureProvisioningConfig -Windows -Password MYPASSWORD -AdminUsername MYADMINUSERNAME |
12     Set-AzureSubnet -SubnetNames 'MYAVAILABLESUBET' #DO NOTE : THIS MUST EXIST!
13 
14 New-AzureVM -ServiceName $service -VMs $MyDC -AffinityGroup $AG -DnsSettings $myDNS -VNetName $vnet

The real magic is located in the first line itself.

Once that’s done then it’s just a mere running of the “Add Role and Feature”-Wizard or running the Powershell cmdlet’s for adding and configuring AD and DNS. (this can be done by adding the module throught Import-Module ServerManager and Import-Module ADDSDeployment , if you want to see what it might look like well here’s a sample AD deployment script (could be done through PowerShell remoting if your want to fully go for DevOps mode )

 1 Import-Module ADDSDeployment
 2 Install-ADDSForest `
 3 -CreateDnsDelegation:$false `
 4 -DatabasePath "C:\Windows\NTDS" `
 5 -DomainMode "Win2012R2" `
 6 -DomainName "MYDOMAINNAME.EXT" `
 7 -DomainNetbiosName "MYDOMAINNAME" `
 8 -ForestMode "Win2012R2" `
 9 -InstallDns:$true `
10 -LogPath "C:\Windows\NTDS" `
11 -NoRebootOnCompletion:$false `
12 -SysvolPath "C:\Windows\SYSVOL" `
13 -Force:$true

once the machine is created add an additional endpoint on HTTPS / Port 443 in order to have RDS work properly (you can also add it to your script)

Step 2 : gimme an R, Gimme, a D Gimme an S! R-D-S

Once AD is in place, we can continue with the installation of RDS itself. now as I mentioned there’s a couple of “flavors” to install. the choices that you have are somewhat limited with Windows Azure. And it makes sense somehow (you’ll see in a aminute)

Well for installing RDS you need to go to Manager and run the Add Roles and Features wizard again.

This time, instead of choosing Role-Based or Feature-based installation choose Remote Desktop Services Installation (and press the obligatory Next button of course or you’ll just sit there for hours)

Now when you didn’t install an AD (or joined a domain when doing a multi machine installation) you might get following message:

If so … welll you knnow what to do (I’ll give a hint : see the requirements)

The next choice to make is either you go the the one click way or the multi click way. When choosing Satandard Deployment you get the choice to pick all the different servers yourself (and thus enabling multi server/role deployments) where the Quick Start gives you the easy option on installing every role on one machine.

I’ll go with the Quick Start for now (but for your convenience and curiosity I’ll add the other installation options at the end of the post)

Now, the screen that pops up next is actually the flavor choice is was talking about earlier, but since we are doing this on Windows Azure our choice is a little pre-defined here.

Can you guess why? No? Look again … see it now? Yes, indeed. the first choice is the one for VM based desktop deployments. Hence maybe the reason why I didn’t call my blogpost the VDI Files (although my server is called something like that) Why won’t this work. We’ll easy, for virtualizing you actually need hardware to become the hypervisor. And since we are on Azure Vm’s already we don’t have access to an hypervisor or Hyper-V host. If you would pick the Virtual machine-based desktop deployment you would actually receive following message/error :

So just abandon that choice and pick Session-based desktop deployment. Now it could be that you still get a popup with an error/message:

this actually means that WinRM isn’t registered well somehow. to avoid/solve this just run a Powershell console in admin mode and run Enable-PSRemoting . This will configure every aspect of WinRM correctly for you with every aspect kept in mind (FW, Listener , etc etc…)

just make sure you answer [A] Yes to All twice.

if you now retry the wizard will pass to the next step:

check that the server is correct (since it’s a single machine install …. well not much choice there, is there?)

confirm and check the ‘’”Restart” option

and DEPLOY:

since it’s RDS, the machine will disappear as terminal connection for a couple of times (it messes with the remote session settings a couple of times and a reboot at the end)

Step 3: Run Forrest, Run

now all should be up and running, the time has come to give it a small test drive.Just surf to the newly created Cloudservice Url (it looks something like this https://cloudservicename.cloudapp.net/RDWeb ) and you’ll get a dirty browser windows with a certificate trust question:

This is normal (IIS auto generates a self signed cert), just click continue to this website. If all is well you’ll get a logon screen for you RDS environment.

Enter a username and password for a user existing in your domain.

now you should see 2 things: a browser window ith all accessible apps (jaaaaay!) and a system tray icon:

Unfortunately when clicking one of the apps you’ll see this

and then this

this is due to the name resolution from DNS (see step 4 for more info).

his can be easily resoled by adding the VIP of your VM and your internal FQDN of your server to your local HOSTS file. That way it can resolve directly. E.g. xxx.xxx.xxx.xxx MYSERVERNAME.MYINTERNALDOMAIN.EXT

after you do that it will as a charm. for instance I added Internet Explorer in private (or pr0n mode if you please )

and gives this as a result

Step 5: additional config

Off course now you want to start using it and adding your own apps. this is a 2 click config which is super easy!

go to the Server Manager and open the RDS management.

CLick on the left hand side on the QuickSessionCollection, which is the standard app collection

this will show all the already available apps. In the task button, select the Publish RemoteApp Programs

and then just follow the wizard (again)

Done the apps should now show up in the browser after a refresh.

and that’s it

APPENDIX:

the small issues arise

As you can see there’s a few catches here and there.

Since I did an install, it also auto-generated a self-signed cert for the HTTPS traffic. now for testing and internal references this isn’t an issue, but make sure you do it correctly for production and public facing (even if it just was for the cosmetic part of ) This does mean however that, if you want to make use of the Windows 8.x RemoteApps feature for registering the feeds and installing the app shortcuts THIS WILL NOT WORK (the CA is not trusted and Windows makes a deal out of it, which I find normal)

Another thing we’ve come across is the DNS issue, since I didn’t incorporate a Site-2-Site VPN (or even a P2S for that matter ), I’m having resolution issues with DNS –> refering from .Cloudapp.net towards the internal dns name doesn’t resolve. For production purposes you would typically handle this through your public DNS namespace servers, which will be able to resolve these hostnames.

as promised: “The Distributed Setup Screens”