Microsoft Lync Server

Lync Server 2013 Monitoring Management Pack

Aqui os dejo el enlace de descarga de los MP para Lync 2013: Lync Server 2013 Monitoring Management Pack

Lync Server 2013 Management Packs contain comprehensive monitoring tools including:

• End-to-End scenario availability from various locations

• Call reliability and quality perceived by real users

• Component health and performance. Active Monitoring Management pack

• Geographically distributable end-to-end scenario validation for Lync Server 2010 and Lync Server 2013 deployments. This includes coverage for internal, remote and branch office users

• Increased scenario coverage in areas like AV Edge Connectivity and Exchange Unified Message Connectivity

• Enhanced troubleshooting logs to streamline root cause analysis of failures. Component and User Management pack

• Increased reliability monitoring of real end user calls and conferences

• Integrated media quality alerts driven from Quality of Experience (QoE) data reported by client applications

• Full event and performance monitoring for all Lync 2013 roles

Seguramente para los que tengáis SCOM esto no tiene ni que comentarse, pero para los que solo lo conozcan de "oidas" os muestro como podéis importar los MP:

Abrimos la consola de administración de SCOM y nos vamos a la sección de Administración y vamos a ManagmentPacks

ahora pulsamos con el botón secundario del ratón y elegimos Import ManagmentPack – Add– Add from Disk … y pulsamos en SI (si hay actualizaciones del MP Online que las descargue)

ahora se nos abre un explorador para buscar los MP que hemos extraido antes con la instalación de los ficheros que nos hemos descargado de la web de Microsoft. La ruta por defecto es : C:\Program Files\Microsoft Lync Server 2013\Management Packs\Management Packs

los seleccionamos todos y pulsamos en Abrir y en la siguiente ventan en install

si queremos comprobar que se han instalado podemos buscarlos pulsando en find y luego escribimos Lync en el cuadro de búsqueda

ahora solo toca esperar a que los servidores con Lync 2013 los descarguen y empecemos a recibir datos de los distintos monitores. Si revisamos el Visor de Eventos de algún servidor de Lync deberíamos encontrar eventos relacionados con la recepción de los módulos de administración que hemos importando para Lync 2013:

Texto completo del evento con ID 223:

Nombre de registro:Operations Manager
Origen:        Health Service Script
Fecha:         10/12/2012 15:18:32
Id. del evento:223
Categoría de la tarea:Ninguno
Nivel:         Información
Palabras clave:Clásico
Usuario:       No disponible
Equipo:        SRV-LYNC03.asirsl.com
Descripción:
DiscoverMachine.ps1 :

——————————————————————————–
-Script Name: Lync Server MP Machine Topology Discovery
-Run as account: nt authority\servicio de red
-Execution Policy: Bypass
——————————————————————————–
Value of Source Id is {2469342F-3092-2CD4-2CE3-D45CA920984C}.
Value of ManagedEntity Id is {3F6E121D-55B8-FAA0-EAEF-9E22257A7944}.
Value of Target Computer is SRV-LYNC03.asirsl.com.
Lync Server Module is added
Successfully initialize discovery data.
Successfully found current machine in topology. Machine Fqdn is SRV-LYNC03.asirsl.com
Successfully discover deployment
LS Site discovery completed for Asir Lync.
LS Pool discovery completed for pool.asirsl.com.
LS Machine discovery completed for SRV-LYNC03.asirsl.com.
Component discovery completed for CMSFileTransfer.
Relationship discovery completed for CentralMgmtHostsCMSFileTransfer.
Component discovery completed for CMSMaster.
Relationship discovery completed for CentralMgmtHostsCMSMaster.
Role discovery completed for CentralMgmt.
Component discovery completed for MCUFactory.
Relationship discovery completed for UserServicesHostsMCUFactory.
Component discovery completed for PresenceFocus.
Relationship discovery completed for UserServicesHostsPresenceFocus.
Role discovery completed for UserServices.
Component discovery completed for Registrar.
Relationship discovery completed for RegistrarHostsRegistrar.
Component discovery completed for XmppFederation.
Relationship discovery completed for RegistrarHostsXmppFederation.
Component discovery completed for Lyss.
Relationship discovery completed for RegistrarHostsLyss.
Role discovery completed for Registrar.
Component discovery completed for ABHandler.
Relationship discovery completed for WebServicesHostsABHandler.
Component discovery completed for AutodiscoverService.
Relationship discovery completed for WebServicesHostsAutodiscoverService.
Component discovery completed for DLExpansion.
Relationship discovery completed for WebServicesHostsDLExpansion.
Component discovery completed for CAHandler.
Relationship discovery completed for WebServicesHostsCAHandler.
Component discovery completed for Lwa.
Relationship discovery completed for WebServicesHostsLwa.
Component discovery completed for LIService.
Relationship discovery completed for WebServicesHostsLIService.
Component discovery completed for McxService.
Relationship discovery completed for WebServicesHostsMcxService.
Component discovery completed for StoreWeb.
Relationship discovery completed for WebServicesHostsStoreWeb.
Component discovery completed for UcwaService.
Relationship discovery completed for WebServicesHostsUcwaService.
Component discovery completed for WebInfra.
Relationship discovery completed for WebServicesHostsWebInfra.
Component discovery completed for Reach.
Relationship discovery completed for WebServicesHostsReach.
Component discovery completed for WebScheduler.
Relationship discovery completed for WebServicesHostsWebScheduler.
Role discovery completed for WebServices.
Component discovery completed for IMConf.
Relationship discovery completed for ConfServicesHostsIMConf.
Component discovery completed for AppSharingConf.
Relationship discovery completed for ConfServicesHostsAppSharingConf.
Component discovery completed for AVConf.
Relationship discovery completed for ConfServicesHostsAVConf.
Component discovery completed for DataConf.
Relationship discovery completed for ConfServicesHostsDataConf.
Role discovery completed for ConfServices.
Component discovery completed for CAA.
Relationship discovery completed for ApplicationServerHostsCAA.
Component discovery completed for CAS.
Relationship discovery completed for ApplicationServerHostsCAS.
Component discovery completed for RGS.
Relationship discovery completed for ApplicationServerHostsRGS.
Component discovery completed for CPS.
Relationship discovery completed for ApplicationServerHostsCPS.
Role discovery completed for ApplicationServer.
Component discovery completed for CMSReplicator.
Relationship discovery completed for OcsCoreHostsCMSReplicator.
Component discovery completed for ClsAgent.
Relationship discovery completed for OcsCoreHostsClsAgent.
Role discovery completed for OcsCore.
Component discovery completed for Common.
Relationship discovery completed for CommonHostsCommon.
Role discovery completed for Common.

Aunque no tendremos datos muy significativos podremos abrir la consola de rendimiento de uno de los servidores de Lync y seleccionaremos User Connections

Espero que os sea de utilidad!!!

Estacionamiento de Llamadas o Call Park en Lync

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

El servicio de Estacionamiento de Llamadas, nos permite utilizar un grupo de extensiones «virtuales» para que retengan una llamada recibida, de tal forma que podemos rescatar esa llamada pulsando el número de extensión con la que se ha «estacionado»:

Imaginemos que un usuario A recibe una llamada de un usuario B desde la cuenta de Lync de un usuario C. El usuario A tiene una conversación confidencial con el usuario B y necesita disponer de un espacio aislado para continuar con la conversación, y a su vez no quiere colgar la llamada porque luego le resultaría complicado volver a contactar con el usuario B. Como la llamada es confidencial, no queremos que el usuario C tenga la conversión en su Lync sino que queremos hacerlo desde nuestra sesión o teléfono. Además, nos encontramos solos en la ubicación del usuario C, por lo que transferir la llamada sería viable pero correríamos el riesgo de perderla. Por lo que podemos estacionar la llamada, el usuario B estará en «espera» y nosotros podemos recuperarla marcando en nuestro Lync o teléfono la extensión que nos muestra en pantalla el Lync en el momento de estacionar la llamada. De esta forma, no tenemos la llamada en abierto durante el tiempo que nos movemos de ubicación, no tenemos que colgarla ni tenemos que transferirla y parecer «gacelas» corriendo hasta nuestra ubicación de destino en busca de contestar la llamada. El proceso es my sencillo, pero a lo mejor he líado algo la explicación, así que voy explicaros como configuramos este servicio y una demostración de su utilización.

Primero voy a configurar el intervalo de extensiones que utilizaremos para estacionar las llamadas, debemos tener en cuenta que el intervalo debe ser lo suficientemente amplio para estacionar las llamadas que utilizarán este servicio. Para ello podemos hacerlo mediante PowerShell o el Panel de Control de Lync Server, nosotros vamos a configurarlo de ambas formas. Para poder configurar este servicio necesitamos ser miembros de los siguientes grupos:

RTCUniversalServerAdmins
CsVoiceAdministrator
CsServerAdministrator
CsAdministrator

Panel de Control de Lync: Características de Voz

Como vemos únicamente debemos cubrir los siguiente datos y asigarlo a nuestro pool o servidor

PowerShell, New-CSCallParkOrbit

Sintaxis: New-CsCallParkOrbit

New-CsCallParkOrbit -Identity «Nombre» -NumberRangeStart ext_inicio -NumberRangeEnd ext_fin -CallParkService ApplicationServer:FQDN

Ejemplo

New-CsCallParkOrbit -Identity «Asir Park Pool» -NumberRangeStart 5585 -NumberRangeEnd 5590 -CallParkService ApplicationServer:pool.asirsl.com

Ahora ya tenemos configurado nuestras extensiones de «estancionamiento de llamadas», podemos configurar otras opciones como son:

– EnableMusicOnHold: se habilita o deshabilita la música en espera

– OnTimeoutURI: configurar el destino de reserva que se va a usar cuando se agota el tiempo de una llamada estacionada

– MaxCallPickupAttempts: que determina el número de veces que una llamada estacionada llama al teléfono de destino antes de reenviar la llamada al URI de reserva

– CallPickupTimeoutThreshold: que determina la cantidad de tiempo que transcurre desde que una llamada se aparca hasta que vuelve a llamar al teléfono que recibió la llamada

Estas opciones por defecto son las siguientes:

Microsoft recomienda configurar la opción OnTimeoutURI para el destino de reserva que se usará cuando el tiempo de espera de una llamada estacionada se agote y deje de sonar

Si queremos crear una nueva confguración específica del sitio debemos hacerlo con el cmdlet New-CsCpsConfiguration , queremos modificar estas opciones debemos hacerlo mediante el cmdlet Set–CsCpsConfiguration

Sintaxis: New-CsCpsConfiguration

New-CsCpsConfiguration -Identity <XdsIdentity> [-CallPickupTimeoutThreshold <TimeSpan>] [-Confirm [<SwitchParameter>]] [-EnableMusicOnHold <$true | $false>] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-MaxCallPickupAttempts <Int32>] [-OnTimeoutURI <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Ejemplo (para conocer el nombre del Site utilizaremos el siguiente cmdlet: Get-CsSite)

New-CsCpsConfiguration -Identity site:»Asir Lync» -CallPickupTimeoutThreshold 00:01:00 -EnableMusicOnHold $true -MaxCallPickupAttempts 1 -OnTimeoutURI sip:callparkdemo@asirsl.com

Si queremos modificar alguna opción utilizaremos Set-CsCpsConfiguration

Sintaxis: Set-CsCpsConfiguration

Set-CsCpsConfiguration [-Identity <XdsIdentity>] [-CallPickupTimeoutThreshold <TimeSpan>] [-Confirm [<SwitchParameter>]] [-EnableMusicOnHold <$true | $false>] [-Force <SwitchParameter>]
[-MaxCallPickupAttempts <Int32>] [-OnTimeoutURI <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Ejemplo
Set-CsCpsConfiguration -Identity Global -MaxCallPickupAttempts 5

Una vez configuradas las diferentes opciones debemos ejecutar el siguiente cmdlet para habilitar el «estacionamiento de llamadas» en la Directiva de Voz aplicada a lo usuarios, puesto que por defecto está deshabilitado: Set-CsVoicePolicy con la opción EnableCallPark. Primero debemos identificar nuestra Directiva de Voz y habilitar el «Estacionamiento de Llamadas»: Get-CsVoicePolicy

Get-CsVoicePolicy

Ahora debemos ejecutar el cmdlet con la opción EnableCallPark y tendremos habilitado el Estacionamiento de Llamadas en la Directiva de Voz:

Set-CsVoicePolicy -Identity Tag:Nombre -EnableCallPark $true

Estos cambios podemos hacerlo mediante el Panel de Control de Lync: Enrutamiento de Voz – Directivas de Voz

Algo importante es que las extensiones virtuales de estacionamiento de llamadas no deben estar normalizadas.

Espero que os sea de utilidad!!!

Call Park, Lync

Deshabilitar un usuario en el Directorio Activo y en Lync

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

En más de una ocasión os habréis encontrado con la situación de tener que deshabilitar un usuario en el Directorio Activo que tiene cuenta de Lync. Sin embargo esto no evita que el usuario pueda iniciar sesión en Lync durante un periodo máximo de 6 meses, y siempre en función de otros factores. Esto puede llegar a ser un problema muy importante para las organizaciones, puesto que el usuario podría estar realizando llamadas a la PSTN sin control o incluso hablar con gente de la organización y poder sacar información de la empresa sin que nadie de cuenta de ello.

Todo esto viene dado porque el usuario si en algún momento inicia sesión con el cliente Lync en un equipo fuera de la organización, y marca la casilla de "Guardar mi contraseña"

el servidor de Lync creará automáticamente un certificado para el usuario. Además, este certificado se publicará en la base de datos RTC con la clave privada y se almacenará en el equipo local del usuario:

Utilizar el certificado digital es algo que nos permite iniciar sesión más rapidamente y más beneficios en cuanto a la seguridad, pero el problema es que no tiene en cuenta si el usuario está o no deshabilitado en el Directorio Activo. El certificado tiene una duración de 180 días, de ahí que en función de cuando el usuario haya habilitado la opción de guardar contraseña y el tiempo que haya pasado hasta que lo hemos deshabilitado en el Directorio Activo tendrá tiempo suficiente para utilizar los siguientes servicios:

IM
Conferencias
Llamadas de Voz

Desde PowerShell podemos ver los certificados que tiene cada usuario, para ello debemos utilizar el siguiente cmdlet: Get-CsClientCertificate sip:direccion_sip

Como vemos en cada equipo que hayamos iniciado sesión y hemos activado la opción de "Guardar mi contraseña" nos ha crea un certificado de usuario como hemos visto en la captura anterior. Por lo tanto el usuario podrá iniciar sesión en Lync hasta que expire su certificado. También podemos revocar los certificados del usuario, pero para que el usuario ya no pueda iniciar sesión en Lync se tienen que dar las siguientes condiciones:

Equipos del dominio

Que expire el ticket de Kerberos (10 horas)

Usuarios Externos

Reinicio de los servidores de Lync
El usuario cierre e inicie sesión
El certificado haya caducado

*Esto es siempre que queramos que sea de forma inmediata cuando hayamos revocado el certificado, son tiempos que debemos tener en cuenta

Para revocar el certificado disponemos del siguiente cmdlet: Revoke-CsClientCertificate

Sintaxis
Revoke-CsClientCertificate [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] -Identity <UserIdParameter> [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Sinopsis
Los certificados de cliente permiten a los usuarios estar autenticados cuando inician sesión en Lync Server. Estos certificados son particularmente útiles en el caso de teléfonos y otros dispositivos que ejecutan Lync Mobile donde resulta complicado escribir el nombre de usuario o la contraseña. Revoke-CsClientCertificate permite a los administradores revocar certificados de cliente que se han emitido a un usuario. Este cmdlet se presentó en Lync Server 2010.

Descripción
Los certificados de cliente proporcionan una alternativa para autenticar a los usuarios con Lync Server. En lugar de proporcionar nombre de usuario y contraseña, los usuarios presentarán al sistema un certificado X.509. (Este certificado debe tener un nombre de sujeto o un nombre alternativo de sujeto que identifica al usuario). Para autenticarse, los usuarios solo deben escribir un número de identificación personal (PIN). Para un usuario de teléfono móvil, escribir un número de PIN suele ser más fácil que escribir un nombre de usuario o contraseña alfanuméricos.En cualquier momento, los administradores pueden revocar certificados de cliente emitidos a un usuario mediante el cmdlet Revoke-CsClientCertificate.

Revoke-CsClientCertificate revoca todos los certificados de cliente emitidos desde el servidor al usuario en cuestión.

Revoke-CsClientCertificate no elimina los certificados del dispositivo cliente; los certificados solo se eliminan del servidor. Sin embargo, es suficiente para evitar que un cliente use certificados con fines de autenticación: si no se puede encontrar un certificado en el servidor, sedenegará la solicitud de autenticación.

Ejemplo

Revoke-CsClientCertificate -Identity sip:sbuitrago@asirsl.com

Para evitar este "problema" y no llevarnos sorpresas a la hora de estar deshabilitar un usuario en el Directorio Activo debemos deshaiblitar el usuario en Lync, bien vía PowerShell o Panel de Control vía Web:

PowerShell

Disable-CsUser sip:direccion_sip

Panel de Control

Espero que os sea de ayuda y tengáis claro el proceso para deshabilitar un usuario en el AD y también en Lync

Active Directory, Lync

¿Qué certificados necesitamos para Lync?

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (1 Comments)

En la fase de planificación de nuestra infraestructura, siempre hay un punto que hace referencia a los certificados que debemos adquirir. Debemos tener muchas cosas en cuenta, pero una básica son que servicios vamos a publicar y con que nombre. Todos sabéis que el nombre del certificado debe coincidir con el nombre del servicio a publicar, sino no funcinarán correctamente o directamente no funcionarán los distintos servicios. Seguro que en alguna ocasión habéis visto esta alerta en vuestro navegador.

En este caso el único problema que tenemos es que el servidor tiene asignado un certificado con un nombre diferente al que nosotros hemos tratado de conectarnos a través de nuestro navegador, y nos avisa de que podemos estar visitando un sitio diferente al que realmente queremos. O bien que estamos utilizando un certificado privado (emitido por nuestra CA en Windows) y no tenemos el certificado raiz instalado en nuestro equipo. Esto no quiere decir que el certificado no esté realizando su función que es la de cifrar el tráfico, pero el nombre que tiene no concuerda con el nombre de la URL que estamos visitando. De ahi que no es solo una cuestión puramente de seguridad, sino también de confianza. Si tenemos un servicio público al que se tienen que conectar nuestros clientes y les aparece esta advertencia, desde luego nuestra imagen como empresa quedaría por lo menos en entredicho. Además a día de hoy un certificado simple tiene un coste inferior a 80€ / año, por lo que no es una cuestión económica el no tener un certificado público.

Comentado esto, vamos a centrarnos en que debemos tener en cuenta a la hora de adquirir un certificado para nuestras implementaciones de Lync. Básicamente yo recomiendo siempre dos certificados: SAN y WILDCARD. Estos certificados serían para servicios diferentes, el certificado SAN para nuestros servidores EDGE y el Wildcard para nuestros Front-END y sus servicios Web. Como todos sabemos los nombres de los servicios que estamos publicando en el EDGE suelen ser los siguientes:

WEBCONF.ASIRSL.COM

AV.ASIRLAB.COM

SIP.ASIRLAB.COM

EDGE.ASIRSL.COM (opcional)

Esto son los nombres que debería tener nuestro certificado SAN (Subjet Alternate Name), de manera que podamos instalarlo en nuestros servidores EDGE y contengan el nombre de todos los servicios que vamos a publicar y en un solo certificado. Siempre estoy hablando de los certificados asignados a las interfaces externas, por lo que son certificados de una entidad certificadora pública (Verisign, Digicert, Thawte). Con esto tendríamos nuestro servidores/es EDGE correctamente configurados en cuanto al certificado se refiere, siempre y cuando los nombres de los certificados se correspondan con los nombres de los servicios (lo doy por hecho).

Ahora vamos a ver los certificados que necesitamos para el resto de servicios y que no pasan por el EDGE, sino por el Front-END o Director. En estos roles publicamos los distintos servicios con los siguientes nombres "por defecto":

lyncdiscover.asirlab.com

lync.asirlab.com o pool.asirlab.com (opcional según el nombre que hayamos configurado)

dialin.asirlab.com

meet.asirlab.com

Estos servicios se suelen publicar a través de un ISA Server, TMG o similar como reverse proxy, y es a ese servidor a cual le tenemos que instalar el certificado externo que adquiramos. El certificado que yo recomiendo siempre es un WILDCARD, porque os permitirá posteriormente utilizarlo para publicar más servicios que los de Lync, por ejemplo: OWA, SharePoint, CRM, WAC y cualquier otra URL del mismo dominio con el siguiente FQDN: loquesea.asirlab.com. De esta forma podéis aprovechar el certificado para publicar más servicios que exclusivamente los de Lync. Y si por ejemplo hoy publicais el meet.asirlab.com únicamente y dentro de 6 meses queréis tener disponible el dialin.asirlab.com o lyncdiscover.asirslab.com ya no tendréis que adquirir más certificados, de cualquier otra forma si. Aqui también podemos disponer de un certificado SAN, pero el coste del certificado con los 3 nombres obligatorios para el EDGE más los dos del Front-END tendrá un sobre coste superior a tener un WildCard y un SAN. Además de que para cada servicio completamente diferenciado es recomendable tener distintos certificados, pero eso ya es otro tema.

Ahora bien, si nuestra infraestructura cuenta con un TMG para publicar las distinas URL, yo recomiendo que el certificado que se instale a los servidores sea de vuestra Entidad Certificadora Privada, puesto que os permite solicitar tantos certificados como queráis sin tener que preocuparos por el coste. Si os olvidáis de algún nombre en la fase piloto, solo tenéis que volver a solicitarlo y no tendréis problema de costes económicos. Tened en cuenta que el TMG presentará en el certificado público al exterior pero hacia los servidores internos se conectará con el certificado interno, y que además el TMG al estar en el dominio ya tiene el certificado raiz de confianza instalado y no tendréis problemas con la publicación de cualquier servicio Web de Lync. Con el certificado Wildcard (*.asirlab.com) podéis publicar con el mismo listener de TMG más servicios como he comentado anteriormente. Esto también es aplicable al EDGE, en su interfaces interna puede tener tener un certificado de nuestra CA Privada y funciona sin problema.

Esto siempre y cuando tengáis un solo dominio SIP, si tenéis varios dominios SIP y queréis tener certificados públicos, el certificado debe contener todos los nombres FQDN de todos los dominios. Como he comentado yo recomiendo hacerlo de esta forma, es de las más económicas, permite la reutilización del certificado para otras publicaciones y nos permite publicar distintos servicios de Lync que inicialmente no lo habíamos hecho sin coste adicional. Todo esto tiene sus matices, pero es cuestión de tener claro que servicios vamos a publicar, que nombres tendrán esos servicios y como se van a publicar al exterior.

Si además implementamos los servicios de UM de Exchange, el certificado que debemos utilizar es también uno de nuestra Entidad Certificadora. Como nuestros servidores de Lync forman parte del dominio, no tendrán problemas con la validación del certificado que ambos se están presentando para la autenticación de servicios. El certificado del servidor Exchange para el ROL de UM debe tener como nombre común el nombre FQDN del servidor sino, no funcionará

Y por último para la integración del OWA con Lync, es más de lo mismo pero teniendo en cuenta algo muy sencillo. Cuando creemos nuestras aplicación de confianza el nombre debe ser el mismo que el nombre común que hemos configurado en el certificado asignado en Exchange para la integración con Lync

Sino es asi podréis encontraros de que todo está correctamente instalado, configurado y publicado pero … error!!! (esta captura representa uno de los posibles errores)

Como véis es muy sencillo, pero es cuestión de tener claras nuestras necesidades y el resto es aplicar el conocimiento que ya tenéis sobre Lync y Certificados. Si no queremos utilizar certificados públicos podemos hacer exactamente lo mismo con nuestra CA Privada, pero al resto de usuarios que no tengan las máquinas en nuestro dominio debemos pasarles nuestro Certificado Raiz para que lo instalen en el contenedor adecuado de sus equipos

Pero si queréis federar vuestro Lync con Microsoft, Google, etc.. debéis disponer de certificados públicos en vuestro EDGE. Si queréis federaros con otras compañias y no tenéis certificados públicos únicamente debéis "intercambiar" vuestras CA.

Aqui os muestro varias capturas de pantalla sobre un certificado WildCard conectándome a distintas URLs y otro SAN:

WildCard: nos conectamos a https://soporte.asirsl.com

WildCard: nos conectamos a https://meet.asirsl.com

SAN: Certificado de un EDGE con los nombres de los distintos servicios publicados

Para terminar este artículo comentaros los servicios que utilizan los distintos clientes de Lync:

Cliente Lync: EDGE

Lync Mobile: Front-END o Director Publicando las distintas URL via TMG u otro proxy

Lync Web APP: Front-END o Director Publicando las distintas URL via TMG y otro proxy

Precios de Certificados

WildCard	SAN

Aqui os dejos algunos interesantes:

Error de certificado cuando usamos Thawte

Windows Server 2012, Instalación de una CA

Creación de CSR para Lync de forma sencilla

Espero que os sea de utilidad!!!

Certificados, Lync

El cliente Lync 2010 no inicia sesión en Lync Server 2013

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Este es un error muy común cuando hemos migrado nuestra versión de Lync Server 2010 a 2013 y los usuarios no tienen correctamente "parcheado" sus sistemas. Como sabéis el cliente de Lync 2010 es compatible 100% con Lync Server 2013, logicamente con las opciones disponibles este cliente. Pero esto no implica que no debamos realizar ciertas tareas de mantenimiento, como es la instalación de las actualizaciones correspondientes de nuestro cliente, sino obtendremos el siguiente mensaje cuando tratemos de iniciar sesión:

La versión mínima de compabilidad del cliente Lync 2010 con Lync Server 2013 es la 4.0.7577.4103 como vemos en la siguiente captura del Panel de Control de Lync

podéis cambiar el comportamiento de bloqueo, pero logicamente no se recomienda. En algunas ocasiones tendréis la necesidades de cambiarlo durante cierto tiempo mientras los usuarios actulizar sus clientes, pero debería ser eso, algo muy puntual y de extrema necesidad.

Para "solucionar" este "problema" debéis instalar la siguiente actualización: Lync 2010 Hotfix KB 2737155 (64 bit)

Como véis tiene muy fácil solución, pero siempre es recomendable que tengáis vuestros sistemas actualizados y no solo el sistema operativo.

Espero que os sea de utilidad!!

Lync Server 2013 Monitoring Management Pack

Estacionamiento de Llamadas o Call Park en Lync

Deshabilitar un usuario en el Directorio Activo y en Lync

¿Qué certificados necesitamos para Lync?

El cliente Lync 2010 no inicia sesión en Lync Server 2013

Santiago Buitrago

Entradas recientes

Comentarios recientes

Archivos

Categorías

Únete y comparte tu conocimiento

Sígueme en Twitter