Ejecutar EMCgrab en ESXi

ESXi es un fantástico producto, pero como todo, requiere chequeos para revisar su estado de salud, especialmente si hay algún caso abierto con EMC, donde te pedirán los informes EMCgrab.

EMCgrab es una pequeña herramienta por linea de comandos que se puede ejecutar prácticamente desde cualquier plataforma. Puedes descargarla para Windows desde ESTE enlace, aunque para acceder necesitas cuenta de usuario en EMC. Tambien puedes descargarlos de ftp.emc.com/pub/emcgrab/ESXi y ftp.emc.com/pub/emcgrab/ESX. El primero es para servidores ESXi, que son de 5.0 en adelante, y el segundo, para ESX.

El sistema es muy simple: el paquete descargado se descomprime. Dentro de la carpeta, verás un archivo "emcgrab.exe". Hay que ejecutarlo desde linea de comandos. El formato de ejecución es el siguiente:

Collect data connecting to ESXi server with ESXiGrab only
emcgrab.exe -host <esx host> -user <esx user> -password <esx password>
Collect data connecting to ESXi server with ESXiGrab only no prompting
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -autoexec -legal 

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password>

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with mixed non-XtremIO and XtremeIO storage
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -mixed_storage 

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with XMS connectivity
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -xms_name <xms server> -xms_user <xms user> -xms_password <xms password>

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with mixed non-XtremIO and XtremeIO storage and with XMS connectivity
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -xms_name <xms server> -xms_user <xms user> -xms_password <xms password> -mixed_storage

El siguiente comando ademas agrega el log bundle en el fichero generado de salida:

emcgrab.exe -host 172.19.4.56 -user <user>-password <password> -vmsupport -outDir <directorio de salida del fichero> -quiet

Si necesitas obtener el resultado en varios ESXi a la vez, puedes utilizar el siguiente script:

$user = 'root'

$pswd = 'XXXX'

Get-Content -Path hostnames.txt | %{

    emcgrab.exe -host $_ -user $user -password $pswd -vmsupport -party XXX -customer XXX -case XXX -contact XXX -phone XXXX -email XXXX

}

En el fichero .txt, un host por linea, sin espacios en blanco.

Solventar error en VDP: Operation failed due to existing snapshot

Un error que pasa con poca frecuencia, pero tarde o temprano aparece en VDP consiste en el fallo del backup avisando de la existencia de que hay un snapshot previo. Miras el Snapshot Manager, y  compruebas que no hay snapshots, y que no se puede consolidar la VM. Pero el error persiste:

¿Cómo puede ser que esté detectando un snapshot, si ya has verificado que no hay ninguno lanzado de forma manual, y a lo mejor incluso en VDP estás configurando la tarea por primera vez? Vale, configurando el backup por primera vez es imposible que pase, pero a lo mejor la máquina ha sido movida o copiada, o bien previamente tuvo respaldo de otro VDP, que son causas probables para el error.

Básicamente, lo que suele suceder es que algún archivo delta se queda enganchado en la VM, impidiendo su eliminacion y por tanto, su borrado y posibles backups posteriores. Veamos un ejemplo. Tenemos una VM con un solo disco.

Pero vamos al navegador de ficheros, y nos encontramos con esto:

Vemosque hay multitud de archivos delta que no deberían estar. Es mas, ni siquiera se utilizan, estan "perdidos", por decirlo de algun modo. De forma que podemos eliminarlos con la tranquilidad de que no vamos a perder datos por ello. En el caso de la imagen superior, eliminaremos todos los archivos que vemos ahora marcados, apagando previamente la VM.

Tras esto, podemos arrancar la VM, que funcionará sin problemas.

Como se ve en la imagen, también elimino, ademas de los archivos delta, los archivos de log y los .ctk. Es importante eliminar los archivos ctk, ya que contienen una lista de cambios producidos en la VM tras el último backup. Basicamente, contienen la informacion de los bloques de informacion que han cambiado, en vez de contener la informacion completa del disco. Solo debería haber un archivo ctk en la VM.

Cómo conectar a Exchange Online con PowerShell

Ya sabemos que Microsoft quiere que administremos todo con PowerShell, y eso incluye sus servicios on-line. Y aunque el interfaz gráfico es muy cómodo, puntualmente se presentan tareas que es recomendable realizar via PowerShell, en lugar de pelearnos con los distintos menús de los sistemas de Azure.

En este caso, vamos a ver cómo realizar la conexión a Exchange Online PowerShell, ya que hay que realizar alguna configuración previa. Lo primero de todo, abrimos PowerShell como administradores.

Ejecutamos el comando  "Set-ExecutionPolicy RemoteSigned" para solicitar que lo que se descargue de Internet sea de confianza (esto vale con realizarlo solo una vez), y le pasamos nuestras credenciales con "$UserCredential = Get-Credential" (el nombre completo de cuenta, con el @xxx.com).

A continuación, realizaremos la conexión. Para ello, hay que tener primero en cuenta el requisito de proxy. Para ello, pasamos el siguiente comando primero, si vamos pro proxy. Si no, saltatelo:

$ProxyOptions = New-PSSessionOption -ProxyAccessType <Value> 

donde el valor "value" debe ser IEConfig, WinHttpConfig o AutoDetect, según lo que corresponda (siempre se puede cambiar el valor a posteriori, si te has equivocado al pasarlo.

Después pasamos el comando de conexion a Office365:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Si configuraste proxy, al final del comando debes agregar "-SessionOption $ProxyOptions" (sin comillas), quedando esto: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection -SessionOption $ProxyOptions

Ya solo queda por pasar el comando "Import-PSSession $Session -DisableNameChecking", sin comillas.

Dos últimos detalles:

- Al finalizar, ejecutar el siguiente comando para cerrar sesión: Remove-PSSession $Session

- Puede suceder que estés trabajando en un entorno híbrido. En ese caso, necesitas instalar un archivo desde tu centro de administracion de Exchange Online, en el apartado "híbrido".

Seleccionas la opción que corresponda, y autorizas la descarga. Para la implementación híbrida, el paquete que descarga es Microsoft.Online.CSE.Hybrid.Client.application.

Si da problemas, lanza la descarga desde Internet Explorer (todavía andamos así, Microsoft?).
Con esto, deberia ser posible realizar consultas y modificaciones de cuentas, asi como migraciones de un entorno a otro desde linea de comandos.

Para agregar el complemento de PowerShell, que puede ser lo que falte para determinados comandos, hay que instalar el módulo PowerShell:

Similar a la instalación del módulo híbrido, pero en vez de pedir la ejecución de una aplicación, ejecuta una ventana de PowerShell con las instrucciones de conexión:

Para verificar que la conexion ha sido realizada correctamente, basta con ejecutar en PowerShell el comando get-mailbox.
Para cualquier duda adicional, tenéis el enlace de Microsoft de ayuda en este ENLACE.

Añadir listado de usuarios a grupo de Directorio Activo

Un va pequeño script (muy pequeño, realmente, apenas son 4 lineas) para agregar un listado de usuarios a un grupo de directorio activo.

Normalmente, con un simple copypaste de un excel al cuadro para agregar miembros al grupo valdria, pero cuando la cantidad de usuarios es masiva, la copia de miles de celdas no le sienta muy bien a la consola de AD, asi que mejor, con esta ejecucion de powershell:

Import-module ActiveDirectory $Fichero = Import-CSV "c:\ListadoUsuarios.csv" 
$Fichero.UserPrincipalName | ForEach-Object {        Add-ADGroupMember -Identity "nombredelgrupo" -Members $_
}

Solo eso. Desde Powershell ISE  pegamos estas lineas, que hacen lo siguiente:
En linea 1, importamos el modulo para trabajar con AD
Linea 2, Indicamos la ubicacion y nombre del fichero .csv con los usuarios.
Lineas 3 y 4, van agregando a los usuarios, uno por linea de excel.

Importante: El fichero .csv debe comenzar en la linea 1 con "UserPrincipalName", quedando asi:

No hay mas. Se puede hacer más complicado, se puede poner recuento de usuarios, pero, la verdad, en las pruebas hechas, no falla, asi que, ¿para qué complicarlo?

No se puede migrar una cuenta desde o365 a Exchange: Cannot find a recipient that has mailbox GUID

Cuando tratamos de migrar una cuenta de o365 a exchange en un entorno híbrido, esto es, donde tenemos Office365 y también un Exchange On-premise trabajando conjuntamente en el mismo entorno AD, obtenemos este error:

Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ‎'xxxxxxxx-xxx-xxx-xxxx-xxxxxxxxxxxx‎'. --] Cannot find a recipient that has mailbox GUID ‎'xxxxxxxx-xxx-xxx-xxxx-xxxxxxxxxxxx‎'.
 

Básicamente, esto sucede cuando el valor del GUID del buzón no está sincronizado en el buzón asociado en la organización local. El valor del buzón se almacena en la propiedad ExchangeGUID (también conocida como el atributo msExchMailboxGUID ) del usuario propietario del buzon. Para verlo, tenemos que ir al editor de atributos de la ficha de usuario.

Por suerte, la solución es simple: sólo hay que establecer el correcto valor GUID en el buzón remoto local asociado previamente a la migración del buzón. 

Para ello, nos vamos al shell de exchange del servidor local y ejecutamos el siguiente valor:

Get-RemoteMailbox usuario@midominio.com | Format-List ExchangeGUID

Puede pasar también que el GUID sea todo ceros, lo que significa que el valor directamente no se estampa en el buzón remoto local:

A continuación, nos vamos a Powershell. El comando a introducir para ver el GUID de la cuenta es muy parecido:

Get-Mailbox usuario@midominio.es| Format-List ExchangeGUID

Los valores, como veis, son distintos. En local teníamos un GUID terminado en 7cc6 (suponiendo que no os dé todo ceros) mientras que en Exchange Online termina, en este caso, en 7bbd.

Entonces, lo que vamos a hacer es establecer el GUID del entorno online, que es el que queremos migrar en este caso a local, en el entorno local. Para ello, volvemos al shell de Exchange local, e introducimos el siguiente comando:

Set-RemoteMailbox usuario@midominio.es -ExchangeGUID 8204ee3b-d483-45bd-97e6-e10d1a7b7bbd

Donde, si os fijáis, estamos poniendo el GUID que nos ha dado powershell, correspondiente a la cuenta online

Ya para terminar, podemos volver a realizar un get-remotemailbox, para asegurarnos que el cambio se ha aplicado

Una vez realizado esto, se puede volver a ejecutar desde Exchange online el proceso de migracion sin mayores problemas.

NOTA: Ten en cuenta que Exchange Online suele tener unos límites de almacenamiento bastante elevados para cuentas tipo E1 en adelante, y es posible que en local las database de almacenamiento de cuentas puedan estar limitadas, de manera que hay que tener cuidado de migrar a una database sin limite, o con un limite de tamaño de buzón inferior al consumido en o365.

Cómo solventar el error 400 "bad name request" en Outlook Web Access

Trabajando con Exchange 2010 -2013 puede ocurrir que cuando se accede al mail via owa y accedes a las opciones del correo (arriba a la derecha), al pulsar “ver todas las opciones” para, por ejemplo, activar el automatic reply, sale la pantalla de selección de zona horaria y lenguaje:

Tras pulsar ok, da un mensaje de error 400, bad request.

Esto es debido a que el usuario no tiene definido un valor de zona horaria en el buzón de Exchange server 2010

Desde el servidor de Exchange, abrimos la consola, y podemos ver el valor configurado para la cuenta de usuario con Get-MailboxRegionalConfiguration -Identity “username” , sin comillas

En este caso, no se marca el campo lenguaje, lo que está ocasionando los problemas. Aplicamos la time zone y el lenguaje con el siguiente comando:

Set-MailboxRegionalConfiguration -Identity “nombredelbuzon” -Language "es-ES" -TimeZone "Romance Standard Time"

Una vez cambiado, volver a introducir el comando inicial, Get-MailboxRegionalConfiguration -Identity “username”, para verificar que se muestran los datos sin errores.

Si todavía tenias el buzon de owa abierto, haz logoff, logon de nuevo, y deberá estar funcionando sin problemas las opciones avanzadas.

Unable to reload module from vSphere: Solución

A partir de la version 6 de vCenter y, hasta donde llega mi conocimiento, la version 6.5 y sus distintas updates, puedes seguir accediendo al vCenter via plugin flash, con el enlace "https://<vcenter>/vsphere-client/?csp"

Y es posible que te encuentres con este mensaje:

Este mensaje aparece cuando se presenta una incompatibilidad de un modulo del vCenter con el idioma utilizado, en este caso, y  como se ve en la captura, el español.

La solución más lógica es dejar de utilizar el acceso web con plugin y empezar a utilizar la versión html5, aunque a veces sea complicado, no estando del todo fina hasta el update de vCenter a 6.7, o bien porque ya son muchos años los que hemos estado con la misma interfaz web con flash, y cuesta el cambio. Pero merece la pena probarlo, es solo un tema de estética, y hay que empezar a manejar la nueva interfaz. Para ello, entramos al vCenter con "https://<vcenter>/vsphere-client/ui"

Otro modo de entrar y operar sin el error consiste en deshabilitar el módulo problemático.
Entramos en el vCenter con la cuenta administrator@vsphere.local, vamos a los client plugins, y deshabilitamos le plugin del fallo.

La última manera de eliminar el fallo es cambiar el idioma por defecto del navegador, y acceder al vcenter indicando el idioma que queremos utilizar para evitar el error de carga de plugin en español. la dirección de acceso es https://<vcenter>/vsphere-client/?locale=en_US" . Con esto, le indicamos que queremos entrar con la configuración en inglés. Si quieres forzar la configuracion en español, cambias el "en_US" por "es_ES"