Tami Reller (CFO & CMO de Windows Division) anunció en Computex 2013 que Outlook 2013 RT estará disponible en todas las tablets con Windows RT como parte de la actualización a Windows 8.1 que estará disponible más adelante este año.
Les dejo dos artículos para más información:
>> Pablo Vernocchi
En Exchange tenemos la posibilidad de crear casillas compartidas (Shared Mailbox) para que varios usuarios puedan acceder a la misma y enviar correos bajo ese nombre.
Un ejemplo clásico puede ser una casilla para info@ o ventas@ o mismo una mesa de ayuda.
El problema que ocurre frecuentemente es que cuando un usuario A envía un correo usando la casilla B, este correo se guarda en la carpeta “Elementos enviados” del usuario A, lo que genera que ningún otro usuario que tenga acceso a la casilla compartida pueda ver qué fue lo que se envió.
Afortunadamente estoy puede configurarse. La funcionalidad de guardar los elementos enviados en la casilla compartida apareció como un hotix post SP3 de Outlook 2003, un hotfix post SP2 de Outlook 2007 y en Outlook 2010 SP1.
Outlook 2010: Email that you send on behalf of someone is not saved in their Sent Items folder
En cada uno de los links correspondientes a cada versión de Outlook está el hotfix o nivel de Service Pack necesario además de las claves de registro que tienen que modificarse para activar la funcionalidad:
Outlook 2010:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences
Outlook 2007:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences
Outlook 2003:
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Preferences
Value name: DelegateSentItemsStyle
Value Type: DWORD
Value: 1
Saludos,
>> Pablo Vernocchi
Bien, vamos avanzando parece. Kevin Allison publicó recientemente un Status Update sobre el desarrollo de los rollups con los bugs encontrados.
Exchange 2007 Service Pack 3 Rollup Update 3:
Será relanzado hoy o mañana la versión corregida, ya que está en las últimas fases de aprobación.
Exchange 2010 Service Pack 1 Rollup Update 3:
Esta actualización estaría demorada entre una y dos semanas.
La explicación completa de Kevin pueden encontrarla en http://blogs.technet.com/b/exchange/archive/2011/03/30/exchange-2007-2010-rollup-3-status-update.aspx
>> Pablo Vernocchi
En un escenario de coexistencia entre Exchange 2003 y 2007/2010, el setup de Exchange crea un nuevo Administrative Group y un nuevo Routing Group para los servidores 2007/2010. Este Routing Group es creado debido a los cambios en la estrategia de routeo intersite – intrasite que tienen las nuevas versiones de Exchange.
Ahora bien, para poder asegurar el flujo de correos entre estos Routing Groups es que se crea un Routing Group Connector (RGC). Este conector se crea durante el setup del primer Hub Transport 2007/2010.
El RGC tiene como servidores de puente (Bridgehead Servers) el primer servidor Hub Transport de la Organización y un servidor 2003 que nosotros definamos durante el setup. Es muy probable que en nuestro escenario tengamos más de un Hub Transport para darle alta disponibilidad al routeo entrante y saliente de correos. Es por eso que necesitamos agregar ambos Hub Tranports al RGC, y así asegurarnos que ante la caída de uno de ellos (ya sea por una falla o por mantenimiento) el flujo de correos desde y hacia Exchange 2003 sigua funcionando.
Dentro de Exchane 2’007/2010 veremos que existen dos RGC:
Get-RoutingGroupConnector
Uno de ellos es desde Exchange 2003 a 2010 y el otro es desde Exchange 2010 a 2003.
Para agregar un servidor de Exchange 2010 al RGC creado durante la instalación, será necesario ejecutar:
Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "E2010HubTransport01"} | Set-RoutingGroupConnector -SourceTransportServers "E2010HubTransport01",”E2010HubTransport02”
Reemplazar E2010HubTransport01 y E2010HubTransport02 por los valores correspondientes a los nombres de los servidores de transporte de Exchange 2010.
Bien, si ahora queremos agregar otro servidor de Exchange 2003, el comando debería ser similar a:
Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "E2010HubTransport01"} | Set-RoutingGroupConnector -SourceTransportServers "E2010HubTransport01",”E2010HubTransport02” –TargetTransportServers “Exchange2003A”,”Exchange2003B”
Si seguimos el paso anterior al pie de la letra, Exchange 2010 puede enviar desde dos servidores de Hub Transport hacia uno o dos servidores de Exchange 2003. Para poder configurar esto mismo, pero en el conector con dirección Exchange 2003 –> Exchange 2010, es necesario ejecutar este comando:
Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "Exchange2003A"} | Set-RoutingGroupConnector -TargetTransportServers "E2010HubTransport01",”E2010HubTransport02”
Reemplazar E2010HubTransport01 y E2010HubTransport02 por los valores correspondientes a los nombres de los servidores de transporte de Exchange 2010.
Si queremos configurar varios servidores de Exchange 2003 como origen del conector (como aneriormente hicimos con Exchange 2010, el comando sería parecido a:
Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "Exchange2003A"} | Set-RoutingGroupConnector -SourceTransportServers “Exchange2003A”,”Exchange2003B” –TargetTransportServers "E2010HubTransport01",”E2010HubTransport02”
Con estas configuraciones podemos asegurarnos que el flujo de correo Exchange 2003 –> Exchange 2010 y el flujo de correo Exchange 2010 –> Exchange 2003 es resistente a la caída o bajada de servidores por mantenimiento.
>> Pablo Vernocchi
Todavía no llegó por esta zona, pero si estás pensando en preparar tu infraestructura de Exchange para clientes con Windows Phone 7, tené en cuenta este post!
Dependiendo las políticas de ActiveSync que fueron configuradas en la organización, y asignadas al usuario, Windows Phone 7 podría encontrar algunos incovenientes al sincronizar con Exchange.
Para asegurarte que no vas a tener problema hay dos workarounds disponibles. El primero es permitir AllowNonProvisionableDevices, la segunda es sólamente configurar los siguientes items dentro de las políticas de ActiveSync:
>> Pablo Vernocchi
En las últimas horas se detectó un issue con los dispositivos iPhone, iPod Touch, iPAD que corren la versión 4 de iOS y Exchange ActiveSync.
Esta nueva versión de sistema operativo para los dispositivos de Apple agrega un cambio al timeout de request de 4 minutos a 30 segundos, e inmediatamente los dispositivos dejan de sincronizar.
Apple también advierte que los administradores de Exchange pueden notar que los servidores corran más lento.
Para corregir este bug, Apple publicó un workaround en http://support.apple.com/kb/TS3398 y publicará la corrección definitiva en una actualización (nuevo release), que no tiene tiempo estimado de lanzamiento aún.
>> Pablo Vernocchi
Estaba ejecutando un proyecto en un cliente, cuando lanza la pregunta…:
La defragmentación (offline) de las bases de datos:
El proceso de defragmentación offline no es una tarea trivial. Para empezar es necesario bajar las bases de Exchange antes de ejecutarla.
Por otro lado, el proceso de defragmentación lee la base original y copia los datos a una nueva base. Luego reemplaza la nueva base (desfragmentada), reemplazando la original. Este paso no es gratuito. Al crear una nueva base, también tenemos nuevos signatures para esa base. Todos los transaction logs están asociados a la base por este signature. Por lo tanto, si tenes que hacer un restore de la base, con una copia de seguridad anterior a la desfragmentación, seguramente no seamos exitosos en la tarea. Las signatures no van a coincidir, y los Transaction logs no se van a aplicar a la base.
Quizás esa sea la razón principal por la que el defrag offline no se debe incluír como una tarea frecuente.
Sin embargo, si necesitaramos ejecutar el defrag, sí o sí necesitaremos un buen full backup!
Más allá de las recomendaciones, sí es neceario desfragmentar las bases de datos luego de ejecutar una reparación de la misma ya que no está soportado tener una base reparada en producción (recuerden que al desfragmentar se genera una nueva base).
También es recomendado desfragmentar cuando estamos usando las versiones estándar de Exchange 5.5/2000/2003 y llegamos al límite de la base de datos (16 GB para 5.5/2000 y 75 GB para 2003).
Así como también se debe desfragmentar si tenemos algún problema con la base de datos que se solucione con el defrag de la misma.
Por otro lado, como regla general y si necesitamos el espacio en el disco, podemos desfregmentar la base de datos cuando el evento 1221 del Event Viewer indica que podemos recuperar más del 30% del tamaño de la base.
Les recomiendo esta lectura adicional sobre espacios blancos en la base y el evento 1221:
http://blogs.msdn.com/jeremyk/archive/2004/04/09/110553.aspx
Saludos,
>> Pablo Vernocchi
Andrés Lozada está preparando una maratón con 7 capítulos para la migración de Exchange 2010, desde Exchange 2003.
Empiezan esta semana!!
Mayo Jueves 13
Webcast TechNet: BYE BYE Exchange 2003 N°1 (Entendiendo los pasos para una Migración y Coexistencia Exitosa)
Mayo Martes 18
Webcast TechNet: BYE BYE Exchange 2003 N°2 (Preparando Directorio Activo)
Mayo Jueves 20
Webcast TechNet: BYE BYE Exchange 2003 N°3 (Instalando Exchange Server 2010 Consolidado)
Mayo Martes 25
Webcast TechNet: BYE BYE Exchange 2003 N°4 (Instalando Exchange Server 2010 Extendido)
Mayo Jueves 27
Webcast TechNet: BYE BYE Exchange 2003 N°5 (Configurando Exchange Server 2010)
Junio Martes 1
Webcast TechNet: BYE BYE Exchange 2003 N°6 (Migrando Buzones)
Junio Jueves 3
Webcast TechNet: BYE BYE Exchange 2003 N°7 (Eliminando Exchange 2003)
No te los pierdas!
>>Pablo Vernocchi
Hace un tiempo ya que este mecanismo de Spamming es frecuente, junto con otros como por ejemplo el Spam de NDRs. Lo que pretendo explicar en este artículo son dos estrategias que podemos implementar para evitar el correo no deseado (SPAM) con direcciones de correo de nuestro propio dominio. Ambas se pueden implementar por separado, o en conjunto.
Este primer método consiste en implementar SenderID. Esta tecnología anti spam permite a los administradores crear un registro en el DNS público donde se declaran las direcciones IP de los servidores de mail que pueden enviar correos para nuestro dominio. De esa manera sería la primer configuración para evitar lo que comunmente se denomina domain spoofing.
Este método no sólo evita que recibamos SPAM de nuestro propio dominio, sino que también sirve para evitar SPAM y virus de otros dominios.
Nosotros tenemos que configurar el DNS para que los antispam de terceros puedan validar este registro, y también para nosotros mismos.
Sencillo. Existen distintos websites con asistentes para la creación del registro TXT. A continuación les paso los que más frecuentemente uso:
No es necesario tener creado el registro TXT para que Exchange utilice la comprobación de SenderID, pero sí es necesario si queremos evitar recibir correos de SPAM de nuestro dominio.
Para habilitar las comprobaciones, es necesario habilitar el filtro AntiSpam de SenderID. Para ello, dentro de la consola de administración de Exchange, vamos a Global Settings –> Message Delivery –> Properties
Dentro de las propiedades, seleccionamos la solapa Sender ID Filtering y seleccionamos la opción Reject. De esa manera, todos los correos que no pasen la validación no ingresarán a nuestro sistema:
Por último, tenemos que asegurarnos que en el SMTP Virtual Server se estén ejecutando las validaciones de Sender ID. Para ello, debemos ingresar a las propiedades del SMTP Virtual Server que está de cara a Internet (por las dudas que tengamos más de uno):
Entrar a la sección Advanced:
Y asegurarnos que esté marcado Sender ID Filtering o marcarla nosotros:
En el caso que la infraestructura no cuente con un Edge Transport Server, primero debemos instalar los agentes de Antispam. Para ello pueden seguir los pasos descritos en este artículo: Cómo instalar los agentes Antispam en un Hub Transport. Si ya contamos con un Edge, no hace falta este paso.
Dentro de la consola de Exchange, ir a Organization Configuration –> Hub Transport. Luego ir a la solapa Anti-Spam y seleccionar el filtro Sender ID.
Seleccionar la opción Reject message de la lista:
De esa manera, tanto en Exchange 2003, 2007 o 2010 estaremos evitando la entrada de mensajes de SPAM enviados con cuentas ficticias de nuestro propio dominio. En la segunda parte, cubriremos una alternativa para hacerlo con permisos en el receive connector y sin agentes AntiSpam.
>>Pablo Vernocchi