Microsoft

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

 

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.