Better to share File Services role with Active Directory DC role OR with the RDS Terminal Server role

The RMS blog has a post about issues/workarounds when installing SSL with RMS (note this is for RMS for Windows Server 2003):

Whew! Now for the fun stuff. To enable SSL in your RMS environment after the RMS server has been provisioned, you should follow these steps:

• Provision a new RMS server using the HTTPS option for the Intranet Cluster URL.
• Configure the old server as a Trusted User Domain on the new server. For instruction on this, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/1c96ee74-fd28-4511-be21-087e2b04c3ee1033.mspx
• Configure the old server as a Trusted Publishing Domain on the new server. For more information on this, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/1c96ee74-fd28-4511-be21-087e2b04c3ee1033.mspx
• Add a new String Value named LicenseServerRedirection registry entry to all of your RMS clients. The registry entry should be added to HKCU\Software\Microsoft\Office\11.0\Common\DRM. The value of this entry should be set to the name of the new server in the format of https://NewRMSServer/_wmcs/licensing.
• Update your Active Directory Service Connection Point to the new server. This can be done manually or via the ADScpRegister utility available from the RMS Toolkit. NOTE: You must be a member of the Active Directory Enterprise Admins group to do this.
• Retire the old RMS server.

You may need to use the ADScpRegister utility from (included wtih RMS for Windows Server 2008, located in "C:\Program Files\RMS SP2 Administration Toolkit" ) to re-register the the URL: ADScpRegister unregisterscp

Here is a guide for installing RMS on Windows Server 2008, that discusses the ADScpRegister utility.

This is very similar to what we do. We have a single TS Gateway that all our clients enter through. This has connection and resource policies that control which user groups can log on to which servers.

Each company has their own self-contained terminal server. Most companies can only log on to the one TS, but for one particularly large client, they have two. We don't do any clustering of them, just half the users connect to TS1 and the other half connect to TS2.

All the servers sit on the same network segment, and we have very strict ACLs to define who can go where on the network (i.e. nobody can really go anywhere). Our GPO for the RDS servers also greatly restricts where they can go on the server itself.

The biggest issue that we have with this setup is the automated deployment of servers for new clients. Most of the process can be automated (we use ESXi and vSphere, which has powershell integration. Same as Hyper-V does), but I haven't yet found out how to automate the modification of TS Gateway policies.

We also have one very large client who uses our hosted terminal servers. Because I didn't want to bother with managing all their password resets and new accounts myself, we gave them delegation rights over their own OU on the domain. When they started to out-grow that, for political reasons, we gave them their own domain under our forest. That's all worked pretty well so far as well, except you can't use the User must change their password on next logon as this is incompatible with TS Gateway. Same deal when their password expires, they can't log on and someone needs to reset their password manually.