Configurar Citrix UPM

Hace unos días os enseñé una presentación sobre conceptos básicos de Citrix. Uno de ellos era User Profile Management o UPM. Como ya os comenté en el otro artículo, es un complemento que viene ya en las versiones de XenDesktop/XenApp, pero que no es necesario implementar.

Por decirlo de forma sencilla, UPM es la forma que tiene Citrix de gestionar los perfiles de los usuarios en un recurso compartido.

Os enseño un diagrama muy interesante que lo explica:

Lo primero de todo, descargamos los ficheros necesarios desde la zona de descargas de Citrix (vienen también en la ISO de la instalación “x64\ProfileManagement\ADM_Templates”), en la sección de Componentes de la versión que nos interesa.

Descomprimimos los ficheros. La carpeta que nos interesa es Group Policy Templates:

Deberemos utilizar los ficheros ADM, ADMX, y ADML de la versión de nuestro sistema operativo que nos interesa. Podéis realizar la carga de los ADMX y ADML en el directorio c:\Windows\Policy Definitions:

Creación y carga GPO Citrix UPM

Primero revisamos que nuestros usuarios de directorio activo tienen activas las siguientes settings:

Una vez configurado el servidor de ficheros, iremos a nuestro controlador de dominio a modificar las GPOs necesarias. En la sección Group Policy Objects, generamos una para Citrix UPM y la editamos con el botón derecho:

Desde Computer > Policies > Administrative Templates > Pulsamos botón derecho Add/Remove Templates…

Pulsamos ADD, ya que vamos a cargar el fichero ADM:

Lo seleccionamos desde la carpeta descargada en el primer punto:

Pulsamos Close:

Ahora tendremos en nuestra nueva GPO la estructura para configurar UPM:

Configurar recurso compartido Citrix UPM

Tendremos que generar en nuestro servidor de ficheros, donde queremos los perfiles de los usuarios, un recurso de red con unos permisos especiales.

Los permisos, que ahora detallamos, serían:

Permisos NTFS:

• Administrators:Full control
• SYSTEM:Full control
• Authenticated users:list folder/read data & create folders/append data, this folder only
• Creator/Owner:full control, subfolders and files only

Permisos SHARE:

• Everyone: Change
• Administrators: Full control

Os explico el detalle. En el recurso compartido, le damos a nivel de Share a Everyone permiso total Read/Write:

Pulsamos Done:

Ahora desde la pestaña Sharing vamos a Advanced Sharing:

Pulsamos sobre Caching:

Y marcamos “No files or programs from the shared folder are available offline”

A nivel NTFS. En la pestaña Security desmarcamos Full Control y Modify para Everyone:

Lo dejamos como en la imagen:

Añadimos a su vez al grupo CREATOR OWNER y les damos Full Control:

También desde Security vamos a Advanced:

Al grupo Everyone pulsamos Edit:

Modificamos el valor Applies to:

Lo dejamos como This folder only:

Repetimos el proceso generando una carpeta para los LOGS:

Una vez terminados los permisos del recurso, vamos a Control Panel à Network and Internet –> Network and Sharing Center à Advanced sharing settings y una vez allí marcamos:

• Turn off Network Discovery
• Turn on file and printer sharing

Abrimos Server Manager à File and Storage Services à Shares. Pulsamos botón derecho sobre nuestro Share para UPM y pulsamos Settings. Marcamos “Enable Access-based enumeration”

Configuración GPO Citrix UPM

Habilitar logs para revisión de problemas. Esto se puede hacer habilitando estos parámetros por GPO y crear un recurso para dichos logs:

Lo dejamos de la siguiente forma:

Como directorio dejaremos:

\\CTXFICH01\Log_UPM_Profile\

Directorios a sincronizar para que se guarden las contraseñas entre sesiones:

• AppData\Local\Microsoft\Windows\Caches
• AppData\Local\Microsoft\Credentials
• Appdata\Roaming\Microsoft\Credentials
• Appdata\Roaming\Microsoft\Crypto
• Appdata\Roaming\Microsoft\Protect
• Appdata\Roaming\Microsoft\SystemCertificates

Si dejamos Enabled el valor Profile Streaming no se guarda la sesión del usuario en Sharefile, por ejemplo.

Lista de directorios a ignorar por GPO:

• AppData\Local\Packages
• AppData\Local\TileDataLayer
• AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache\ChromeDWriteFontaCache
• AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache
• AppData\Local\assembly
• AppData\Local\Citrix\DriveMapper3
• AppData\Local\Citrix\SelfService\img
• AppData\Local\Comms
• AppData\Local\CrashDumps
• AppData\Local\Google\Chrome
• AppData\Local\Google\Chrome\User Data\Default\Cache
• AppData\Local\Google\Chrome\User Data\Default\Cached Theme Images
• AppData\Local\Google\Chrome\User Data\Default\JumpListIcons
• AppData\Local\Google\Chrome\User Data\Default\JumpListIconsOld
• AppData\Local\Google\Chrome\User Data\Default\Media Cache
• AppData\Local\Google\Chrome\User Data\Default\Plugin Data
• AppData\Local\Google\Chrome\User Data\PepperFlash
• AppData\Local\Google\Update\download
• AppData\Local\Microsoft\AppV
• AppData\Local\Microsoft\GameDVR
• AppData\Local\Microsoft\Group Policy
• AppData\Local\Microsoft\Internet Explorer\Recovery
• AppData\Local\Microsoft\Internet Explorer\Recovery\High
• AppData\Local\Microsoft\Media Player
• AppData\Local\Microsoft\Messenger
• AppData\Local\Microsoft\Office\14.0\OfficeFileCache
• AppData\Local\Microsoft\Office\14.0\OfficeFileCache.old
• AppData\Local\Microsoft\OneDrive
• AppData\Local\Microsoft\OneNote
• AppData\Local\Microsoft\Outlook
• AppData\Local\Microsoft\PlayReady
• AppData\Local\Microsoft\Terminal Server Client
• AppData\Local\Microsoft\WER
• AppData\Local\Microsoft\Windows Live
• AppData\Local\Microsoft\Windows Live Contacts
• AppData\Local\Microsoft\Windows Live Mail
• AppData\Local\Microsoft\Windows Mail
• AppData\Local\Microsoft\Windows Store
• AppData\Local\Microsoft\Windows\1033
• AppData\Local\Microsoft\Windows\AppCache
• AppData\Local\Microsoft\Windows\Application Shortcuts
• AppData\Local\Microsoft\Windows\Burn
• AppData\Local\Microsoft\Windows\Caches
• AppData\Local\Microsoft\Windows\Cookies
• AppData\Local\Microsoft\Windows\Explorer
• AppData\Local\Microsoft\Windows\GameExplorer
• AppData\Local\Microsoft\Windows\History
• AppData\Local\Microsoft\Windows\INetCache
• AppData\Local\Microsoft\Windows\INetCookies
• AppData\Local\Microsoft\Windows\Notifications
• AppData\Local\Microsoft\Windows\Ringtones
• AppData\Local\Microsoft\Windows\RoamingTiles
• AppData\Local\Microsoft\Windows\Temporary Internet Files
• AppData\Local\Microsoft\Windows\WebCache
• AppData\Local\Microsoft\Windows\WER
• AppData\Local\Microsoft\Windows\WinX
• AppData\Local\Mozilla\Firefox\Profiles\virt4901.default\Cache
• AppData\Local\Mozilla\Firefox\Profiles\virt4901.default\cache2
• AppData\Local\Mozilla\Firefox\Profiles\virt4901.default\safebrowsing-to_delete
• AppData\Local\SAP\SAP GUI
• AppData\Local\SAP\SAP GUI\Cache
• AppData\Local\SAP\SAP GUI\Traces
• AppData\Local\Sun
• AppData\Local\Temp
• AppData\Local\Temporary Internet Files
• AppData\Local\WebEx\wbxcache
• AppData\Local\Windows Live
• AppData\LocalLow
• AppData\Mozilla
• AppData\Roaming\Citrix\PNAgent\AppCache
• AppData\Roaming\Citrix\PNAgent\Icon Cache
• AppData\Roaming\Citrix\PNAgent\ResourceCache
• AppData\Roaming\Citrix\SelfService\Icons
• AppData\Roaming\ICAClient\Cache
• AppData\Roaming\Macromedia\Flash Player\#SharedObjects
• AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys
• AppData\Roaming\Microsoft\Document Building Blocks
• AppData\Roaming\Microsoft\Internet Explorer\UserData
• AppData\Roaming\Microsoft\Templates\LiveContent\Managed\
• AppData\Roaming\Microsoft\Windows\Cookies
• AppData\Roaming\Microsoft\Windows\Network Shortcuts
• AppData\Roaming\Microsoft\Windows\Printer Shortcuts
• AppData\Roaming\Mozilla\Firefox\Crash Reports
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\Crashes
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\healthreport
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\indexedDB
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\minidumps
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\saved-telemetry-pings
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\sessionstore-backups
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\storage
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\weave
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\webapps
• AppData\Roaming\Sun\Java\Deployment\cache
• AppData\Roaming\Sun\Java\Deployment\log
• AppData\Roaming\Sun\Java\Deployment\tmp
• AppData\Temp
• Sharefile
• Software\Microsoft\Windows NT\CurrentVersion\Fonts
• Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes
• Software\Microsoft\Windows\CurrentVersion\UHF\SHC
• Videos
• AppData\Local\Microsoft\Internet Explorer\DOMStore

Ejemplo de ficheros a ignorar:

• AppData\Local\IconCache.db
• *.EXE
• .arcsight\console\log\console.log*
• AppData\Roaming\Microsoft\Excel\*.xar
• *thumn*.db
• *icon*.db
• *.sqlite-journal
• *.sqlite-shm
• *.sqlite-wal
• cookies.*
• downloads.*
• healthreport.*
• patterns-backup*.*
• sessionCheckpoints.*
• Telemetry.*
• webappsstore.*
• *.corrupt
• AppData\Roaming\Mozilla\Firefox\Profiles\profiles.ini
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\*.bak*
• AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.default\parent.lock
• !ctx_localappdata!\Microsoft\Windows\UsrClass.dat*

Configuramos el patch:

\\ctxfich01\UPM_Profile\%username%\!CTX_OSNAME!!CTX_OSBITNESS!

Y habilitamos las entradas:

Deshabilitamos CEIP ya que viene por defecto Enabled:

Para evitar problemas con los perfiles deshabilitamos la siguiente GPO:

Do not check for user ownership of Roaming Profile Folders
en Computer Configuration -> Administrative Templates -> System -> User Profiles

También añadimos los administradores a UPM habilitando la siguiente GPO:

Add the Administrators security group to roaming user profiles
en Computer Configuration -> Administrative Templates -> System -> User Profiles

Set path for Remote Desktop Services Roaming User Profile
en Computer Configuration -> Administrative Templates -> System -> Remote Desktop Session Host -> Profiles

FOLDER REDIRECTION

A nivel de usuario para complementar UPM utilizaremos Folder Redirection. El impacto en el logon puede ser alto…por lo que se recomienda redirigir sólo la de AppData (Roaming) y el resto dejarlas deshabilitadas.

Habilitamos AppData (Roaming) con la ruta del recurso de UPM:

\\CTXFICH01\UPM_Profile\%username%\Win2012R2x64

El resto de carpetas Disabled:

LINK GPO UPM

Para terminar linkamos la GPO de UPM a los servidores que nos interesa:

Elegimos nuestra GPO:

Hacemos una actualización de políticas en uno de los servidores VDA donde haremos las pruebas:

APUNTE FIREWALL WINDOWS

Me he encontrado con un problema con el servidor de ficheros, donde sí se generaban los LOGs, en cambio tenía problemas con los perfiles. Se me generaban perfiles Temporales y no había de que se generaran.

Todo viene con la política por defecto del dominio, que genera una regla para el firewall de windows (Dominio) que lo deja en OFF. Que esté en OFF no significa DESHABILITADO del todo. Hay que dejarlo en NOT CONFIGURED (Salvo que queráis el firewall ON y pelearos con sus reglas).

La GPO por defecto se edita y es éste apartado:

Tendremos que hacer una actualización de políticas en nuestras máquinas.

La entrada Configurar Citrix UPM se publicó primero en VMware Citrix Blog.

Licenciamiento Oracle en VMware

El otro día un compañero me preguntó como se licenciaba Oracle en una infraestructura virtualizada VMware. Como cada tecnología va avanzando, y el negocio es el negocio, cada fabricante tiene que adaptarse a los nuevos avances, para adecuar su licenciamiento. Y Oracle no podía ser menos, así que vamos a conocer cómo se licencia en cada versión:

Licencias Oracle hasta VMware vSphere ESXi 5.0

Hasta la versión 5.0 era requerido un almacenamiento compartido, eso significaba que las máquinas virtuales con Oracle que se ejecutaban en VMware podían correr sobre cualquier host físico ESX que tendría ese almacenamiento compartido configurado. Como Oracle licenciaba núcleos físicos, si tenías un clúster, tenías que licenciar todos los hosts que lo conformaban. Algo nada barato.

Licencias Oracle desde VMware vSphere ESXi 5.1-6.0

En las versiones más recientes de vSphere ESXI, 5.1 y posteriores, los usuarios finales ya no necesitaban tener un almacenamiento compartido para migrar en vivo una máquina virtual en ejecución. Con vMotion se habría otro panorama, ya que la máquina virtual con Oracle podía moverse por cualquier host ESXi.

Como resultado de esto, Oracle requiere la licencia de todos los núcleos físicos de todos los hosts físicos ESXi que son parte de una misma instancia de vCenter Server, incluidos los centros de datos dentro de la instancia de servidor vCenter, ya que el usuario final tiene la capacidad para mover la máquina virtual que ejecuta el software de Oracle a cualquier servidor dentro de la instancia de vCenter Server.

Licencias Oracle hasta VMware vSphere ESXi 6.0 y superior

Con vCenter Server 6.0 o superior, vmware saca una nueva funcionalidad que permite ejecutar varias instancias de vCenter Server, así que una máquina virtual que ejecuta Oracle puede moverse a través de vCenter Server Instances, lo que afecta a la licencia en todo el entorno.

Como resultado de esto, Oracle exige que se licencien todos los núcleos físicos de todos los hosts ESXi físicos de todas las instancias de vCenter Server que tienen hosts con ESXi 6 o hipervisores posteriores.

La entrada Licenciamiento Oracle en VMware se publicó primero en VMware Citrix Blog.

Script Matar Procesos Libreoffice

Hoy os quiero enseñar como matar procesos de Libreoffice a través de Powershell. Os explico un poco los casos de uso para este script. Un aplicativo que no puede tener sesiones en memoria por más de 1 minuto ya que puede dar problemas.

Al final, cuando abres SCALC, por ejemplo, en memoria se generan varios procesos Windows, esos son soffice.bin, soffice.exe, scalc.exe…y si abrimos SWORD, pues sword.exe pero no otro SOFFICE.EXE ni SOFFICE.BIN. Y esto se repite por cada usuario que esté logueado en el equipo.

----soffice.bin
----soffice.exe

             |_______ scalc.exe

             |_______ sword.exe

Si matas soffice.exe no matas los subprocesos, pero eso sí pasa con soffice.bin. Así que, vamos a mirar directamente a SOFFICE.bin para forzar su cierre. Miraremos el ID y nos aseguramos que el proceso de Libreoffice no esté en memoria más de 60 segundos.

Os dejo el script y la explicación por sección, deja log por pantalla y en fichero:

##############################################################################
##############
############# Script Raúl para el Blog de Negu - 24062018
############# 
############ Parar procesos con más de 60 segundos en memoria
##############################################################################
# Clear-Host
# Cargamos una variable con la hora menos 60 segundos
$60Segundos = (Get-Date).AddSeconds(-60)
# Cargamos variable con el cmd más antiguo en memoria
$Procs = get-process -name soffice.bin -ErrorAction SilentlyContinue | Sort StartTime | Select -First 1
# Empezamos a escribir el log
# Start-Transcript ("c:\script\log\matar-procesos{0:yyyyMMdd-HHmmss}.log" -f (Get-Date))
# Si existen procesos en memoria los comprueba
if ($Procs -ne $null)
{
# Revisamos los IDs
ForEach ($ProcID in $Procs.ID)
{
# Vemos la diferencia de tiempo
$diferencia = $60Segundos - $Procs.StartTime
# Si la diferencia es igual o mayor que 1 minuto
if ($diferencia.Minutes -ge '1')
{
$hora1 = Get-Date
# Matamos los IDs de los procesos de más o igual a 1 minuto 
stop-process -id $ProcID -Force
# Exportamos todo a un fichero log
$log1 = Write-Output "Forzamos cierre proceso $ProcID, el dia $hora1, llevaba $diferencia minutos"
Add-Content $log1 -Path "c:\script\log\matar-procesos.log"
Write-Output "##############PROCESOS CERRADOS###############"
Write-Output "Forzamos cierre proceso $ProcID, el dia $hora1, llevaba $diferencia minutos"
Write-Output "##########FIN PROCESOS CERRADOS###############"
} 
# Si hay procesos soffice pero no tienen más de o igual de 1 minuto 
else 
{
$hora2 = Get-Date
# Exportamos todo a un fichero log
$log2 = Write-Output "$hora2, no hay procesos de mas de 60seg que cerrar"
Add-Content $log2 -Path "c:\script\log\matar-procesos.log"
Write-Output "##############NO HAY PROCESOS DE 60SEG###############"
Write-Output "$hora2, no hay procesos de mas de 60seg que cerrar"
Write-Output "##########FIN PROCESOS CERRADOS###############"
}
}
}
# Si no existen procesos soffice en memoria
else
{
$hora3 = Get-Date
# Exportamos todo a un fichero log
$log3 = Write-Output "$hora3, no hay procesos que cerrar"
Add-Content $log3 -Path "c:\script\log\matar-procesos.log"
Write-Output "##############NO HAY PROCESOS A CERRAR########"
Write-Output "$hora3, no hay procesos que cerrar"
Write-Output "##########FIN PROCESOS CERRADOS###############"
#Liberamos variables para nueva ejecucion
Remove-Variable 60segundos
Remove-Variable Procs
}
# Parar la escritura del log
# Stop-Transcript

La entrada Script Matar Procesos Libreoffice se publicó primero en VMware Citrix Blog.

Configurar cabina NETAPP E2800A para VMware

Hoy os quiero mostrar como realizar una instalación de una cabina NetApp E2800A en una plataforma VMware con dos VMware ESXi DELL R640 a través de tarjetas SAS.

Seguiremos las Best Practice: https://community.netapp.com/fukiw75442/attachments/fukiw75442/fas-and-v-series-storage-systems-discussions/2645/1/NetAppandVMwarevSphereStorageBestPracticesJUL10.pdf

Antes de encender el equipo conectamos un cable Ethernet al puerto P1 de la controladora A. No lo haremos con la controladora B y su puerto P1, ya que las buenas prácticas dicen que hay que dejarlo sin configurar por si tienen que venir los técnicos de NetApp a repararnos la cabina.

Por otra parte, conectamos los cables SAS en los puertos 0c y 0d de cada controladora, y los cruzamos con los ESXi:

• Puerto 0c Controladora A –> ESXi1 – Puerto SAS 1
• Puerto 0d Controladora A –> ESXI2 – Puerto SAS 1
• Puerto 0c Controladora B –> ESXi1 – Puerto SAS 2
• Puerto 0d Controladora B –> ESXi2 – Puerto SAS 2

Podemos conectarnos vía software SANTricity o vía web con la IP que lleva por defecto la NetApp E2800A

Por defecto la IP de gestión es la 192.168.128.101/24, así que nos conectamos directamente con nuestro portátil al puerto P1 de la controladora A, y nos colocamos una IP del rango, por ejemplo, 192.168.128.100/24:

Realizamos una pequeña comprobación:

Vamos a un navegador y lanzamos https://192.168.128.101:8443 , la primera pantalla que se carga nos pedirá introducir una contraseña para el usuario admin:

Pulsamos Next:

Introducimos un nombre para el ARRAY:

Pulsamos Next:

Pulsamos Next:

Marcamos YES si queremos Hot Spare (normalmente será que NO, salvo que te sobre disco) y Next:

Configuraremos el servidor de correo más tarde:

Esto dependerá del cliente, interesante para el soporte remoto:

Pulsamos Finish:

Pulsamos Close:

Ya tenemos la primera configuración:

CREAR VOLUMEN GROUP CABINA NETAPP

Pulsamos Create a volumen group:

Introducimos Nombre, tipo de RAID, discos donde lo vamos a usar y capacidad. Montaremos un RAID5 para los discos SAS:

En pocos segundos veremos este mensaje:

Pulsamos Storage > Pools & Volume Groups > Volume Group

Seleccionamos:

AÑADIR HOSTS A CABINA NETAPP

Añadimos los Hosts. Storage –> Hosts

Pulsamos Create –> Host

Completamos los datos del ESXi1:

Repetimos el proceso para el ESXI2.

CREATE VOLUME EN CABINA NETAPP

Pulsamos Create > Volume para asignar a los hosts un volumen:

Asignaremos los host luego:

Crearemos un nuevo Workload y le damos un nombre, en mi caso le añado el del RAID:

Sólo crearemos un datastore VMFS:

Le damos todo el espacio del RAID:

Ahora vamos a editar el nombre y pulsamos Add/Edit Volumes:

Le ponemos un nombre al DATASTORE y cambiamos el tamaño del bloque, en mi caso 512KB

Pulsamos Finish

CREAR HOST CLUSTER EN CABINA NETAPP

Se debe generar un Host Cluster, ya que los dos host van a compartir el mismo Volumen:

Añadimos los hosts ESX:

Ahora asignamos los hosts:

Ahora asignamos los volúmenes:

Veremos los volúmenes asignados:

Con esto ya sólo tendremos que asignar la LUN a nuestros ESXi a través de vCenter.

La entrada Configurar NETAPP E2800A para VMware se publicó primero en VMware Citrix Blog.

Error VMware: La imagen ISO de VMware Tools requerida no existe

Hoy queremos enseñaros como resolver un error que se me ha generado en la versión 6.7 de VMware, en mi caso con los servidores Windows 2016 al intentar actualizar o instalar las VMware Tools. Se ve que las imágenes que adjunta la versión están corruptas.

Por si os preguntáis donde podemos descargar los paquetes ISO o ejecutables (EXE, RPM, DEB…) de las VMware Tools, podéis descargarlos en:

https://packages.vmware.com/tools/esx/index.html

Si simplemente queréis corregir las tools de una máquina o varias pero de forma manual, podéis copiar el ejecutable en el sistema operativo e instalarlo desde el ejecutable, como harías con otro programa.

Yo esto creo que no es lo más recomendable, porque corriges el problema a medias. Así que lo vamos a corregir de una forma más “elegante” llevando el ejecutable donde está mirando nuestro vcenter y ahora tiene problemas. Los ficheros se guardan en los ESXi así que tenemos que habilitar SSH en ellos para poder ir corrigiendo el problema uno a uno:

Luego usaremos Filezilla, por ejemplo, para acceder a los ficheros. La ruta es /productLocker/vmtools

Copiamos los ficheros ISO, SIG y SHA. Y renombramos si existen los de Windows, por ejemplo:

Y volvéis a probar.

La entrada Error VMware: La imagen ISO de VMware Tools requerida no existe se publicó primero en VMware Citrix Blog.

Configurar replicas Veeam para Vmware

Hace unos días , mi Nas Synology murió literalmente. Los famosos procesadores Atom que daban problemas a equipos de varios fabricantes, le ha tocado a mi Nas. Después de tirar el laboratorio varias de las máquinas se han quedado inconsistentes. Así que he tenido que montar varios servidores de pruebas.

Con ello, tengo unos discos duros de 1TB fuera de mi NAS, que realmente no utilizo, y que voy a darles uso de una vez por todas. Ese uso, es simplemente tener una réplica de las máquinas virtuales que más me interesan. Para ello utilizaré una licencia temporal Enterprise de Veeam 9.5 Update 3.

Así que me pongo manos a la obra y os explico como hacerlo. Partimos con una máquina W2016 ya instalada y con VEEAM ejecutándose.

Lo primero es dar de alta nuestra infraestructura VMware. Pulsamos Backup Infraestructure –> VMware vSphere:

Escribimos el nombre o ip de nuestro vcenter y pulsamos Next:

Añadimos las credenciales para conectarnos a nuestro vcenter:

Confiamos en el certificado:

Si no tenéis los parches, mínimo Update1 de la versión 9.5, os dará un error y tendréis que instalarlo. Ya que la versión 6.5-6.7 no funciona en Veeam sin los parches. Pulsamos FINISH:

Una vez preparada la infraestructura, vamos a HOME -> Replication Job -> VMware vSphere:

Le damos un nombre a la tarea de replicación y pulsamos NEXT:

Seleccionamos las máquinas de las que nos interesa hacer una réplica. De la máquina de VEEAM no haremos réplica, sino un backup y la descarga de un OVA, ya que Veeam no recomienda hacer una réplica de ella:

Elegimos el cluster o esxi, la carpeta donde queréis que se organicen las réplicas y el datastore donde se albergarán:

Elegimos la “coletilla” para el nombre de las réplicas, los puntos de restauración y pulsamos Advanced

Marcamos en la pestaña vSphere –> Enable VMware Tools quiescense

Pulsamos Next:

Dependiendo de las máquinas tendréis que hacer varias tareas. Si tiene SQL, si es Windows, es el vCenter,…Marcamos la casilla para VSS si tiene una particularidad en el servicio que da, como el vcenter:

Seleccionamos la programación y pulsamos Apply:

Pulsamos Finish y deberemos testear que se hacen correctamente:

La entrada Configurar replicas Veeam para Vmware se publicó primero en VMware Citrix Blog.

Azure – Primeros pasos

Aunque alguna vez he tocado Azure, llevaba varios meses sin hacerlo, y creo que no he generado nunca contenido sobre él, vamos a ver como serían los primeros pasos para generaros una cuenta y empezar a generar máquinas virtuales.

Lo primero tendremos que crear una cuenta desde https://azure.microsoft.com/es-es/ . Yo previamente ya tenía una cuenta de Microsoft que usaré para esto. Sino la generáis previamente para qu todo sea más cómodo. Generaremos una cuenta gratuita de Azure, así que pulsamos Inicio gratuito:

Pulsamos nuevamente en Inicio gratuito:

Ahora toca lo tedioso que es rellenar los datos del formulario. Mi consejo es que no intentéis mentir, porque tenéis que validar datos y no acabará bien:

Hay que verificar el número de teléfono y la tarjeta de crédito:

Y ya tendremos el registro hecho. Decir que durante 30 días hay 170€ para gastar y aprender con la plataforma. Pulsamos Ir a portal:

La verdad que es todo muy intuitivo, y tenéis la posibilidad de aprender con el asistente del primer arranque:

Pulsamos Crear recursos para empezar. Vamos a lanzar una máquina virtual con Ubuntu:

Seleccionamos Ubuntu:

Tendremos que ir rellenando los datos de la máquina virtual y como no hemos generado un grupo de recursos, generaremos uno nuevo:

Para la clave pública (si no elegís contraseña), vamos a nuestro equipo, si es un Windows, abrimos un powershell y lanzamos el comando (sino podéis usar PuttyGen):

ssh-keygen -t rsa -b 2048

Y con eso generaremos la clave pública SSH:

La copiamos en el formulario (es el contenido del fichero vmubuntu01.pub) y pulsamos Aceptar.

Guardar los ficheros de la clave privada a buen recaudo. Seleccionamos el tipo de HW para la máquina virtual y pulsamos Seleccionar (acordaros que tenemos 170€ para gastar):

Elegimos una zona de disponibilidad:

Los puertos abiertos de forma pública:

Una de las opciones interesantes es disponer de Extensiones extras si lo necesitamos:

Una vez que le damos a Aceptar, tenemos la ventana de Resumen. Pulsamos Crear si hemos terminado. Podemos también descargarla como plantilla para futuras máquinas virtuales:

Comienza la implementación automática. Cuesta unos 5 minutos:

Nos saltará un popup al terminar. Vamos al recurso:

Como podéis ver, es fácil ver la IP Pública y otras opciones sobre la máquina como Reiniciarla, Detener, Conectar…:

Y simplemente tendríamos que entrar por Putty y configurar la clave para validar o la contraseña:

Seguiremos probando para ver qué podemos hacer en Azure con VMware y con Citrix, ya que las opciones son infinitas.

La entrada Azure – Primeros pasos se publicó primero en VMware Citrix Blog.

VMware Error 400 vCenter

Hoy os mostramos el error [400] Se produjo un error al enviar una solicitud de autenticación al servidor de vCenter Single Sign-On. Un error que puede surgir por varios motivos, pero me gustaría daros la solución rápida que a mi me ha servido:

Simplemente, aunque la consola no es accesible, sí lo es la gestión del vCenter. Vais a la URL https://vcenter:5480

Sección Hora:

Y añadís un par de servidores de tiempo, que es lo que provoca el error 400:

Con los servidores configurados, reiniciáis el vCenter:

Y volverá estar accesible en unos minutos:

La entrada VMware Error 400 vCenter se publicó primero en VMware Citrix Blog.

Convertir certificado Lets Encrypt Synology a PFX

Hoy quiero enseñaros a convertir los certificados que exportamos desde Synology en formato PEM (son tres), a un formato PFX, que es lo que lo que normalmente usaremos en ciertas herramientas para añadir certificados.

Lo primero que tenemos que hacer es entrar en el Panel de Control de nuestra Synology –> Seguridad:

Seleccionamos nuestro certificado Lets Encrypt y pulsamos el desplegable:

Pulsamos Exportar certificado:

Descomprimimos los ficheros:

En mi caso usaré Ubuntu directamente desde una consola de Powershell. Así que lanzamos ubuntu con el siguiente comando:

ubuntu.exe

Una vez arrancado, vamos a la ruta donde residen los ficheros:

cd /mnt/c/Users/runzue/Downloads/synology-certificados/

Necesitaremos instalar como root la tool que nos permita realizar la operación si no la tenemos:

apt install libnss3-tools

Y ahora lanzaremos con OpenSSL la exportación a PFX e introducimos credenciales:

openssl pkcs12 -export -out nombredominio.pfx -in cert.pem -inkey privkey.pem -certfile chain.pem -name "nombredominio"

Enter Export Password:
Verifying - Enter Export Password:

Ya tenemos el fichero PFX para subir a Netscaler o donde estimemos:

La entrada Convertir certificado Lets Encrypt Synology a PFX se publicó primero en VMware Citrix Blog.

Crear laboratorio vSAN con testigo en modo Nested

Después de renovar parte del laboratorio, ya tengo suficiente potencia como para crear contenido sobre vSAN, que hasta ahora andaba demasiado justo. He añadido un par de discos SSD y con 64GB de RAM del Shuttle será más que suficiente para mostraros entradas sobre este tema tan interesante.

Usaré para este LAB dos servidores físicos ESXi (Shuttle de 64GB de RAM y HP Microserver Gen8 de 16GB de RAM), cada uno con su disco Flash y con ellos tres ESXi virtuales que vamos a generar en modo Nested y que usaremos en clúster vSAN.

Uno de los pasos para adaptar mi entorno es deshabilitar HA si está habilitado:

Cada ESXi virtual lo configuraremos como los hosts físicos y eso que nos ahorramos. Por otra creamos un clúster vSAN con vSAN activo:

Lo primero que haremos será crear una red en nuestros Switchs distribuidos. Yo re-aprovecho la que utilizo para iSCSI, pero os enseño como crear otra para vSAN:

Pulsamos botón derecho en DSwitch1 –> Grupo de puertos distribuidos –> Nuevo grupo de puertos distribuidos... :

Le damos un nombre significativo como DPort-vSAN:

Lo dejamos por defecto:

Pulsamos FINISH:

Y ya tenemos la red preparada:

Acordaros de luego configurar cada ESXi con la red adecuada:

Ahora generaremos un VMware ESXi que vamos a utilizar para el LAB de vSAN como plantilla de los otros dos:

Creamos nueva máquina:

Seleccionamos Crear una nueva máquina virtual:

Le damos nombre y elegimos una carpeta:

Seleccionamos Host:

Seleccionamos Almacenamiento SSD:

Compatible con ESXi 6.7 y posterior:

Marcamos Otro y VMware ESXi 6.5 o posterior:

Le daremos unos 10GB de RAM , 4 vCPUs y dos discos SSD (uno para caché y otro para máquinas virtuales). Una vez realizada la configuración NO lo añadimos al clúster de los host físicos. Clonamos la máquina 2 veces para generar los otros 2 ESXi Virtuales.

Una de las máquinas virtuales tendrá el role de testigo, no va a almacenar otras máquinas, así que nos sirve este modelo. Lo dejamos fuera del clúster y los configuramos como los fisicos:

Agregamos el disco añadido y lo formateamos para poder utilizarlo

Importante que se detecte como FLASH:

Con todo en condiciones, vamos a configurar el clúster vSAN. Pulsamos en Configurar de nuestro clúster:

Pulsamos en Configurar el clúster de vSAN con dos Hosts. Yo he marcado la pestaña de Desduplicación y compresión. Pulsamos Siguiente:

Deberemos tener configurados interfaces para tráfico vSAN. Pulsamos Siguiente:

Seleccionamos los discos:

Seleccionamos el Host que actuará de testigo:

Seleccionamos los discos para caché y para capacidad del testigo:

Como veis los discos son la suma de ambos hosts:

Con esto ya tendríamos la configuración de nuestro clúster vSAN en modo Nested. Para que esté totalmente disponible tardará unos minutos:

La entrada Crear laboratorio vSAN con testigo en modo Nested se publicó primero en VMware Citrix Blog.

¿Qué es una Arquitectura Multi-tenant?

Mi actual empresa, Cistec Technology, está impulsando nuevas tecnologías de virtualización, y por suerte, yo estoy o estaré involucrado en esos proyectos en mayor o menor medida. Estas cosas te obligan a estar al día de todas las novedades que dan empresas de software como VMware, Citrix, Datacore, Flexxible,…y nuevos términos que van apareciendo en la industria.

Así como ya explicamos qué era la hiperconvergencia, hoy quiero explicaros qué significa disponer de una Arquitectura Multi-Tenant.

Multi-Tenant, se podría definir, como una arquitectura en la que una sola instancia de una aplicación de software sirve a múltiples clientes. Cada cliente sería un Tenant. No quiero que penséis que un Tenant es un usuario aislado. Un tenant, lo más normal, es que sea un grupo de usuarios que comparten un acceso común con privilegios específicos a la instancia de software, separando los datos sensibles.

Este tipo de arquitectura tiene muchísimo más sentido en entornos SAAS (Software como Servicio), que no quiere decir que también en entornos IAAS ó PAAS, donde por ejemplo, un proveedor pone a disposición de cliente bases de datos SQL y servidores WEB, para alojar páginas como este blog.

Al final, que una infraestructura sea segura y multiusuario recae en el administrador IT, y este tipo de Arquitecturas a día de hoy son fundamentales en medianas o grandes empresas porque nos dan una mejora en escabilidad, a nivel económico y de seguridad en los datos que una arquitectura con tenant único no nos daba. Fundamental en un entorno Cloud hoy en día.

Os dejo un esquema que lo define bien:

La entrada ¿Qué es una Arquitectura Multi-tenant? se publicó primero en VMware Citrix Blog.

Install Docker Netscaler CPX

Hoy os queremos enseñar a instalar Netscaler CPX sobre una máquina virtual VMware Centos 7 mediante un sistema de Dockers. Para enseñaros como hacerlo utilizaré VMware Workstation y una máquina virtual linux Centos 7 con red en modo Bridge. Así que nos ponemos manos a la obra, y lanzamos el comando para instalar Docker:

yum –y install docker

Ahora habilitamos el servicio:

systemctl enable docker.service

Ahora podemos reiniciar el sistema. Al arrancar veremos que se ha generado un nuevo interface:

Podemos gestionar los servicios lanzando los siguientes comandos:

systemctl start docker.service ## Arranca docker ##
systemctl stop docker.service ##  Para docker ##
systemctl restart docker.service ## Reinicia docker ##
systemctl status docker.service ## Ver estado docker ##

Descargamos la imagen de Netscaler CPX. Se pueden ver las instrucciones en la web de Docker Store:

El comando sería en este momento:

[root@localhost ~]# docker pull store/citrix/netscalercpx:12.0-56.20

Trying to pull repository docker.io/store/citrix/netscalercpx ...

12.0-56.20: Pulling from docker.io/store/citrix/netscalercpx

6ce531b1ca45: Pull complete

38e4a6bc2d04: Pull complete

7cbb621499da: Pull complete

a2921fd6218f: Pull complete

2b4e7c8adb0a: Pull complete

980882099ccc: Pull complete

81e3dc3dd27c: Pull complete

17dabbe4b8a9: Pull complete

0e3da0d4fd64: Pull complete

f2e7b4c3e799: Pull complete

c3469b674821: Pull complete

9af9916546cf: Pull complete

1aeb683ace83: Pull complete

4e3ae7b95fc5: Pull complete

Digest: sha256:d88b72e227efdccdf2e7a553a4207038f34825ce08ce7c9cbf5664ad5c1cf23a

Status: Downloaded newer image for docker.io/store/citrix/netscalercpx:12.0-56.20

[root@localhost ~]# docker images

REPOSITORY                            TAG                 IMAGE ID            CREATED             SIZE

docker.io/store/citrix/netscalercpx   12.0-56.20          8528cafdfa33        6 months ago        375 MB

docker run -dt -P --privileged=true –net=host –e NS_NETMODE=”HOST” -e CPX_CORES= --name  --ulimit core=-1 -e CPX_NW_DEV='' -e CPX_CONFIG=’{“YIELD”:”NO”}’ -e LS_IP= -e LS_PORT= e PLATFORM=CP1000 -v :/cpx :

[root@localhost ~]# docker run -e EULA=yes -dt -P --ulimit core=-1 --cap-add=NET_ADMIN store/citrix/netscalercpx:12.0-56.20

9fafe15a2025db7a75e2e2efe6d5da32152736e3bfa52a372bc18e148763e555

• dt: Ejecutar el docker en background
• P: Abre los puertos por defecto para Netscaler CPX
  • 80 se utiliza para HTTP
  • 443 se usa para HTTPS
  • 22 utilizado para SSH
  • 161 / UDP se usa para SNMP
• p: Para cada puerto individual (Ejemplo: -p 22 -p 443 -p 161/udp)
• ulimit: No limitamos las opciones
• cap-add: Añadimos capacidades linux

MAS INFORMACION: https://docs.citrix.com/en-us/netscaler-cpx/12/deploy-using-docker-image-file.html

Comprobamos que se ha generado. Fijaros en los puertos que asigna a los puertos por defecto en el docker que son los que utilizaréis para conectaros. Ejemplo, 32770 para el 80:

[root@localhost ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9fafe15a2025 store/citrix/netscalercpx:12.0-56.20 "/var/netscaler/bi..." About a minute ago Up About a minute 443/tcp, 0.0.0.0:32771->22/tcp, 0.0.0.0:32770->80/tcp, 0.0.0.0:32769->161/udp ecstatic_swirles

Una vez que lo tenemos generado, ahora tenemos que averiguar la IP. Para ello utilizaremos el IP del CONTAINER o DOCKER:

[root@localhost ~]# docker inspect 9fafe15a2025

Deberéis aseguraros que existe regla de firewall:

iptables -L

Chain DOCKER (1 references)
target prot opt source destination
ACCEPT udp -- anywhere 172.17.0.2 udp dpt:snmp
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:http
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:ssh

Si no queréis problemas sería mejor habilitar las iptables (y deshabilitar Selinux, salvo que os manejéis) ya que sino los dockers os darán errores aunque os dejo como hacer un disabled:

[root@localhost ~]# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)

ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t filter -C DOCKER ! -i docker0 -o docker0 -p udp -d 172.17.0.2 --dport...at chain?).
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -C POSTROUTING -p udp -s 172.17.0.2 -d 172.17.0.2 --dport 161 -j ... that name.
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -C DOCKER -p tcp -d 0/0 --dport 32774 -j DNAT --to-destination 17... that name.
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t filter -C DOCKER ! -i docker0 -o docker0 -p tcp -d 172.17.0.2 --dport...at chain?).
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -C POSTROUTING -p tcp -s 172.17.0.2 -d 172.17.0.2 --dport 80 -j M... that name.
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -C DOCKER -p tcp -d 0/0 --dport 32775 -j DNAT --to-destination 17... that name.
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t filter -C DOCKER ! -i docker0 -o docker0 -p tcp -d 172.17.0.2 --dport...at chain?).
ago 01 23:12:43 localhost.localdomain firewalld[723]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -C POSTROUTING -p tcp -s 172.17.0.2 -d 172.17.0.2 --dport 22 -j M... that name.
ago 01 23:16:17 localhost.localdomain systemd[1]: Stopping firewalld - dynamic firewall daemon...
ago 01 23:16:17 localhost.localdomain systemd[1]: Stopped firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.

Con todo esto abrimos un navegador y vamos a la url:

https://IP_DOCKER:PORT_ASIGNADO

La imagen es sobre la propia máquina virtual, por eso voy al puerto 80. Si lo hacemos sobre el host que lanza la máquina virtual iríamos a http://IP_MAQUINA_VIRTUAL:32770 en mi caso es el puerto que me ha asignado al generar el docker para el puerto 80:

La contraseña para SSH es root / linux

Podéis comprobar que se basa en debian fácilmente:

root@8d694a324986:~# cat /etc/debian_version
stretch/sid

root@8d694a324986:~# cli_script.sh "add server test1 192.1.1.1"
exec: add server test1 192.1.1.1
Done

root@8d694a324986:~# cli_script.sh "show ns config"
exec: show ns config
        NetScaler IP: 172.17.0.2  (mask: 255.255.0.0)
        Number of MappedIP(s): 0
        Node: Standalone
        NetScaler IP Vlan: 1 Tagged: NO Bound Ports:
                           System Time: Thu Aug  2 00:52:08 2018
              Last Config Changed Time: Thu Aug  2 00:47:12 2018
        Config Changed since Last Saved Config: TRUE
Done

La entrada Install Docker Netscaler CPX se publicó primero en VMware Citrix Blog.

Citrix Health Assistant – Chequear VDA

Cuando montas una infraestructura nueva de Citrix XenApp / XenServer, instalas un componente esencial en las máquinas que van a compartir escritorios o aplicaciones que es la VDA. Este componente, muchas veces nos viene ya heredado en algunos clientes y tenemos que analizarlo porque el cliente realmente tiene problemas.

Para hacer un análisis de una VDA problemática o simplemente como “best practices” cuando realizas la instalación desde cero de una nueva infraestructura, os presentamos una herramienta muy útil que seguramente guardaréis entre las favoritas, Citrix Health Assistant.

La podéis descargar desde el siguiente enlace con vuestra cuenta Citrix. Como podéis observar en la imagen es para versiones 7.X y no para versiones anteriores.

https://support.citrix.com/article/CTX207624?download

No es necesaria su instalación, más bien es un ejecutable que se lanza en una máquina y que abre un asistente que te da acceso a lanzar chequeos en local o remotamente. Algo muy útil y simple.

Os dejo los requisitos para que funcione:

Prerequisites Citrix Health Assistant

• Windows 7 or newer with .Net 3.5.1 or higher installed
• Citrix XenDesktop or XenApp 7.0 VDA or newer
• To check a remote VDA:
  • Windows Remote Management (WinRM) is enabled on the remote VDA to be checked
  • A domain user account with local admin privilege on the remote VDA is required

Os explico la ejecución en local y luego la remota. Simplemente descomprimís el ZIP descargado. Y lanzaréis CitrixHealthAssistant.exe:

Siempre como Administrador:

Se abre la aplicación:

Y elegimos localmente si estamos ya en la VDA:

En cuestión de segundos nos revisará el estado y si tenemos alguna carencia que hay que corregir para que no nos de problemas:

Para hacerlo remotamente, simplemente usaremos el nombre FQDN y un usuario / contraseña con permisos de conexión:

Como veréis puede pasar que os falte algún KB o GPOs y la herramienta lo detecta:

Si queréis ver la secuencia completa, podéis revisar el LOG que deja:

Herramienta súper interesante y creo que necesaria para ahorraros disgustos.

La entrada Citrix Health Assistant – Chequear VDA se publicó primero en VMware Citrix Blog.

VMware Fusion – Error Proceso Peer Valido

En mi vuelta a MacOS he instalado VMware Fusion, y me he encontrado con un error que me ha impedido lanzar la instalación de un Windows 10 que pensaba generar.

El error dice algo así “No se puede encontrar un proceso peer válido con el que conectar” y se produce al arrancar la máquina virtual.

La seguridad de MacOS nos están jugando una mala pasada y nos bloquea la ejecución. Así que vamos a autorizarlo. Simplemente vamos a Ajustes –> Seguridad y privacidad :

Veremos un mensaje en la pestaña General. Pulsamos Permitir:

Una vez lo permitamos, ya arrancará nuestra máquina virtual sobre VMware Fusion:

La entrada VMware Fusion – Error Proceso Peer Valido se publicó primero en VMware Citrix Blog.

Primera configuración Cisco Meraki

Aprovechando que puedo refrescar algún conocimiento sobre Cisco Meraki y la certificación CMNA, voy a daros unas pinceladas de como se configuran los equipos Meraki cuando son comprados.

Lo primero que pasa, es que llega un correo con un número de orden de todo el pedido. Vamos, que da igual la cantidad de equipos que compremos de una vez, utilizaremos un sólo número para darlos de alta todos a la vez. Y esto es lo que queremos enseñaros en esta entrada.

El sistema de gestión es totalmente en la nube. Algo que tiene sus ventajas (muchísimas a mi entender como la gestión centralizada de equipos totalmente independientes, seguridad, simplicidad,…), y alguna que otra desventaja, como pueden ser las primeras configuraciones, que son intuitivas pero hay que hacer varias para estar “suelto”, la necesidad de disponer de Internet para realizar configuraciones o cambios,…y poco más, porque una vez montado, es muy interesante y se te hace difícil ver la gestión de otros switchs, APs,…como algo simple.

Lo primero que hay que hacer, es disponer de una cuenta desde el siguiente enlace:

https://meraki.cisco.com/

Pulsamos sobre Register Meraki devices:

Acordaros que nos estamos conectando a un Cloud, y es imprescindible que los equipos dispongan de acceso a Internet. Os dejo los puertos necesarios:

Una vez disponen los equipos de acceso a Internet habilitado. Lo primero es crear el nombre de tu red. Lo normal es que tiendas a colocar el nombre de tu localización o sede (es normal), pero no tiene por qué estar relacionado. Así que damos un nombre de red, y pulsamos Add devices:

Introducimos el número de orden que nos ha pasado Cisco y pulsamos Add devices:

Automáticamente aparecerán todos nuestros equipos comprados y pulsaremos Create network:

Según los equipos adquiridos, aparecerán más o menos menús en el panel izquierdo. Con esto ya tenemos enlazados los equipos Cisco Meraki a nuestra cuenta:

La entrada Primera configuración Cisco Meraki se publicó primero en VMware Citrix Blog.

Política Citrix Local Time

El otro día veíamos como utilizar Citrix Health Assistant y vimos un error en mi LAB relacionado con el KB de Citrix CTX126099

Hoy os queremos enseñar como resolver este error a través de configuraciones de políticas que una vez aplicadas ya no será un problema:

Lo primero que haremos será generar una política desde Citrix Studio. Vamos a Policies –> Create Policy:

Filtramos por Time Zone Control y pulsamos Select en ambas opciones una a una:

Para Estimate local time for legacy clients, marcamos Enabled:

Para Use local time of client:

Pulsamos en Select user and machine objects –> User or group:

Pulsamos Edit –> Browse:

Escribimos Domain Users:

Le damos un nombre a la política y pulsamos Finish:

Hasta aquí hemos resuelto Citrix Group Policy Settings. Para resolver Microsoft Group Policy Settings vamos a generar una GPO de Microsoft en Directorio Activo:

Simplemente generaremos  la siguiente GPO:

User Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Destop Session Host > Device and Resource Redirection > Allow time zone redirection > Enabled

Actualizamos las políticas con un gpupdate /force:

Si lanzamos otra vez la validación veremos que los checks están ya marcados como OK y podemos dar por resuelto el problema:

La entrada Política Citrix Local Time se publicó primero en VMware Citrix Blog.

Upgrade Firmware Merakis

Hoy quiero enseñaros como podéis hacer una actualización de todos vuestros equipos Cisco Meraki desde el panel de gestión. Es un procedimiento bastante sencillo.

Lo primero que hay que hacer es ir al menú Organization –> Firmware upgrades

Desde la pestaña Overview podréis ver las versiones estables, real candidate o betas a las que podéis acceder:

Pulsamos All networks –> Marcamos el equipo que queremos actualizar –> Schedule upgrade:

Pulsamos Next:

Ahora podéis programar la actualización o hacerlo en el momento:

Pulsamos Schedule change:

Veremos la programación:

Y desde Scheduled changes el tiempo que queda:

Podréis modificar la programación si aún no se ha lanzado:

O cancelar la programación:

La entrada Upgrade Firmware Merakis se publicó primero en VMware Citrix Blog.

Popup Logon Citrix Inicio Sesion en Windows

He estado estos días haciendo pruebas con Autocad sobre Citrix XenApp y para ello he montado un nuevo laboratorio sobre VDA Windows Server 2016. Mis clientes son Windows 10 Profesional.

La cosa es, que después de montarlo todo, en el arranque del logon de las diferentes aplicaciones, se lanza un par de pantallas un poco molestas que dicen algo así como “Inicio Sesion en Windows” y Windows + G. Seguro que las conocéis si habéis llegado a este post.

Así que os explico como eliminarlas de una manera rápida, así que lanzamos la aplicación y os enseño las pantallas de las que hablo:

Estas son las dos pantallas que nos encontraremos:

Para eliminarlas del logon, que lo hacen más lento, simplemente vamos a pasar tres claves de registro, que si no existen las generáis:

• Para eliminar la pantalla de “Inicio de sesion en Windows”:
  • HKEY_Local_Machine\SOFTWARE\Wow6432Node\Citrix\ (Es probable que tengáis que generar la clave LOGON y la DWORD DisableStatus en vuestra VDA)
    • Crear key Logon
    • Crear DWORD “DisableStatus” con el valor a 1

• Otra clave a insertar sería:
  • HKEY_CURRENT_USER\System\GameConfigStore\
    • Creamos con valor DWORD “GameDVR_Enabled” to 0

• Adicionalmente:
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
    • Creamos key “GameDVR”
    • Creamos DWORD 32bit “AllowGameDVR” y valor 0

Hay que reiniciar la VDA para completar el proceso correctamente.

La entrada Popup Logon Citrix Inicio Sesion en Windows se publicó primero en VMware Citrix Blog.

Configuración vGPU en VMware 6 para Citrix XenApp

Hoy os quiero mostrar como configurar sobre una infraestructura VMware Vsphere 6 una tarjeta gráfica física sobre una máquina virtual. En este caso, se trata de una prueba de concepto de aplicaciones CAD sobre Citrix XenApp 7.15 LTSR. Con lo que le daremos todo el poder de la tarjeta gráfica a una VDA con Windows Server 2016 en la que tendremos preinstalado Autocad Revit y Civil entre otros.

Instalación driver NVIDIA GRID K2 VMware ESXi

Descargamos el driver.

https://docs.vmware.com/en/VMware-Horizon-7/7.1/com.vmware.horizon-view.linuxdesktops.doc/GUID-AA333E98-0AA4-419B-8676-8B2C6F89CAF7.html

Nos conectamos vía SSH  al ESXi (habilitado previamente). Cargamos el fichero VIB en un volumen para que lo tengamos accesible:

Y lanzamos los siguientes comandos. Paramos el servicio xorg:

/etc/init.d/xorg stop

Ponemos el servidor en mantenimiento:

esxcli system maintenanceMode set --enable true

Instalamos el fichero VIB. Hay que poner la ruta completa al PATH, no la relativa:

esxcli software vib install -v /path-to-vib/NVIDIA-VIB-name.vib

[root@local:/vmfs/volumes/5aedbd53-5f82026f-1c58-2c768a50b4d4/ISOS/DRIVER NVIDIA K2] esxcli software vib install -v /vmfs/volumes/5aedbd53-5f82026f-1c582c768a50b4d4/ISOS/DRIVER\ NVIDIA\ K2/NVIDIA-kepler-VMware_ESXi_6.5_Host_Driver_367.92-1OEM.650.0.0.4598673.vib

Installation Result

   Message: Operation finished successfully.

   Reboot Required: false

   VIBs Installed: NVIDIA_bootbank_NVIDIA-kepler-VMware_ESXi_6.5_Host_Driver_367.92-1OEM.650.0.0.4598673

   VIBs Removed:

   VIBs Skipped:

Sacamos de mantenimiento:

esxcli system maintenanceMode set --enable false

Reiniciamos el ESXi.

reboot

Cuando arranque comprobamos que el servicio xorg está arrancado:

[root@local:~] /etc/init.d/xorg status

Xorg is not running

Si no está arrancado como en el ejemplo lo arrancamos:

/etc/init.d/xorg start

Configuración NVIDIA GRID K2 en máquina virtual VMware

Este ejemplo está basado en una tarjeta NVIDIA K2.

Apagamos la máquina virtual donde vamos a colocar la tarjeta física NVIDIA:

Editamos la configuración:

Pulsamos Seleccionar para añadir un nuevo dispositivo y seleccionamos Dispositivo PCI compartido:

Pulsamos Agregar:

Seleccionamos la tarjeta, el perfil y pulsamos Reservar toda la memoria para garantizarnos que se va a reservar la memoria para esta máquina virtual:

Automáticamente se marcará la reserva de memoria y pulsamos Aceptar:

Arrancamos la máquina virtual:

Al tratarse de un elemento hardware hay que tratarlo como lo haríamos en nuestro ordenador personal. Le instalaremos el Driver correspondiente para este caso. Podéis bajarlo desde la web oficial de NVDIA:

https://www.nvidia.com/download/driverResults.aspx/104534/en-us

Para subirlo al esxi, simplemente he generado una ISO con Rufus, y la he subido al almacenamiento.

Se la mapeo a la máquina virtual:

Y realizamos una instalación del driver desde el SETUP:

Si vais al Administrador de dispositivos antes de instalar el driver se ha tenido que detectar:

Una vez instalado el driver y reiniciado ya aparecerá configurada:

Optimizaciones aplicaciones Autocad en Citrix XenApp

Después de realizar estas configuraciones, Autodesk Revit se nos quejan porque no hay aceleración Hardware, esto se debe a que la tarjeta NVIDIA GRID K2 que estoy usando no es compatible:

A continuación, quizá tengáis que restablecer el ajustador de rendimiento en AutoCAD del siguiente modo:

1. Hay que cerrar todos los programas de Autodesk que se estén ejecutando.
2. Pulsáis WINDOWS-R en el teclado para abrir la ventana Ejecutar (o haga clic en el menú Inicio > Ejecutar), escriba REGEDIT y haga clic en Aceptar.
3. En el Editor del Registro, busque y seleccione la siguiente ubicación del Registro:

HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\Rxx.x\ACAD-xxxx:40x\3DGS Configuration

Esta ruta es única en cada versión de AutoCAD, por lo que si tenéis varios Autodesk instalados en la misma VDA os encontraréis varias rutas.

4. Haga doble clic en la entrada FirstRun y cambie su valor a 0 (cero).

Adicionalmente preparemos el driver NVDIA para que trabaje optimizado con aplicaciones CAD. Así que abrimos el NVIDIA DESKTOP MANAGER:

Pulsamos Cargar:

Pulsamos Aceptar:

En la propia aplicación de Autocad se pueden modificar parámetros en la barra inferior derecha, en el icono de la esfera. Esto es jugar con las mejores características para el uso que le vais a dar:

Aquí yo he subido la caché, a falta de más pruebas:

Comprobaciones GPU para Autocad en Citrix XenApp VDA

Para revisar si realmente trabaja bien nuestra tarjeta gráfica en nuestra infraestructura Citrix podemos utilizar FURMARK para lanzar un Test de nuestra GPU. Así que descargáis el ejecutable y lanzáis la aplicación:

https://geeks3d.com/furmark/

Modificáis la Resolución a por ejemplo 1920×1080 y lanzáis el test. Se abrirá una pantalla de prueba y veréis el comportamiento de la GPU:

Podéis comprobar con una tool de la herramienta las características de la GPU:

Problema NVIDIA GRID 2 perfil GPU en blanco

Como anotación, por si os encontráis en VMware con este problema os dejo mis pruebas. Al instalar la tarjeta el Perfil de GPU salía en blanco al instalarle la PCI a la máquina virtual:

Puede deberse a dos problemas hasta lo que he visto:

• Instalación incorrecta del driver
• O parámetro en BIOS inhabilitado

Desinstalación driver NVIDIA GRID K2 en VMware ESXi

Os explico como desinstalar el driver de vuestro esxi si os da problemas:

[root@local:~] /etc/init.d/xorg stop

Listamos los drivers instalados:

[root@local:~] esxcli software vib list | grep NVIDIA

NVIDIA-kepler-VMware_ESXi_6.5_Host_Driver  367.92-1OEM.650.0.0.4598673            NVIDIA     VMwareAccepted    2018-08-28

Eliminar el driver:

[root@local:~] esxcli software vib remove -n NVIDIA-kepler-VMware_ESXi_6.5_Host_Driver

Removal Result

   Message: Operation finished successfully.

   Reboot Required: false

   VIBs Installed:

   VIBs Removed: NVIDIA_bootbank_NVIDIA-kepler-VMware_ESXi_6.5_Host_Driver_367.92-1OEM.650.0.0.4598673

   VIBs Skipped:

Desinstalar módulo NVIDIA:

vmkload_mod -u nvidia

Espero os ayude…

La entrada Configuración vGPU en VMware 6 para Citrix XenApp se publicó primero en VMware Citrix Blog.

Error Plesk: 0.0.0.0:80 failed (98: Address already in use)

Después de toda actualización “gorda” de Plesk me llevo una sorpresa, normalmente no muy agradable. En este caso ha sido un cambio de versión que me ha dejado las webs fuera de servicio.

La gestión de plesk no ha dado ningún problema, de hecho el procedimiento es muy sencillo, pero como digo, mi servidor Centos daba errores por todos lados.

Lo primero que suelo hacer, porque siempre van por ahí los tiros, es comprobar los servicios MYSQL y NGINX.

[root@servidor-1 ~]# systemctl status mysql.service
● mariadb.service - MariaDB 10.1.35 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Fri 2018-09-01 06:48:03 UTC; 4min 27s ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 1159 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 796 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR=|| VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environmen t _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 784 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Main PID: 845 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─845 /usr/sbin/mysqld

Aug 31 06:48:02 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:02 14065...
Aug 31 06:48:02 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:02 14065...
Aug 31 06:48:02 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:02 14065...
Aug 31 06:48:02 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:02 14065...
Aug 31 06:48:03 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:03 14065...
Aug 31 06:48:03 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:03 14065...
Aug 31 06:48:03 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:03 14065...
Aug 31 06:48:03 servidor-1.localdomain mysqld[845]: 2018-08-31 6:48:03 14065...
Aug 31 06:48:03 servidor-1.localdomain mysqld[845]: Version: '10.1.35-MariaDB...
Aug 31 06:48:03 servidor-1.localdomain systemd[1]: Started MariaDB 10.1.35 da...
Hint: Some lines were ellipsized, use -l to show in full.

Y como no podía ser de otra forma, es NGINX el que me da el error. Ya comento que casi siempre es el problema. Quizás por mi integración con Varnish+Apache+Nginx+Mysql:

[root@servidor-1 ~]# systemctl status nginx.service
● nginx.service - Startup script for nginx service
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2018-08-31 06:52:40 UTC; 24s ago
Process: 1522 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
Process: 1519 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 1517 ExecStartPre=/usr/bin/test $NGINX_ENABLED = yes (code=exited, status=0/SUCCESS)

Aug 31 06:52:39 servidor-1.localdomain nginx[1522]: nginx: [emerg] bind() to 188.xxx.xxx.xxx:80 failed (98: Address already in use)
Aug 31 06:52:39 servidor-1.localdomain nginx[1522]: nginx: [emerg] bind() to 149.xxx.xxx.xxx:80 failed (98: Address already in use)
Aug 31 06:52:39 servidor-1.localdomain nginx[1522]: nginx: [emerg] bind() to 188.xxx.xxx.xxx:80 failed (98: Address already in use)
Aug 31 06:52:40 servidor-1.localdomain nginx[1522]: nginx: [emerg] bind() to 149.xxx.xxx.xxx:80 failed (98: Address already in use)
Aug 31 06:52:40 servidor-1.localdomain nginx[1522]: nginx: [emerg] bind() to 188.xxx.xxx.xxx:80 failed (98: Address already in use)
Aug 31 06:52:40 servidor-1.localdomain nginx[1522]: nginx: [emerg] still could not bind()
Aug 31 06:52:40 servidor-1.localdomain systemd[1]: nginx.service: control process exited, code=exited status=1
Aug 31 06:52:40 servidor-1.localdomain systemd[1]: Failed to start Startup script for nginx service.
Aug 31 06:52:40 servidor-1.localdomain systemd[1]: Unit nginx.service entered failed state.
Aug 31 06:52:40 servidor-1.localdomain systemd[1]: nginx.service failed.

Parece que algo está utilizando el puerto 80 y 443 que NGINX debería utilizar. Así que reviso qué puede ser:

[root@servidor-1 ~]# netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program n ame
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1071/master
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 822/named
tcp 0 0 127.0.0.1:12346 0.0.0.0:* LISTEN 1071/master
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 5353/sw-cp-se rver:
tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 985/dovecot
tcp 0 0 127.0.0.1:12768 0.0.0.0:* LISTEN 783/psa-pc-re mote
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 985/dovecot
tcp 0 0 127.0.0.1:6082 0.0.0.0:* LISTEN 922/varnishd
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 985/dovecot
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 985/dovecot
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 985/dovecot
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13404/varnish d
tcp 0 0 0.0.0.0:8880 0.0.0.0:* LISTEN 5353/sw-cp-se rver:
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 1071/master
tcp 0 0 188.xxx.xxx.xxx:53 0.0.0.0:* LISTEN 822/named
tcp 0 0 149.xxx.xxx.xxx:53 0.0.0.0:* LISTEN 822/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 822/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 992/sshd
tcp6 0 0 :::25 :::* LISTEN 1071/master
tcp6 0 0 :::8443 :::* LISTEN 5353/sw-cp-se rver:
tcp6 0 0 :::4190 :::* LISTEN 985/dovecot
tcp6 0 0 :::993 :::* LISTEN 985/dovecot
tcp6 0 0 :::995 :::* LISTEN 985/dovecot
tcp6 0 0 :::7081 :::* LISTEN 17505/httpd
tcp6 0 0 :::3306 :::* LISTEN 845/mysqld
tcp6 0 0 :::106 :::* LISTEN 792/xinetd
tcp6 0 0 :::110 :::* LISTEN 985/dovecot
tcp6 0 0 :::143 :::* LISTEN 985/dovecot
tcp6 0 0 :::8080 :::* LISTEN 17505/httpd
tcp6 0 0 :::80 :::* LISTEN 13404/varnish d
tcp6 0 0 :::8880 :::* LISTEN 5353/sw-cp-se rver:
tcp6 0 0 :::465 :::* LISTEN 1071/master
tcp6 0 0 :::53 :::* LISTEN 822/named
tcp6 0 0 :::21 :::* LISTEN 792/xinetd
tcp6 0 0 :::22 :::* LISTEN 992/sshd
udp 0 0 188.xxx.xxx.xxx:53 0.0.0.0:* 822/named
udp 0 0 149.xxx.xxx.xxx:53 0.0.0.0:* 822/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 822/named
udp 0 0 0.0.0.0:68 0.0.0.0:* 689/dhclient
udp6 0 0 :::53 :::* 822/named

Matamos los procesos que interfieren con NGINX, en este caso VARNISH

[root@servidor-1 ~]# fuser -kivn tcp 80
USER PID ACCESS COMMAND
80/tcp: varnish 18837 F.... varnishd
Kill process 18837 ? (y/N) y

Y arrancamos los servicios nuevamente, esta vez sin problemas:

[root@servidor-1 ~]# service nginx start
Starting nginx (via systemctl): [ OK ]

[root@servidor-1 ~]# service varnish start
Redirecting to /bin/systemctl start varnish.service

[root@servidor-1 ~]# service httpd start
Redirecting to /bin/systemctl start httpd.service

Espero que os sirva como a mi esta solución.

La entrada Error Plesk: 0.0.0.0:80 failed (98: Address already in use) se publicó primero en VMware Citrix Blog.