Archivo

Archivo del autor

User Profile Manager v1 – Instalación y Configuración

miércoles, 28 de mayo de 2008 Sin comentarios

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.

 

Categories: General Tags:

Citrix User Profile Manager Technology Preview

martes, 27 de mayo de 2008 Sin comentarios

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

Categories: Noticias Tags:

El diseño conceptual en una plataforma XenApp

martes, 27 de mayo de 2008 Sin comentarios

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

 

Categories: General Tags:

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

lunes, 26 de mayo de 2008 Sin comentarios

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.

Categories: General Tags:

Como clonar un Servidor XenApp 4.x

lunes, 26 de mayo de 2008 Sin comentarios

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

 

Categories: General Tags:

Cambiar el nombre de una conexión ICA

sábado, 24 de mayo de 2008 Sin comentarios

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

Categories: General Tags:

La Gestión de un Proyecto Citrix

martes, 20 de mayo de 2008 Sin comentarios

Gestionar un Proyecto Citrix

Muchos son los procesos o procedimientos de implantación de una infraestructura Citrix, pero muy pocas son realmente eficientes y cumplen los requerimientos específicos del fabricante, realizando instalaciones sin pasar por las fases oportunas que están definidos en cualquier tipo de proyectos, sin tener en cuenta características realmente importantes como son las fases de pruebas o test de aplicaciones entre otras.

El proceso de gestión del proyecto Citrix

Durante un proceso de gestión de un proyecto Citrix, se presenta una metodología la cual es vital, para que esta sea un éxito y sus resultados finales sean óptimos y eficientes. Para ello se establecen varias fases durante el ciclo de vida del mismo, los cuales están determinados en los siguientes bloques:

Fase de Análisis
Fase de Diseño
Fase de Pruebas y Test
Fase de Rollout (Piloto e implantación)

Todas estas fases definidas dentro de un proceso de Gestión del Proyecto.

En la Fase de Análisis, se establece una estrategia que permite disponer de una definición general del alcance del proyecto, así como de los conceptos generales del mismo, permitiendo identificar los posibles riesgos que este puede tener en una integración en una infraestrutura organizativa determinada.

En la Fase de Diseño, se establecen los métodos a utilizar, y se diseña la arquitectura más viable a aplicar, permitiendo disponer de un proceso operativo y de soporte durante el diseño del mismo.

En la Fase de Pruebas y Test, se establecen los procesos de instalación, el entorno a instalar, como y que fallos se detectan, soluciones a los mismos, y recopilación de resultados. La fase de Test constaría de las siguientes fases:

-Integración de Aplicaciones
-Políticas e Implementación de Perfiles
-Integración de la infraestructura
-Automatización de Scripts
-Entorno de integración productivo
-Test y escalabilidad

En la Fase de Rollout, se establece el proceso de implementación de una plataforma Piloto en pruebas, para observar los resultados y terminar de perfilar el proceso que se generará para llegar a un procedimiento de implantación final de la plataforma.

Todas estas fases se definen entre ellas, en un proceso de check antes de finalizar cada una, con el fin de realizar un cierre correcto de las fases correspondientes y anotando los resultados de cada una de ellas.

Este procedimiento se establece como una gestión de un proyecto Citrix, donde podremos realizar una coordinación de un equipo de proyecto, podremos mitigar el riesgo y en su consecuencia minimizarlo, podremos calcular y especificar los tiempos de integración, y tener la satisfacción absoluta de nuestro cliente o de la empresa donde se realice dicha integración.

Conceptos básicos de gestión de proyectos Citrix

Toda gestión de proyectos es importante en cualquier tipo de integración o implementación de una solución determinada. La metodología se establece en un proceso de separación lógico el cual se aplica o puede ser aplicado incluyendo los siguientes componentes:

-Trabajando con colaboradores/sponsors/clientes
-Definición de roles y responsabilidades
-Identificación y discusión de los puntos de verificación
-Manejo de tiempos
-Organización y mantenimiento del plan del proyecto especificado en
tareas
-Aplicación de un control de calidad (ISO900x)
-Planificación organizacional y plan de comunicación

Todos estos componentes estarán o podrán estar incluidos en los siguientes objetivos:

-Obtener objetivos de la gestión del proyecto
-Exponer las propuestas de los sponsors/clientes
-Obtener quién define el proyecto
-Definir las diferencias según desviaciones localizadas
-Exponer métodos aplicados al cambio
-Obtener tareas de la gestión del proyecto
-Identificar los beneficios y la calidad de la gestión
-Obterner los puntos de comunicación
-Identificar los posibles fallos en el proyecto

Posteriormente a todos estos puntos se podrá definir el Executive Project, en esté estará referenciado los puntos correspondientes a, Roles y responsabilidades, puntos de verificación, el proceso, el plan, la calidad, y el plan de comunicación.

Todos los puntos son muy importantes en cualquier gestión de proyectos y deben de tenerse muy en cuenta en cualquier integración de una plataforma Citrix, ya que el no realizar un seguimiento o no aplicar un proceso, podría tener un resultado y una viabilidad del proyecto poco fiable.

El plan de comunicación en un proyecto

Un plan de comunicación en un proyecto es de gran importancia, para el que cambio sea totalmente controlado y exista una difusión de la información de una forma correcta y eficiente, sin caer en el error de difundir la información al grupo o personal inadecuado.

La comunicación regular y fluida mejora considerablemente cualquier gestión de proyectos y en especial un proyecto Citrix, por la criticidad y complejidad que este puede llegar a tener.

El tipo de información que se puede establecer en un plan de comunicación puede quedar establecido en los siguientes puntos:

-Requerir información del proyecto en curso, procesos realizados, cambios, problemas localizados, proceso de seguimiento y siguientes procesos a realizar. Todo establecido en un documento establecido que se denomina “Status Report” o Report de estado del proyecto.
-Información y direcciones de personal de importancia para los distintos procesos y sesiones de dudas que surjan para la resolución de las mismas, todo ello estará establecido en documentos denominados FAQ, estos documentos contendrán respuestas a preguntas realizadas por usuarios y/o personal involucrado en el mismo.
-Información de Marketing, direcciones generadas y fase de documentación de noticias, contestaciones, reconocimiento y testimonios sobre el proyecto en curso.

En cuanto a la comunidad de usuarios, habrá que tener en cuenta algunos puntos de importancia, para que el proceso de cambio que puede representarles sea lo menos traumática posible y con el menor impacto.

Para este punto podrán establecerse la generación de los documentos necesarios y en medida de lo posible de fácil accesibilidad, para ello se podrán establecer los siguientes puntos:

-Documentación de uso de la plataforma
-Procedimientos de acceso a Web sites, portales o intranets
-Notificaciones por eMail
-Notificaciones por voz o telefónicamente
-Documentos centralizados en un repositorio de consulta

Cualquier duda al respecto estoy a vuestra disposición. 🙂

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

Categories: General Tags:

XenApp 5.0 – Primeras impresiones

sábado, 17 de mayo de 2008 Comments off

xenApp 5.0, testeamos la nueva versión.

Primeras impresiones.

Una de las nuevas funcionalidades de XenApp 5.0 es Citrix Delivery Clients(SV). Cuando los usuarios se conectan a las aplicaciones publicadas, estos utilizan un tipo de cliente y otro, el software cliente está disponible en una amplia gama de versiones y para distintos dispositivos, para que los usuarios puedan conectarse a las aplicaciones publicadas de diversas plataformas.

XenApp utiliza la arquitectura ICA, un protocolo de intercambio de información entre dispositivo cliente y los recursos publicados por un servidor XenApp.

El protocolo ICA envía las pulsaciones de teclado, clicks de ratón, pantalla y actualizaciones entre el servidor y el cliente, por lo que el usuario del
dispositivo cliente tiene la sensación de estar ejecutando la aplicación en
modo local.

A todo ello Citrix realiza el cambio del Software cliente, pasando del anteriormente conocido como Program Neightborhood, a llamarse Delivery Client (SV).

Versiones de XenApp 5.0

Las distintas versiones que serán comercializadas de XenApp 5, están catalogadas en tres gamas de productos:

-Advanced
-Enterprise
-Platinum

La diferencia entre cada una de ellas varía en función de las necesidades y de los componentes que necesitemos. En este caso tendremos las siguientes características.

Advanced, contempla los módulos de:Server-side application virtualization,
SpeedScreen Progressive Display,Support for 64-bit platforms,The Secure Gateway.

Enterpise, contempla los módulos de: (anteriores de Advanced)
Client-side application virtualization (streaming),Simple Network Manager Protocol (SNMP) monitoring, Health Assistant,XenApp Provider and XenApp Management Packs,CPU Utilization Management, Resource Manager powered by EdgeSight.

Platinum, contempla los módulos de: (anterior Enterprise), SmartAuditor, EasyCall (EasyCall appliance must be purchased separately). Application Performance Monitoring powered by Citrix EdgeSight, SmartAccess powered by Citrix Access Gateway
(Access Gateway appliance must be purchased separately)
Single Sign-on powered by Citrix Password Manager,Preferential Load Balancing, WAN Optimization (WANScaler appliance must be purchased separately)

En el DataStore en XenApp 5, se almacena la siguiente información.

– Configuración de la granja
– Aplicaciones publicadas, configuración
– Configuración de servidores
– Cuentas de administración
– Configuración de impresoras

Y soporta, SQL, ORACLE, SQL Express, IBM DB2 y Access.

El el DVD de instalación del producto, se incluye Secure Gateway y Web Interface, además de los distintos elementos Software especificados, en nuestro caso hemos testeado una versión platinum y ciertamente los cambios son muy sustanciales.

La plataforma hay que instalarla en Windows Server 2008, aúnque se indica que puede funcionar en Windows Server 2003, no hemos podido realizar el respectivo test, enseguida que lo tengamos realizado os notificaremos a todos de los resultados.

Uno de los puntos que XenApp 5 potencia, es la virtualización por Streaming, la cual tendremos que tener muy en cuenta como una gran solución de vistualización de software y de aplicaciones sin necesidad de disponer de una conexión física con nuestra plataforma XenApp 5.

Uno de los puntos importantes a indicar, es que la nueva versión, permite Streaming, mediante el uso de los protocolos HTTP y HTTPS, este reemplaza el file server, mejorando de esta forma el acceso mediante un único punto de acceso Web.

El Balanceo de Cargas en la versión Platinum de carácter preferencial, es otro de los puntos fuertes de la solución de Citrix, anteriormente la carga se realizaba mediante el número de usuarios que se conectaban a una granja tanto a nivel de aplicación como a nivel de servidor, con este nuevo avance, se puede asignar mayor o menor prioridad y niveles de servicios especificos de XenApp a usuarios específicos y aplicaciones específicas. Los usuarios y las aplicaciones con mayor prioridad y los
niveles de servicio pueden conectarse a sus sesiones XenApp con mayor rápidez, la experiencia de poder disponer de más sesiones interactivas ICA, y disponer de más recursos disponibles.

El Proceso de Instalación – Algunos comentarios

Cuando iniciamos el preceso de instalación de XenApp 5.0, lo primero que nos sorprende es la estructura de directorios, tenemos que indicar que hemos testeado la versión Platinum del producto, entre las distintas carpetas de esta entrega, podemos encontrar la siguiente estructura.

Administration
Citrix PAssword Manager
Citrix Streaming Profiler
Clients
Documentation
Licensing
Network Manager
Resource
Resources
Secure Gateway
SmartAuditor
Support
Web Interface
XenApp Management Pack
XenApp Server

Por ejemplo podemos observar, que aún cambiando el nombre del producto, los nombres de los archivos ejecutables siguen siendo los mismos, tanto en el cliente ICA como en el corespondiente a XenApp 5.0, en este caso podemos localizar dos subcarpetas en las cuales está definido el entorno de x32 y el de x64, localizando en ellas el nombre de fichero «MPS.MSI» al igual que su anterior versión del producto. en cambio en el contenido o propiedades de este aparece el nombre del producto de «Citrix XenApp 5.0 for Windows Server 2008» y en las palabras clave «Presentation Server» muy curioso!!!.

Suponemos que en la versión final estos pequeños temas estarán ya solucionados y se terminará realizando un cambio definitivo de nombres, ya que ello y por lo que se observa se sigue manteniendo el nombre de Presentation Server entre «comillas»

Por otra parte nos encontramos con el mismo tema, en cuanto al cliente o clientes ICA correspondientes, manteniendo el mismo nombre en los ejecutables que en sus versiones anteriores, tanto en ica32, como en icaweb, como en el resto de versiones para los distintos sistemas operativos existentes.

Si que por el contrario se observan ciertos cambios a nivel de la carpeta de Support, pero únicamente añadiendo .NET 3.5 y alguna otra Tool necesaria para una correcta instalación de la nueva versión de XepApp.

Podríamos resumir que dicho esto, la estructura y nombres de ficheros a nivel global no se han modificado, manteniéndose prácticamente en su totalidad, tanto a nivel de estructura como de ficheros y ejecutables.

Además de ello, la visión de instalación de producto a pasado a un gris claro con el nombre de Citrix, muy similar a sus anteriores versiones, pero algo más clara.

Entre las distintas mejoras adicionales, podemos especificar que existen bastantes cambios a nivel de «features» sobre Windows Server 2008, XenApp 5.0 incluye todas las funcionalidades de Windows Server 2008, incluido el release de Presentation Server 4.5. en su Future Pack 1, soportado por Windows Server 2008.

La escalabilidad a nivel de granja permite reducir significativamente el proceso de arranque en tiempo en cuanto a IMA, incluidos los tiempos de resolución así como los tiempo de enumareación de aplicaciones.

La reducción en cuanto a tiempos de instalación de XenApp se reducen considerablemente, así como las funcionalidades de escalabilidad de un Single Server, permitiendo la reducción de uso de CPU de usuarios activos en plataformas de 32 bits.

Otro de los puntos curiosos es que en ciertos puntos de la documentación, se sigue realizando referencias a Presentation Server pero esta vez en su versión 5.0, en lugar de realizar un cambio de nombre a XenApp 5.0, en estos casos al no ser la versión totalmente definitiva, esperamos que seán solucionados estas descripciones, antes de que salga definitivamente en el mercado, ya que ello puede generar significativa confusión a nivel global.

A nivel de seguridad ha estado mejorado, incorporando totalmente el protocolo IPv6, en el Citrix Delivery Client, y secure gateway, además de ello se incluyen las funcionalidades de UAC (User Account Control), y se añaden funcionalidades de seguridad avanzadas a los servicios de XenApp 5.0 (extendiendo los parámetros en comandos de línea, para proceso

Categories: General, Noticias Tags:

¿Cómo utilizar el DataStore en ORACLE con XenApp 4.5?

jueves, 1 de mayo de 2008 Sin comentarios

¿Cómo utilizar el DataStore en ORACLE?

 

Uno de los puntos que nos encontramos muchas veces es saber como podemos utilizar el DataStore en ORACLE, el uso del DataStore en plataformas SQL Server es muy claro, pero en este caso el “tema” podríamos indicar que queda algo “cojo” y poco clarificado para poder utilizar posteriormente dicho DataStore desde una integración con cualquier versión de XenApp.

 

El primer proceso pasará por la instalación del cliente oracle, en este caso hemos procedido a utilizar el cliente de Oracle 10g (Release 10.1.0.2), para realizar la respectiva creación del respectivo conector y que este pueda ser utilizado posteriormente desde XenApp 4.5.

 

Al insertar el respectivo CD de Oracle Client 10g. Release (10.1.0.2), arrancará el proceso de instalación, aceptando la pantalla de Welcome , pulsando Next, prescindiendo de las opciones mostradas a continuación, como “Deinstall Products…”

 

 

 

Pulsaremos Next para iniciar el proceso de instalación apareciendo la siguiente dialog:

  

Seleccionaremos el path donde deseamos que se realice la instalación y el nombre de la respectiva carpeta de instalación, tal y como se muestra en la dialog anterior, los datos serán los establecidos a continuación:

 

Ø Path Source: Defecto

Ø Name: Defecto

Ø Path: Defecto

 

 posteriormente a ella, pulsaremos Next, apareciendo al siguiente dialog con el respectivo contenido:

 

 

 

En esta seleccionaremos los respectivos idiomas a utilizar, en nuestro caso añadiremos Spanish, seleccionando en Available Languages el idioma correspondiente y pulsando la flecha de Añadir, teniendo posteriormente seleccionados los idiomas, Spanish y English. Pulsando Ok

 

Una vez pulsado Ok, aparecerá la selección de que modalidad o que tipo de instalación deseamos realizar, para ello seleccionaremos la opción de Custom.

 

 

Pulsando a continuación, Next para continuar, apareciendo la siguiente dialog:

 

 

Para ello seleccionaremos los siguientes módulos Oracle:

 

ü  Oracle Network Utilities

ü  Oracle Java Utilities

ü  SQL *Plus

ü  Oracle JDB/OCI Interfaces

ü  Oracle JDB/THIN Interfaces

ü  Oracle Windows Interface

ü  Oracle XML Developer’s kit

 

Pulsando a continuación Next, seleccionando el puerto número 2030, y pulsando a continuación Next.

 Apareciendo la siguiente Dialog, con los módulos a instalar:

 

  

Pulsando a continuación INSTALL para iniciar el proceso de instalación, apareciando el proceso de incio de instalación tal y como se muesta:

  

 

Una vez finalizado el proceso de instalación aparecerá una dialog con el respectivo mensaje.

 

 

Una vez finalizado procederemos a utilizar el “Oracle Net Configurator” con el cual configuraremos el acceso a la BD.  Para ello seguiremos los pasos indicados en el Asistente.

 

          Naming Methods Configuration:

           Seleccionamos los módulos de:

Ø Host Name

Ø Local

 Pulsando a continuación Next, para continuar con el respectivo Wizard de configuración.

Ø  Seleccionamos la opción “local net service Name configuration

Ø Seleccionando posteiormente la opción “Oracle8i or Later database or service

Ø Especificaremos posteriormente y este punto el “Service  Name” o nombre de la Base de datos.

Ø Seleccionaremos “TCP” como protocolo de comunicación.

Ø Pulsaremos Next

Ø Posteriormente indicaremos el hostname del servidor de Oracle o su correspondiente IP.

Ø Seleccionaremos el puerto por defecto de Oracle: “1521

Ø Pulsaremos Next

Ø Especificaremos que se realice el test, lo cual nos reportará con un error:

Ø Pulsaremos en “Change Login” y damos las credenciales correctas a utilizar.

 

Llegados a este punto, iniciaremos la instalación de XenApp 4.5. tal y como indica la documentación oficial del producto hasta el punto “Crear comunidad de Servidores”, en este caso seleccionaremos como “Almacén de BD”: Oracle in OraHome92.

 

 

Una vez realizada la respectiva selección, al pulsar siguiente nos solicitarán los datos de conexión ·instancia.user.password y tras ser introducidos correctamente, el fichero tsnames.ora será creado con los datos correctos de conexión y podremos continuar con la instalación de XenAPP.

 

 

 Recomendaciones Generales a utilizar el cliente oracle con ciertas aplicaciones.

 

A nivel del cliente Oracle, tendremos que tener en cuenta que serán necesarios los siguientes aspectos, antes de realizar la instalación del mismo, ya que Oracle genera por defecto la instalación en un directorio determinado.

 

Generación de los DSN correspondientes mediante ODBC

 

ü  Necesidad del nombre DSN a conectar

ü  Usuario y password para realizar test de conexión.

 

Será necesario además el disponer del TNS Service Name.

Modificación del registro de Oracle para establecer el idioma.

 

ü  Será necesario saber el valor de NLS_LANG

 

Modificación del registro para mejora del rendimiento.

Será necesario disponer de los ficheros de configuración de Oracle para poder establecer la conexión de cualquier tipo de aplicación.

 

ü  TSNAMES.ORA

ü  SQLNAT.ORA

 

Asignación de permisos a usuarios locales a las carpetas de Oracle.

Por otra parte será necesario modificar la siguiente clave del registro para un correcto funcionamiento del cliente de Oracle.

 

HKEY_LOCAL_MACHINE–>SOFTWARE–>ORACLE_HOME->NLS_LANG

El valor en NLS_LANG tendría que estar configurado como: AMERICAN_AMERICA.WE8ISO8859P1

 

Categories: General Tags:

Instalación de un Servidor con XenApp 4.5.

martes, 22 de abril de 2008 Sin comentarios


En toda plataforma XenApp 4.5. es recomendable el uso de RAID1 debido a las características de mejora de rendimiento en procesos de lectura, al ser un servidor de aplicaciones, es importante que donde se realice la instalación del Sistema Operativo esté siempre definido en RAID1, por otra parte es importante tener en cuenta la cantidad de memoria RAM necesaria en cada uno de los servidores XenApp 4.5.

XenApp 4.5. por defecto no gestiona más de 4GB de RAM, y el crecimiento no es progresivo en función de la RAM que se añada, pero sí que por el contrario puede ser beneficioso en ciertas aplicaciones, que puedan llegar a necesitar de cierta mejora de rendimiento.

XenApp 4.5. mejora su rendimiento en primer lugar a nivel de RAM disponible y posteriormente a nivel de arquitectura física de hardware de equipo y RAID utilizado.

A nivel de Hardware y del sistema operativo deberá de estar instalado para conseguir el máximo rendimiento, de la siguiente forma:

RAM, módulos con mismo voltaje. Recomendable 4GB por servidor.
1 o 2 Procesadores a 3Ghz o superior
RAID 1.
Discos con espacio suficiente contemplando posibilidad de crecimiento.
Recomendación de discos de 72GB (mínimo)
Una única partición y unidad.
20% como mínimo de espacio libre en dicha unidad, posteriormente a aplicar el fichero de paginación.
Timing entre tarjetas de red, en caso necesario.
Resolución 1024×764 a nivel de tarjeta gráfica como mínimo para consolas administrativas.

Entre sus distintas virtudes, cualquier plataforma XenApp 4.5, debe de disponer de los correspondientes ficheros de paginación correctamente implementados y configurados, así como el suficiente espacio en disco para no entrar nunca en un proceso de servicio lento a nivel del suministro de accesos y aplicaciones.

Este fichero de paginación deberá de cumplir los siguientes requisitos:

2.5 veces la RAM existente en el servidor.
Misma unidad en la que sea instalado el sistema operativo.
20% como mínimo de espacio libre en dicha unidad.
Instalación de la consola de recuperación.

Hay que tener en cuenta que en el caso o necesidad de tener que incrementar RAM en cada uno de los respectivos servidores a más de 4GB de RAM, será necesario reinstalar el servidor si no ha existido previsión de crecimiento, en este caso y para evitar este tipo de problemas futuros, se recomienda la instalación de Windows Server 2003 Enterprise.

Cualquier plataforma XenApp 4.5. es de carácter multilenguaje, pero ello no quiere decir que la aplicación de los parches del fabricante sean de carácter mixto, en cualquier plataforma de estas características se aconseja el uso de Idioma Inglés, pero en contrapartida el sistema operativo debe de estar instalado en el mismo idioma que XenApp 4.5.

Con ello podemos encontrarnos con dos problemas adicionales, si no han sido contemplados o planteados al cliente, siendo los siguientes:

Uso del cliente ICA32 con publicación de escritorio (aparecerá en Inglés).
Actualización del cliente ICA32, muy pesado y elevado consumo de ancho de banda en el proceso de actualización automático.
En el caso del que el cliente utilice el escritorio completo, existen productos adicionales de Citrix, que podrían solucionar este tema, publicando un escritorio remoto previamente definido, este proceso quedaría cubierto con XenDesktop, en el caso de que no sea posible por problemas de costes, podremos publicar el escritorio del usuario definido por el perfil del mismo y generado en cada uno de los servidores de XenApp 4.5.

Ello representará el tener en cuenta la necesidad de una securización de cada uno de los Servidores de XenApp 4.5.

En este caso se deberán de cumplir los siguientes requisitos:

Sistema Operativo en Español con SP1 aplicado (mínimo) (recomendado W3KSR2+SP2).
Añadir Servidor al dominio.
Instalar los servicios de Termina.l.
Servicios de Terminal Instalados.
Desactivar el uso de IE a los usuarios.
Seguridad Media.
Forzar la asignación del servidor de licencias mediante IP.
Los servicios de Terminal podrán ser configurados en función de las necesidades reales de la plataforma, inicialmente tendrían que ser establecidos por puesto, en el caso de que existiera algún servidor de licencias de Terminal Server con Windows 2000 Server, se establecería el licenciamiento por usuario.
En este último punto de establecer una licencia por usuario, el servidor de Licencias de Terminal no realiza un control de las licencias ni una gestión de las mismas. Pero si que por el contrario será necesario el disponer de las respectivas CAL para cada puesto susceptible a poder establecer conexión a la granja.

Hay que tener en cuenta los siguientes puntos de cara al licenciamiento de licencias de Terminal con las licencias concurrentes de XenApp 4.5. En el caso de que el servidor de licencias de Terminal tuviera un número superior de licencias CAL a las establecidas por XenApp 4.5. se establecerán siempre las existentes o disponibles por XenApp 4.5., ello quiere decir que en estos casos el resto de CAL disponibles de Terminal Server serán desestimadas.

Instalación de .NET 2.0. (en un orden muy concreto y determinado).
La instalación de .NET 2.0 debe de ser implementado e instalado en un orden muy determinado, ya que en el caso de cambiar dicho orden la instalación de XenApp 4.5. no será estable y podrá ocasionar problemas posteriores.
Desactivación de actualizaciones automáticas.
Remap de unidades (en caso necesario).
Antivirus
XenApp 4.5. tiene algunos problemas en cuanto a compatibilidades con ciertos antivirus del mercado, se desaconseja en su totalidad el uso en todas sus vertientes de antivirus de los fabricantes:
McAfee, Norton,Panda

Aconsejamos en medida de lo posible el uso de Trend Micro, actualmente uno de los dos antivirus certificados por Citrix y el único con el máximo indice de compatiblidad. Garantizando de esta forma un correcto funcionamiento de la plataforma.
Registro de licencias de XenApp 4.5. en MyCitrix, generación del fichero de licenciamiento.
XenApp 4.5. en Español. / Sitema Operativo en Español
En el caso de un DataStore con Oracle o SQL Server, Disponer del Data Store creado, según indicaciones del fabricante.

En cuanto a los perfiles de los usuarios, se establecerá un redireccionamiento de los mismos a un file Server, este redireccionamiento contará de los siguientes puntos:

Aplicación de politicas locales para establecer redireccionamiento.
Redireccionamiento a una unidad compartida FileServer.
Perfil bloqueado a nivel de politica local a 15MB.
Utilización de Roaming Profiles para la mejora de rendimiento y velocidad de acceso evitando de esta forma:
Problemas constantes de corrupción de perfiles de usuario.
Acceso inicial centralizado en el File Server, en caso de fallar, generación de un perfil temporal para establecer el acceso del usuario.
Dentro de la parte correspondiente a los perfiles, tendremos que tener en cuenta el Home Directory del usuario, lo que sería o estaría establecido como el directorio de trabajo de este, el Home Directory, quedará establecido en la definición del usuario en el Directorio activo, en la pestaña correspondiente a Servicios de Terminal. Para ello será necesario tener disponible:

Unidad compartida con acceso especifico del usuario
Asignación en las propiedades del usuario el acceso a la misma.
Previsión de publicación de Mi Maletín, redireccionado a dicha unidad.
Entre las distintas configuraciones de cada uno de los servidores de Windows 2003, será necesario habilitar la funcionalidad de “Remote Desktop” y añadir posteriormente los usuarios que pueden establecer conexin, los usuarios del dominio, tendrán además que estar incluidos en el grupo de Remote Desktop.

En cuanto al proceso de conexión a los servidores se establece de forma remota, con el fín de facilitar el proceso de integración e implementación de la nueva plataforma, para ello se establecerá la configuración correspondiente a la habilitación del Remote Desktop a nivel de servidor, asignando a este los permisos correspondientes, tal y como se muestra a continuación (System Properties):

Una vez definidos todas las necesidades y disponer de los respectivos passwords y usuarios de acceso se procederá a la instalación del primer servidor con XenApp 4.5.

Para ello se establecerá un check list, para evitar de esta forma el poder dejarse u olvidarse cualquier procedimiento de instalación., El proceso de XenApp 4.5. en el servidor primario será establecido de la siguiente forma y siguiendo estos puntos:

Nombre de la nueva comunidad XenApp 4.5.
Instalación .NET 2.0
Instalar Access Management Console (complete 10 componentes).
Desactivar agente de Program Neighborhood.
Passthrought No.
Crear una nueva comunidad.
Especificamos el nombre de la nueva comunidad
Especificamos posteriormente la configuración del servidor Data Store con ORACLE.
El proceso de creación del Data Store con ORACLE se realiza según las indicaciones del fabricante. .
Especificaremos la definición de la Zona primaria.
Estableceremos la granja como predeterminada.
Realizaremos el test de conectividad.
Estableceremos el remedo por detecto.
Seleccionaremos el puerto necesario a nivel de TCP.

XenApp 4.5. realiza una serie de instalaciones de Software adicional como es el caso de JAVA JRE, en este caso será necesario realizar una serie de modificaciones en el registro, que equivaldrán a las especificadas a continuación:

Evitar Iconos de Java automáticos
Evitar actualizaciones de Java automáticas
Datos importantes en la generación de Zonas.
Se generarán dos zonas en el caso necesario.
La generación será establecida de una zona por servidor para poder disponer de tolerancia a fallos a nivel del Data Collector, ello permitirá el disponer de alta disponibilidad, en el caso de fallo del servidor primario de la granja dispondremos siempre de un Data Collector de Backup para seguir funcionando de forma correcta, mientras son realizados las tareas de Recovery.
Las tareas de Recovery de un servidor primario, deben de ser exactas al servidor inicialmente implementado, en estos casos es recomendable realizar un plan de recuperación adecuado.

Sobre el DataStore en Oracle

A nivel del cliente Oracle, tendremos que tener en cuenta que serán necesarios los siguientes aspectos, antes de realizar la instalación del mismo, ya que Oracle genera por defecto la instalación en un directorio determinado.

 

  Generación de los DSN correspondientes mediante ODBC

·        Necesidad del nombre DSN a conectar

·        Usuario y password para realizar test de conexión.

 Será necesario además el disponer del TNS Service Name.

  Modificación del registro de Oracle para establecer el idioma.

·        Será necesario saber el valor de NLS_LANG

 Modificación del registro para mejora del rendimiento.

 Será necesario disponer de los ficheros de configuración de Oracle para poder establecer la conexión.

·        TSNAMES.ORA

·        SQLNAT.ORA

Asignación de permisos a usuarios locales a las carpetas de Oracle.

 

Categories: General Tags: