VoIP
Parte III: Microsoft Teams DR en Azure – Configuración básica del SBC
DESPLIEGUE DE AUDIOCODES SBC VE EN AZURE
En esta 3ª entrega vamos a ver la configuración básica del SBC, en este articulo vamos a explicar:
- Prerrequisitos de la implementación
- Configuración básica de Seguridad
- Configuración TLS
Prerrequisitos de la implementación
¿Qué necesitamos para la configuración?
- Certificado Publico con al menos un SAN, no hace falta que sea multi SAN.
- Dar de alta en el DNS publico el FQDN del SBC
- Diseño de puertos y protocolos.
| To SIPTrunk | Proxy Set | 5061 |
| Señalización | UDP – TCP 5060 | |
| Media | 6000 – 6500 | |
| To TEAMS | Proxy Set | 5061 |
| Señalización | TLS – 5067 | |
| Media | 7000 – 7500 |
- Direccionamiento IP de Teams
52.114.148.0 | 52.114.132.46 | 52.114.75.24 | 52.114.76.76 | 52.114.7.24 | 52.114.14.70
sip.pstnhub.microsoft.com | sip2.pstnhub.microsoft.com | sip3.pstnhub.microsoft.com
Diseño de puertos y protocolos
En el diseño final quedaría de la siguiente manera.
Por un lado, tenemos la parte de Direct Routing, que conecta el SBC con Teams, para ello nos registraremos con el Proxy Set 5061, la señalización es SIP/TLS por el puerto 5076 y el trafico de MEDIA es el rango 7000 – 7500. En el caso de la PSTN, Tenemos la IP del SipTrunk contra el que nos registramos por el puerto 5061, pero en este caso la señalización es SIP/UDP_TCP 5060 y la media el rango 6000 – 6500
Configuración Básica de Seguridad
Antes de entrar en la configuración básica del SBC sera necesario que veamos en AZURE que la configuración del Firewall permitirá el tráfico entre los puertos y direcciones que necesitamos. Para ello haremos lo siguiente:
- Entramos en portal.azure.com
- Vamos al “Grupo de Recursos” donde tenemos el SBC desplegado
- Seleccionamos la interfaz de red “eth 0”
- Dentro del menú de propiedades seleccionamos “Reglas de Seguridad Vigentes”
- Ahora nos aparecen todas las reglas de Seguridad de Firewall, tanto de entrada como de salida
Desde aquí podemos comprobar según los datos que tenemos previos si la configuración de seguridad nos permitirá el trafico por los puertos y con los protocolos que hemos definido en el diseño, este es un paso importante que nos ahorrara muchos quebraderos de cabeza a la hora de registrar el SBC tanto en Teams como con nuestro Operador de SipTrunk.
En este apartado podemos limitar más la comunicación y seguridad, las reglas por defecto son genéricas, pero podemos tanto modificando el Firewall de Azure, como el propio que trae el SBC para añadir solo las direcciones IP necesarias en la comunicación y que el resto se descarte. Para ello realizare un artículo especifico de Seguridad.
A continuación, veremos la configuración Básica de seguridad en el SBC:
- Entramos en el sbc emeasbc.zertia.es
- Vamos al menú, Setup / Administration / Web & CLI y seleccionamos CLI Settings
- Dentro de la configuración deshabilitamos “Embedded Telnet Server”
NOTA: Cada cambio de configuración nos pedirá hacer un “Save” después d realizar, esto es necesario para terminar de aplicar el cambio
- Ahora vamos al menú Setup / Signaling & Media / Core Entities y seleccionamos SRDs
- Seleccionamos el SRDs por defcto, y en Registration ponemos:
Configuración NTP
Ahora vamos a ver cómo podemos configurar correctamente el NTP, este apartado es importante, es necesario que el SBC tenga correctamente la fecha y hora para el registro del Enrutamiento directo de Teams.
Para configurar el NTP vamos a:
- Seleccionar SETUP / ADMINISTRATION y entrar en TIME & DATE
- Habilitar el NTP y poner la dirección IP, en mi caso como el SBC tiene salida a Internet he puesto el NTP del Ejercito, en el caso de que el SBC lo tengamos en un entorno On-prem, podremos poner el NTP local que suele ser un controlador de dominio, en este caso habrá que asegurarse de que los puertos y protocolo NTP este abierto y haya comunicación con el mismo.
- Comprobaremos que la configuración es correcta viendo en Time Zone que la hora y fecha está bien.
- En el mismo apartado podemos habilitar “Daylight Saving Time” donde podremos configurar el cambio de horario de verano e invierno
NOTA: Antes y después de cualquier cambio de configuración se recomienda guardar una copia del Fichero de configuración *.ini
Parte II: Microsoft Teams DR en Azure – Despliegue y configuración del SBC en Azure
DESPLIEGUE DE AUDIOCODES SBC VE EN AZURE
En el siguiente articulo vamos a explicar como desplegar nuestro SBC de Audiocodes en AZURE, para ello deberemos seguir las siguientes instrucciones:
- Entramos en el portal de Azure https://portal.azure.com/
- Vamos a Todos los servicios, y después buscamos Marketplace (All services > Marketplace).
- Buscamos “Mediant VE Session Border Controller (SBC)” y después pulsamos en “Crear”
- Lo primero de todo, deberemos rellenaremos la configuración básica del SBC, nos basaremos siempre en el diseño y arquitectura inicial.
- Virtual Machine Name: emeasbc
- Username: sbcadmin
- Contraseña: *******
- Suscripción: Visual Studio Enterprise – MPN
- Grupo de Recursos: SBCRESOURCES
- Ubicación: Oeste de Europa
NOTA: En este caso, debemos tener en cuenta varios aspectos, por ejemplo:
El usuario y clave que creemos durante el despliegue sustituye al usuario Admin por defecto que trae las implementaciones on-prem de Audiocodes.
Para más información de las suscripciones de azure visitar el siguiente enlace https://docs.microsoft.com/es-es/azure/azure-subscription-service-limits
Para más información sobre las ubicaciones de Azure, visitar https://azure.microsoft.com/es-es/global-infrastructure/locations/
¿Qué es un grupo de recursos en Azure? https://docs.microsoft.com/es-es/azure////azure-resource-manager/resource-group-overview
- Ahora, vamos a configurar las opciones avanzadas:
- Capacidad de nuestra máquina virtual: Aquí según nuestra suscripción tendremos limitaciones, pero es cierto que el SBC es capaz de funcionar con una maquina de no mucho rendimiento. Yo en este caso, mi recomendación es ir a algo medio, pero eso sí, hay que tener en cuenta las limitaciones del fabricante. Por ejemplo: Si necesitamos transcoding sera mejor poner al menos 2 CPU. Mi recomendación en estos casos es que el rendimiento de la maquina no es necesario que sea el mejor, pero quizás si es bueno invertir mas en Alta Disponibilidad (HA) o en las comunicaciones.
- Habilitar o no “Boot Diagnostics”
NOTA: Si algo es destacable en una implementación en Azure es la capacidad de escalabilidad o lo que llamamos “elasticidad” esto quiere decir, que podemos empezar con un SBC básico para los 60 usuarios de nuestra implementación con quizás 10 o 20 sesiones sería suficiente, y después podemos ir aumentando las capacidades de nuestra maquina según vayamos necesitando más recursos.
Es recomendable leer previamente al diseño las Realease Notes de las últimas versiones de SBC Audiocodes
https://www.audiocodes.com/media/13231/sbc-gateway-msbr-series-release-notes-ver-72.pdf
- El tercer paso sera configurar la Red, basándonos en el diseño inicial. Lo mejor en estos casos es configurar el grupo de recursos y las redes antes del despliegue, pero también podemos ir haciéndolo según vayamos desplegando la máquina.
- Crearemos la red Virtual 10.0.0.0 /16
- Ahora crearemos las subredes, la que nos conectara con el SipTrunk que hemos llamado VoIP y la de Direct Routing que es la subred de Teams.
- Ahora marcaremos la IP publica como “estática” en este caso nos configura la IP de la Subnet de Teams, después veremos cómo habilitar la otra red
- De manera opcional podemos cambiar el DNS con el que aparecerá dentro de Azure nuestra maquina
Una vez terminemos la configuración y pulsemos en Aceptar, veremos el resumen de toda la configuración y podremos comprar el SBC
ASIGNAR UNA IP PUBLICA AL INTERFAZ SIPTRUNK
- Desde el portal de Azure, vamos a “recursos” y entramos en el grupo de recursos donde tenemos nuestra maquina SBC
- Seleccionamos el recurso, en este caso la tarjeta Ethernet1, ya que la 0 se configura por defecto en el primer despliegue
- Ahora seleccionamos “configuraciones IP” del menú de la izquierda
- Habilitamos la dirección IP Pública
NOTA: Para acceder a la configuración y ver que se ha desplegado bien el SBC, con la dirección IP publica de la Interfaz Eth 0 desde un navegador entraremos al SBC
En el siguiente articulo veremos los prerequisitos necesarios para la configuración del SBC para la integración de Teams, (Puertos, Códecs, IP’s, Certificados, DNS, etc…)
Parte I: Microsoft Teams DR en Azure – Diseño y arquitectura de la solución
DESPLIEGUE DE ENRUTAMIENTO DIRECTO (DR) DE TEAMS EN AZURE
Introducción
Con la llegada del concepto de Informática en la nube “Cloud” haya por el 2010 y en el momento en el que se ha consolidado como una tecnología emergente dando solución a millones de empresas en todo el mundo, han sido numerosos los fabricantes que han apostado por dar sus soluciones en entornos de nube publica, privada o hibrida. Pero especialmente en el caso de la telefonía y las comunicaciones de voz con la PSTN ha sido de especial avance tener una solución SBC virtual en la nube, como es el caso de Audicodes o Ribbon dos de los principales fabricantes que integran la PST con Direct Routing de Teams.
Parece que aun fue ayer, cuando configurábamos los primeros Mediation Server de Lync 2010, en los que no estaba ni soportado en un entorno virtual, estos “roles” se tenían que montar de forma física y ahora con el paso de los años tenemos una solución pura en la nube, en la que podemos tener una arquitectura que no tiene nada que envidiar a aquellas PBX de VoIP que se montaban en al menos dos armarios en un CPD.
Ahora con un coste muchísimo mas barato tenemos una solución de Telefonía tradicional conectado a nuestra aplicación de colaboración por excelencia de Microsoft Teams.
Lo único que necesitaremos sera hacer un buen diseño y arquitectura de la solución y a continuación desplegarlo, para ello voy a crear una serie de artículos en el Blog, que irán desde el diseño lógico, hasta la configuración del SBC pasando por el despliegue en Azure.
Antecedentes
Tenemos una empresa de unos 60 usuarios, en los que actualmente tiene una PBX 3Cx. Esta empresa ya tiene un Tenant en O365 con licencias E5 (Incluye la opción de llamadas telefónicas) y ya usa Microsoft Teams como herramienta de colaboración. Ahora quieren migrar su sistema de Telefonía de VoIP a Teams.
Objetivo
Dar servicio de voz a los 60 usuarios de la empresa, a través de Enrutamiento Directo de Teams, desplegando un SBC en AZURE. El SBC que vamos a utilizar para este laboratorio sera uno de Audiocodes.
Diseño y Arquitectura
Como se puede ver en Diseño. El Servidor en Azure esta conectado a una Red (SBC_VNET) a su vez tiene dos Interfaces, una que se conectará a Teams y otra sera el SIPTRUNK del Operador que son proveerá de Telefonía. Cada interfaz de red esta conectada a una SubNet, (Subnet-teams y Subnet-VoIP) estas subredes tienen una IP Privada. De cara a Internet habrá un NAT con dos IPs públicas.
NOTA: Para cualquier despliegue en el que se vean implicadas comunicaciones de Voz o de Video, hay que tener en cuenta las líneas de comunicaciones, es importante tener un buen ancho de banda, y además es importante concienciar al usuario final o al cliente para que sepa que este tipo de soluciones dan mucha flexibilidad a la hora de poder realizar una llamada de teléfono desde nuestro dispositivo conectados en cualquier lugar, por ejemplo estando de viaje de negocios desde un hotel podemos asistir vía teléfono a una conferencia con Teams, pero si la conexión wifi del usuario final es de mala calidad, podrá afectar a la comunicación.
En el próximo articulo explicaremos el despliegue del SBC de Audiocodes en Azure.
Parte II: Microsoft Teams DR en Azure – Despliegue y configuración del SBC en Azure
CREAR UN “TENANT” EN OFFICE 365 PART 3 – Configuración DNS
CREAR UN “TENANT” EN OFFICE 365 PART 3
Configuración DNS
Una vez tenemos creado el Tenat en Office 365 necesitaremos configurar nuestro DNS Publico para que la comunicación del trafico vaya contra el Tenant.
En este caso, no tengo ninguna configuración en local, por ejemplo, un servidor de correo electrónico Exchange Server. Puede darse el caso de que tengamos una infraestructura local en el cliente. Ojo con esto, porque al configurar el DNS publico podemos afectar estos servicios, lo cual habrá que hacer estos cambios de forma paulatina y controlada.
En el caso de que tengamos ya infraestructura de correo o de Skype for Business, habrá que plantear una migración o un entorno hibrido.
Pero en este caso, no tengo ninguna infraestructura en local, con lo cual es una configuración Office 365 pura.
Para configurar el DNS de Office 365 necesitaremos acceso a nuestro DNS Publico, en este caso mi dominio, mrlync.com esta alojado en WordPress. Utilizare la configuración de WordPress para añadir las entradas en el DNS.
1.- Configuración DNS en Office 365
Lo primero que haremos será conectarnos a Office 365 con las claves de Administrador del Tenant y una vez dentro iremos a:
Dominios > Agregar un Dominio
Agregamos el Dominio “mrlync.com”
Ahora nos pide que hagamos una comprobación del dominio, en este caso utilizaremos la opción del registro TXT
Cuando le damos a siguiente, nos dirá que datos necesitamos añadir a nuestro DNS para hacer la comprobación.
Este registro la añado al DNS Publico de WordPress, mas adelante explico como configurar los DNS desde la pagina de WordPress
Una vez añadido el registro en mi DNS, daremos a comprobar dese la pagina de Office 365 donde estábamos configurando el Dominio.
Una vez que Office 365 sabe que somos los propietarios del dominio mrlync.com continuaremos la configuración de los registros DNS en Office 365, en este caso vamos a elegir la opción de configurar nosotros nuestro propio DNS, para realizar la configuración manual de los registros, al final, es la mejor manera de aprender.
Seleccionaremos los servicios en línea, como ya he comentado antes, en este caso, no hay ninguna configuración previa, cuidado con esto, porque si ya tenemos una configuración de Skype for Business o Exchange habrá que hacer una configuración hibrida o un proceso de migración.
En la siguiente pantalla veremos todos los registros que necesitamos configurar. En este caso son estos.
2.- Configuración DNS en WordPress
Una vez tenemos la lista de las entradas DNS que necesitamos incluir en nuestro proveedor de DNS publico, iniciaremos la configuración, en este caso usare Wordpres.
Para iniciar la configuración, entramos como administradores en WordPress, después vamos al panel de configuración y seleccionamos Dominios.
Ahora seleccionamos el dominio, en este caso “mrlync.com”
Seguidamente seleccionamos “servidores de nombre y DNS”
Y después en “Registros DNS” podremos añadir las entradas correspondientes.
2.1 – Ejemplo de entrada MX
Ahora vamos a ver como añadir la entrada de tipo MX necesaria para O365 en Wordpres
Siguiendo la tabla de configuración de Office 365 añadimos los campos en WordPress y damos a Añadir nuevo registro y veremos que nos aparece en la configuración
Ahora desde la pagina de O365 podremos hacer una comprobación, quizás hay que esperar a que replique el cambio, esto no es inmediato.
2.3 – Ejemplo de entrada CNAME
Ahora vamos a ver como añadir un registro CNAME, los registros que necesitaremos son:
Desde la pagina de Administración de WordPress incluiremos la entrada de SIP para Lync / Skype online.
Una vez hayamos incluido las entradas CNAME, podremos hacer la comprobación desde la pagina de O365
2.4 – Ejemplo de entrada TXT y SRV
En las siguientes imágenes viene un ejemplo para registros TXT y SRV en wordpress
Una vez hayamos añadido todas las entradas DNS en nuestros proveedor, hacemos la comprobación desde O365
Implementar “Call Admission Control – CAC” en Skype for Business. Parte 1
Después de un tiempo sin pasar por aquí, hoy voy a escribir sobre la herramienta de Skype for Business llamada CAC (Call Admission Control), herramienta que ya existía en las versiones anteriores Lync. A muchos de los Administradores o Implementadores de Skype/Lync la palabra CAC en un proyecto nos supone un gran quebradero de cabeza, porque muchos de nosotros no somos administradores de Networking y para implementar CAC es necesario un buen diseño de red de la implementación. Para empezar a conocer que es CAC deberemos de conocer en que consiste.
¿Qué es el Call Admission Control – CAC?
Básicamente es un servicio de control y administración de Ancho de Banda con el que se limitara el numero de llamadas simultaneas a través de enlaces de ancho de banda limitado, como es una red WAN, de esta manera evitaremos la degradación de la red.
¿Por qué implementar CAC?
Básicamente en muchos entornos en los que te enfrentas a un despliegue de Skype/Lync la gran preocupación es como soportará la red del cliente la carga que supone desplegar VoIP y videoconferencia ya que estas requieren un alto ancho de banda y baja latencia para ofrecer un buen servicio de calidad. En muchas ocasiones el cliente no tiene disponibilidad de contratar un ancho de banda suficiente para que la comunicación de VoIP y video en sus sedes remotas, en estas ocasiones lo mejor es por nuestra parte hacer un calculo de ancho de banda para que el cliente sepa las necesidades, pero además también se puede optar por implementar QoS o en este caso Call Admisión Control – CAC.
En otros artículos explicare como hacer un calculo de ancho de banda y como implementar QoS en Skype/Lync
¿Cómo funciona CAC?
La política de CAC se aplica entre usuarios de distintas sedes que están conectados a través de una red WAN. La política de CAC se comprueba antes de que uno de los puntos implicados acepte la llamada, de esta manera CAC determinara cual es la mejor ruta para encaminar la llamada. El orden es el siguiente: La red WAN, Internet o PSTN.
Por ejemplo, supongamos que tenemos dos usuarios, uno en la oficina de Barcelona y otro en la oficina de Madrid.
El usuario de Madrid hace una llamada al usuario de Barcelona, antes de que este acepte la llamada, CAC hará la comprobación de Ancho de Banda y en este caso determina que la llamada se curse por la red WAN
Pongamos ahora, que cuando el usuario de Madrid lanza una llamada al usuario de Barcelona en ese momento hay otras 10 personas de Madrid haciendo llamadas a través de la WAN.
En este caso el CAC determinara que la mejor ruta para cursar la llamada con calidad será a través de Internet por el Servidor Perimetral. Pero en el caso de que no se consiga, usara la PSTN para enviarla.
Es aconsejable para que esto funcione correctamente tener un buen diseño de las políticas y rutas de llamadas, y a la vez un buen planteamiento de la tarjeta de contacto de los usuarios con la información de los números de teléfono correctamente implementados.
Si el CAC entra en servicio en una llamada, los usuarios pueden notar que la llamada tarda un par de segundos en establecerse.
¿Qué pasaría si la llamada no puede cursarse por Internet o por la PSTN?
Pues bien, en el peor de los casos el usuario Madrid no podrá conectar con el usuario de Barcelona y la llamada se cancelará.
En la parte 2 veremos un ejemplo de diseño en un entorno y la configuración de CAC, además de su comprobación.
Powershell Commands to Test Lync and Skype for Business Services
Este articulo en Español aquí
After a few weeks without writing today I have been encouraged again, I have many “articles” in my mind, but I am more involved in some new project. This time I bring some PowerShell commands that you can launch tests of installed services in a Skype for Business implementation.
Usually when we do a Unified Communications installation there is a moment during the project where we will do a “battery” of tests to check the services of Skype for Business. This complicates sometimes, because we will need at least 2 or 3 Skype clients with different user accounts to do the “typical” IM tests, calls, conferences, etc … Apart from The complication to have the “clients” Skype simultaneously, we will need the help of another coworker to be able to do the tests.
Well, with these commands that I will specify below, we will be able to do a basic tests of the Skype services that will give us the “health” result of the platform.
To perform the tests we will need two accounts registered in Skype for Business, I always advise to have a couple of “Test” accounts, which we can have to do tests, etc. This is something we will ask in the Initial Requirements to begin the installation To our client or the Active Directory administrators. In this case the accounts that I am going to use are.
Login: MRLYNC\SkypeTest1
Sip: SkypeTest1@mrlync.com
Password: *********Login: MRLYNC\SkypeTest2
Sip: SkypeTest1@mrlync.com
Password: *********
Once we have the data of our “Test” accounts, we will enable them in our Skype for Business.
Declare the variables
The first thing we will do is declare your variables with the data we want to use for the tests:
$login1 = “SkypeTest1@mrlync.com”
$sip1 = “SkypeTest1@mrlync.com”
$password1 = “*****” | ConvertTo-SecureString -AsPlainText -Force
$cred1 = New-Object System.Management.Automation.PsCredential($login1, $password1)
$login2 = “SkypeTest2@mrlync.com”
$sip2 = “SkypeTest2@mrlync.com”
$password2 = “******” | ConvertTo-SecureString -AsPlainText -Force
$cred2 = New-Object System.Management.Automation.PsCredential($login2, $password2)
$targetfqdn = “skypepool.mrlync.com”
$authtype = “ClientCertificate”
#$authtype = “Negotiate”
Surely you have noticed that the field “login” we declare it as the field “Sip”, with Skype for Business I worked in this way the commands, but if we are going to run the tests in a platform of Lync 2013, surely we will need to put The login field: “MRLYNC \ SkypeTest1”
Front End Services
Once we have collected the data in the variables, we use the following commands to test the services of our Pool or Standard Front End Server.
#Regitration
Write-Host “Registration“
Test-CsRegistration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Address Book Service
Write-Host “Address Book Service“
Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Lis Configuration
Write-Host “Lis Configuration“
Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Presence
Write-Host “Presence“
Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2
#Lync Web App
Write-Host “Skype Web App“
Test-CsUcwaConference -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -OrganizerSipAddress “sip:$sip1” -OrganizerCredential $cred1 -ParticipantSipAddress “sip:$sip2” -ParticipantCredential $cred2 -verbose
#Skype IM
Write-Host “Skype IM“
Test-CsIm -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$login1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$login2” -ReceiverCredential $cred2
Test-CsGroupIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Test-CsMcxP2PIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
#VoIP
Write-Host “VoIP”
Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
All of these commands can be added in a TxT file format * .ps1 and launched directly as a script from PowerShell, so we can use it to test the Skype deployments that we will configure
Comandos Powershell para probar los servicios de Lync/Skype for Business
This article in English here
Tras unas semanas sin escribir hoy me he animado de nuevo, tengo muchos “artículos” en la recamara, pero la verdad que últimamente ando mas liado en algún proyecto nuevo. En esta ocasión traigo algunos comandos PowerShell con los que se pueden lanzar pruebas de los servicios instalados en una implementación de Skype for Business.
Normalmente cuando hacemos una instalación de Comunicaciones Unificadas hay un momento durante el proyecto donde haremos una “batería” de pruebas donde comprobar los servicios de Skype for Business. Esto se complica a veces, ¿por que?, pues principalmente se complica porque necesitaremos al menos 2 o 3 clientes Skype con diferentes cuentas de usuario para hacer las “típicas” pruebas de IM, llamadas, conferencias, etc… A parte de la complicación para tener los “clientes” Skype simultáneamente, necesitaremos la ayuda de otro compañero para poder hacer las pruebas.
Pues bien, con estos comandos que paso a especificar a continuación, podremos hacer una pruebas básicas de los servicios de Skype que nos dará el resultado de “salud” de la plataforma que estamos montando.
Para realizar las pruebas necesitaremos dos cuentas dadas de alta en Skype for Business, yo siempre aconsejo tener un par de cuentas “Test”, que podremos tener para hacer pruebas, etc.. Esto es algo que pediremos en los Requisitos iniciales para comenzar la instalación a nuestro cliente o los administradores del Directorio Activo. En este caso las cuentas que voy a utilizar son
Login: MRLYNC\SkypeTest1
Sip: SkypeTest1@mrlync.com
Password: *********Login: MRLYNC\SkypeTest2
Sip: SkypeTest1@mrlync.com
Password: *********
Una vez tengamos los datos de nuestras cuentas “Test”, las habilitaremos en nuestro Skype for Business.
Declaramos las variables
Lo primero que haremos será declarar nuestras variables con los datos que queremos usar para las pruebas:
$login1 = “SkypeTest1@mrlync.com”
$sip1 = “SkypeTest1@mrlync.com”
$password1 = “*****” | ConvertTo-SecureString -AsPlainText -Force
$cred1 = New-Object System.Management.Automation.PsCredential($login1, $password1)
$login2 = “SkypeTest2@mrlync.com”
$sip2 = “SkypeTest2@mrlync.com”
$password2 = “******” | ConvertTo-SecureString -AsPlainText -Force
$cred2 = New-Object System.Management.Automation.PsCredential($login2, $password2)
$targetfqdn = “skypepool.mrlync.com”
$authtype = “ClientCertificate”
#$authtype = “Negotiate”
Seguramente os habréis fijado en que el campo “login” lo declaramos igual que el campo “Sip“, con Skype for Business me funcionaron de esta manera los comandos, pero si vamos a ejecutar las pruebas en una plataforma de Lync 2013, seguramente necesitaremos poner el campo login: “MRLYNC\SkypeTest1“
Servicios del Front End Server
Una vez hemos recogido los datos en las variable, usaremos los siguientes comandos para probar los servicios de nuestro Pool o Servidor Front End Estándar.
#Regitration
Write-Host “Registration“
Test-CsRegistration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Address Book Service
Write-Host “Address Book Service“
Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Lis Configuration
Write-Host “Lis Configuration“
Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Presence
Write-Host “Presence“
Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2
#Lync Web App
Write-Host “Skype Web App“
Test-CsUcwaConference -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -OrganizerSipAddress “sip:$sip1” -OrganizerCredential $cred1 -ParticipantSipAddress “sip:$sip2” -ParticipantCredential $cred2 -verbose
#Skype IM
Write-Host “Skype IM“
Test-CsIm -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$login1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$login2” -ReceiverCredential $cred2
Test-CsGroupIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Test-CsMcxP2PIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
#VoIP
Write-Host “VoIP”
Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Todos Estos comandos los podemos añadir en un fichero TxT con formato *.ps1 y lanzarlo directamente como un Script desde PowerShell, así lo podremos usar para probar las implantaciones de Skype que vayamos a configurar
InstallDatabase Skype Monitoring “failed with the operating system error 5(Access is denied.)”
Skype for Business Monitoring Server “failed with the operating system error 5(Access is denied.)”
Normalmente en la instalaciones de Lync o Skype for Business es el propio cliente el que suele aprovisionarnos de una instancia SQL a la que haremos referencia para instalar nuestras BBDD de Back End o en este caso una instancia para instalar las BBDD de Monitoring Server donde nuestro Front End registra los datos necesarios para luego a través de Reporting Service poder consultarlos.
Pero no siempre es así, y muchas veces nos tenemos que enfrentar a instalar nosotros mismos un SQL Server, instancias, Reporting, etc .. Al final como en muchas otras cosas, uno aprende a base de experiencia y de encontrarse errores y problemas. Para ello, yo siempre aconsejo hacer pruebas en nuestro laboratorio, para poder enfrentarnos a la instalación en el cliente con cierta seguridad. En este articulo, contare uno de esos casos que me encontré.
La BBDD de Monitoring la íbamos a instalar en una instancia de un servidor SQL remoto, creo que era la tercera vez que iba a instalar un servidor SQL, monte la instancia, configure el Reporting Service y comprobe que podía acceder sin problemas SQL Server Management Studio con el usuario Administrador de Skype.
El siguiente paso, asociar la nueva instancia SQL como Monitoring del Front End desde la topología.
Hasta aquí todo correcto, pero una vez publicada la topología, lance el siguiente comando para instalar las BBDD en el servidor SQL del Monitoring.
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn cvtsql01.xxxxxx.com
Apareció el siguiente error
Error. “Directory lookup for the file “x” filed with the operating system error 5(Access is denied.)”
En este caso el problema era que el servicio en el servidor SQL de la instancia “Monitor” estaba corriendo con la cuenta “NT Service” que por defecto al crear la instancia estaba así.
Al cambiarla a “local system account” y hacer un “restart” del servicio puede crear de forma correcta las BBDD desde el Servidor Front End
Como conclusión a la hora de implementar la monitorización en la infraestructura de Skype o Lync hay que tener en cuenta las cuentas con las que ejecutamos los servicios de las BBDD, como dije al principio no soy experto en SQL pero de esta manera conseguí solventar este problema, y de momento tras actualizaciones, reinicios, etc… parece que el servicio esta aguantando y no da problemas
Saludos!
Cambiar el parametro “FailOverTimeout” para las llamadas PSTN en Lync
Recientemente nos encontramos con un problema a la hora de “tracear”. En concreto algunas llamadas que no se cursaban correctamente entre los clientes Lync/Skype contra algunos números externos, en esta ocasión era numeración de Emergencia (062, 112, 091, etc …)
Concretamente cuando realizábamos la batería de llamadas y poníamos una traza de Wireshark en nuestros Mediation Server, veíamos lo siguiente:
A los 10 segundos nuestro Mediation Sever enviaba siempre un “CANCEL” y la llamada no llegaba a cursarse:
Indagando por la red dimos con la solución. Lync por defecto espera 10 segundos a que la llamada progrese y si no lo hace manda una opción “CANCEL” y la corta, no pudiendo ver de esta manera por qué la llamada no se cursa, o quizás este tipo de llamadas a números de Emergencia estaban tardando más de lo normal en cursarse y con esta “restricción” no conseguían progresar.
Aunque parezca que Lync es un sistema bastante “restringido” a la hora de configurar sobre todo las opciones SIP que enviamos a nuestros TRUNKS, existen algunos ficheros de configuración en los cuales podemos cambiar (con mucho cuidado) parámetros como es el caso de “FailOverTimeour”. Esta opción por defecto está a 1000
<add key=”FailOverTimeout” value=”10000″/>
<add key=”MinGwWaitingTime” value=”1″/>
<add key=”MaxGwWaitingTime” value=”20″/>
<add key=”FailuresForGatewayDown” value=”10″/>
<add key=”FailuresForGatewayLessPreferred” value=”25″/>
<!– Valid values are between 5 and 600 –>
<add key=”HealthMonitoringInterval” value=”300″/>
<!– Valid values are between 60 and 3600 –>
<add key=”GatewayStateReportingInterval” value=”1800″ />
Cambiándola a 2000 conseguimos subir a 20 segundos el tiempo que tarda nuestro Lync en enviar el “CANCEL”.
El fichero se llama “OutboundRouting.exe.config” y lo podemos encontrar en la ruta del servidor “C:\Program Files\Microsoft\Lync Server 2013\Server\Core“.
El fichero lo podemos Editar con “XML Notepad”, por ejemplo:
La manera mas correcta de proceder a la hora de modificar ficheros de configuración de este tipo en Lync, o al menos la que aconsejo, es siempre hacerlo parando servicios de forma ordenada, servidor a servidor, lo que llamamos comúnmente “drenar los servidores”, y mas en arquitecturas con mas de un servidor en los Pool.
Problema con la distribucion de usuarios en los “Routing Groups” de Lync 2013
Hoy quiero escribir este artículo acerca de un problema que me encontré hace un año aproximadamente en una migración de un entorno de Lync 2010 a Lync 2013, en concreto el problema se produjo al mover los usuarios desde un entorno al otro.
Tras montar toda la infraestructura de Lync 2013, movimos algunos usuarios de prueba al nuevo pool, después de unos días sin experimentar ningún problema y ver que todo estaba correcto, se decidió mover el resto de usuarios de la infraestructura, unos 5.000 usuarios.
Ese mismo día dejamos programado el Script que migraría todos los usuarios, el Script lanzaba el siguiente comando.
Get-CsUser -Filter {RegistrarPool -eq “lyncpool2010.mrlync.com”} | Move-CsUser -Target “lyncpool2013.mrlync.com”
¿Cuál fue nuestra sorpresa? Al día siguiente mientras los usuarios arrancaban los clientes Lync de sus ordenadores empezamos a notar lentitud en el comportamiento de los mismos, muchos de ellos se quedaban con las funciones limitadas, o no veían presencia, etc… Tras ver los problemas que estaban ocurriendo se decidió volver a mover los usuarios a la versión 2010 y todo volvió a la normalidad.
Parecía claro que a los servidores no le sentaba bien la carga de usuarios, con lo cual procedimos a ir migrando usuarios en grupos de 50 en 50, en el momento que pasamos los 1500 usuarios volvimos a notar los problemas de rendimiento.
Nuestro primer pensamiento fue pensar que era un problema de rendimiento debido arquitectura, esta era la arquitectura que teníamos:
Teníamos un pool de FrontEnds con redundancia geográfica dividido en dos Sites separados físicamente en dos CPD, sabíamos que con 4 FrontEnds teníamos más que suficiente para aguantar la carga de los 5000 usuarios, por ello nos centramos en que el problema pudiera ser la conexión de red entre los dos CPD, pero los tiempos y la calidad de red parecía correcta, por otro lado pensamos en que el fallo podría estar en la conexión de los FrontEnd con el BackEnd y que por alguna razón teníamos un cuello de botella, pero al igual que el caso anterior todo parecía correcto.
Tras las pruebas y descartar que el problema pudiera ser causa del rendimiento de los servidores comenzamos a revisar la configuración y el comportamiento de los servidores de Lync 2013 y sus Routing Groups.
Tras el movimiento de usuarios vimos que todos se metían en el mismo Routing Group cuando la manera correcta seria que se distribuyeran entre varios. Para comprobar los Routing Groups, hicimos consultas a la BBDD RTC Local de los FrontEnd, o el atributo msRTCSIP-UserRoutingGroupID.
Pero casualmente en una de las pruebas que lanzamos fue usando la consola de Administración de Lync y la sorpresa fue ver que los usuarios si se distribuían bien. Tras este comportamiento decidimos probar con la consola de Powershell Remoto contra uno de los servidores y lanzamos el movimiento de usuarios en grupos de 50 en 50, ¿Cuál fue el resultado? Todos los usuarios se movieron de forma correcta y se acabaron los problemas de rendimientos.
En conclusión, el problema era que los primeros script de movimiento de usuarios los hacíamos con el “Lync Server Management Shell” en el propio servidor de Lync.
Y tras utilizar un script que abría una consola de PowerShell remoto en Lync todos los usuarios se distribuían correctamente. ¿Por qué cuando lanzábamos el mismo comando PowerShell desde la consola de PowerShell del servidor no se distribuían bien los usuarios? No he conseguido encontrar la explicación coherente, pero estaba claro que ejecutar el movimiento de usuarios desde el propio PowerShell de Lync nos daba problemas
Desde este problema todas las instalaciones o migraciones de Lync que realizo, el PowerShell remoto se ha convertido en un elemento obligatorio para la administración, aunque sea en un único Servidor Standard Edition.
Para entender más acerca de cómo funcionan los routing groups, os recomiendo la siguiente página:
http://masteringlync.com/2013/10/29/understanding-how-windows-fabric-works/
Con respecto al script de conexión de powershell remoto, encontrareis muchas maneras de hacerlo en internet, cualquiera de ellas os servirá, la que yo utilizo es la siguiente:
En un fichero TXT copiamos el siguiente código
$Cred = Get-Credential “mrlync\lyncadmin”
$Session = New-PSSession -ConnectionURI “https://lyncserver01.mrlync.com/OcsPowershell”-Credential $cred
Import-PSSession $sesión
Este fichero lo renombramos a *.ps1 y lo ejecutamos desde el PowerShell, con este formato nos pedirá clave de “lyncadmin” cada vez que lo ejecutemos. En algunos entornos puede haber mucho movimiento en lo que a las bajas y altas de la compañía respecta, de esta manera podemos dejar un script de PowerShell remoto para que gestione las altas en Lync teniendo la contraseña de administrador en otro fichero encriptado para que se ejecute de forma automática, esta gestión de las altas de usuario en Lync las abordaré en otro artículo en el que explicare como crear un proceso automático de altas en el que incluso se asignen las políticas según el perfil de usuario.
- 1
- 2
- Siguiente →
