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"

Solventar los problemas de la Security Update de Julio de 2019

Es posible que tras la actualización de Julio de 2019 (Monthly rollup) sobre equipos Windows 7 o Server 2008 R2 sp1 arrancando con UEFI, nos encontremos con que los equipos no arrancan mostrando un fallo del tipo "Info: An error has occurred while attempting to read the boot configuration data.", o bien "Windows cannot verify the digital signature for this file" provocando que el equipo no arranque y solo permita llegar a la pantalla de reparación.

Esto es debido a un error en los parches desplegados por Microsoft. Lo gracioso es que la actualización KB4512506 que causa el problema se lanzó el 13 de Agosto de 2019, y la solución está en la KB4512514, preview para la siguiente actualización, lanzada el 17 de Agosto. De manera que en vez de modificarse la monthly rollup, te puedes encontrar con que tus maquinas actualizadas a partir de las actualizaciones de seguridad mensuales, no arranquen, así que cuidadito con las updates del verano.

Si el problema que se muestra es que efectivamente tu equipo, con arranque UEFI arranca automáticamente a la ventana de recuperación del equipo, la solución consiste en reemplazar los ficheros winload.efi, winload.exe, winresume.efi y winresume.exe. Vamos a ello:

• Desde la consola de recuperacion, vamos a la ruta donde tengas tu instalacion de Windows. Si es C:\, la ruta es c:\windows\winsxs\C:\windows\winsxs\
• Entramos en la carpeta "amd64_microsoft-windows-b..vironment-os-loader_31bf3856ad364e35_6.1.7601.24499_none_b984965a9ca0bb23" sin comillas, todo seguido, sin espacios. Dentro de esta carpeta, veremos 4 archivos.
• Escribimos "md c:\w" Cambiar la C por la unidad en la que se encuentre tu instalacion. Este comando creará un directorio con el nombre "w" en la raiz de c.
• Escribimos copy . c:\w . Deberia mostrar "4 archivos copiados"
• Seguidamente vamos a system32 con cd \windows\system32
• Escribimos copy c:\w\*.* . Esto reemplazará los anteriores archivos. Puedes hacer previamente una copia de ellos
• Salimos de la consola, y reiniciamos. 

Solo hay que seguir los pasos de la imagen superior. El equipo debería arrancar sin problemas.

Ah, un pequeño detalle: La carpeta donde se encuentran los 4 archivos corresponde a la copia de los mismos de Junio. Por tanto, se crearan en esa ruta distintos "backups" con lso que podemos afinar la restauracion a lo largo del tiempo, o en caso de no encontrar exactamente la ruta indicada más arriba.

Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco.

Para ponernos en situacion sobre la causa y resolucion del aviso "Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco", os comento este ejemplo desde el inicio.

Vamos a instalar un Appliance cualquiera, en este caso, Zabbix, donde indican la descarga en un formato aparentemente válido, VMDK.

Me salto los pasos de descargar el archivo, descomprimir, crear la carpeta de la VM, subir los archivos al datastore y registrar la VM. Hasta aqui, todo perfecto. Es cuando arrancas la Vm cuando te encuentras con el error antes mencionado.

Basicamente, este error viene provocado por una incompatibilidad del archivo VMDK, no tanto por el formato, si es thin, thick, lazy zero, o cualquier otro formato, sino por la compatibilidad del VMDK con el producto de VMware que lo soporta. Me explico: muchas veces, estos archivos se generan pensando en las versiones más simples del producto, y por ello su formato es VMware Fusion, Player o Workstation. El producto ESXi es otra historia, y en este caso, es donde lo hemos subido, y donde la máquina falla a la hora de inicializarse.

Siempre que tratemos con appliances en este formato, la forma más simple de solventar este problema es realizar una conversion de formato a la vez que subimos el appliance a nuestro datastore. Para ello, utilizaremos VMware Converter.

Abrimos la aplicacion y pulsamos sobre Convert Machine.

Tenemos solo los archivos del appliance, no necesitamos poner la maquina en funcionamiento. Solo indicamos en las opciones, "Powered off", y marcamos el archivo de nuestro appliance.

Este paso es importante: indicamos que el destination type es VMware Infrastructure virtual Machine, no un vmware workstation o similar. Ponemos los datos para la conexión con nuestro vCenter (importante, el vCenter, no el ESXi).

Indicamos el nombre de la VM, y la ubicacion que debe tener, y next. Iniciará el despliegue de la VM. Tras esto, podreis arrancarla sin los problemas anteriores.

Después de todo esto, que en el fondo es un "workaround" en caso de encontrarte con este fallo, la moraleja es: si puedes, descarga el appliance en formato OVF (Open Virtualization Format), que no te dará tanta guerra y es fácilmente importable desde la consola de vCenter.

Habilitar copy-paste para la consola de VMware

Usualmente me conecto a las VM´s via Escritorio Remoto de Windows, pero hay que reconocer que la consola de VMware es cómoda para trabajar, sobre todo en primeras configuraciones, cuando todavia no está bien habilitada la red, por poner un ejemplo. Aunque se echa en falta la simple posibilidad de utilizar el portapapeles. El poder, en tu equipo, copiar por ejemplo un password complicado que debes introducir en la nueva maquina para lo que sea, o peor aún, debes ejecutar un script de cientos de lineas, y no tienes forma de pasarlo, con lo facil que sería con un coypaste.

Copypaste es una opción que originalmente existia en VMware, pero en la version 4.1 se deshabilitó, por problemas de seguridad. Por suerte, es facil habilitarlo, sólo tenemos que seguir los siguientes pasos:

• Verificar que tenemos las VMware Tools instaladas. Si no es asi, ¡tienes un problema serio! ¡Son vitales! Instalalas sin falta.
• Apagamos la VM, y vamos a la pestaña "summary". Ahí pulsamos sobre Edit settings.

• Seguidamente, vamos a la pestaña "VM Options", en las opciones de la izquierda expandimos "Advanced", y pulsamos sobre "Edit Configuration"

• Nos aparecerán los parámetros de configuración de la VM.Abajo, veremos la opción "add row". Tenemos que añadir los siguientes parámetros:

"isolation.tools.copy.disable", sin las comillas, y en valor, "FALSE", y otra linea mas con "isolation.tools.paste.disable" con valor "FALSE" igualmente, tal y como se ve en la imagen superior.

• Pulsamos Ok, vamos cerrando los cuadros de dialogo, y ya está. SOlo queda arrancar de nuevo la VM.

Esta opción sólo modifica la VM sobre la que lo has hecho, pero puede ser que quieras activar estas opciones para toda tu granja de servidores. En ese caso, tendrás que modificar las opciones en el host ESX. Para ello, nos conectamos al ESXi como root, hacemos backup del fichero /etc/vmware/config antes de modificarlo, y seguidamente, lo editamos, añadiendo estas entradas al archivo:

vmx.fullpath = "/bin/vmx"
isolation.tools.copy.disable="FALSE"
isolation.tools.paste.disable="FALSE"

Tras esto, guardamos y cerramos el archivo.
Por cierto, la activación no es inmediata, se habilitarán cuando las VM´s se reinicien (o apagando y encendiendo, claro). Ten en cuenta también que si actualizas el host, habrá que volver a realizar los cambios.