Revisión 25/05/2020
Office 365 abarca un conjunto de servicios en “la nube”, en muchos casos estos servicios son versiones de productos ya conocidos para quienes trabajan en IT hace algún tiempo como Exchange y Sharepoint, pero también existen servicios nativos que no los encontramos On Premises como por ejemplo Planner o Microsoft Teams.
Microsoft ofrece estos servicios en base a suscripción y esto puede ser abonado de forma mensual o anual. Dependiendo del plan y licencia qué servicios son incluidos.
Si bien Office 365 incluye múltiples planes, incluso algunos orientados al hogar, el foco de este artículo es a un nivel más corporativo, orientado a profesionales de IT que se encuentran haciendo la transición de conocimiento hacia la nube y entornos híbridos.
Teniendo esto en cuenta vamos a comenzar viendo los principales conceptos asociados a Office 365.
Qué es un Tenant en Office 365?
Básicamente un Tenant es la cuenta que se configura en Office 365 para la organización. Estos Tenants funcionan como contenedores individuales y son identificados con un subdominio bajo el dominio «onmicrosoft.com«. El nombre seleccionado para el Tenant debe ser único y en general se usa el nombre principal de la organización. Por ejemplo Empresa1 podría ser «empresa1.onmicrosoft.com» y los usuarios incluidos en Empresa1 de forma predeterminada se autenticarían y tendrían una dirección de correo del tipo «usuario@empresa1.onmicrosoft.com«.
Dado que usualmente las organizaciones tienen un nombre público registrado en DNS, esta es una de las primeras cosas que se configuran dentro de Office 365, usualmente el dominio externo de la organización, en este caso «empresa1.com«. Para esto es necesario validar la propiedad del nombre DNS dentro de Office 365. Una vez realizado esto es posible autenticarse y usar direcciones de correo “@empresa1.com” (sin necesidad de usar el onmicrosoft.com).
Identidades en Office 365
Para el manejo de usuarios y otros objetos en la nube, Office 365 usa como directorio Azure Active Directory (AAD).
Tenemos varios tipos de identidades:
- Identidad solo en la nube (cloud only identity). Esto significa que los usuarios son creados y administrados directamente en la nube. Esto aplica a organizaciones que no cuentan con un servicio de directorio On Premises (en general Active Directory) o por algún motivo no quieren vincular las identidades locales con Azure AD. En este caso todo lo relativo a identidad y autenticación es manejado en Azure AD. La administración general de cuentas puede ser realizada desde el Office 365 Admin Center (https://portal.office.com) o mediante Windows Powershell. En la imagen a continuación se ve el caso de un administrador haciendo un cambio en el Centro de Administración de Office 365, por ejemplo creación de una cuenta, esto pasa por Azure AD y posteriormente queda visible el cambio en el Admin Center.
- Identidad sincronizada (Synchronized Identity). Esto aplica al caso de organizaciones que ya cuentan con usuarios configurados en Active Directory y se desea sincronizar estas identidades (de forma parcial o total) con la nube. Esto permite un cierto nivel de integración y habilita a escenarios híbridos. Para sincronizar información de Active Directory con Azure AD se utiliza Azure AD Connect, este es un servicio que se configura usualmente en un servidor dedicado y permite la sincronización de atributos y contraseñas (no en texto plano, sino que un hash) con Azure. De esta manera los usuarios pueden acceder a recursos locales así como recursos de la nube con los mismos datos de usuario y contraseña. A fines prácticos para el usuario sería como tener una única cuenta. Esta sincronización en general implica en primer instancia una etapa de ajustes donde entre otras cosas se chequea la configuración de determinados atributos y configuración de UPNs. Una vez realizado esto es posible avanzar con la configuración de la herramienta de sincronización (Azure AD Connect). En la imagen a continuación tenemos por un lado una organización con una instalación de Active Directory, Azure AD Connect configurado y sincronización de objetos y contraseñas con Azure Active Directory. En este caso la fuente autoritativa es Active Directory (on premises) por lo que los cambios se realizan localmente y posteriormente son sincronizados con Azure.
- Identidad Federada (Federated Identity). Este caso aplica a escenarios avanzados a nivel de autenticación, por ejemplo cuando es requerido Single Sign On (SSO). Este modelo también requiere la sincronización de identidades, pero en este caso el directorio que valida estas identidades es uno On Premises. Esto significa que mientras todo funcione correctamente no es necesario sincronizar contraseñas. Para esto se debe instalar un servicio adicional: Active Directory Federation Services (ADFS) pero existen alternativas de terceros (no Microsoft). En la imagen a continuación se ve un proceso similar que en el caso de identidad sincronizada (ya que aplica también a este escenario) y en adición aparece un nuevo servicio: ADFS, en este caso los usuarios “federados” obtienen un token de seguridad a través de ADFS y posteriormente es pasado a Azure AD por autorización para acceder a los distintos servicios de Office 365.
La tendencia actual en ambientes corporativos es ir por el modelo de identidad sincronizada con Azure AD y sin federación. El modelo de identidad federada implica mayor complejidad y mantenimiento, incluyendo más servidores y dependencias por lo que salvo que se cuente con requerimientos muy específicos, con la sincronización de cuentas y contraseñas en general es suficiente. Más info sobre los modelos de identidad y autenticación en el siguiente artículo:
Planes de Office 365
Office 365 se encuentra dividido en varias familias de servicios, a su vez cada familia incluye distintos planes:
- Office 365 Business
- Office 365 Enterprise
- Office 365 Educación
- Office 365 Gobierno
La selección del tipo de familia y plan varía en función al tipo de negocio. En este sentido Office 365 Business y Enterprise pueden generar cierta confusión, la principal diferencia entre estos 2 es la cantidad de usuarios soportados; Office 365 Business soporta un máximo de 300 mientras que Office 365 Enterprise soporta un número ilimitado de usuarios. En adición a esto existen otras diferencias muy específicas por ejemplo a nivel de cumplimiento pero estas pueden ir variando.
Licencias en Office 365
En Office 365 cada usuario activo requiere una licencia. Esta licencia es la que define que funcionalidad va a estar disponible para el usuario. Dentro de un Tenant es posible tener una combinación de licencias y dependiendo de los requerimientos qué tipo de licencia asignar a cada usuario.
Plan Enterprise
Este es el plan más común dentro de un entorno corporativo y E1 es el tipo de licencia más económica. Esta licencia incluye funcionalidad básica como acceso a Exchange Online, Sharepoint, Onedrive y Teams entre otros pero no incluye las aplicaciones de escritorio como Outlook y Word, esto es incluido dentro de Office 365 ProPlus (M365 Apps for Enterprise) o la licencia E3 que incluye las características del ProPlus + E1.
Actualmente el E5 es el más costoso e incluye funcionalidad avanzada. Por fuera de esto, como se mencionó anteriormente es posible combinar licencias de cada plan dependiendo de los requerimientos del usuario, para esto se adquieren pools de licencias y posteriormente se asignan a los usuarios en base a la funcionalidad requerida.
En relación a Office 365 ProPlus (desde el 21/4/2020: «Microsoft 365 Apps for Enterprise»), esto incluye las aplicaciones de escritorio (Office) y Onedrive. Independientemente de que exista esta opción es posible usar otras versiones de Office mientras se encuentren soportadas por Office 365.
Plan Business
El 21 de abril de 2020 Microsoft introduce algunos cambios en el nombre de las suscripciones orientadas a consumidor final y pequeños y medianos negocios, en todos los casos manteniendo la funcionalidad y costos. Desde entonces se usa como marca «Microsoft 365» en lugar de «Office 365». Este cambio también afecta al cliente de Office que pasa a ser Microsoft 365 Apps.
El nombre actualizado de cada suscripción quedaría del siguiente modo:
- Office 365 Business Essentials -> Microsoft 365 Business Basic
- Office 365 Business Premium -> Microsoft 365 Business Standard
- Office 365 Business -> Microsoft 365 Apps for Business
Como se mencionó anteriormente, este plan tiene un límite de 300 usuarios y esta orientado a pequeñas y medianas empresas.
En la imagen original de los productos se muestra con claridad lo incluido en cada uno (ver más abajo la tabla con los nombres actualizados):
Como se puede observar en la imagen original, el plan Office 365 Empresa o Business (ahora M365 Apps for Business) incluye aplicaciones de escritorio y acceso a OneDrive para almacenar documentos, el plan Office 365 Empresa Premium o Business Premium (ahora M365 Business Standard) incluye también acceso a servicios como Exchange Online y Sharepoint, por otro lado el plan Office 365 Empresa Essentials o Business Essentials (ahora M365 Basic)) incluye únicamente acceso a servicios (no aplicaciones de escritorio).
Tabla actualizada:
Con esto llegamos al final de esta introducción a Office 365. Si te interesa el tema podes suscribirte gratis al sitio con el formulario más abajo o dejar tus dudas en la sección de comentarios.
Por último algunos artículos relacionados:
- Microsoft 365 vs Office 365, cuál es la diferencia?
- Colaboración con grupos de Office 365
- Qué es una implementación Híbrida de Exchange?
- Qué es Exchange Online?
- Desmitificando entornos híbridos con Office 365
Hola es un buen resumen de introducción, les recomiendo hablar sobre las configuraciones híbridas para exchange y skype for business ya es bien importante comprenderlo en detalle
Me sumo en la parte de skype for business, y de que manera se pueden importar y/o listar / agregar automaticamente (ya que la lista esta vacia y la tarea es manual) los contactos que uno posee en el correo y/o directorio de la empresa internamente. Ya que si bien hay una opcion para ello, no nos ha funcionado jamas!….estimo que por lo que leo se trataba de una bug reportado, que supuestamente iban a corregir pero jamas paso y el skype quedo alli en el olvido.
Hola Daniel.
Tengo varias dudas, pero la primera es ¿Cómo puedo saber la IP real de origen de un correo en ambiente hibrido?, es decir saber si el correo fue enviado desde un PC, Dispositivo móvil Etc
Yo se que en el caso del servidor On-Premises puedes revisar los logs de los conectores y del IIS (OWA), habilitando el logging de los servicios / protocolos. En el caso de la nube estimo que eso lo tendras que realizar con powershell. Pero me sumo al pedido concreto y que seguramente Daniel sabra respoder con mas exactitud y profesionalismo.
Hola Julio / Gustavo, para obtener esa información habría que revisar en varios lugares. Dependiendo de si el buzón se encuentra On Premises o en Exchange Online a donde conectarse.
En el caso de Exchange On Premises habría que usar Message Tracking y en base a los datos obtenidos con esta herramienta buscar información del cliente en los logs de Internet Information Services. Lo más simple para analizar los logs de IIS sería con LogParser (pero esto sería opcional).
En cuanto a Office 365, se podría usar Message Trace ya sea desde el Exchange Admin Center o desde el portal de Security & Compliance (este sería el recomendado), hacer una búsqueda del correo y posteriormente ya con los datos del mensaje hacer una búsqueda de auditoría. En la auditoría se detalla información específica de cliente.
Hola buen día,
Estoy en la etapa de implementar el Híbrido de mi Exchange, ya tengo sincronizado mi directorio activo con Azure, queremos hacer la migración de algunos buzones a la nube para evaluar su comportamiento, mi pregunta en concreto es: ¿Necesito adquirir un certificado SSL UCC para lograr una correcta sincronía y seguridad de mis buzones? Actualmente mi certificado esta creado internamente y me comentaron que este no es suficiente para terminar el proceso del Híbrido.
Saludos.
Juan Alfonso,
Yo realice una implementacion hibrida express para luego pasar totalmente a la nube.
El certificado es un requisito cuando das de alta los registros en el DNS y para validar el dominio, yo realice un certificado temporal en la web de COMODO. No recuerdo si te dejan crear un SAN (Subject Alternatiove Name) poco recuerdo, creo que termine haciendo un Wildcard con*.MiEmpresa.com. espero haber despejado tus dudas. Una vez finalizada la sincro, que te permite hacer un SSO o conservar tu contraseña por cada usuario actual pero en office 365 y si decides pasarte totalmente a la nube, puedes desestimar o cortar el conector con AD local (te va a quedar el usuario especialmente creado para la sincro en la nube) y pasado 1 semana o menos, los atributos que antes no podias editar o eran limitados por cada user, se van a convertir en atributos editables y veras mas propios de ofice 365. Yo tuve que realizar una pequeña limpieza u acomodamiento de algunos Alias, lo que si te comento que el @tempresa.onmicrosoft.com lo tienes que pasar como secundario, péro nunca aliminarlo.
Espero haberte ayudado en algo.
saludos Gustavo J. Rodrigo
Hola Juan Alfonso, para el híbrido precisas un certificado confiable, en este caso un certificado público. No necesariamente UCC, pero en general es la opción más común. Esto puede variar dependiendo de los requerimientos.
Daniel,
Un consulta obvia que te hago a ti y que si bien se la respuesta, te lo consulto por las dudas.
Que pasa si se te corta internet respecto del correo interno y con una solucion puramente cloud. y que pasa si es hibrida, en ambos casos el flujo de correo interno (mas alla del bucle infinito entre un usuario en la nube y uno on-premises que no hay forma de solucionar, al menos yo no lo se) queda inutilizado cierto ?
Saludos.!
Hola Gustavo, si todos tus buzones están en la nube, el envío y recepción de correo no dependería de tu conexión a Internet. Si en cambio es una implementación híbrida y tenés buzones On Premises y otros buzones en Office 365, frente a la caída del enlace a Internet tus usuarios On Premises podrían enviar correos internos (entre ellos) y todos los correos salientes (hacia Internet u Office 365) quedarían encolados. Una vez reanudada la conectividad y dependiendo de la configuración, estos correos encolados se enviarían automáticamente en el próximo reintento.
En el caso de los usuarios en Office 365, durante el período de tiempo que estés con el enlace a Internet caído les funcionaría el correo entre ellos y hacia Internet (salvo que tengas una configuración de transporte centralizada donde los correos siempre deban pasar por Exchange On Premises). Lo que no les funcionaría es el envío de correo a usuarios que se encuentren On Premises, estos correos quedarían encolados. Una vez reanudada la conectividad se deberían entregar los mensajes en el próximo reintento.
Qué tal Daniel, gracias por esta oportunidad que nos brindas para exponer nuestras dudas. Como información estoy manejando un ambiente híbrido. Acá mis preguntas:
1.- Al momento de habilitar un buzón de O365 (remoto) por Powershell, aunque en el comando se coloque el Remote Routing Address, éste no queda registrado en el buzón On-prem y hay que agregarlo a mano. Creo que es un BUG de MS. Te ha pasado esto? cómo lo manejas?
2.- Las licencias se asignan por grupos de AD en On-prem. Hay casos donde se da de baja un usuario y luego lo contratan de nuevo (en poco tiempo, no más de 20 días) el usuario tenía licencia de 365 por estos grupos, luego se le quitan por la baja, y luego se agrega el usuario nuevamente al grupo de licencias. En estos casos, hay que asignarle la licencia directamente desde el portal o por PW, ya que no sincroniza bien. Te ha pasado esto también?
3.- Información que estaba en una «Nota» dentro del Outlook, se pierde parte del contenido de la misma.
Muchas gracias por tú ayuda.
Saludos!
Hola Carlos, respondo consultas:
1. En entornos híbridos, podes crear los buzones directamente en Office 365 (Buzón remoto) o podes crearlo On Premises y posteriormente moverlo a la nube. La opción que estampa todos los atributos necesarios es la 2da (crearlo on premises y moverlo a la nube). En definitiva, para evitar problemas, al momento te recomendaría primero crear el buzón en Exchange On Premises y luego moverlo a Office 365.
2. Te dejo un artículo de troubleshooting de problemas comunes usando licenciamiento en base a grupos:
https://docs.microsoft.com/es-es/azure/active-directory/users-groups-roles/licensing-groups-resolve-problems
3. Este punto no me queda 100% claro, te referís a que se migró un elemento pero le falta el contenido?
Saludos!
Hola Daniel
Gracias por la oportunidad de expresarnos y a la vez el tiempo en respondernos.
Tengo una consulta, si yo quisiera que la sincronizacion de un entorno híbrido sea bidireccional, que herramienta podría utilizar, sabiendo que el ad connect es unidireccional, que herramienta podría utilizar
Quedo muy agradecido por tu tiempo
Hola Jairo, en principio habría que entender bien el requerimiento específico. AAD Connect tiene características de writeback (por lo que ciertos atributos podrían ser sincronizados desde Azure AD al AD On Premises). Esto dependiendo del licenciamiento podría ser utilizado para varias cosas como por ejemplo sincronización de contraseñas (lo que habilitaría a que usuarios cambien la contraseña en la nube y esta se sincronice con Active Directory) o por ejemplo algunos atributos relacionados a Exchange para que funcione bien el entorno híbrido.
Hola Daniel, muchas gracias por transmitir tus conocimientos.
Mis consultas son las siguientes:
1. Tengo todas mis cuentas de correo en un servidor virtual de Zimbra (ver 8.7.11 GA), quiero migrar todas las cuentas con sus respectivos buzones hacia O365 pero deseo dejar este server de Zimbra siempre activo por aquello de dejar un respaldo de correos (que todos los correos queden copiados en Zimbra y posterior viajen a O365).
2. Si mi decision fuera migrar todas la cuentas y buzones y deshabilitar el server de Zimbra, existe alguna opcion o posibilidad de regresar todos los buzones nuevamente a Zimbra por si se decidiera no seguir pagando el servicio de O365 en un tiempo futuro.
Que requisitos, pasos, consideraciones se deben de tomar en cuentaq en los escenarios involucrados en mis consultas?
Hola estimado Daniel
Nuevamente agradecido por tu tiempo y conocimientos.
El escenario es un Ad local y los buzones en 365
Mi consulta es saber que herramienta propia de MS permitiría la sincronizacion bidireccional.
Para que pueda permitir hacer el cambio de contraseña desde el ad o desde el portal office
Saludos
Jairo Arteaga
Hola Jairo, ese requerimiento lo podes cumplir usando AAD Connect. La característica se llama «Password Writeback».
Te dejo un link a un artículo de Microsoft donde se detalla el funcionamiento y requerimientos a nivel de licenciamiento:
https://docs.microsoft.com/es-es/azure/active-directory/authentication/concept-sspr-writeback
Hola Lester, lo primero sería definir qué mecanismo usar para la migración, si usar herramientas de terceros o herramientas nativas de Office 365. En este caso la migración de datos sería una copia por lo que no debería afectar los buzones en origen.
Una vez con los buzones en Office 365 sería posible cambiar los registros en DNS para los correos dejen de pasar por el Zimbra y pasen directamente por O365.
En caso de rollback, nuevamente dependería de las herramientas que tengas a disposición.
El proceso no es tan simple como para detallarlo en un comentario por lo que te dejo un link a un artículo de Microsoft que te puede ser util como para tener algunas lineas generales:
https://docs.microsoft.com/es-es/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes
Tengo una consulta, en nuestra compañía contamos con directorio activo onpremise implementado la verdad a medias, el provecho que le damos es poder darle inicio de sesión a los usuarios en el sistema operativo al encender la máquina (acceso a windows). Ahí le cambiamos la contraseña cuando la olvidan y no mas.
No tenemos exchange ni servidor de correo, nuestro correo es hosteado en un servidor externo de un proveedor a través de Zimbra.
Nosotros queremos irnos a OFFICE 365, pero tengo la INQUIETUD, si nosotros tenemos necesariamente que hacer sincronización entre el directorio activo onpremise (el que está a medias) y el directorio activo de Azure. Lo pregunto por dos motivos, el uso que le damos al active directory on premise hoy, la versión del mismo 2008 y los costos de consultoria para ello que nos cobran. Si el valor agregado que nos daría unicamente serían el hecho de iniciar sesión en ambos lados con un mismo usuario y contraseña, que es ventajoso pero igual podemos convivir con ello.
Lo que si me preocuparía es que por no querer hacer la sincronización e invertir ese dinero de consultoría, NO pueda aprovechar el outlook para ver los correos tanto en web como en onpremise.
Es decir Outlook instalado será la aplicación que algunos usuarios podrán utilizar segun la licencia para ver su correo, y no solo sobre el navegador. El hecho de no haber hecho esta integración de directorios, me impedirá que los correos me bajen de la nube hacía mi outlook instalado?.
Muchas gracias.
Hola Paulo, la realidad es que dependiendo del porte de la organización y de los requerimientos si es importante la sincronización del directorio On Premises con Azure Active Directory o no.
Si son pocas cuentas y no tienen ningun requerimiento específico que implique esta integración quizás en tu caso no valga la pena.
La sincronización de directorio en principio no tendría relación con el mecanismo de acceso al correo, podrías no tener Active Directory On Premises y unicamente usar las cuentas en Office 365 (Azure).
Te recomiendo revisar la serie de artículos dedicados a Office 365 / Azure que hay en el sitio comenzando por el siguiente:
https://aprendiendoexchange.com/introduccion-office-365
El resto de los artículos serían los incluidos en el Capítulo XII del manual para aprender Exchange:
https://aprendiendoexchange.com/aprender-exchange
Buenas, primero que todo muy buen aporte, este articulo. Lo que no me queda claro es que con las nuevas licéncias de Microsoft365, para tener Office ProPlus multisesión para entornos de sesión remota para usuariosn, que licéncia tenemos que contratar si tenemos los servicios de Microsoft365 como Exchange y algun otro activo?
Muchas gracias Daniel
Hola Marti, el Proplus cambió de nombre pero el licenciamiento es el mismo.
En principio cada usuario debe tener una licencia que incluya el Proplus o M365 Apps independientemente de como se conecten al equipo.
Hola , como estas?. te hago una consulta , tengo unos grupos creados en el office365 que son del tipo de seguridad y seguridad habilitada para correo, y de estado , sincronizado desde el entorno local, y otros grupos que son de tipo microsoft 365 y estado en la nube, quisiera saber si se puede tener todo en la nube, osea ,si se puede migrar de alguna forma los de entorno local??. Te agradeceria mucho si me podes oriengtar con algo, muchas gracias.
Abrazo.
Maximiliano
Hola Maximiliano, como poder es posible, el tema si es la solución para tu entorno.
Si ya no vas a mantener un entorno híbrido es posible sincronizar lo que se necesario, hacer la migración y una vez finalizado dejar de sincronizar los objetos y hacer los cambios para que queden en la nube de forma autoritativa. Pero como te digo esto depende mucho de tu entorno y de los requerimientos.
Daniel, buenas tardes
actualmente en mi empresa tenemos un tenant office 365 con una combinacion de usuarios en el modo 365 standard y 365 premium, mi pregunta es: que cantidad maxima es la que puedo tener de cada modo dentro de un tenant, del modo standard tengo 300 y en premium tengo 202, sabes si el limite de 300 es para cada modo o en combinado