Isso é muito parecido com o que fazemos. Temos um único Gateway TS que todos nossos clientes acessam. Isso tem políticas de conexão e recursos que controlam quais grupos de usuários podem fazer logon em quais servidores.
Cada empresa tem seu próprio servidor de terminal independente. A maioria das empresas só pode fazer logon no TS, mas para um cliente particularmente grande, elas têm dois. Nós não fazemos nenhum cluster deles, apenas metade dos usuários se conectam ao TS1 e a outra metade se conecta ao TS2.
Todos os servidores estão no mesmo segmento de rede e temos ACLs muito restritas para definir quem pode ir onde na rede (ou seja, ninguém pode realmente ir a qualquer lugar). Nosso GPO para os servidores RDS também restringe muito onde eles podem ir no próprio servidor.
O maior problema que temos com essa configuração é a implantação automatizada de servidores para novos clientes. A maior parte do processo pode ser automatizada (usamos ESXi e vSphere, que tem integração powershell. Igual ao Hyper-V), mas ainda não descobri como automatizar a modificação das políticas do TS Gateway.
Também temos um cliente muito grande que usa nossos servidores de terminal hospedados. Como eu não queria me preocupar em gerenciar todas as suas redefinições de senha e novas contas, concedíamos a eles direitos de delegação sobre sua própria UO no domínio. Quando eles começaram a crescer, por razões políticas, nós lhes demos seu próprio domínio sob nossa floresta. Isso tudo funcionou muito bem até agora, exceto que você não pode usar o User must change their password on next logon , pois isso é incompatível com o TS Gateway. Mesma oferta quando a senha expira, eles não podem fazer logon e alguém precisa redefinir sua senha manualmente.