Microsoft Lync Server
Header

Una de las cosas que más ha evolucionado en los últimos años ha sido la forma en la que nos comunicamos, desde el "tradicional" e-mail hasta las videoconferencias desde cualquier dispositivo ….

IM_NO_ES_UN_EMAIL.jpg
 
Pero en este artículo me gustaría comentar el "mal uso" que se hace a veces de la mensajería instantánea, muchas veces confundiendo su uso con el del correo electrónico. En años anteriores (y en la actualidad) los usuarios utilizan el correo como una vía de comunicación en "tiempo real", enviándose en menos de dos minutos 10 correos electrónicos, algo que se debería hacer con la IM. Un e-mail al final debe ser algo breve, pero no tanto como un IM, sobre todo pensando en que es una vía de comunicación asíncrona y que no debemos esperar una respuesta de forma inmediata. Entre que lo enviamos, pasa por los distintos filtrados y servidores, un e-mail puede llegar a tardar unos 60 segundos (es posible que menos, pero utilicemos este valor como referencia) en llegar al buzón de destino. Y en muchas ocasiones se utiliza el e-mail para contestar un , OK, NOS VEMOS, PERFECTO, ME VALEACEPTADO, etc.. para esto tenemos la IM por favor. De ahi que herramientas como Lync nos ayudarán a tener unas conversaciones más fluidas con nuestros compañeros / clientes / socios / etc…, además de minimizar el almacenamiento utilizado y de optimizar las comunicaciones profesionales (como se hacía antes con las comunicaciones personales (Yahoo Messenger, Windows Messenger, etc…)). La IM es casi un sistema síncrono, ambos participantes podemos envira y recibir mensajes en tiempo real, otra cosa será la velocidad a la que podamos leer los mensajes del resto de participantes. Pero aquí es donde en ocasiones se utiliza (desde mi punto de vista) se realiza una "mal uso" de la IM, porque muchos usuarios tratan de tener conversaciones de la misma forma que con los correos electrónicos: Mensajes largos. En la IM lo ideal es tener las conversaciones que queramos, pero con mensajes rápidos, cortos y esperando respuestas de la misma forma. Si queremos enviar un mensaje que tardamos 60 segundos en escribir, ya no es un mensaje instantáneo … es un correo como los de siempre. La idea de la IM se basa en rápidas respuestas y comunicaciones fluidas, y si tenemos que ver esto  a cada mensaje de alguien …. xxxxx está escribiendo un mensaje
 
IM_NO_ES_UN_EMAIL_2.jpg
 
No utilicemos la IM como un correo por favor, pero tampoco hagamos lo contrario … pero si realmente queremos agilizar las comunicaciones empresariales daremos el salto a la Videoconferencia y con Lync esto podemos hacerlo de manera sencilla … desde un e-mail podemos llegar una videoconferencia en 3 sencillos pasos pasando por la IM desde un e-mail , Audio  y luego Videoconferencia
 
IM_NO_ES_UN_EMAIL_3.jpg
 
Si tenemos unos de estos e-mails que se convierten en un partido de tenis, lo mejor que podemos hacer es que cuando nos llegue un e-mail pulsemos Control + IM y se nos abrirá una conversación de IM con el remitente y ya podemos establecer una comunicación más fluida. Si consideramos que no es suficiente y queremos expresarle de viva voz nuestros comentarios, podemos llamarlo directamente desde la conversación y si por último queremos tener una sensación completa de trabajo colaborativo podemos pulsar en el botón de videoconferencia para iniciarla en ese mismo instante.
 
Debemos optimizar el tiempo que dedicamos a  contestar e-mails, para ello podemos hacerlo con nuestra herramienta de Comunicaciones Unificadas por excelencia: Microsoft Lync. Como habéis observado pasar de leer un e-mail a tener una videconferencia con nuestros contactos. Además, no confundamos el funcionamiento de cada herramienta, un correo debe ser algo más extenso y no buscando una respuesta rápida. Sí queremos una respuesta inmediata y de un tema concreto en el menor tiempo posible pero sin más distracciones, enviemos un IM y si queremos tratar temas con cierta duración y además poder interactuar de forma natural tenemos las llamadas de VoIP y las Videoconferencias.
 
La correcta utilización de las distintas herramientas tienen muchos más beneficios que los que os he comentado, pero para mi es importante que la IM sea rápida y fluida … además con la llegada de todos los dispositivos móviles, yo creo que la IM es la forma más eficiente de comunicarnos con este tipo de dispositivos. Claramente, después de las llamadas de Audio o Videoconferencias que nos aportan un valor añadido a nuestras comunicaciones, generando confianza y transparencia en nuestras conversaciones. Debemos ser conscientes que los e-mails no transmiten sensaciones, pasión ni entonación, por lo que en muchas ocasiones pueden ser mal interpretado por la persona que lo recibe. En la IM se ha mejorado en muchos aspectos, porque la comunicación es casi en tiempo real y podemos contestar acto seguido de que recibimos un mensaje, y utilizando correctamente los emoticonos llegamos a un punto de comprensión de la conversación muy elevado. Teniendo en muchos casos claro lo que queremos trasmitir, sin que nuestros contactos tengan otra percepción de lo que queremos comentarles.
 
En resumen, por favor, utilicemos las herramientas de forma correcta y no cambiemos la filosofía con la que fueron creadas. Pensemos que la tecnología nos ayudará a "humanizar" las comunicaciones y acercarnos a un mundo virtual lo más real posible.
 
Espero que os sea de utilidad!!!

​En Lync Server 2010 y 2013 tenemos un servicio ubicaciones diseñado para E911 (sería el 112 en Europa), pero en este caso vamos a ver como podemos utilizarlo para mostrar la ubicación de los usuarios de Lync. De tal forma que cuando un usuario inice sesión en Lync, podamos de forma automática mostrar su ubicación en función de en que subred haya iniciado sesión, un punto de acceso wireless, un switch determinado, etc…

Ubicacion_usuarios_Lync_Lis_1.jpg

Lo primero que debemos hacer es configurar los orígenes de donde vamos a sacar la información de la ubicación, para ello tenemos los siguientes cmdlets:

  • Set-CsLisLocation: Crea una ubicación o modifica una existente en la base de de datos de configuraciones de ubicaciones (E911)
  • Set-CsLisPort: Nos permite  asociar un puerto y una ubicación
  • Set-CsLisServiceProvider: Nos permite crear o modificar la información sobre el servicio web que nos ofrece un proveedor de enrutamiento de E911
  • Set-CsLisSubnet: Nos permite crear una asociación entre una ubicación y una subred IP
  • Set-CsLisSwitch: Nos permite crear una asociación entre una ubicación y un switch de red, utilizando para ello la MAC del Switch (ChassisID)
  • Set-CsLisWirelessAccessPoint: Nos permite crear una asociación entre una ubicación y un punto de acceso inalámbrico, utilizando para ello el BSSID

Como vemos tenemos múltiples formas de configurarlo, pero yo soy voy a mostrar lo que podéis utilizar de forma más sencilla:

  • Set-CsLisSubnet: Nos permite crear una asociación entre una ubicación y una subred IP
  • Set-CsLisWirelessAccessPoint: Nos permite crear una asociación entre una ubicación y un punto de acceso inalámbrico, utilizando para ello el BSSID

En todas las empresas con Lync tienen una o varias subredes (misma ubicación u oficinas conectadas mediante VPN) y uno o varios puntos de acceso Wifi. Claramente un switch también lo vamos a tener, pero la configuración es muy similar en ambos casos.

Veamos primero como hacerlo con los Puntos de Acceso inalámbricos, de tal forma que podamos asignar una ubicación a los usuarios que estén conectados a un punto de acceso en concreto. Lo primero que debemos conocer es el BSSID (dirección física (MAC) del punto de acceso al que nos conectamos), yo os lo voy a mostrar en dos AP de Cisco desde cli: Show dot11 bssid

AP2

 

Ubicacion_Lis_AP_4.png
AP3

 

 

Ubicacion_Lis_AP_5.png
 
Ahora que ya tenemos la MAC de cada punto de acceso, vamos a configurar una nueva ubicación mediante el punto de acceso, para ello tenemos el siguiente cmdlet:

 

Set-CsLisWirelessAccessPoint -BSSID 00-3a-99-2b-b2-30 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas-AP2

Ubicacion_Lis_AP_2.png

Set-CsLisWirelessAccessPoint -BSSID 00-3a-99-3c-34-d0 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas-AP3

 

Ubicacion_Lis_AP_2-1.png
El parámetro obligatorio es el BSSID, sino sería imposible saber a que punto de acceso estamos conectados, pero como vemos tenemos más parámetros disponibles:

 

  • Description
  • Location
  • CompanyName
  • HouseNumber
  • HouseNumberSuffix
  • PreDirectional
  • StreetName
  • StreetSuffix
  • PostDirectional
  • City
  • State
  • PostalCode
  • Country

Antes de publicar los cambios, vamos a crear también varias ubicaciones por la subred en la que nos encontremos, para ello tenemos los siguientes cmdlets:

Set-CsLisSubnet -Subnet 192.168.100.0 -Country ES -CompanyName "ASIR INTRASITE" -Location Ponteareas
Ubicacion_Lis_AP_2-2.png

 

 
Set-CsLisSubnet -Subnet 192.168.250.0 -Country ES -CompanyName "ASIR INTRASITE" -Location CPD
Ubicacion_Lis_AP_2-3.png
 
Una vez que hemos añadido los puntos de acceso y/o subredes (cada uno lo que quiera o ambas cosas), lo que nos queda es publicar los cambios para que se vean reflejados en los usuarios de Lync (deben cerrar y abrir nuevamente la sesión en sus clientes Lync). Para publicar las ubicaciones, tenemos el siguiente cmdlet: Publish-CsLisConfiguration

 

 

Ubicacion_Lis_AP_3.png
 
Antes de ver el efecto que tiene esta configuración sobre los usuarios, vamos a ver las distintas ubicaciones creadas con los cmdlets correspondientes:

 

Get-CsLisSubnet | ft AutoSize

Ubicacion_Lis_AP_3-2.png

Get-CsLisWirelessAccessPoint | ft AutoSize

 

Ubicacion_Lis_AP_3-3.png
 
Ahora sí, vamos a probar que verían los usuarios cuando se conectan en una subred determinada o a alguno de los puntos de acceso definidos:

 

Sin ubicación definida

Ubicacion_Lis_AP_1.png

Location Ponteareas

 

Ubicacion_Lis_AP_1-1.png
Location CPD

 

 

Ubicacion_Lis_AP_1-2.png
Location Ponteareas-AP3

 

 

Ubicacion_Lis_AP_1-3.png
 
Y así según nos vayamos moviendo de subred o punto de acceso, por último comentaros que la base de datos de ubicación se actualizar cada 4 horas, pero si queremos cambiarlo podemos hacerlo con el siguiente cmdlet:

 

Set-CsLocationPolicy -LocationRefreshInterval 1

Ubicacion_Lis_AP_6.png

y si queremos ver la configuración que hemos modificado tenemos el siguiente cmdlet:

Get-CsLocationPolicy

Ubicacion_Lis_AP_7.png

Por último me gustaría puntualizar varias cosas:

  • Solo se puede establecer las ubicaciones a usuarios que se conectan en interno (conexiones directas los Front-END como en el esquema), no a los usuarios que se conecten vía EDGE.
  • La ubicación si no se actualiza de forma automática si nos movemos de subred o punto de acceso, para esto tendremos que cerrar e iniciar sesión en Lync nuevamente

En el esquema que os muestro al inicio del artículo, he puesto varias ubaciones vía subred y un punto de acceso. Además, hay dos ubicaciones remoas que podéis configurar también vía Set-CsLisSubnet porque son usuarios de Lync que se conectan vía VPN a los Front-END de forma directa, no así el usuario remoto que lo hace vía EDGE. Lo comento porque luego los cmedlets que he puesto no refleja lo puesto en el esquema, simplemente es una referencia gráfica de lo que podríais implementar.

Espero que os sea de utilidad!!!

​En ocasiones podemos encontramos con este "problema" cuando iniciamos sesión con el cliente Lync 2013 y el dominio SIP no coindice con el nombre común y nombre de sujeto en el certificado del Servicio Web de Lync Server. Aquí el problema no es si tenemos el certificado raíz de la CA que ha emitido el certificado, siempre y cuando lo tengamos instalado claramente, pero de todas formas el error sería otro (esto lo comento por aclararlo)

Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_1.png
Como sabemos el cliente Lync 2013 utiliza un descubrimiento automático para encontrar el servidor del Lync (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?), de ahí que en la misma instalación con el cliente Lync 2010 no tengáis problemas de acceso y con el 2013 os muestre esta alerta.  Aquí os muestro dos capturas de Wireshark una de un cliente Lync 2010 y otra de Lync 2013 con un mismo servidor y cuenta de usuario:
 
Cliente Lync 2010: como podemos apreciar el nombre de dominio (oculto por razones obvias) es XXX.XXX y el nombre de dominio del servidor de Lync es srv-lync00.grupoXXX.XXX, vamos que no es el mismo nombre de dominio que el dominio SIP de los usuarios, pero igualmente como el certificado es de confianza y el nombre del servidor coincide con el nombre del certificado (Certificado SAN) no tiene problema y conecta al usuario sin mostrar advertencia alguna:
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_Lync_2010.png
Cliente Lync 2013: como podeoms ver el cliente 2013 busca los registros lyncdiscoverinternal.xxxx.com, lyncdiscover.xxxx.com, etc…  y el nombre del servidor es el mismo (que con el cliente 2010)  srv-lync00.grupoxxxx.com y tiene un nombre de dominio diferente al dominio SIP y ahí está el "problema", puesto que con el modelo de seguridad del cliente Lync 2013 en la resolución de nombres nos mostrará una advertencia por si estamos seguros de que nos estamos conectando al servidor adecuado.
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_6.png
Para corregir este problema, sino podemos cambiar los nombres asignados a los certificados, debemos crear un GPO y configurar los dominios SIP que queramos añadir de confianza para el usuario. Para poder configurar las directivas de Lync, primero debemos descargarnos las plantillas Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool (Plantillas ADMX Office 2013 y Configuración Lync 2013) y luego reailzar la siguiente configuración: Configuración de Usuario – Directivas – Plantillas administrativas : xxxx – Microsoft lync 2013 – Directivas de características de Microsoft Lync – Lista de confianza de dominio
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_3.png
Y añadimos los nombres de dominio SIP en los que tengamos este problema, porque recordar si que iniciamos sesión con un usuario que su dominio SIP está como nombre común y sujeto en el certificado del servicio web de Lync no os mostrará alerta alguna: * Fijaros que pode defecto los dominios lyn.com, outlook.com, lync.glbdns.microsoft.com y microsoftonline.com ya son de confianza y no los podemos agregar
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_4.png
Una vez que se aplique a todos los usuarios, ya nos mostraré el error de certificado y se conectará de forma transparente. Si este cambio queréis hacerlo sobre equipos que no están en el dominio, debéis modificar el registro del usuario y añadir los dominios SIP manualmente. Para ello debemos acceder a la siguiente ruta del registro HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync y crear un nuevo Valor de Cadena con el nombre TrustModelData y escribir los nombres de dominio SIP que queramos configurar:
Lync_No_Puede_Comprobar_Que_El_Servidor_Es_De_Confianza_2.png
Ahora la próxima vez que iniciéis sesión con vuestro cliente Lync 2013 y se den las mismas circunstancias en cuanto al nombre común y sujeto del certificado del servicio Web de Lync Server, ya no mostrará la alerta e iniciará sesión de forma normal.
 
Espero que os sea de utilidad!!!

​En este esquema de red la configuración de red es muy similar al anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte III)), pero tenemos una configuración algo diferente en lo que se refire a los routers. Además, he añadido una capa de complejidad añadiendo varios switchs, en los que configuraremos varias VLAN. La idea de las VLAN nos permitirá definir diferentes subredes IP (una por VLAN) y además nos pemitirá aislar la red de servidores, estaciones de trabajo y elementos de red a nuestro antojo.  Además, cuando la red empieza a tener cierto volumen de dispostivos es bueno que configuremos diferentes VLAN para aislar la red y además optimizar los dominios de broadcast (pulsar en la imagen para verla a tamaño real)

Topologías Lync 2013_Esquema_4_1.jpg

Como vemos en este esquema tenemos una VLAN para servidores, varias para las estaciones de trabajo, la red inalámbrica y los teléfonos IP para Lync. Además, tenemos dos configuraciones interesantes en cuanto a la VLAN como son la VLAN 15 que se utilizará con una subred 172.26.0.0/28 para las interfaces externas del Reverse-Proxy y EDGE y que será en donde publiquemos los disintos servicios. Y además, tenemos la VLAN 20 para la subred 172.26.1.0/29 para las interfaces internas del Reverse-Proxy y EDGE. Esta configuración es diferente al de los otros esquemas, porque la separación de las subredes se ha hecho a nivel de VLAN, por lo que no será suficiente con que alguien cambie la IP de su equipo para estar en otra subred y tener acceso a la subred comentada, puesto que esto se define a nivel de switch.
 
Todos los switchs son de Capa 3 y que utilizaremos para el ruteo entre las VLANs, cada switch tendrá la primera dirección IP del rango en la que se encuentre para hacer de gateway de los equipos o servidores. La única excepción es entre el switch central y el switch que tiene configurada las VLANs para las estaciones de trabajo, porque se ha configurado una VLAN 30 para conectar ambos switchs  y que el Switch de las estaciones de trabajo utilizará como default gateway para que todo el tráfico que no conoce se lo envíe al switch que tiene directamente conectado. El switch central tiene también como default gateway  la IP 192.168.200.1, que es la VIP que se ha configurado entre los dos routers configurados con HSRP (o GLBP en función de lo que queráis hacer), porque este swtich será el primer salto que tendrán los esquipos para conectar con internet. Pensad que el switch central es el único que tenemos conectado fisicamente con el Switch más cercano a los routers, por lo que es el único "camino" para llegar a internet (hasta los routers), y como cada switch tiene una serie de VLANs con su correspondiente IP. Cada IP que tiene configurada el switch en cada VLAN es la IP que los equipos tienen como Default Gateway. Si podemos utilizar un protocolo de enrutamiento (RIP, OSPF, EIGRP, etc..) podemos configurar de forma automática el enrutamiento entre todas las VLAN del switch vecino, porque cada switch tiene el conocimiento  suficiente para interconectar a nivel IP todas las subredes. Pero bueno, esta configuración es básica en cualquier red con VLAN, pero aquí lo interesantes es definir ciertas ACL en las VLAN 15 Y 20 para filtrar el tráfico hacia y desde las interfaces que queremos proteger y publicar a la red del Reverse-Proxy y EDGE.
 
En la interface LAN del EDGE y Reverse-Proxy NO TENEMOS QUE CONFIGURAR DEFAULT GATEWAY y sí en la interface WAN, por lo que como deben tener acceso a la redes internas vía la interface LAN, debemos crear las diferentes rutas estáticas en cada servidor para poder tener acceso a las distintas subredes internas. Aquí dejar claro, que a través de la interface WAN no se pueden comunicar con nadie más que con Internet (hacia y desde), por lo que debemos configurar los diferentes filtrados en la VLAN 15 para evitar el acceso entre VLAN. Las rutas estáticas comentadas son las siguientes:
 
Topologías Lync 2013_Esquema_4_2.jpg
El EDGE tiene que tener acceso a todas las redes internas en donde tengamos usuarios con Lync que quieren conectarse con usuarios externas, y el Reverse-Proxy solo necesita tener acceso a la red de servidores y si queremos solo al Exchange, Front-END y Office Web App. En el ejemplo, os expongo la ruta estática hacia toda la subred IP de la VLAN de servidores. Como podéis apreciar el Default Gateway siempre es el switch al que están directamente conectados, puesto que tiene la subred IP del mismo rango y además la tabla de enrutamiento configurada para hacer el ruteo correspondiente. El valor que he puesto en la ruta estática if N, el valor de N se corresponde con la interface en la que tenemos configurada la IP interna del servidor Reveser-Proxy  o EDGE, esto ya lo he comentado en los siguientes artículos:
En este esquema de red lo que tenemos que tener en cuenta, son las rutas estáticas a crear porque si o si es algo obligatorio con este escenario. El resto es más o menos similar a los tres artículos anteriores, la configuración de los routers también está en Alta Disponibilidad, saliendo a internet por la VLAN 10  que conectará con la VIP 192.168.200.1 y que tendrá como activo para la salida a Internet de los equipos internos el router 1 y como pasivo el router 2. La peculariedad aquí, es que ambos routers tienen dos grupos de Alta Disponibilidad (HSRP) por lo que tenemos dos VIP, y la segunda 172.26.0.1 tendrá como activo el router 2 por donde publicaremos los servicios del EDGE (todos por los puertos estandar ya que tenemos tres IPs Públicas en el Router 2 y 1 IP Pública en el Router 1.
 
En el switch en el que tenemos conectados los routers, hemos configurado dos puertos en el switch como troncales, en donde solo permitimos transportar tráfico de las VLAN 10 y 15. Esto es así, porque solo tenemos una interface Internet en los routers en esta ocasión, pero que si podemos configurarlos como Router-On-Stick (http://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/14976-50.html) y así configurar una subred IP en cada subinterface. Aquí mucho cuidado, recordad  que debéis configurar una ACL aplicada de entrada en la subinterface para evitar que ambas subredes internas puedan tener conectividad entre ellas. Pensad que la subred 172.26.0.0/29 es para crear una "DMZ vía VLAN" para las interfaces Externas del Reverse-Proxy y EGE. La subred 192.168.200.0/28 será para ofrecer conectividad a Internet a las subredes internas, puesto que por debajo tenemos el switch central que tiene acceso a esta VLAN y tiene la posibilidad de enrutar todo el tráfico que no "conozca" hacia este gateway, que se corresponderá con el Router 1 que hemos configurado como activo para este grupo de HSRP, y en el caso de que el Router 1 no está disponible los usuarios no tendrán problema de acceso a internet porque entrará como activo el Router 2. En este caso, lo que no funcionaría serían los acceso al Exchange, Office Web App y el cliente Lync móvil. Esto es así, porque las publicaciones y registros DNS apuntan a la IP que gestiona el Router 1. Pero lo que si seguimos mantenimiento sería la conexión desde el exterior de los usuarios de Lync, las Federaciones, etc… porque el router 2 estaría activo. Si el Router 2 no está disponible, las conexiones de Lync desde el exterior no funcionarían pero si los servicios Web de Lync. En este caso aún teniendo los servicios web de Lync activos, no podemos hacer mucho, porque no podemos iniciar sesión con el cliente Lync de escritorio, ni los teléfonos IP que tengamos fuera de la red  pero si en el cliente móvil. Pero claro, el cliente móvil cuando queremos utilizarlo para llamar por VoIP no podremos, porque todo el tráfico RTP va por el EDGE además de otra características.
 
Como vemos, aunque el escenario cambie y aumente la complejidad de la red, las diferencias a nivel de Lync con mínimas y que os expongo en los siguientes puntos (siempre relacionándolo con los 4 esquemas vistos hasta la fecha):
  • Debemos cambiar los puertos estándar de los sevicios  del EDGE
  • Crear rutas estáticas en el EDGE y Reverse-Proxy si tenemos varias subredes internaces en la red o si estamos en una subred diferente a la de los equipos con Lync
El resto de configuraciones van siempre ligadas a la red:
  • Configuración VLAN
  • Configuración HSRP o GLBP
  • Configuración DMZ
  • Configuración Router on a Stick
  • Configuración dos IPs Privadas en las interfaces LAN de los routers 
Como vési es cuestión de ir adaptando las configuraciones en función de los elementos con los que contamos, no os quedéis con las direcciones IP y configuraciones de Alta Disponibilidad, porque cada uno podrá configurar lo que quiera. Yo simplemente lo expongo por tener una referencia, pero cada uno configurará lo que quiera/necesite.
 
Espero que os sea de utilidad!!!

Las directivas de cliente nos permite determinar que características de Lync tendrán disponibles los usuarios, estas podemos aplicarlas a nivel Global,  de Sitio y Usuario.

Políticas de Cliente_Lync_2013_Global_Site_User.jpg
Las directivas de cliente podemos apliarlas a tres niveles:
  • Global: A todos los usuarios de Lync en la topología
  • Sitio: A todos los usuarios de un sitio en nuestra topología
  • Usuario: A los usuarios de forma individual
Para crear, modificar, asignar o eliminar una directiva de cliente tenemos los siguientes cmdlets:
  • New-CSClientPolicy: Crear una nueva directiva de Sitio o Usuario
  • Get-CSClientPolicy: Ver la definición de la directiva
  • Set-CSClientPolicy: Establecer los valores de la directiva
  • Grant-CSClientPolicy: Asignar la directiva
  • Remove-CSClientPolicy: Borrar una directiva
  • New-CSClientPolicyEntry: Añade nuevas opciones

Comentaros que la directiva Global no la podemos eliminar, únicamente podemos establecer los valores queramos y para ello lo haremos con el siguiente cmdlet:

Set-CsClientPolicy -Identity Global -DisableSavingIM $True

Set-CsClientPolicy -DisableSavingIM $True

He puesto los dos cmdlets porque al ser la directiva Global sino colocáis el -Identity ya sabe es la directiva Global. También tenemos la directiva de Sitio, la configuración es muy similar, porque no utilizamos el cmdlet Grant-CsClientPolicy para asignar la directiva, simplemente la creamos y establecemos los valores que queramos y automáticamente se establecen para los usuarios del sitio. Para crear la directiva de Sitio, lo primero es conocer el nombre de los sitios que tenemos configurados, para ello utilizaremos el siguiente cmdlet: Get-CsSite

Get-CsSite | fl Identity

Políticas de Cliente_Lync_2013_Global_Site_User_1.jpg
Ahora que ya conocemos el nombre del Site, utilizaremos el cmdlet New-CsClientPolicy para crear la directiva asociada a este sitio:

New-CsClientPolicy -Identity "Site:Asir Lync"

Ahora nos ha creado y ya es de aplicación la nueva directiva con el nombre sss y con sus valores por defecto:

Identity                                    : Site:Asir Lync
PolicyEntry                                 : {}
Description                                 :
AddressBookAvailability                     : WebSearchAndFileDownload
AttendantSafeTransfer                       :
AutoDiscoveryRetryInterval                  :
BlockConversationFromFederatedContacts      :
CalendarStatePublicationInterval            :
ConferenceIMIdleTimeout                     :
CustomizedHelpUrl                           :
CustomLinkInErrorMessages                   :
CustomStateUrl                              :
DGRefreshInterval                           :
DisableCalendarPresence                     :
DisableContactCardOrganizationTab           :
DisableEmailComparisonCheck                 :
DisableEmoticons                            :
DisableFeedsTab                             :
DisableFederatedPromptDisplayName           :
DisableFreeBusyInfo                         :
DisableHandsetOnLockedMachine               :
DisableMeetingSubjectAndLocation            :
DisableHtmlIm                               :
DisableInkIM                                :
DisableOneNote12Integration                 :
DisableOnlineContextualSearch               :
DisablePhonePresence                        :
DisablePICPromptDisplayName                 :
DisablePoorDeviceWarnings                   :
DisablePoorNetworkWarnings                  :
DisablePresenceNote                         :
DisableRTFIM                                :
DisableSavingIM                             :
DisplayPhoto                                : AllPhotos
EnableAppearOffline                         :
EnableCallLogAutoArchiving                  :
EnableClientMusicOnHold                     : False
EnableConversationWindowTabs                :
EnableEnterpriseCustomizedHelp              :
EnableEventLogging                          :
EnableExchangeContactSync                   : True
EnableExchangeDelegateSync                  :
EnableFullScreenVideo                       :
EnableHighPerformanceConferencingAppSharing : False
EnableHotdesking                            :
EnableIMAutoArchiving                       :
EnableMediaRedirection                      :
EnableNotificationForNewSubscribers         :
EnableSQMData                               :
EnableTracing                               :
EnableURL                                   :
EnableUnencryptedFileTransfer               :
EnableVOIPCallDefault                       : False
ExcludedContactFolders                      :
HotdeskingTimeout                           : 00:05:00
IMWarning                                   :
MAPIPollInterval                            :
MaximumDGsAllowedInContactList              : 10
MaximumNumberOfContacts                     :
MaxPhotoSizeKB                              : 30
MusicOnHoldAudioFile                        :
P2PAppSharingEncryption                     : Supported
EnableHighPerformanceP2PAppSharing          : False
PlayAbbreviatedDialTone                     :
SearchPrefixFlags                           :
ShowRecentContacts                          : True
ShowManagePrivacyRelationships              : False
ShowSharepointPhotoEditLink                 : False
SPSearchInternalURL                         :
SPSearchExternalURL                         :
SPSearchCenterInternalURL                   :
SPSearchCenterExternalURL                   :
TabURL                                      :
TracingLevel                                : Light
WebServicePollInterval                      :
HelpEnvironment                             :

Ahora nos quedaría establecer los valores que queramos sobre dicha directiva:

Set-CsClientPolicy -Identity "Site:Asir Lync" -EnableClientMusicOnHold $TrueIdentity

Por último, si queremos crear una directiva para asignar de forma individual a cada usuario los pasos a seguir para crear, configurar y asignar una directiva son los siguientes:

New-CsClientPolicy -Identity DirectivaDemo

Set-CsClientPolicy -Identity DirectivaDemo -DisableEmoticons $True  -IMWarning "Alerta de Seguridad"

Grant-CsClientPolicy -Identity Lync1 -PolicyName DirectivaDemo

Ahora si queremos listar las directivas existentes en nuestra topología utilizaremos el siguiente cmdlet:

Get-CsClientPolicy | fl Identity

Políticas de Cliente_Lync_2013_Global_Site_User_3.jpg

Si queremos conocer los valores configurados en cada una de las directivas tendremos que hacerlo con el cmdlet: Get-CsClientPolicy

  • Directiva Global: Get-CsClientPolicy -Identity  Global
  • Directiva de Sitio: Get-CsClientPolicy -Identity "Site:Asir Lync"
  • Directiva de Usuario: Get-CsClientPolicy -Identity  ASIR

Si queremos saber que directiva de cliente tiene asignada el usuario utilizaremos el siguiente cmdlet: Get-CsUser -Identity <Usuario> | fl ClientPolicy

Get-CsUser -Identity sbuitrago | fl ClientPolicy

Políticas de Cliente_Lync_2013_Global_Site_User_2.jpg
Si quisiéramos ver todas las directivas asignadas a un usuario tendríamos el siguiente cmdlet: Get-CsEffectivePolicy -Identity <Usuario> (Cómo podemos mostrar las directivas asignadas a los usuarios de Lync)

Si por ejemplo queremos aplica una directiva de usuario a todos los usuarios de una OU, podemos hacerlo así:

Get-CsUser -OU "OU=Usuarios,DC=AsirLAB,DC=com" | Grant-CsClientPolicy -PolicyName ASIR

si en la OU ya hubiese algún usuario con la directiva aplicada, nos mostrará un mensaje similar a este:

ADVERTENCIA: El objeto con la identidad "CN=Ana Rial Pérez,OU=Usuarios,DC=AsirLAB,,DC=com" no se ha modificado.

Sí queremos quitar una directiva asignada a un usuario, lo haremos estableciendo a $Null el valor de PolicyName desde el cmdlet Grant-CsClientPolicy

Grant-CsClientPolicy -Identity Lync1 -PolicyName $Null

Ahora la pregunta del millón, ¿Qué ocurre cuando el usuario no tiene ninguna directiva de usuario asignada? Pues que al usuario se le aplica la directiva Global y de Sitio si existe, del tal forma que tendremos siempre alguna directiva aplicada a los usuarios. Está claro que si una vez que le hemos quitado la directiva asignada no veremos la directiva Global como directiva asignada: Get-CsUser -Identity Lync1 | fl ClientPolicy

Políticas de Cliente_Lync_2013_Global_Site_User_4.jpg

Las directivas se aplican de arriba abajo: GlobalSitio Usuario, por lo tendrá preferencia la directiva de Usuario (si existe) y prevalecerá sobre el resto (Global y Sitio). Luego recordaros que la directiva de Global no se puede borrar, solo editar y la creación de directivas de Sitio se realiza igual que las de usuario solo que no se asignan, simplemente una vez creadas se aplica a los usuarios del sitio en cuestión.

Espero que os sea de utilidad!!!