Windows Update/SCCM falla con error 8007000E

Esta fue bastante vergonzosa…

Después de estar buscando por media hora por que fallaba con el error 8007000E el escaneo de parches en un servidor, me di cuenta de que estaba introduciendo mal el código del error en Google y estaba poniendo 80007000E en vez de 8007000E.

En fin, cosas que pasan cuando tienes una semana muy larga.

Si te aparece este error cuando estás instalando instalar parches revisa el consumo de memoria de tu equipo. En mi caso era un servidor con un 1GB de memoria que fallaba cada vez que intentaba hacer el escaneo. Amplié la memoria a 2GB y santo remedio 🙂

Referencia

Convertir NDR IMCEAEX a dirección X500

Si alguna vez has borrado por error o has restaurado un buzón/contacto/grupo de Exchange a un usuario diferente del original, probablemente has recibido quejas de los usuarios diciendo que cada vez que envían un correo al usuario en cuestión reciben un NDR de Exchange con un mensaje parecido al siguiente:

captura ndr

El motivo de esto es que Outlook almacena los usuarios de Exchange como contactos X500 en la caché de Autocompletar (¿Por qué? No se, pero viene de muy atrás). Para solucionar esto la KB2807779 nos dice que podemos limpiar la cache de Autocompletar de Outlook o agregar un contacto X500 al usuario de Exchange. El problema es que no hay forma sencilla de aplicar la primera opción de forma automatizada a muchos usuarios a la vez, así que normalmente solo nos queda la segunda.

Para aplicar la segunda solución debemos abrir las propiedades de un buzón/contacto/grupo en Exchange, ir a la pestaña de direcciones de correo y agregar una dirección personalizada X500. ¿Qué ponemos como dirección? Tenemos que copiar la dirección que nos devuelve en el mensaje de error de NDR y reemplazar ciertos caracteres tal y como nos explica esta entrada.

Como soy vago, muy vago. Hice una pequeña funcion en PowerShell para no tener que hacer este reemplazo manualmente. Aquí os la dejo.

function Convert-IMCEAEX ($address) {
$address = $address.Replace("+20"," ")
$address = $address.Replace("+28","(")
$address = $address.Replace("+29",")")
$address = $address.Replace("+2E",".")
$address = $address.Replace("_","/")
$address = $address.Replace("IMCEAEX-","")

$lastIndex = $address.LastIndexOf("@")
if ($lastIndex -gt 0) {
$address = $address.Substring(0, $lastIndex)
}

return $address
}

Creo que está bastante claro lo que hace. Simplemente le pasamos la dirección “sucia” y esta nos la limpia.

Exportar listado de dispositivos con ActiveSync y su cuenta asociada

Aquí os dejo un script para saber qué dispositivos tenemos sincronizados con nuestra organización. Es muy recomendable ejecutarlo cada cierto tiempo para hacer limpieza de dispositivos que hace tiempo que no se conectan, que pertenecen a usuarios que ya se han ido de la empresa, o simplemente tener una idea de quienes tienen sincronizado su correo con dispositivos móviles.

Esta pensado para Exchange 2010, pero debería funcionar en otras versiones también.

Descargar

Crear Directorio Personal/Carpeta Particular (Home Directory) con Powershell

Seguimos migrando el servidor de ficheros…

Esta vez toca mover los directorios personales (carpeta particular en AD) de todos los usuarios al nuevo servidor.

Ir usuario a usuario cambiando este directorio es muy tedioso, por lo que una vez más vamos a usar PowerShell para terminar mas rápido.

Lo primero que tenemos que hacer es crear los directorios en el nuevo servidor para después mover los datos. Una de las cosas que hay que tener cuenta al mover estos directorios personales de cada usuario es que solo ese usuario (y los administradores del servidor) deben tener acceso a estos. Cuando este directorio se asigna desde la interfaz de administración de Active Directory esta se encarga de asignar los permisos requeridos, pero cuando lo haces directamente desde el servidor de ficheros los permisos se deben cambiar manualmente.

Afortunadamente, los de Scripting Guy de Microsoft crearon una serie de posts donde explican como hacer esto a través de PowerShell, el problema es que el código que está en la parte 3 de la serie, que debería hacer todas estas tareas, tiene varios bugs.

Desde aquí te puedes decargar ese código corregido y convertido en una funcion (Create-HomeDirectory). Recuerda cambiar los valores de HomeDrive, UserRoot y Domain por los valores que correspondan para tu entorno.

Para usar la función solo tienes que ejecutar Create-HomeDirectory NombreUsuario.

Una vez que esten creados todos los directorios con los permisos correspondientes en el nuevo servidor solo queda mover los datos con Cortar y Pegar, Robocopy o cualquier otra herramienta.

A Active Directory no le importa si tu nombre es Jose o José

Hoy fue uno de esos días que se viven una vez cada 10 años, ¡Hoy el usuario tuvo la razón!

Ya lo se, parece increíble, pero es la verdad.

Tenemos una aplicación que coge los atributos de un usuario del Active Directory y después los usa para conectarse a diferentes servicios. Esta funciona perfectamente para todos los usuarios excepto para José. Cuando José se intenta conectar a uno de los servicios estos siempre dan un error de autenticación (usuario o contraseña erroneos) y fallan.

Después de estar varios días mirando logs finalmente dimos con el problema… La aplicación se intenta autenticar utilizando el usuario Josñ. ¡Un aplauso para los desarrolladores que no soportan Unicode!

El usuario nos comentaba que él podía hacer que la aplicación funcionase si utilizaba el usuario Jose en vez de José y, por supuesto, nosotros no le creímos. ¿Como va a ser lo mismo conectarse con un usuario que con otro? ¿Tendría dos usuarios en el Active Directory?

Para nuestra sorpresa, no había otro usuario y la aplicación si que funcionaba al iniciar sesión con el usuario Jose. Lo curioso es que cuando revisabamos los logs aparecía que el usuario que se conectaba era José.

Después de investigar un rato conseguimos el siguiente artículo de Microsoft que confirmaba lo que decía el usuario. Cuando te intentas conectar al Active Directory con un usuario que tiene acentos o simbolos diacríticos en el nombre (sAMAccountName) se hace una conversión a “símbolos simples” para facilitar el inicio de sesión con interfaces que no soportan estos caracteres. Bien de parte de Microsoft, muy mal de parte de los desarrolladores.

Así que ahí está… Todos los días se aprende algo nuevo.

Autodiscover con dominio SMTP compartido

Paciencia y foco, este post es un poco denso 😀

Fusiones, adquisiciones o simple colaboración entre empresas de una misma corporación… Si eres administrador del servicio de correo de tu empresa (por vocación o por enmarronamiento) y has vivido alguno de los momentos que menciono antes, seguramente te ha tocado pasar por una situación llamada “Split SMTP domain” o “Shared SMTP address space”.

Un dominio SMTP compartido, como su nombre lo indica, es un mismo dominio SMTP que es compartido por varias organizaciones o sistemas de correo. Esto quiere decir que, por ejemplo, para el dominio midominio.com, puede haber buzones de correo en los servidores de la organización Alfa o en los servidores de la organización Beta.

Cuando una persona envía desde internet un correo a empleado@midominio.com, este es recibido por los servidores de la organización Alfa, si este buzón se encuentra en sus servidores el correo se entrega localmente, de lo contrario es reenviado a la organización Beta. Fácil, ¿No?

El problema, como siempre, está en los detalles. Desde hace varias versiones de Exchange, Lync y Outlook existe algo llamado Autodiscover, que no es más que un mecanismo para encontrar información de autoconfiguración de dispositivos, disponibilidad de personas y localización de servidores sin necesidad de introducir manualmente los parametros de estos servidores. Tener el Autodiscover funcionando de forma correcta es bastante complicado, requiere configuración de los servidores de CAS, certificados de confianza, cambios en el DNS, publicación de SCP en AD, una pata de conejo y extracto de mandragora, entre otras cosas.

Con un poco de esfuerzo, se puede configurar el Autodiscover para que funcione correctamente en una organización de Exchange. Pero, ¿Qué pasa si tengo un dominio SMTP compartido? No hay problema, en Exchange se puede utilizar el atributo ExternalEmailAddress (llamado targetAddress en el AD). Este atributo nos indica, en el caso de Autodiscover, a que dominio debemos recurrir para buscar los parametros de configuración de un buzón.

Por ejemplo, en la organización Alfa tengo los dominios alfa.com y omega.com y en la organización Beta tengo los dominios beta.com y omega.com. Cuando intento configurar mi Outlook a través de Autodiscover para el buzón boli@omega.com primero me conecto a autodiscover.omega.com, que está alojado en la organización Alfa, el Exchange de esta organizacón ve que el usuario boli@omega.com tiene un ExternalEmailAddress de boli@beta.com, y redirige el cliente de Outlook a autodiscover.beta.com. Outlook se conecta a autodiscover.beta.com y obtiene todos los parámetros necesarios para configurar correctamente este buzón. MAGIA

Si todo fuese tan fácil no estaría escribiendo esta entrada…

¿Qué pasa si no tengo relación de confianza entre los dominios de AD de ambas organizaciones? En este caso Autodiscover no va a funcionar para los usuarios de una de las dos organizaciones. ¿Por qué? La razón es muy sencilla, cuando te conectas con el usuario boli@omega.com a autodiscover.omega.com este primer servidor que está en la organización Alfa te pide que te autentiques con usuario y contraseña. ¿Pero como me autentico si mi usuario no existe en la organizacion Alfa? EXACTO, no puedes, por lo que Autodiscover no va a funcionar para ti. Y con esto vendran popups constantes en Lync y Outlook. Si tienes Lync 2013 puedes evitar estos popups con este hack, pero si tienes Lync 2010 no puedes hacer nada.

Así que ya sabes, si te piden que compartas un dominio SMTP entre varias organizaciones de Exchange, trata, en la medida de lo posible, de tener una relación de confianza entre las mismas. De lo contrario puedes tener problemas tanto con el Lync como con Outlook.