Estoy muy contento de anunciarles que Microsoft nos convocó para hacer de una implementación de SQL 2005 un caso de éxito.
Les dejo la URL a los interesados:
http://www.microsoft.com/conosur/casosexito/caso/BolsaCereales.asp
Saludos,
Vernocchi, Pablo
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
Anteriormente había escrito sobre las distintas versiones de Exchange 2003 que se pueden encontrar en:
http://www.eseutil.net/que-version-de-exchange-elegir
Hace unos días Microsoft publicó las features y diferencias entre la version Standard y Enterprise de Exchange 2007. La info está disponible en:
http://www.microsoft.com/exchange/preview/edition_compare.mspx
Saludos,
Vernocchi Pablo
Finalmente luego de muchas expectativas de aquellos que trabajamos con Exchange llegó el momento, a fin del 2007 se liberara la versión final de Exchange 2007. Seguramente si usted no le presta atención a los nuevos lanzamientos de producto, en este momento se estará preguntando que tiene de especial esta nueva versión que no hayamos visto hasta ahora. La respuesta es simple…. TODO.
Nos encontramos ante un salto similar o incluso mayor al que vimos entre las versiones 5.5 y 2000. Pero empecemos desde el principio.
Instalando Exchange 2007.
Antes de comenzar la instalación deberemos cumplir una cantidad de pre-requisitos relacionados tanto con el hardware como con el software. Es importante recalcar que si bien existirá una versión de 32 bits disponible para pruebas, las instalaciones en producción deberán correr sobre plataformas X64, con un mínimo recomendado de 2 GB de RAM + 5 MB adicionales por usuario alojado. En este equipo se deberá instalar un Windows 2003 SP1 o R2 (obviamente 64 bits), el cual tendrá que estar unido a un dominio de Windows 2000 en modo nativo como mínimo. Adicionalmente deberemos instalar .NET Framework 2.0, Microsoft Management Console 3.0, Microsoft Command Shell (MSH) y en caso de instalar el rol de acceso a cliente necesitaremos IIS. En cuanto estos requisitos sean cumplidos podremos comenzar con la instalación de Exchange, ya sea en un único servidor o dividiendo los roles en múltiples equipos.
Divide y triunfaras.
La nueva arquitectura basada en roles dará a los administradores la posibilidad de instalar servidores íntimamente relacionados con las funciones que cumplirán en la organización, reduciendo significativamente la superficie de ataque.
Entremos un poco más en detalle, los roles pueden ser separados en 2 categorías bien definidas. Por un lado el Edge Transport o Servidor de borde y por otro los 4 roles restantes.
Edge Transport: Sera el servidor encargado de recibir los correos provenientes de Internet, en él se aplicaran los filtros de higiene relacionados con el flujo de mensajes y actuara como Relay de SMTP. Este rol es opcional.
Hub Transport: Ya sea tratando con mensajes provenientes del edge server de la DMZ o directamente desde Internet, este rol será el primer contacto del mensaje con nuestro forest. Adicionalmente será el encargado del ruteo de todos los mensajes de la organización, tanto internos como externos. Por lo tanto es el lugar ideal para configurar filtros de contenido y journaling. Este rol es requerido.
Mailbox: Como su nombre lo indica, es el rol encargado de hostear las bases de datos que serán utilizadas tanto para mailboxes como para carpetas públicas. Este rol es requerido.
Client Access: El rol de acceso a clientes será necesario si queremos utilizar OWA, ActiveSync, Outlook Anyware (RPC/http), IMAP, POP3 o web services. Este rol es opcional.
Unified Mesaging: Sera el encargado en la comunicación con la PBX para brindar servicios de llamadas a VoIP, Mensajes de voz y fax. Este rol es opcional
Como puede ver las posibilidades y combinaciones existentes para cada implementación son muchas y podrán ajustarse a las necesidades más diversas. Desde una implementación con un único servidor hasta una más compleja que incluya redundancia en todos sus roles y almacenamientos.
Ya está instalado. Y ahora?
Como no podía ser de otra manera la nueva administración de Exchange esta a la altura de los cambios de infraestructura. En esta versión Microsoft introduce un cambio radical en la administración de su producto. La nueva Exchange Management Console, mejor organizada y menos compleja que su predecesora.
Esta íntegramente basada en PowerShell, por lo tanto todas las acciones que realicemos por medio de la interfaz gráfica serán traducidas a cmdlets (comandos de powershell) que luego ser ejecutadas por un intérprete. Esto da como resultado una interfaz de línea de comandos robusta y con posibilidades de alterar todos los objetos de la organización, lo que disminuirá en gran medida las tareas de administración rutinarias, ya que podrán ser reemplazados por scripts altamente portables.
Para ir cerrando…
Definitivamente 2 hojas no son suficientes para repasar todas las virtudes de esta versión, por lo tanto me voy a limitar a simplemente a nombrar algunas características que dejamos afuera y son dignas de mención: Autodiscover, Local Continuos Replication, Cluster Continuos Replication, Messaging Records management, Address rewriting, disclaimers, Sender & IP reputation, Calendaring, Exchange Toolbox.
Espero que la sola mención de estas funciones los incite a la lectura y a seguir investigando.
Leandro Amore y Pablo Vernocchi para la revista Nexx IT