Welcome to Delicate template
Header
Just another WordPress site
Header

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

Una opcion básica que he echado de menos en hyper-v 3 es la generación de un template o el clonaje de VMs.

En Hyper-V 2 si tenemos la opción de clonado desde las acciones de virtual machine, pero donde esta en Hyper-V 3!!?

De echo, las acciones disponibles sobre la VM en hyper-V3 son:

clone_actions

¿Que hay de mi “clone”?!!  Por desgracia, si quieres disfrutar de esta funcionalidad (entre otras muchas) en Hyper-V 3, no te quedara otra que implementar SCVMM. Sin duda una gran solución, pero…

…entonces, como lo clonamos vms?

Tenemos varias opciones. En mi caso realizo un export sobre una unidad de red y un import de la VM cuando quiero desplegar. Al realizar el import debemos asegurar-nos de utilizar la opción “copy the virtual machine” para generar un nuevo ID de maquina.

hyperv2

Otra opción, es el clonaje manual. Copiamos la estructura de carpetas de la “imagen”. Creamos una nueva VM y atachamos el disco “clonado” en lugar de crear uno nuevo. Prefiero la primera opción, pues evitamos tener que crear toda la estructura de carpetas.

Como dice Porky “eso es todoa amigos”.

Esperemos por eso, que en futuras actualizaciones Microsoft tome nota de este  ¿“lapsus”? …

Generando un perfil por defecto centralizado

Existen muchos casos en los cuales los perfiles de usuarios deben ser, no solo optimizados, si no customizados por necesidades de los mismos.

Estas modificaciones o customizaciones del mismo, pueden incluir, desde iconos específicos por defecto en el escritorio de usuario, modificaciones sobre la moneda y/o el sistema decimal i/o otras modificaciones no realizables o que no vale la pena incluir en modificaciones por GPOs.

Disponer de un perfil default customizado, posibilita que cualquier nuevo usuario en el entorno, disponga de un esqueleto del mismo, de forma predeterminada, evitando tener que modificar el mismo una vez generado por parte del usuario. De este modo, cualquier modificación que deba afectar a todos los usuarios, será incluido en este perfil.

Generando el esqueleto por defecto.

Lo primero que debemos saber es que debe incluir o que modificaciones deben ser comunes para todo el global de los usuarios de nuestro entorno. Es importante saber de antemano que es necesario, pues nos evitará tener que ir modificación/regenerando el perfil por defecto una y otra vez.

Una vez sepamos que cambios deben ser aplicados de antemano sobre el perfil de usuario, procederemos a la generación del mismo, siguiendo los pasos definidos a continuación:

Cabe tener en cuenta que :

El único método admitido para la personalización del perfil de usuario predeterminado es mediante el parámetro Microsoft-Windows-Shell-Setup\CopyProfile que se encuentra en el archivo de respuesta Unattend.xml. El archivo de respuesta Unattend.xml se transfiere al la Herramienta de preparación del sistema (Sysprep.exe).

Procedimiento:

Iniciar sesión como Administrador local o un usuarios con derechos de administrador ocal. Es importante tener en cuenta que no es posible realizar este proceso con una cuenta de administrador de dominio.

A grandes rasgos, en este punto, debemos realizar todas las modificaciones sobre el perfil, que queramos que sean incluidas en el defaultprofile.

Tras ello, procederemos a generar el fichero de creación unattended.xml.

Vamos a ver el procedimiento por pasos.

–       Nos logamos como administrador local

–       Realizamos los cambios específicos sobre el perfil.

–       Creamos el fichero unattend en C:\windows\system32\sysprep\

–       Este fichero debe incluir como mínimo la opción Microsoft-Windows-Shell-Setup\CopyProfile en True.

–       Establecer la opción “CopyProfile” a “True”

–       Ejecutar:  sysprep /generalize /oobe /unattend:unattend.xml

Como generamos el fichero unattend.xml

Utilizaremos para ello Windows SIM (incluido en el AIK Y/o ADK) el cual nos permitirá generar el fichero unattend a través de una GUI.

profile_1

Una vez descargado e instalado en nuestra maquina, generamos el fichero unattend.xml como mínimo, con la opción de CopyProfile, utilizando para ello Windows SIM.

Utilizando Windows SIM

Instalado nuestro SIM desde AEK o desde AIK (segundo el SO utilizado), procedemos a la generación de nuestro unattend.xml.

Profile_2

Abrimos Windows SIM y creamos un nuevo fichero de respuesta.

Profile_3

Para modificar el archivo de respuesta, necesitaremos disponer de una imagen de Windows. Para ello, copiaremos en un recurso local la ruta “Sources” del CD de instalación. En ella se incluyen los ficheros de Windows Image necesarios.

Especificamos imagen .win a utilizar y generamos el catalogo .clg.

Profile_4 Profile_5

En este punto, vamos a incluir la opción de copia de perfil. Expandimos “Components” y buscamos amd64_Microsoft-Windows-Shell-Setup.

Profile_6

Agregamos el componente en la sección 4_Specialize:

Profile_7

En el archivo de respuesta seleccionar: Components\4_specialize\amd64-Microsoft-Windows-Shell-Setup_neutral.

Aquí en la sección de Propiedades establecemos el valor copyProfile a TRUE.

Profile_8

Guardamos el archivo de respuesta como “CopyProfile.xml”

Profile_9

Profile_10

Tras ello, ejecutamos el comando indicado en el procedimiento: sysprep /generalize /unattend:unattend.xml

Tras generalizar la imagen, se apagara el equipo. Esta nueva imagen incluirá el default profile modificado. podemos desplegar desde esta imagen Windows con las configuración especifica del perfil customizado.

Profile_11

Levantada esta imagen, es momento de copiar el default profile en un recurso de red, para utilizar de forma centralizada.

Notas:

–       Si queréis comprobar el log, no utilizar la opción /shutdown en el proceso de sysprep. Podreis encontrar el log en: %systemroot%\panther\unattendgc\setupact.log

–       Debe utilizar el modificador /generalize con sysprep.exe para que se pueda usar el parámetro Copy Profile. La opción /unattend se utiliza para seleccionar el archivo Unattend.xml

–       El perfil de la cuenta predefinida de administrador se elimina cuando se realiza una instalación de Windows limpia o cuando se ejecuta la herramienta Sysprep. El parámetro CopyProfile se procesa antes de que la cuenta predefinida de administrador se elimine. Por lo tanto, cualquier personalización que realice, aparecerá en el nuevo perfil de cuenta de usuario. Esto incluye la configuración de perfil de cuenta predefinida de administrador.

–       Si hay varios perfiles de usuario, puede que la utilidad sysprep de Windows elija un perfil no esperado y lo copie en el perfil de usuario predeterminado. Por ello se recomienda eliminar todos los perfiles del sistema y dejar únicamente el perfil de administrador a modificar.

–       No todas las personalizaciones se propagarán a los nuevos perfiles. El proceso de inicio de sesión del nuevo usuario reestablecerá algunas de las opciones. Para configurar los valores de configuración, utilice la configuración de directiva de grupo o el scripting.

Generando el punto compartido para el Default Profile

Veamos como copiar y definir este perfil de forma centralizada. Para ello, deberemos conectarnos al recurso:

\\DomainServer\NETLOGON

Dentro, creamos una carpeta que utilizaremos como default profile, por ejemplo:

Default Profile.V2

Situarnos en Equipo > Propiedades > Configuración Avanzada del sistema

Tras ello, seleccionar el Default Profile y clicar en la opción “Copy to”

Profile_12

Profile_13

Seleccionamos la nueva ubicación del perfil. En nuestro caso, el recurso de red:

\\DomainServer\NETLOGON\Default Profile.V2\

Seleccionamos “Cambiar”  > “todos” > Aceptar.

Una vez realizado, ya podemos utilizar las GPOs de AD para configurar el recurso por defecto para almacenar el perfil default del entorno.

Recursos:

Personalizar el perfil de usuario local predeterminado al preparar una imagen de Windows: http://support.microsoft.com/kb/973289

Utilizar Windows SIM: http://technet.microsoft.com/es-es/library/dd799285%28v=ws.10%29.aspx

Descargar AIK Windows 7 y 2008R2: http://www.microsoft.com/es-es/download/details.aspx?id=5753

Y/O Windows ADK para Windows 8 / 2012 Server:  http://www.microsoft.com/es-es/download/details.aspx?id=39982