Microsoft Lync Server
Header

En varias ocasiones me he encontrado este problema en la recta final de la implementación inicial de Lync, concretamente al Configurar los componentes de Lync Server

Error_lync_componentes_Server_1.png 
Esto viene dado por falta de espacio en la partición de sistema, en el servidor en el cual me muestra el error tengo una partición para el Sistema Operativo con 50GB pero con 15,9GB libres.
Error_lync_componentes_Server_2.png
 
Como esta máquina había sido provisionada por un tercero (sin seguir mis recomenaciones), lo he hecho para poder continuar con la instalación es borrar temporales, la ISO de Lync y todo lo que he podido. Ahora de 15,9GB libres tengo 18,4GB libres.
Error_lync_componentes_Server_3.png
 
Vuelto a lanzar el proceso de Instalar o desintalar componentes de Lync Server para poder completar la instalación
Error_lync_componentes_Server_4.png
 
y según va transcurriendo la instalación, voy viendo (con temor a que no me llegue el espacio antes de que el proveedor me lo pueda ampliar) como va el consumo de espacio en disco y aquí está la evolución durante los 5 minutos que ha durado el proceso:
Error_lync_componentes_Server_5.png
Y ahora os detallo el espacio ocupado por cada subcarpeta de CsData (ubicación por defecto: %systemdrive%\CsData)
​Carpeta ​BBDD y Logs ​Tamaño Total
​ABSStore rtcab ​256MB
ApplicationStore​ cpsdyn, rgsconfig, rgsdyn 144MB​
​BackendStore ​rtcshared, rtcxds ​8,06GB
​CentralMgmtStore ​lis, xds ​32MB
​LyssStore ​lyss ​384MB
​RrtDatabaseStore ​rtc, rtcdyn ​5,85GB
 
Fijaros en el tamaño fina de la carpeta CsData, 14,7GB que nos dejaban sin espacio para continuar con la instalación.
Error_lync_componentes_Server_8.png
Al poder eliminar casi 3GB de espacio en disco he podido completar la instalación
Error_lync_componentes_Server_6.png
y los 3GB recuperados son con los que me he quedado de espacio libre en el disco
Error_lync_componentes_Server_7.png
De ahí siempre la importancia de que tengamos claros desde el inicio los requisitos mínimos para cada servidor en cuanto a:
  • Sistema Operativo
  • RAM
  • Tarjetas de Red
  • Almacenamiento
  • Nivel de RAID del almacenamiento
  • Certificados
  • etc…
 
Esto es algo que debemos tener  muy en cuenta antes de iniciar la implementación, en este caso este es un proyecto piloto y no tengo problemas "serios". Ahora le enviado la solicitud correspondiente para que se revisen los datos que se le habían enviado y poco más. Pero si esto os ocurre en producción, un viernes a última hora (para que todo esté listo el lunes) y vosotros no podéis ampliar el disco … el proyecto se para.
 
Como veis lo que  inicialmente parecía un problema del SQL Server, de permisos, de rutas, etc.. pues algo más simple que todo esto. Además, como no habíamos llegado el límite de espacio en disco tampoco el servidor nos ha alertado de ello.
 
Espero que os sea de utilidad, y no para resolver este error sino para evitarlo!!!

Aquí os dejo tres enlaces para que podáis descargaros varios VHD para que podáis probar  Lync, SharePoint y Lync 2013:

This download enables you to fully evaluate the Microsoft Lync 2013, Microsoft Exchange 2013, SharePoint 2013, and UC developer platform APIs including the Microsoft Lync 2013 SDK, the Exchange Web Services Managed API 2.0 as well as the Microsoft Lync Server 2013 SDK and the Microsoft Unified Communications Managed API 4.0. Also, Lync Server
 
Test Drive – Lync Server 2013 – Part 1 of 3
http://www.microsoft.com/en-us/download/details.aspx?id=40266 
 
Test Drive – Lync Server 2013 – Part 2 of 3
http://www.microsoft.com/en-us/download/details.aspx?id=40267
 
Test Drive – Lync Server 2013 – Part 3 of 3
http://www.microsoft.com/en-us/download/details.aspx?id=40265

Espero que os sea de utilidad!!!

Una de la novedades que presentaba Windows Server 2012, era la posibilidad de forzar la actualización de las directivas de grupo de forma remota a equipos nivel de OU. De esta forma nos evitamos el tener que ejecutar de forma manual el comando gpupdate o gpupdate /force  en cada equipo  o tener que reiniciarlo. Esto desde luego ayuda mucho a forzar que se apliquen las directivas casi de forma immediata, pero también nos podemos encontrar con el siguiente problema

Actualizacion_GPO_Remoto_1.png
Esto ocurre porque tenemos alguna configuración por defecto en el firewall de los equipos, o bien la hemos modificado pero no nos hemos dado cuenta de que necesitamos tener abiertos ciertos puertos para que podamos forzar la ejecución del gpupdate de forma remota desde las consola de Administración de directivas de Grupo. Para solucionar este problema, debemos crear una nueva directiva, pero debemos seleccionar como GPO de incio de origen la plantilla Puertos de firewall de actualización remota de directiva de grupo:
Actualizacion_GPO_Remoto_6.png
La configuración esta plantilla es la siguiente, de ahí que ya no tenemos que hacer nada más sobre la directiva (únicamente asignarla)
Actualizacion_GPO_Remoto_7.png
Si queremos crear esta directiva vía PowerShell aquí tenéis el cmdlet: New-GPO –Name «Configurar Firewall Actualizacion Remota GPO» –StarterGpoName «Group Policy Reporting Firewall Ports»
Ahora que ya hemos creado nuestra GPO y asignado a la OU correspondiente, debemos esperar a que se aplique en segundo plano cada 90 minutos o en intervalos de 30. Sino deseamos esperar, pues iniciamos sesión en cada equipo y ejecutamos gpupdate. Una vez que la directiva se haya aplicado, volvemos a intentar aactualizar la directiva de grupo a la OU deseada y veremos como los equipos ya no aparecen con errores en la siguiente ventana:
Actualizacion_GPO_Remoto_2.png
Si bien es cierto que en función de que se vaya aplicando la directiva de Firewall configurada para permitir la actualización remota de las directivas, vamos viendo como los equipos que aún seguíamos sin poder actualizar de forma remota ya es posible hasta que por fin se complete sin errores:
Actualizacion_GPO_Remoto_3.png
Como podemos apreciar, es muy sencillo solucionar el problema inicial.  Aquí os dejo la URL de Microsoft por si queréis ampliar más información: http://technet.microsoft.com/es-es/library/jj572986.aspx
Espero que os sea de utilidad!!!

Aquí os dejo un pequeño vídeo en donde se muestran las conexiones que origina un cliente Lync 2013 utilizando los distintos servicios disponibles:

  • Inicio de Sesión
  • Sesiones de A/V
    • Llamadas de Audio
    • Videoconferencias
  • Conferencia Web
  • Compartir Pantalla
  • Transferencia de Ficheros​
  • Cierre de Sesión

Espero que os sea de utilidad!!!

​Seguramente muchos de vosotros hayáis instalado en algún momento una Entidad Certificadora en Windows (Windows Server 2012, Instalación de una CA), y si sois administradores de Lync seguro que lo habréis hecho en cada implementación.​ Pero no solo para Lync, sino para una red con autenticación 802.1x (NPS: Autenticación 802.1X Red Cableada, NPS: Autenticación 802.1x para nuestra red inalámbrica), VPN vía SSTP (Windows Server 2012, Configuración VPN con SSTP), VPN entre dispositivos de Seguridad (Cisco VPN IPSec Site-to-Site con Certificados Digitales), inicios de sesión mediante tarjetas inteligentes y otros muchos usos. En alguna ocasión hemos querido ampliar la vigencia de un certificado, aunque no sea una excelente práctica de seguridad, pero en ocasiones necesitamos que un certificado tenga una vigencia superior a 2 años.

Lo primero que pensamos es en duplicar alguna de las plantillas que queremos emitir, y configurar la caducidad en función de nuestras necesidades. Una vez configurada la nueva plantilla, debemos emitirla para que esté disponible para que podamos solicitar el certificado en cuestión. Pero el problema es que cuando creyendo que ya tenemos nuestro certificado emitido para 5 años, como podemos apreciar en las siguiente imagen vemos que el certificado realmente tiene dos años de vigencia
Caducidad_Superior_2_Anos_1.png
Debemos tener en cuenta que un certificado debe tener una vigencia menor en función de:
  • Tiempo de vida restante del certificado raíz de la CA
  • Período de validez inferior establecido en la plantilla
  • El valor especificado en el registro de nueva CA
Hay cosas que caen por su propio peso, como son las dos primeras opciones, pero en muchas ocasiones desconocemos el valor en años que tiene por defecto para todos los certificados emitidos por la CA. Si queremos ver el valor de registro en donde nos muestra el número de años de validez de un certificado, tenemos el siguiente comando:
certutil -getreg ca\ValidityPeriodUnits
Caducidad_Superior_2_Anos_2.png
 Si ahora queremos cambiar este valor 2 a más años, debemos ejecutar el siguiente comando:
certutil -setreg ca\ValidityPeriodUnits 5
Caducidad_Superior_2_Anos_3.png
Para que estos cambios se hagan efectivos debemos reiniciar el servicio CertSvc, y posteriormente podemos emitir un certificado con la plantilla la cual hemos modificado la vigencia del mismo y ya obtendríamos un certificado con la duración especificada en la plantilla. Claramente, siempre y cuando el valor del registro que hemos establecido sea igual o superior al especificado en la plantilla del certificado, porque si el valor de la plantilla es de 6 años el certificado se crearía con 5 años (en función de nuestro ejemplo). Esto es por lo comentado antes, la vigencia del certificado siempre debe ser menor que alguna de las opciones comentadas anteriormente.
Caducidad_Superior_2_Anos_4.png
Como vemos el poder tener certificados con una vegencia superior a 2 años es bastante sencillo, creamos una plantilla con la vigencia deseada teniendo en cuenta que debemos tener el certificado raiz y el registro con valores de vigencia superiores a la plantilla.
Espero que os sea de utilidad!!!