Como es de conocimiento mundial, el 27 de febrero hubo un “mega-terremoto” con devastadoras consecuencias, tanto en pérdida de vidas humanas como en pérdidas de miles de hogares y cuantiosos daños a la infraestructura pública.
En lo estrictamente informático, esto trajo muchas consecuencias, como las que revisa Luis Montenegro en su blog sobre planes de contingencia, pero una de las consecuencias más importantes que el Gobierno de Chile determinó retrasar el cambio de horario de invierno, el cual se aplaza desde la media noche del sábado 13 de marzo (cuando debiese ocurrir) a la medianoche del sábado 3 de abril (nueva fecha)
Microsoft liberó un hotfix que actualiza los sistemas operativos para este cambio de horario, el cual puede ser descargado en la siguiente dirección:
Le recomiendo leer detenidamente la información referente al hotfix y luego solicitarlo desde el link “Ver y Solicitar la descarga de la revisión” que aparece al inicio de la página. Se recomienda instalar la actualización lo antes posible.
Aprovecho la oportunidad para responder un par de preguntas que ya he recibido:
- ¿Cómo se aplica el hotfix en un entorno virtualizado con Hyper-V?
El Hotfix DEBE ser aplicado tanto en la partición padre (host) y como en las particiones hijas (guests). Hay que tener cuidado con las máquinas virtuales que están sincronizando la información de horas con con el host de virtualización.
- ¿Cómo afecta este cambio a los Usuarios/Administradores de Exchange Server?
Las citas del calendario se verán desfasadas 1 hora durante el período entre el 13 de marzo y el 3 abril.
Una vez aplicado el hotfix, hay 4 formas para enfrentar esto:
A. No hacer nada, y decir a los usuarios que confirmen sus reuniones por mail o por teléfono.
B. Pedir a los usuarios que revisen y re-programen manualmente sus reuniones para ese período de tiempo.
C. Utilizar la herramienta “Time Zone Data Update Tool for Microsoft Outlook” en cada estación de trabajo.
D. Utilizar la herramienta “Microsoft Exchange Calendar Update Configuration Tool” , con la cual se pueden actualizar las citas en el calendario centralizadamente, pero ojo, pues es un proceso complejo.
Como pueden ver, hay varias opciones y la mejor dependerá de su entorno particular (cantidad de usuarios, uso de outlook para calendarios, etc.)
Más información:
Cualquier duda pueden hacerla como comentario, o a través de la lista de distribución del Grupo Latinoamericano de Usuarios de Exchange (G.L.U.E.)
Gonzalo
|
NOTA:
Este post fue publicado originalmente en mi anterior blog el
16/08/2007. Hice algunos cambios, modificaciones y adiciones para mejorar el artículo
|
En los artículos previos explicamos:
Ahora, me gustaría hablar un poco sobre cómo efectivamente y de forma "segura" permitir el Relay (Reenvío) a través de nuestro servidor SMTP.
La pregunta obvia es: Por qué razón alguien querría permitir Relay en sus servidores de correo?
Razones pueden haber varias: Clientes de correo qué sólo poseen compatibilidad para POP3/IMAP4 necesitarán un servidor de correo SMTP para enviar mensajes (Por ejemplo, aún hay dando vueltas clientes de correo antiguos o dispositivos móviles y PDAs que no soporten ActiveSync.), usuarios que viajan, etc.
La esencia del Relay Bueno es que sólo permitiremos el envío de correo para los usuarios del dominio que se autentifiquen con nuestro servidor de correo. En el artículo sobre Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado, vimos este comportamiento. Ahora les mostraré cómo hay que configurar el Servidor para que funcione de ésta forma.
Paso 1. Cerrar el Open Relay
En Exchange 2003 el Open Relay viene cerrado por defecto. De todas formas, les sugiero comparar la configuración de su servidor con la mostrada en éste artículo:
Verificando las opciones de Relay en Exchange 2000/2003.
Paso 2. Permitir el Relay SOLO a Usuarios Autenticados
En las propiedades del servidor Virtual SMTP (Exchange System Manager -> ... -> Servidor -> Procolos -> SMTP -> SMTP Virtual Server), en la lengüeta Acceso (Access) presionamos el botón de Autenticación (Autentication). Tendremos un par de ventanas como las del siguiente dibujo:
En la ventana de Autenticación, deben estar seleccionados los 3 checkboxes principales (como muestra la figura).
Ahora presionamos el botón Usuarios (Users) y se abrirá una nueva ventana.
En esta nueva ventana debemos dejar solamente el grupo de Usuarios Autenticados (Authenticated Users), con los permisos de Enviar (Submit) y Reenviar (Relay).
En este último paso realizamos la configuración más importante: le dijimos al servidor smtp que los usuario autenticados y sólo éstos (es decir, los usuarios que se identificaron exitosamente con su nombre de usuario y contraseña al establecer la sesión smtp), pueden reenviar correo a través de este servidor smtp a direcciones que no pertenecen a la organización (dominio smtp).
Luego cerramos todas las ventanas y reiniciamos el servicio SMTP para que se apliquen los cambios.
Finalmente, debo recordar que toda la información de usuarios y sus claves que se envían al servidor smtp (y al pop3 y al imap4), viajan en texto plano (o codificadas en Base64), por lo que es trivial con un sniffer poder obtener estas contraseñas.
En Consecuencia, es recomendable usar otros protocolos de envío/recepción de correo (Mapi, RPC sobre HTTP(S), HTTPS, ActiveSync, HTTPS, etc), o al menos cifrar las comunicaciones a estos servicios usando TLS (con certificados digitales para cada protocolo).
Gonzalo
Etiquetas de Technorati:
Exchange Server,
Relay
Muchas veces nos hemos encontrado con que al reiniciar servicios éstos se quedan “colgados” en estado “deteniendo” o “iniciando”.
Una forma para detener realmente estos servicios (o aplicaciones) es usando el par de comandos: tasklist y taskkill.
Nota para mis amigos Linuxeros: cualquier parecido con ps/kill es sólo coincidencia… supongo… :p
Los pasos son bastante simples:
1. Elegir el Objetivo.
Para poder usar taskKill necesito conocer el ID de proceso que quiero “eliminar”. Este proceso puede ser una aplicación o puede ser un servicio. Si estoy usando Windows 2008/R2 me basta con ir al administrador de tareas y en la lengüeta de “Procesos” o “Servicios” y leer desde ahí el Si es una aplicación es bastante fácil, pues me basta con ir al administrador de tareas (taskmanager) y obtener desde ahí el número de Proceso, o PID (Process ID).
Pero si estoy usando Windows 2003 Server, obtener el PID de un servicio es un poco más complejo.
A. Ejecutar desde la línea de comandos: tasklist. se obtiene una respuesta como la siguiente:
para poder filtrar por el nombre del servicio podemos usar el comando findstr para que busque el nombre del servicio “spool” en en la salida:
tasklist | findstr spool
y obtenemos el número del proceso: 1312
(si, ya se que parece powershell, pero en realidad no es nada nuevo!)
2. Dispara!
Ya sabemos que queremos pasar a mejor vida el proceso 1312, así que ahora simplemente ejecutamos:
taskkill /PID 1312 /F
Notas:
- El modificador /F es para “Forzar” la finalización del proceso.
- Como siempre es posible invocar los comandos seguidos de un “/?” para conocer todas las opciones.
- En el caso de eliminar un proceso con taskkill, solamente terminamos su ejecución, no estamos “borrando” el proceso, éste se volver a ejecutar cuando demos inicio nuevamente al proceso manualmente (más abajo) o al siguiente reinicio.
IMPORTANTE: este comando debe ser ejecutado con privilegios de administración, o con una interfaz de comandos ejecutada como administrador
De esta forma terminamos definitivamente con el proceso problemático, y ahora es posible darle inicio nuevamente usando el comando:
net start <nombre_proceso>
Finalmente, el servicio volvió a subir, pero esta vez con un nuevo PID, es decir, es un nuevo proceso para el sistema:
Espero que les sea de utilidad.
Gonzalo
Microsoft Press ha puesto hoy a disposición del público general un e-book de su nuevo libro First Look: Office 2010, que en castellano sería algo así como “Una primera mirada a Office 2010”.
Para descargarlo pueden hacer click en la imagen.
En lo que respecta a Exchange (obvio!), el capítulo 6 trata sobre Outlook 2010 (Manage Rich Communications with Outlook 2010)
Si aún no han probado Office 2010, pueden bajar ahora mismo el beta público (disponible en español)
Gonzalo
Junto con discos duros cada vez más grandes, cuyas capacidades ya se miden en TeraBytes desde hace un buen rato, se está generando cada vez mayor cantidad de información almacenada, sea como Bases de Datos (SQL, Exchange u otros) o como archivos de Discos Duros Virtuales (.VHD), todos los cuales “pesan” varios GB. Un desafío importante es poder realizar el movimiento de estos archivos entre distintos discos duros, a veces ubicados en distintos servidores – muchas veces a través de la red – por distintos motivos: respaldos, mantenimiento, etc.
Esta tarea generalmente consume mucho tiempo dependiendo de varios factores: velocidad de lectura/escritura en disco, uso de CPU de los servidores involucrados, velocidad y congestión de la red, entre otros. Una forma de disminuir notoriamente el tiempo que dicha copia de información tarda es utilizando una herramienta que viene con Exchange Server, al menos desde la versión 2000: ESEUtil.exe. En mi experiencia, el uso de ESEUtil reduce en un 40% a 50% el tiempo empleado por otras herramientas como Xcopy o RoboCopy.
ESEUtil es una herramienta de línea de comando para verificar, modificar y reparar una base de datos Exchange – las cuales típicamente son de varios GB, pero una de sus opciones permite realizar la copia de archivos usando la siguiente Sintaxis:
esutil.exe /Y Archivo_Origen /DArchivo_Destino
A continuación hay un ejemplo (real) de la copia por red de un archivo de respaldo (.bkf) por red FastEthernet (100Mbps) de 16,5 GB, el cual sólo tardó 1372 segundos = 22 minutos!. Nada mal.. hagan sus propios cálculos ;)
Notas:
- Eseutil no acepta “comodines” (Wildcards) en los nombres de archivos. es decir no puedes pedir copiar c:\*.*
- Es necesario entregar la ruta completa del archivo de origen, como en el ejemplo.
- No es necesario entregar la ruta del archivo de destino. En este caso el archivo de destino se grabará en el directorio desde donde se está ejecutando el comando y con el mismo nombre de archivo, como en el ejemplo.
- Hay 2 versiones de ESEUtil, asegúrate de usar la adecuada a tu servidor:
- Una de 32-bits (Exchange 2003) que generalmente se encuentra en: C:\Program Files\Exchsrvr\Bin
- Una de 32-bits (Exchange 2003) que generalmente se encuentra en: <SystemDrive>:\Program Files\Microsoft\Exchange Server\Bin.
(Reemplazar SystemDrive por la letra de unidad donde está instalado Exchange)
Preguntas:
- ¿Tengo que tener Exchange Server instalado para usar Eseutil?.
No, no es necesario. Desde un equipo con Exchange Server puedes copiar los archivos eseutil.exe y ese.dll a un directorio en otro servidor y realizar las copias de archivos (u otro mantenimiento a tus bases de datos de Exchange). También puedes invocar a eseutil por red (\\ServidorExchange\RutaEseutil)
- No creo en la magia ni en la brujería, ¿Cómo funciona realmente esto “por debajo”?
Simplificando un poco las cosas, el “truco” se consigue al no realizar verificaciones de escritura en el destino de la copia, sólo se realiza una copia “en bruto” de la información. Es el equivalente en TCP a enviar información continuamente y sin esperar por un ACK. Para mayor información puedes leer el artículo (en inglés) Slow Large File Copy Issues que está en las referencias, o dejando un comentario a este post.
- OK. ¿Pero si no se hacen verificaciones y estoy realizando una copia por red, cómo puedo estar seguro de que mi archivo de destino es una copia fiel del original?
En realidad si se realizan verificaciones, pero en otros niveles de la comunicación: Ethernet y TCP al menos ;)
- ¿Hay algún impacto en el uso de la red al realizar esta copia de archivos?
El uso de eseutil hace un uso más intensivo de la red de lo que harían otros programas como Windows Explorer o RoboCopy. La siguiente imagen es un ejemplo del uso de la red al realizar la copia del ejemplo anterior.. es fácil ver cuándo comenzó la copia de archivos ;)
Para los más observadores, el servidor fuente es un Windows 2003 y el destino un Windows 2008, por lo que el alto uso de red no es producto de las mejoras en TCP/IP de Windows 2008, sino sólo de ESEUtil.
Referencias:
Espero que este dato les sea de utilidad.
Consultas y comentarios son siempre bienvenidos.
Gonzalo
| NOTA: Este post fue publicado originalmente en mi anterior blog el
14/08/2007. |
En el foro/mailing-list del
G.L.U.E. he visto un par de veces que se ha hecho esta pregunta. Por ese motivo les dejo un manualcillo mostrando cómo se puede configurar Exchange Server 2000/2003 para realizar esta tarea. Espero en los próximos días publicar un artículo sobre cómo hacer esto en Exchange 2007
Supondremos que tenemos un usuario "Juan Pérez" con dirección de correo jperez@empresa.com, que desea que todos los mails que llegan a su casilla sean redirigidos a dos casillas de correo externas (fuera de la organización Exchange): hotmail y yahoo.
Paso 1: Creación de Contactos
En Active Directory Users and Computers (ADUC), ir a la OU donde vamos a crear a los nuevos contactos. Hacer click Derecho sobre la OU y seleccionar nuevo -> Contacto.
Tenemos que tener los siguientes datos para crear el contacto:
Nombre: Juan
Apellido: Pérez
e-mail Externo: jperez@hotmail.com
Personalmente me gusta poner junto al apellido el dominio al cual pertenece el contacto. En nuestro caso, es Juan Pérez y el Dominio es Hotmail, por lo que en el apellido escribo Pérez - Hotmail. Eso me permite visualmente saber a cuál dominio/empresa pertenece el contacto (y hacía dónde se dirigirá el mail), como se ve en la figura:
Al en la siguiente pantalla del asistente, tenemos que crear el alias de Exchange asociado al contacto y su dirección de correo. El alias viene "pre-llenado", podemos mantener el mismo o cambiarlo.
Luego debemos presionar el Botón "Modify" para ingresar la dirección de correo externa.
Aparecerá una nueva ventana con varios tipos de direcciones de correo, seleccionaremos "SMTP Address" y presionamos OK.
Aparecerá una nueva ventana, en donde ingresaremos la dirección de correo de nuestro contacto, en nuestro caso: jperez@hotmail.com
Presionamos OK, volvemos a la ventana original y presionamos Finish para que se cree el nuevo contacto.
Nota: con esto ya es suficiente para que el contacto pueda ser encontrado en la GAL y enviarle mails, los cuales serán enviados directamente a su casilla externa.
Ahora debemos crear tantos contactos como necesitemos para hacer el envío de mails a direcciones externas. El proceso es exactamente el mismo. En nuestro ejemplo crearemos sólo 2, tal como se ve en la imagen.
Paso 2: Creación de un Grupo de Distribución
En ADUC, Ir a la OU donde vamos a crear el grupo de distribución, Click Derecho sobre la OU y seleccionar Nuevo -> Grupo. Aparecerá la siguiente ventana.
Aquí debemos dar un nombre al grupo, éste puede ser cualquiera, pero es recomendable usar nombres de objetos que sean razonables y que permitan una fácil identificación.
Los conceptos sobre el Alcance (Scope) y el tipo (type) del grupo están fuera del alcance de este tutorial, pero para nuestro propósito, es más que suficiente con seleccionar: Global y Distribution, respectivamente. Presionamos Next.
Nota: en Exchange 2007 los grupos de distribución deben ser de tipo Universal
En la nueva ventana activamos la opción de Crear una dirección de correo de Exchange, tal como muestra la figura. El Nombre del Alias no es relevante, sólo importa que no esté repetido.
La advertencia nos indica que si estamos en una situación con varios dominios o incluso varios forest, tenemos que privilegiar el uso de grupos Universales.
Presionamos Next y finalmente Finish en la siguiente ventana.
Con esto el Grupo ya ha quedado Creado.
Ahora, hacemos doble click sobre el grupo creado y en la nueva ventana seleccionamos la lengüeta de Miembros
Presionamos ahora sobre el botón Agregar (Add).
Aparecerá la típica pantalla de búsqueda, pero para que busque contactos, debemos presionar el botón de Tipos de Objetos (Object Types).
Se nos abrirá una nueva ventana y en ésta debemos seleccionar el tipo de Objeto: "Contactos".
Presionamos OK, volvemos a la ventana original de búsqueda y escribimos o buscamos a nuestros contactos. (por su nombre, por ejemplo)
Una vez agregados los contactos, tenemos que los miembros del grupo de distribución son nuestros contactos, como en la siguiente figura.
Nota: Otra forma de agregar los contactos al grupo es: desde las propiedades de cada contacto, seleccionando la lengüeta miembro de (Member Of) y ahí poner el grupo de distribución del cual el contacto va a "ser miembro".
Paso 3: Configurar el Reenvío de Correos
Finalmente, para poder configurar el reenvío de los correos, nos vamos a las propiedades del usuario a quien deseamos configurar que sus correos sean reenviados, y seleccionamos la lengüeta: Exchange General, y ahí presionamos el botón de Delivery Options (Opciones de Entrega).
En la ventana "Opciones de Entrega", en la sección de Reenvío (Forward), seleccionamos "Reenviar a" (Forward To) y presinamos el botón "Modificar" (Modify).
Nos aparecerá la ya conocida ventana de búsqueda, ahi escribimos o buscamos el nombre de nuestro grupo de distribución recién creado, como muestra la figura, y presionamos OK.
Volvemos al la ventana original y tenemos que decidir si vamos a reenviar los mails conservando una copia en el buzón del usuario, para lo cual debemos marcar la opción de "entregar el Mensaje a Ambas direcciones la de reenvío y la del buzón".
Si no no queremos que quede una copia en el buzón del usuario, dejamos la opción sin seleccionar.
Presionamos OK dos veces y salimos de las propiedades del usuario.
Listo! Ahora cada vez que alguien le envíe un correo a nuestro usuario (jperez@empresa.com), ésta será reenviada a las direcciones de correo Externas (Ambas), definidas en los contactos que creamos y que forman parte del grupo de distribución al cual configuramos el reenvío.
Espero que les sea de utilidad, y como siempre los comentarios son bienvenidos.
Gonzalo
| NOTA: Este post fue publicado originalmente en mi anterior blog el
28/08/2007. |
Graciosamente, yo tenía pensado escribir exactamente este artículo, pero antes de escribirlo, chapoteando por internet, encontré que alguien ya lo había escrito por mi!!!
Daniel Matey, MCSE y ex-MVP español en MOM, escribió en su blog una serie de artículos Básicos, respondiendo a las preguntas básicas clásicas que se ha encontrado en foros... justamente lo que yo espero hacer hacer en mi blog ... ;)
Para no reinventar la rueda, y puesto que está casi lo mismo que yo pensaba poner en este artículo, mejor les dejo estos links, pues los artículos están buenísimos y responden a preguntas del tipo: qué son los registros MX?, cómo crear registros MX?, cómo saber si mi servidor hace Relay?, cómo saber si estoy en una lista negra?, etc., etc....
Disfrútenlos ;)
Gonzalo
|
NOTA:
Este post fue publicado originalmente en mi anterior blog el
14/08/2007. Hice algunos cambios, modificaciones y adiciones para mejorar el artículo
|
Como vimos en los artículos sobre envío de correo SMTP (PARTE I, PARTE II y Relay), al establecer una conexión SMTP es bastante fácil poder obtener una lista de las direcciones de correo válidas en un dominio: Basta con adivinar los nombres de usuario al enviar al correo el comando "rcpt to: <usuario_adivinando>@dominio.org".
Por ejemplo, si Juan Pérez tiene una cuenta de correo jperez@dominio.org, generalmente veremos en los logs de recepción (y/o bloqueo) de correo, más de algún mensaje dirigido a casillas del tipo: jperez128@dominio.org, juanjperez@dominio.org, etc. Claramente el spammer está intentando adivinar direcciones de correo válidas.
Si tenemos habilitado en nuestro servidor Exchange el filtrado por destinatario (recipient filter) para que no acepte mensajes a destinatarios que no están en el directorio, es decir, sólo reciba correos para destinatarios que posean una dirección de correo válida, el servidor entregará un mensaje de error con código 5.x.y al atacante durante la conexión smtp.
Esto tiene 3 problemas:
- Estamos dando –indirectamente - a nuestro atacante información sobre cuáles son las direcciones de correo electrónico válidas en nuestra organización.
- Nuestro servidor SMTP está procesando un alto volumen de peticiones del atacante y realizando una gran cantidad de consultas al Servicio de Directorio (Active Directory), consumiendo inútilmente recursos valiosos.
- El servidor de correo está obligado, por adhesión a la RFC 2821 a enviar un correo con un NDR al "remitente" que trata de enviar correos a las direcciones "equivocadas". En el caso de un ataque, aún más recursos desperdiciados y posibilidad de caer en listas de backscatter.
La situación recién mencionada es conocida como un ataque de Directory Harvest, o “Cosecha de Directorio”.
Como respuesta a este problema, se puede implementar en nuestros servidores SMTP la funcionalidad de Tar Pitting, la cual consiste en introducir un retraso en las respuestas con código 5.x.y, usualmente asociadas a problemas derivados de ataques de SPAM.
Exchange 2003
La funcionalidad de TarPitting no es exclusiva de Exchange 2003, pues es una característica del servidor SMTP, y por tanto de IIS, la cual está disponible para cualquier equipo tenga instalado el SP1 de Windows 2003 Server.
Cómo se configura?
Súper simple.
- Debemos abrir el editor del registro (Inicio -> Ejecutar -> Regedit).
- Buscamos la siguiente ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters
- Clic derecho - Nuevo Valor DWORD.
- Escribir: TarpitTime (OJO con las mayúsculas y minúsculas), Presionar Enter.
- Abrir el nuevo valor creado (TarpitTime) haciendo doble clic sobre él, luego haga clic sobre decimal e ingrese un número en el cuadro de texto. Por ejemplo: 8.
- Cierre el editor de Registro.
- Reinicie el Servicio SMTP del servidor.
Qué hicimos?. Creamos el valor en el registro y configuramos una demora de 8 segundos en las respuestas del tipo 5.x.y.
Por qué 8 segundos? porque 8 segundos es un tiempo razonable para que un usuario que escribió mal una dirección espere por su respuesta, pero es una eternidad para un robot spammer ;)... además, me gusta el número 8 :p
Referencias:
Exchange 2007/2010:
En Exchange 2007 la configuración de TarPit viene habilitada de forma predeterminada en los conectores de recepción (Servidores de Transporte) en un valor de 5 segundos. Para revisar esta configuración se puede utilizar el cmdlet:
get-ReceiveConnector | select name,tarpitinterval
y para modificar esta configuración, se puede usar este comando:
set-ReceiveConnector "Receive Connector Name" -tarpitinterval 00:00:10
hay que reemplazar el nombre del conector y el valor de la demora en horas:minutos:segundos
Referencias:
Bonus: Mi Amigo Christian Aguilera me comentó que además el retraso tiene una "Duración Aleatoria". Con esto se persigue engañar a los robots de spam, para que así no logren detectar que existe un mecanismo de Tar Pitting configurado en nuestro servidor. Esta es una de las ventajas que Exchange 2007 traiga su propio servicio SMTP (y ya no use el servicio SMTP del IIS).
Si quieren conocer más sobre Exchange 2007, les recomiendo los sitios de:
Gonzalo
| NOTA: Este post fue publicado originalmente en mi anterior blog el
14/08/2007. Hice algunos cambios, modificaciones y adiciones para mejorar el artículo |
Te has visto alguna vez en una situación como esta?
Usuario: (te llama y te dice:) "Hola. sabes, no puedo enviar un correo".
ADMIN: OK, me podría decir por favor qué mensaje de error le aparece en la pantalla?
Usuario: "Si, aquí dice: su mensaje no se ... ha podido entregar... código del error: 5.2.3. Qué puede ser?".
ADMIN: ???? (Este tipo cree que me sé TODOS los códigos de error de memoria o qué?!).
Bueno, al menos yo sí .. más de un par de veces.... y no me sé los mensajes de error de memoria, pero...sí conozco son los primeros números que componen los códigos de las “Notificaciones de Estado de Entrega” (RFC 1891 y RFC 1893)
- 2.X.Y : Éxito, la operación pudo ser realizada.
- 4.X.Y : Error transitorio persistente, la operación no puede ser realizada temporalmente, por ejemplo debido a problemas con la red, o con recursos del servidor.
- 5.X.Y : Errores permanentes, este tipo de errores implican que el servidor esté con algún problema o que hay alguna regla específica que se esté violando, por ejemplo el error 5.2.3 significa que “el mensaje es demasiado grande para la cuota local”.
Nota: estos mismos códigos aplican para comunicaciones HTTP.
Pero, más importante aún, aunque no me conozca los códigos de errores, al menos sé donde encontrarlos ;D
KB284204: Notificaciones del estado de entrega en Exchange Server y Small Business Server
Espero que les sirva.
Gonzalo
PS: Cualquier relación o parecido con las historias del BOFH es completamente intencional ;)
|
NOTA:
Este post fue publicado originalmente en mi anterior blog el
13/08/2007. Hice algunos cambios, modificaciones y adiciones para actualizar un par de herramientas
|
Hace unos días atrás, se dio una discusión bastante interesante en el foro/mail-list de ITPRO Chile, la cual trataba básicamente sobre la "legitimidad" de tener software pirata, por el simple hecho que "todo el mundo usa software pirata".
Más allá del dilema moral al respecto y de la Guerra Santa entre los adherentes al software de código abierto (y software libre) "Versus" el Software Propietario, me declaro un simpatizante y usuario de software GRATIS. En este punto no puedo eludir mi deber de aclarar que en castellano libre NO ES LO MISMO que gratis. (lo siento…)
Bueno, aquí les dejo una pequeña lista de los programas y herramientas gratuitas que habitualmente utilizo como usuario doméstico, o como Administrador de Sistemas.
- Antivirus:
- AntiSpyware: Windows Defender
- Cliente (y Servidor) FTP: FileZilla
- Compresor: 7-zip, excelente herramienta, incluso descomprime .rar :)
- CD/DVD Burner:
- IsoRecorder, Excelente programa para grabar .iso a CD/DVD. Compatible con XP, Vista, Windows7 y Windows 2008/R2.
- CDBurn y DVDBurn, ambas vienen en el Resource Kit de Windows 2003 Server.
- Daemon-Tools: Permite leer y cargar en un CD/DVD Virtual imagenes .iso. OJO: en las últimas versiones (4.x) han incluido en la instalación la "opción" de instalar Software Spyware: DAEMON Tools Searchbar y Save Now. Mi recomendación es instalar versiones anteriores (3.x) y poner MUCHO cuidado a las opciones de instalación
- Sniffers:
- Capturas de Pantalla
- Recortes (Cropper), viene con Windows Vista y Windows 7. Permite sacar recortes de pantalla (ventanas completas o sólo alguna parte seleccionada). Ideal para hacer informes de forma rápida.
- Snapshots. Captura imágenes de la pantalla, muy sencillo y simple de usar
- Camstudio: Permite grabar en video lo que ocurre en tu pantalla (tipo screencast), una excelente alternativa a software como Camtasia
- Virtualización: Microsoft ofrece en el nuevo programa VHD Test Drive la posibilidad de bajar discos duros virtuales de servidores con productos pre-instalados para probarlos. Imperdible.
- IMFCompanion. Indispensable para los administradores de Exchange 2003 que usamos IMF como filtro antispam. Permite "ver" y "rescatar" correos que han sido bloqueados erróneamente (falsos positivos).
- Crimson Editor. Excelente editor de texto. Permite editar casi cualquier archivo de texto en casi cualquier formato (HTML, C, ASM, XML, y un largo etc.), con highlights de sus palabras reservadas. Además tiene un cliente ftp incorporado para hacer actualizaciones a sitios web desde el mismo editor, en incluso se puede configurar un compilador y así compilar desde el mismo editor.
- Karen's Power Tool. Lejos uno de mis favoritos. Karen ha escrito un montón de herramientas gratuitas súper útiles y simples de usar para poder realizar tareas importantes.
En más de una oportunidad sus aplicaciones me han ayudado :D. Por mencionar sólo algunas:
- Replicator. Esta herramienta replica y sincroniza archivos y directorios. La copia es idéntica al original, incluso replica la fecha de creación del archivo. Es capaz de replicar "el borrado de archivos" entre el origen y el destino. Se puede configurar para que replique periódicamente.
- 'Net Monitor. Permite monitoreo básico de algunos servicios críticos de cualquier red: HTTP y SMTP; también verifica la conectividad con cualquier equipo de la red (ping). En conjunto con EMailer II es capaz de enviar correos o alertas en caso de fallas. (casi igual que MOM :p)
- Karen's EmailerII. Envía correos desde la línea de comandos. Puede ser usado para, por ejemplo, enviar alertas desde el 'Net Monitor, o desde el Performance Monitor de Windows (Les Recomiendo el Blog de Isabel de la Barra sobre PerfMon ;) )
- Karen's Print Logger. Esta herramienta se instala en nuestro servidor de impresión y lleva un registro (en .txt, fácilmente importable en excel) sobre qué cosas han sido impresas: usuario, cantidad de hojas, nombre del archivo o URL, fecha y hora, entre otros. Increíblemente útil y Gratis.
Hasta aquí mi lista de herramientas gratuitas favoritas. Como pueden ver, son hartas las cosas que se pueden hacer con herramientas de buena calidad y sin necesidad de piratear software ;).
Espero, que la parte II de éste artículo la construyan Ustedes contándome cuáles son sus herramientas gratuitas favoritas ;).
Gonzalo
Etiquetas de Technorati:
Herramientas,
Gratis,
Tools
|
NOTA: Este post fue publicado originalmente en mi anterior blog el
13/08/2007
|
Como "Corolario" a los artículos sobre Cómo Enviar Correo Electrónico "a mano" (PARTE I y PARTE II), les quiero mostrar una forma rápida de verificar si un servidor de correo está permitiendo el reenvío no autorizado de de correos (Open-Relay).
Primero que todo, me gustaría quitar un poco el estigma negativo a la palabra Relay: Relay significa simplemente "retransmitir". El Relay en sí no es malo, de hecho, hay un "Relay Bueno" y un "Relay Malo".
Todo Servidor SMTP, por definición, debe aceptar los correos que van dirigidos hacia su dominio SMTP, es decir, "si yo soy el servidor de @dominio.org, debo aceptar todos los correos entrantes dirigidos a *@dominio.org". (dejamos de lado por un momento las consideraciones de filtrado antispam previas y posteriores a la conexion SMTP, hasta un próximo post).
Que pasa si, por ejemplo, tengo a muchos clientes remotos que revisan su correo usando protocolos POP3 o IMAP (diversas razones pueden justificar este escenario: desde las preferencias personales del administrador hasta el uso de dispositivos móviles como PDAs o BlackBerry en modo "Profesional"). Ellos necesitarán un Servidor de Correo Saliente (SMTP) para poder enviar su correo electrónico, el cual no solamente irá dirigido a nuestro dominio SMTP, sino que muchos otros dominios SMTP de clientes, proveedores, amigos, familiares, etc, etc, etc. Por lo tanto, en este escenario, nosotros debiésemos permitir el relay a través de nuestros servidores a nuestros usuarios en ubicaciones remotas. Esto sería "Relay Bueno".
Por otra parte, si yo soy un spammer, me gustaría poder enviar miles (o millones) de correo comercial no solicitado (UCE, Unsolicited Comercial E-Mail, o SPAM), idealmente a costa de los recursos de otros servidores (entre otras razones, para no caer yo mismo en una lista negra). Entonces yo busco a servidores que me permitan, sin autentificarme, enviar correos electrónicos a cualquier dominio SMTP. (ver Cómo Enviar correo electrónico a mano, Parte II: SMTP Autenticado). Esto sería el "Relay Malo"
Enredado?
En realidad es súper simple: Si yo soy el servidor de correo que sirve al dominio SMTP @empresa.org, nadie debe ser capaz de enviar correo electrónico a través mío a un dominio que no sea @empresa.org. (salvo mis usuarios autenticados).
Luego de esta larga, pero necesaria introducción sobre relay, manos a la obra.
La prueba para verificar si un servidor está permitiendo el Relay Abierto (Open Relay o Anonymous Relay), es conectarse anónimamente al servidor y tratar de enviar un correo a un dominio cualquiera de internet, distinto del dominio SMTP del servidor.
(Los detalles los puedes ver en el Artículo sobre cómo enviar correo electrónico a mano).
En este caso, el servidor de correo, al verificar que, anónimamente, estamos tratando de enviar un correo a un dominio que no es el propio, de inmediato arroja un mensaje de error (550 5.7.1 Unable to relay for usuario88@hotmail.com) indicando que no va a reenviar este mensaje.
Espero, en un próximo post mostrarles cómo se configura el servidor Virtual SMTP de un Exchange Server 2003 para conseguir este resultado.
| Update: … y en Exchange 2007 y 2010 también! |
Finalmente, no puedo dejar de mencionar que existen varias herramientas gráficas y sitios de internet a través de los cuales revisar si un servidor está permitiendo Relay, es cosa de pedirle a nuestro buscador favorito que nos encuentre "test open relay".... pero no es tan divertido como hacerlo uno mismo usando la línea de comandos, verdad? ;)
Gonzalo
|
NOTA: Este post fue publicado originalmente en mi anterior blog el
11/08/2007
|
En un artículo anterior aprendimos cómo enviar un correo electrónico a mano, es decir, utilizando solamente la línea de comandos y las instrucciones del protocolo SMTP.
La gran mayoría de los servidores SMTP del mundo piden credenciales a los clientes que tratan de enviar correos a través de ellos, cuando el correo no está dirigido al dominio SMTP de éste (algunos simplemente las exigen, como espero mostrarles en una futura sección de Antispam), por esta razón en esta segunda parte veremos cómo es el procedimiento para enviar correo electrónico autentificándonos en el servidor, es decir, entregando nuestros nombre de usuario y contraseña durante la sesión SMTP.
Los detalles sobre cómo es una sesión SMTP pueden verlos en el post sobre cómo enviar un correo electrónico a mano, por lo que ahora nos centraremos en la parte de la autenticación.
Primero, desde una línea de comandos, hay que conectarse al Servidor SMTP usando:
telnet <Servidor_SMTP> 25
Como respuesta obtendremos un banner similar a este:
Los pasos a seguir son:
1. Saludo al Servidor. Ahora, saludaremos al servidor con un comando EHLO, en vez de HELO. Esto no es dislexia (ni disteclia), sino que es una abreviación de Extended HELO ;).
En el Banner vimos que el Servidor es un Servidor que soporta Extended SMTP (ESMTP), por lo que como respuesta a este saludo, el servidor nos entregará una lista de los comandos de ESMTP que soporta.
Nota: algunos sistemas verifican que nosotros seamos realmente quienes decimos ser realizando consultas de DNS-Reverso o verificando nuestra IP en una Lista Negra, pero esos temas los veremos pronto, en los artículos de Antispam que pronto publicaré ;)
2. Ingresamos el nombre de usuario y contraseña. usando el comando AUTH LOGIN, decimos al servidor que vamos a autenticarnos usando login y password, por lo que el servidor nos responde con un amistoso: 334 VXNlcm5hbWU6 QUË?
ESMTP usa como método de codificación Base64, por lo que, salvo que seas un balazo (de)codificando en Base64, es indispensable que tengas un codificador/decodificador de Base64 a mano ;).
Luego de una búsqueda por "Base64 Decoder", nuestro buscador favorito debiese darnos al menos una respuesta, por ejemplo yo usé éste decodificador.
Ahora si …
334 es un código para indicarnos: OK, esperando Datos, y VXNlcm5hbWU6 , que es la codificación para "Username:"-.
Usando el Codificador transformamos nuestro nombre de usuario a Base64, y lo pegamos en la línea de comandos. Si nuestro login name fuese, por ejemplo: nombre.apellido, al servidor hay que ingresarle: bm9tYnJlLmFwZWxsaWRv.
La respuesta del servidor ahora es: 334 UGFzc3dvcmQ6.
334, al menos ahora ya sabemos lo que significa ;), y nuestro decodificador de base64 nos dice que "UGFzc3dvcmQ6" es la codificación para "Password:".
Necesitamos, entonces, codificar nuestro password y pegarlo para enviárselo al servidor. Si nuestro password fuese, por ejemplo: P@assw0rd, la codificación sería: UEBhc3N3MHJk.
Finalmente, si ingresamos bien la contraseña, el servidor nos entrega un mensaje de autentificación exitosa: 235 2.7.0 Authentication successful. (mmm....esta vez sin codificar? ... cómo?, y justo cuando ya nos estábamos acostumbrando al Base64... ;)
En este momento, ya estamos autenticados en el servidor, por lo que en adelante el proceso de envío de mail es el ya conocido.
3. Indicamos el remitente y destinatario(s): MAIL FROM: y RCPT TO.
Lo importante es que ahora, dependiendo de la configuración del servidor, podríamos enviar correos sin importar que el remitente y/o destinatario pertenecieran al dominio SMTP del servidor. En nuestro ejemplo, el dominio smtp del servidor es @dominio.org, pero como remitente se usó una dirección @gmail.com, y como destinatarios direcciones @gmail.com y @hotmail.com
4. Enviamos el Cuerpo del Mensaje. Usamos el comando DATA. Dentro del cuerpo del mensaje es muy recomendable incluir un nombre de destinatario (Esto le indica al servidor que comenzaremos a enviar el cuerpo del correo ("la Data").
El Servidor nos responde que podemos comenzar a enviar los datos, y que debemos presionar la secuencia Enter -> . -> Enter para indicarle que hemos terminado con el cuerpo del mensaje (Enter, luego un punto y Enter nuevamente).
En el cuerpo del mensaje se incluye una línea con el comando From: (Usuario Gonzalez), y otra con el comando subject: (mail de prueba). Estas líneas son importantes pues la gran mayoría de los servidores de correo bloquean los mensajes sin "asunto", o sin nombre de remitente por considerarlos SPAM.
|
Update: Los servidores de Correo Exchange 2007 exigen que el remitente sea una dirección de correo válida: usuario@dominio.org.
|
Luego, el Servidor nos responderá que el mensaje fue recibido correctamente, indicándonos el identificador interno que le dio al correo.
5. Cerrar la Conexión. Finalmente, debemos cerrar la sesión en el servidor con el comando QUIT. (como lo muestra la imagen anterior)
En este segundo artículo de la serie, vimos como enviar un correo electrónico autentificándonos en el servidor con nuestro nombre de usuario y contraseña usando el protocolo ESMTP.
Gonzalo
|
NOTA: Este post fue publicado originalmente en mi anterior blog el
11/08/2007
|
En una conferencia sobre Troubleshooting que dimos en el GLUE, me llamó la atención que muy pocas personas supieran enviar correos electrónicos usando sólo la línea de comandos (y no a través de un cliente de correo, como Outlook u Outlook Express). Por eso el siguiente artículo.
Muchas veces, como parte de las pruebas que realizamos para resolver problemas de flujo de correo entre servidores, luego de hacer un TroubleShooting de Redes Básico, el siguiente paso es revisar que la comunicación SMTP pueda establecerse exitosamente.
Para esto es necesario conocer un poco de "SMTP-nés".
Primero, desde una línea de comandos, hay que conectarse al Servidor SMTP usando:
telnet <Servidor_SMTP> 25
El 25 luego del nombre o dirección IP del servidor corresponde al puerto al cual estamos estableciendo la conexión, en este caso el 25 es el estándar para smtp.
Si la conexión se establece exitosamente, el servidor mostrará una respuesta consistente de un código, y un banner con su nombre, el software SMTP que está ejecutando, la versión de éste, la fecha y la hora. Un servidor SMTP MS Exchange 2003 SP2, despliega un banner similar a este:
En este punto es interesante mencionar que como respuesta a nuestros comandos (o verbos), el servidor siempre nos entregará un código numérico con la siguiente nomenclatura:
- 2XX: operación ha concluido con éxito.
- 3XX: operación aceptada, pero se esperan nuevos datos.
- 4XX: error, servidor queda a la espera que se repita la instrucción.
- 5XX: error permanente.
Los pasos a seguir son:
1. Saludo al Servidor. Como personas educadas que somos, lo que corresponde es saludar al Servidor, indicando nuestra identificación (nuestro nombre dns). El Servidor, que también es todo un caballero, nos responderá el saludo (con su correspondiente código).
Nota: algunos sistemas verifican que nosotros seamos realmente quienes decimos ser realizando consultas de DNS-Reverso o verificando nuestra IP en una Lista Negra, pero esos temas los veremos pronto, en los artículos de Antispam que pronto publicaré ;)
2. Indicamos el remitente y destinatario(s), usando los comandos MAIL FROM: y RCPT TO:, éste último más de una vez, en caso de querer enviar mail a más de un destinatario.
Nota: Los comandos SMTP no son sensibles a mayúsculas y minúsculas.
El servidor nos validó como remitentes válidos y validó al destinatario de nuestro mail (su dirección de correo electrónico) como válida, y está listo para recibir el mensaje.
3. Enviamos el Cuerpo del Mensaje. Para realizar esto le escribimos el comando DATA. Esto le indica al servidor que comenzaremos a enviar el cuerpo del correo ("la Data").
El Servidor nos responde que podemos comenzar a enviar los datos, y que debemos presionar la secuencia Enter -> . -> Enter para indicarle que hemos terminado con el cuerpo del mensaje (Enter, luego un punto y enter nuevamente).
En el cuerpo del mensaje se incluye una línea con el comando subject: (mail de prueba). Esta línea es importante pues la gran mayoría de los servidores de correo bloquean los mensajes sin "asunto" por considerarlos SPAM.
Luego, el Servidor nos responderá que el mensaje fue recibido correctamente, indicándonos el identificador interno que le dio al correo.
4. Cerrar la Conexión. Finalmente, debemos cerrar la sesión en el servidor con el comando QUIT.
En este primer artículo de la serie, vimos como enviar un correo electrónico usando sólo comandos smtp. En el Próximo Artículo veremos cómo enviar correo cuando el servidor SMTP Requiere de Autentificación.
Gonzalo
|
NOTA: Este post fue publicado originalmente en mi anterior blog el
10/08/2007
|
Cuando se está tratando de resolver un problema de comunicación, por ejemplo de flujo de correos entre servidores, lo segundo que hay que revisar (lo primero, todos sabemos: verificar que el servidor esté "encendido y con todos sus cables bien conectados" ;) ), es probar que se pueda establecer comunicación con éste. Para realizar las pruebas utilizaremos herramientas que ya vienen incorporadas en Windows.
1. Lo primero es lo Primero: Ping
Abrimos una ventana de Símbolo de Sistema (o D.O.S., o consola, o línea de comando, o shell) y escribimos:
ping <IP_Destino> -N 10
El comando ping, realiza una solicitud de echo ICMP (echo-Request) al servidor que queremos verificar. Por defecto se realizan 4 solicitudes, pero yo prefiero usando el parámetro -N <número>, darle un múltiplo de 10. Esto tiene 2 razones bastante simples:
- Si hay problemas de intermitencia en el enlace (me ha pasado con enlaces de microondas), sólo 4 ping no siempre detectan esta situación.
- Si se realiza una cantidad múltiplo de 10 es inmediato el cálculo del porcentaje de pérdida de paquetes ;)
El ejemplo anterior corresponde a un cliente que perdía la conexión con el servidor de Escritorio Remoto dónde estaba el ERP de la empresa. Este era un enlace de microondas que tenía “mal apuntada” la antena y gracias a éste (y otros muchos reportes, con más paquetes) pudimos identificar el problema.
Otra información importante que se puede sacar desde este ping es que tan rápida o lenta está la red, viendo el tiempo de recorrido redondo (roundtrip). Claramente no hay un tiempo óptimo, pues depende de las características de la red, la congestión y el ancho de banda. Aún así este valor no debiese superar los 20 ms (en el ejemplo: un mínimo de 80 y un máximo de 841 no fueron buenos números).
Finalmente se puede determinar qué tan “lejos” está el emisor del receptor del mensaje, comparando los valores del TTL.
IMPORTANTE: En el ejemplo anterior se hace ping desde el equipo cliente en la ubicación a un servidor web de una muy conocida y prestigiosa Universidad ;) . Por qué?, porque yo sé que ese servidor “SI responde PING”. Es posible que el “destino” del Ping no esté configurado para responder Ping, o que haya un firewall bloqueando las peticiones de echo, por lo que si como respuesta a un ping “no hay respuesta” esto no necesariamente indica problemas en la red o en el servidor.
2. NSLookup
En el ejemplo anterior en realidad hicimos una pequeña trampa: asumimos que el servidor DNS estaba funcionando ;)
El servidor DNS es el encargado de hacer la traducción <nombres> = <dirección IP>. En este caso: www.uc.cl = 146.155.99.60, pues en realidad, la petición de eco se hace a la IP de destino, no al <nombre>.
La herramienta más básica para revisar que el servidor DNS al cual estamos consultando esté respondiendo es nslookup, que en su forma más simple puede invocarse de la siguiente forma:
nslookup <IP_Destino>
Una posible respuesta a esta solicitud es la del siguiente ejemplo:
Las primeras líneas identifican al servidor que me está respondiendo la consulta: 192.168.8.1 y el puerto 53 (estándar para DNS)
La tercera línea indica que el servidor no es “dueño” ni “parte” de la zona DNS, por lo que su respuesta no es “de primera mano”, sino que responde “lo que sabe”.
Finalmente las últimas líneas identifican el nombre con su dirección IP. Una respuesta distinta a ésta implicaría problemas con el servidor DNS o con su capacidad para resolver (por sí mismo o preguntando a otros servidores) las consultas que se le realizan. En este caso (y como regla general), es mejor ejecutar los comandos con la dirección IP en vez del nombre.
3. Tracert
OK. Ya sabemos si tenemos, o no, pérdida de paquetes, y sabemos encontrar la dirección IP de nuestro destino. Otra herramienta muy útil en la resolución de problemas es Tracert (traceroute en sistemas basados en Unix), pues nos permite saber por dónde (por cuáles routers) pasan los paquetes mientras viajan entre el origen y el destino.
tracert <IP_Destino>
Una ejecución se muestra en el siguiente ejemplo:
La Primera columna indica el número de salto. Las siguientes 3 muestran el tiempo de respuesta del router frente a los paquetes enviados, si el resultado es un (*) simplemente indica que no se obtuvo respuesta. La cuarta columna muestra el router: nombre, si es capaz de resolverlo, o su dirección IP.
La primera línea (primer salto), si tiene el número 0, es el equipo local, si tiene el número 1 es el Default Gateway o puerta de enlace del equipo desde el cual se está ejecutando el Tracert. La última línea debiese ser el Servidor o Equipo de destino. (no siempre es alcanzable).
Una variante súper interesante de Tracert es VisualRoute, que muestra visualmente en un mapa del mundo la ubicación (aproximada, por cierto) de los routers por dónde pasa un paquete en su recorrido por la súper carretera de la información. (Se requiere JAVA)
3. PathPing
Una de mis favoritas, pues combina en una sólo herramienta las 3 anteriores :D.
pathping <IP_Destino>
El funcionamiento de pathping es más o menos el siguiente:
- Primero resuelve el nombre del destino a su dirección IP. (Nslookup)
- Luego obtiene el camino por dónde viajan los paquetes (Tracert)
- Finalmente, realiza una prueba de conectividad enviando una ráfaga de solicitudes de eco ICMP, es decir, hace ping muchas veces a cada router en el camino recién obtenido.
- Y lo mejor, despliega estadísticas sobre pérdidas de paquetes al final de la ejecución :)
En nuestro ejemplo del enlace vía microondas:
Notas:
- BORRADA corresponde a IP’s públicas reales, borradas para proteger la identidad de los implicados ;)
- Los saltos (routers) 7 y 8, destacados en otro color, presentaban pérdidas de paquetes.
- Pathping tarda un rato, alrededor de 5 minutos, en terminar de ejecutarse, debido a la cantidad de paquetes (100) que envía a cada salto, pero vale la pena esperar.
4. Notas Finales
Muchas de estas herramientas (si no todas) poseen una versión en entorno gráfico, tal vez más amigables y tal vez hasta gratis. De todas formas creo importante saber que existen y vienen junto al sistema operativo, pues a veces es a lo único a lo cual podemos echar mano.
Tip: para quienes den exámenes de certificación sobre networking, el uso de estas herramientas son preguntas seguras ;)
Otra consideración importante es que en este artículo revisamos las herramientas con sus opciones más elementales (o las que eran mis favoritas), pero todas éstas poseen muchas otras funcionalidades que son interesantes y útiles. Sólo basta con escribir el nombre de la herramienta seguido de un “/?” para descubrirlas ;)
Espero que esto les haya resultado de utilidad y que NO tengan que usarlo para resolver problemas en sus redes ;)
Gonzalo
Hoy se liberó Exchange 2010 en su versión final (RTM).
Esto quiere decir que ya está disponible para ser descargado por usuarios corporativos, personas con suscripciones technet o msdn, y por cualquier persona que quiera probarlo en los siguientes links:
Les dejo algunos links con información de capacitación gratuitos sobre Exchange 2010
Gonzalo
Jaap Wesseluis, MVP en Exchange, escribió un muy interesante libro sobre Exchange 2010, el cual está disponible para su descarga gratuita (previo registro) en el siguiente link:
La tabla de contenidos es la siguiente:
- Chapter 1: Introduction to Exchange Server 2010
- Chapter 2: Installing Exchange Server 2010
- Chapter 3: Exchange Server 2010 Coexistence
- Chapter 4: Managing Exchange Server 2010
- Chapter 5: High Availability in Exchange Server 2010
y tal como dice su título, es una presentación de Exchange 2010 desde un enfoque práctico, con muchos diagramas y aún más guías paso a paso para la implementación y configuración de Exchange 2010.
Espero que les sea de utilidad.
Gonzalo
Hace unos posts atrás les comenté sobre los Exchange Analyzers, herramientas que permiten realizar diagnóstico y análisis para facilitar la resolución de problemas (trobleshooting).
La semana pasada fue liberada la primera versión “oficial” del ExRCA. Esta herramienta, como su nombre lo dice, permite realizar diagnósticos de la conexión a los servidores Exchange de forma remota, esto es, simulando la experiencia de un usuario conectándose desde Internet a OWA, OutlookAnywhere (RPC/HTTPS) o ActiveSync.
Importante: Todos los tests son compatibles con Exchange 2010 :)
La herramienta está disponible en: https://www.TestExchangeConnectivity.com.
De las mejoras introducidas en este release final mi favorita es el OutBound SMTP Email Test, que verifica las configuraciones de tu servidor smtp de salida, desde el punto de vista un servidor de correo de destino: Revisar que no esté en (algunas) listas negras, que tenga el registro SenderID/SPF creado, etc.
Les dejo el video (subtitulado en inglés) sobre el ExRCA, cualquier semejanza con la realidad es absolutamente intencional ;)
fuente: http://msexchangeteam.com/archive/2009/10/19/452905.aspx
Gonzalo