Category Archives: Exchange 2003

Glue invita: Disaster recovery y Troubleshotting en Exchange 2003

Buenas prácticas de cómo realizar respaldos de Exchange 2003 y cámo tener un plan de Recuperación ante Desastres adecuado según la Arquitectura de Exchange. Veremos: Base de datos, firma, t. logs, checkpoint, utilidades para manejar base de datos, cómo darse cuenta cual es el T.log que necesita la base, Recovery SG, Cache Buffers y proceso de Mount de la base.
Lugar: Central Tech. Av. Corrientes 531 Piso Buenos Aires.
Oradores: Pablo Vernocchi y Pablo Eiroa.
Nivel: Intermedio.
Conocimientos: Infraestructura.

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032322555&Culture=es-AR

Saludos,
Vernocchi, Pablo

Migrando desde MDaemon a Exchange

Mdaemon es un servidor de correo electrónico para Windows que provee una solución de mensajería para empresas pequeñas y medianas.

En muchas ocasiones me ha tocado migrar de MDaemon a Exchange y mantener la coexistencia entre ambos servidores por un tiempo. Dado que muchas personas pueden estar en esta misma situación, he decidido escribir unas líneas con los pasos que siempre seguí para poder realizarlo.

NOTA: Esta nota supone que tanto MDaemon como Exchange ya están instalados y configurados correctamente, también supone que el dominio smtp es vernocchi.com.ar. La versión de MDaemon utilizada fue la última al momento de escribir esta nota (9.5.4). Los cuadros de diálogo pueden variar entre versiones, pero el procedimiento no.

Como primer paso debemos configurar un alias para el dominio vernocchi.com.ar en MDaemon. Para ello, vamos a Accounts –> Address Aliases o presionamos F3:

Una vez allí creamos un alias para la dirección ip del servidor MDaemon, en este caso 10.42.57.201 que apunte a nuestro dominio smtp:

Como siguiente paso tomaremos el primer usuario en usar Exchange y le configuraremos un reenvío de correos. Para ello vamos a Accounts –> Account Manager o presionamos Alt+M.

Seleccionamos la cuenta y hacemos clic en Edit.

Vamos a la solapa Forwarding, seleccionamos “This account is currently forwarding mail”. En el campo de direcciones ingresamos el Alias del buzón en Exchange (Atencion!: no poner la dirección smtp) y, en el campo “Forward the message to this domain” ponemos el nombre del servidor de correo Exchange o su dirección IP.

Listo! Todos los correos que lleguen a esa cuenta serán reenviados automáticamente al servidor Exchange. Pero… cuando ese usuario conteste un correo a un usuario que ya exista en AD, Exchange entenderá que el correo es local, y lo va a almacenar en el buzón del usuario y nunca va a llegar al MDaemon. Solucionar eso es simple:

Creamos un contacto para los usuarios que tengan su casilla en MDaemon y les reenviamos el mail. Para eso:

Para crear un contacto en AD, nos paramos sobre la OU que querramos, hacemos clic con el botón secundario, nuevo –> Contacto.
Llenamos la informació correspondiente:

A su vez le configuramos un buzón y en E-mail hacemos clic en Modify y seleccionamos SMTP:

Acá ingresamos la dirección de correo pero, en vez de ponerle @vernocchi.com.ar le ingresamos el Alias que creamos previamente en MDaemon (@10.42.57.1).

Debería quedar así:

Ya tenemos el contacto, ahora tenemos que configurar el reenvío. Para ello entramos en las propiedades del usuario, solapa Opciones generales de Exchange, botón “Delivery Options”. Ahí seleccionamos la opción “Forward to:”, hacemos clic en “Modify” y buscamos el contacto que creamos previamente:

Una vez configurado todo, veremos en la pantalla de MDaemon como el tráfico de correos fluye sin problemas:

Es un proceso simple y espero que les sirva para la migración.

Saludos,
Vernocchi, Pablo

Reinicio lento en servidores Exchange 2000/2003 instalado en Domain Controllers

Una falla muy conocida en Exchange 2003, instalado en Domain Controllers, es su lento apagado. Resulta que el problema es causado porque los servicios de Active Directory se detienen antes que los de Exchange. Como todos ya sabemos, Exchange se apoya fuertemente en nuestra estructura de AD, y avisa a AD cuando se va a detener. En ese momento, Exchange no puede contactarse con AD y es por eso que demora bastante en apagarse, ya que se detienen por TimeOut.

Existen varios procedimientos para solucionarlo que van desde modificar la registry hasta correr scripts antes del apagado, aunque la verdadera solución y recomendación es no instalar Exchange en Domain Controllers.

Vamos a ver todas las alternativas.

1) Cambios en la registry:

Existe una clave en la registry ubicada en: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control llamada WaitToKillServiceTimeout. Este parámetro indica el tiempo en milisegundos que el sistema operativo esperará que un servicio se dentenga antes de “matarlo”.

Lo recomendado es configurar ese valor en 120000. Esta solución no es la más recomendable ya que detiene abruptamente los servicios y puede causar corrupción en las bases de datos.

USUARIOS DE SBS2003: esta clave ya viene configurada por defecto, y a veces su valor es demasiado bajo, lo que puede causar que las bases de Exchange se corrompan. Microsoft lanzó un Workaround.

Services may stop abruptly when you shut down or restart a Windows Small Business Server 2003-based computer
http://support.microsoft.com/default.aspx?scid=kb;en-us;839262

—————————————————–

2) Scripts al shutdown:

La mejor manera de atacar este problema es deteniendo los servicios de Exchange antes del proceso de shutdown del servidor. Acá tenemos tres opciones:

————————–

 2.1) Lee Derbyshire escribió un archivo .bat que muestra un menú antes de apagar. Es un proceso manual antes de apagar el servidor, y su contenido es:

@ECHO OFF
ECHO.
ECHO Please select…
ECHO.
ECHO R – Reboot
ECHO S – Shut Down
ECHO A – Abort Shutdown
ECHO Q – Quit
ECHO.

CHOICE /C RSAQ

IF ERRORLEVEL 4 GOTO END
IF ERRORLEVEL 3 GOTO ABORT
IF ERRORLEVEL 2 GOTO SHUTDOWN
IF ERRORLEVEL 1 GOTO REBOOT
IF ERRORLEVEL 0 GOTO END
GOTO END

:ABORT
shutdown /a
GOTO END

:REBOOT
SET PARAM=/r
GOTO STOPSERVICES

:SHUTDOWN
SET PARAM=/s
GOTO STOPSERVICES

:STOPSERVICES
ECHO ON
net stop MSExchangeES /y
net stop MSExchangeIS /y
net stop MSExchangeMTA /y
net stop MSExchangeSA /y
net stop WinHttpAutoProxySvc /y
shutdown %PARAM% /t 10 /c “TO ABORT, RE-RUN BATCH FILE AND PRESS A”

:END

Lo que muestra una ventana así:

————————–

 2.2) La siguiente opción que tenemos es adjuntar un .bat a una policy de shutdown del servidor. Esta opción es más compleja, pero mucho más segura.

Como primer paso debemos escribir un archivo de texto con el siguiente contenido:

net stop MSExchangeES /y
net stop MSExchangeIS /y
net stop MSExchangeMTA /y
net stop MSExchangeSA /y
net stop WinHttpAutoProxySvc /y

Luego lo renombramos con extensión .bat y armamos la policy.

 Para ello vamos a incio –> ejecutar –> gpedit.msc y luego presionamos aceptar.
 Expandimos Computer Configuration –> Windows Settings –> Scripts (Startup/Shutdown) y hacemos doble clic en Shutdown:

 Hacemos clic en el botón add:

 Escribimos la ruta en donde guardamos el archivo bat:

 Y quedará así:

 

Aceptamos la ventana y ya quedará configurada. 

————————–

 2.3) La última opción es adjuntando un VBScript a una policy de shutdown del servidor. El efecto y resultado es el mismo que en la anterior opción:

Como primer paso debemos escribir un archivo de texto con el siguiente contenido:

servername = “localhost”
 set wmi = getobject(“winmgmts://” & servername)
 StopService (“Microsoft Exchange System Attendant”)
 StopService (“IIS Admin Service”)
 StopService (“Netlogon”)

Sub StopService (ServiceName)
         wql = “select state from win32_service ” _
               & “where displayname='”& ServiceName & “‘”
         set results = wmi.execquery(wql)
         for each service in results
            if service.state = “Running” then
             service.stopService
            end if
          next
End Sub

Luego lo renombramos con extensión .vbs y armamos la policy de la misma manera que la anterior, pero cambiando el nombre del archivo por el vbs que creamos recientemente.

 

Saludos,
Vernocchi Pablo

Cómo redirigir el acceso Web en OWA

En esta oportunidad veremos como redirigir los accesos al OWA para que los usuarios sólo tengan que acceder al servidor web ingresando http://nombredeservidor/, sin la necesidad de agregar el /Exchange al final.
De esta manera, facilitaremos mucho el acceso pudiendo, por ejemplo, crear un registro en el DNS para que se acceda via http://webmail.dominio.com/

Redirigir automáticamente las peticiones a /Exchange

Luego de hacer estas configuraciones, los usuarios podrán acceder al Webmail sin la necesidad de tipear /exchange en el browser:

1. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools.
2. Expandir Web Sites
3. Hacer clic con el botón secundario del Mouse sobre el Default Web Site y seleccionar Propierties.
4. Seleccionar la solapa “Home Directory”.
a. Seleccionar “A redirection to a URL”
b. En el campo “Redirect to” escribir /Exchange
c. Tildar “A directory below URL entered” 

Reenviar peticiones http a https: 

Luego de configurar los siguientes pasos, IIS automáticamente redirigirá las peticiones http a https, con lo cual los usuarios no deberán ingrear https:// en la barra de direcciones. Previamente debemos haber instalado un certificado para SSL y configurado en los directorios virtuales de Exchange.

1. Crear una carptea en c:\inetpub\wwwroot llamada owaasp
2. Descargar el archivo owahttps.zip y descomprimirlo en la carpeta previamente creada
3. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools
4. Expandir sites, expandir Default Web Site.
5. Sobre el directorio virtual Exchange hacer clic con el botón secundario del Mouse y seleccionar Propierties.
6. Ir a la solapa Custom Errors
7. Buscar de la lista 403;4 y seleccionar Edit
8. En Message Type Seleccionar URL, escribir /owaasp/owahttps.asp, y aceptar todas las ventanas.


9. Ubicar el directorio OWAASP dentro del Default Website

10. Hacer clic con el botón secundario del Mouse y seleccionar Propierties.
11. En la sección Application Settings hacer clic en Create y luego seleccionar ExchangeApplicationPool en el campo “Application Pool”.

Espero que les haya sido útil,

Saludos,
Vernocchi Pablo

Seguridad en mensajes (Parte 3)

Ya tenemos todo configurado. Entendemos las diferencias entre las distintas posibilidades dentro de la seguridad ofrecida por estándares y aplicadas en Exchange.

Hemos logrado firmar un mensaje digitalmente y asegurarnos que el contenido no fue modificado en tránsito pero… ¿qué pasa si alguien más está husmeando las conexiones?

Acá les pego una porción de una conexión smtp con un mensaje sin cifrar:

Y acá tenemos los resultados de una comunicación estándar entre un servidor Exchange y un servidor de un tercero:

Si juntamos todos los pedazos de conexión obtenemos:

Así es, ese texto lo puede leer cualquiera que se interponga entre nuestro servidor y el servidor de destino. Pero, para todas los problemas tenemos una solucón.

En esta oportunidad, veremos como proteger la confidencialidad de un correo, evitando que cualquiera lo pueda leer, y veremos su resultado.

El primer intento de cifrar un mensaje, puede no ser tan exitoso:

Y justamente se debe a que el usuario de destino no tiene un certificado, por lo tanto no tenemos acceso a sus claves para cifrarlo. Sin mucho más, se le otorga un certificado a ese usuario y con eso se resuelve el inconveniente.

Para esta demo, iniciamos sesión con el usuario Jorge, e intentamos enviar un mail cifrado a Pablo:

También veremos en la pantalla un ícono diferente, pero esta vez azul, informando que el correo está encriptado:

Como medida de seguridad, ese mensaje no es accesible via “Vista previa”, solamente se puede leer al abrirlo:

Y, al abrirlo, nos encontramos con un batallón de íconos y candados:

Al hacer clic sobre el ícono azul, que indica encripción, podemos ver los detalles del certificado, aí como también el nivel de encripción utilizado:

Y ahora, la prueba final. Sniffeando una conexión SMTP enviando un correo encriptado, obtenemos los siguientes resultados:

Cumplimos nuestra meta, ahora el mensaje se transmite de manera tal que no se puede interpretar a simple vista.

Saludos,
Vernocchi Pablo

Seguridad en mensajes (Parte 2)

Se larga la segunda parte de este artículo!

En esta oportunidad vamos a ver cómo configurar las firmas digitales en los correos electrónicos, para agregar Integridad a la información transportada y, además, brindar Autenticación en el mensaje ya que esa firma sólamente nos pertenece a nosotros.

Paso a paso. Lo primero que vamos a necesitar para implementar S/MIME es un certificado. Podemos utilizar la infraestructura de Certificados que provee Microsoft o adquirir los certificados através de terceros como Verising (pago) o CACert.org (grauito), entre otros. Si optamos por la de Microsoft (gratuita, parte de Windows Server) necesitaremos instalarla. Para ello he redactado una pqueñísima guia disponible en http://www.eseutil.net/como-instalar-una-ca-certificate-authority-en-windows-2003

***NOTA***

Este artículo utiliza la CA provista por Microsoft

******

Bien, como primer paso obtendremos un certificado digital para nuestra cuenta de usuario. Para ello abrimos el navegador y vamos a la URL de nuestra CA interna, iniciando sesión con nuestro usuario y contraseña:

En las tareas disponibles, seleccionamos “Request a Certificate”:

Como tipo de certificado, seleccionamos “User Certificate” y hacemos clic en submit:

Saldrá una advertencia de seguridad, diciéndonos que el sitio web está intentando obtener un certificado en nuestro nombre. Como confiamos en este sitio, elejiremos “Yes”:

Y ahora a instalar el certificado y nuevamente aceptar la ventana de advertencia de seguridad:

——————————————————

Primera etapa finalizada. Ya tenemos certificado para firmar digitalmente nuestros correos y para poder encriptarlos. Ahora, a proteger nuestra confidencialidad!:

Abrimos el Outlook, escribimos un mensaje nuevo y hacemos clic en el boton “Opciones”:

Luego, Opciones de Seguridad:

Y ahora sí, seleccionamos el checkbox “Add digital signature to this message”. Si queremos agregar nuestra firma a todos los correos salientes, por default, tenemos que ir (dentro del Outlook) a Herramientas –> Opciones –> Seguridad –> Tildar la segunda casilla:

Bien, ya tenemos escrito nuestro correo y configurado para que vaya a un remitente determinado:

——————

Cuando el correo llega a destino, la primer modificación visible es el ícono con el que se representa el sobre cerrado:

Luego, al abrir el mensaje, un sello aparece a la izquierda del mensaje indicando que ese correo fue firmado:

Al hacer clic en el sello, se mostrará toda la información referente al certificado que avala la firma digital:

 

***NOTA***

Si utilizan un servidor interno como CA, probablemente las firmas digitales lleguen como inválidas a destinos externos. Esto se debe a que su CA no es de confianza de destino. Solución? Adquirir un certificado comercial, o distribuír el Certificado de nuestra CA interna para que se agregue en las PCs de los destinatarios

******

Saludos,
Vernocchi, Pablo

Seguridad en mensajes (Parte 1)

En esta oportunidad veremos algunos aspectos en cuanto a seguridad en los mensajes.

Un poco de historia:
Con el crecimiento de Internet en los últimos 10 años, el correo electrónico ha sufrido un cambio en su utilización. Ya no es más una herramienta de mensajería interna en empresas, sino que se ha difundido en todos nosotros.

El protocolo adoptado para transmitir los correos fue SMTP (Simple Mail Transfer Protocol). El estándar SMTP posibilita el intercambio de correos desde diferentes plataformas. Históricamente este protocolo fue diseñado para enviar mensajes cortos, sin confidencialidad en redes cerradas, y principalmente no diseñado para transmitir información sensible através de una red mundial, como Internet. Básicamente SMTP transporta los mensajes de una manera que cualquiera puede leerlos (clear text).

S/MIME (Secure/Multipurpose Internet Mail Extension) fue desarrollado como estándar para reforzar la seguridad y confidencialidad de SMTP.
S/MIME fue desarrollado en 1995 por un grupo de vendors de seguridad. Fue una de las tantas especificaciones, como PGP. En 1998 se desarrolló la segunda versión de S/MIME, a diferencia de la versión 1 ésta ya estaba por considerarse como un estándar. En 1999, la versión 3 fue propuesta por la IETF con una serie de especificaciones técnicas.

S/MIME 3 fue altamente aceptado y los productos Microsoft que lo soportan son:

Microsoft Outlook 2000 SR-1 y superior
Microsoft Outlook Express 5.01 y superior
Microsoft Exchange 5.5 y superior

Qué beneficios brinda S/MIME?:

S/MIME provee dos servicios de seguridad: Firma digital y encripción de mensajes.
Estos dos servicios son la base en la seguridad en mensajes y los veremos en detalle a continuación:

Firma Figital
La firma digital es la contrapartida de la firma en un documento en papel. Como en las firmas legales, la Firma Digital provee:

* Autenticación: Valida la identidad. Como no hay autenticación en SMTP, no hay manera de saber quién envió el mensaje. Autenticación en una firma digital resuelve ese problema, permitiendo al destinatario del mensaje asegurarse que el mensaje fue enviado or quien dice haberlo enviado.

* No repudiación: Por ser única, la firma digital evita que el remitente del mensaje lo desconozca.

* Integridad de información: La integración de información es el resultado de una operación específica que hace posible la firma digital. Cuando el mensaje es enviado, se calcula el hash del mensaje. Cuando se recibe, el hash es calculado nuevamente y, si el mensaje fue modificado en tránsito, da un error en la firma digital.

***NOTA***: Muchos softwares que agregan discalimers a los mensajes hacen que las firmas digitales sean inválidas, ya que son modificados en tránsito cuando se les agrega la nota de pie de mensaje.

 

Los pasos, en líneas generales son:

Y cuando el mensaje es recibido, el cliente realiza lo siguiente:

 

Encripción de mensajes:

La encriptación del mensaje prevee una solución para evitar que terceros puedan tener acceso al contenido del mensaje, ya que el correo SMTP se transporta en texto plano.

Encriptar es el proceso de modificar el contenido para que no sea leído o entendido hasta que no se revierta la alteración producida. De esta manera encriptar un mensaje nos provee:

* Confidencialidad: Proteje el contenido del correo. Sólo el destinatario seleccionado puede desencriptar el correo y poder leerlo. Éste método provee confidencialidad mientras el mensaje está en tránsito o almacenado.

* Integridad de la información: Como en la firma digital, encriptar un correo provee integridad de información, como resultado de las operaciones que se efectúan sobre el mismo.

Al momento de enviar un correo, los pasos son los siguientes:

 

Y cuando se recibe:

 

Aunque encriptar el contenido del mensaje provea confidencialidad e integridad, no autentica el remitente de ninguna manera. Un mensaje encriptado, pero sin firma digital sufre los mismos problemas de suplantación de identidad que el correo común.

Rights Management Services (RMS):

Como alternativa tenemos un servicio llamado RMS. Dentro de los beneficios de implementar una solución basada en RMS, podemos encontrar:

 * Proteger la información confidencial contra un acceso o uso compartido con usuarios no autorizados

* La capacidad de controlar no únicamente el acceso a los datos, sino la manera en que se utilizan y distribuyen.

* Garantizar que el contenido de los datos esté protegido y sea resistente a la manipulación

* La capacidad de controlar la fecha de caducidad de los contenidos

Un mensaje protegido por RMS no puede ser reenviado, ni impreso. Cuando respondemos sobre ese mismo mensaje, el cuerpo original es eliminado. Además las funciones de captura de pantalla están deshabilitadas. No se puede mostrar en paneles de vista previa y no se muestran las primeras líneas del mensaje en la advertencia de escritorio de Outlook 2003.

En resúmen, podemos destacar las siguientes diferencias entre S/MIME y RMS:

 

Función
RMS
Firma S/MIME
Encripta-ción S/MIME
Avala la identidad del editor
 
*
 
Establece una diferencia de los permisos por usuario
*

 

 

Impide una vista no autorizada
*

 

*
Encripta el contenido protegido
*

 

*
Ofrece expiración del contenido
*
   
Controla la lectura, reenvío, guardado, modificación o impresión del contenido por parte del usuario
*

 

 

Amplía la protección más allá de la ubicación de publicación inicial
*
*
*

La intención de esta primer parte es que puedan distiguir entra todas las alternativas de seguridad de mensajería que soporta Exchange..

Próximamente estaré mostrando cómo implementar todo esto, S/Mime y RMS en acción.

Saludos,
Vernocchi Pablo

Cómo mover las bases de datos de Exchange a otra ubicación

En diversos escenarios es necesario mover las bases de Exchange de disco, carpeta, partición, etc.
En esta oportunidad cubriremos todos los aspectos técnicos para realizar esta operación satisfactoriamente.

Almacenes de Buzones y Carpetas Públicas:

Como primer paso abriremos la consola de Administración de Exchange. Expandimos “Servers”, ubicamos nuestro servidor, lo expandimos también, expandimos nuestro “Storage Group” y allí encontraremos los almacenes de buzones.

Una vez que tengamos ubicado el almacén de buzón que querramos mover, hacemos clic con el botón secundario sobre él, y luego propiedades:

Aparecerála siguiente ventana, donde se muestran las rutas de las bases actuales:

 

Para cambiar la ruta y mover automáticamente las bases, debemos hacer clic en browse y seleccionar la carpeta de destino:

Cuando tengamos casi todo listo, en la pantalla aparecerán las nuevas rutas a modo de confirmación.

Cuando presionemos “OK” saldrá una advertencia. El proceso de mover las bases de datos requiere que los buzones sean desmontados, por lo tanto no accesibles a los usuarios. Si estamos muy seguros de lo que estamos haciendo, y que lo estamos haciendo cuando nadie está trabajando, le decimos que SI.

Qué placer ver este tipo de carteles!! 🙂 :

Para el almacén de carpetas públicas es exactamente el mismo procedimiento.

 ***NOTA***
Para brindar adecuadamente los permisos NTFS a las bases de datos deberíamos configurar, en la carpeta de destino, los siguientes permisos:

Administrators: Full control
Authenticated Users: Read and Execute, List Folder Contents, Read
Creator Owner: Nada
Server Operators: Modify, Read and Execute, List Folder Contents, Read, Write
System: Full Controll
******

Logs de transacciones:

El procedimiento para mover los registros de transacciones es similar. Los logs son compartidos por todos los mailbox stores de un storage group, por lo tanto esta configuración debe ser realizada a nivel de SG:

Veremos una ventana similar a las anteriores, seleccionamos Browse y luego le declaramos la nueva ruta:

Nuevamente, si estamos seguros de lo que estamos haciendo y nadie está trabajando, podemos darle OK y saldrá la advertencia porque se desmontarán los buzones:

Y el breve pero relajante mensaje de:

Con eso ya hemos movido las bases de mensajes y registros de transacciones de disco.

Recursos adicionales:

How to move Exchange databases and logs in Exchange Server 2003
http://support.microsoft.com/kb/821915/en-us

XADM: How to Move Exchange Databases and Logs in Exchange 2000 Server
http://support.microsoft.com/kb/257184/en-us

Optimizing Storage for Exchange Server 2003
http://www.microsoft.com/technet/prodtechnol/exchange/guides/StoragePerformance/fa839f7d-f876-42c4-a335-338a1eb04d89.mspx

Saludos,
Vernocchi, Pablo

Utilizando Grupos de almacenamiento de recuperación

En esta oportunidad mostraremos cómo utilizar el “Grupo de almacenamiento de recuperación” para recuperar un buzón desde un backup.

En innumerables ocasiones he recibido pedidos de “un correo importantísimo” eliminado por error del usuario. En versiones anteriores a Exchange 2003, teníamos pocas alternativas de recuperación. Si usábamos software de backup de terceras partes, la tarea podría ser sencilla. Pero si utilizábamos la herramienta de Windows (ntbackup.exe) era bastante tedioso que podría llevar bastante tiempo (montar un servidor en otro hardware, montar el mismo dominio de AD, montar un servidor Exchange de la misma versión con el mismo nivel de Service Pack, hacer el restore, extraer los datos con Exmerge). Al final siempre intentaba influenciar al usuario de que el correo no era tan importante :).

Con Exchange 2003 se introdujo el concepto de Grupo de almacenamiento de recuperación que nos permite restaurar un backup completo en el mismo servidor, sin la necesidad de andar montando otro paralelo, ni mucho menos.

¿Cómo utilizar la herramienta? Previamente tendremos que leer la nota de cómo configurar exmerge, ya que es el único medio por el que podremos acceder a los correos restaurados. Post SP1, podremos recuperar los buzones desde la consola de administración de Exchange, armaremos un tutorial en breve.

Para comenzar el procedimiento abriremos la consola de Adminstración de Exchange, expandimos Servidores y hacemos clic con el botón secundario sobre el servidor Exchange sobre el cual queremos hacer la restauración, luego seleccionamos “Nuevo –> Grupo de almacenamiento de recuperación…”.

Seleccionamos la ruta donde ubicaremos los archivos de transacciones y de acceso del sistema, y acemos clic en aceptar.

Veremos que tenemos un nuevo grupo de Almacenamiento. Ahora lo que tenemos que hacer es decirle qué base de datos de mensajes vamos a restaurar. Para eso haremos clic con el botón secundario del mouse sobre “Grupo de almacenamiento de recuperación –> Agregar base de datos para recuperar…”

Esto disparará una búsqueda que mostrará las bases disponibles para la restauración, donde debemos seleccionar una:

Aparecerán las propiedades, y hacemos clic en aceptar:

Ya tenemos todo configurado del lado del Exchange para hacer el restore. Ahora iniciamos la herramienta de backup (ntbackup.exe), seleccionamos la copia de seguridad a restaurar y, dentro de los contenidos, seleccionamos SOLAMENTE el almacén de buzón:

Como siguiente paso, indicaremos una ruta temporaria de extracción y tildaremos la opción “Último conjunto de restauración…” si correspondiese.

Una vez finalizada la restauración, aparecerá el siguiente mensaje:

Como siguiente paso, montaremos el almacén de recuperación para poder accederlo:

Aparecerá la siguiente advertencia que indicaremos “si”:

Bien, hasta este punto estamos en orden. La única manera de acceder a este almacen de recuperación es con Exmerge. Para ello deberíamos haber configurado todo como se explica en la nota cómo configurar exmerge en este mismo Blog. La única diferencia que encontraremos es que al iniciar Exmerge tendremos una base de datos más de donde extraer la información:

 

Espero que este breve tutorial les sirva, podrán encontrar más información en http://www.microsoft.com/downloads/details.aspx?FamilyID=df144af6-bee5-4b35-866a-557e25fe2ba1&displaylang=en
Vernocchi Pablo

PD: Gracias Benjamin Mateos (MVP Exchange) por los comentarios y modificaciones de la nota.

Directivas de Destinatarios

En esta oportunidad cubriremos aspectos básicos sobre las “Directivas de Destinantarios”.

A través de las directivas podremos configurar globalmente los dominios de Internet que nuestro servidor Exchange aceptará. Además podremos definir la estructura que van a tener las direcciones de correo electrónico al momento de su creación.

Por default, la dirección de correo se forma con el nombre que tiene el buzón (que es el mismo que el nombre de usuario). Pero… ¿qué pasa si mis usuarios inician sesión con un nombre y quiero que sus direcciones de correo sean distintas? Por ejemplo, si mi nombre de usuaro es pvernocchi, y quiero que mi dirección de correo sea pablo.vernocchi@dominio. ¿Tengo que hacerlo uno por uno? La solución la encontrarán en esta nota.

Para empezar, abriremos la consola de Administración de Sistema. Expandiremos destinatarios –> Directivas de destinatario. Ahí encontraremos una ventana parecida a la siguiente:

Si abrimos la directiva por defecto, encontraremos todo lo que expliqué más arriba, y en la solapa dominios, los declarados por los asistentes que hayamos ejecutado anteriormente (Asistente de conexión).

Si entramos a las propiedades de la directiva predeterimanda encontraremos tres solapas.

 

La tercera es para notas administrativas. Entonces, entramos a la segunda solapa, y ahí podremos definir las direcciones de correo. Para eso, haremos doble clic en el dominio predeterminado y, antes de la arroba escribiremos:

%s        La dirección de correo tendrá solo el apellido     vernocchi@vernocchi.com.ar
%g        La dirección de correo tendrá sólo el nombre     pablo@vernocchi.com.ar
%i         La dirección de correo tendrá sólo la inicial del 2do nombre     d@vernocchi.com.ar

Estas son algunas de las opciones que podremos elegir. Por supuesto se pueden combinar y poner %g.%s@vernocchi.com.ar y mi dirección de correo sería pablo.vernocchi@…

Bien, con eso ya tenemos resuelto la primer parte de nuestro desafío. Pero… ¿qué pasa si nuestra compañía tiene 3 sucursales con distinto nombre de dominio?
Supongamos el siguiente escenario:
Argentina: dominio @empresa.com.ar
España: dominio @empresa.com.es
Mexico: dominio @empresa.com.mx

Cada país cuenta con un servidor de Exchange. Para eso, tendremos que hacer uso de múltiples directivas y, a través de LDAP, decirle: si tu buzón está en España, tu cuenta de correo debe ser %g.%s@dominio.com.es . Parece medio críptico, pero en realidad nos llevará un par de clics.

Por cuestiones de esta demo, haremos sólo una:

Hacemos clic con el botón secundario –> nuevo –> Directiva de destinatario

Seleccionamos que sea de “Direcciones de correo electrónico”

Le damos un nombre descriptivo y hacemos clic en Modificar:

Se abrirá una ventana de búsqueda, donde podremos definir en qué servidor están alojados los buzones

Luego de aceptar ese cuadro de diálogo, saldrá la siguiente advertencia:

 

 

Y el filtro LDAP ya está creado automáticamente. Lo único que queda es definir los dominios y la estructura de la dirección de la cuenta, para ello abriremos la política creada recientemente:
 

Vamos a nueva y seleccionamos dirección SMTP:

Seleccionamos el formato que queremos:

Ahora tendremos que activarla y configurarla como predeterminada:

Al aceptar la ventana, nos preguntará si queremos aplicar esta nueva regla al filtro que configuramos previamente:

Y con eso termina este breve repaso de Directivas de Destinatarios.

Saludos,
Vernocchi, Pablo