Hola
Cuando marcamos esta casilla de las propiedades de un servidor de Remote Desktop:
Los servidores de Remote Desktop Web Access mostrarán, además de los iconos y nombres de las RemoteApps configuradas, un icono del cliente RDP cuyo nombre será siempre por defecto “Remote Desktop”. Los ficheros .rdp subyacentes los podéis encontrar en C:\Windows\RemotePackages.
Las aplicaciones remotas pueden renombrarse cómodamente desde el RemoteApp Manager. Sin embargo, la conexión a una sesión del servidor no puede renombrarse mediante la UI, y si el RD Web esta mostrando lo que se expone en diferentes servidores o granjas, nos encontraremos con que no sabemos que icono “Remote Desktop” corresponde a qué servidor.
Este nombre puede cambiarse de dos maneras:
$RemoteDesktop = gwmi -namespace "root\cimv2\terminalservices" win32_tsremotedesktop $RemoteDesktop.name = "Conexiona a Servidor de Ofimatica" $RemoteDesktop.put()
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\RemoteDesktops\TSRemoteDesktop
Lógicamente, si hay varios servidores que compartan una misma granja, deberemos ser consistentes con el valor que especificamos en todos ellos.
El icono se puede igualmente modificar mediante la propiedad $RemoteDesktop.iconpath, o con la cadena IconPath del registro.
Saludos
David Cervigón
Esto no tendría nada de especial en los tiempos que corren, si no fuera porque se trata de un portátil, del tipo “mobile workstation”. Pesa 3 Kg (sin contar el alimentador, bastante voluminoso), el display es de 15” y además tiene todo esto:
Este es un ejemplo de la última serie de equipos con procesadores Intel Core i7, y los 8 procesadores lógicos que se muestran corresponden a la combinación de la tecnologías Multicore (en este caso, 4) e Hyperthreading.
Como veis, esta unidad esta equipada con 16 Gb de RAM, y leo en las especificaciones que puede llegar a 32 Gb. Dado que soporta Hyper-V sin problemas podríamos llegar a correr sobre el un muy elevado numero de máquinas virtuales. En nuestro caso, he llegado a arrancar 32, por alcanzar un número redondo.
Sin embargo, para estos usos tiene una grave limitación, por buscarle alguna pega. Es un claro ejemplo de prestaciones descompensadas. El disco interno, pese a ser SATA II a 7200 r.p.m, no da abasto cuando pasamos de entre 2 y 4 máquinas virtuales. La solución es rodear el portátil con múltiples unidades de almacenamiento externo, y por fortuna estos equipos vienen ya equipados con puertos eSATA y también USB 3.0.
Así es que para la demo de Dynamic Memory no nos queda mas remedio que recurrir al “viejo” Core 2 Duo de 8Gb, aunque de nuevo la limitación será el almacenamiento. Aquí usaremos el disco interno, otro alojado en la bahía de expansión, y dos USBs externos. Y aun así iremos justos.
Antes de irnos de vacaciones nos pusimos manos a la obra y reinstalamos todo el laboratorio desde cero, aprovechando un cambio en la línea que nos une con Internet. Además, aunque intentamos ser lo mas cuidadosos posibles para que las cosas no degeneren, algunos equipos venían arrastrando actualizaciones desde la RTM de Windows Server 2008. Nos repartimos el trabajo, dejamos todo medio como estaba originalmente y nos dimos a la fiebre mundialista y vacacional. A la vuelta, gran parte de los servidores y máquinas virtuales estaban sin activar, en periodo de gracia, o algunos directamente no dejaban ya hacer logon. ¿Quien metió que clave en donde?. ¿Era una clave MAK o KMS?. Si no se hizo, ¿puedo meter las claves de manera remota?. ¿Puedo lanzar el proceso de activación sin pasearme por las consolas locales o remotas de todos los equipos, uno por uno?
En nuestro caso, solemos usar claves obtenidas de TechNet/MSDN para las instalaciones, que son de tipo MAK (Múltiple Activation Keys). Se activan directamente contra los servidores de Internet. Estaríamos ante el mismo problema si utilizáramos claves KMS (Key Management Service), para lo que deberíamos definir el servidor interno. Todos los detalles sobre este tipo de activaciones lo tenéis aquí:
La instalación de claves y activación remota pueden hacerse con ayuda del script SLMGR.VBS, en particular:
y así lo veníamos haciendo, pero a medida que los clientes y servidores crecen, sobre todo virtuales, puede ser complicado la gestión remota, el inventariado y la monitorización del estado de los sistemas en lo tocante a su estado de activación:
La VAMT 2.0 nos permite en minutos, hacer consultas a del estado de nuestros equipos, por conjunto de IPs, Directorio Activo, Grupo de trabajo o repositorio LDAP, y almacenar las claves de los productos para usarlas en caso de tener que instalarlas y activarlas remotamente::
En nuestro caso hacemos una consulta al dominio para obtener el estado de todos los equipos:
Obtenemos que algunos equipos no están correctamente activados:
Seleccionamos uno de ellos, le introducimos la clave correspondiente de las que tenemos almacenadas;
y lo activamos de manera remota:
Mas información:
Hola a todos de nuevo.
Fue cerrar el portátil para irme de vacaciones y empezar a anunciarse novedades, como la disponibilidad de la beta del SP1 de Windows 7 y Windows Server 2008 R2, de la RTM de los componentes de integración 2.1 para Linux, actualizaciones y nuevas incorporaciones a los Solutions Accelerators (Microsoft Planning and Assestment Toolkit, WMM Self-Service Portal 2.0 RC). Y fue volver, y empezar a lidiar con todos los cambios que internamente siempre supone empezar un nuevo año fiscal en Microsoft, y en especial este entre nubes y nubarrones, en un verano caluroso y tormentoso.
Vamos a empezar como los críos, con periodo de adaptación y algún post ligerito, para irnos luego metiendo en harina con lo mencionado más arriba y otras cosas.