Microsoft Lync Server
Header

Voy a explicaros como podéis ampliar el listado de estados que trae por defecto el cliente Lync. Para ello tenemos que crear un fichero XML y publicarlo en una ruta de red compartida, local, en un servidor web via HTTP o HTTPS. Además vamos a ver los requisitos que debe cumplir:

  • El texto puede contener como máximo 64 caracteres
  • El cmdlet CustomStateURL nos permitirá distintas opciones de configuración: Ruta de Red o Local, HTTP y HTTPS
  • Los estados pueden ser configurados únicamente como: Ocupado, No Molestar o Disponible
  • Se pueden crear como máximo 4 Estados Nuevos

Nosotros aqui vamos a ver la forma de publicar el fichero XML  vía HTTPS, y lo haremos en el IIS de nuestro Front-END o Director donde ya tenemos los Servicios Web de nuestro Lync Server. Los primero que debemos hacer es crear el fichero XML, y guardarlo con el nombre que queramos, en nuestro caso le he llamado presencial.xml  

<?xml version="1.0"?>
<customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">
  <customState ID="1" availability="online">
    <activity LCID="3082">Documentando</activity>
  </customState>
  <customState ID="2" availability="busy">
    <activity LCID="3082">En una Webcast</activity>
  </customState>
  <customState ID="3" availability="busy">
    <activity LCID="3082">Formacion Online</activity>
  </customState>
  <customState ID="4" availability="do-not-disturb">
    <activity LCID="3082">Reunion de Equipo</activity>
  </customState>
</customStates>

Vamos describir las distintas partes del XML:

customState ID: Indicamos la posición del Estado en nuestro Listado

activity LCID: le indicamos el código del idioma del cliente Lync para el cual va a estar disponible (ID de Localización de Microsoft)

availability: Estado de nuestra Presencia

Tenemos que modificar el texto que queremos que se muestre cuando despleguemos el listado de estados, <activity LCID="3082">Documentando</activity> y con esto tendríamos configurado nuestro XML. Si queremos en el mismo XML podemos configurar varios idiomas:

  <?xml version="1.0"?>
<customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">
  <customState ID="1" availability="online">
    <activity LCID="1033">Working from Home</activity>
    <activity LCID="3082">Trabajando desde Casa</activity>
  </customState>
  <customState ID="2" availability="busy">
    <activity LCID="1033">In a Live Meeting</activity>
    <activity LCID="3082">En una Reunión Online </activity>
  </customState>
  <customState ID="3" availability="busy">
    <activity LCID="1033">Meeting with Customer</activity>
    <activity LCID="3082">En una reunion con un cliente</activity>
  </customState>
  <customState ID="4" availability="do-not-disturb">
    <activity LCID="1033">Auditing</activity>

    <activity LCID="3082">Auditando</activity>
      </customState>
</customStates>
Una vez que hemos modificado correctamente nuestro XML, debemos copiarlo en la ruta adecuada para tener acceso desde nuestros Clientes Lync. Como lo que queremos es tener acceso vía HTTPS, lo vamos a copiar dentro de la carpeta Internal Website y External Website de nuestro Front-END o Director:
 
External Website (Lync 2010)
Lync_Estados_1.png
Internal Website (Lync 2010)
Lync_Estados_3.png
 
External Website (Lync 2013)
Lync_2013_Presencia_1.jpg

Internal Website (Lync 2013)

Lync_2013_Presencia_2.jpg
External WebSite (Skype For Business)
Estados Skype For Business_1.png
Internal WebSite (Skype For Business
Estados Skype For Business_1.png
De esta forma podremos tener acceso desde cualquier ubicación, dentro o fuera de la red coporativa. Para comprobar que el fichero es accesible, escribimos el nombre FQDN de nuestra URL que alberga los Webservices de Lync y debemos ver algo parecido a esto:
 
Lync 2010
Lync_Estados_4.png
 
Lync 2013
Lync_2013_Presencia_4.JPG
 
Skype For Business
Estados Skype For Business_3.png

Como podemos observar, estamos visualizando en el navegador el contenido de nuestro XML, por lo que inicialmente estaría correcto. Ahora debemos modificar nuestra política de usuario para que nuestros clientes Lync puedan consultar esta URL con los nuevos estados. Para ello abrimos una consola de Powershell de Lync y escribimos el siguiente cmdlet:

 
Ejemplo: Set-CsClientPolicy -Identity Nombre_Politica -CustomStateUrl "https://fqdn_pool/presencia.xml
Set-CsClientPolicy -Identity ASIR -CustomStateUrl "https://lync.asirsl.com/presencia.xml
 
Ahora podemos ejecutar este cmdlet y ver que se ha aplicado correctamente:
 
Lync 2010
 
Get-CsClientPolicy -Identity Global | Select-Object Custom* | fl
 
Lync_Estados_5.png
 
Lync 2013
 
Get-CsClientPolicy -Identity Global | Select-Object Custom* | fl
Lync_2013_Presencia_5.jpg
 
Skype For Business Server 2015  
 
Get-CsClientPolicy -Identity Global | Select-Object Custom* | fl
Estados Skype For Business_4.png
Como vemos se ha aplicado correctamente la configuración deseada, ahora únicamente debemos iniciar sesión de nuevo en nuestro cliente Lync y  tendremos nuestros estados disponibles:
 
Lync 2010
Lync_Estados_0.png
 
Lync 2013
 
Lync_2013_Presencia_3.jpg
 
Actualización 13-10-2015:  Skype for Business Server 2015 y Office 2016
Estados Skype For Business.png

Sin que decir tiene que debemos tener publicada la URL en donde tengamos el XML, tanto desde dentro como desde fuera de nuestra red. Si tenemos una instalación típica de Lync, ya debemos tener publicados los Servicios Web correspondientes con el FQDN adecuado, por lo que esto lo doy por hecho.

 
Como os había comentado este ejemplo habla únicamente de la publicación del XML vía HTTPS, pero también podéis hacerlo vía HTTP o directamente con acceso a carpetas locales o compartidas. Aqui os dejo varios ejemplos sacados de la Web de Microsoft:
 

 
Desde luego esto es lo más cómodo y transparente para el usuario, además nos permite cambiarlo en cualquier momento sin tener que realizar distintas configuraciones. Comentaros también que podemos crear tantos ficheros XML  como queramos,  tenerlos publicados y aplicados siempre a distintas políticas de usuarios. Se puede dar el caso de que queráis distintas opciones de presencia según el usuario o usuarios que se conecten. Para ello previamente debemos crear la política correspondiente (New-CsClientPolicy), luego asignar el fichero XML a esta nueva política (Set-CsClientPolicy -Identity Nombre_Politica -CustomStateUrl "https://fqdn_pool/presencia2xml”) y posteriormente establecer la política a los usuarios que se desee (Grant-CSClientPolicy)
 
Como veis poco hay que hacer, dejar todo el mismo sitio y cambiar la URL del fichero de presencia si hemos cambiado algo en nuestra topología, en mi caso he configurado la versión Enterprise con un Pool de dos servidores y he modificado la dirección de los servicios Web, eso si, he copiado el fichero en ambos (no os olvidéis)
 
Espero que os sea de utilidad!!!

Es muy común que cuando llamamos a un usuario desde nuestro cliente Lync/Skype4B lo hagamos como una llamada de cliente a cliente, por lo que  no tendrá coste alguno. Pero si en alguna ocasión hemos llamado al usuario a través de tu número de teléfono, cuando volvamos a intentar llamarle de forma directa sin elegir el tipo de llamada lo haga directamente por el último método que hemos usado:

Evitar_Llamadas_PSTN_0.png

También sabemos que podemos poner que por defecto todas las llamadas sean de cliente a cliente, así os lo había comentado en este artículo: LLamar a Lync como opción por defecto. En este artículo había explicado como configurar un política que definiese que por defecto las llamadas fuesen llamadas de VoIP (EnableVOIPCallDefault), hasta aquí todo perfecto, pero el problema viene cuando además hemos llamado al usuario a su número de trabajo, etc…  puesto que las siguientes llamadas sino elegimos el tipo de llamada utilizará el último utilizado. Esta configuración ya no la podemos controlar desde el servidor de Lync/Skype4B, puesto que esta información se almacena en una clave de registro en la sesión del usuario:
 
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync\sbuitrago@asirsl.com\ContactStateCacheU
 
Como podéis apreciar en la imagen anterior, vemos que debajo de la clave HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync tendremos  el nombre de usuario (más bien la dirección SIP del usuario) con el que hemos iniciado sesión, luego una clave con el nombre ContactStateCacheU  que es donde se almacena la información o caché de las últimas llamadas realizadas desde nuestro cliente Lync/Skype4B. En la imagen vemos que debajo de la clave  ContactStateCacheU  tenemos la dirección de los usuarios a los que hemos llamado (no tienen porque ser todos usuarios de Lync/Skype4B y sí contactos de nuestra agenda de Outlook) y dentro la siguiente información:
  • ClickToCall: número de teléfono al que hemos llamado
  • Name: nombre de usuario al que hemos llamado

Esta información es la que utilizará nuestro cliente Lync/Skype4B para realizar la siguiente llamada, aquí os muestro una captura de una llamada (he borrado parte del número de mi móvil y en la captura de pantalla anterior lo he sustituido por XXXXXX, pero vamos, ahí tenéis un número de teléfono seguro)

Evitar_Llamadas_PSTN_1.png

Esto hará que hagamos  una llamada a un usuario que tiene Lync/Skype4B y está disponible para llamarlo vía VoIP, pero sin embargo la llamada la enviaremos a su móvil (con el consiguiente coste que tendrá). Lo que queremos es que la llamada sea a su cliente Lync/Skype4B:

Evitar_Llamadas_PSTN_2.png

Esta llamada también queda reflejada en el registro del usuario y quedaría así:

Evitar_Llamadas_PSTN_3.png

Dicho todo esto, el problema que tenemos es claro, la última llamada que hagamos a un usuario será la que quede en caché para volver a utilizarla a menos que explícitamente elijamos el tipo de llamada. Tenemos  varias soluciones para evitar esto y todas a nivel de cliente:

  • Eliminar todas las claves que están dentro de ContactStateCacheU: podemos hacerlo con un script de powershell o cmd, pero el problema que tienes que una vez que el usuario vuelva a llamar volverá a crear dichas claves. Esto no nos sirve, porque tendríamos que tener el script de borrado de las claves ejecutándose cada minuto en la sesión del usuario
  • Cambiar los permisos de la clave ContactStateCacheU: con esto evitamos que el cliente Lync/Skype4B acceda y cree nuevas claves en cada llamada, esto si nos sirve. Para ello crearemos un script con POwerShell que busque la clave ContactStateCacheU y le quite los permisos al usuario que ha iniciado sesión, de esta forma el cliente Lync/Skupe4b siempre utilizará la configuración que hemos establecido a nivel de directiva de usuario (LLamar a Lync como opción por defecto)

Como creo que la segunda opción es la más acertada y la más fiable, aquí os dejo un script que hemos creado desde ASIR (gracias Amandio por tu ayuda!!)

Evitar_Llamadas_PSTN_4.png
Aquí os dejo el código del script para copiar – pegar:

# Buscar Claves que incluyan la palabra Contac dentro la clave HKCU:\SOFTWARE\Microsoft\Office\15.0\Lync
$keys = Get-ChildItem -Path HKCU:\SOFTWARE\Microsoft\Office\15.0\Lync -Include Contact* -Recurse | Select-Object Name 
foreach ($key in $keys){ 
    # Leemos el valor Name
    $keyRoot = $key.Name 
    # Reemplazamos el valor por HKCU 
    $PSKeyRoot = $keyRoot.Replace("HKEY_CURRENT_USER","HKCU:") 
    # Leemos los permisos actuales
    $acl = Get-Acl $PSKeyRoot
    # Creamos los permisos necesarios
    $ace = New-Object System.Security.AccessControl.RegistryAccessRule("$env:username","FullControl", "ContainerInherit", "None", "Deny")
            
    # Añadimos la regla a la ACL  
    $acl.AddAccessRule($ace) 
    # Establecemos los permisos sobre la clave de registro que habíamos puesto en la variable PSKeyRoot 
    Set-Acl -Path "$PSKeyRoot" -acl $acl 
}

El proceso del script es sencillo y aquí os lo dejo documentado por fases:

  1. Buscamos una clave de registro dentro de HKCU:\SOFTWARE\Microsoft\Office\15.0\Lync que empiece por Contact (solo existe la que buscamos: ContactStateCacheU) y tenemos su valor en una variable
  2. El valor que nos devuelve comienza por HKEY_CURRENT_USER\SOFTWARE y debemos cambiarlo por HKCU: , y así lo hacemos
  3. Establecemos los permisos que vamos a aplicar sobre el usuario que ha iniciado sesión ($env:username): queremos denegar el Control Total sobre la clave ContactStateCacheU y las subclaves (son las que representan a los usuarios llamados)
  4. Establecemos el valor de dichos permisos sobre la clave de registro que habíamos capturado, puesto en un variable,  cambiado el nombre y lo más importante

Esto lo que permitirá es que denegaremos el acceso a la clave HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync\$env:username\ContactStateCacheU y subclaves al usuario que ha iniciado sesión:

Evitar_Llamadas_PSTN_5.png

Y con esto el cliente Lync/Skype4B no podrá leer el contenido de la clave ContactStateCacheU ni las subclaves, lo que hará que siempre llame utilizando VoIP (EnableVOIPCallDefault), lo que mediante la directiva de cliente que habíamos configurado desde el servidor. El que no pueda acceder a la clave ContactStateCacheU no impide el correcto funcionamiento del cliente Lync/Skype4B, simplemente que no almacenará en caché las últimas llamadas y por lo tanto siempre utilizará las llamadas de VoIP que es lo que queremos.
 
Por último lo que nos queda es aplicar este script a todos los usuarios que queramos, para ello simplemente nos creamos una GPO con la siguiente configuración:
Evitar_Llamadas_PSTN_6.png
Básicamente en la directiva de grupo, editamos la configuración de usuario, nos vamos a Configuración de Windows – Scripts (inicio de sesión o cierre de sesión ) y configuramos el script como inicio de sesión, se lo agregamos como Scripts de PowerShell. Una vez configurada nuestra directiva se la vinculamos a la OU en donde tenemos los usuarios y en el próximo inicio de sesión se le aplicará dicha directiva.
 
Con esta configuración los usuarios ya no podrán leer la clave ContactStateCacheU y con esto ya tenemos lo que queremos, que todos los usuarios a los cuales se haya aplicado la GPO tendrá siempre la llamada de VoIP por defecto.
 
Espero que os sea de utilidad!!

El 112 trata de ser la asistencia más inmediata posible a las demandas de los ciudadanos de todo el pais que se encuentren en una situación de riesgo personal o colectivo.

Se establece que los ciudadanos podrán utilizar de forma gratuita este número 112 para pedir, en casos de urgente necesidad, la asistencia de los servicios públicos que se requieran en servicio de urgencia sanitaria, de extinción de incendios y salvamento, de seguridad ciudadana y de Protección Civil, cualquiera que sea la Administración pública de la que dependan.
 
Este servicio se llevará a cabo por las Comunidades Autónomas que para ello, establecerán los correspondientes centros de recepción de llamadas de urgencia: www.112.es
112_VoIP_Problemas.PNG
Real Decreto 903/1997, de 16 de Junio, por el cual se regula el acceso, mediante redes de telecomunicaciones, al servicio de atención de llamadas de urgendcia a través del número telefónico 112 rd-903-1997.pdfrd-903-1997.pdf
 

¿Qué ocurre cuando queremos hacer una llamada al 112 desde un sistema de VoIP? …… Pues que las llamadas no se pueden cursar, la mayoría de los ITSP no lo permitirán. Esto es debido a que llamadas no pueden ser identificadas desde su origen, porque podemos tener un DID de Galicia pero estar en Madrid y la llamada que queremos realizar es al servicio de 112 de Madrid. Esto es lógico, porque con VoIP podemos tener un DID de distintas provincias y nosotros estar en otra completamente diferente. Si realizamos una llamada al 112, el operador (no el ITSP) sabe la localización en la que estás y derivará la llamada al centro de soporte de tu comunidad. Esto con VoIP por su propio funcionamiento, ya no es posible, porque podemos cursar la llamada desde Madrid y sin embargo el DID es de Galicia. Ahora bien, es posible solucionar esto? La respuesta es si, puesto que el 112 tiene su número geográfico asignado, vamos un DID al cual podemos llamar desde cualquier sistema, pero sabiendo que estamos llamando a un servicio de urgencias de una comunidad autónoma en concreto, aquí os dejo un listado de números geográficos asignados a distintas comunidades autónomas a los cuales podemos llamar directamente:

Andalucía 955041812 y 112
Aragón 976281234 y 112
Asturias:  985773344 y 112
Canarias: Gran Canaria 928492112 y 112
Canarias: Tenerife 922532112 y 112
Cantabria 942319400 y 112
Cataluña 935867700 y 112
Galicia 981541400 y 112
La Rioja 941222222 y 112
Madrid 917089158 y 112
Melilla 952699100 y 112
Murcia 968229604 y 112
Navarra 948222222 y 112
País Vasco 944441444 y 112
Valencia 962759060 y 112

Los números geográficos son aquellos que aportan información de procedencia geográfica del origen o del destino de una comunicación, atendiendo a la primeras cifras del número, es decir, el prefijo:

112_VoIP_Problemas_3.PNG

Ahora bien, si queremos que los usuarios puedan marcar el 112 para llamar a su servicio de urgencias de su comunidad por VoIP y más concretamente en Lync/Skype, podemos configurarlo creando una regla de normalización en el plan de marcado. Para ello debemos crear una regla de normalización de la siguiente forma:

 

 

112_VoIP_Problemas_1.PNG
Está claro que es algo "estático", si configuramos el 112 para que se traduzca al 981541400  (Galicia), no podemos volver configurarlo en el mismo plan de marcado. Pero también es cierto, que si tenemos una implementación de Lync/Skype y usuarios en todo el territorio nacional, debemos crear distintos planes de marcado (por comunidad) para crear una regla de traducción por cada plan de marcado. Estos planes de marcado deberían crearse en base a la distribución por comunidades autómonas según la web www.112.es, de esta forma se tendrá una distribución adecuada de los planes de marcado y las reglas de traducción para cada 112 con su número geográfico. De esta forma, los usuarios que están en distintas comunidades autónomas podrán pulsar el 112 y se traducirá  a su número geográfico correspondiente (ejemplo de Galicia):

112_VoIP_Problemas_2.PNG
De esta forma podremos cursar las llamadas al 112 vía VoIP sin problema, porque realmente ya definimos los números geográficos correspondientes por comunidad autónoma. Sin esta configuración, sería imposible, porque con VoIP no es posible identificar el origen de la llamada y así enrutarla al servicio de 112 correspondiente.  Claramente una vez normalidad el número 112 -> +34981541400  el ITSP cursará la llamada sin problemas, para el es una llamada nacional y la dejará pasar sin inconveniente.

Si bien es cierto, que esta configuración también la puede realizar el ITSP en base al DID que mostremos en la llamada y así saber a que servicio de 112 enrutar la llamada, pero de momento no son muchos los ITSP que ofrecen este servicio.

Recordaros que el 112 es servicio gratuito y que se puede utilizar desde casi cualquier dispositivos, desde móviles bloqueados e incluso sin SIM.

Aquí os de una estupenda guía prácita de usuario: "El Plan Nacional de Numeración" Guia_Numeracion.pdfGuia_Numeracion.pdf En donde encontraréis información sobre las numeraciones en España, amplio y muy sencillo de entender.

Espero que os sea de utilidad!!!

Muchas instalaciones de Lync Server 2013 son la versión Standard, de ahí que vamos a ver que tenemos  que hacer para migrar a Skype Empresarial Server 2015 … (pulsar en la imagen para verla a tamaño real)

Migrar Lync Server 2013 ST a Skype4B ST_Topologia.jpg

El orden de migración de servidores es el mismo que con la versión Enterprise, de adentro a fuera (Front-END, Director, etc…), pero en este caso como es una versión Standard, será primero los Front-END y luego los EDGE (pulsar en la imagen para verla a tamaño real):

Migrar Lync Server 2013 ST a Skype4B ST_Topologia_Orden_Migracion.jpgComentado esto, vamos a empezar por recordar los requisitos que debemos cumplir en nuestra topología y servidores:

En mi caso mi servidor de Lync Server 2013 está en Windows Server 2012 R2, por lo que debemos instalar la actualización KB2982006 Esta actualización la  tenemos que descargar como siempre de la web de Microsoft, pero en este caso la tenemos que solictar desde la web que he puesto en el vínculo del KB (https://support.microsoft.com/en-us/kb/2982006/). Cuando accedemos lo primero que debemos es solicitar dicha actualización especificando una dirección de correo a donde nos harán llegar la URL de descarga directa de la actualización:

Migrar Lync Server 2013 ST a Skype4B ST_1.png

Migrar Lync Server 2013 ST a Skype4B ST_2.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

En cuestión de segundos tendremos en nuestro buzón un correo como este con la URL de descarga de la actualización:

Migrar Lync Server 2013 ST a Skype4B ST_2_1.png

Una vez que lo hemos descargado, debemos ejecutar el instalador, que básicamente primero deberá extraer el fichero de la actualización de este fichero .exe, simplemente nos indica en donde queremos extraerlo y luego podremos iniciar el proceso de actualización:

Migrar Lync Server 2013 ST a Skype4B ST_4.png

Le indicamos la ruta de destino de los ficheros que va a extraer, la carpeta no tiene porque existir, porque la creará el asistente sino existe:

Migrar Lync Server 2013 ST a Skype4B ST_5.png

Migrar Lync Server 2013 ST a Skype4B ST_6.png

Migrar Lync Server 2013 ST a Skype4B ST_7.png

Una vez que haya finalizado de extraer el fichero, nos vamos a la carpeta en donde está el fichero de la actualización preparado para ser instalado:

Migrar Lync Server 2013 ST a Skype4B ST_8.png

Para instalar este parche, únicamente debemos ejecutarlo y seguir el miniasistente hasta que se finalice el proceso:

Migrar Lync Server 2013 ST a Skype4B ST_9.png

Migrar Lync Server 2013 ST a Skype4B ST_10.png

Ahora en los servidores Front-END he ejecutado el siguiente comando de PowerShell para verificar que estaban todos los requisitos a nivel de roles y características de Windows (https://technet.microsoft.com/en-us/library/dn933900.aspx):

Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, BITS
Migrar Lync Server 2013 ST a Skype4B ST_12.png
En mi caso ya lo tenía todo correctamente actualizado, por lo que no ha hecho cambio alguno en el servidor:
Migrar Lync Server 2013 ST a Skype4B ST_13.png

Mientras tanto como en la migración de la versión Enterprise de Lync 2013 (Migración paso a paso de Lync Server 2013 Enterprise a Skype For Business 2015 Enterprise), debemos instalar las herramientas administrativas de Skype For Business 2015 en otro servidor diferente a los Front-END. Desde ahí debemos ejecutar el proceso de actualización del pool de Lync Server 2013 a Skype For Business 2015.  Ahora el instalador tiene la posibilidad de conectarse a Windows Update antes de iniciar el instalador, justo después de la instalación de Visual C++ 2013 Redistributable (x64):

 

Upgrade Lync 2013 a Skype For Business_1.png
Por lo que podemos elegir que antes consulte a Windows Update, actualice el sistema operativo y luego continue con la instalación de Skype For Business (en mi caso no ha hecho falta ir a Windows Update, puesto que ya tenía todos los servidores completamente actualizados):

 

Upgrade Lync 2013 a Skype For Business_2.png

 

Una vez que pulsamos en Install inciará el proceso de instalación de los componentes principales de Skype For Business que nos permtirán tener el Asistente de Instalación, pero lo primero que debemos hacer es aceptar el contrato de Licencia y pulsar en Aceptar
Upgrade Lync 2013 a Skype For Business_2_1.png

Upgrade Lync 2013 a Skype For Business_2_2.png

Una vez que finalice se abrirá directamente el asistente de implementación de Skype4B, ahora lo que haremos será pulsar en Instalar herramientas adminsitrativas (como vemos no tocará el Directorio Activo, puesto que ya tenemos Lync instalado y Skype4B no hará modificación alguna)
Upgrade Lync 2013 a Skype For Business_2_3.png
Upgrade Lync 2013 a Skype For Business_2_4.png
Upgrade Lync 2013 a Skype For Business_2_5.png
Upgrade Lync 2013 a Skype For Business_2_6.png
Con esto ya tenemos las herramientas administrativas instaladas
Upgrade Lync 2013 a Skype For Business_2_7.png
Ahora nos vamos a la interface Metro y escribimos en el buscador Skype y vemos que ya tenemos disponibles el Asistente para implementación de Skype Empresarial Server, Panel de Control de Skype Empresarial Server, Generador de Topologías Skype Empresarial Server y Shell de administración de Skype Empresarial Server
Upgrade Lync 2013 a Skype For Business_2_8.png

Lo primero y único que debemos hacer ahora es abrir el generador de la Topología de Skype Empresarial Server y marcar la casilla de Descarga topología de la implementación existente y pulsamos en Aceptar

Upgrade Lync 2013 a Skype For Business_2_9.png

 

Guardamos la topología con el nombre que queremos  y pulsamos en Guardar
Upgrade Lync 2013 a Skype For Business_2_13.png

Estamos en el momento más importante y es el inicio de la migración a Skype For Business, para ello abrimos la topología, hacemos clic con el botón secundario del ratón encima de nuestro pool  Front-END de Lync Server 2013 y pulsamos en Actualizar a Skype Empresarial Server 2015 …

Migrar Lync Server 2013 ST a Skype4B ST_Topologia_11.png
Nos muestra una confirmación de si realmente queremos actualizar nuestro pool a Skype For Business 2015, claramente pulsamos en SI
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_12.png

Como vemos ya se ha movido el pool a nivel de topología a la configuración de Skype Empresarial Server 2015:

Migrar Lync Server 2013 ST a Skype4B ST_Topologia_13.png
Para completar este primer proceso, debemos publicar la topología y esperar a que se complete:
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_14.png
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_15.png
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_16.png
Debemos pulsar en Haz clic aquí para abrir la lista de tareas, en donde nos mostrará las tareas a relizar en el(los) servidor(es) de nuestro pool de Skype Empresarial Server 2015 que acabamos de migrar desde Lync Server 2013:
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_17.png

Por lo que nos ponemos a ello, nos vamos al servidor srv-lync00.asirlab.com que es el servidor migrado y vamos a detener todos los servicios de Lync. Como tenemos que detener los servicios, veamos primero en que estado se encuentran (iniciados claramente, pero bueno) con el cmdlet Get-CsWindowsService

Migrar Lync Server 2013 ST a Skype4B ST_Parar_Servicios_1.png
 
Pues como debemos pararlos, vamos a ejecutar el cmdlet Disable-CsComputer -Scorch, el cual además de parar los servicios en el momento lo que hará será establecer ha Deshabilitado como Tipo de Inicio
Migrar Lync Server 2013 ST a Skype4B ST_Parar_Servicios_2.png
 
Si volvemos a ejectar el cmdlet  vemos que ya están parados (el que queda iniciado es el IIS, pero no es problema)
Migrar Lync Server 2013 ST a Skype4B ST_Parar_Servicios_3.png
Y si ahora abrimos la consola de administración de servicios de Windows (services.msc), veremos que están todos parados y el tipo de inicio cambiado ha Deshabilitado (no todos son servicios de Lync, pero ahí si que están todos los de Lync):
Migrar Lync Server 2013 ST a Skype4B ST_Parar_Servicios_4.png

Pues ahora simplemente nos toca iniciar el proceso de instalación de Skype Empresarial Server 2015, para ello iniciamos la instalación desde el instalador de Skype4B

Upgrade Lync 2013 a Skype For Business_1.png
Por lo que podemos elegir que antes consulte a Windows Update, actualice el sistema operativo y luego continue con la instalación de Skype For Business (en mi caso no ha hecho falta ir a Windows Update, puesto que ya tenía todos los servidores completamente actualizados):
Upgrade Lync 2013 a Skype For Business_2.png
Una vez que pulsamos en Install inciará el proceso de instalación de los componentes principales de Skype For Business que nos permtirán tener el Asistente de Instalación, pero lo primero que debemos hacer es aceptar el contrato de Licencia y pulsar en Aceptar
Upgrade Lync 2013 a Skype For Business_2_1.png

Como el asistente ya detecta que hay una instalación de Lync, automáticamente se pondrá actualizar a Skype4B (unos 15 minutos más o menos)

Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_1.png
Nota: si ejecutamos este proceso sin previamente actualizar y publicar la topología nos mostrará la siguiente advertencia:
Migrar Lync Server 2013 ST a Skype4B ST_19.png
Si mostramos en Mostrar registros veremos el texto completo:
Migrar Lync Server 2013 ST a Skype4B ST_20.pngEntiendo que esto no tiene sentido que os ocurra, pero bueno, por si alguien se despista pues tenéis que ver este artículo desde el principio y seguirlo paso a paso: FIN NOTA

Una vez haya finalizado el proceso de actualización en el Front-END, veremos si se ha completado sin problemas y pulsamos en Aceptar
Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_2.png

Ahora nos queda iniciar nuevamente todos los servicios, como es un único servidor vamos a ejecutar el cmdlet Start-CsWindowsServices
Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_5.png
 
Si os acordáis habíamos previamente parado los servicios con el cmdlet Disable-CsComputer -Scorch que además de parar los servicios cambiaba el tipo de inicio a Deshabilitado. Pues bien, ahora con el Start-CsWindowsService los inicia y cambia el tipo de inicio a Automático (inicio retrasado) que el tipo de inicio por defecto:
Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_4.png
En cuanto finalice de iniciar los servicios vamos revisar si realmente los ha iniciado todos, para ello ejecutaremos el cmdlet Get-CsWindowsService

Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_6.png
Para migrar nuestro EDGE lo primero es que vayamos al generador de topologías de Skype Empresarial Server 2015 y migremos el EDGE. Para ello una vez abierto el Generador de Topologías de Skype Empresarial 2015 nos vamos a la sección de Grupo de servidores perimetrales, pulsamos con el botón secundario del ratón encima de nuestro EDGE y pulsamos en Actualizar a Skype Empresarial Server 2015…  
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_18.png

Nos vuelve a advertir del cambio que vamos a realizar y pulsamos en SI
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_19.png

Ahora el servidor ya nos apareceré en la configuración de Skype Empresarial Server 2015 en el Grupo de servidores perimetrales

Migrar Lync Server 2013 ST a Skype4B ST_Topologia_20.png
Por último debemos publicar la topologia, para ello desde el generador de topologías pulsamos con el botón secundario del ratón encima de la topología y ñulsamos en Topología – Publicar…
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_21.png
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_22.png
Esta es la segunda vez que publicamos la topología de Skype Empresarial Server 2015 y ahora nos indica que debemos seleccionar el servidor de Administración Central, porque actualizará sus bases de datos.
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_23.png
Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_7.png
Ahora si que ya tenemos todo 100% actulizado, únicamente tenemos que seguir el proceso que nos indica si pulsamos en Haga clic aquí para abrir la lista de tareas para el EDGE
Migrar Lync Server 2013 ST a Skype4B ST_Actualizando_Front_END_8.png
 
Ahora debemos iniciar el proceso de actualización de EDGE. Es muy similar o casi idéntico en cuanto al proceso como al del Front-END, instalamos lo componentes de Skype For Business (cumpliendo previamente los requisitos) y como la topología ya se habrá replicado (debemos esperar unos minutos para que sea así, verficarlo con el cmdlet: Get-CsManagementStoreReplicationStatus) simplemente debéis para previamente los servicios del EDGE (Stop-CsWindowsService) e iniciar el proceso de actualización y poco más. Una vez que termine debéis iniciar nuevamente todos los servicios (Start-CsWindowsService) y ya tenéis vuestra topología de Lync Server 2013 migrada a Skype Empresarial Server 2015!!!
Migrar Lync Server 2013 ST a Skype4B ST_Topologia_24.png
En este artículo no he comentado nada de los requisitos a nivel de espacio en disco, etc… pero son los mismos para todas las versiones, vamos que debeis tener 32GB libre en el servidor para poder iniciar el proceso de actualización sino … (todo esto podéis verlo aquí Migración paso a paso de Lync Server 2013 Enterprise a Skype For Business 2015 Enterprise)
Upgrade Lync 2013 a Skype For Business_2_311.png
 
Cómo en el caso de la versión Enterprise he realizado las siguientes comprobaciones:
  • Iniciar sesión en Skype
    • Cliente de Escritorio: OK
      • Desde dentro de la red: OK
      • Desde Internet pasando por el EDGE: OK
    • Cliente Móvil: OK
      • Desde dentro de la red: OK
      • Desde internet pasando por el Reverse-Proxy: OK
    • Lync Web App: OK
      • Usuario anónimo: OK
      • Usuario autenticado: OK
  • Realizar llamadas
    • Vía ITSP: OK
    • Vía Cisco CME: OK
  • Recibir llamadas
    • Directivas: OK
    • A través de los grupos de Respuesta: OK
  • Verificar el acceso al buzón de voz de Exchange: OK
  • Verificar la integración de Skype For Business en OWA: OK
  • Compartir presentaciones de PowerPoint: OK
  • Federaciones
    • Con otras implementaciones de Lync: OK
    • Con Skype: OK
Y como en la anterior migración, no he tocado nada a nivel de:
  • Hardware (únicamente la ampliación de disco 🙂 en algún servidor)
  • DNS
  • Certificados
  • Reglas de Firewall
  • Reverse-Proxy
  • Exchange 2013 (UM)
  • Etc..

Vamos que ha sido otra migración sencilla y rápida, con la "suerte" de que todos los usuarios estaban en sus casitas de fin de semana, así que no he tenido que preocuparme de nada. Pero bueno, también es cierto que esto es un proceso de migración In-Place para una topología de lo más sencilla a nivel de Comunicaciones Unificadas (1 Front-END, 1 EDGE, 1 Reverse-Proxy, 1Exchange Server).

Espero que os haya sido de utilidad!!!