Skype

ms-diagnostics:33038 reason “Cannot transfer the call to another pool” and Meeting ID not Found

Posted on

Hola a todos,

Otra vez por aquí con uno de esos errores curiosos que se encuentra uno en las implantaciones de topologías globales en las que hay varios “SITES” con diferentes Front-End Pools separados por una red dedicada para el cliente, como puede ser una red MPLS por ejemplo.

DISEÑO:

Partimos del siguiente diseño:

Diagrama General.jpg

Tenemos dos Site en Skype for Business, a nivel Topología, uno en “SPAIN” y otro en “UK” unidos por una red dedicada, cada infraestructura tiene su salida a la PSTN local por medio de Gateway/SBC y su Mediation Server correspondiente, hasta aquí todo correcto.

PROBLEMA DETECTADO:

El cliente tiene costumbre de uso el servicio de “Audioconferencia” de Skype, inlcuso de forma interna, ya que en algunas de sus sedes aun no están migrados a la solución de Comunicaciones unificadas y tiene PBX de VoIP, en este caso todo el servicio de Audioconferencia esta alojado en uno de los Front End Pool, concretamente en el de UK siento este el que aloja todas cuentas del “Dial In Access Number“.

De esta manera nos encontramos que el Servicio Principal “Dial in Access Number” esta el Pool de UK y en los ID de conferencia pueden estar alojados tanto en el propio Pool de UK como en el de SPAIN.

Es aquí donde nos encontrábamos el problema:

  1. Un usuario del Pool de Spain, crea una conferencia con el ID de conferencia. 60051
  2. Este envía la convocatoria a los contactos para la reunión
  3. Un usuario de UK conectado a la PSTN marca el numero “Dial in Access Number” de UK con numero +44 20 7234 XX XX para entrar a la reunión
  4. Marca el ID de conferencia 60051 y recibe el siguiente mensaje “sorry, I can’t connect to your meeting right now“.
  5. Y se cuelga la llamada

Cuando la llamada entraba por el “Dial in Access Number” de UK y el ID de conferencia estaba en el Front End de SPAIN se producía este error.

SOLUCION DEL PROBLEMA:

diagrama-error

Para solucionar el problema, lo primero que hicimos pue poner una traza con el “logging tool” en el Front End de UK y lanzar una prueba.

Pudimos ver el siguiente error:

error1

“Cannot transfer the call to another pool”

Para solucionar este error simplemente hay que cambiar el habilitar el parámetro “ReferSupport”

Set-CsTrunkConfiguration -Identity (Trunk_Name) -EnableReferSupport $false

solucion

Una vez cambiado el parámetro EnableReferSupport a False el Pool de UK era capaz de conectar la llamada del servicio de audio conferencia con el ID de la sala del usuario del pool de España

diagramasolucion

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (English)

Posted on Actualizado enn

This is my first article in English, now I will combine the articles in Spanish and English to facilitate the work of visitors. My English is not very advanced but I hope to help with my articles to all who encounter the same problems that I have found and here I am telling. Or simply the intention to use English is to reach more lovers of microsoft unified communications, Skype world for business, office 365, cloud, and etc…

I chose this last article, a problem which I have already met several times “Cannot start RTCSRV Service”. When the RTCSRV service is not started on the EDGE server, It can be normally for the following reasons:

– Problem with some of the certificates
– Some of the latest updates installed
– Some cumulative update of Skype for Business

This is what I usually find in some customers, but, this time, the situation was different, first, I will show the design.

diseno-1-blog-edge

Is noteworthy in this design that external firewall in DMZ is no NAT, the public IP addresses are directly posted on the Internet. This design was working fine until we installed the CU of June 2016 in the EDGE Server and we installed the security updates for Windows, when we restart we saw that the service “Skype for Business Server Access Edge” gave us the following error:

error-1-blog-edge

The first thing we did was uninstall updates, to restart the service, we saw these two errors:

error-2-blog-edge

error-3-blog-edge

After seeing that none of the usual reasons were the cause of the error, we remember that not long ago the customer changed the approach in its public IP address. Returning to the initial design. The “Public IP 1” and “Public IP 4” we had the same IP in the network interface for “sip.dominio.com” and the Rever Proxy:

diseno-2-blog-edge

There was a problem of incompatibility in the design and the Server was unable to start the Service.

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (Castellano)

Posted on Actualizado enn

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (Castellano)

Después de una larga temporada sin escribir, retomo el blog con este error que me encontré en un cliente y casualmente después de actualizar al ultimo CU de junio de 2016. Antes de pasar a detallar los detalles de como fue lo que me encontré y como lo solucionamos, me gustaría adelantaros mi intención de empezar a escribir alternativamente los post, en Ingles y Castellano, se que será difícil ya que es trabajo doble, pero una llamada que recibí hace poco y ver el origen de las visitas que recibe las entradas del blog me han llevado a tomar esta decisión, por eso he puesto (Castellano) en el titulo del post.

Bueno, pasemos a detallar el problema encontrado, como siempre hago, os lo contare de forma coloquial, y veréis que mas que un problema técnico lo que nos encontramos fue un problema de diseño que por casualidades “salto” o apareció después del reinicio típico después de actualizar el CU del EDGE.

Lo primero que hay que tener en cuenta es el diseño aproximado de este cliente en concreto para entender el “porque”.

diseno-1-blog-edge

Importante en este diseño que en firewall externo de la DMZ no había NAT, las IP’s publicas están directamente publicadas con la IP publica tanto para el EDGE server como para el Proxy Reverso que en este caso es un KEMP.

Pues bien, este diseño, estuvo funcionando bien hasta que casualmente le pasamos el CU de junio 2016 al EDGE server y parcheamos el servidor, una vez realizamos esto, reiniciamos y levantamos los servicios pero al levantar el servicio de “Skype for Business Server Access Edge” nos daba el siguiente error:

error 1 blog edge.jpg

Con ello, nos pusimos a buscar en y lo primero que pensamos era que podía ser la actualización, lo primero que hicimos fue quitar el CU instalado desde el panel de control, claro al levantar el servicio en este caso veíamos estos dos errores:

error 2 blog edge.jpg

error 3 blog edge.jpg

Seguíamos sin poder levantar el servicio de acceso, tras repasar e instalar de nuevo los certificados,  llegamos incluso a plantearnos recuperar un back up de la propia maquina virtual pero no tenia mucho sentido, entonces caímos en que habíamos no hace mucho tiempo cambiado un planteamiento en su direccionamiento IP publico. Y efectivamente ahí estaba el problema. Volviendo al diseño inicial. La “Public IP 1” y la “Public IP 4” eran la misma, teníamos por error la misma IP configurada en el interfaz de la tarjeta de red para “sip.dominio.com” y para el Proxy Reverso:

Diseño 2 blog edge.jpg

 Con lo cual había un problema de incompatibilidad y el Servidor era encapad de levantar el servicio. Una vez cambiamos la IP en el interfaz del KEMP pudimos levantar el servicio sin ningún problema.

InstallDatabase Skype Monitoring “failed with the operating system error 5(Access is denied.)”

Posted on Actualizado enn

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.

Capturetopo

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

Capture_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í.

Service01.

Al cambiarla a “local system account” y hacer un “restart” del servicio puede crear de forma correcta las BBDD desde el Servidor Front End

Service02..JPG

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!

 

Perdida del registro de llamadas en Skype for Business (KB3114351) SOLUCIONADO

Posted on Actualizado enn

Buenos días,

Parece que ya hay solución al problema que comente en el articulo anterior:

En la ultima actualización publicada por Microsoft para Skype for Business lo publican:

Aquí podéis descargar el paquete de actualización publicado el 9 de Febrero del 2016

https://support.microsoft.com/en-us/kb/3114732

 

Perdida del registro de llamadas en Skype for Business (KB3114351)

Posted on Actualizado enn

Por fin consigo sacar un hueco para escribir otro pequeño artículo, estas últimas semanas están siendo de locura en lo que al trabajo respecta pero espero volver a coger el buen habito de compartir mis experiencias con las Comunicaciones Unificadas de Microsoft, no se me olvidan los post que tengo pendientes pero de momento os dejo esto que me he encontrado esta semana y que no quería dejar escapar.

En un cliente nos hemos encontrado varias incidencias en las que los usuarios de “Skype for Business” habían perdido el registro de llamadas perdidas y conversaciones. Cuando entraban aparecía la lista vacía, y días antes todo parecía haber funcionado bien

Captura1

En el cliente Skype no había ningún error típico de perdida de conexión con Outlook o Exchange Server y tras revisar toda la configuración, incluso intuir que podía ser uno de los Front End del Pool descubrimos que el problema era la actualización:

“Security Update for Skype for Business 2015 (KB3114351)”

El equipo de soporte había liberado la actualización y según se lanzaba en los clientes los usuarios iban perdiendo el registro.

Tras desinstalar la actualización el cliente empezó a funcionar correctamente.

Problema con la distribucion de usuarios en los “Routing Groups” de Lync 2013

Posted on Actualizado enn

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:

Diseño CPD

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.

Routings

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.

Captura lync shell

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.

Problemas de incompatibilidad de versiones de 802.1x – Teléfonos Polycom y Avaya – Parte 2

Posted on Actualizado enn

En este segundo artículo, paso a contar como solucionamos el problema de securiación con la incompatibilidad de 802.1x. En principio ADAC como comentamos en el primer artículo es un sistema propietario de AVAYA para su telefonía VoIP y su electrónica de red, pero finalmente y gracias al fabricante pudimos ponerlo para los teléfonos Polycom dedicándole una VLAN dedicada para el registro de los teléfonos.

A continuación añado las capturas de configuración de los Switch de planta

1.- A nivel Global la configuración de 802.1X

switch01

2.- A nivel de puerto en el Switch se aplica la siguiente configuración

switch02

3.- Y por último se añadió el rango de las MAC de los teléfonos Polycom

switch03.2

Quiero advertir ante todo que estas capturas son muy genéricas, en cada cliente las configuraciones de este tipo pueden ser muy particulares, pero la intención de este artículo es orientar en el caso de que alguien se encuentre en una situación parecida, que sepa que puede usar ADAC en electrónica AVAYA con los teléfonos Polycom.

Hay otra manera que es usando autenticación por MAC, esto requiere ir añadiendo las MAC, una a uno de los teléfonos, evidentemente en una instalación con un número elevado de teléfonos esto puede ser engorroso. Pero existe la manera de hacerlo con reglas como se muestra en la siguiente captura

Pantallazo 22

 

No soy un experto en la configuración de electrónica de red, por ello en un caso parecido a este siempre aconsejo primero hablar con el Integrador o el fabricante para que nos ayude en la manera de lo posible.

Nos leemos en el próximo articulo

Problemas de incompatibilidad de versiones de 802.1x – Teléfonos Polycom y Avaya – Parte 1

Posted on Actualizado enn

En mi primer artículo que publico quiero abordar un problema que nos encontramos con los teléfonos Polycom VVX 410 y la securizacion de red del cliente. Este artículo se compone de dos partes, en la primera parte desarrollare el problema y como conseguimos detectarlo.

En los proyectos en los que he trabajado para migrar el sistema de voz y comunicaciones a un sistema de Microsoft Lync Server me he encontrado en situaciones en las que el cliente ha planteado un despliegue más agresivo y ha ido retirando los teléfonos y sustituyéndolos por dispositivos usb y poniendo solo teléfonos de área común en salas de reuniones y zonas comunes. Sin embargo, otros clientes han planteado un despliegue menos agresivo para el usuario, y han decido sustituir los teléfonos tradicionales por teléfonos Lync sobre todo para los perfiles de directivos, secretarias, etc ….

De los modelos con los que he trabajado a parte de algún modelo de SNOM, he trabajado sobre todo con Polycom, CX3000, CX600, CX500, y los VVX410 y VVX600, en mi opinión los más fáciles de desplegar son los modelos CX, pero la impresión del usuario es que el VVX410 se manejan mejor y además muchas de sus opciones pueden ser configuradas por los administradores, en mi opinión so más potentes pero no son fáciles de desplegar, en otro artículo abordare como preparé el despliegue de unos 600 teléfonos VVX en un cliente, sobre todo las opciones del fichero de configuración que elegimos para el despliegue.

En el cliente tenían una desplegada Voz IP con una Centralitas AVAYA CS1K y aparte toda la electrónica de red es del mismo fabricante, la electrónica Avaya tiene una opción que se llama ADAC, la cual permite al Switch controlar los teléfonos IP para registrarlos en la red mediante LLDP de esta manera el Switch negocia con el teléfono y le deja registrarse en la red, evidentemente ADAC está pensado para funcionar con teléfonos propietarios del fabricante. Aquí os dejo un pequeño esquema donde se puede entender el funcionamiento de ADAC.

img1

http://www.voxns.com/understanding-ip-phone-deployment-lldp-med-provisioning/

Si necesitáis más información acerca de esto y todo lo relacionado con el mundo AVAYA, os recomiendo que leáis el blog de Michael Mcnamara http://blog.michaelfmcnamara.com

Pues bien, el cliente en concreto quería mantener con los nuevos teléfonos la autenticación en la red. Para ello se planteó inicialmente 802.1x que es soportado tanto por la electrónica de red AVAYA como por los teléfonos VVX, de esta manera podíamos autenticar contra un servidor radius los teléfonos Polycom.

Implementar 802.1x en los teléfonos nos dio muchos quebraderos de cabeza, no fue nada fácil cargar los certificados del dispositivo generándolos con la entidad certificadora del cliente. En el siguiente enlace esta toda la información oficial de Polycom para implementar 802.1x en los teléfonos.

http://support.polycom.com/global/documents/support/technical/products/voice/802_1X_TB57352.pdf

La opción que decidimos implementar fue EAP-TLS, una vez configurado el teléfono con los certificados correspondientes no fuimos capaces de ver ningún registro del teléfono en el Radius. Después de varios intentos, pusimos una traza y este fue el resultado:

  • Según la traza que capturamos el switch avaya soporta 802.1X – 2001

img2

  • Y el teléfono Polycom soporta 802.1x – 2004

img3

Este era el motivo por el cual no conseguíamos que el teléfono llegara al servidor Radius ya que la propia electrónica de red no era capaz de entenderse con el. La solución fácil pasaba por una actualización de la electrónica de red pero tras conversaciones con el fabricante no había actualización para el modelo de switch que tiene el cliente en sus instalaciones. Por ello tuvimos que encontrar otra solución, que pasaba por usar ADAC y mediante el rango de las MAC de los teléfonos registrarlos en una VLAN dedicada. En la segunda parte del articulo pasare a contar la solución que se desplego.