Ahora que siguiendo las seis notas anteriores tenemos toda nuestra infraestructura objetivo instalada, configurada y probada, es el momento ideal para hacer el licenciamiento legal necesario
Es importante dejar este paso para el final, ya que tenedremos tiempo suficiente para hacer todas las pruebas de configuraciones que necesitemos usando las funcionalidades completas por un plazo de 90 días. Luego de ese plazo los clientes dejarán de poder conectarse; y además a los 120 días dejará de funcionar el servicio
La importancia radica en que una vez activado el servidor de licencias e instalada la clave de licencia de clientes, si hubiera que reactivar en una nueva instalación ya habría que ejecutar pasos adicionales
Utilizaré como servidor de licencias (RD-License Server) al Controlador de Dominio (DC1) donde como vimos hasta ahora estamos haciendo en forma centralizada toda la configuración
Simplemente pulsamos sobre el icono verde correspondiente para comenzar el asistente correspondiente
Agregamos al servidor correspondiente
E ingresamos para hacer la configuración del mismo
Seleccionamos el tipo de licenciamiento que usaremos, en mi caso elegiré por usuario
Y cerramos el cuadro abierto
Vemos que ya el correspondiente icono se ha grisado (rol instalado) y lo configuraremos ingresando por “Tools / Terminal Services / Remote Desktop Licensing Manager” (Si, todavía dice “Terminal Services” que fue cambiado en Windows 2008)
Miremos un poco las propiedades del servidor
Aunque el sistema preguntará durante el proceso de activación, podemos ingresar valores por omisión que tomará, tanto del método de conexión, como información adicional. Pueden hacerlo ahora como lo hice yo, o luego durante la activación
El proceso de activación de licencias de Escritorio Remoto tiene dos pasos: primero hay que activar al servidor de licencias, y luego se activan las licencias de clientes. Debemos comenzar por el primero
La siguiente es la infromación mínima requerida
Y ya, por omisión, queda marcada la opción para comenzar el segundo paso: activar las licencias de cliente
Observe la cantidad diferente de opciones de licenciamiento, deben elegir la adecuada que tenga cada uno
Yo, seleccioné la mía
Acá es donde cada uno debe ingresar su propia clave de licenciamiento
Justo justo se me ha perdido la captura de pantalla donde ingreso la clave, bueno, supongo que cada uno tiene su clave legal ¿correcto? :)
Ya parecía que iba a quedar todo listo, pero no, aún faltan un par de cosas. Vemos que el servidor muestra un signo de exclamación amarillo, así que todavía hay que hacer alguna configuración. Ingresemos por “Review”
Vemos que debemos agregar el servidor al grupo “Terminal Server License Servers”, lo hacemos mediante el botón “Add to Group”
Si, ya sabemos que hay que ser administrador
Y todavía lo último, hay que reinciar el correspondiente servicio
Al fin :)
Lo que hice a continuación, es crear sesiones remotas (con RemoteApp) tanto desde CL1 como desde CL2, para constatar que el otorgamiento de licencias era lo esperado, y así fue
Podemos inclusive obtener reportes de las licencias otorgadas
Con esta nota vemos que hemos completado todos los pasos necesarios para crear la infraestructura propuesta originalmente, instalando y configurando todos los roles de Escritorio Remoto, y demostrando la funcionalidad de cada uno, con acceso de los clientes tanto desde la red interna, como desde redes externas, y sin comprometer la seguridad, ni necesidad de usar VPNs
WindowServer 
Comentarios
Hola Guillermo, buen día!
Por favor podrías buscar esa captura de pantalla que se te perdió, que es la que más necesito :)
¿Cuál no llegas a ver? porque yo desde acá veo todas sin problema. A veces si la conexión a Internet es lenta o anda con problemas me ha pasado, y con paciencia y F5 se consigue
Pero si no consigues aún así verla, avísame y aunque sea te la envío por mail
buenas guillermo una consulta, las licencias se otorgan automáticamente a los clientes que se van conectando,o yo puedo asignarlas manualmente a estos(o administrarlas a que clientes si y que otros no se ñesúede otorgar licencias),o si por algun motivo un cliente se conecto pero no quiero que tenga licencia como haria para quitarsela…saludos
Hola Leo, no, no se puede controlar eso; entiendo que si se pudiera hacer eso se podría manipular totalmente el sistema de licencias
Se pueden revocar licencias por Dispositivo solamente, y las de cliente se liberan luego de cierto tiempo sin uso
Te dejo dos enlaces que tienen algo de infor
Revoke a Remote Desktop Services Per Device Client Access License
https://technet.microsoft.com/en-us/library/cc732416(v=ws.11).aspx
Manual Revocation of Client Access Licenses (CALs) – Enterprise Mobility and Security Blog
https://blogs.technet.microsoft.com/enterprisemobility/2008/02/15/manual-revocation-of-client-access-licenses-cals/
Hola guillermo, encantado de conocerte, tengo una cuestion. Una vez tengamos toda la infraestructura creada y todo funcionando correctamente. Imaginamos que tengo 40 licencias instaladas en cada server: RDSH «40 en el RDSH1 y 40 en el RDSH2» pero quiero que mis usuarios accedan a los gateways sin saber expecificamente a cual accede. mi pregunta es, ¿debo de facilitar el acceso por el server RD-WA-CB-GAT y el es el encargado de distribuir la conexion? es algo que no entendi bien y quizas este haciendolo mal.
Muchas gracias.
El gusto es mío también :)
Primero una aclaración, las RDCAL son para todo el Bosque/Dominio, no son para cada servidor
Ahora a la pregunta, pero todo depende de cómo accedan los usuarios. Si acceden por RD-Web o RD-Gat, el RDCB es el que se encarga de repartir la carga entre los servidores
En cambio si acceder directamente al escritorio remoto por conexión RDP, creo que no hay forma, salvo que hubiera un balanceador de carga externo
De acuerdo, entiendo entonces.
Vale pues entonces digamos que el acceso se hara por RD-Gat.
Mi caso seria entonces 2 RDSH, el role de RD-Gat debe de estar instalado entonces en el RD-WA-CB-GAT y entonces este sera el servidor que veran los usuarios a la hora de querer acceder a los RDSH?
No se si me estoy haciendo un lio.
gracias.
Me estás haciendo revisar las notas anteriores … :) porque te imaginarás que no recuerdo todas en la memoria y qué configuración hice :)
En la nota 6, la que usa el RD-Gat, la nota hace conexión a un RDSH específico, y por lo tanto puede ver en qué servidor está, esto no hay forma de ocultarlo
Para que no vea, qué servidor, pienso que la única forma es usando RemoteApp, y tengo dudas. O sea que se conecte al RD-Web
Heheheheeh cierto, es complicado el proceso.
Pues he seguido segun los pasos 6 y esta bien configurado.
Lo que me he dado cuenta fue lo siguiente:
Al tener todo configurado bien, si creo un grupo especifico para remote desktop «aparte de mi grupo admin» cuando el usuario intenta acceder por la IP que tiene el RD-WA-CB-GAT «por RDP» el ya lo redirige segun la disponibilidad o carga en los RDSH.
Resumiendo. Por el RDP funciona, lo unico hay que crear un GPO con grupos de restricciones y poner los usuarios solo con acceso a remote desktop users y aplicar sobre el pool de las RDSH.
Fue de muy gran ayuda este tutorial «enorme :)»
Eres un maquina. Muchas gracias.
Son muchas las combinaciones posibles que se pueden hacer
En la nota 2, en lugar de crear el grupo para acceso remoto, como es sólo una demostración, lo que hice es crear dos usuarios, y los incluí directametne en el grupo «Remote Desktop Users» de cada RDSH, pero por supuesto que lo correcto es hacerlo como dices, por grupos
El tema de acceder por nombre o por IP, puede llegar a dar advertencias de seguridad o aún impedir el acceso. Todo tiene que ver a quién está otorgado el certificado digital. Si es por nombre, no lo puede validar por IP, y a la inversa
Me alegro te haya servido, hay unos cuantos artículos relativos a Escritorio Remoto
Hola Guillermo he seguido desde hace tiempo tus notas…Hasta el punto que he implementado los servicios de escritorio remoto en Windows Server 2016. Y todo ha salido bien con tus notas de Windows Server 2012.. Pero tengo una duda con el certificado autofirmado del servidor de puerta de enlace. Pues al generar el certificado, éste se genera con la extensión .pfx y al momento de importarle en el equipo cliente éste falla la autenticación cuando se realiza la conexión desde Internet. Por cierto he creado un registro tipo A en servidos DNS externo para utilizarlo también en el certificado autofirmado (rd.midominio.co) y así poder resolver el nombre de la puerta de enlace externamente.
Hola Luis, me alegro te sirvan las notas
Un certificado es similar a un documento de identidad: indica la identidad de un servidor, porque lo afirma una Autoridad Certificadora
Para que se tome como válido, el cliente debe confiar en la Autoridad Certificadora
Al usar un certificado autofirmado, el cliente debe tener como Autoridad Certificadora Raíz al certificado
Si yo te dijera que soy la «máquina Guillermo», porque lo dice la «Autoridad Certificadora Guillermo», primero debes configuar en la «Autoridad Certificadora Guillermo» ¿se entiendo lo que escribí? :)
Hola Guillermo, gracias por tu explicación, ya solucioné lo del certificado, me he asegurado que siempre en el cliente se instale o importe en «Ubicación de Almacén = Equipo Local» y que lo guarde «Entidades de Certificación Raíz de Confianza». Al hacer esto, ya el equipo cliente confia en el servidor de puerta de enlace tanto para la conexion RDP como la conexion RDWeb (https = seguro).
Ahora con el fin de permitir la impresion remota de los clientes fuera de la red (desde internet), quiero implementar el ROL «Servicios de Impresión y Documentos», pero no sé si implementarlo en el servidor de Controlador de Dominio (DC) o implementarlo en el servidor de RDSH, pues a éste servidor es al que se conectaran externamente.. Gracias por la sugerencia que me puedas brindar. Un caluroso saludo desde Bogotá – Colombia
Hola Luis, es así el tema de certificados, se debe confiar en la CA que lo expide, y al ser de tipo Raíz tiene que estar en el lugar correspondiente
Personalmente trato de nunca poner servicios adicionales en los DCs. Teniendo más de un DC cualquier problema que tenga uno, otro provee el servicio y es más fácil reinstalar que recuperar; pero si tiene roles adicionales esto es un problema
Cuidado con la funcionalidad de servidor de impresión, porque dependiendo de cantidad de impresiones simultáneas, tipo de impresión y clase de impresora, puede «no ser nada» o ser una carga importante. Aunque lógicamente que esté en el propio RDSH es una ventaja
Guillermo, una pregunta por si pudieses orientarme:
He preparado un sistema siguiendo tus indicaciones al pie de la letra, con todo funcionando debidamente. En mis pruebas, puedo acceder a las aplicaciones mediante RDWeb, con balanceo de carga correcto y todo tal cual explicas en estos tutoriales (excelentes ciertamente, mil gracias). Ahora bien, cuando intento acceder mediante mstsc.exe, puedo hacerlo con las credenciales del administrador, pero con los usuarios de menor nivel me dice: «Se denego la conexion porque las cuentas de usuario no estan autorizadas para el inicio remoto de sesion». Insisto, ese mismo usuario si puede entrar mediante https://mi.dominio.com/RDWeb y ve las aplicaciones publicadas y las ejecuta.
Como prueba, entro al DC1, y lanzo desde ahi el «mstsc.exe /admin» contra uno de los dos servidores RDSH que sirven la aplicacion en cuestion y puedo hacerlo como administrador, pero no como el usuario que te comento.
Este usuario pertenece a un grupo de seguridad «dominio\Tiendas» que esta habilitado en las propiedades de la coleccion para el acceso a esos RDSH (de hecho, como digo, funciona por RDWeb)
Si consulto la configuracion del host RDSH, veo que el grupo de seguridad «dominio\Tiendas» esta incluido en el grupo local «Usuarios de escritorio remoto».
He buscado todo lo que se me ha ocurrido, sin exito.
Agradeceria alguna pista…
Un saludo desde España!
Hola Carlos, gracias por tu comentario :)
A mi entender lo que puede estar molestando es el «/admin» porque eso es para tomar la sesión de consola del administrador. Prueba sin el modificador
Efectivamente era ese el fallo en las conexiones desde el DC1, pero en realidad el problema que tengo para andar probando estas cosas (y molestandote) es que, desde hace algun tiempo, no me funciona correctamente el acceso desde internet mediante mstsc.exe. Lo configure en su momento (siguiendo el tutorial) para que utilizase el servidor de puerta de enlace de RDS y funciono bien. Con el tiempo no se que toque o cambie pero dejo de funcionar y ahora solo puedo entrar si lo configuro para que NO use un servidor de puerta de enlace de RDS. Haciendo asi, el primer usuario que se conecta accede bien. Ahora bien, lo curioso es que si intento entrar con un segundo usuario sin que el primero haya cerrado sesion, este segundo no accede: me pide la contraseña, muestra los avisos de Estableciendo conexion, Estimando calidad de la conexion e Iniciando conexion remota, para al final darme el tipico error de «Escritorio remoto no puede conectarse al equipo remoto por una de las siguientes razones: 1)No esta habilitado el acceso remoto al servidor 2)El equipo remoto esta apagado…»… etc
Alguna idea?
Hola Carlos, ya sé cuál es el problema: «no se que toque o cambie pero dejo de funcionar» ja ja ja
Es difícil solucionar ya que no hay datos, ni podría hacerlo desde acá, como para comenzar a investigar, revisa los logs tanto en el cliente como en los servidores
Trackbacks
[…] Remote Desktop – Escritorio Remoto: Instalación y Activación de las Licencias (RD-CAL) (Nota… […]
[…] Remote Desktop – Escritorio Remoto: Instalación y Activación de las Licencias (RD-CAL) (Nota 7) […]