Archivo

Archive for the ‘Exchange’ Category

Uso de In-Place E-Discovery and Hold

Muy buenas tardes. Hace un tiempo atrás hice una sesión para channel9 en donde conversamos acerca de las caracteristicas de E-Discovery e In-Place Hold.

Para poder ver la sesión pueden entrar a https://channel9.msdn.com/Series/Latam-CloudSeries/Office-365-Retencion-de-correos

Espero que les agrade.

Saludos!!

 

Categorías:Exchange, Office 365

Elevando el nivel funcional de tu dominio? lee esto antes de comenzar

Elevar el nivel funcional de un dominio es un proceso simple de realizar que no debiese requerir mayor planeamiento que evaluar el impacto de las aplicaciones legacy que pudiesen requerir un nivel funcional inferior.

Sin embargo a veces esto no es del todo cierto… Si vamos a elevar nuestro nivel funcional desde Windows Server 2003 a Windows server 2008/2008R2/2012/2012R2 debemos considerar que la contraseña del servicio KRBTGT (Key distribution service center account) será reseteado.

Si bien esto generalmente no tiene mayor impacto (incluso es parte de nuestro procedimiento de recuperación de desastres) sobre las aplicaciones, hay situaciones en las que las aplicaciones que consumen nuestro dominio de ActiveDirectory no pueden autenticar a los clientes conectados (Hello Exchange!!).

Debido a esto debemos tener la siguiente precaución al elevar el nivel funcional de nuestro dominio:

 

1. Luego de elevar el nivel funcional, debemos conectarnos a nuestro servidor de Active Directory de Windows Server 2003 en busca de los eventos EventID 14 KDCEVENT_NO_KEY_INTERSECTION_AS (Microsoft-Windows-Kerberos-Key-Distribution-Center) y EventID 10 KDCEVENT_KRBTGT_PASSWORD_CHANGE_FAILED (Microsoft-Windows-Kerberos-Key-Distribution-Center).

2. Si no vemos estos eventos logueados luego de unos minutos (asegurense que hay usuarios iniciando sesión o utilizando Exchange…), debemos realizar nuestras pruebas para asegurarnos de que esta todo bien.

 

3. Si vemos estos eventos… mala suerte en el trabajo, buena suerte en el amor (o algo así), debemos resolver nuestro problema de autenticación de usuarios simplemente reiniciando el servicio de KDC en todos nuestros controladores de dominio.

 

¿Como?

  • Opción 1: Debemos ir a la consola de servicios (Services.msc) y reiniciar el servicio Kerberos Key Distribution Service.
  • Opción 2: Utilizar una consola de comandos (CMD) con permisos administrativos y ejecutar la linea “SC \\ComputerName Stop kdc” (en donde ComputerName es nuestro controlador de dominio) y luego “SC \\ComputerName Start kdc”.
  • Opción 3: Utilizar Powershell “Get-Service KDC –ComputerName Computer | Restart-Service” (en donde Computer es nuestro controlador de dominio).
  • Opción 4: Utilizar Powershell y hacer el cambio masivo en todos los controladores. Personalmente no recomiendo esta opción ya que podría dejar usuario sin servicio durante el reinicio de los servicios (valga la redundancia). Siempre es mejor realizar el proceso de manera manual. Pero sin son Vikingos y no le temen a nada, esta sería la forma de hacerlo:
    • Abrir un Windows Powershell con permisos administrativos
    • $DC=Get-ADDomainController
    • Get-Service KDC –ComputerName $DC | Restart-Service

Happy updates!!

Cambio de Hora en Chile – Nueva zona horaria –03:00

En Chile acabamos de pasar de una zona horaria Santiago –04:00 a Santiago –03:00 en orden de eliminar los cambios generados por el horario de verano (que atrasaba o adelantaba en una hora para el ahorro energético).

Si bien hemos pasado por muchos periodos de reacondicionamiento de la fecha en la que realiza el cambio de hora, es la primera vez que nos cambiamos de huso horario, al parecer, de manera definitiva. La razon de esto es que el Gobierno de Chile a definido que el ahorro energético se ha vuelto marginal y por otro lado, los sistemas se han vuelto cada vez más complejos en cuanto a su requerimiento de “perfeccion horaria”, por lo que estos cambios, generan impacto negativo en muchos negocios.

 

El cambio de hora y zona horaria, si bien no debiese impactar mayormente las aplicaciones ya que estamos en la misma hora que la definida en el huso horario –03:00, si tiene factores estéticos y de funcionalidad entre sistemas que piensan que nuestro huso horario es –04:00 y otras que piensan que es –03:00.

Debido a esto, les resumo la situación de Exchange y Outlook:

 

________________________________________________________________

ACTUALIZACION

Ya fue liberado el Rollup Update nro 9 para Exchange 2010 con Service Pack 3 que incluye, entre otras cosas, la actualizacion para la zona horaria de Chile y Mexico.

Pueden descargar el RU9 desde el siguiente Link: https://support.microsoft.com/en-us/kb/3030085 

Importante 1: Si los servidores de Exchange tienen  Spanish Chile en sus Regional Settings (configuración regional) el RU9 no se instalará correctamente. Es necesario cambiarlo a English United States para que no tengan problemas.

Importante 2: Al instalar la actualización es posible que las agendas tengan problemas con la hora de la cita. Para esto deberán seguir el instructivo de corrección detallado en: https://support.microsoft.com/en-us/kb/3048372 

________________________________________________________________

 

 

Windows Server y Desktop: Información detallada en http://support2.microsoft.com/gp/cp_dst/es-cl. Lo único que deben hacer los usuarios es instalar el hotfix http://support.microsoft.com/en-us/kb/3039024/es-cl disponible para todas las plataformas actuales de Windows Server y Windows Desktop (Si, XP tambien está incluido 🙂 )

 

Microsoft Exchange Server 2010/2013: Se está liberando una nueva actualizacion acumulativa (la nro 8) para Exchange 2013 que ya incluye el cambio en la zona horaria de Santiago. Esperen una próxima actualización acerca del rollup update para Exchange 2010.

 

Clientes Outlook: Los clientes Outlook utilizan la llave de registro de Windows asociada al TimeZone para leer su información de zona horaria, por lo que en este caso si ya está instalado el update no deben realizar ningún paso posterior.

 

Clientes OWA: Los clientes de OWA verán aún en Exchange la información de zona horaria en –04:00 en vez de –03:00, sin embargo el servidor utiliza la informacion del registro para actualizar la informacion de la agenda, por lo que es posible que haya una disparidad entre dos usuarios con calendario compartido, pero si todos los servidores (incluyendo los extranjeros) están actualizados, se debiese ver la hora correctamente.

Adicionalmente al crear un nuevo usuario, la primera vez que ingrese a OWA y le sea preguntado su zona horaria, verán Santiago –04:00.

 

Clientes ActiveSync: El mismo síntoma que los usuarios de OWA, aunque menos notorio, ya que activesync no permite ver calendarios compartidos.

 

Clientes POP e IMAP: No se verán impactados por el problema.

 

En el caso de otras aplicaciones, no hay información aún al respecto, pero nos encantaría oír sus comentarios. Así que sientanse libres de comentar y trataré de responder lo antes posible.

 

Happy updates!!

Conceptos generales sobre bases de datos de Exchange

Hay tareas sobre bases de datos que todo buen administrador de Exchange debe tener conciencia y conocimiento acerca de su significado y ejecución. Normalmente la diferencia entre conocer estos puntos y no conocerlos, puede significar que una tarea de recuperación de 10 minutos nos tome horas y horas, con un resultado a veces poco prolijo y con un alto descontento por parte de los usuarios.

Debido a esto, como PFE a veces nos toca la tarea de evaluar el conocimiento de un administrador en los procesos de administración y mantención de una base de datos. Asi que presten atención y prueben los siguientes puntos en laboratorio Smile

 

Resetear la secuencia de los logs de transacciones de una base de datos:

Es un proceso que anteriormente se ocupaba debido a que el log de transacciones de una base de datos era consumido rápidamente, lo que significaba que una base de datos al llegar al número máximo de logs posibles, fallara y se desmontara.

Actualmente no es un proceso que ocurra generalmente, pero en caso de ser necesario, se puede realizar de la siguiente forma:

1. Desmontar la base de datos

2. Asegurese que la base de datos ha sido desmontada satisfactoriamente utilizando el comando eseutil /mh Database_File_Name (Debiese encontrar como resultado Clean Shutdown)

3. Mueva los logs de transacciones de dicha base de datos a otra ubicación.

4. Vuelva a montar la base de datos.

Nota: este cambio hace imposible la restauración de las copias incrementales de una base de datos, por lo tanto se recomienda que se realice un nuevo respaldo de las bases de datos cuando sea posible.

 

Validar que un log de transacciones esté contiguo:

Para verificar que uno cuenta con todos los logs de transacciones de una secuencia, se puede ejecutar el siguiente comando:

eseutil /ml Enn (en donde nn corresponde a los dos primeros números del log de transacciones, el cual es un prefijo que se asocia al set de logs que está asociado a una determinada base de datos)

Si falta algún log de transacciones, podrá observar un error como este:

Missing log file: Enn00000004.log

Operation terminated with error -528 (JET_errMissingLogFile,Current log file missing))

Verificar que un log de transacciones está en un estado consistente:

Para verificar que un log de transacciones está en un estado consistente, puede ejecutar la siguiente variación del comando anterior:

eseutil /ml Enn0000000X.log (en donde Enn000000X.log corresponde al log de transacciones que se desea investigar)

Verificar el estado de una base de datos:

Para verificar el estado de una base de datos, puede ejecutar el siguiente comando:

Eseutil /mh Database_File_Name

Debiese encontrar la línea state con una de estas dos opciones:

Clean Shutdown: La base de datos ha sido desmontada correctamente, por lo que es posible montarla.

Dirty Shutdown: La base de datos no ha sido desmontada correctamente, por lo que es necesario utilizar los logs de transacciones o medidas de reparación para llevar la base de datos a un estado consistente.

 

Diferencias entre Soft/Hard Recovery y Repair

Una recuperación o recovery es el hecho de insertar logs faltantes dentro de una base de datos. Si Exchange detecta que una base de datos está en un estado inconsistente, es posible que intente de manera automática realizar un replay de los logs para dejar la base de datos en un estado consistente al momento de intentar montarla, sin embargo a veces es necesario realizar este procedimiento utilizando Eseutil. Estas dos opciones son llamadas soft recovery.

En el caso que se realice una recuperación desde un respaldo de la base de datos, y sea necesario hacer el replay de los logs utilizando Eseutil y el archivo Restore.env, esto es llamado Hard Recovery.

Si la base de datos está corrupta y no es posible recuperar la información desde un respaldo o a través de los logs, se hace necesario realizar una reparación o repair, utilizando Eseutil con el switch /P.

A continuación podrá ver algunos ejemplo de cuando y como ejecutar estos comandos.

Realizar un Soft Recovery de una base de datos desde la consola de comandos:

Un soft recovery es el proceso en que ocurre un replay de los logs de transacciones cuando Exchange vuelve a montar una base de datos o cuando es necesario hacer el replay de los logs existentes a una base de datos desmontada a través de línea de comandos.

Si el archivo de checkpoint (Enn.chk) no está presente durante la recuperación, el proceso realizará un barrido de todos los logs disponibles hasta encontrar los faltantes. De esta forma, es recomendado que cuente con el archivo de checkpoint para reducir el tiempo de ejecución de la herramienta.

La sintaxis completa para ejecutar un soft recovery usando ESEUTIL es la siguiente:

Eseutil /R Enn /L Log_Files_dir /S Checkpoint_file_dir /D Database_file_path

Realizar un Hard Recovery de una base de datos desde la consola de comandos:

Un hard recovery es el proceso en que ocurre un replay de los logs de transacciones cuando desde Exchange se vuelve a montar una base de datos que ha sido restaurada desde un respaldo o cuando es necesario hacer el replay de los logs desde línea de comandos manualmente usando ESEUTIL hacia una base de datos que ha sido recuperada y que esta offline.

Una restauración desde un respaldo genera un archivo Restore.env que es utilizado de manera similar al checkpoint para definir los logs que serán requeridos para llevar la base de datos a un estado consistente.

Si necesitase ejecutar de manera manual este proceso, la sintaxis completa para ejecutar un hard recovery usando ESEUTIL es la siguiente:

Eseutil /CC Temp_files_path (Temp_files_path es el directorio temporal que se definió en la herramienta de respaldo para colocar los archivos que fueron restaurados)

Nota: Para verificar que log exacto requiere para llevar a modo consistente la base de datos puede ejecutar el comando Eseutil /CM Temp_files_path

Realizar una reparación de una base de datos desde la consola de comandos:

En el caso en que no cuente con los logs de transacciones para poder recuperar una base de datos, puede que sea necesario realizar una reparación de la misma utilizando el eseutil junto con switch /P. Tenga en consideración que este comando analiza cualquier página que este dañada y la descartará. De esta forma puede existir pérdida de información, por lo que este comando debe ser utilizado como última opción.

Si necesitase ejecutar este comando, la sintaxis es la siguiente:

Eseutil /P Database_file_path

Se recomienda realizar un respaldo de la base de datos a reparar antes de ejecutar la acción, mantener el doble de espacio disponible en el disco desde donde ejecutará la herramienta (ya que se generará una base de datos temporal) y tomar en consideración que este procedimiento es el que toma más tiempo de ejecución.

Categorías:Exchange

Liberado el Service Pack 1 para Exchange 2013

Al fin nuevas cosas traen los vientos del grupo de producto de Exchange!!, hace mucho que estabamos esperando la salida del Service Pack 1 para Exchange 2013, el que trae, adicional a las actualizaciones acumulativas una serie de nuevas mejoras como:

 

  1. Aparece el rol de EDGE para Exchange 2013. Antiguamente para tener este rol debiamos ocupar un servidor Legacy de Exchange 2010 EDGE. Ahora, si bien esta opción aún esta completamente soportada, para nuevas implementaciones ya podremos hacerlas de manera nativa con 2013.
  2. Mejoras en las políticas de DLP y su uso en OWA!
  3. DLP Document fingerprint. Esta nueva caracteristica permite utilizar informacion como plantilla y prevenir que, por ejemplo, documentos sensibles se filtren a través de correo electrónico.
  4. S/MIME en OWA. Nada que decir, esta característica hace tiempo que estaba siendo pedida por los consumidores y al final la tenemos presente.
  5. Soporte para Active Directory con nivel funcional de la foresta y dominio Windows 2012 R2. Esto tambien se añade al RU13 para Exchange Server 2007 SP3 y RU5 para Exchange Server 2010 SP3.
  6. MAPI/HTTP. Exchange 2013 SP1 introduce un nuevo método de comunicacion llamado MAPI sobre HTTP que permite alivianar la carga RPC sobre los servidores y aislar los métodos de comunicación. Esta característica viene deshabilitada por defecto permitiendo al administrador decidir si desea o no habilitarla. Clientes anteriores, como Outlook 2010 y 2013 sin SP1 seguirán conectándose utilizando RPC/HTTP. Les recomiendo que den una lectura a la siguiente información: http://technet.microsoft.com/library/dn635177(EXCHG.150).aspx
  7. DAGs sin access points. Esto viene desde muchísimos años atormentándonos!!!… No en realidad no, pero es una excelente capacidad de Windows Server 2010 R2 clúster que nos permite no configurar una IP/nombre de servicio para el DAG. Esto facilita muchas cosas ya que anteriormente muchos casos levantados a soporte han sido causados por mala configuración del cluster y failovers que nadie entiende por que sucede y son generados por una mala dependencia de estos recursos. Prontamente un post dedicado a este punto! 
  8. Muchas más!!!!

 

 

Más información y la totalidad de las nuevas características en: http://blogs.technet.com/b/exchange/archive/2014/02/25/exchange-server-2013-service-pack-1-available.aspx

Categorías:Exchange Etiquetas:

RU 5 para Exchange 2010 y RU 13 para Exchange 2007 liberados

Una buena noticia para todos es que el grupo de Exchange ha liberado nuevas actualizaciones para Exchange que resuelven varios problemas reportados por clientes.

 

Pueden descargar su correspondiente actualización desde:

  • Update Rollup 5 for Exchange Server 2010 Service Pack 3
  • Update Rollup 13 for Exchange Server 2007 Service Pack 3

     

    Un punto importante es que siempre antes de actualizar nuestros servidores, debemos tener un plan de actualización revisado y de preferencia, probado antes en laboratorio.

    Un punto importante para la actualización de Exchange Server 2007 es que agrega los nuevos cambios de hora alrededor del mundo.

    Fuente: http://blogs.technet.com/b/exchange/archive/2014/02/25/released-update-rollup-5-for-exchange-2010-service-pack-3-and-update-rollup-13-for-exchange-2007-service-pack-3.aspx

    Categorías:Exchange Etiquetas:

    Se anuncia la próxima salida de Exchange 2010 SP3

    Cuando salió Exchange 2013, muchos se preguntaron por que no se podía probar la solución en un ambiente mixto con Exchange 2010. La razón viene de la mano del Service Pack 3 de Exchange 2010. Con este nuevo Service Pack, se añaden las herramientas necesarias para que funcione este ambiente mixto sin problemas.

    Adicionalmente se agrega la posibilidad de instalar Exchange 2010 sobre Windows Server 2012, con las ventajas que esto significa.

    Como punto final, se añaden todas las actualizaciones y parches que han aparecido para Exchange 2010, por lo que si tienes un servidor a media parchar… el SP3 será un buen momento para ponerse al día 🙂

    La fecha de salida es para la primera mitad del 2013, por lo que aún tenemos tiempo para prepararnos leyendo como actualizar nuestros DAG:

    http://technet.microsoft.com/en-us/library/ee861125.aspx

    o leyendo los pasos previos a la instalación de cualquier Rollup Update, ya que este procedimiento aplica también par ala actualización de Service Pack:

    http://technet.microsoft.com/en-us/library/ff637981.aspx

    Adicionalmente debemos tener precaución a nivel de Active Directory, ya que este SP realiza una modificación de esquema. Debido a esto es recomendado tomar las precauciones del caso ya que este proceso es irreversible:

    http://technet.microsoft.com/en-us/library/cc759633(v=WS.10).aspx

    Aun no hay mucha información detallada, así que ojalá tengamos más información y nuevas capacidades luego 🙂

    Fuente: http://blogs.technet.com/b/exchange/archive/2012/09/25/announcing-exchange-2010-service-pack-3.aspx

    Categorías:Exchange