Microsoft Lync Server
Header

​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!!!

Si queremos ver las políticas que tenemos asignadas a un usuario(s)​ de forma sencilla, tenemos el siguiente cmdlet: Get-CsEffectivePolicy -Identity <Usuario>

Get-CsEffectivePolicy -Identity arial

Mostrar_las_directivas_asignadas_a_un_usuario_2.JPG

Si queremos mostrar más las políticas aplicadas a los usuarios que están en una OU, podemos hacerlo de la siguiente forma: Get-CsUser -OU "OU=Usuarios,DC=AsirLAB,DC=com" | Get-CsEffectivePolicy

Mostrar_las_directivas_asignadas_a_un_usuario_1.JPG

Este cmdlet es súper útil para saber que políticas tiene un usuario, de forma rápida sabremos que configuraciones tenemos aplicadas. Sino tiene ninguna directiva personalizada, veremos las directivas Globales o de Sitio.

Espero que os sea de utilidad!!!

Es posible que se os de la circunstancia de que queráis deshabilitar el acceso anónimo a una conferencia cuando se accede vía Lync Web App, evitando así que los usuarios se sin credenciales en Lync (nuestro o federado) pueda conectarse a una conferencia. Si accedemos a una conferencia a través del Lync Web App nos encontramos con esto:
 
Deshabilitar_Usuarios_Anónimos_Lync_Web_App_2.png

De tal forma que los usuarios escriben un nombre que los identificará y se conectarán a la conferencia, si queremos evitarlo tenemos el siguiente cmdlet:

Set-CsWebServiceConfiguration -AllowAnonymousAccessToLWAConference $False

Si queremos ver el cambio  aplicado podemos ver la configuración con este otro cmdlet:

Get-CsWebServiceConfiguration

Deshabilitar_Usuarios_Anónimos_Lync_Web_App_4.png

Si ahora volvemos a conectarnos a la conferencía vía Lync Web App solo tendremos la posibilidad de reunirnos a la misma autenticándonos previamente

Deshabilitar_Usuarios_Anónimos_Lync_Web_App_1.png

Espero que os sea de utilidad!!!

​En los escenarios anteriores (Esquemas de red para nuestras implementaciones de Lync Server (Parte I) y Esquemas de red para nuestras implementaciones de Lync Server (Parte II)) siempre hemos tenido que cambiar la configuración del EDGE, ajustando los puertos de los distintos servicios a publicar. Ahora nos encontramos con un escenario ideal para empresas pequeñas que quieren implementar Lync, no tener problemas de conectividad desde las redes externas y disponer de todas las funcionalidades del producto. De ahí que contemos con una conexión de datos que tiene 4 direcciones IP Públicas, las cuales configuraremos en nuestro router/firewall para realizar las distintas publicaciones (Pulsar en la imagen para verla a tamaño real).

Topologías Lync 2013_Esquema_3.jpg

Seguimos con el mismo escenario que los anteriores en cuanto a las subredes, una subred 192.168.0.0/24 para la LAN1 (red local) y una subred 172.26.0.0/28 (la hemos amplicado de 6 a 14 hosts) para las interfaces externas del Reverse-Proxy y EDGE. Como ahora con 4 IP Públicas tenemos la posibilidad de publicar cada servicio del EDGE en su puerto nativo, configuraremos el EDGE con nombres e IP diferentes para cada servicio. De ahí que tengamos que ampliar la subred que estábamos utilizando hasta la fecha, de un /28 a /29. Si bien es cierto que con la /28 no  tendríamos problemas, nos daremos algunas IPs más para otros servicios que queramos implementar en esa subred (publicar un RDS, Servidor SSTP, etc..). Sí no queremos publicar más que los serviciores del Reverse-Proxy y EDGE, entonces dejaremos la subred en /28, porque tendremos más que suficiente: 1 IP para el Router, 1 IP para el Reverse-Proxy 3 IPs para el EDGE y aún así nos sobraría una. Comentado esto, la configuración del EDGE en las interfaces externas ahora podría quedar de la siguiente forma:

En nuestro caso como hemos implementado NAT también para esta subred,  lo que haremos será configurar el EDGE con estas direcciones IP, tanto para la interface interna (192.168.0.16) como para las interfaces externas (172.26.0.3, 172.26.0.4, 172.26.0.5)  y como estamos detrás de NAT le indicaremos la IP Pública que configuraremos para los perimetrales de A/V (213.213.213.5)

Topologías Lync 2013_Esquema_3_1.jpg

Como ahora disponemos de 3 IP Públicas para los servicios del EDGE, configuraremos los puertos estándar para cada servicio (443, 5061 y 5269), de esta forma evitaremos en redes externas el bloqueo de la conexión, el puerto 443 se suele permitir en el 99% de las redes

Topologías Lync 2013_Esquema_3_2.jpg

A nivel de configuración de router, lo que nos queda es redireccionar los puertos hacia el EDGE en base a la configuración que hemos publicado en Lync:

Topologías Lync 2013_Esquema_3_3.jpg

El resto de configuraciones que había comentado en el primer artículo se mantienen, puesto que tenemos un solo router y tenemos que poder realizar todas las configuraciones con el. Básicamente crear dos subredes, una para los equipos de la LAN y otra para las interfaces externas del Reverse-Proxy y EDGE, crear un filtrado en el router para que no se puedan comunicar entre ellas y crear de alguna forma una "DMZ" para la subred 172.26.0.0/28 de los servicios que vamos a publicar.  Como en este caso además tenemos cuatro IP Públicas, tenemos lo necesario para poder configurar de forma estándar nuestra topología, como diferencia a mayores de la configuración de los puertos debemos configurar varios registros DNS:

Topologías Lync 2013_Esquema_3_4.jpg

Como el EDGE tiene la interface interna en la misma subred que los equipos y servidores (192.168.0.0./24), no tendremos que realizar más configuración en el EDGE. Este tercer esquema es el más común, porque al final los clientes suelen solicitar a su ISP varias direcciones IP Públicas para configurar Lync con todos los servicios vía puertos estándar. La red prácticamente no se tiene que modificar y únicamente como siempre crear una subred IP a mayores y configurar NAT sobre ella sino se dispone otro router o hardware específico para configurar VLAN o DMZ. Si tuvíeramos un segundo router, aunque no fuese un modelo profesional, podríamos conectar las interfaces públicas del Reverse-Proxy y EDGE al switch integrado que todos traen y ahí configurar la subred 172.26.0.0/28 (o la que queráis), de tal forma que así si la tendríamos separada de la red local ya a nivel físico. En estos esquemas trato de buscar alternativas con lo que puede tener el cliente, pero está claro que todo se puede mejorar o configurar de otra forma si se tiene una partida económica para el proyecto. Pero igualmente, podemos conseguir el mismo servicio adaptando la infraestructura IT a lo que tenemos.

Espero que os sea de utilidad!!!