It has been a long while since I looked at RDS – with Azure, Office 365 and Server 2016 there seems to be a lot of new (or better) options. To get across some of the options I have decided to do a review of Microsoft’s documentation with the aim of deciding on a solution for a client. The specific scenario I am looking at is a client with low spec workstations, using Office 365 Business Premium (including OneDrive), Windows 10 and have a single Windows 2016 Virtual Private Server.
Some desired features:
- Users should be able to use their workstations or the remote desktop server interchangeably
- Everything done on workstations should be replicated to the RDS server and visa-versa
- Contention on editing documents should be dealt with reasonably
- The credential for signing into workstations, email and remote services should be the same (ideally with a 2FA option for RDS)
Issues faced:
- The Office 365 users were created several months before the RDS server was deployed
- The Azure AD connect service which synchronizes users in an Active Directory deployment with Office 365 user (Azure AD) is a one way street, assuming the ‘on-prem’ active directory object exist already and only need to be create in Azure AD (Office 365) – see the work around for this here
- Office 365 licensing for ‘shared’ computers means that Office 365 Business Premium users can’t use a VPS – so entrerprise plans of business plus must be used.
How to configure Remote Desktop Services? After getting Active Directory installed and configure to sync with Azure AD I now need choose and implement the RDS configuration.
Starting with the Microsoft Doc we have the following options:
- Session-based virtualization – Many users per host
- VDI – Virtual machine for each user — note that if your server is already a VM this isnt really an option (nested VMs are not ideal)
Based on our clients situation – session-based make much more sense for now. Next up – what are we going to publish to the users logging into remote desktop service?
- Desktops – Providing users with the full desktop experience
- RemoteApps – Users run apps that seem to be running locally but are in fact being served via RDS
Desktops makes sense for now. So – how do we set up a Session-based desktop for remote access by multiple users?
- Add the required roles to the RDS servers (see: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure)
- Create an AD service and link it to office 365 with Azure AD Connect
As Microsoft says:
- You still must have an internet-facing server to utilize RD Web Access and RD Gateway for external users
- You still must have an Active Directory and–for highly available environments–a SQL database to house user and Remote Desktop properties
- You still must have communication access between the RD infrastructure roles (RD Connection Broker, RD Gateway, RD Licensing, and RD Web Access) and the end RDSH or RDVH hosts to be able to connect end-users to their desktops or applications.
After setting all of this up I am very happy with the results. The single source of truth for user must be the ‘on-prem’ AD. Syncing an on-prem AD service to Office 365 is almost seemless with some miner tweak required that are fairly easy to find with some googling.