Grupo de soporte de Microsoft Exchange y Mensajería Unificada de España

El caso curioso del Outlook que organizaba los correos dentro de carpetas

Madalina Florea — Thu, 03 Jan 2019 11:43:02 GMT

Hola @ todos, Recientemente hemos tenido un caso curioso en el cual una usuaria se quejaba de que los correos le desaparecían del Inbox y se reorganizaban solos dentro de las carpetas. Tras mucho troubleshooting lo que habíamos visto es lo siguiente:

Se había revisado el buzón para reglas corruptas y/u ocultas, pero el problema seguía (no había ninguna).
El dispositivo móvil se le había desconectado durante semanas y el problema seguía reproduciéndose
La máquina se había cambiado por otra con otra imagen distinta.
El antivirus se había deshabilitado pero los correos aleatoriamente seguían recolocándose en varias carpetas.
En los logs de auditoria se podía ver que los cambios se habían hecho desde la propia maquina cliente y con el mismo usuario.
Usando MFCMAPI y verificando los atributos de PR_LASTMODIFIER Y PR_LAST MODIFICATION_TIME, la cuenta que había hecho los cambios aparecía como la cuenta que lo había enviado y no la usuaria.

En este momento dado que no podíamos explicar el comportamiento nos hemos enfocado en como se realizaba el envío. La usuaria, era una de 2 secretarias que recibían correos a una cuenta compartida de la cual se realizaba un envío a una lista de distribución para que ambas secretarias recibieran el correo. De las dos secretarias, el problema solo pasaba en una de las dos cuentas. También las dos secretarias solían responder a los correos poniendo en copia oculta a la otra para poder saber a qué correos se ha respondido. La secretaria que tenía el problema solía organizar sus correos en carpetas en función de contenido del correo manualmente. Este setup nos llamó algo la atención y revisando la cabecera del correo hemos visto la siguiente cabecera: X-MS-Exchange-Processed-By-BccFoldering: Este agente (BCCFolderingAgent) funciona de la siguiente forma:

El agente detectará si se envió un mensaje a un destinatario en BCC.
Si el destinatario ha movido el mensaje anterior en este hilo a una carpeta diferente a la Bandeja de entrada (ya sea manualmente o por una regla), el agente moverá el mensaje BCC actual a la misma carpeta.
Mantendrá el mensaje en la Bandeja de entrada, siempre y cuando el mensaje anterior del mismo hilo esté en la bandeja de entrada, elementos enviados, en elementos eliminados o si el remitente es el mismo que el destinatario.

Para deshabilitar el agente en entornos de Exchange on-premises podemos utilizar el siguiente comando: New-SettingOverride DisableBCCFolderingAgent -Component MailboxTransport -Section StoreDriverBccFolderingAgent -Parameters @('Enabled=false') -Reason "Custom override to disable BCCFolderingAgent" Aquí tenéis más información sobre el cmdlet: New-SettingOverride. El override va a realizar modificaciones en AD y se va a aplicar para todos los servidores (es un cambio a nivel de organización). Si quieres solo hacer la modificación en un servidor vas a necesitar utilizar el switch de “-server”. Para asegurarnos que los cambios se han aplicado lo antes posible se puede ejecutar el siguiente comando, aun así los cambios tardaran en reflejarse unos 15 minutos (dependiendo de vuestra infraestructura y lo que tarde en replicar en AD): Get-ExchangeDiagnosticInfo -Server <servername> -Process MSExchangeDelivery -Component VariantConfiguration -Argument "refresh" Para revertir los cambios podemos ejecutar el siguiente comando: Remove-SettingOverride DisableBCCFolderingAgent Espero que la información haya sido de utilidad! Madalina y Juan

Teams WebApp – Cuando se añade una nueva pestaña tipo web, con una URL a un SharePoint, no funciona. IFrames y Clickjacking

Marta Gomez Quiza — Thu, 03 May 2018 16:45:41 GMT

Hoy quiero compartir con vosotros uno de los casos que más quebraderos de cabeza me ha dado últimamente y, como casi todo, resultó tener una solución más sencilla de lo esperado. En este caso en particular se quería publicar, en uno de los grupos de Teams, la intranet de la empresa, creada en SharePoint Onprem 2013. Me gustaría destacar que Microsoft Teams es un producto exclusivo de la nube de Office 365 y está optimizado para trabajar con el resto de productos Online. La integración de bibliotecas de SharePoint Onprem con Microsoft Teams no está soportada. No obstante, no se trata de asociar una librería si no de linquear una dirección de un SharePoint, publicado externamente, que se comportaría como cualquier otro sitio web.

Ejemplo de creación de una pestaña web

Como podéis ver en la ultima de las imágenes este blog carga perfectamente. Para reproducir el problema voy a añadir una nueva pestaña, tipo web, a muestro Teams de prueba y usaré la dirección de la página principal de Microsoft.

Y Opps! Aquí encontramos nuestro problema. “Si su sitio no se carga correctamente, haga click aquí”

Cuando clicamos en el enlace vemos las siguientes opciones.

Ver el sitio en su aplicación de escritorio. Si seguimos este enlace y accedemos a la aplicación la página se cargará correctamente.
Ir al sitio web. La página se cargará correctamente
Volver a cargar esta ficha. El error permanecerá.

Con una traza de Fiddler podemos ver algo muy interesante: La página está se carga pero no se renderiza. En la siguiente imagen podéis ver como se recibe un código 200 como respuesta y como la web está presente, pero por alguna razón TeamsWebApp no es capaz de mostrarla.

¿Por qué se carga en la aplicación de escritorio y no en la web? ¿Qué diferencia existe entre ellas?

Múltiples, desde luego. Pero la diferencia que nos atañe en ese caso es que la aplicación de escritorio trabaja con Webviews mientras que Teams WebApp lo hace con IFrames. Esto sucede porque SharePoint, y muchas páginas de Microsoft, evita por defecto el IFRAMING de páginas entre dominios como medida de seguridad para evitar el clickjacking. El clickjacking es un ataque web donde se engaña a la victima para que haga clic en un enlace o elemento que no tenía la intención de visitar o pulsar. Una de las formas que tienen las paginas defenderse de este ataque es evitar que se carguen Iframes.

Como permitir los Iframes en Sharepoint.

Abrir Sharepoint Designer (El clásico, no wiki/sitepage)
Modificar la Master Page para el sitio.
En la sección de body añadir la líena
Guardar el archivo.
Refrescar la página de Sharepoint en Teams. Es posible que se obtenga un error inicial con un enlace a la página de mantenimiento apareciendo ?Conttents=1 al final de la URL. Aparecerá un cuadro que pondrá “Allow Framing page”. Cerrando esa página y debería estar solucionado.

Resumen de las novedades de Microsoft Teams en Febrero 2018.

Marta Gomez Quiza — Mon, 02 Apr 2018 10:43:16 GMT

Cada semana Microsoft Teams va sacando nuevas funcionalidades. Aquí os dejo en el resumen de las que han aparecido en este pasado mes de febrero.

Restaurar un canal borrado.

Esta es una posibilidad que se venía pidiendo desde hace mucho tiempo y por fin está implementada. Desde ahora ya puedes restaurar Teams Channels desde la interfaz. Eso si, no se pueden restaurar canales que hayan sido borrados en un periodo superior a 21 días.

Localización de los datos de Teams desde el Centro de Administración de Office 365.

Ya puedes conocer donde están lubicados tus datos de Teams desde el Panel de Administración.

Acceso anónimo a reuniones.

Permite enviar una invitación de reunión a cualquier persona con un correo válido (Outlook, Gmail.. ) Esta persona recibirá un correo con las instrucciones para unirse a la reunión sin la necesidad de descargarse el cliente, A no ser que necesiten hacer uso de otras características, como compartir escritorio.

Sala de espera en reuniones donde hay participantes de nuestra empresa.

Los participantes anónimos ahora tienen una sala de espera virtual donde esperar a que la reunión empiece. De esta forma, los organizadores podrán unir a los invitados externos cuando lo deseen.

Iniciar una llamada de Teams desde un enlace.

Ya se puede inciar una llamada de Teams cuando haces click en un link (En una página web, por ejemplo)

Compartir el Historial de Conversación.

Ahora, cuando añades a alguien en un grupo chat, también puedes añadir el historial de conversación. En el momento de añadir un nuevo usuario aparecerán las opciones para poder añadir, o no, el historial.

Silenciar un chat.

Esta característica permite poner en pausa las notificaciones, de manera temporal, para un chat en particular. Seguirás recibiendo mensajes, pero no te aparecerán las alertas. Funciona tanto en conversaciones individuales, grupos y reuniones.

Respuesta rápida a las notificaciones de una conversación.

Ya se puede responder directamente a los mensajes en la misma ventana de notificación.

Novedades en Microsoft Teams en dispositivos Móviles.

Plataforma	Característica	Descripción
Android, iOS	Ocultar chat	Oculta antiguas conversaciones para ordenar la lista de chats. Puedes encontrarlos de nuevo usando la búsqueda.
Android, iOS	Desactivar chat	Silenciar temporalmente conversaciones que no estás siguiendo ahora mismo.
Android, iOS	@mention de chat	Captar la atención de alguien, o de todos los usuarios, con una @mencion en las conversaciones de grupo
Android, iOS	Wiki	Wiki está ahora disponible en teléfono móvil.
Android, iOS, WP	Solución de errores y mejoras generales de rendimiento	Nuevas correcciones y añadiendo mejoras de rendimiento.

Resumen de las novedades de Marzo en Teams.

Marta Gomez Quiza — Mon, 02 Apr 2018 10:42:54 GMT

Nuevas características añadidas en Teams durante el mes de Marzo.

Nueva pestaña para gestionar tareas y proyectos.

Ya se puede integrar MeisterTask con Teams. Para poder añadirlo como pestaña a uno de nuestros grupos podéis hacer clic aquí o ir a la Store > Top picks.

Nuevos idiomas soportados.

Teams ahora soporta Rumano, Indonesio y Vietnamita.

Más canales por equipo.

Se puede crear hasta 200 canales por equipo (incluyendo los canales borrados)

Acceso a invitados.

El acceso a invitados se ha extendido a todo aquel que tenga una dirección electrónica válida. Desde ahora, cualquiera con correos como Outlook o GMail pueden ser añadidos a los equipos. Esta es una de las características mas deseadas, que por fin es una realidad en Teams.

Mejora en las notificaciones de llamada.

Si ya ves el símbolo Llamadas en la parte izquierda de Teams, empezarás a ver las notificaciones de llamadas perdidas y nuevos mensajes de voz. Selecciona la notificación de llamada perdida y ve a la pestaña de “Historial de Llamadas” para poder devolverla. Haciendo clic en la pestaña de “Voicemail” podrás escuchar los mensajes. Si todavía no ves el símbolo Llamadas y clicas en una notificación de llamada perdida te llevará directamente a un chat con el llamante, sin poder pudiendo iniciar desde allí una conversación o devolver la llamada.

Transición de Skype for Business Online a Microsoft Teams – Introducción

Marta Gomez Quiza — Mon, 02 Apr 2018 10:42:32 GMT

Estáis leyendo mi primer artículo en este blog ¡Bienvenidos seáis! Mi nombre es Marta y formo parte del Soporte Comunicaciones Unificadas Premier de Microsoft desde agosto del 2015. Como esto es un comienzo para mi, en esta primera entrada me gustaría hablaros de otro comienzo más: La transición de Skype for Business Online a Microsoft Teams. Teams está en crecimiento, adquiriendo nuevas características y funcionaliddes mes a mes. Podéis consultar el estado de las actualizaciones en el Roadmap de Office 365 (EN)

¿Qué es Microsoft Teams?

Destacar la cultura de integración y la productividad entre grupos de trabajo que Teams nos ofrece. Podríamos definir Teams como el resultado de la integración de las características de varias aplicaciones de Office 365. Un espacio de trabajo donde un grupo puede iniciar reuniones de audio y/o vídeo, compartir o trabajar en documentos de Office, chatear e incluso enviar pegatinas y memes.

Mejoras respecto a Skype for Business.

Gracias a la integración de la que surge Teams, son muchas las mejoras que podemos mencionar respecto a Skype for Business (Mayor facilidad para compartir información y archivos, posibilidad de trabajar en documentos de Office de manera simultanea, consulta de información, mejor gestión de los grupos, posibilidad de integrar aplicaciones de terceros, bots, etc..) La experiencia de reuniones también ha sido mejorada haciendo que ahora se pueda conocer, con un simple vistazo, los asistentes confirmados, organizadores, sala, hora, día y la posibilidad de cancelar la reunión.

Buenas prácticas.

La eficiencia de Microsoft Teams se verá incrementada con un buen uso de la misma. Es importante entender como queremos usar la herramienta y que queremos conseguir de ella. Esto nos ayudará a saber que canales debemos crear y que gente debemos añadir a cada uno para mejorar la eficiencia de las comunicaciones y evitar duplicidades. Organizar los canales por un nombre claro y único. Puede sonar muy básico pero suele ser el talón de Aquiles a la larga. Una estructura desordenada generará que nuestros usuarios no sepan donde encontrar la información o que la encontremos en varios sitios distintos a la vez, creando la posibilidad de que los hilos crezcan con conversaciones y resoluciones distintas.

Ejemplo simple de organización de equipos de trabajo.

Es muy importante que cuando empecemos a trabajar con Teams tengamos clara la estructura interna de nuestra empresa y su forma de trabajar, sus proyectos y como puede crecer. De esta forma, cuando en un futuro tengamos que añadir más grupos – o canales dentro de los mismos – lo haremos asegurándonos de no haber duplicidades. Uso de las @menciones pero no abuses. Las menciones son una manera muy útil de captar la atención de ese usuario, o grupo de usuarios, que necesitamos en un determinado momento. Como todo, hay que ser responsable con su uso, ya que el abuso de las menciones grupales o de usuarios podría generar el efecto contrario al deseado haciendo que aquellos a quien queremos reclamar atención empiecen a ignorar las notificaciones de Teams. Organiza las pestañas y los documentos de una manera sencilla. Al igual que con la creación de grupos y canales, debemos tener mucho cuidado con como organizamos la documentación para evitar duplicados y elementos descatalogados. La información siempre debe estar organizada de la forma más sencilla y amigable para los usuarios finales. Usa nombres amigables y crea diferentes niveles con subcarpetas.

User Voice: Solicita y proporciona feedback. Microsoft Teams es una herramienta muy joven que le queda camino por recorrer y, por supuesto, cosas que mejorar. En la página Microsoft Teams User Voice podrás solicitar mejoras, cambios o nuevas características. Estas páginas son revisadas por ingenieros que estudian y analizan cada solicitud y, con un sistema público de votos se pueden impulsar nuevas ideas para su estudio. Un ejemplo es la solicitud de un cliente de Teams para sistemas Linux. Como podéis ver aquí la petición ha sido votada por casi 2800 personas y Grupo de Producto la mantiene en backlog para ser desarrollada en un futuro.

Optimiza tu entorno actual de Skype for Business para funcionar con Microsoft Teams.

Antes de empezar la transición de Skype for Business a Teams es importante asegurarnos de que la calidad de la red es adecuada para el cambio. De esta manera nos evitaremos muchos problemas en el futuro. También es importante conocer las dependencias del entorno. Teams combina múltiples servicios de Office 365, por lo que depende de que estos estén instalados. Por ejemplo, si no tienes pensado implementar SharePoint Online tienes que tener en cuenta que la compartición de archivos en los grupos no funcionará.

Antes de nada, crea un piloto.

Crea un piloto de Teams para poder estudiar cual será el desarrollo cuando llegue el momento. Para ello, redacta la logística que seguirá, quienes serán sus participantes y diseña un plan de pruebas y feedback para su mejora. Una vez esas bases estén implementadas juega con el entorno, publica publicaciones, anima a los usuarios involucrados a participar lo más posible y estudia los resultados para preparar el plan de acción para la sustitución de Skype for Business por Teams.

Arranca el proyecto: Coexistencia de Teams con Skype for Business.

Opción 1 – Coexistencia total con Skype For Business hasta su degradación. Con esta opción le daremos a los usuarios la posibilidad de que las dos herramientas convivan durante un periodo de tiempo hasta que finalmente Skype for Business se elimine y únicamente quede Teams. Opción 2 – Evolución gradual desde Skype for Business a Teams. De las dos opciones esta es la mas recomendable. En este caso iremos introduciendo características de Teams a la par que degradamos sus homólogas en Skype for Business para que los usuarios, de una forma menos agresiva, se vayan familiarizando con la nueva herramienta. Hasta aquí llega la pequeña introducción de como es el camino del cambio de Skype for Business a Teams. Si tenéis cualquier pregunta no dudéis en publicar un comentario.

Las migraciones a Exchange Online fallan con el error “TooManyBadItemsPermanentException”

Alberto Pascual — Thu, 29 Jun 2017 08:51:45 GMT

Algunos habéis podido observar en los últimos años que un mayor número de migraciones están fallando debido a encontrar demasiados ítems corruptos. Si analizamos más de cerca el motivo, veréis que el informe de migración contiene entradas haciendo referencia a elementos corruptos y no ha sido posible traducir las entradas principales de seguridad. Quería tomar unos minutos y proporcionar más información para ayudar a comprender lo que esto significa, por qué pasa ahora, y qué se puede hacer al respecto. Durante una migración de buzones de correo, existen varias fases por las que pasamos. Empezamos con una copia de la jerarquía de carpetas (incluyendo las vistas asociadas a dichas carpetas), posteriormente realizamos una copia inicial de los datos (lo que llamamos la sincronización inicial) y una vez finalizada la sincronización inicial, copiamos las reglas y descriptores de seguridad. En el informe de movimiento veremos entradas similares a las siguientes:

Stage: CreatingFolderHierarchy. Percent complete: 10 Initializing folder hierarchy from mailbox : X folders total Folder hierarchy initialized for mailbox : X folders created Stage: LoadingMessages Copying messages is complete. Copying rules and security descriptors. Por los momentos vamos a centrarnos en la fase de copia de reglas y descriptores de seguridad. Los descriptores de seguridad son listas de control de acceso o ACLs (Access Control Lists) que se comprenden de Entradas de Control de Acceso o ACEs (Access Control Entries) y que se almacenan en formato SDDL. En el contexto de un buzón, se incluyen tanto los descriptores de seguridad de buzón o permisos de buzón (Mailbox Security Descriptor / Mailbox Permissions) como los descriptores de seguridad de carpetas (también conocidos como Folder Security Descriptors o permisos de carpetas individuales). Ahora, cuando nos fijamos en el Mailbox Security Descriptor, debe tenerse en cuenta que únicamente se copian los permisos de buzón explícitos. Estos incluyen permisos concedidos mediante el CmdLet Add-MailboxPermission, o la consola de administración de Exchange (2010)/Exchange Admin Center (2013 y 2016) para agregar permisos de acceso total o “Full Access”. Cualquier permiso heredado no se evaluará durante la fase de copiado. Por ejemplo, los permisos de “Receive-As” otorgados en un objeto de base de datos en Active Directory resultan siendo un permiso heredado de Full Access para todos los buzones alojados en dicha base de datos. Cuando estos buzones se migran a Exchange Online, dichos permisos heredados no llegan a copiarse. Una vez descrito brevemente los Security Descriptors, echemos un vistazo al problema comentado al principio de este artículo. A mediados del 2016, se introdujo un cambio en Exchange Online en el que, si un Security Principal no pudiese ser validado/mapeado a un objeto de Exchange Online, se marcaría como un ítem corrupto o defectuoso. Anteriormente, dichos permisos no resolubles simplemente se ignoraban y luego eran los administradores los que tenían que investigar por qué de repente ciertos permisos dejaban de funcionar después de la migración. Con este cambio, los administradores pueden consultar cuales son los permisos no resolubles o que no se puedan asociar a otros objetos de Exchange Online y por lo tanto poder anticiparse a posibles futuras incidencias relacionadas con los buzones migrados, por lo tanto, desde mi perspectiva como un ingeniero de soporte, dicho cambio es beneficioso para la organización. Es probable que este comportamiento continúe evolucionando según pasa el tiempo, pero mi consejo es el de familiarizarse con él para entender que es lo que ocurre en realidad. ¿Cómo podría afectarle esto en su entorno? Bueno, dado que estaremos incrementando el número de ítems corruptos por cada permiso que no podamos asociar a un objeto en Exchange Online, una vez alcanzado o sobrepasado el umbral establecido para el número de elementos corruptos/inválidos en la migración (por defecto es 10 en un lote de migración o Migration Batch y 0 en el caso de Move Requests – salvo que se especifique un valor superior), la migración/movimiento de buzón fallará. Dependiendo del estado de permisos, se podría observar potencialmente un número elevado de entradas relacionadas con estos en el informe de movimiento. En dicho informe podremos ver entradas tales como las siguientes: 11/12/2016 8:44:43 AM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals for folder "Folder Name"/"FolderNTSD": Failed to find a principal from the source forest. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: Alias: ; DisplayName: ; MailboxGuid: ; SID: ; ObjectGuid: ; LegDN: ; Proxies: [X500:; SMTP:user@contoso.com;];. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: ; ObjectGuid: ;. De acuerdo, ¿entonces cuál es la lógica aplicada para validar los permisos?... Existen 4 pasos básicos asociados a este proceso que paso a detallar a continuación: Exchange Online necesita resolver el SID presente en el Security Descriptor (presente en carpeta o buzón)

Exchange Online realiza una petición al MRS Proxy de On-Premises pasando el SID a resolver
El MRS Proxy de On-Premises consulta el SID proporcionado al Active Directory, el cual devolverá un conjunto de atributos (incluyendo el SID primario y el legacyExchangeDN)
Exchange Online recogerá el valor del legacyExchangeDN obtenido en el paso anterior e intentará coincidirlo con un objeto de Exchange Online que contenga dicho valor como una dirección proxy X500.

Normalmente, la sincronización de directorios se encargará de estampar el legacyExchangeDN de cada lado como una dirección proxy X500, pero esto no significa que el legacyExchangeDN de On-Premises deba coincidir con la dirección proxy X500 de un objeto habilitado para correo – o Mail-Enabled recipient presente en Exchange Online (p.e. un buzón, MailUser, Mail-enabled Security Group…). Si este último es el caso, entonces es cuando la resolución del permiso fallará. Existen dos tipos de excepciones relacionados con permisos y me gustaría diferenciarlas: SourcePrincipalMappingException – Cuando se nos presenta esta excepción, es porque el MRS Proxy intenta consultar el SID en el Active Directory de On-Premises y no ha podido resolverse. Es muy común encontrarnos con este escenario y normalmente es provocado cuando un usuario deja la organización y su cuenta es eliminada. También podemos ver esta excepción cuando el SID en cuestión es parte del SIDHistory de una cuenta de On-Premises, dado que cuando el MRS Proxy intenta consultar el SID, únicamente buscaremos por ObjectSID o msExchMasterAccountSID y, por ende, MRS Proxy no consultará el SIDHistory, por lo tanto, dicha excepción será la esperada. La situación en el que el SIDHistory tenga valores no es algo habitual, pero desde luego es algo para tener en cuenta. Nota: Exchange Online tiene implícito un límite excepcional de ítems corruptos para que los movimientos no fallen por este tipo de excepción, siempre y cuando el número no supere los 1000. TargetPrincipalMappingException – Esta excepción indica que no podemos mapear o relacionar el permiso a una cuenta de usuario en el bosque de destino (Exchange Online). Un ejemplo perfecto de esto sería el de un usuario o grupo al que se le han otorgado permisos sobre un buzón, pero ese usuario o grupo se encuentra excluido del ámbito de sincronización con la nube. Después de intentar mover el buzón mediante MRS, dicho usuario o grupo no estará presente en Exchange Online y por lo tanto obtendremos de forma esperada esta excepción. Otro escenario que podemos encontrarnos es si un grupo de seguridad que no esté Mail-Enabled, se haya utilizado para otorgar permisos. Este tipo de grupos (no Mail-Enabled) no se sincronizan con Exchange Online y por lo tanto no existirán en el bosque de destino. Para resolver el problema tenemos dos opciones:

Incrementar el límite de ítems corruptos (Bad Item Limit) para tener en cuenta los errores de permisos. En entornos complejos en los que hay múltiples versiones de Exchange y los objetos han estado de un lado a otro, podemos encontrarnos con miles de errores de permisos, por lo que no sería descabellado establecer un valor elevado en el Bad Item Limit. Las buenas noticias es que según Exchange ha ido evolucionando a lo largo de los años, la posibilidad de encontrarnos mensajes corruptos es relativamente baja, por lo que la mayoría de los ítems corruptos que encontremos serán permisos que no podamos resolver y no contenido del buzón en si. No obstante, podemos identificarlos mediante el análisis del informe de movimiento. Más adelante en este mismo post veremos como hacerlo.
La segunda opción consiste en cancelar la petición de movimiento, arreglar los permisos en cuestión (bien eliminándolos o arreglando su resolución) y volver a intentar el movimiento de nuevo. ¿Y si quiero arreglar dichos permisos y continuar con el movimiento? Bueno, no voy a decir que no lo hagáis, sin embargo, no cambiará nada y únicamente estaremos perdiendo el tiempo, dado que únicamente evaluaremos los permisos una única vez al final de la copia inicial de los datos. Si el movimiento falla por superar el número de ítems corruptos (debido a permisos), no volveremos a evaluarlos y daremos el movimiento como fallido con las excepciones descritas anteriormente. Por lo que las únicas opciones se reducirán a incrementar el Bad Item Limit o volver a lanzar el movimiento recreándolo desde cero después de arreglar dichos permisos.

Tal y como había prometido, vamos a ver como analizar el informe de movimiento con relación a los errores de permisos. Para ello deberemos hacer uso de PowerShell para exportar el informe de movimiento y almacenarlo en una variable temporal. Para guardar el informe en una variable temporal deberemos ejecutar la siguiente línea en una Ventana de PowerShell conectada a una sesión de Exchange Online: $movereport = Get-MoveRequestStatistics -IncludeReport También podemos exportar informe a un fichero XML y analizarlo en local ejecutando la siguiente línea: Get-MoveRequestStatistics -IncludeReport | Export-CliXml c:\temp\movereport.xml Una vez exportado el fichero XML, podemos guardarlo en una variable para poder trabajar con el mediante la siguiente línea (sin necesidad de conectarnos a Exchange Online): $movereport = Import-CliXml c:\temp\movereport.xml Si anteriormente no habéis visto lo que contiene un informe de movimiento, simplemente puedo indicar que la información contenida (de todo tipo) es oro en paño, y que podremos encontrar a través del portal. Ahora que tenemos el informe de movimiento almacenado en una variable (a la que llamamos $movereport), podemos acceder a la preciada información haciendo llamadas a ella tal y como podemos ver a continuación: $movereport.report.baditems – Esto nos devolverá una lista de todos los ítems corruptos que se han encontrado. Una recomendación interesante es que podemos hacer uso de “Out-GridView” (o OGV) para poder ver los resultados en una ventana grafica en lugar de mostrarlos en la ventana de PowerShell. $movereport.report.baditems | Out-GridView $movereport.report.baditems | OGV Lo bueno de hacer uso de Out-GridView es que podemos jugar con filtros sobre la marcha. Por ejemplo, podemos comprobar los items corruptos y relacionarlos con los errores de permisos simplemente eligiendo “Add criteria”, seleccionando la opción “Kind”, y hacemos clic en “Add”. Cambiamos la condición “Contains” a “Does not contain”, y escribimos “Security”. De esta forma únicamente mostraremos los ítems corrutos de cualquier otro tipo. Ahora que hemos identificado el cambio de comportamiento, y observado cómo solucionarlo, vamos a terminar hablando sobre que aproximación deberíamos tener en cuenta a la hora de planificar la migración. La aproximación recomendada de cara a este cambio de comportamiento sería la de continuar migrando con un número bajo de BadItemLimit, y manualmente corregir aquellos que fallen. Recomendamos esto porque las migraciones que resulten fallidas podrían indicar bien que existen BASTANTES permisos corruptos en origen (más de 1000) o bien que son permisos validos pero que simplemente dichas cuentas no existen en Exchange Online y por lo tanto no es posible mapearlas. Ambas condiciones no deberían ser comunes, por lo que sería recomendable llevar a cabo una investigación sobre que ha sido la verdadera causa. Agradecimientos especiales a Brad Hughes y el resto del equipo de MRS por su asistencia y revisión de este contenido, y por supuesto a Ben Winzenz por tomarse su tiempo en redactarlo (su versión en inglés puede encontrarse en https://blogs.technet.microsoft.com/exchange/2017/05/30/toomanybaditemspermanentexception-error-when-migrating-to-exchange-online/)

Bloqueo automático de dispositivos ActiveSync

Marco Castro Rodiño — Wed, 26 Apr 2017 09:05:28 GMT

Hola a todos, En esta entrada me gustaría hablar sobre la capacidad de Exchange para bloquear dispositivos ActiveSync que estén experimentando un mal comportamiento. El cmdlet Set-ActiveSyncDeviceAutoblockThreshold puede modificar una regla de umbral de bloqueo automático y cambiar una variedad de opciones como por ejemplo la duración del bloqueo. Esta es la configuración de mi entorno Exchange 2016 obtenida con el cmdlet Get-ActiveSyncDeviceAutoblockThreshold:

BehaviorType : UserAgentsChanges BehaviorTypeIncidenceLimit : 6 BehaviorTypeIncidenceDuration : 01:00:00 DeviceBlockDuration : 01:00:00

BehaviorType : RecentCommands BehaviorTypeIncidenceLimit : 30 BehaviorTypeIncidenceDuration : 00:10:00 DeviceBlockDuration : 00:20:00

BehaviorType : Watsons BehaviorTypeIncidenceLimit : 5 BehaviorTypeIncidenceDuration : 00:10:00 DeviceBlockDuration : 00:20:00

BehaviorType : OutOfBudgets BehaviorTypeIncidenceLimit : 10 BehaviorTypeIncidenceDuration : 00:10:00 DeviceBlockDuration : 00:20:00

BehaviorType : SyncCommands BehaviorTypeIncidenceLimit : 60 BehaviorTypeIncidenceDuration : 00:10:00 DeviceBlockDuration : 00:20:00

BehaviorType : CommandFrequency BehaviorTypeIncidenceLimit : 400 BehaviorTypeIncidenceDuration : 00:10:00 DeviceBlockDuration : 00:20:00

Recientemente hemos tenido varios casos para evitar que dispositivos ActiveSync generen demasiados logs de transacción mediante un número excesivo de hits, por lo que quiero poner como ejemplo el BehaviorType "CommandFrequency". Con la configuración de mi entorno, si un dispositivo ActiveSync alcanza 400 hits en una franja de tiempo de 10 minutos, será bloqueado 20 minutos, y además ese usuario puede ser notificado mediante un correo electrónico personalizado. El cmdlet necesario para aplicar esa configuración sería:

Set-ActiveSyncDeviceAutoblockThreshold -Identity "CommandFrequency" BehaviorTypeIncidenceLimit 400 -BehaviorTypeIncidenceDuration 10 -DeviceBlockDuration 20 -AdminEmailInsert "Tu dispositivo se ha bloqueado. "]

A continuación os dejo una pequeña descripción de cada BehaviorType:

UserAgentChanges: La frecuencia con la que un dispositivo cambia su agente de usuario.
RecentCommands: Mira tanto el timestamp como el hashcode del comando para determinar si el dispositivo ha entrado en un bucle.
Watsons: Cuántos Watsons han sido generado por el dispositivo, lo que podría sugerir un ataque a través de un bug del producto.
OutOfBudgets: La frecuencia con la que el dispositivo sigue realizando hits tras una respuesta 503.
SyncCommands: Mira el timestamp y las claves de sincronización para comprobar si la misma orden se envía de modo repetido.
CommandFrequency: Mira la rapidez con la que el dispositivo realiza hits a los servidores Exchange (a través de todos los comandos).

Por último, mencionar que esta configuración se aplica a nivel organización, por lo cual es recomendable estudiar en profundidad cada modificación antes de aplicarla. Un saludo, Marco Castro

Analizando estadísticas de generación de logs de transacciones

Juan Gasca Dominguez — Tue, 28 Feb 2017 09:22:49 GMT

Hola a todos, en la entrada de hoy voy a comentar como recolectar información de generación de logs de transacciones en un entorno de Exchange, utilizando como referencia un artículo públicado en nuestro Blog oficial en Inglés. (No aceptes imitaciones :-p ) La información recolectada, nos permitirá extraer una referencia de la carga actual en las bases de datos. Esta información es muy útil para realizar cálculos de capacidad, previendo así el crecimiento del entorno y los evolutivos necesarios para mantener los requerimientos de servicio. La recolección de los datos se realizará mediante un script llamado GetTransactionLogStats.ps1 cortesía de nuestro compañero Mike Hendrickson. (Thanks Mike) Requerimientos

El script soporta versiones Exchange 2010 o superiores.
Remote powershell debe estar habilitado en los servidores en cuestión y configurado para permitir las conexiones desde la máquina donde se lanzará el script en cuestión.

Parámetros El script dispone de los siguientes parámetros:

Gather: Con este modificador capturaremos las transacciones generadas que posteriormente analizaremos. Si omitimos este modificador se debe utilizar -Analyze
Analyze: Con este modificador analizaremos la información ya capturada anteriormente. Si omitimos este modificador se debe utilizar -Gather
ResetStats: Este modificador se utilizará para limpiar el fichero de recolección, solo se utiliza en el modo Gather
WorkingDirectory: El modificador indica donde se alojará el fichero de recolección, en caso de omitirlo el script utilizara el directorio de trabajo de powershell (No tiene por qué coincidir con el directorio donde está alojado el script).
LogDirectoryOut: El modificador indica donde se alojarán los ficheros de salida generados a través del proceso Analyze, en el caso se omitir el modificador la salida se alojará en la ruta especificada mediante WorkingDirectory

Utilización Teniendo en cuenta los parámetros comentados, os adjunto varios ejemplos de uso del script:

Recolectar información de los servidores "server1" y "server2"
- .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2”
Recolectar información especificando el directorio de recolección y forzando la limpieza del fichero de recolección si este existe
- .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2” -WorkingDirectory “C:\GetTransactionLogStats” -ResetStats
Lanzar el script en modo análisis indicando la ubicación donde se alojarán los ficheros de salida generados
- .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut “C:\GetTransactionLogStats\LogsOut"

Fichero de salida generado en el modo recolección "Gather"

Logstats.csv - Una vez recolectada la información, el fichero de recolección generado tendrá un contenido tal como se muestra en la imagen, como podéis ver es un fichero separado por comas que está compuesto por la siguientes columnas:
- Databasename: Nombre de la base de datos
- Servername: Nombre del servidor
- LogGeneration: Número de logs generados
- Timecollected: Hora en la que se ha recogido la información

Ficheros de salida generado en el modo análisis "Analyze"

LogGenByHour.csv - Este fichero de salida generado por el proceso de análisis, se utiliza para identificar el ratio horario de generación de logs en la calculadora de requerimientos de Exchange "Exchange Server Role Requirements Calculator" y está compuesto por las siguientes columnas:
- Hour: La hora en la que se ha recolectado el estado del log. Sus valores son entre 0 - 23
- LogsGenerated: El número total de logs creados durante esa hora para todos los días presentes en el fichero analizado "LogStats.csv"
- HourToDailyLogGenRatio: El ratio de todos los registros en esa hora en particular. La suma de valores de esta columna durante las 24h de la tabla debe ser 1 y se puede copiar directamente en la calculadora de requisitos.
- NumberofHourlySamples: El número de muestras horarias que se utilizaron para calcular el valor de cada hora.
- AvgLogGenPerHour: El número medio de transacciones generadas por base de datos por hora
LogGenByDB.csv - Este fichero contiene las estadísticas de generación de transacciones por cada base de datos durante el proceso de recolección. Esta información puede utilizarse para identificar si la base de datos, servidor o grupo de disponibilidad está sobre o subutilizado en comparación con el resto, y está compuesto por las siguientes columnas:
- DatabaseNAme: Nombre de la base de datos monitorizada
- LogsGenerated: El número total de transacciones creadas por las copia primaria de la base de datos durante el proceso de recollección
- LogGenToTotalRatio: El ratio de logs generados por esta base de datos en comparación con las transacciones realizadas por todas las bases de datos
- NumberofHours: El numero de muestras horarias que fueron capturadas para esta base de datos
- LogsGeneratedPerHour: La número medio de transacciones generadas por hora para esta base de datos.
LogGenByDBByHour.csv - El fichero es similar al LogGenByDB.csv, pero contiene información acerca del ratio de generación de transacciones por hora para cada base de datos, y está compuesto por las siguientes columnas:
- DatabaseName: Nombre de la base de datos monitorizada
- Hour: La hora en la que se ha recolectado el estado de las transacciones. Sus valores són entre 0 - 23
- LogsGenerated: El número total de transacciones creadas por la copia primaria de la base de datos durante el proceso de recollección
- HourToDailyLogGenRatioForDB: El ratio de transacciones generadas durante esta hora en esta base de datos comparado con el total de logs generados para esta base de datos

Ejecutar la recolección con una tarea programada De cara a obtener un muestreo útil, sería recommendable recoger la información cada hora, la forma más sencilla de hacerlo es ejecutar el script mediante una tarea programada. La manera de hacerlo es crear una archivo por lotes que llame al powershell.exe y que este a su vez lance el script "GetTransactionLogStats.ps1", este archivo por lotes debe ser ejecutado desde una tarea programada que nos permitirá establecer la frecuencia de ejecución. Aqui tenéis un ejemplo de comando que debería utilizarse en el fichero por lotes:

powershell.exe -noninteractive -noprofile -command “& {C:\LogStats\GetTransactionLogStats.ps1 -Gather -TargetServers “server1”,”server2” -WorkingDirectory C:\LogStats}”

Se debe tener en cuenta que en este ejemplo la secuencia de commandos se encuentra en C:\logstats, la misma ruta que el directorio de trabajo del propio script, para que si la tarea programada se ejecuta en una ubicación alternativa (por defecto c:\windows\system32\) el script sepa donde leer y escribir el fichero de recollección logstats.csv. El commando no carga ningún snapin the exchange, ya que el script no utiliza ningún commando específico de Exchange. Generación de informes utilizando la información recolectada Una vez recolectada toda la información que hemos mencionado durante el post, solo queda pasarla a un formato más entendible, ya sea de cara a presentar un informe ejecutivo o simplemente obtener una gráfica para valorar la situación de un vistazo rápido, como se suele decir: "Una imagen vale más que mil palabras" Como apunte, me gustaría comentar que para mantener un histórico de ficheros LogGenxx.csv debemos implementar algún script que mueva (move-item) los ficheros generados durante el día en una carpeta de trabajo diferente, para evitar que los ficheros se sobreescriban. Aquí os dejo unas líneas de ejemplo para generar una carpeta con la fecha de ayer y mover todos los ficheros con fecha de ayer a dicha carpeta:

New-Item -path "c:\logstats\$((Get-Date).AddDays(-1) | Get-Date -Format ddMMyyyy)" -type directory

Get-ChildItem -Path "C:\logstats" -filter "*.csv" | ? {$_.LastWriteTime -lt (Get-date)} | Move-Item -path "C:\logstats\$((Get-Date).AddDays(-1) | Get-Date -Format ddMMyyyy)"

Siguendo con el tratamiento de la información recolectada, en este punto tenemos varias opciones al gusto del consumidor para manejar estos datos, yo personalmente creo que la opción más sencilla es procesar todos estos datos a través de "Power BI Desktop" el cual nos permitirá establecer una "plantilla" de visualización de datos para poder obtener un gráfico dinámico periódico utilizando como origen los ficheros que generamos/alojamos en esa máquina de administración donde se lanza el script. Espero poder ampliar información a este respecto en próximas actualizaciones.

Nuevas opciones de migración en Exchange Online

Alberto Pascual — Wed, 21 Dec 2016 18:25:19 GMT

Hace un par de semanas hemos implementado una nueva experiencia de migración que simplificará enormemente el onboarding hacia Office 365 y Exchange Online desde entornos de Microsoft Exchange actuales. Esta nueva experiencia ayudará a cualquier cliente que ejecute al menos un servidor de Exchange 2010, 2013 y/o 2016 a migrar a la nube sin problemas. Al iniciar la migración, evaluamos lo que ya ha configurado en Exchange Online y le guiamos por el Asistente de configuración híbrida para evaluar el entorno local. Una vez que se recoja toda la información sobre su estado actual, le hacemos un par de preguntas sobre su estado deseado, como por ejemplo, cuán rápido desea migrar a Exchange Online y si necesita funciones avanzadas. A continuación, el asistente de configuración híbrida le guiará por la configuración necesaria para migrar sus usuarios a Exchange Online. Si ejecutamos la última versión del asistente de configuración híbrida, en función de su configuración actual y de las opciones seleccionadas durante la ejecución del asistente, se mostrarán las siguientes opciones a elegir (siempre y cuando no se haya ejecutado anteriormente en el entorno):

Full Hybrid: Esta es la configuración común para los clientes que son más grandes en tamaño y que necesitarán de más tiempo para migrar o clientes que no serán capaces por limitaciones de negocio y/o técnicas de mover todos los buzones de correo hacia Exchange Online a corto y medio plazo. Esta es la opción más compleja de configurar, pero le brindará características mejoradas como opciones de flujo de correo y consultas de disponibilidad free/busy entre la nube y usuarios locales. Para más información sobre Full Hybrid puede ir aquí.
Minimal hybrid: Esta es una opción recientemente introducida que se ha añadido al asistente de configuración híbrida en Junio de 2016 que le permite configurar su entorno para admitir migraciones híbridas y la administración de destinatarios sin la necesidad de la sobrecarga adicional de configurar funciones de consultas de disponibilidad y otras características incluidas en el modo Full Hybrid mencionado en el punto anterior. A menudo, los clientes utilizan esta opción si lo que desean es mover todos sus buzones a Exchange Online en el transcurso de un par de meses o menos y quieren mantener la sincronización de directorios (AD local y Azure AD). Para obtener más información esta opción por favor vaya aquí .
Express Migration: Ésta es la nueva opción que hemos añadido en la que el asistente de configuración híbrida beneficiará a los clientes más pequeños o a clientes que realmente desean moverse a Exchange Online en el transcurso de un par de semanas o menos. Sin embargo, si tiene la necesidad de mantener la sincronización de directorios en su lugar, entonces esta no es la opción para usted. Esta opción configurará a los usuarios y le guiará a través de la nueva experiencia de migración para obtener los buzones de Exchange Online con una interrupción mínima para los usuarios

Más acerca de Express Migration

Anteriormente, un administrador de la pequeña y mediana empresa tenía que elegir entre la opción de hibridar (con la complejidad que conllevaba) y una migración discontinua o escalonada (y por supuesto compleja). Ahora puede obtener una experiencia de Migración Express muy simplificada. Con ésta opción, obtenemos una única sincronización de directorio en la que se incluyen sus usuarios junto con los beneficios de la opción Minimal Hybrid mencionado anteriormente para permitir realizar las migraciones de una forma simple. Después de esa sincronización inicial de cuentas de usuario, la sincronización de directorios se deshabilitará automáticamente tanto en Office 365 como en su entorno local. Esto le dará a los clientes pequeños y medianos que previamente hubiesen pensado en realizar una migración por Cutover, la capacidad de obtener los beneficios de la migración híbrida sin las complicaciones de un entorno híbrido. ¿Beneficios de esta opción? Si la comparamos con otro método de migración más tradicional como Cutover, observamos lo siguiente:

Los nombres de usuario y las contraseñas se sincronizarán desde el entorno local
Los usuarios no tendrán que volver a crear perfiles de Outlook y se evita una saturación en la red por la descarga consiguiente de los buzones nuevamente.
El flujo de correo continuará funcionando entre los usuarios antes, durante y después de la migración
Los usuarios no experimentarán un corte de servicio durante la migración

Cómo Iniciar la migración?

Todas las opciones de migración descritos en este artículo (Completo, Mínimo y Express) ya pueden iniciarse desde una interfaz, por lo que vayamos viéndolo paso a paso. Uno de los componentes clave de esta nueva experiencia es el panel de migración. Este es un nuevo panel que hemos creado en el Portal de Administración de Office 365 que coincide con el aspecto moderno y sensación que el resto del portal. Sin embargo, no se trata sólo de la renovada apariencia, sino también de la inteligencia incorporada que hay por detrás. Por ejemplo, al entrar en el panel de migración vamos a detectar si ha ejecutado el Asistente de configuración híbrida, si ya ha sincronizado a sus usuarios, y si ya se ha creado un extremo de migración. Dependiendo de lo que ya está en hecho, podemos llevarlo hacia la opción de migración adecuada. Para ello, tendrá que ampliar la sección "Usuarios" en el portal de Office 365 y luego seleccionar la opción "Migración de Datos". Una vez allí, seleccione la opción de correo electrónico de Exchange para iniciar la experiencia. Una vez seleccionada la fuente, realizamos una comprobación rápida del tenant para ver si ha ejecutado el Asistente de Configuración Híbrida en algún momento. Si aún no lo ha ejecutado, significa que sabemos que el entorno local no ha sido preparado aún para la migración y por lo tanto le llevaremos a través de la descarga y ejecución del Asistente de Configuración Híbrida. Cuando descargue y ejecute el asistente de configuración híbrida, verá una pantalla de bienvenida, sólo tiene que seleccionar siguiente: A continuación, verá la pantalla de detección de servidor de Exchange local que hará la vez de punto de contacto para iniciar la configuración, sólo seleccione siguiente ya que el servidor más adecuado será el que se detecte. De forma predeterminada, intentaremos conectarnos al servidor de Exchange que ejecuta la versión de Exchange más reciente: Proporcione sus credenciales tanto para su entorno de Exchange local como para Exchange Online. Seleccione la opción de migración adecuada. Para este ejemplo, estamos mostrando Express Migration por lo que seleccionaremos la opción “Minimal Hybrid”: Seleccione update, y empezaremos a configurar su entorno local de Exchange para poder realizar el movimiento de buzones mas adelante:

Siguiente fase: Provisionar usuarios

Si no ha sincronizado a sus usuarios hasta este momento, verá una opción para realizar una sincronización única de sus usuarios o para instalar AAD Connect por separado. Como se mencionó anteriormente, si planea mover todos sus buzones a Exchange Online y no tiene la necesidad de mantener la sincronización de directorios, seleccione la opción de sincronización de una sola vez. Seleccionando esta opción es lo que consideramos una "Migración Express". Si necesita sincronización de directorios por cualquier motivo, debe instalar y configurar AAD Connect por separado. Nota: si seleccionó la sincronización de una sola vez y más tarde decidió que necesita sincronización de directorios, puede configurar AAD Connect para realizar la sincronización de directorios Si no ha seleccionado la opción “Minimal Hybrid” en el paso anterior, entonces no se le dará la opción de sincronización de directorios de una sola vez. La razón por la que no lo obtendría si optó por “Full Hybrid” es porque ese escenario de implementación requiere las características avanzadas de coexistencia y la sincronización de directorios. Una vez seleccionada la opción "Sincronizar mis usuarios y contraseñas una vez", el asistente de configuración híbrida mostrará una barra de progreso mientras que el asistente estará esperando a que se configure AAD Connect y que el conjunto inicial de usuarios se sincronice. Para completar la configuración de configuración híbrida, deberá configurar AAD Connect. En casi todos los casos, las opciones predeterminadas de AAD Connect son las mejores opciones. Una vez completado, verá la página final del asistente que le permitirá dar su opinión. Una vez cerrado, se le mostrará la página de la lista de usuarios para comenzar a mover los buzones. En la página de la lista de usuarios tendrá la opción de seleccionar los usuarios que desea migrar. Por debajo estaremos utilizando MRS para migrar a los usuarios tal y como se hace en una migración híbrida. Puede utilizar este nuevo panel para migrar buzones, independientemente de la opción de despliegue elegida en el asistente. La experiencia es tan simple como seleccionar a los usuarios y hacer clic en iniciar la migración. En ese momento, realizaremos una búsqueda para ver si los requisitos previos están en su lugar. Si algo falta, le guiaremos para completar el requisito faltante.

Limitaciones

Existen algunas limitaciones con el nuevo panel de migración que necesita tener en cuenta. Estamos trabajando para no tener dichas limitaciones en un futuro próximo:

Sólo un punto de migración es posible: Si hay más de un punto de migración, elegiremos el creado por el asistente de configuración híbrida o por la nueva experiencia de migración.
Sólo un lote de migración puede ser iniciado a la vez: Todavía no soportamos varios lotes de migración con este nuevo panel de migración. Esto significa que debe esperar a que finalice la migración anterior antes de iniciar otra. Sabemos que el tener múltiples lotes es importante para los clientes medios y más grandes, y por lo tanto tenemos esto como máxima prioridad.
Requerimos que se asignen licencias a los usuarios de forma independiente: Es necesario que todos los usuarios que se migren a través de esta experiencia tengan una licencia asignada antes de que comience la migración (a excepción de los buzones compartidos), esto no es un proceso automático y por ello se necesita dicha intervención por su parte.

Conclusión

Estas actualizaciones harán que la experiencia de onboarding hacia Exchange Online sea más transparente para muchos clientes de Exchange. Hemos creado y continuamos mejorando el panel Migración para satisfacer las necesidades de nuestros clientes. Si tiene algún comentario que nos permita mejorar dicha experiencia, utilice por favor el botón proporcionado en el asistente de configuración híbrida

Grabaciones de Webcasts ya disponibles en Channel 9

Alberto Pascual — Sat, 27 Aug 2016 09:26:54 GMT

Hola!, Desde el equipo de soporte de Microsoft Exchange, tenemos el placer de informarte que disponemos de nueva área en Channel 9 donde iremos publicando nuevo contenido que se vaya grabando totalmente en Español, para empezar ya tenéis disponibles los 5 webcasts que se hicieron durante el mes de Junio con sus correspondientes diapositivas. Puedes acceder a dicha área y encontrar las grabaciones en https://channel9.msdn.com/Blogs/Exchange-Online-Tech-Talk Esperamos que lo disfrutes tanto como nosotros haciendolo. Un saludo, El equipo de soporte de Microsoft Exchange