“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!

 

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

 

 

Skype for Business Cloud Connector

Posted on

Pues ya lo tenemos aquí, por fin el tan esperado Cloud Connector con el que podremos integrar nuestros Gateways  locales con los usuarios de Skype en la nube, de momento estoy testeando la instalación.

En cuanto tenga las impresiones y la instalación publicare el articulo, paciencia 🙂

Capture_CloudConnector

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.