Welcome to Delicate template
Header
Just another WordPress site
Header

Chart_XenDesktopVDA

 

Mas información en: CTX136668

Problema común que nos podemos encontrar en ciertas implementaciones.

Existen pero una serie de pasos que podemos aplicar para mirar de mejorar el rendimiento de nuestro StoreFront que pueden solventar nuestros problemas de rendimiento con StoreFront.

– Deshabilitar Netbios sobre TCP.

– Habilitar Socket Pooling (En StoreFront no puede hacer-se desde consola).

SocketPooling esta des-habilitado por defecto en todo los Stores que generemos dentro de StoreFront. Para habilitar Socket Pooling, seguiremos los siguientes pasos:

• Editar fichero web.config ubicado en su respectivo Store C:\inetpub\wwwroot\Citrix\storename\

• Buscar la linea: <farmset … pooledSockets=»off» … >

• Modificar el parámetro Off por On.

– Utilizar Application Initialization en el Application Pool (Solo Windows 2012) Aplicar el procedimiento descrito en: http://support.citrix.com/article/CTX137400

– Des-habilitar la frma de verificación: Aplicar procedimiento descrito en: http://support.citrix.com/article/CTX130580

Otros Recursos

Initial Desktop Director Web Page Loading Delay: http://support.citrix.com/article/CTX130580

Web Interface 5.x Delay on First Page: http://support.citrix.com/article/CTX117273

How to Configure IIS to Optimize Receiver for Web Initial Connection: http://support.citrix.com/article/CTX137400

Enable SocketPooling: http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-configure-conf-socket.html

Configuring Recycling Settings for an Application Pool: http://technet.microsoft.com/en-us/library/cc753179%28v=ws.10%29

En este post explicamos algunos de los cmdlets utilizados para la creación de un catálogo en XenDesktop  con el fin de ayudar a entender y realizar nuestras tareas de automatización del Brocker.

Una vez realizado el documento de arquitectura, elegidos y definidos los métodos de despliegue así como la definición del resto de componentes de diseño, tendremos claro que pasos seguir durante el proceso de despliegue. El proceso completo puede realizar-se claramente desde Citrix Studio, pero vamos a realizar un completo deploy desde PowerShell para que veáis como funciona y lo que podemos llegar a realizar desde el mismo.

No vamos a profundizar en el uso de PowerShell, para ello hay muchos manuales y muy bueno colgados en la red.

Empezando

Un Catálogo de máquinas es una colección de máquinas (ya sean físicas o virtuales) que podemos asignar a usuarios de nuestra organización. Podemos desplegar un catalogo basado en equipos físicos (dónde instalamos previamente nuestros agentes VDA) o realizar un deploy automatizado, utilizando servicios como MCS o PVS, desde una GoldImage previamente generada.

El primer paso, es la generación de este catalogo , para ello utilizaremos el comando “New-BrockerCatalog”.

Debemos tener en cuenta la sintaxis a utilizar, la cual se establece de la siguiente forma.

SYNTAX. Ver Aquí

Generemos el Catalogo y veamos posteriormente que hemos hecho:

NewC-BrokerCatalog –name ‘PowerShell_Catalog’ –AllocationType ‘Permanent’ -MachineArePhysical $false -ProvisioningType ‘Manual’ -SessionSupport ‘SingleSession’ –PersistUserChanges ‘OnLocal’ -AdminAdress “Localhost:80” –Description ‘Catalogo creado en PowerShell’

1

Tras la ejecución del comando, podemos ver el nuevo Catalogo generado en nuestra consola de Studio.

Ahora ya tenemos generado el catalogo, hemos indicado que tipo de maquinas incluirá y nos toca proceder a incluir-las. Recordad, que podemos obtener datos de nuestro catalogo con el comando Get-BrockerCatalog –name ‘Name_Catalog’. Aunque no todos los parámetros del catalogo son modificables y en alguos casos será necesario crear uno nuevo si deseamos otro tipo.

Veamos ahora que ocurre si generamos un Catalogo, del tipo MCS con la sintaxis anterior:

New-BrokerCatalog –name ‘PowerShell_Catalog2’ –AllocationType ‘Random’ -MachineArePhysical $false -ProvisioningType ‘MCS’ -SessionSupport ‘SingleSession’ –PersistUserChanges ‘OnLocal’ -AdminAdress “Localhost:80” –Description ‘Catalogo creado en PowerShell’

Durante el proceso de creación no obtendremos errores, pero al comprobar nuestra consola:

2

Esto es normal, debido a que hemos indicado que se genere un catalogo de tipo MCS sin indicar datos relativos a la imagen que será utilizada para el deploy.

3

Veamos como solucionar-lo. Si intentamos solucionar el problema desde la MMC, veremos que no disponemos de opciones para ello, y únicamente podremos realizar un test o borrar el catalogo para generar de nuevo.

4

Lo primero que debemos hacer, es generar un IdentityPool. Y que es esto? Los cmdlet AcctIdentityPool proporcionan la habilidad de generar pool que pueden ser almacenados como máquinas en AD. Para ello debe ser provisto de el nombre de esquema, el tipo de esquema, la OU y el dominio al que hace referencia, para que sea utilizado para el almacenaje de las nuevas cuentas.

Su sintaxis puede ser consultada Aquí.

Veamos como utilizar-lo.

New-AcctIdentityPool -AdminAddress ‘localhost:80′ -AllowUnicode -Domain ‘ctxdom.local’ -IdentityPoolName ‘Ejemplo_PowerShellVMs’ -NamingScheme ‘Maquina-####’ -NamingSchemeType ‘Numeric’

5

Ahora ya hemos definido como van a generar-se las VMs en nuestro AD y dónde.Continuemos con el proceso.

Es el momento de crear nuestros metadatos del catálogo de la siguiente forma. Este paso no es obligatorio.

Set-BrokerCatalogMetadata -AdminAddress ‘localhost:80’ -CatalogId 5 -Name ‘Citrix_Desktop_PShellCatalog’ –Value ‘1234’

El nombre por defecto suele ser: Citrix_DesktopStudio_IdentityPoolUid. El CatalogID lo podemos encontrar realizando una consulta. Tal como comentamos anteriormente, tenemos los cmdlets que empiezan con “get-“ los cuales nos permitirán obtener información. Podemos obtener el ID de nuestro catalogo de la siguiente forma:

Get-BrokerCatalog | ft Name, Uid

Donde obtendremos el listado de catálogos con su respectivo ID.

6

Opcional: Chekear Catalogo

Test-ProvSchemeNameAvailable -AdminAddress ‘Localhost:80’ -ProvisioningSchemeName @(‘Ejemplo_PowerShellVMs’)

Ahora es momento de crear el objeto de esquema para el aprovisionamiento de VMs.

Syntaxis aquí.

El proceso de creación hace una copia del disco duro conectado a una instantánea de máquina virtual y lo almacena en el lugar de almacenamiento que la unidad de alojamiento en el esquema de provisiones define . Esta es una tarea de larga y por lo general tomará un rato en completar la operación (dependiendo del tamaño del disco duro que está siendo copiado y el número de instantáneas generado ) .

Para la generación de las VMs deben utilizar-se Snapshot en lugar de la propia VM, de forma que el contenido del disco duro pueda ser determinado fácilmente.

Para este cmdlet se requiere información facilitada por el “Citrix Machine Creation Services: Hosting Unit Service Snapin”, el cual provee información relativa a los hipervisores. También toma información del Snapin de “AD Identity Service”, el cual proporciona información acerca de los IdentityPool.

El esquema de aprovisionamiento es una colección de todos los datos que son necesarios para generar una plantilla desde las cuales las VMs serán creadas. Por ello, necesitamos la siguiente información.

• Hosting Unit A definido en el HostService, así como la red y el almacenamiento definido previamente.
• Un IdentityPool definido.

Veamos un ejemplo de cración de esquema sencillo.

New-ProvScheme -CleanOnBoot -HostingUnitName HostSettings -IdentityPoolName Ejemplo_VMs_Pshell -MasterImageVM ‘XDHyp:\hostingunits\HostSettings\XenDesktop_Shared.VM\NEW UPGRADE XD7.5 VDA.snapshot’ -ProvisioningSchemeName ‘PowerShellScheme’

8

El proceso tardará un rato. Adicionalmente, podemos especificar la red a utilizar, númeor de CPUs y memoria, mediante los parámetros indicados en Syntaxis. O se puede modificar posteriormente mediante el comando Set-.

Podemos especificar el num de CPU o memoria con los parámetros –VMMemoryMB o – VMCpuCount

Cabe recalcar, que IdentityPoolName debe coincidir con el PoolName creado en el punto 2 del proceso. Así como ProvisioningSchemeName debe ser un nombre único.

9

Ahora vamos a actualizar nuestro Catalogo al cual vamos a asignar el esquema de PVS recien creado.

Set-Broker –Name PowerShell_Calago2 –ProvisioningSchemeID f75ced9b-7ef4-47a7-ad1e-22694ae190fd

Añadimos direcciones de controlador al esquema de aprovisionamiento. Esta es la lista de controladores donde las maquinas creadas pueden registrar-se . Esto solo afecta a las maquinas que sean creadas. No afectará a las maquinas ya creadas.

Add-ProvSchemeControllerAddress -AdminAddress ‘localhost:80’ -ControllerAddress @(‘Citrix1.ctxdom.local) -ProvisioningSchemeName ‘PowerShellScheme’

91

Vamos a ver como crear ahora las cuentas de nuestras VMs en AD.

New-AcctADAccount -Count 2 -IdentityPoolUid 79ae43e8-09e6-4b0f-93f6-c34ce81f73a0

Esto creara, según lo definido en el IdentityPool, dos cuentas [“Count2”] con la nomenclatura Maquina-#### que definimos anteriormente. Maquina-0001 Maquina-0002.

92

Podemos verlas en nuestra dirección AD suministrada.

93

Y ahora queda desplegar VMs. Hemos generado el GoldenImage desde un Snapshot, hemos creado las cuentas de AD, hemos generado la definición de las VMs con el esquema de PVs y ahora es momento de deployar.

New-ProvVM -ADAccountName @(‘CTXDOM\Maquina-0001$’,’CTXDOM\Maquina-0002$’) -ProvisioningSchemeName ‘ExampleMachines’ -RunAsynchronously

94

Podemos obtener el VMID ejecutando el comando “Get-ProvVM”. Ahora, bloqueamos la maquina y prevenimos posibles cambios accidentales sobre la misma.

Lock-ProvVM -ProvisioningSchemeName ‘ PowerShellScheme’ -Tag ‘Brokered’ -VMID @(‘VMID_VM’)

95

Añadimos una máquina asignada al sitio. Este paso se utiliza para fabricación de la máquina disponible para ejecutar aplicaciones y escritorios de los usuarios.

New-BrokerMachine -CatalogUid -MachineName CTXDOM\Maquina-0001′
New-BrokerMachine -CatalogUid -MachineName CTXDOM\Maquina-0002′

Detalles:

96 97

Al no definir anteriormente el parámetro CPU y MEM, toma como defecto, el valor de la VM utilizada como master.

98

Y aquí tenemos nuestras VMs en nuestro Host Hyper-V.

99

¿Y todo esto, para que?

Los administradores solemos realizar muchos procesos repetitivos diariamente. No cabe entrar en detalle  la utilidad del Scripting y sus posibilidades. Si a priori generar estos procesos puede ser algo engorroso y/o tediosos, una vez preparados nuestros correspondientes Scripts nos permitirán automatizar tareas que realizamos de forma común de forma mas ágil y rápida, reduciendo la cantidad de faena así como evitando errores en la ejecución de las tareas.

Recursos adicionales:

http://support.citrix.com/static/kc/CTX127254/help/New-BrokerCatalog.html
http://support.citrix.com/static/kc/CTX127254/help/Set-BrokerCatalog.html
http://support.citrix.com/proddocs/topic/infocenter/ic-how-to-use.html
http://support.citrix.com/static/kc/CTX127254/help/New-ProvScheme.html
http://support.citrix.com/static/kc/CTX127254/help/about_HypHostSnapin.html
http://support.citrix.com/static/kc/CTX127254/help/Get-HypConfigurationDataForItem.html
http://support.citrix.com/static/kc/CTX127254/help/Lock-ProvVM.html
http://support.citrix.com/static/kc/CTX127254/help/New-BrokerMachine.html

Relog.exe  es una herramienta la cual nos permite trabajar sobre los ficheros .blg de contadores obtenidos mediante la heramienta de perfmon. Relog.exe crea nuevos logs de performance en base a un contador inicial pudiendo realizar varias tareas sobre el mismo, como acortar y/o convertir.

Podemos obtener la sintaxis completa de esta herramienta ejecutando desde CMD el siguiente comando:

rerelog.exe -?

Si se ejecuta obtenemos la siguiente salida:

Parameters: 

<filename [filename …]>     Performance file to relog.

Options:

  -?                            Displays context sensitive help.

  -a                            Append output to the existing binary file.

  -c <path [path …]>          Counters to filter from the input log.

   -cf <filename>                File listing performance counters to filter from the input log. Default is all counters in the original log file.

  -f <CSV|TSV|BIN|SQL>          Output file format.

  -t <value>                    Only write every nth record into the output file. Default is to write every record.

  -o                            Output file path or SQL database.

  -b <dd/MM/yyyy H:mm:ss>       Begin time for the first record to write into the output file.

  -e <dd/MM/yyyy H:mm:ss>       End time for the last record to write into the output file.

  -config <filename>            Settings file containing command options.

  -q                            List performance counters in the input file.

  -y                            Answer yes to all questions without prompting.

 Veamos algunos ejemplos sobre lo que podemos hacer:

Convertir un Log: Convertir un Log nos permitirá ,por ejemplo, generar un CSV desde el blg original. Aunque el uso de blg es amigable para los administradores, puede ser necesario en muchas ocasiones trabajar en CSV sobre dichos ficheros.  Este proceso es muy sencillo, simplemente ejecutamos:

Relog.exe FicheroLog.blg –f CSV –o NuevoNombre.CSV

Filtrar contadores determinados: Esta funcion es muy útil cuando se han sacado muchos contadores y solo queremos obtener y trabajar sobre un contador especifico. Imaginemos que queremos trabajar unicamente sobre los contadores de % tiempo de procesador. Podríamos generar un nuevo .blg con la siguiente linea de ejecución:

Relog FicheroLog.blg –c “\Processor(*)\%Processor Time” –o NuevoFichero_filtrado.blg

Este filtrado tambien podemos realizar-lo apoyados sobre un fichero txt con una lista de contadores concreta. El formato debe ser el siguiente:

\Memory\Pages/sec

\Hyper-V Hypervisor Virtual Processor(_Total)\% Guest Run Time

\Server\Logon Total

\PhysicalDisk(_Total)\% Idle Time

Un contador por cada linea. Y podemos ejecutar-lo de la siguiente forma:

Relog.exe FicheroLog.blg –cf ficheroContadores.txt –o NuevoFichero.blg

Filtrar un contador por tiempo: Este es el tipo de filtrado que mas utilizo. A menudo los clientes me envian contadores sin paradas durante varios dias. Ello implica un contador con poco detalle que abarca varios dias y con el que es sumamente dificil trabajar. Para estos casos, relog es la mejor herramienta, la cual nos permite seleccionar un periodo de tiempo del contador y generar un nuevo contador mas pequeño con la información necesaria. Para ello ejecutaremos:

Relog.exe fichero.blg –b “DD/MM/YYY HH:MM:SS” –e “DD/MM/YYY HH:MM:SS” –o nuevoFichero.blg

 Input

—————-

File(s):

     .\Performance Counter.blg (Binary)

Begin:    9/1/2014 13:11:24

End:      10/1/2014 13:11:22

Samples:  8641

100.00%

—————-

Output

—————-

File:     PERFORMANCE_DAY1.blg

Begin:    9/1/2014 13:11:24

End:      9/1/2014 20:11:00

Samples:  2518

Consultar los contadores dentro de un blg. Relog nos permite obtener una lista de los contadores incluidos dentro de un fichero de perfomance sin la necesedida de abrir-lo. Ademas al sacar una lista, es facil exportar-la a un fichero para poder indicar-le al próximo cliente que contadores debe sacar ;). Para ello ejecutaremos:

Relog.exe –q fichero.blg

Filtar Registros según valor: Adicionalmente, sobre todo el procesamiento, podemos incluir el modificador –t<valor> el cual nos permite filtrar el contador BLG sobre cada x registro. Es decir, si disponemos de un contador que cada 10 sec. tenemos un registro del contador obtenido cada 10 sec.

Registro1 -> 10segundos despues -> Registro2 -> 10segundos despues -> Registro3 -> 10segundos despues -> Nregistro (…)

Este parametro (-t) nos permite escoger cada cuantos registros incluimos en el nuevo fichero. Es decir, si ponemos –t 2 diremos que obtenga unicamente 1 registro cada 2. Así pues obtendriamos:

Registro1(incluido) – Registro2(descartado)  – Registro3(incluido).

De este modo simplificamos y reducimos el fichero blg para su uso, aunque tambien reducimos el detalle global del contador.

Tips: Ten en cuenta que todos los tipos de filtrajes pueden ser mezclados, asi pues podemos acortar en el tiempo un blg al mismo tiempo que seleccionamos contadores especificos y lo convertimos en CSV. ¿Fácil no?

Resources: http://technet.microsoft.com/en-us/library/bb490958.aspx

La herramienta de Windows PowerCFG soporta una opción en linea que nos permite utilizar la herramienta para el análisis de la eficiencia energética de inactividad del servidor.

Energy

Cuando se ejecuta powercfg /energy la herramienta realizar durante 60 segundos una prueba para detectar posibles problemas de eficiencia energética y genera un informa HTML situado por defecto en:

C:\Users\USERX\energy-report.html

Para asegurar un análisis correcto, asegúrese que todas las aplicaciones locales están cerradas antes de ejecutar el comando.

Nota: PowerCfg no esta disponible para entornos anteriores a Windows 7 y 2008R2

Esta herramienta proporciona una forma sencilla de identificar corregir problemas de administración de la energía y podrían convertir-se en ahorro significativos. Para obtener ayuda visitar: http://goo.gl/lZtDh5

Tan rápido como ejecutar en nuestra consola de power-Shell del servidor:

Add-WindowsFeature “RSAT-AD-Tools”

Una vez finalizado el proceso, ya dispondremos de nuestras consolas para la administración remota de nuestro entorno.

rsat1

 

Concurso Microsoft Drones: Os dejo un interesante concurso de microsoft en el que podéis ganar un ARDrone2.0 estas navidades. http://www.laguerradelosdrones.com/