Microsoft Teams: Tres detalles a tener en cuenta en la migración a Direct Routing
Hoy voy a comentaros un par de detalles sobre la migración a Direct Routing desde CloudPBX de Microsoft, los cuales os evitarán algunos problemas en el momento de la migración. El proceso es muy sencillo, pero como sabéis, al final en los pequeños detalles es donde se logra el éxito o “no éxito” (fracaso nunca) del paso de CloudPBX (Microsoft Phone System) a Direct Routing.
Ahora voy a contar realmente lo que comentaré, porque cuando inicié el boceto para la infografía de este artículo se me han ido presentando ideas que al final me han cambiado/ampliado “un poco” el alcance de dicho artículo. No voy a entrar en detalle, porque sería imposible, pero voy a comentar alguno de los procesos más “críticos” que hay en el proceso de migración a Teams con Direct Routing:
- Migración desde PBX-IP a Skype For Business
- Migración desde Skype for Business a Teams (Cloud PBX o Microsoft Phone System)
- Migración de CloudPBX a Direct Routing
Insisto, solo voy a comentar lo que considero más importante a tener en cuentan en dichas migraciones, pondré enlaces a algunos artículos que tengo sobre ello y luego comentaré con más detalle el proceso de migración a Direct Routing. A continuación, os muestro la infografía con algunas de las tareas más importantes en los procesos de migración:
Vamos a empezar por comentar la migración desde una PBX-IP hacia Skype for Business, estos son los hitos más a tener en cuenta (fuera de la instalación de SkypefB):
- Trunk SIP: durante los procesos de migración a Skype, es muy probable que queramos mantener un entorno dual durante algún tiempo. Para esto, debíamos conectar Skype con la PBX-IP, de tal forma que podamos conectar a los usuarios de teléfonos físicos con Skype y al revés.
- Funcionalidades: con Lync/SkypefB damos un salto de calidad hacia las Comunicaciones Unificadas: Mensajería, Voz, Audio/Video, algo que hasta la fecha no existía en las empresas o no estaba muy extendido.
- Federación: se nos ampliaba la posibilidad de comunicarnos de forma nativa con otras empresas con Lync/Skype, además de los usuarios de Skype de Consumo.
- Dominios: podemos disponer de un Skype For Business Server pero albergar usuarios de varios dominios, algo que era fantástico para empresas con múltiples dominios
- Red de Datos: algo que siempre ha sido crucial es el desempeño de la red de datos, puesto que, con la llegada de la VoIP ya era “todo datos”. Ya se tiene que tener en cuenta otro tipo de servicios de red, que, hasta la fecha no se habían tenido en cuenta: QoS, Vlan, etc..
- Lync Server: Asignar a una VLAN de Voz a los Teléfonos Polycom CX600 desde un DHCP Server de un Switch Cisco
- Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV)
- Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte II de IV)
- Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte III de IV)
- Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte IV de IV)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte I)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte II)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte III)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte IV)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte V)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte VI)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte VII)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte VIII)
- Esquemas de red para nuestras implementaciones de Lync Server (Parte IX)
Una vez completada la integración con la PBX-IP, estaba el deshacerse completamente de ella, entonces teníamos que configurar un Trunk SIP con un ITSP y portar la numeración desde nuestro operador de voz tradicional (Vodafone, Telefónica, etc..) hacia un proveedor de VoIP. Y una vez completada la portabilidad, ya éramos 100% IP para los servicios de datos y voz. De momento, todo esto era desplegable en On-Premises, por lo que obligaba a disponer de un entorno “complejo” (ADDS, SQL, Exchange, Reverse-Proxies, etc..) y contar con Exchange On-Premises para dotar a los usuarios de buzón de voz. Pero, eso sí, teníamos capacidades de manipulación de las llamadas de Voz de forma sencilla desde Skype:
Poco a poco, Microsoft ha ido incorporando servicios de O365, los cuales podíamos configurar e ir introduciendo el concepto de híbrido conocido hasta el momento para Exchange, pues ahora para la solución de Skype For Business. Para ello, el 1 de Febrero de 2017 llegó el servicio de Microsoft Phone System: Skype For Business RTC Online ya disponible en España. El cual no permitía varios escenarios:
- CloudPBX: solución 100% nube de VoIP por parte de Microsoft, vamos, dotar a los usuarios de llamadas en la nube pagando planes de minutos los cuales perduran:
- Cloud Connector: servicio que permitía migrar a nuestros usuarios a Skype Online pero seguir utilizando los servicios de VoIP de On-Premises, lo que nos permitía seguir utilizando nuestros proveedores de VoIP para realizar y recibir llamadas
En este enlace “Skype For Business RTC Online ya disponible en España” se describe el proceso de habilitar usuarios en Skype For Business Online con servicios de VoIP habilitado para nuestros usuarios. Pero mientras tanto, podíamos tener la integración de Skype For Business On-Premises con Exchange Online, por lo que podíamos tener nuestros con buzones de correo y buzón de voz en Exchange Online y sus cuentas de Skype For Business en On-Premises:
En este artículo os cuento un paso a paso de como migrar vuestros usuarios de Exchange On-Premises a Exchange Online, entiendo en cuenta el impacto en la red de datos y el proceso completo de migración.
Todo esto además, nos obligaba a conocer un montón de tecnologías, no solo Skype:
- Active Directory
- Microsoft Exchange
- Reverse-Proxies
- Certificados
- Redes de Datos
- VoIP
Aquí os dejo un artículo donde comento en un determinado momento, que hacía falta conocer para ser un buen ingeniero de soluciones de Comunicaciones Unificadas de Microsoft: ¿Qué conocimientos necesito para ser un ingeniero Comunicaciones Unificadas?. Esto no lo hacía más complejo, pero si que los técnicos encargados de despliegues fuesen más especialistas en muchas tecnologías. Por “alusión” al tema, aquí os dejo un enlace de descarga a mi libro de instalación de Lync paso a paso que sirve perfectamente para Skype For Business (pulsar en la imagen para descargarlo):
Con la llegada de Skype For Business Online con VoIP, a muchos de nosotros nos apetecía dejar de mantener soluciones On-Premises y consumir únicamente el servicio (SaaS). Para esto, teníamos que migrar nuestro Skype For Business a Online:
- Migrar SkypefB On-Premises a SkypefB On-Line CloudPBX
- ¿Migrar a CloudPBX o un entorno híbrido con Cloud Connector de Skype For Business?
- ¿Migrar a CloudPBX o un entorno híbrido con Cloud Connector de Skype For Business? (Parte II)
Dentro de este proceso, habría que tener en cuenta el proceso de portabilidad de nuestra numeración a Microsoft. De tal forma que, ya podemos recibir llamadas con nuestros números de teléfono que hasta la fecha teníamos con nuestro ITSP habitual. El proceso completo de migración viene descrito en esta imagen, no solo la portabilidad (con la llegada de la pandemia las portabilidades suelen retrasarse hasta 30 días):
En ocasiones, sino migrabas por el manual, podías hacerlo a las “bravas” y para ello también había un proceso “no documentado”:
No es lo que deberíamos hacer, pero sino nos quedaba otra, teníamos la alternativa que os he mostrado. Habilitar usuarios en Skype For Business Online y eliminar manualmente toda referencia al Skype For Business en nuestro Active Directory. Y hasta aquí, si hemos migrado todo a Skype For Business Online (incluido la VoIP), ya estamos 100% en nube, cero infraestructura a mantener por nuestros equipos de IT.
Cuando ya estábamos con Skype for Business Online/On-Premises a tope, llegó la irrupción de Teams y todo su ecosistema: Microsoft Teams: Primeros Pasos + Administración + Migración + Seguridad
- SharePoint
- OneDrive
- Exchange
- CloudPBX
Y aquí es onde irrumpe claramente ya Teams, pero aún faltaba la posibilidad de poner utilizar nuestros proveedores de VoIP para cursar las llamadas, solo tenía la posibilidad de contratarlo con Microsoft. Funciona muy bien, pero no teníamos integración con sistemas locales y el coste .. pues digamos que .. es más barato contratar las llamadas con tu ITSP (más o menos un 60% con respecto a Microsoft), pero sin bien es cierto que Microsoft se encarga de todo, tú solo configuras y consumes el servicio. Esto sigue siendo un entorno 100% SaaS, cero infraestructura a mantener por el equipo de IT.
Pero ya con la llegada de Direct Routing, se nos abre un mundo de posibilidad de interconexión local y poder utilizar nuestro ITSP para cursando las llamadas por donde queramos. Tenemos múltiples fabricantes de SBC certificados donde podemos elegir, con el que nos sintamos más cómodos: Lista de controladores de borde de sesión certificados para el enrutamiento directo
Luego cada cual tiene su propia configuración, yo en su momento he publicado como configurarlo con AnyNode:
- Microsoft Teams: Configuración de Direct Routing vía SBC de AnyNode en Azure
- Microsoft Teams: Configuración de tu SBC con Múltiples Tenants e ITSP
- Direct Routing: Normalización de Teléfonos de Usuario en Llamadas Entrantes
Por ser simple, al final un SBC es un software (virtualizado o en un bundle de hardware) que nos permite conectar por un lado el mundo de Teams y por otro sistemas analógicos, troncales, etc… vamos, interconectar Teams con otros sistemas de VoIP. Claro, con esto, ya podemos conectar a nuestros usuarios de Teams con nuestro ITSP y ya pueden realizar y recibir llamadas sin problema y con un entorno “híbrido” en cuanto a la plataforma ser refiere.
Por que digo que es híbrido, porque el SBC es algo que nosotros tenemos que adquirir, configurar y mantener, pero que como es algo virtualizable lo podemos dejar en Azure, Aws, etc.. por lo que no necesitamos desplegar nada en nuestras oficinas. Por otro lado está Teams, 100% SaaS, de ahí mi concepto (mal o bien llevado) de híbrido. Con este entorno, ya estamos en un entorno IaaS (Azure por ejemplo para tener allí nuestro SBC) y SaaS (Teams en Office 365). Algo que, a buen seguro, se ajusta al 95% de las empresas, porque ahora podemos reducir el coste de las llamadas/licencias necesarias y el coste de mantener el SBC es mínimo o “residual”.
Desde aquí, lo importante desde este artículo
Hasta aquí un rápido recorrido entre un entorno PBX-IP, pasando por SkypefB Server y llegando a Teams con CloudPBX. Aunque ya he comentado la inclusión del SBC, ahora os voy a comentar que debemos tener en cuenta cuando tenemos a nuestros usuarios en CloudPBX y los queremos mover a Direct Routing.
Sacando las configuraciones que haya que hacer, las técnicas para implementar el SBC (Microsoft Teams: Configuración de Direct Routing vía SBC de AnyNode en Azure), quiero comentar dos cosas que ocurren cuando modificamos las licencias de los usuarios (cuando retiramos los planes de llamadas:
- Quitar Planes de Llamadas (no la licencia de Phone System): el usuario queda deshabilitado para VoIP y Buzón de Voz (EnterpriseVoiceEnabled $False -HostedVoiceMail $False)
- Colas de Agentes: ya no podemos asignar agentes a las colas de llamadas de forma individual
- Números de usuario: al no tener plan de llamadas ya no tendrán números de usuarios
Pues bien, como se “corrige” esto, pues de la siguiente forma:
- Habilitar Usuarios para Voz: debemos habilitarlos nuevamente para VoIP, para ello tenemos el siguiente cmdlet:
- Usuario único: Set-CsUser -Identity <nombre-usuario> -EnterpriseVoiceEnabled $True -HostedVoiceMail $True
- Múltiples usuarios: Get-CsOnlineUser | Set-CsUser -EnterpriseVoiceEnabled $True -HostedVoiceMail $True
- Colas de Agentes: debéis crear grupos de Office 365, Seguridad o Listas de Distribución para configurarlos en vuestras colas. Si ya teníais usuarios asociados a las colas, en cuestión de días dejarán de funcionar.
- Números de usuario: si queremos asignar números de usuario una vez migrados a Direct Routing, se los tenéis que pedir a vuestro ITSP y aquí os muestro como se configuran: Direct Routing: Normalización de Teléfonos de Usuario en Llamadas Entrantes. Básicamente es configurar el SBC y asignar el número directo vía PowerShell a cada usuario: Set-CsUser -Identity <nombre-usuario> -OnPremLineURI Tel:+XXXXXXXXX
Estas son las tres cosas por las que he empezado este artículo, espero que por lo menos estas dos cosas hayan quedado claras y no os hayáis agobiado por el resto del artículo. Simplemente quería dar algo más de información, algo superficial, pero era para que tengáis en cuenta algunos esfuerzos que hay que tener en cada fase, pero claro, no lo puedo comentar todo en un sólo artículo.
Espero que os sean de ayuda, porque al final son dos chorradas, que si las tenemos claras no tendremos problemas, sino tendremos a 10 o 10000 usuarios sin poder llamar por no tenerlo en cuenta (sobre todo el primer punto).
