Porqué en la simplicidad está la potencia

Selección del servidor de Licencias por defecto.

Uno de los puntos más importantes en una instalación de Presentation Server 4, son los servidores de licencias de Terminal Server, en muchos casos pueden existir varios de estos servidores repartidos por nuestra red, y podríamos caer en el problema de estar utilizando un License Server inadecuado o incorrecto. En el siguiente punto indicamos como seleccionar el servidor de Licencias al cual deseamos conectar.

En este primer ejemplo generaremos un servidor de licencias Corporativo, para ello arrancaremos regedit para realizar la localización de la siguiente clave de registro:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServLicensingParameters

Realizaremos el cambio del Value Name “Role” de 0 a 1, el valor 0 está especificado para determinar un nivel de dominio de Terminal Server y 1, está especificado para determinar un Servidor de Licencias Corporativo.

Ejecutamos «Adsiedit.msc», esta utilidad está disponible en el proceso de instalación de Windows Server 2003 Support tools. Realizamos la apertura del contenedor, y realizamos la apertura del correspondiente a:

CN=Configuration,DC=<domainname>,DC=<com>

Posteriormente a ello, expandimos el nivel correspondiente a CN=Sites y realizamos un clic en el contenedor correspondiente a Enterprise License Server.

En la pantalla izquierda, realizamos clic seleccionado «New» -> «Object».y en el objeto «Class Object» arrancamos el correspondiente wizard, seleccionando «licensingSiteSettings» y pulsamos “Next”.
 

Añadimos el valor con el nombre «TS-Enterprise-License-Server» y pulsamos Next, finalizando con «Finish». Posteriormente a ello, cerramos Adsiedit.msc.

Realizamos la apertura de “dssite.msc” y localizamos el License Server creado con anterioridad, “Ts-Enterprise-License-Server”, donde pone “Licensing Computer” seleccionamos “Change”, seleccionamos el servidor de licencias correspondiente y pulsamos “Ok”, Aplicamos los cambios.

Una vez realizado este cambio, unicamente quedará pendiente la replicación en todos los controladores del dominio.

Para verificar el tipo de servidor utilizado y los parámetros del mismo, utilizaremos la utilidad “lsview” contenida en el Resource Kit de Windows 2003.

Otro de los posibles cambios, para realizar un cambio de servidor de Licencias no corporativo, se establece en la siguiente clave de registro:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServLicensingParameters

Realizaremos clic en File Menu, y crearemos el Nuevo servidor de Licencias, poniendo como parámetros y creación de clave como:

New Key -> “LicenseServers” con el botón derecho del ratón “Nueva->Clave”

Posteriormente a ello, generaremos una nueva clave dentro de esta misma, siguiendo el procedimiento anteriormente mencionado, en este caso pondremos el nombre NetBIOS con el FQDN o la dirección IP correspondiente al servidor de licencias que estamos utilizando en ese momento.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

El diseño de la seguridad en una plataforma XenApp

La seguridad es algo que por defecto siempre estamos pensando, como proteger los
accesos,los datos, las validaciones y otro sin fín de elementos que estamos en
constante proceso de modificación y aseguramiento.

En las plataformas XenApp la seguridad pasa por una serie de elementos que pueden
ayudarnos a mejorarlas, como secure Gateway.

Citrix Secure gateway, es un punto de acceso para soluciones XenApp, incorpora
entre sus distintas funcionalidades, SSL, un punto de acceso, y está disponible en
Windows y Solaris.

Uno de los puntos que tenemos que tener en cuenta y presentes en cualquier proceso
de validación es que vamos a utilizar en este, este documento pretende ser una mini
guía a tener en cuenta y que puede ayudaros a saber que elementos pueden ser
necesarios.

En este caso tendríamos que tener en cuenta:

 – Integración de Secure Gateway
 – Redundancia de servidores
 – Certificados
 – Autenticación fuerte mediante (two-factor)

La redundancia estara establecida dependiendo siempre de los roles y las necesidades
de continuidad del servicio propiamente dicho, en estos aspectos podrá ser implementada
una solución de Cluster o similar, Secure Gateway elemina ciertos mecanismos de redundancia,
y elimina el punto de fallo, especialemnte cuando se depende de ciertos elementos.

El sistema de validación de doble factor, autenticación fuerte, podrá ser establecido,
mediante prodesos de validación como RSA SecurID, accediendo mediante un servidor RADIUS,
o en la propia integración con el directorio activo.

La arquitectura de una solución Secure Gateway podrá ser establecida siguiendo los siguiente
baremos o consultas.

si, necesitamos que usuarios externos accedan a las aplicaciones XenApp, entonces
implementaremos Secure Gateway o Access Gateway Advanced.
Si, los dispositivos que utilizamos no son Windows dependen de la DMZ el acceso, entonces
implementaremos Access Gateway Advanced o Secure Gateway for Solaris.
Si Secure Gateway is requerido en conjunto con Advanced Access Control, entonces implementaremos
Access Gateway Adcanced.

En el caso de los servidores de certificados, tendremos que tener en cuenta o basarnos en la
siguiente tabla.

Si nuestra organización utiliza un certificado de un tercero, entonces necesitaremos un
servidore de certificados.
Si la organización utiliza usuarios internos con una solución de certificados, entonces
tendremos que generar un root certificate para el dispositivo cliente.

Internamente se generan certificados o pueden ser generados para utilizarlos mediante el relay
de SSL que se utiliza con el Citrix XML communications.

En la planificación de un diseño Secure Gateway o la arquitectura del mismo, tendremos además que
tener en cuenta los siguientes puntos:

– Monitorización de la red
– Puertos del firewall
– La redundancia del firewall
– El proceso de seguridad de la red

en cuanto a los puertos del firewall, tendremos que tener en cuenta los siguientes de forma inicial,
puerto 443 para la red interna en la DMZ
Para una red segura en la DMZ, tendremosq ue tener en cuenta los puertos 443 y 80
Adicionalmente a nivel de firewall, serán necesarios los puertos 1494, en el caso de publicación de recursos
de XenApp y el 2598 en el caso de session reliability.
Otro de los aspectos a tener en cuenta, quedarán establecidos en el método del diseño del sistema de validación (password).

En este caso podríamos tener los siguientes elementos en cuenta para el disño del mismo,

– Entorno del usuario
– Local Store
– Central Store
– Definición de las aplicaciones
– Politicas a utilizar
– Configuración de usuarios
– Agentes (distribución)
– Conceptos avanzados en cuento a requerimientos

Si tenemos un entorno windows o novell intentaremos utilizar siempre estos entornos para las politicas de passwords.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

Como bloquear la animación Flash en un WebSite

El proceso de eliminación o de bloqueo de una animación Flas, en cualquier servidor Web puede ser muy importante, debido a que en el caso de no ser eliminado y un uso excesivo puede causar ciertos problemas, para ello proponemos esta solución que puede ser del interés de todos (recordad de sacar copias de seguridad del registro, y que no nos hacemos responsables de los daños que pueda causar esta modificación en vuestros equipos).

Utilizaremos para ello REGEDIT.EXE

Eliminaremos la sub-key de la clave:

{D27CDB6E-AE6D-11CF-96B8-444553540000}
Shockwave Flash Object
C:WINDOWSsystem32macromedflashflash.ocx

Localizaremos la clave:

[HKLMSOFTWAREMicrosoftInternet ExplorerActiveX Compatibility]

Crearemos una sub-key con el nombre {D27CDB6E-AE6D-11CF-96B8-444553540000}

Crearemos un nuevo registro dentro de esta subclave REG_DWORD con el valor Data, y en hexadecimal, poniendo el valor: 400, con el nombre: Compatibility Flags

El tema de los 4GB puede ser algo complejo, la definición de un procesador de 32bits, tiene una definición por defecto que los recursos de gestión de memoria están establecidos en 32 bits, ello quiere decir que la localización o relocalización de memoria se establece a nivel de bytes con una memoria establecida de 2^32 = 4.2 billones de longitud máxima de memoria, ello establece que la localización máxima de memoria que se puede gestionar está establecida en 4.2 billones en una única localización o procesador, lo que es lo mismo que 4GB apróximadamente.

Las aplicaciones de 32 bits como se dice en Windows a nivel de aplicación podríamos decir que «virtual» puede indicarse que utiliza o que gestiona 4GB de espacio de memoria, pero la realidad es que el sistema operativo gestiona 2GB dedicado al Kernel y otros 2GB para el uso restante de aplicaciones.

La causa principal de este problema está determinado en entornos Terminal Server, los servicios de terminal tienen ciertos problemas en los procesos de gestión de memoría de caracter compartido.

El uso de la / 3GB (para Windows 2000) o / 4GT (para Windows 2003) en el boot.ini puede ser problemático en entornos de Terminal Server porque los interruptores realizan un cambio de funcionalidad a nivel de partición entre la solicitud de espacio de memoria y espacio de memoria del núcleo.

Estos interruptores da a cada solicitud 3GB de memoria, lo que a su vez sólo deja 1 GB para el núcleo lo que puede definirse como un gran problema en entornos de Terminal Server.

Sin embargo, los sistemas de arranque / PAE pueden soportar hasta 64GB de memoria física. Ello permite el que procesadores de 32-bits o procesos de 32-bits puedan «utilizar» grandes cantidades de memoria a través de AWE (Una extensión de funcionalidades).

Esto significa que ceden a nivel de la memoria física y distribuyen sus 2 GB de espacio de direcciones virtuales. Ello quiere decir que sólo pueden utilizar 2 GB de memoria a la vez.

Todos los de la familia x86 de Intel desde los procesadores Pentium Pro incluyen una memoria de modo de llamada PAE. Con el chipset adecuado, el modo PAE permite el acceso hasta 64 GB de memoria física.

Cuando los procesadores x86 se ejecuta en modo PAE, la unidad de gestión de memoria MMU, permite la asignación de direcciones virtuales divididas en cuatro campos o bloques.

La MMU todavía implementa paginación y direccionamiento de paginación, pero a tercer nivel. El modo PAE puede hacer frente a más memoria que el estándar en modo de traducción, sino porque EDPs y PTEs son de 64 bits de ancho en lugar de 32-bits.

El sistema de direcciones físicas representa internamente con 24 bits, lo que x86 la capacidad de soportar un máximo de 2 ^ (24 +12) bytes, o 64 GB, de memoria.

Muchas de estas limitaciones quedan establecidas a nivel de desarrollo de aplicativo, si este no aprovecha dichas funcionalidades el crecimiento nunca llega a ser de carácter progresivo.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

User Profile Manager v1 Technical Preview

En esta occasion realizamos el redactado de como instalar y configurar UserProfileManager.

El paquete preliminar que podemos descargarlo directamente de MyCitrix, una vez desempaquetado podremos observar el contenido del mismo, correspondiente a una versión para x32 y otra correspondiente a x64, para el artículo utilizaremos la versión de x32.

Una vez desempaquetado el fichero ZIP, observaremos que contiene una carpeta denomnada, UserProfileManager Migrator 1.0.0.0, esta carpeta contiene una utilidad y documentación adicional para realizar una migración de Roaming Profiles al formato de UserProfileManager, reduciendo de esta forma el tiempo de carga y los tiempos de espera en la carga de un perfil determinado.

Entre la documentación, observaremos la existencia de un documento con las mejores prácticas de cómo utilizar User Profile Manager.

Los prerrequisitos para utilizar esta versión se establecen de la siguiente forma:

Sistema Operativo, Windows XP, Windows 2003 Server, Windows Vista, Windows Server 2008. Para Windows 2008 y Vista, será necesario leer el documento de “Release Notes” donde contiene información vital y de importancia para una correcta instalación en estos sistemas operativos, en este caso será necesaria una instalación mediante línea de comando.

¿Porqué Utilizar User Profile Manager?

UPM, nos permitirá el disponer mayor rapidez de carga y de operativa en la gestión y creación de perfiles para usuarios en entornos virtualizados y XenApp, un ejemplo claro es cuando un usuario (x) accede a distintos servidores de XenApp, su perfil se copia o se crea nuevamente lo que genera lentitud y crecimiento del mismo cada vez que realiza un acceso a un servidor determinado.

UPM, extiende los perfiles mandatory en servicios registrando los cambios, las carpetas y ficheros correspondiente al perfil quedan totalmente centralizados en un File Server o en un Almacenamiento centralizado, de esta forma dicho perfil podrá ser utilizado por distintos servidores XenApp en el proceso de acceso o logon de un usuario determinado a la correspondiente Granja.

UPM, Puede ser utilizado en escenarios como Servidores XenApp, perfiles locales, XenDesktop y Streming.

Utilización de perfiles

UPM utiliza mandatory profiles, en el caso de que existan ya perfiles creados, se recomienda la lectura del documento “Mejores Prácticas” donde obtendremos información adicional.

El proceso de creación de un mandatory profile es sencillo y se recomienda la aplicación a todos los usuarios de la plataforma XenApp.

Creación de un perfil mandatario

Aunque entiendo que ya sabéis como funciona la creación del mismo.

Instalación de User Profile Manager.

Ejecutaremos el fichero .exe correspondiente a la versión x32

Pulsaremos Next

Aceptaremos los terminos de licencia y pulsaremos Next,.

Especificaremos la carpeta de instalación y pulsaremos Next y posteriormente Install, para iniciar el proceso de instalación. Una vez finalizado pulsaremos Finish.

UPM Solicita el reinicio del equipo, CUIDADO!! Realizad la instalación cuando no exista carga o servicio.

Utilización de perfiles

UPM utiliza mandatory profiles, en el caso de que existan ya perfiles creados, se recomienda la lectura del documento “Mejores Prácticas” donde obtendremos información adicional.

El proceso de creación de un mandatory profile es sencillo y se recomienda la aplicación a todos los usuarios de la plataforma XenApp.

El contenido de los respectivos ficheros una vez instalado, quedará de la siguiente forma:

En el contenido del mismo, existirán tres ficheros de configuración .ini, además de un ejecutable, así como de un fichero correspondiente .adm correpondiente a un fichero de plantilla de policies, conteniendo toda la información necesaria para poder ser gestionado.

Para realizar la gestión del mismo, utilizaremos Group Policy Editor, realizando la carga de la correspondiente template mediante la opción de Añadir/Quitar plantillas.

Obtendremos el contenido a administrar en:

Activación y puesta en funcionamiento de UPM

Para poner en funcionamiento UPM, será necesario además de haber configurado con anterioridad los puntos indicados, configurar los distintos elementos mendiante GPO con el template administrativo, todo el proceso de configuración y redireccionamiento se establece mediante este método, simplificando enormemente las tareas de gestión de perfiles.

UPM, genera un registro de su actividad quedando este almacenado en %SystemRoot%System32LogfilesUser Profile Manager

Tenemos que tener en cuenta y recordar que UPM funciona y se activa como un servicio del sistema, si este no está operativo el redireccionamiento de carpetas no será operativo y dejará de funcionar.

Citrix User Profile Manager Technology Preview

Citrix anunció en Synergy la compra de sepago PROFILE, ello refuerza enormemente las soluciones de Citrix Delivery Center, con XenDesktop, XenApp y Provisioning Server.

Comentar al respecto que el manejo de perfiles en cualquier plataforma XenApp, siempre ha sido un problema podríamos indicar que algo completo, los procesos de redireccionamiento y los problemas en cuanto a creación de impresoras y otros relacionados, permitirán a Citrix con la adquisición de PROFILE una gran ventaja y una mejora realmente sustancial.

Podéis descargaros User Profile Manager de 6,23MB:
https://www.citrix.com/userprofilemanager/previewdownload
Será necesario que os validéis con vuestro usuario de MyCitrix.

Entre sus ventajas podremos especificar su facilidad de implementación, así como la completa gestión de los distintos perfiles.

La página de sepagoPROFILE: http://www.sepago.com/e/news.html

El diseño conceptual en una plataforma XenApp

En cualquier diseño de una plataforma XenApp es necesario el disponer de los nterlocutores válidos, así como tener claro todos los elementos de imporancia para poder realizar una estrategia de diseño adecuada y escalable.

Las áreas que tendremos que fijar especial interés o atención, quedarán establecidas en XenApp, el Acceso, la seguridad y la infraestructura de integración.

En la arquitectura a adoptar con XenApp, tendremos que tener en cuanta lass areas y definiciones de la granja o granjas, así como las zonas basadas en requerimientos, los data Collectors, los procesos de fileover y los factores correspondientes a dispersidad geográfica.

A nivel de arquitectura del Data Store, la definición del mismo y la configuración, se centrarán en elementos software, el hardware a utilizar para el almacenamiento de datos, la longitud de la misma, la redundancia, localización, el proceso de backup y los métodos de acceso a utilizar, todo ello definido y especificado en el Data Strore.

En cuanto a Load Manager, la arquitectura del balanceo de cargas correspondiente a aplicación, tendremos que tener en cuanta el diseño del mismo, los servidores que realizarán estas funcionalidades, las reglas utilizadas y los evaluators de definición de las mismas.

A nivel de Diseño de aplicaciones a publicar, los elementos clave se centrarán en la integración de aplicaciones y la instalación de la arquitectura previamente definida.

En el proceso de aplicaciones a publicar, definiremos la metodología para introducir nuevas aplicaciones en un entorno XenApp, además de realizar un especial énfasis en el manejo de grupos y usuarios especificados y determinados para entornos de aislamiento.

Identificar el Acceso a las distintas áreas.

En todo proceso de diseño, tendremos que tener en cuenta la identificación de las distintas áreas de diseño, especificadas en dos módulos de importancia, uno centrado en una instalación podríamos decir que básica y otra mediante elementos hardware adicionales como Access Gateway.

En cuanto a arquitectura básica, quedaría esta definiada mediante la edición avanzada de Access Gateway, Web Server y el sevidor o servidores componentes de la respectiva granja de servidores XenApp, todos ello con el software correspondiente, y las funcionalidades de tolerancia a fallos previamente definidas.

En cuanto a Access Gateway, esta área definiría la arquitectura a utilizar con este dispositivo, en su versión enterprise, incluyendo los procesos de logon, agentes, STA y los servicios y métodos de autenticación.

La configuración de la granja estará definida en parte por el uso o no de Access Gateway en su versión Advanced, permitiendo la inclusión y los settings relacionados con el método de autenticación de Citrix XenApp, utilizando Access Suite Console.

Los recursos estarán definidos específicamente para los usuarios, identificando las aplicaciones web, la compartición de ficheros y publicación de aplicaciones, acceso centralizado y aplicación de reglas y procesos de navegación.

La configuración de políticas comportarán las diferentes políticas a aplicar al entorno a crear, para la asociación de ficheros.

El proceso correspondiente al logon point, permitirá la política basada en procesos de logon o distintos puntos de acceso, permitiendo distintas configuraciones y elementos adiciones, y permitiendo la integración de Access Gateway con XenApp, además de las distintas posibilidades de conectividad mediante el servicio Citrix XML.

El proceso denominado Endpoint análisis, permitirá la configuración de cliente, y opciones de análisis mediante niveles y acceso limitado, permitiendo el uso de recursos y aplicaciones publicadas, accesos web internos y recursos.

El uso de Access Gateway y Secure Gateway

Uno de los puntos importantes, es la decisión de utilizar uno de los dos elementos, la configuración de Access Gateway permitirá el uso y las funcionalidades de valor añadido que suministra un Appliance, permitiendo funcionalidades de cluster y configuración de políticas.

La configuración de Secure Gateway, proveerá configuraciones detalladas y específicas sobre este, incluyendo secciones en general de tolerancia a fallos y networking.

El balanceo, estará determinado por el hardware y estará limitado a sus funcionalidades , específicamente para dos o más dispositivos Access Gateway.

Otros puntos a tener en cuenta

El cualquier diseño, tendremos que tener en cuenta además los siguientes puntos de vital importancia.

-Infraestructura compartida
-Servicios de Directorio
-Infraestructura de Red

Todos ello de vital importancia para una correcta implementación de una solución XenApp en cualquier infraestructura ya productiva.

Además de ello, no podremos olvidarnos de los elementos de otras áreas igualmente necesarias y de importancia:

-Los procedimientos de soporte y operatividad
-Los sistemas de integración
-La politica o control de cambio
-Los procesos de integración de aplicaciones
-El proceso de test y escalabilidad
-El proceso o procedimiento de Backup y Recovery

Todos estos elementos mencionados estarán directamente relacionados con la gestión de un proyecto Citrix que ya he comentado en artículos anteriores a este.

La estrategia de la documentación en el diseño

Cualquier documentación es de vital importancia para cualquier proyecto XenApp, los diagramas, los servicios y diseño de los mismos, el diseño de la seguridad, la infraestructura y los elementos a utilizar son totalmente imprescindibles y de vital importancia.

Las consideraciones que podría realizaros al respecto se centrarían básicamente en los siguientes puntos.

-Discutir los elementos a utilizar.
-Discutir el diseño y localizar información adicional
-Proveer de un diseño claro y eficiente
-Obtener datos lo más clarificantes posibles.
-Crear un alto nivel de detalle en le documentación resultante

Notas de instalación de XenApp 5.0 con Windows Server 2008

Determinar la versión del servidor de licencias Citrix

Para saber que versión del servidor de licencias estamos utilizando, nos logaremos en el servidor en cuestión, una vez logado ejecutaremos la siguiente línea de comando dependiendo del sistema operativo si es o no de 32 bits, siendo la ejecución del mismo en las siguientes rutas:

32 bits. C:Program FilesCitrixLicensingLS
64 bits. C:Program Files (x86)CitrixLicensingLS

La línea de comando a ejecutar: lmver lmgrd.exe, especificando la versión del servidor de licencias.

El Servidor de licencias a nivel de requerimientos de sistema podrá ser
instalado en plataformas Windows 2000, 2003 y 2008 cualquier edición será válida.

La consola administrativa, es compatible con IE 5.0 con los siguientes
requerimientos mínimos, HTML 3.2 o HTML 4.0

A nivel de Web Servers, IIS, 5.0, 6.0 o 7.0, para la familia de Windows Server 2008, será necesario instalar los roles ASP.NET, Windows Autentication Security y IIS 6 Management Compatibility.

Para Apache la versión compatible tendrá que ser la correspondiente a
Apache HTTP Server 2.0.49

A nivel del Servlet Engine, necesitaremos Tomcat 4.1.24

Además de la necesidad de Java Runtime Environment versión 1.5-0_11,
descargable desde: http://java.sun.com/products/archive/j2se/5.0_11/index.html

Añadir roles al License Management Console

Para añadir los respectivos roles, lo podremos realizar desde el menú Inicio(Start), All Programs, Administrative Tools, Server Manager.

Una vez seleccionado en el panel, desplegaremos las funcionalidades de roles, realizando «clic» sobre Web Server (IIS), y seleccionando la opción de «Add Role Service». Seleccionando de esta forma los roles necesarios, tal y como indicamos, los check box a seleccionar serán:

– Application Development -> ASP
– Security -> Windows Authentication
– IIS6 Management Compatibility

Una vez seleccionados pulsaremos Next. Pulsaremos Install y finalizaremos la instalación con Close.

Notas sobre los puertos utilizados del servidor de licencias

Los puertos que tendremos que tener en cuenta para el license server, serán los que se especifican a continuación:

27000 – especificado como el puerto del license server de Citrix.
7279 – demonio utilizado para la detección del mismo.

Si no se disponen de máquinas de x64 podremos instalar el servidor de licencias en servidores de x32 bits sin problemas.

El fichero de instalación del servidor de licencias se establece con el nombre, CTX_Licensing.msi, el cual iniciará el proceso de instalación correspondiente.

Otro método de instalación podrá ser establecido mediante línea de comando directa, utilizando msiexec con sus respectivas parametrizaciones.

Como clonar un Servidor XenApp 4.x

El clonaje de servidores Citrix XenApp, puede ser muchas veces un problema, sobre todo cuando estos están en entornos productivos, las aplicaciones instaladas, y totalmente operativo, la idea de este artículo es el poder realizar un clonaje de este tipo de servidores, sin necesidad de realizar una instalación al completo del mismo.

Atención!!! Está guia no ha estado verificada aún para Servidores Windows Server 2008.

Los elementos que vamos a necesitar son los siguientes:

– sysprep o NewSID
– Symantec Ghost (puede ser cualquier otro)

Los pasos que realizaremos son los siguientes:

Crearemos una carpeta denominada «prep» o como deseeis llamarla, en ella copiaremos sysprep.exe
Crearemos una segunda carpeta denominada «WinTools» donde copiaremos el contenido del CD1 de
Windows 2003 Server, localizado en SupportTools.

Una vez realizado este paso, realizaremos una copia del servidor con la aplicación de clonación que deseemos utilizar, posteriormente a realizar la clonación del mismo, deberemos realizar un cambio del SID, creando uno nuevo para este servidor, cambiaremos además el nombre del servidor, su IP..etc… para ello usaremos Sysprep o NewSID en su versión 4.

En el CD de Windows 2003 Server, tal y como se ha indicado anteriormente existe un directorio, denominado Sypport, y dentro de este Tools, el fichero denominado DEPLOY.CAB, este fichero contiene sysprep, deberemos de descomprimirlo con cualquier herramienta y copiar el contenido en la carpeta creada al principio con este fín. Además de ello, podemos generar un fichero de respuestas para que el proceso sea totalmente automático. Para este proceso utilizaremos el programa contenido en el mismo directorio, denominado setupmrg.exe.

Posteriormente a ello, pararemos en este servidor los siguientes servicios, pasándolos a Manual:

Citrix XML Service
Citrix MFCOM Service
Citrix SMA Service
Independent Management Architecture de Citrix
Servicio Citrix WMI

Una vez realizada esta acción, crearemos el siguiente script, el cual grabaremos con el nombre
fix.cmd en el directorio «prep».

El contenido del fichero fix.cmd será el siguiente:

— fichero fix.cmd —
@echo off
echo Backup del Registro en %TEMP%copiareg.reg
set CTXREG=»%TEMP%copiaeg.reg»
echo Windows Registry Editor Version 5.00 > %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_LOCAL_MACHINESOFTWARECitrixIMA] >> %REGISTRO%
echo «ServerHost»=»%COMPUTERNAME%» >> %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_CLASSES_ROOTAppID{BBBF5400-E091-11D8-AD76-005056C00008}] >> %REGISTRO%
echo «RunAs»=»%COMPUTERNAME%\Ctx_SmaUser» >> %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesIMAService] >> %REGISTRO%
echo «Start»=dword:00000002 >> %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCitrix SMA Service] >> %REGISTRO%
echo «Start»=dword:00000002 >> %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMFCOM] >> %REGISTRO%
echo «Start»=dword:00000002 >> %REGISTRO%
echo. >> %REGISTRO%
echo [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCitrixWMIService] >> %REGISTRO%
echo «Start»=dword:00000002 >> %REGISTRO%
echo. >> %REGISTRO%
echo Modificar el valor UID en CtxSta.config, poner un valor distinto al existente.
echo y grabar el fichero, saliendo posteriormente de notepad
notepad %ProgramFiles%citrixsystem32ctxsta.config
pause
echo SQL: Realizar la Modificación del valor WSID con el nombre del servidor actual en MF20.dsn
echo el cual está localizado en Independent Management Architecture, la edición es directa.
echo al arrancar el notepad y modificar el valor, grabar el fichero, saliendo posteriormente de notepad
notepad %ProgramFiles%citrixIndependent Management Architecturemf20.dsn
pause
regedit /s %REGISTRO%
del %TEMP%copiareg.reg
set REGISTRO=
echo Proceso de Reinicio del server.
shutdown /r /t 40
— final fichero fix.cmd—-

Posteriormente a la creación del fichero fix.bat, modificaremos la siguiente clave del registro para que el proceso de reinicio, realice la ejecución de este script para ello seguiremos los siguientes pasos:

Utilizando regedit
accederemos a la clave del registro:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce
Crearemos el siguiente valor con nombre RegFix con tipo REG_SZ y contenido C:sysfix.cmd

Una vez realizado este cambio, escribiremos desde C:Sys
sysprep -activated -reseal
Iniciandose el proceso de creación y regeneración en el servidor.
Cuando finalice, el servidor arrancará de forma automática.
Iniciándose y preparándo el nuevo entorno.

En el proceso de arranque deberemos de añadir la información correspondiente, como el nombre de la empres, organización, el CDKey de Windows 2003 Server para activar el producto, nombre del servidor, contraseña, direcciones I y acceso al Dominio, una vez entrados los datos y finalizado el respectivo asistente, se reiniciará el servidor nuevamente, accediendo por primera ves y ejecutando el Script que habiamos creado con anterioridad fix.cmd.

Inicialmente se ejecutará el cambio de configuración, si no realiza la publicación del fichero ctxsta.config, deberemos de modificarlo de forma manual, cambiando el valor de UIA dentro del entorno de configuración [GlobalConfig].

El siguiente cambio, quedará establecido en el fichero MF20.dsn, siguiendo la misma acción que el anterior caso, en este deberemos de especificar los datos de acceso a la base de datos de SQL Server, en el se especificará:

Address=
Network=
DATABASE=
WSID=
APP=
SERVER=

Este fichero está localizado en: %ProgramFiles%citrixIndependent Management Architecture

Una vez finalizado, el servidor será reiniciado, cuando reinicie, debremos de eliminar la clave de registro creada con anterioridad, en:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce
Y eliminaremos el siguiente valor con nombre RegFix con tipo REG_SZ y contenido C:sysfix.cmd

Una vez realizado este cambio, deberemos de especificar las aplicaciones publicadas, añadiendo el nuevo servidor de la granja.

De esta forma quedará finalizado el clonaje del servidor.

Espero que os sea de utilidad

Cambiar el nombre a una conexión ICA

Uno de los fallos más importantes de Presentation Server y XenApp, es el nombre de la conexión virtual que se establece con el servidor de Presentation Server o XenApp, el problema reside en que por norma general la conexión realizada mediante WebInterface durante el proceso de Download del cliente ICAWeb, o durante el proceso de instalación del mismo mediante ejecutable, el usuario establece por defecto el uso del nombre del PC Local.

El aplicar este tipo de configuración es muy viable y factible cuando la nomenclarura de nombres está totalmente estandarizada y no se realizan conexiones WAN o desde Internet, con equipos de carácter personal no clasificados. En el caso de que exista la posibilidad de utilizar equipos no controlados, podemos encontrarnos con nombres duplicados en nuestras conexiones, además de que podemos encontrarnos con problemas debido a duplicación de nombres y generación de impresión por impresoras que no son las correctas.

La mayor parte de los problemas residen principalmente en que al ya existir un canal virtual con un nombre de equipo, al realizar la segunda conexión, este utiliza en la mayor parte de los casos los recursos ya existentes, realizando tareas de impresión en otros lugares siendo estos muchas veces los menos adecuados.

Para solucionar este problema es necesario modificar o generar una nueva clave del registro del PC desde donde es solicitada la sesión ICA, realizando un cambio de nombre del dispositivo remoto.

En este caso publicamos un Script realizado en VBScript, que soluciona esta problemática, el cual únicamente es necesario aplicarlo en el proceso de logon del usuario remoto.

const HKEY_LOCAL_MACHINE = &H80000002
strComputer = «.»
Set StdOut = WScript.StdOut
Set oReg=GetObject(«winmgmts:{impersonationLevel=impersonate}!\» &strComputer & «rootdefault:StdRegProv»)
strKeyPath = «SOFTWARECitrixICA Client»
strValueName = «ClientName»
oReg.GetExpandedStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
dim objICA
set objICA = CreateObject(«Citrix.ICAClient»)
Randomize Timer
Dim tmpCounter,tmpGUID
Const strValid = «0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ»
For tmpCounter = 1 To 5
tmpGUID = tmpGUID & Mid(strValid, Int(Rnd(1) * Len(strValid)) + 1, 1)
Next
CreateGUID = tmpGUID
nombre = «ICA»+CreateGUID
strValueName = «ClientName»
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,nombre