Remote Desktop – Escritorio Remoto: Instalación y Activación de las Licencias (RD-CAL) (Nota 7)

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

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Coldfran  On 09/09/2016 at 19:58

    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 :)

    • Guillermo Delprato  On 10/09/2016 at 06:42

      ¿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

  • leo  On 08/10/2016 at 10:49

    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

  • christiaannn  On 12/12/2016 at 07:15

    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.

    • Guillermo Delprato  On 12/12/2016 at 08:41

      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

      • christiaannn  On 12/12/2016 at 08:51

        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.

      • Guillermo Delprato  On 12/12/2016 at 09:00

        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

      • christiaannn  On 12/12/2016 at 11:19

        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.

      • Guillermo Delprato  On 12/12/2016 at 13:20

        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

  • Luis Fernando Orjuela  On 05/03/2017 at 23:59

    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.

    • Guillermo Delprato  On 06/03/2017 at 07:15

      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í? :)

    • Luis Fernando Orjuela  On 10/03/2017 at 13:37

      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

      • Guillermo Delprato  On 10/03/2017 at 15:46

        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

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: