Microsoft Lync Server
Header

​Con Windows Server 2012 R2 (y versiones anteriores) podemos crear ficheros VHDX y asignárselos como discos locales a distintos servidores (físicos o virtuales), simulando el comportamiento de una SAN. Esto nos permite tener un servidor con almacenamiento local (o no) y compartirlo mediante nuestra red de datos vía iSCSI. De esta forma podemos tener un servidor económico con almacenamiento SAS o SATA directamente conectado y presentárselo a los distintos servidores (Físicos o Virtuales) vía red con iSCSI para que puedan utilizarlos como discos duros directamente conectados. Como sabéis servicios como SQL Server o Exchange Server necesitan tener almacenamiento directamente conectado (no unidades de red) para poder almacenar sus BBDD. De esta forma y a través de nuestra red (1GBit o 10GBit) podemos asignar discos duros virtuales (VHDX) a los distintos servidores, de tal forma que para los servidores los discos duros presentados son disco locales. Esto podemos configurarlo mediante el Tarjet iSCSI  y vamos a ver como podemos configurarlo con Windows Server 2012 R2. Lo primero que debemos hacer es agregar el rol Servidor del destino iSCSI (iSCSI Tarjet), para ello vamos a agregar este rol:

Windows_Server_2012_R2_iSCSI_1.png

Windows_Server_2012_R2_iSCSI_2.png
Windows_Server_2012_R2_iSCSI_3.png
Ahora debemos elegir la opción Servidor del destino iSCSI bajo el rol de Servicios de archivos y almacenamiento – Servicios de iSCSI y archivo y pulsamos en siguiente
Windows_Server_2012_R2_iSCSI_4.png
pulsamos en siguiente
Windows_Server_2012_R2_iSCSI_5.png
nos muestra un resumen del rol y/o características que vamos a instalar y si está todo correcto, pulsamos en instalar
Windows_Server_2012_R2_iSCSI_6.png
Windows_Server_2012_R2_iSCSI_7.png
Una vez que se haya instalado el rol Servidor del destino iSCSI , abrimos la consola Administrador del Servidor, vamos a las opciones de Servicios de archivos y de almacenamiento y luego pulsamos en iSCSI desde donde podemos empezar a configurar nuestros discos virtuales iSCSI. Lo primero que debemos hacer es crear un VDHX que utilizaremos para asignárselo a algún servidor, para ello pulsamos en Para crear un disco virtual iSCSI, inicie el Asistente para nuevo disco virtual iSCSI
Windows_Server_2012_R2_iSCSI_8.png
 
Se incia un asistente en donde podemos ir configurando las siguientes opciones disponibles, lo primero que nos solicitará será en donde se crearán los disco virtuales y bien podemos asignarlo a un volumen de nuestro servidor o a un ubicación en concreto. Yo tengo una carpeta creada para almacenar allí los VHDX, aquí es donde físicamente se almacenarán los VHDX que vamos a asignar al resto de servidor via iSCSI.
Windows_Server_2012_R2_iSCSI_9.png
Debemos escribir el nombre que tendrá el fichero VHDX y si queremos podemos describir su utilización en la casilla Descripción y pulsamos en Siguiente
Windows_Server_2012_R2_iSCSI_10.png
Elegimos el tipo de disco a crear y su tamaño (en Windows Server 2012 R2 un máximo de 64TB), yo he elegido que se vaya expandiendo dinámicamente (no recomendado en algunos escenarios porque no tiene un alto rendimiento) para no utilizar el espacio disponible en mis volúmenes locales, si hemos configurado el tipo de disco y su tamaño pulsamos en siguiente
Windows_Server_2012_R2_iSCSI_11.png
 
Ahora debemos especificar el servidor al cual le vamos a asignar este disco virtual, y como es la primera vez que estamos configurando un disco virtual solo tenemos habilitada la opción Nuevo destino iSCSI
Windows_Server_2012_R2_iSCSI_12.png
 
Debemos especificar un nombre para poder identificarlo de forma sencilla y pulsamos en siguiente
Windows_Server_2012_R2_iSCSI_13.png
 
pulsamos en Agregar
Windows_Server_2012_R2_iSCSI_14.png
podemos agregar escribiendo su IQN o podemos busarlo por el nombre del equipo (en este caso tendría que ser un equipo que está unido al dominio) para ello pulsamos en Examinar
Windows_Server_2012_R2_iSCSI_15.png
 
Escribiemos el nombre de equipo y lo seleccionamos

Windows_Server_2012_R2_iSCSI_16.png

pulsamos en agregar

Windows_Server_2012_R2_iSCSI_17.png
 
ahora que ya tenemos configurado nuestro servidores de acceso, pulsamos en Siguiente
Windows_Server_2012_R2_iSCSI_18.png
 
Podemos configurar varios tipos de autenticación si queremos que los servidores conectados al disco virtual se tengan que autenticar previamente, pulsamos en siguiente
Windows_Server_2012_R2_iSCSI_19.png
Por último nos muestra un resumen de nuestra configuración y si está todo correcto pulsamos en crear
Windows_Server_2012_R2_iSCSI_20.png
Espermos unos segundos hasta que se complete la configuración y pulsamos en cerrar
Windows_Server_2012_R2_iSCSI_24.png
 
Con esto ya tenemos nuestro primer disco virtual iSCSI creado y asignado, pero ahora debemos ir al sevidor en el cual queremos configurar el iniciador iSCSI para conectarlo a este disco virtual
Windows_Server_2012_R2_iSCSI_25.png
 
Si ahora nos vamos a la carpeta en donde hemos creado el VHDX vemos que tiene apenas 4MB, recordemos que yo habia configurado un disco dinámico y mientras que no lo utilicemos añadiendo información sobre el no crecerá
Windows_Server_2012_R2_iSCSI_26.png
Antes de configurar el servidor en el cual configuraremos el disco virtual, debemos crear una excepción en el firewall local del servidor que hemos configurado, recordar que la comunicación es vía iSCSI y utiliza la red de datos para estar disponible en la red. Ahora abrimos el firewall local y vamos a ver las aplicaciones permitidas y como vemos por defecto no existe excepción para el Servicio iSCSI
Windows_Server_2012_R2_iSCSI_28.png
Habilitaremos la excepción del servicio iSCSI a nivel de dominio, privado o público (en mi caso únicamente a nivel de dominio porque la máquina que se conectará al disco virtual está en el dominio)
Windows_Server_2012_R2_iSCSI_29.png
Pues ahora lo que nos queda es configurar el Iniciador iSCSI en el servidor de destino
Windows_Server_2012_R2_iSCSI_21.png

Sí es la primera vez que lo estáis ejecutando os comentará que debéis iniciarlo y pulsamos en SÍ

Windows_Server_2012_R2_iSCSI_22.png

Lo primero que haremos será ir a la pestaña Detección para conectarnos vía iSCSI con el servidor de iSCSI y pulsamos en Detectar portal …
Windows_Server_2012_R2_iSCSI_30.png
 
Escribimos la dirección IP del servidor y dejamos el puerto por defecto (3260) y pulsamos en Aceptar (lo suyo sería que la red iSCSI tuviese su propia VLAN, direccionamiento IP y red dedicada para una mayor rendimiento)Windows_Server_2012_R2_iSCSI_31.png
 
Si todo va bien, debéis ver algo similar a esto pero con vuestros datos claramente en caso contrario os mostrará un error de que no puede conectar. Ahora para completar la configuración debemos pulsar en Conectar, si os fijaís dentrás tengo el administrador de discos abierto y nos muestra el único disco que tienen conectado que es el de sistema
Windows_Server_2012_R2_iSCSI_33.png
 
Una vez que lo tenemos conectado, podréis observar que en la consola de administración de discos ya nos aparece el nuevo disco virtual el cual le hemos presentado desde el servidor
Windows_Server_2012_R2_iSCSI_35.png

Ahora debemos iniciarlo, crear un nuevo volumen y asignar una letra de unidad para tener acceso al mismo (al igual que se haría con cualquier disco duro conectado al equipo)

Windows_Server_2012_R2_iSCSI_36.pngWindows_Server_2012_R2_iSCSI_37.png

Windows_Server_2012_R2_iSCSI_38.png
Windows_Server_2012_R2_iSCSI_39.png
Windows_Server_2012_R2_iSCSI_40.png
 
Una vez inicializado creamos un nuevo volumen simple …
Windows_Server_2012_R2_iSCSI_41.png
Windows_Server_2012_R2_iSCSI_42.png
Windows_Server_2012_R2_iSCSI_43.png

Asignamos una letra de unidad la cual utilzaremos para acceder al volumen

Windows_Server_2012_R2_iSCSI_44.png

Y debemos formatearlo para tenerlo accesible, elegimos el sistema de archivos que queremos para este volumen, el tamaño de la unidad de asignación (en función de lo que vayamos a almacenar debemos ajustarlo, recoerdad que Exchange y SQL Server escribe en bloques de 64KB), la etiqueta del volumen y si queremos formateo rápido y compresión de archivos y carpetas

Windows_Server_2012_R2_iSCSI_45.png

Como siempre nos muestra un resumen de la tarea y pulsamos en finalizar si estamos de acuerdo con ello

Windows_Server_2012_R2_iSCSI_46.png

En cuestión de segundos tendremos nuestro volumen disponible en la letra que le habiamos asignado

Windows_Server_2012_R2_iSCSI_47.png

y como vemos al sistema se le presenta con el tamaño máximo que le asignamos cuanto lo creamos (10GB), pero si recordáis en el servidor solo ocupada 4MB porque esa un disco de expansión dinámica

Windows_Server_2012_R2_iSCSI_48.png
 
Si ahora volvemos a la consola de administración del servidor en la sección de iSCSI veremos que ya nos aparece el servidor como conectado
Windows_Server_2012_R2_iSCSI_49.png

 

Como podemos ver es muy sencillo y muy práctico, porque nos permite asignar VHDX a distintos servidores desde una máquina central con o sin almacenamiento SAN. Simplemente si el serivdor tiene almacenamiento (da igual como) podemos asignar ese espacio a ficheros VHDX que posteriormente asignaremos a nuestros servidores.

Y por último comentaros algo muy sencillo y que es de uso coticionado, que ocurre si los 10GB que le habíamos asignado al servidor en ese VDHX no es suficiente pasando el tiempo. Esto tiene fácil solución siempre que tengamos espacio suficiente en el servidor de iSCSI para poder seguir almacenando los VHDX. Lo que debemos hacer es ampliar el VHDX y automáticamente el servidor que lo tiene conectado lo podrá ver como espacio disponible para redimensionar el volumen. El como hacerlo es súper sencillo, nos vamos al administrador del servidor, vamos a la sección de almacenamiento y luego la iSCSI y pulsamos con el botón secundario del ratón sobre el disco virtual que queramos ampliar y pulsamos en Expandir disco virtual iSCSI …

Windows_Server_2012_R2_iSCSI_50.png

Ahora nos muestra una nueva ventana para que podamos ver el tamaño actual, el máximo (es el tamaño máximo al que podemos ampliar el VHDX pero por que es el tamaño disponible en este servidor para almacenar el VHDX, por lo que más grande que esto no lo podría hacer sino sabéis que la limitación por VHDX es de 64TB) y por último escribimos el nuevo tamaño que queremos tener en el VHDX
Windows_Server_2012_R2_iSCSI_51.png

Yo le he puesto 20GB y acto seguido la información en pantalla ya está actualizada así que ahora nos quedaría como último paso acceder al servidor que lo tiene conectado y ver que ha ocurrido

Windows_Server_2012_R2_iSCSI_52.png

Abrimos el administrador de discos del servidor que tiene conectado el VDHX vía iSCSI y vemos que tenemos 10GB más de espacio disponible sin asignar
Windows_Server_2012_R2_iSCSI_53.png

Pulsamos con el botón secundario del ratón encima de la partición que queremos expandir (Datos (D:)) y pulsamos en Extender volumen

Windows_Server_2012_R2_iSCSI_54.png

Únicamente debemos seguir el asistente hasta el final y tendremos ampliada la partición a 20GB (sin necesidad de parar la máquina ni desconectar usuarios, etc…)

Windows_Server_2012_R2_iSCSI_55.png

Asignamos el espacio que queramos a la partición en función del tamaño total No asignado, en mi caso me asigando el 100% del total no dispnoible para así tener los 20GB

Windows_Server_2012_R2_iSCSI_56.png

para finalizar la expansión del volumen pulsamos en Finalizar

Windows_Server_2012_R2_iSCSI_57.png

Y ya tenemos los 20GB  disponibles desde el administrador de discos ..

Windows_Server_2012_R2_iSCSI_58.png

Y desde el explorador también podemos observar que el espacio del volumen es de 20GB en total

Windows_Server_2012_R2_iSCSI_59.png

Como podemos apreciar en menos de 15 minutos tenemos un sistema de almacenamiento vía iSCSI en toda nuestra red, aprovechándonos de toda su potencia. Comentaros que antes os había dicho que siempre es recomendable tener una red propia para el tráfico iSCSI y que comprendería las siguientes configuraciones:

  • VLAN para el tráfico iSCSI
  • Direccionamiento IP diferente a la red de datos
  • Jumbo Frames configurado si vuestro hardware lo soporta

Pensad que los usuarios que accediesen a la información almacenada en los discos virtuales no se conectará por la red iSCSI, sino por la tarjeta de red del servidor que está asignada para ello (la por defecto). Por lo que si podemos aislar la red de datos de la red iSCSI sería perfecto, evitando tráfico innecesario  y que podría reducir el rendimiento de la red iSCSI. Y me repito, los clientes que consumirían los datos compartidos en dicho volumen no acceder por la red iSCSI, esa solo se utliza para conectar el servidor iSCSI con el iniciador iSCSI y asignar el disco al servidor de destino.

Ejemplo

Windows_Server_2012_R2_iSCSI_60.png

Y claramente está soportado utilizar el almacenamiento del servidor iSCSI en los Storage Pools

 

Windows_Server_2012_R2_iSCSI_61.png
 
Como resumen la idea es tener un servidor con un alcenamiento  local (Discos directamente conectados o vía SAN (iSCSI o FC)) y compartir ficheros VHDX vía iSCSI a los distintos servidores. Utilizando la red Ethernet para ello con todos los beneficios que esto conlleva, de tal forma que centralicemos el almacenamiento y asignemos nuestros discos virtuales iSCSI a los servidores que lo necesiten via iSCSI. Si ya tenemos una SAN via hardware esta configuración del servidor no las podemos ahorra, pero le presentaríamos LUNs no VDHX y esto si que representa una ventaja.

 

Espero que os sea de utilidad!!!

Seguro que a muchos de vostros esta nueva forma de solicitar los reinicios en Windows 8 y Server 2012 no os habrá hecho mucha gracia,  por lo menos a mí nada de nada. ​Puesto que como sabéis ahora cuando Windows 8 o Windows Server 2012 con actualizaciones importantes nos muestra un aviso durantes tres días (72horas) antes de reiniciarse y cuando se cumple ese tiempo nos muestra otro mensaje indicando que en 15 minutos reiniciará y NO TIENES LA POSIBILIDAD DE HACER "NADA". Como todos sabemos los segundos martes de cada mes, se pueden descargar las actualizaciones  críticas de seguridad, por lo que en tres días más tendríamos un reinicio obligatorio si o si. Esto es una estación de trabajo es un incordio, pero en un servidor es un auténtico problema. Podemos configurar una GPO para evitar que se reinicie el equipo si tiene iniciada sesión algún usuario en el equipo o servidor, para ello debemos en los equipos con Windows 8 Pro o superior editar las directivas de grupo locales (gpedit.msc), o bien desde un controlador de dominio crear una GPO que aplicaremos a los equipos con la siguiente configuración:

Debemos establecer a habilitado la directiva No reiniciar automáticamente con usuarios que hayan iniciado sesión en instalaciones de actualizaciones automáticasReiniciar_al_instalar_las_actualizaciones-2.png

En el caso de que tengamos un sistema operativo NO profesional, podemos hacerlo creando el siguiente valor de registro NoAutoRebootWithLoggedOnUsers en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU y establecer el valor a 1

Reiniciar_al_instalar_las_actualizaciones-3.png

Pero claramente esto no es suficiente y Microsoft ha sacado el 12 de Abril del 2013 una actualización (KB2822241) para Windows 8 y Windows Server 2012 que nos permite configurar una clave de registro (KB2835627) para forzar un reinicio del sistema en cuanto se hayan instalado las actualizaciones críticas. Para ello debemos crear la clave AlwaysAutoRebootAtScheduledTime en la siguiente rama del registro: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU y establecer a 1 el valor de dicha clave. Para que este cambio tenga efecto debemos reiniciar el servidor, y en las siguiente instalación de actualiaciones críticas, el sistema se reinciará automáticamente.

Reiniciar_al_instalar_las_actualizaciones-1.png

Ahora bien, debemos establecer las opciones de actualización (Día y Hora de descarga e instalación) de forma adecuada a nuestras necesidades. Se supone que los servidores deberían o podrían descargarse las actualizaciones durante el día o noche (preferiblemente), pero su instalación siempre en horario no laboral (a ser posible durante el fin de semana). De tal forma, que su instalación y reinicio no tenga repercusiones en el funcionamiento de la red. Pero no olvidemos tampoco, que no debería solaparse con la tareas de backup que tengamos programadas. También es cierto que las actualizaciones críticas de seguridad, deberíamos aplicarlas lo más rápido posible, pero tampoco ser el "conejillo de indias"
 

Espero que os sea de utilidad!!!

Muy buena y esperada actualización para los que utilizamos Lync 2013 con Windows 8.1​, puesto que como sabéis en Windows 8.1 no podemos compartir presentaciones de PowerPoint desde nuestro cliente Lync (Error del cliente Lync 2013 compartiendo una presentación de PowerPoint en Windows 8.1). Esto lo había comentado en varios ocasiones, y con esta actualización Office Web Apps Server 2013 2837634 por fin lo han corregido.

El procedimiento para aplicar esta actualización es muy sencilla, estos son los pasos a dar:

Una vez que tenemos claro los pasos a datos, veamos la parte práctica a continuación.

  • Quitar la granja de Office Web Apps: para ello utilizaremos el siguiente cmdlet: RemoveOfficeWebAppsMachine

Actualizacion_WAC_2013_Nov_2013_1.png

Si queremos verificar que nuestro servidor ya no pertenece a la granja de Office Web App ejecutamos el siguiente cmdlet: Get-OfficeWebAppsFarm y podemos comprobar que ya no forma parte de una granja de Office Web Apps Server
Actualizacion_WAC_2013_Nov_2013_2.png
  • Instalamos la actualización que nos hemos descargado previamente, poco más que aceptar el contrato de licencia de MSFT y pulsar en Continuar (proceso que durará entre 5 y 10 min)

Actualizacion_WAC_2013_Nov_2013_3.png

Actualizacion_WAC_2013_Nov_2013_4.png
Una vez que finalice el proceso de instalación, nos solicitará que debemos reiniciar el servidor para completar la actualización y pulsamos en sí
Actualizacion_WAC_2013_Nov_2013_5.png

Y por último volvemos a configurar nuestra granja de Office Web Apps, para ello utilizamos el siguiente cmdlet:  New-OfficeWebAppsFarm -InternalUrl "FQDN_INTERNO" -ExternalUrl "FQDN_EXTERNO" –EditingEnabled:$true –CertificateName “Nombre_Certificado”

Actualizacion_WAC_2013_Nov_2013_6.png

Con esto ya hemos completado el proceso de actualización, ahora solo nos quedará probar desde cliente Lync a compartir una presentación de PowerPoint y ver si el resultado es el esperado y ….

Actualizacion_WAC_2013_Nov_2013_7.png
…. funciona perfectamente, por fin!!!

Actualizacion_WAC_2013_Nov_2013_9.png

Esto para los usuarios que utilizamos Lync a diario en nuestro Windows 8.1 es muy importante, porque sino o bien tenía que conectarme mediante Lync Web App o iniciar sesión en Windows 8. Por el resto como podéis apreciar la configuración es muy sencilla y además en 10 minutos lo tenéis funcionando. 

Aquí tenéis el enlace de descarga: http://support.microsoft.com/kb/2837634/en-us y ya sabéis, toca actualizar vuestra granja de Office Web Apps Server
 
Espero que os sea de utilidad!!!

​Con la llegada del CU3 de Lync Server 2013 (Actualización 5.0.8308.556 para Lync Server 2013: Octubre 2013)​, se solucionaban algunos problemas (o bugs )y también se habilitaba la posibilidad de instalar Lync Server en Windows Server 2012. Pero cuando finalizamos su instalación, se registran dos ID de sucesos: 32402, 61045 en los Front-END

 

ID. de evento 32042
Nombre de registro: Lync Server
Fuente: Servicios del usuario de LS
Fecha: 15/10/2013 4:02:05 AM
ID. de suceso: 32042
Categoría de la tarea: (1006)
Nivel: Error
Palabras clave: clásico
Usuario: N/D
Equipo: LyncFE01.contoso.local
Descripción:
Certificado HTTPS entrante y no válido.
Nombre de sujeto: LyncFE01.contoso.local emisor: Contoso CA
ID. de evento 32042
Nombre de registro: Lync Server
Origen: Infraestructura de LS MCU
Fecha: 15/10/2013 4:02:20 A.M.
ID. de suceso: 61045
Categoría de la tarea: (1022)
Nivel: Error
Palabras clave: clásico
Usuario: N/D
Equipo: LyncFE01.contoso.local
Descripción: El DATAMCU no pudo permanecer conectado a la parte delantera por el canal de C3P (conexión HTTPS).
El servidor de conferencia Web no pudo enviar notificaciones C3P al enfoque en https:// LyncFE01.contoso.local:444/LiveServer/Focus.

 

Información de MSFT sobre este problema: http://support.microsoft.com/kb/2901554

Causa: Este problema puede producirse cuando se instalan servidores de 2013 Front End de Lync Server en Windows Server R2 de 2012 debido a los cambios que se realizaron en cómo se almacenan en caché las sesiones TLS en Windows Server R2 de 2012. Estos cambios que algunos servidores de Lync Server 2013 que implican entre servidores o comunicación dentro de un servidor en el puerto TCP 444 un error.

Solución: Para evitar este problema, establezca la clave del registro de Schannel en un valor de 0 x 0002 en todos los equipos que alojan servidores frontales de Lync Server de 2013. Este cambio deshabilita la optimización de TLS de vale de sesión en el sistema.  Lo que debemos hacer es crear una clave en el registro de los servidores, para ello debemos acceder a la siguiente subclave de registo: HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel y debemos crear la siguiente clave EnableSessionTicket con un valor establecido a 2

Lync_Server_2013_compatible_con_Windows_Server_2012_R2.png
Por último debemos reiniciar los servicios de Lync Server, para ello debemos ejecutar estos dos cmdlets de powershell de Lync Server:

  • Stop-CsWindowsService
  • Start-CsWindowsService

Con este cambio en el registro desparecerán los sucesos con los IDs 32402, 61045 y vuestro Lync Server funcionará sin problema

Espero que os sea de utilidad!!!

Para los que utilizamos DirectAccess (Windows Server 2012: DirectAccess (Actualizado 15-02-2013)) el migrar a Windows 8.1 era cuestión de tener disponible la versión Enterprise, pues ya está aquí

BUZRAgUCMAAg3sA.png