PowerShell

Common Area Phone en Skype for Business online (CAP Online)

Posted on Actualizado enn

Common Area Phone en Skype for Business online (CAP Online)

En el siguiente articulo explicaremos como registrar un teléfono de área común en Skype online de Office 365.

Los teléfonos de área común son una característica que se puede configurar en Skype for Business on-prem, esta caracteristica se usa para configurar teléfonos en salas de reuniones o en espacios comunes, la particularidad de estos telefonos es que no están asociados a ningún usuarios en particular, ademas no requiere de una licencia de usuario.

La configuración y administración de estos teléfonos (CAP) en Skype for Buisness on-prem no es precisamente algo sencillo, requiere crear objetos en AD (Active Directory) ademas de activar las opciones de registro por extensión y PIN. Casi toda la configuracion y administracion se hace mediante Powershell con lo cual requiere que el administrador tenga buenos conocimientos de scripting.

En el caso de Skype for Business online no existía esta característica hasta mas o menos Marzo del 2018, ahora se pueden crear teléfonos de área común (CAP) en Skype for business online y emparejarlo a un teléfono físico que colocaremos en zonas comunes de nuestra empresa.

De momento no se puede usar todos los teléfonos que soporta registro en Office 365 para registrarlos como área común, de momento la opción de CAP online algunas gamas de telefonos Audiocodes y Polycom.

En este caso utilizaremos un teléfono Audiocodes 440HD con firmware version UC_3.0.4.1264

A continuación pasaremos a explicar los pasos requeridos para registrar teléfonos de área común.

Configuración de CAP Online en Office 365

Lo primero que necesitaremos sera un usuario en Office 365, en nuestro caso el usuario se llama “pruebaskype” y tiene la siguiente configuración de licencias

  • Licencia Office 365 Enterprise E3
  • Sistema telefónico

Dentro de la licencia E3 tiene todas las opciones de servicio activas.

Este usuario también esta activo en Skype for Business online y se le ha asociado un numero de la RTC Local, ya que en el despliegue contamos con un Cloud Connector Edition.

Captura.PNG

Activar el servicio CAP online en Office 365

Una vez tenemos el usuario creado, vamos a activar en Office 365 el servicio de CAP online.

Desde la pagina de administración de Office 365, vamos al menú facturación, Comprar servicios. Y una vez en la pagina de “Comprar Servicios” iremos a Otros Planes

Captura01

Ahora, buscaremos “teléfono de área común” e iniciaremos la prueba gratuita o podemos comprar directamente la licencia de 6,70 € por usuario al mes

Captura02

Asignar la licencia CAP al usuario en Office 365

Una vez comprada la licencia de teléfonos de área común, iremos al panel de administración de Office 365, buscaremos el usuarios “pruebaskype” y editaremos la licencia de producto.

Captura04

Y activamos “teléfono de área común

Captura06

Configuración del Teléfono AudioCodes 440HD

A continuación explicaremos como configurar el telefono Audiocodes 440HD

  1. Con el teléfono conectado a la red, entramos en el “menú” pulsando la tecla menúCaptura01.PNG
  2. Ayudándonos con las teclas de “cursor” bajaremos hasta la opción “Administration20180503_115957
  3. Ponemos la clave de administración, la de por defecto es “123420180503_120010
  4. Una vez entramos en el menú de administración vamos a “Common Area Phone20180503_120025
  5. Una vez dentro, seleccionamos “Enabled” y guardamos20180503_120047
  6. El teléfono se reseteará
  7. Una vez arranque el teléfono, pulsaremos en “Sign inCaptura03.PNG
  8. Seleccionaremos la opción “CAP Provisioning20180503_120306
  9. Seguidamente nos aparecerá la URL de aprovisionamiento y el “Paring Code20180503_120322

Configuración del emparejamiento

Ahora iremos a la pagina “http://aka.ms/skypecap” y nos logaremos con el usuario Administrador de Office 365. Una vez en la pagina buscamos el usuario con licencia CAP Online y podremos el código de emparejamiento.

Captura01

Una vez hemos añadido el código de aprovisionamiento que obtuvimos en el teléfono deberemos ver que el teléfono se registra de forma automática.

20180503_120637

Y en la url de aprovisionamiento veremos que el teléfono esta registrado

Captura03

De esta manera ya tenemos el teléfono registrado y listo para usar como telefono de área común de Skype for business online

 

Powershell Commands to Test Lync and Skype for Business Services

Posted on Actualizado enn

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”

capture1

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

capture2
Script Registration Result

#Address Book Service

Write-Host “Address Book Service

Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1

capture3
Script Address Book Service

#Lis Configuration

Write-Host “Lis Configuration

Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1

capture4
Script Lis Result

#Presence

Write-HostPresence

Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2

capture5
Presence

 #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

capture6
Skype Web App 01
capture7
Skype Web App 02
capture8
Skype Web App 03
capture9
Skype Web App 04

 

capture10
Skype Web App 05

#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

capture11
Script Skype IM

#VoIP

Write-Host “VoIP”

Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2

capture12
VoIP

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

Posted on Actualizado enn

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

capture1

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

capture2
Resultado Script Registration

 

#Address Book Service

Write-Host “Address Book Service

Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1

capture3
Resultado Script Address Book Service

 

#Lis Configuration

Write-Host “Lis Configuration

Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1

capture4
Resultado Script Lis

 

#Presence

Write-HostPresence

Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2

capture5
Resultado Script Presence

 

 #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

capture6
Resultado Skype Web App 01
capture7
Resultado Skype Web App 02
capture8
Resultado Skype Web App 03
capture9
Resultado Skype Web App 04

 

capture10
Resultado Skype Web App 05

 

 #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

capture11
Script Skype IM

 

 #VoIP

Write-Host “VoIP”

Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2

capture12
Resultado VoIP

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

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.