Windows Server 2008 R2 permitió la implementación de Terminal Server (Servicios de escritorio remoto) sin un dominio y sin ninguna insistencia en los dominios. Esto fue muy útil, especialmente para implementaciones independientes virtuales o en la nube de un servidor que se administra de forma remota para un cliente remoto que no necesita ni desea ninguna característica de ActiveDirectory o Dominio.
Esto se ha vuelto cada vez más difícil a medida que Microsoft restringe sus tecnologías cada vez más en cada versión de Windows. Con Windows Server 2012, la configuración de licencias para los Servicios de escritorio remoto es más difícil cuando no está en un dominio, pero aún es posible. Con Windows Server 2012 R2 (al menos en la vista previa) las barreras ahora son severas:
El asistente Agregar / quitar roles y características en Windows Server 2012 R2 tiene un modo de implementación RDS especial que tiene una regla que dice que si no está en un dominio que no puede implementar. Le dice que cree o se una a un dominio primero. Por supuesto, esto entra en conflicto directo con el hecho de que un controlador de dominio de Active Directory no debe ser la misma máquina que una máquina de servidor de terminal. Entonces, la tecnología de Microsoft no es tanto un sistema operativo en la nube como un clúster de nodos no deseados, necesarios para admitir la única máquina que realmente QUIERO implementar. Esto es asqueroso, así que estoy tratando de encontrar una solución.
Sin embargo, si omite ese asistente y solo va a marcar las casillas de verificación en el asistente principal de Roles / Características, puede implementar las características, pero la interfaz de usuario no está allí para configurarlas, y cuando vuelve a la página de configuración de RDS en el asistente de roles , recibe un mensaje que dice que no puede administrar su sistema de Servicios de escritorio remoto cuando inicia sesión como Administrador de computadora local, porque aunque tiene todos los privilegios de administrador que podría tener (en su sistema basado en grupos de trabajo), la IU de configuración de RDS sí No acepte esas credenciales y permita que continúe.
Mi pregunta breve es: ¿puedo obtener de alguna manera el siguiente resultado final?
- Necesito permitir que 10-20 usuarios por sistema tengan una sesión RDS (TS).
- No necesito ninguna de las opciones elegantes de RDS, a menos que Microsoft de alguna manera dependa de que esas características estén presentes. Creo que necesito el "Host de sesión RDS", ya que este es el valor de "Terminal Server". Microsoft dice que es "escritorio completo de Windows para el cliente de Servicios de Escritorio Remoto".
- Necesito configurar la licencia para que el Período de gracia no caduque dejando mi RDS no funcional, por lo que esto probablemente significa que necesito una forma de configurar las CAL de TS.
Si todo lo anterior pudiera hacerse técnicamente con el uso juicioso de PowerShell, estoy preparado para considerar incluso desarrollar todos los scripts de PowerShell que necesitaría para hacer lo anterior. No le estoy pidiendo a alguien que escriba eso por mí. Lo que estoy preguntando es, ¿alguien sabe si hay un impedimento técnico para lo que quiero hacer arriba, además de la incapacidad deliberada de la interfaz de usuario R2 2012 para los usuarios del grupo de trabajo? ¿Seguirían funcionando todas las tecnologías subyacentes si las manipulo y controlo desde un script de PowerShell?
Obviamente, una respuesta de 1 palabra Sí o No no es tan útil para nadie, por lo que la pregunta es realmente sí o no, y ¿por qué? En el caso, la respuesta es Sí, entonces cómo.