Category Archives: Exchange 2000

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 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

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

Cómo restringir que usuarios envíen correos a Internet con Exchange

Gente,

En esta oportunidad veremos cómo limitar usuarios para que no puedan enviar correos a Internet.

Antes de empezar tendremos que tener en cuenta la modificación de una clave en el registro. Para eso, abrimos el regedit, y vamos a HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Resvc/Parameters/, agregamos un valor del tipo:

Value Name: CheckConnectorRestrictions
Data Type: REG_DWORD
Radix: Hexadecimal
Value: 1

Una vez que tengamos hecho eso, empezaremos a configurar todo.

Como primer paso, creamos un grupo donde alojaremos los usuarios que no puedan enviar correos (por ejemplo “Sin mail Saliente”).

Luego, abrimos el administrador de sisitema, expandimos servidores, expandimos nuestro server y, sobre conectores hacemos clic con el botón secundario –> nuevo conector SMTP. Le ponemos el nombre que querramos.

Ahora debemos asociar ese conector con un servidor virtual SMTP, para ello hacemos clic en el botón “Agregar” que está abajo a la derecha. Veremos una lista de servidores virtuales SMTP, seleccionamos el que corresponda y hacemos clic en Aceptar.

Luego tendremos que asociar ese conector con un grupo de direcciones a las que afectará. En nuestro caso será * (asterisco) ya que valdrá para todos los dominios en Internet.

Nos vamos a la solapa llamada “Restricciones de entrega” y veremos las configuraciones por defecto. Tendremos que agregar nuestro grupo (“Sin mail Saliente”) en el campo “Rechazar mensajes de”.

Listo, ahora lo que falta es reiniciar dos servicios, SMTP y Microsoft Exchange Routing Engine para que apliquen las configuraciones del registro que cambiamos al principio.

Espero que les sirva,
Vernocchi Pablo.

NOTA: Antes de implentar los cambios recomendados en este artículo, les recomiendo leer estos dos artículos de Microsoft por efectos secundarios:

Mail delivery is slow after you configure delivery restrictions that are based on a distribution list:
http://support.microsoft.com/kb/812298

In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups
http://support.microsoft.com/kb/895407/

Cómo configurar Exchange para trabajar con conectores POP3

Es muy visto escenarios con conectores POP3. Esto nos permite tener una conexión de Internet con IP dinámica y poder aprovechar todas las funcionalidades de Exchange.

El problema pasa cuando tenemos direcciones pop3 que no se descargan a nuestro Exchange, sino que lo descargan los usuarios, generalmente los que no están físicamente en la oficina donde Exchange está instalado. Los usuarios mandan mail a usuarioremoto@dominio.com y el Exchange envía un NDR diciendo “user unknown” o cosas raras por el estilo.

Básicamente esto pasa porque el usuario no está creado en Active Directory, pero la dirección de correo existe en nuestro ISP.

Si creáramos la cuenta en AD, los mails quedarían de por vida en el buzón y nunca serían descargados por el usuario que chequea sus mails en el ISP… Un buen método para poder zafar de este problema es:

a) Ir al Exchange System Manaher
b) Expandir Servidores, Protocolos, SMTP
c) Clic con el botón secundario, seleccionar Propiedades
d) Clic en la solapa Messages, ingresar la dirección IP del servidor SMTP del ISP en Forward all mail with unresolved recipients to host, y luego OK.
e) Reiniciar Servicios de SMTP.

Cómo agregar un segundo dominio SMTP a Exchange 2000/2003

GENTILEZA:
Rafael E. Villaseñor Jofré
———————————————–
Exchange puede trabajar con múltiples dominios. Para poder configurarlos debemos abrir el System Manager y navegar hasta:

– First Organization (Exchange)
|_ Recipients
|_ Recipients policies
|_ (en el panel derecho) Default Policy
|_ Doble click y se abrirán las propiedades

– Seleccionar la Solapa del medio (E-Mail Addresses (Policy)
– Clic en “New…”
– Doble Clic en “SMTP Address”
– Escribir en el espacio “Address”: @tudominio.com => OK
– Te encontrarás en la pantalla anterior. Seleccionar la nueva dirección
SMTP creada y luego clic en “Set as Primary”
– Ok
– Esperar unos minutos para que se replique la política y tendrás un nuevo
mail en todos los usuarios.

Luego de unos minutos deberías abrir la MMC de “Usuarios y equipos de AD” y
abrir las propiedades de los usuarios que tengan buzones de Exchange,
seleccionar la solapa “Correo electrónico” y verificar que se hubiera
aplicado la política (debería estar seleccionado el CHECKBOX que dice
“Actualizar direcciones automáticamente…”.

Esa es la forma automática y menos trabajosa. La otra es ingresar a las
propiedades de cada uno de los usuarios a través de “Active Directory Users
& Computers” y manualmente en la solapa “E-mail Addresses” agregar el
dominio deseado repitiendo el esquema descripto anteriormente. Como
excepción deberías desmarcar el CHECKBOX que dice “Actualizar direcciones
automáticamente…”.

Lectura Adicional:
How to customize the SMTP e-mail address generators through recipient
policies

Configuring Exchange to receive mail for multiple domains

Saludos,
Vernocchi Pablo

Cómo agregar un disclaimer en Exchange 2000/2003

En los newsgroups de Microsoft son muchas las consultas que se reciben sobre este tema.

Este post es para centralizar los links que hacen referencia a cómo agregar disclaimers a los correos salientes de Exchange.

Tenemos dos maneras de hacerlo:

1) Usando software de terceros, hay una lista en este link. Recomendado GFI MailEssentials, si bien el producto es comercial, los disclaimers siguen andando en modo definitivo, aún expirado el trial.

2) Usando un event sink para el smtp, como se describe en las notas técnicas:
How to add a disclaimer to outgoing SMTP messages in Visual Basic
How to add a disclaimer to outgoing SMTP messages in Visual Basic script

Saludos,
Vernocchi Pablo

Cómo prevenir llegar al límite del store en Exchange Standard?

Que dilema. Usuarios con muchos elementos, y sin ánimo de autoarchivar.
Los administradores de Exchange nos encontramos muy seguido con este tipo de cuestiones. Grandes cantidades de correo, poco presupuesto para migrar a Enterprise, y Microsoft que demora el lanzamiento del SP2 de Exchange 2003!!

Hace poco tiempo tuve un problema similar en un cliente con SBS 2000. 20 usuarios, muchos mails y nadie autoarchiva. Clientes de correo Outlook 2000 (que la función de autoarchivar cuesta un poco hacerla andar).

Lo primero que tuve que hacer fue deshabilitar la opción de mantener una copia de los elementos eliminados por 7 días. Esto ocupa lugar en la base, que necesitaba para montarla.

Segundo, una vez montado el store, utilizando un Recipient Policy forcé la eliminación de los elementos eliminados mayores a 30 días (hubo casos donde se borraron mas de 7500 elementos!).

Tercer paso, usando Exmerge y editando el exmerge.ini, autoarchivé a .pst desde el servidor los elementos que tenían más de un año de antigüedad. Esto se scheduleó una vez al mes, usando opciones de línea de comandos.

Una nueva defragmentación de las bases, replantear el tema de los límites para los buzones y quedó 10 puntos.

Espero que esta experiencia les sirva a todos,
Vernocchi, Pablo.