Exchange 2010: Configuración de autodiscover

Tanto si vamos a usar Outlook Anywhere, como si queremos distribuir la OAB vía web o si queremos que las cuentas de Outlook se configuren solas debemos configurar el servicio de autodiscover en Exchange 2010.
En primer lugar para poder realizar esta configuración necesitamos tener un certificado válido con multiples SAN (Subject Alternate Names) e instalado en el Exchange. Sin este certificado sólo los equipos del dominio podrán descargar la OAB el resto recibirán un error 0x8004010f.

Se trata de una configuración sencilla de 4 pasos:

1. El registro DNS

Debemos crear un registro de tipo A en nuestro dns en la zona del dominio de la dirección principal de correo del usuario. Si nuestro usuario es usuario1@gersonrodrigo.es habría que crear un registro A en la zona gersonrodrigo.es llamado autodiscover y que apunte a la IP del servidor CAS.

Creación de ámbito DHCP por linea de comandos

Hoy vamos a crear ámbitos DHCP por línea de comandos. Para ello vamos a realizar un pequeño script que usará el comando netsh.

Crearemos un ámbito sencillo con las opciones típicas: a nivel de ámbito la puerta de enlace y a nivel de servidor los servidores de nombres y el nombre del dominio.

Necesitaremos crear un fichero de texto auxiliar llamado Datosambitos.txt con el siguiente formato:

Ambito, Descripcion,IP Subred,Mascara,router,IP inicio,IP fin
Servidores, sede principal,10.0.1.0,255.255.255.0,10.0.1.1,10.0.1.10,10.0.1.200

Y ahora creamos un script con el siguiente contenido (recordad cambiar las variables en negrita por las de vuestro entorno y ponerle extensión bat o cmd):

Control de sesiones de Terminal Server por línea de comandos

Aunque los sistemas operativos de microsoft son plenamente visuales no por ello carecen de una poderosa línea de comandos. Hoy vamos a ver cómo consultar las sesiones de terminal server en curso y cómo podremos cerrarlas mediante comandos.


El comando está en C:\WINDOWS\system32 en windows 2003 (está en el path) pero en Windows XP el comando está en C:\WINDOWS\system32\dllcache por lo que desde fuera del directorio no funcionará.

Para ver las sesiones remotas en un servidor escribimos:

Automatización de filtros en FSRM

En muchas ocasiones los usuarios se empeñan en llenar los discos de la compañía (que no son precisamente baratos) con ficheros de películas y música. Para impedir que esto suceda podemos usar el componente FSRM de Windows.

Vamos a crear un filtro para impedir la grabación de este tipo de ficheros con ayuda de FSRM (File Serve Resource Manager). Dado que es posible que haya que realizar más de un tipo de filtrado, lo haremos a través de la linea de comandos:

Para ello crearemos 3 objetos:

1. Un grupo de ficheros que contendrá ficheros de video.
2. Una plantilla que usará ese grupo de ficheros para aplicarse
3. Un filtro que aplicará esa plantilla en la ubicación deseada.

Un Robocopy rico rico y con fundamento

Hoy vamos a preparar cual Karlos Arguiñano, un Robocopy rico rico y con fundamento.
Para proporcionar los distintos matices aderezaremos con las siguientes especias::

1. /MON:15 /MOT:1 Que quede en memoria una vez finalizado y copie a los 15 minutos todos los cambios.
2. /XO :Que en caso de cortarlo y relanzarlo no copie los ficheros que no han sido modificados desde la última copia.
3. /TEE /LOG+:C:\log-robocopy7.log :Que guarde un log incremental y que además lo muestre por pantalla.
4. /E : copia subdirectorios aunque estén vacios.
5. /ZB : Usa copia normal y si no puedes usa tipo ntbackup (con éste último basta con ser operador de copia aunque no se tengan permisos).
6. /R:1 /W:1 :Segundos para reintento 1, número de reintentos 1

Así finalmente nuestro Robocopy queda tal que así.

El caso del controlador que se olvidó de su dominio

 Hoy vamos a ver un caso que me ocurrió en un cliente y que me dió unos cuantos dolores de cabeza: El cliente se quejaba de que no podía añadir un controlador adicional 2008 a su dominio 2003 ya que una vez extendido el esquema e uniciado el dcpromo en la última parte del asistente le aparecía la siguiente advertencia:

 Los síntomas:

Migración simple a Office 365

En este caso el cliente ha decidido migrar a Office 365. El punto de partida es un Exchange 2010 SP1. El objetivo final es tener todos los correos de la empresa el nube.
Se desestima el inicio de sesión único dado que implica tener servidores de Federación y Proxies de Federción en local, lo que además implica la imposibilidad de logarse si caen las comunicaciones de la oficina central.
Se desestima una migración híbrida con espacio de nombres compartido, se realizará una migración tipo Big Bang.
Cuando se aborda un proyecto de este tipo, uno de los pasos que siempre se sugieren es la sincronización con el directorio activo local para poder replicar la GAL. En este caso, partiendo de un Exchange 2010 SP1 No hay que realizar este paso dado que la migración fallará.

En este artículo no nos centraremos en otras configuraciones de Office 365 como la comprobación del dominio, simplemente abordaremos la migración de buzones de Exchange.