Mr.Lync

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!

 

HTTP Authentication failed – Kemp Reverse Proxy & Lync Server 2013

Posted on Actualizado enn

Buenas de nuevo a todos,

Dos artículos en dos días seguidos, no me lo creo ni yo 🙂 Bueno, espero seguir este ritmo.

Esta vez traigo algo un poco mas llamativo técnicamente, en concreto es un problema que me encontré a la hora de integrar un “Reverse Proxy” del fabricante Kemp Technologies, con una instalación de Microsoft Lync Server 2013.

Normalmente me gusta dividir en tres fases las instalaciones de Lync/Skype, primero suelo desplegar la parte interna (Front End, Back End, Trusted Application Server, Monitoring, etc...), después la integración con la Voz (Mediation Server, SBC – Gateway, Lync Phone Edition, etc …) y por ultimo la parte Publica o Externa (Edge Server y Rever Proxy). Para mi siempre esta ultima parte la mas complicada, ya que la gestión de los firewall, DMZ, IP Publica, NAT, etc … suele ser un quebradero de cabeza normalmente.

Pero normalmente si el cliente no tiene ya su propio Reverse Proxy y decide poner uno, como fue este caso, solemos recomendar uno, de los que están certificados para Lync/Skype como el de Kemp Technologies, además suele ser fácil de instalar y trae sus propias plantillas de configuración para Lync/Skype en la que solo hay que rellenar las IP’s, cargar los certificados, etc …

Lync 2013 and Skype for Business Configuration Templates and Installation Guides

https://kemptechnologies.com/loadmaster-documentation/#c7842

En este caso, el entorno que tenia configurado era algo parecido a esto:

Kemp000

 

 

Como podréis ver una instalación sencilla, en la que incluso para no tener muchos problemas con las rutas decidimos conectar el Interfaz “eth0” directamente a la VLAN de Servidores donde estaba el propio Front End.

Una vez configurados los servicios virtuales en el Proxy Reverso y cargados los Certificados. Comprobé que los servicios estaban arriba.

 Kemp001.jpg

Parecía que todo estaba bien, y en este caso para realizar las primeras pruebas lo mejor es utilizar la pagina que todos ya conocemos, el analizador de conectividad de Microsoft . Una vez lanzada la prueba de “lyncdiscover” mi sorpresa fue que el resultado daba el siguiente error:

Kemp002

 Parecía un error en el método de autenticación, en concreto el error decía:

HTTP authentication test failed

Y mas tarde respondía

Elapsed Time: 100015 ms.

Lo primero que hice fue sacar trazas en el Fron End, tanto de Wireshark como de logging tool de Lync para ver si había algún error pero parecía todo correcto. Tras varias conversaciones con el fabricante encontramos la solución, tan simple como marcar la siguiente opción:

Subnet Originating Requests en las Standard Options del Virtual Service

Kemp003

De esta manera la prueba con el Analizador de Conectividad de Microsoft pasaba correctamente

Kemp004

Espero que si os encontráis algún error como este, en un escenario parecido en el que hay un Proxy Reverso Kemp “jugando” con esta opción encontréis la solución.

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