Microsoft
Hyper-V component is not running in a VMWare Server
This article in Spanish, here
Today I do not bring an “article” related about Skype for Business or Lync Server, but testing Cloud Connector lab, I found a pretty interesting problem and I think it can be helpful.
The Cloud Connector has 4 virtual machines that install itself in a HOST Hyper-V
In this case my lab is based on VMWare, concretly in ESX 5.1, this is my virtual environment. When preparing the virtual machine I would do from HOST for cloud connector in VMWare and enable within Hyper-V during the installation I encountered the following error:
“An error ocurred while arrempting to start the selected virtual machine(s)”
This problem is due to install Hyper-V Host on a VMWare machine, and to solve it we did the following:
1) Power off the virtual machine
2) Once the machine is turned off, select “Edit Settings“.
3) Download the * .vmx file, with the virtual machine selected, go to the “Summary” tab.
4) In the section “Resources” on the Storage, right-clicking the mouse and select “Browse Datastore.”
5) A new window will open, select the virtual machine in particular and download the file with * .vmx termination
6) Once we have the downloaded file, we will edit it with Notepad ++ and add the following options
vhv.enable = TRUE
hypervisor.cpuid.v0 = FALSE
You have to respect the position of the lines, and place the new options between “cleanShutdown” and “migrate.hostlog“
7) When we have the edited file we save it and upload it to the “Datastore“
Aconsejo cambiar el nombre al fichero .vmx existente y subir el nuevo
8) Now we can close the Datastore, re-enter the configuration by selecting the “Edit Settings” option as in step 2
9) Select the “Options” tab after and mark “CPU / MMU Virtualization“
Use Intel VT-x/AMD-V for instrucción set virtualization and Intel EPT/AMD RVI MMU virtualization
We already have our virtual machine in VMWare ESX ready to install a HOST of Hyper-V
Hyper-V component is not running in a VMWare Server
This article in English, here
Hoy no traigo un “articulo” relacionado con Skype for Business o Lync Server, pero montando el laboratorio de Cloud Connector, me encontré con un problema bastante interesante y que creo que puede servir de ayuda.
Como ya muchos sabréis, el Cloud Connector lleva unas 4 maquinas virtuales que la propia instalación que lo monta en un HOST Hyper-V
En este caso mi laboratorio esta basado en VMWare, concretamente en ESX 5.1, este es mi entorno virtual. Al preparar la maquina virtual que haría de HOST para cloud connector en VMWare y habilitar dentro Hyper-V durante la instalación me encontré con el siguiente error:
“An error ocurred while arrempting to start the selected virtual machine(s)”
Este problema se da debido a montar Hyper-V Host en una maquina VMWare, y para solucionarlo hicimos lo siguiente:
1) Apagamos la maquina virtual
2) Una vez se apague la maquina, seleccionamos “Edit Settings“.
3) Descargamos el fichero *.vmx, para ello con la maquina virtual seleccionada, vamos a la pestaña “Summary“
4) En el apartado “Resources” sobre el Storage, haciendo clic con el botón derecho del ratón, seleccionamos “Browse Datastore.”
5) Se nos abrirá una nueva ventana, en ella seleccionamos la maquina virtual en concreto y descargamos el fichero con terminación *.vmx
6) Una vez tengamos el fichero descargado, lo editaremos con el Notepad++ y añadimos las siguientes líneas
vhv.enable = TRUE
hypervisor.cpuid.v0 = FALSE
Hay que respetar la posición de las líneas, y colocar las nuevas opciones entre “cleanShutdown” y “migrate.hostlog“
7) Cuando tengamos el fichero editado lo guardamos y lo subimos al “Datastore“
Aconsejo cambiar el nombre al fichero .vmx existente y subir el nuevo
8) Ahora podemos cerrar el Datastore, volvemos a entrar en la configuración seleccionando la opción “Edit Settings” como en el paso 2
9) Seleccionamos la pestaña “Options” después “CPU/MMU Virtualization” y marcamos
Use Intel VT-x/AMD-V for instrucción set virtualization and Intel EPT/AMD RVI MMU virtualization
Ya tenemos nuestra maquina virtual en VMWare ESX lista para montar un HOST de Hyper-V
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
ms-diagnostics:33038 reason “Cannot transfer the call to another pool” and Conference ID not Found (English)
Hello all,
Again here, with one of those curious mistakes this time one of those of a global topology there are two “Skype sites” with two “Front-End Pools” separated by a dedicated network for the customer, such as an MPLS network for example.
DESIGN:
We have this design:
We have two Site in Skype for Business, one in “SPAIN” and another in “UK” linked by a dedicated network, the two sites have their output to the local PSTN through “Gateway / SBC” and its corresponding Mediation Server, all right here.
PROBLEM DETECTED:
The client uses much the service “Skype Conference Call”, because in some of its offices still are not migrated to Unified Communications and has VoIP PBX, in this case all audio conferencing service is housed in one of the Front End Pool, specifically in the UK that houses all accounts “Dial in Access Number“.
El Servicio Doméstico “Dial in Access Number” se encuentra en el Pool del Reino Unido y el Conference ID se puede alojar en el Spain Pool y el Reino Unido.
- A user in Spain, creates a conference with Conference ID. 60051
- He sends the ID to the contacts for the meeting
- A UK User connected to the PSTN dials the number “Dial in Access Number” of UK with number +44 20 7234XX XX to enter the meeting
- The user dial the Conference ID 60051 and receive the following message “sorry, I can not connect to your meeting right now“.
When the call is received by “Dial in Access Number” in the UK and the Conference ID was on the Front End SPAIN this error occurred.
PROBLEM SOLUTION:
To solve the problem, the first thing we can put a trace with the “logging tool” in the Front End pool of UK and launch a test.
We could see the following error:
“Cannot transfer the call to another pool”
To solve this error simply change the parameter “Refer Support” to False
Set-CsTrunkConfiguration -Identity (Trunk_Name) -EnableReferSupport $false
After changing the Enable Support Refer parameter to “False” in the UK Pool was able to connect the call audio conferencing service with the conference ID of the user Spain Pool
ms-diagnostics:33038 reason “Cannot transfer the call to another pool” and Meeting ID not Found
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:
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:
- Un usuario del Pool de Spain, crea una conferencia con el ID de conferencia. 60051
- Este envía la convocatoria a los contactos para la reunión
- 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
- Marca el ID de conferencia 60051 y recibe el siguiente mensaje “sorry, I can’t connect to your meeting right now“.
- 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:
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:
“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
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
“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (Castellano)
“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”.
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:
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:
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:
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.)”
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!
HTTP Authentication failed – Kemp Reverse Proxy & Lync Server 2013
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:
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.
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:
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
De esta manera la prueba con el Analizador de Conectividad de Microsoft pasaba correctamente
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
Error “Cannot open database “xds” en Lync 2013
Buenas a todos,
Por fin consigo un rato para escribir, iré poniendo todos los post atrasados (lo prometo..), de los problemas y casos curiosos que me he ido encontrando en mis ultimas instalaciones de Microsoft Lync Server 2013 y Skype for Business. A parte continuo en mis ratos libres probando la instalación de Cloud Connector que me resulta un producto de lo mas interesante, al menos para las pequeñas y medianas empresas que han decidido irse a la nube de Microsoft y que quieren migrar sus viejas centralitas a un entorno de comunicaciones unificadas sin tener que desembolsar mucho dinero en una infraestructura de servidores.
Bueno ya tendré mas tiempo de hablar del Cloud Connector, pero en este articulo quiero hablaros de un problema que me he encontrado recientemente en un cliente.
Concretamente necesitábamos conectarnos para realizar una auditoria de la infraestructura que tenia en Lync 2013 y con información obtenida hacerle una propuesta de migración a Skype for Business con integración de Voz y servicios externos a través de un EDGE, pues bien, lo primero en estos casos es o pedirle el fichero de la topología o conectarte con un usuario que te faciliten con los permisos RBAC adecuados para descargarla tu mismo.
En este caso el cliente nos proporcionó un usuario con pertenecía a los siguientes grupos y permisos:
Pero a la hora de conectarme al FrontEnd y descargar la topología, primero recibía este mensajes “Topology Builder could not copy to the topology from the Central Management Store. Cannot read Topology. Verify that the topology data is accessible“
Después volví a forzar la descarga y recibí la siguiente ventana de error:
El texto del error completo decía lo siguiente:
DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) atSystem.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) at System.Data.SqlClient.SqlConnection.Open() at Microsoft.Rtc.Common.Data.DBCore.PerformSprocContextExecution(SprocContext sprocContext) — End of inner exception stack trace — at Microsoft.Rtc.Management.Store.Sql.XdsSqlConnection.ReadDocItems(ICollection`1 key) at Microsoft.Rtc.Management.ScopeFramework.AnchoredXmlReader.Read(ICollection`1 key) at Microsoft.Rtc.Management.WritableConfig.AnchoredXmlSchemaCache.get_Item(ScopeClass scopeClass) at Microsoft.Rtc.Management.Xds.ManagementConnection.GetAnchoredXmlWrapperFromReader(SchemaId schemaId) at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopologyXml(TypedXml& typedXml, AnchoredXml& anchoredXml) at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopology(TypedXml& topologyXml, Topology& topology) at Microsoft.Rtc.Management.Xds.XdsCmdlet.<ReadTopology>b__5() at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.<>c__DisplayClass1.<Run>b__0() at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.Run[T](Boolean dropImpersonation, Func`1 func) atMicrosoft.Rtc.Management.Xds.XdsCmdlet.ReadTopology() — End of inner exception stack trace — at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate) at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper() at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
Failed
Finished
Tras revisar con el cliente los permisos del usuario, etc…, probé a lanzar el comando Get-CsAdminRole desde la Shell de Lync para ver que estaban bien aplicados los permisos, y recibí lo siguiente “Cannot open database xds requested by the login. The login failed“.
Con este error si pude indagar mas por la red, finalmente para solucionarlo simplemente de la manera mas fácil, arrancar el Topology Builder como Administrador
De esta forma pude descargar de forma correcta la topología, también para ejecutar comandos con el PowerShell utilizando la misma formula.
Seguramente que este post no sea de lo mas atractivo pero os lo cuento porque he visto en algún otro blog que con el mismo error que aconsejaban desinstalar todos los componentes de Lync como “Administrative Tools, Core Components, etc ..” y borrar la carpeta “RTCLOCAL” cosa que un entorno en producción es impensable y si de esta manera al menos podemos ir administrando la plataforma sin tener que provocar tanto trastorno al cliente. A mi de esta manera me sirvió y pude trabajar con normalidad.
Saludos
