Microsoft Lync Server
Header

Federación Lync – Skype: Opciones disponibles para el usuario final

septiembre 4th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Aquí os dejo un pequeño resumen de lo que tenemos disponible con la federación de Lync y Skype

Funciones de Usuario Final en Lync.jpg
Os dejo aquí los enlaces a otros de mis artículos referentes a la federación Lync – Skype
Espero que os sea de utilidad!!!

¿Qué es Lync Online?

septiembre 4th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Excelente vídeo de Microsoft para mostrarnos en cuestión de 1 min el beneficio de una herramienta como Lync Online

Lync Server: InstallDatabaseInternalFailure: Error interno al intentar crear o actualizar la base de datos

septiembre 3rd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

​Quiero comentaros uno de los problemas que me he encontrado ahora mismo cuando he querido publicar una topología de Lync Server 2013: InstallDatabaseInternalFailure: Error interno al intentar crear o actualizar la base de datosError_Publicación_Lync_NtAccountTypeUnknown_1.png

El problema viene dado cuando he querido publicar la topología, hasta la fecha no había tenido problema alguno con el dominio. Para poneros en situación, os comento que toda la plataforma de MV había sido implementada por un proveedor de IaaS, por lo que yo debería configurar el dominio, TMG y Lync Sever 2013. Estos son los servidores de los cuales dispongo:

  • 1 Controlador de Dominio
  • 1 Servidor de Office Web App
  • 1 Front-END de Lync Server 2013
  • 1 EDGE de Lync Server 2013
  • 1 TMG 2010 SP2 como Reverse-Proxy
Lo primero que se ha hecho es actualizar todas las máquinas con las últimas actualizaciones disponibles (sobre 350MB por servidor), posteriormente e ha configurado el dominio y unido las máquinas al dominio. Ahora se ha configurado un CA, los pre-requisitos del servidor de WAC, Front-END de Lync y EDGE de Lync. Una vez todo configurado (incluso el TMG), empiezo a notar algún comportamiento extraño entre dos servidores a los cuales no puedo acceder a través del EDGE porque no me validaba las claves de usuario (TMG y Front-END), sin embargo si me conecto al controlador de dominio desde ahí si puedo hacerlo. Pensando que inicialmente puede ser otra cosa, continuo con la instalación de Lync, BBDD, etc… y cuando termino de configurar la topología y trato de publicarla me encuentro con el problema que os muestro en la captura anterior. Claramente lo primero que hago es revisar los siguiente:
  • Que haya iniciado con un usuario con los derechos administrativos necesarios (los tenía, pero nunca está de mas asegurarse)
  • Los permisos sobre la carpeta CsData
  • Que el servidor tenga espacio disponible en la partición de Sistema
Y claro, aparentemente estaba todo correcto, pero revisando más en detalle el log del error mostrado me encuentro con esto:
Error_Publicación_Lync_NtAccountTypeUnknown_2.png

Como vemos no se reconoce la cuenta de inicio de sesión, por lo que estas cosas siempre suelen ir ligadas a duplicidad de SID (Identificador de Seguridad) y como todos sabemos no pueden existir dos máquinas con el mismo SID en nuestro dominio. Aquí os dejo un artículo muy interesante para los que no conozcáis lo que es el SID y los problemas de la duplicidad de SID: http://bit.ly/14lYgRz

Teniendo en mente que el problema podría venir por una duplicidad de SID, me he descargado las  Download PsTools (1.60 MB), en donde tenemos la utilidad PSGetSID la cual nos permite visualizar de forma sencilla el SID de cada equipo unido al dominio o no. Si queremos que nos muestra el SID de la máquina sobre la cual ejecutamos la herramienta, únicamente debemos ejecutarla desde una línea de comandos sin modificador alguno, pero si queremos encontrar el SID de una máquina de forma remota de debemos ejecutar el psgetsid.exe con el siguiente modficador:

Y aquí tenemos todos los modificadores posibles para PSGetSID
Usage: psgetsid [\\computer[,computer[,…] | @file] [-u username [-p password]]] [account|SID]
-u Specifies optional user name for login to remote computer.
-p Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.
Account PsGetSid will report the SID for the specified user account rather than the computer.
SID PsGetSid will report the account for the specified SID.
Computer Direct PsGetSid to perform the command on the remote computer or computers specified. If you omit the computer name PsGetSid runs the command on the local system, and if you specify a wildcard (\\*), PsGetSid runs the command on all computers in the current domain.
@file
PsGetSid will execute the command on each of the computers listed in the file

Una vez ejecutado en todos los servidores, me encuentro una desagradable sorpresa por un lado y por otro la causa del problema:

SID for \\SRV-LYNC00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-fw00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-dc00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-wac00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\EDGE:
S-1-5-21-639020047-2635447608-3603641496

Ahora bien, como se soluciona esto, puesto ejecuntado un SYSPREP (¿Qué es Sysprep?) a cada servidor, pero sin tocar el DC para que no tenga que reconstruir el dominio de nuevo. Simplemente dejar al DC con ese SID y el resto lo volverán a generar de forma aleatoría. Debemos borrar las cuentas de los servidore unidos al dominio, para que cuando los volvamos a crear tengamos la seguridad de que se asigna con el nuevo SID. Esto ocurre cuando se clona una máquina base para acelerar el proceso de despliegue de entornos virtualizados, pero también se podía hacer en su tiempo con las máquinas fisicas con Norton Ghost, Acronis. No es que ahora no se puede hacer, pero ya es menos común. En este caso mi proveedor se le ha olvidado aplicar un SYSPREP y la verdad me ha fastitiado un poco, porque ha tirado a la basura algunas horas de mi trabajo.

La idea era comentar el problema de publicación de Lync y las causas, aunque finalmente he tenido que comentar otras cosas

Espero que os sea de utilidad!!!

Lync Server: habilitar en Lync a los usuarios de una Unidad Organizativa o Departamento

septiembre 2nd, 2013 | Posted by Santiago Buitrago in Sin categoría - (0 Comments)

En muchas ocasiones tenemos la necesidad de habilitar en Lync todos los usuarios de una Unidad Organizativa de nuestro Directorio Activo, y además queremos automatizar dicho proceso. Esto podemos hacerlo de forma sencilla mediante PowerShell, primero debemos conocer el DN de la OU en la cual tenemos los usuarios que queremos habilitar en Lync. Para ello podemos hacerlo de varias formas, desde la consola de Usuarios y Equipos de Active Directory vamos al menu Ver y habilitamos la opción Características avanzadas

Habilitar_Usuarios_Lync_OU_2.png
Ahora pulsamos con el botón secundario del ratón encima de la OU en cuestión y vamos  propiedades, ahora nos vamos a la ficha Editor de atributos, buscamos el atributo distinguishedName y pulsamos en ver y nos mostrará el valor del DN que necesitaremos posteriormente, por lo que copiaremos el valor mostrado:
 
OU=Usuarios,OU=AsirLAB,DC=dominio,DC=com
Habilitar_Usuarios_Lync_OU_3.png 
Ahora que ya tenemos el DN, lo que debemos hacer es ejecutar el siguiente script de PowerShell en alguno de los servidores de Lync:
 
Get-CsAdUser -filter {Enabled -ne $True} -OU “DN_OU” | Enable-CsUser -RegistrarPool <fqdn_front-end_o_pool>-SipAddressType Emailaddress
 
Ejemplo:
 
Get-CsAdUser -filter {Enabled -ne $True} -OU “OU=Usuarios,OU=AsirLAB,DC=dominio,DC=com” | Enable-CsUser -RegistrarPool <fqdn_front-end_o_pool>-SipAddressType Emailaddress
Este script habilitará en Lync a todos los usuarios de la OU Usuarios dentro de la OU AsirLAB del dominio dominio.com, su dirección SIP se creará en base a su dirección de correo electrónico y no lo intentará con los usuarios que ya están habilitados en Lync (-filter {Enabled -ne $True}).
 
Podemos utilizar distintos filtros en función de nuestras necesidades, para ello podemos utilizar los siguientes modificadores:
 
SINTAXIS
    Get-CsAdUser [-Identity <UserIdParameter>] [-Credential <PSCredential>] [-DomainController <Fqdn>] [-Filter <String>] [-LDAPFilter <String>] [-OU    <OUIdParameter>] [-ResultSize <Unlimited>] [<CommonParameters>]
 
Ejemplo: Habilitar usuarios del departamento de Sistemas que no estén habilitados en Lync
 
Get-CsAdUser -LdapFilter "Department=Sistemas" -filter {Enabled -ne $True} | Enable-CsUser -RegistrarPool <fqdn_front-end_o_pool>-SipAddressType Emailaddress
 
Por último podemos listar los usuarios de nuestro AD que no ha sido habilitado en Lync en nuestro Active Directory, para ello tenemos el siguiente cmdlet:
 
Get-CsAdUser -Filter {Enabled -ne $True} | Select-Object DisplayName
 
Como todo ahora es cuestión de que configuréis vuestro propio script en función de vuestras necesidades.
 
Espero que osea de utilidad!!!

Lync Server: Modificar el tiempo de validez de un certificado de usuario

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

Hace ya algún tiempo, había publicado un artículo que me había parecido muy interesante sobre la diferencia entre deshabilitar un usuario en el Directorio Activo y no en Lync: Deshabilitar un usuario en el Directorio Activo y en Lync

Aqui os dejo el texto incial del artículo para que veáis de que se trata: 

​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. 
 
Caducidad_certificados_1.png
 
Pues ahora vamos a ver como podemos manejar el tiempo de expiración de un certificado de usuario emitido por nuestro servidor de Lync. Por defecto, como os había comentado los certificados tienen una fecha de expiración de 6 meses, esto en algunos casos puede ser excesivo, por lo que debemos poder manejar estas ventanas temporales de alguna forma.  Y por supuesto que podemos hacerlo, para ello tenemos el siguiente cmdlet para establecer el tiempo máximo de duración de un certificado de usuario:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours
 
Pues si queremos que en vez de 6 meses, los certificados caduquen a los 90 días el valor de DefaultValidityPeriodHours deberá ser de 2160:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours 2160
 
A partir de este momento, todos los usuarios que inicien sesión en Lync recibirán un certificado de usuario por parte del servidor con una duración máxima antes de caducar de 90 días. Pero claro, que ocurrirá con los usuarios que un día antes de este cambio ya se las había emitido el certificado, pues que seguirán utilizando este certificado hasta que caduque. Y claramente, esto no es lo que queremos, para ello lo que podemos hacer es revocar todos los certificados de usuarios, y la próxima vez que los usuarios inicien sesión ya tendrán el nuevo certificado con una caducidad de 90 días. Para ello tenemos el siguiente cmdlet que revocará todos los certificados asignados a los usuarios:
 
Get-CsClientCertificate | Revoke-CsClientCertificate
 
También podemos establecer el valor mínimo y máximo de validez de un certificado pero con las siguientes limitaciones:
  • Mínimo –> 1 Hora
 Caducidad_certificados_2.png
  • Máximo –> 8760 Horas (1 año)
 Caducidad_certificados_3.png

Para establecer estos valores, debemos utilizar los siguientes cmdlets:
 
Set-CsWebServiceConfiguration –MinValidityPeriodHours 1

 

Set-CsWebServiceConfiguration –MaxValidityPeriodHours 2880
 
Así que ya sabéis, que si necesitáis cambiar la fecha de caducidad de vuestros certificados de usuario, dos comandos y todo arreglado.
 
Espero que os sea de utilidad!!!