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:

1. 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.

2. 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.

Me encontré en el mismo escenario que tú. La implementación de Escritorio remoto en un cuadro independiente de Server 2012 es bastante difícil, porque los chicos de Microsoft no le permiten ejecutar esto en una red sin dominio y, si lo hace, no puede administrar todas las configuraciones.

Por lo tanto, puede instalar una caja basada en grupos de trabajo y obtener los roles de Escritorio remoto trabajando en ella. También necesitamos instalar las funciones de Licencia de escritorio remoto en la misma máquina. Pero, una vez en este punto, incluso si tiene CAL RDS adecuadas instaladas en el servidor, cuando el usuario inicia sesión, recibe el mensaje de que el período de prueba está activado.

Finalmente logré hacer que funcione, al menos algo así como los viejos Servicios de Terminal que solíamos conocer. Eso funciona para mí en dos máquinas de producción de pequeños clientes que necesitan RDS pero no pueden permitirse tener dos servidores en su red.

Aquí vamos:

1. Instale las licencias de Escritorio remoto y los servicios de rol Host de sesión de Escritorio remoto mediante los siguientes pasos:

   • Administrador del servidor abierto
   • Haga clic en Administrar y seleccione Agregar roles y características
   • Seleccione instalación basada en funciones o basada en funciones
   • En Servicios de escritorio remoto, elija Licencia de escritorio remoto y Servicios de rol Host de sesión de escritorio remoto.
   • Continuar con la instalación

2. Agregue el servidor de licencias al grupo de servidores de licencias de Terminal Server y reinicie el servicio de escritorio remoto (puede usar licmgr.exe)

3. Agregue las licencias al servidor de licencias.

4. Configure la función Host de sesión de escritorio remoto con para usar el servidor de licencias de escritorio remoto local. Sigue estos pasos:

   • Abra PowerShell como administrador
   • Escriba el siguiente comando en el indicador de PS y presione Entrar:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

Ejecute el siguiente comando para configurar el modo de licencia (Nota: Valor = 2 para Por dispositivo, Valor = 4 para Por usuario, usamos por usuario)

$obj.ChangeMode(4)

Ejecute el siguiente comando para reemplazar el nombre de la máquina con License Server ( mylicenseserveres el nombre de su servidor):

$obj.SetSpecifiedLicenseServerList("mylicenseserver")

Ejecute el siguiente comando para verificar las configuraciones que se configuran utilizando los pasos mencionados anteriormente:

$obj.GetSpecifiedLicenseServerList()

Debería ver el nombre del servidor en la salida.

Una vez hecho esto, reinicie el sistema e inicie sesión con cualquier usuario (si usa un grupo de trabajo, sabe que sus usuarios deben ser parte del Remote Desktop Users) y el mensaje del período de prueba desaparecerá.

Fuente de todo este desastre: http://support.microsoft.com/kb/2833839

Administrar con Powershell

Hay algunas cosas con las que puede manejar Powershell. Para ver los comandos intente:

import-module RemoteDesktop get-command -module RemoteDesktop

Hay una lista de comandos que puede ejecutar a través de Powershell para administrar su caja. Sin embargo, he probado algunos, pero algunos de ellos requieren que tengas algunas características adicionales instaladas, que no se pueden implementar en el escenario del que estamos hablando.

El feo camino

Si nada de lo anterior funciona para usted, hay una manera de restablecer el período de gracia a los 120 días iniciales. Por supuesto, no recomiendo hacer esto, ya que el usuario seguirá notando el mensaje. Por supuesto, deberá comprar las licencias adecuadas.

Para restablecer el contador, simplemente elimine esta clave de registro:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Grace Period

Por supuesto, necesitará privilegios adicionales para hacerlo, ejecutar regeditcomo administrador no funcionará. Prueba esto:

• Obtén PSEXEC
• Iniciar un cmd como administrador
• correr psexec -s -i regedit.exe
• eliminar la clave deseada
• reiniciar

Espero que algo de esto funcione para ti. Si realiza algunos avances con Powershell y RDS, infórmenos.

Cuando estaba configurando un entorno en un laboratorio para probar esto (una implementación simple de RDS sin un dominio), encontré la respuesta a su pregunta, aunque no es la que desea escuchar.

RDS en [Server 2012 y 2012 R2] requiere que todos sus servidores se agreguen a un dominio . Eso, de acuerdo con un administrador de programas de Microsoft en el equipo de Virtualización de escritorio remoto, que escribió el artículo del blog de MSDN vinculado, Configuración de una nueva implementación de Servicios de escritorio remoto con Windows PowerShell.

Entonces, lamento que no sea la respuesta que querías, pero parece ser bastante autoritario para mí. No puede hacer lo que desea, porque Microsoft ha decidido que la membresía de dominio sea un requisito técnico para los servidores RDS en Server 2012 y 2012 R2.

Encontré que durante la prueba es importante tener al menos 1 NIC configurada con IPv6 habilitado. Esto se requería como el loopback para que el servidor de licencias RDS se hablara a sí mismo. Intentó resolverlo a través de IPv6 para hacerlo (como se ve en Pings). Tenía IPv6 deshabilitado en ambas NIC y esto provocó que el servidor no volviera a funcionar correctamente.