Microsoft Lync Server

Publicar los servicios web de Lync con Web Application Proxy en Windows Server Technical Preview

Cómo ya he comentado en otras ocasiones, para publicar los distintos servicios Web de Lync debemos utilizar un Proxy Inverso o Reverse-Proxy, para ello he publicado distintos artículos sobre IIS ARR y TMG:

Pues ahora tocaba hacerlo con Web Application Proxy, un nuevo servicio disponible desde Windows Server 2012 que viene disponible con el Rol de Acceso Remoto. En este caso voy a mostraros como configurarlo pero ya con la versión de Windows Server Technical Preview. Para ello debemos configurar el servicio de federación (AD FS) en uno de los servidores internos de la red, y además configurar el servidor que hará de Proxy Inverso como un AD-FS Proxy. Necesitamos AD-FS para almacenar la configuración del Web Application Proxy y para la configuración de la autorización. Aquí os dejo como casi siempre un esquema de red en donde tenemos los elementos necesarios para configurar este servicio, además os he puesto a la derecha varias opciones de donde podemos situar el Proxy Inverso en nuestra red:

Para configurar Web Applicatio Proxy debemos hacerlo en varias fases que veremos a continuación y son las siguientes:

Configuración AD FS en un servidor unido al dominio
Configuración de AD FS Proxy en el servidor que será nuestro proxy inverso con Web Application Proxy

Los requisitos para esta configuración son los siguientes:

Servidor unido a un dominio (o un controlador de dominio, pero no sería lo más idóneo)
Una entidad certificadora, puesto que no necesitamos certificados públicos para la configuración de AD FS puesto que será interno
Un servidor que no esté en el dominio en donde agregaremos el rol de Acceso remoto en donde se configurará el Web Application Proxy y el servicio de Federación.

Como la configuración del Web Application Proxy se almacenará vía AD FS, será lo primero que tenemos que hacer. Para ello utilizaremos un servidor con Windows Server 2012 R2 y agregaremos el rol de AD FS, por lo que desde el Administrador del servidor pulsamos en Administrar – Agregar Roles y pulsamos en Siguiente

Seleccionamos Instalacikón basada en características o en roles y pulsamos en Siguiente

Selecionamos el servidor sobre el cual queremos realizar la configuración de un nuevo rol y pulsamos en Siguiente

Ahora debemos seleccionar Serviciosde federación de Active Directory y pulsamos en Siguiente
Si seleccionar nada, pulsamos en Siguiente

Pulsamos en Siguiente

Para iniciar el proceso de instalación, pulsamos en Instalar

Una vez que finalice la instalación del rol de Federación, debemos iniciar el asistente de configuración, para ello pulsamos en Configure el servicio de federación en este servidor

Como es nuestro primer servidor de federación, seleccionaremos Crear el primer servidor de federación de una granja de servidores de federación y pulsamos en Siguiente

Seleccionamos una cuenta con permisos de administrador de dominio y pulsamos en Siguiente

Previo a este paso, debemos tener instalado en el servidor un certificado para poder utilizarlo en el servicio de federación, este certificado puede ser privado puesto que únicamente (en este artículo) será utilizado para conectarse el Web Application Proxy. Aquí os dejo un artículo como configurar una CA en Windows Server 2012: Windows Server 2012, Instalación de una CA

Una vez que ya tenemos nuestro certificado, únicamente debemos seleccionarlo (o importarlo en este momento), escribir un nombre para el servicio de federación (debéis crear el registro DNS correspondiente) y escribir un nombre para este servicio.

Ahora debemos especificar una cuenta de dominio (sin privilegios) como cuenta de servicio, si queréis ampliar información sobre la cuenta de servicio aquís tenéis un KB de MSFT https://technet.microsoft.com/en-us/library/hh831782.aspx. Una vez que hemos creado la cuenta y la hemos configurado, pulsamos en Siguiente

Debemos crear una base de datos para la configuración, bien podemos crearla usando Windows Internal Database o utilizando un servidor de SQL. En este caso utilizaremos la opción de Crear una base de datos en este servidor que usa Windows Internal Database

Por último, nos muestra un resumen de la configuración que vamos a realizar a través del asistente, si todo está correcto, pulsamos en Siguiente

Se comprueban los requisitos del sistema para verificar que nuestro servidor cumple con todos ellos, si es así pulsamos en Configurar para iniciar el proceso

Una vez que se ha completado el proceso de instalación, nos los mostrará con la siguiente pantalla, para cerrar esta ventana pulsamos en Cerrar

Ahora lo único que nos queda es probar que el servicio funciona correctamente, para ello accedemos a la siguiente URL: https://adfs.asirlab.com/adfs/ls/IdpInitiatedSignon.aspx y pulsamos en Iniciar sesión

Nos solicitará credenciales y se las especificamos para comprobar que funciona correctamente
Si todo ha salido bien, veremos una pantalla similar a esta. Ahora sí que damos por finalizada la configuración de AD FS que necesitamos para almacenar la configuración del AD FS Proxy que será el servidor que tiene el rol de Proxy Inverso (Web Application Proxy)

Hasta ahora hemos completado la primera parte de la configuración que necesita nuestro Proxy Inverso, por lo que ahora debemos realizar las distintas configuraciones en el propio servidor que hará de proxy. Antes comentaros que el debería tener la siguiente configuración:

Dos tarjetas de Red con una subred IP diferente en cada interface
Sólo configurar la puerta de enlace y servidores DNS públicos (8.8.8.8 u otro público) en la interface que tengamos como externa
Si tenemos una DMZ o distintas VLAN internas, debemos configurar las rutas estáticas necesarias para que desde la interface interna podamos tener conexión con las redes privadas en donde tenemos los servidores que vamos a publicar y el acceso al servicio de AD FS
Un certificado para configurarlo en las reglas de publicación del Proxy Inverso
Un certificado (o el mismo que el de la publicación de servicios si procede) para el servicio de Federación
Modificar el fichero HOSTS del equipo para que pueda resolver los distintos nombres de los servidores que vamos a publicar o que necesitemos tener acceso (AD FS)
El FQDN del servidor debería ser con el sufijo del dominio interno que tenemos

Una vez dicho esto, vayamos paso a paso configurando todo lo necesario para configurar el rol de Acceso Remoto y preparar la configuración del Web Application Proxy. Para ello, una vez configuradas la tarjetas de red del servidor, establezcamos el FQDN del servidor y modifiquemos el fichero HOSTS del servidor:

Editamos el fichero HOSTS, aquí solo he puesto el los del servidor de Lync, pero habría que poner el nombre del servicio de AD FS que hemos configurado previamente y también nos haría falta la URL de los servicios de nuestro WAC y Exchange si lo tenemos en On-Premises. Aquí no los he puesto porque me he centrado únicamente en Lync

Ahora que ya tenemos los requisitos previos realizados, iniciaremos el proceso de configuración del ROL de Acceso Remoto. Comentaros, que yo estoy utilizando un Windows Server Technical Preview, pero en la versión de Windows 2012 es muy similar su configuración. Dicho esto, nos vamos a la consola de administración del servidor y agregamos el rol de Acceso Remoto:

Seleccionamos Role-Based or feature-based installation y pulsamos en Next

Seleccionamos el servidor sobre el cual vamos a querer agrear el rol de acceso remoto, en este caso es el servidor sobre el cual estamos conectados y pulsamos en Next

Seleccionamos el Rol de Remote Access y pulsamos en Next

No seleccionaremos nada y pulsamos en Next para continuar con la instalación

Pulsamos en Next

Ahora debemos seleccionar el servicio que queremos instalar dentro del ROL de Remote Access que previamente hemos seleccionado, por lo que marcamos la casilla de Web Application Proxy

Nos muestra los componentes que tiene que agregar adicionalmente al servicio de Web Application Proxy y pulsamos en Add Features

ahora ya tenemos todo lo necesario para continuar, para ello pulsamos en Next

Nos muestra un resumen de lo que se va a instalar, si estamos de acuerdo pulsamos en Install para iniciar el proceso

Una vez que termine la instalación, nos mostrará la siguiente pantalla en donde nos mostrará una opción de configuración del Web Application Proxy para ellos pulsamos en Open the Web Application Proxy Wizard

Una vez abierto el asistente de configuración, nos mostrará una pantalla en donde nos indica que debemo configurar inicialmente el servicio de federación, para iniciar el proceso pulsamos en Next

Escribiemos el FQDN del servicio de federación que habíamos configurado previamente y las credenciales correspondientes con los permisos de administrador y pulsamos en Next

Seleccionaremos el certificado que vamos a utilizar en el AD FS Proxy, recordad que como el servidor no está en el dominio y si utilizáis certificados privados debéis instalar el certificado raíz en el servidor para que no tengáis problemas con el certificado que utilicéis. Como el certificado que he utilzado lo ha emitido mi CA interna, una vez que he importado el certificado también he instalado el certificado raiz en el contenedor de certificados raiz de confianza del propio servidor, de tal forma que vea el certificado como válido. Dicho esto, ya podemos seleccionar el certificado en la pantalla de AD FS Proxy Certificate y pulsamos en Next

Ahora nos muestra un resumen de los comandos de powershell que se ejecutarán en base a la configuración que hemos ido realizando a través del asistente y pulsamos en Configure para continuar

Si tanto la URL, como las credenciales y el certificado presentado están correctos, nos mostrará la siguiente pantalla indicándonos que se ha completado de forma correcta.

Ahora lo único que nos queda es crear las reglas de publicación necesarias para nuestro Lync, para ello pulsamos en Publish

Pulsamos en Next

Cómo para los servicios de Lync no utilizamos preautenticación, seleccionamos Pass-through y pulsamos en Next

Debemos cubrir los siguientes campos disponibles en la publicación del servicio:

Nombre: Será el nombre descriptivo que tendrá la regla de publicación
External URL: Dirección web del servicio que vamos publicar, en este caso voy a publicarlos servicios web externos de Lync y este es el FQDN que había establecido en la topología de Lync (lync.asirlab.com)
External Certificate: Es el certificado que vamos a presentar a los usuarios externos cuando se conecten a los distintos servicios de Lync
Backend serve URL: Dirección web del servidor que vamos a publicar, al igual que hacemos con otros proxy debemos especificar la URL y el puerto 4443 que se corresponde con el sitio web externo que tenemos en nuestros front-END

Ahora que ya tenemos todos los campos cubiertos, pulsamos en Next

Nos muestra un resumen de la configuración que se va a aplicar vía powershell (Add-WebApplicationProxyApplication) y para que se cree la regla de publicación pulsamos en Publish

Y por último en Close y ya tenemos nuestra primera regla de publicación de los servicios web de Lync

Y aqui tenemos nuestra primera de Lync en el Web Application Proxy, ahora tendremos que hacer todas las necearias como por ejemplo:

meet.asirlab.com (Reuniones en línea)
dialin.asirlab.com (Conferencias Telefónicas)
lyncdiscover.asirlab.com (Cliente Lync Móvil)
office.asirlab.com (Office Web App)
mail.asirlab.com (EWS de Exchange)

Por mostraros una diferente a Lync, aquí tenéis la regla de publicación del Office Web, en mi caso he puesto la dirección externa y el servidor interno siempre con la misma URL pero puede ser diferente sin problema alguno.

Claramente lo que nos quedaba por haacer es probar que podíamos conectarnos, por lo que tratamos de conectarmos por ejemplo a la URL de las reuniones en línea y vemos que funciona perfectamente.

Algo que debemos hacer es configurar el tiempo de desconexión de las conexiones que pasan por el Proxy, como por ejemplo el cliente Lync Móvil. Si recordáis había pulicado este articulo sobre las desconexiones del cliente Lync móvil através del IIS ARR (Cliente Lync Móvil 2013: La información del servidor ha cambiado. Reinicia Lync). Por defecto MSFT recomendaba poner un valor de 200 segundos
y con este valor los clientes Lync de móvil cuando no tenían la aplicación en primer plano a los 200 segundos se desconectaban y claro eso genera problemas a los usuarios finales que deben reconectar cada poco tiempo. Para esto se configuraban las desconexiones a los 960 segundos, algo más razonable y que permite tener la aplicación en segundo plano iniciada durante un tiempo prudencial:

Dicho esto, ahora debemos ver como hacerlo en el Web Application Proxy, para ello debemos hacerlo mediante PowerShell. Lo primero es ver el valor por defecto y luego cambiar si fuese necesario, para ello ejecutamos el siguiente cmdlet: Get-WebApplicationProxyApplication y vemos todas las reglas de publicación. Si ahora ejecutamos Get-WebApplicationProxyApplication -Name Lync | fl nos muestra la configuración de cada publicación y vemos que el valor InactiveTransactionsTimeoutSec está establecido a 300

Por lo que debemos cambiarlo a 950 y así ajustarlo de forma adecuada, para ello ejecutamos el siguiente cmdlet: Set-WebApplicationProxyAppliation -ID xxxxxx.xxxxxx.xxxxxx.xxxxxxx -InactiveTransactionsTimeouts 950. El ID de la aplicación lo veis con ejecutando el cmdlet Get-WebApplicationProxyApplication -Name Lync | fl

De esta forma el valor por defecto de desconexión establecido a 300 segundos (más que la recomendación de 200 segundos en el IIS ARR), lo hemos pasado a 950.

Por último comentaros, que si publicáis algún servicio vía HTTP tendréis que permitir la conexión en el Firewall Local de Windows, porque por defecto se ha creado solo una regla para el tráfico HTTPS. Si abrimos la consola avanzada del firewall la regla AD FS HTTPS Services (TCP-in), por lo que permitirá todas las conexiones al puerto 443 de entrada a cualquiera de las interfaces del Proxy.

Si creamos una regla para publicar una web vía HTTP, la conexión no funcionará …

Si vemos las conexiones activas en el servidoa al puerto 80 y el firewall activado vemos que no tenemos ninguna conexión activa

Lo que debemos hacer es crear una reglapara el tráfico HTTP de entrada y listo, ya tendremos acceso a los servicios web publicados en el PROXY através del puerto 80 en TCP

Si ahora volvemos a conectarmos al servicio web publicado, ya tendremos acceso al mismo

Si nuevamente volvemos a revisar las conexiones activas, vemos que ya las vemos establecidas y con el Firewall activo

Por último hacer un breve comentario sobre las tres posibles (hay más, pero como norma general) ubicación del Proxy Inverso en nuestra red, he esquematizado los más habituales:

Opción 1: Situaremos el Proxy (fuera del dominio) en una DMZ protegido por dos Firewall corporativos, realizando filtrados a nivel 3 desde todas las zonas de red (Internet, LAN). Esta es la mejor opción posible de las que os expongo, puesto que tenemos distintas barreras de seguridad antes de tener acceso a la red interna, además de que podemos realizar distintos filtrados en distintas zonas de la red. Si fuese posible, que los dos Firewalls fuesen de compañias diferentes, evitando así que si uno de ellos tuviese alguna vulnerabilidad, no estuviese afectada toda la red. Ni que decir tiene que debemos mantener nuestra infraesctructura de red adecudamente actualizada

Opción 2: La más común de todas, tenemos un firewall / Router a nivel de perímetro co un interface LAN con una subred IP diferente a la de la LAN. De esta forma el Proxy se conectará directamente al router (o switch intermedio) con una interface y subred IP y con la otra internface y subred IP a la LAN. Para esto podremos utilizar VLAN o simplemente configurar dos subredes diferentes pero todos compartiendo el mismo medio físico (Switch). Si es así no es lo más recomendable aun para este escenario lo suyo sería una VLAN para poner las interfaces LAN del Router y WAN del Proxy, y otra VLAN en el switch para configurarlo para la red local e interface LAN del Proxy.

Opción 3: Menos común y la peor opción, es tener el proxy con dos interfaces en la misma subred, no tiene ni sentido tenerlo así. El proxy también puede funcionar con una sola IP, por lo que es lo mismo que tener dos interfaces con la misma subred. Es común en las empresas pequeñas tener este esquema, porque tienen un router y una interface LAN que está en la misma subred IP que la red interna para que los equipos se puedan conectar a internet. Pero si bien es cierto que con este escenario no tenemos una capa de seguridad a nivel de filtrado IP, puesto que si un atacante compromenten el Proxy, por lo menos a nivel IP ya se encuentra en la misma subred. Esto facilitará al atacanque descrubrir distintos servicios de la red local, los equipos, etc… si estuviese en otra subred IP se podrían aplicar de forma "más efectiva" distintos filtrados, porque realmente el Proxy Inverso solo necesita comunicarse con los equipos de la red coporativa que van publicar sus servicios a internet (para más cosas, pero vamos por se escueto)

Y ya dicho esto, ahora que cada uno tome las decisiones que crea oportunas para situar su Proxy Inverso en su red, el riesgos que quiera asumir cada uno ya …

Como veis un Proxy Inverso no es un servicio muy complicado de configurar, únicamente debemos cumplir todos los requisitos y tener claros los conceptos de publicación, DNS, certificados, etc… pero hay que tenerlo claro :-).

Os dejo algunos artículos que os podrían ser de interés con respecto al Proxy Inverso para una topología de Lync:

Espero que os sea de utilidad!!!

Windows Server 2012 R2: Discos Virtuales iSCSI (Actualizado 30-01-2015)

marzo 11th, 2015 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

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:

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

pulsamos en siguiente

nos muestra un resumen del rol y/o características que vamos a instalar y si está todo correcto, pulsamos en instalar

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

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 fisicamente se almacenarán los VHDX que vamos a asignar al resto de servidor via iSCSI.

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

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

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

Debemos especificar un nombre para poder identificarlo de forma sencilla y pulsamos en siguiente

pulsamos en Agregar

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

Escribiemos el nombre de equipo y lo seleccionamos

pulsamos en agregar

ahora que ya tenemos configurado nuestro servidores de acceso, pulsamos en Siguiente

Podemos configurar varios tipos de autenticación si queremos que los servidores conectados al disco virtual se tengan que autenticar previamente, pulsamos en siguiente

Por último nos muestra un resumen de nuestra configuración y si está todo correcto pulsamos en crear

Espermos unos segundos hasta que se complete la configuración y pulsamos en cerrar

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

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á

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

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)

Pues ahora lo que nos queda es configurar el Iniciador iSCSI en el servidor de destino

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

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 …

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, direcionamiento IP y red dedicada para una mayor rendimiento)

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

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

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

Una vez inicializado creamos un nuevo volumen simple …

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

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

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

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

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

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

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 …

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

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

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

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

Ú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…)

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

para finalizar la expansión del volumen pulsamos en Finalizar

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

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

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 difenente a la red de datos
Jumbo Frames configurado si vuestro hardware lo soporta

Pensad que los usuarios que accediesen a la ínformació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

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

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.

Nota Importante (actualización 30-01-2015)

Desde Windows 7, 8, Server 2008 R2 y superior las directivas SAN (https://technet.microsoft.com/es-es/library/gg252636.aspx) establece a OfflineAll todos los discos descubiertos en el sistema a excepción del disco de sistema. Por lo que si os habéis realizado las configuraciones de este articulo, cuando reiniciéis los servidores tendréis que poner los discos en línea una y otra vez en cada reinicio. Claramente esto no se puede dejar así, por lo que debemos establecer la directiva SAN a OnlineAll y así tendremos siempre los discos activos siempre que se reinicie el servidor. Para ello iniciamos DISKPART y escribimos el comando SAN para que nos muestra la directiva actual (por defecto OfflineAll), para cambiarla escribimos san policy=onlineall

Con esto ya haremos que el sistema siempre tenga los discos activos y vuestros VHD expuestos via iSCSI a través del iniciador. Tenemos tres políticas que os comento acontinuación:

OnlineAll: Pone todos los discos en línea (no hacer eso si se comparten los discos entre varios servidores, a excepción de si tenéis un clúster)
OfflineAll: Todos los discos está fuera de línea a excepción del disco de sistema
OfflineShared: Pone en línea todos los discos que no se encuentra en buses compartidos (SCSI e iSCSI)

Si alguno de vosotros ha probado esta configuración recordar establecer la directiva SAN al valor OnlineAll

Espero que os sea de utilidad!!!

Service Pack 1 para Microsoft Office Web Apps Server (KB 2880558)

mayo 12th, 2014 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

Microsoft ha liberado el día 18/04/2014 el SP1 para Microsoft Office Web Apps Server (KB 2880558), disponible para su descarga desde aquí: http://www.microsoft.com/es-ES/download/details.aspx?id=42547

Este servicio será utilizado por Lync, SharePoint y Exchange 2013 para poder visuarlizar vía web documentos de Office. En Lync 2013 se utliza para poder compartir las presentaciones de PowerPoint en las reuniones en línea. El proceso de instalación es muy sencillo y se resume en los siguientes pasos:

Quitar la granja de servidores de Office Web App: Remove-OfficeWebAppsMachine
Instalar el paquete de actualización: http://www.microsoft.com/es-ES/download/details.aspx?id=42547
Reiniciar el servidor
Configurar nuevamente la granja de Office Web App: New-OfficeWebAppsFarm

Una vez que tenemos claro estos pasos, pues procedemos llevarlo a la práctica, así que lo primero será quitar la granja de Office Web Apps Server

Instalamos la actualización que nos hemos descargado previamente: http://www.microsoft.com/es-ES/download/details.aspx?id=42547

Una vez que se complete la instalación de la actualización, debemos reiniciar el servidor y una vez que se haya reiniciado volvemos a configurar la granja de Office Web Apps Server: New-OfficeWebAppsFarm

New-OfficeWebAppsFarm -InternalUrl "https://office.asirsl.com" -ExternalUrl "https://office.asirsl.com" –EditingEnabled:$true –CertificateName “office”

Con esto ya hemos finalizado el proceso de actualización, ahora solo nos queda probar que funciona correctamente. Si queremos probarlo desde Lync, iniciamos una conferencia y compartimos una presentación de PowerPoint:

También podemos acceder a la siguiente url para verificar que los servicios del Office Web Apps Server están activos: https://nombre_servidor/hosting/discovery (https://office.asirsl.com/hosting/discovery)

Como podéis apreciar tampoco tiene mucha complicación la actualización, únicamente seguir los pasos adecuados para actualizar correctamente el Office Web Apps Server.

Espero que os sea de utilidad!!!

Importante: Microsoft cambiará la IP del registro SIPFED.MICROSOFT.COM

mayo 12th, 2014 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

Microsoft ha anunciado que cambiará la dirección IP de SIPFED.MICROSOFT.COM (65.55.30.130) a la IP 131.107.255.86, pero este cambio se hará efectivo el día 9 de Mayo a las 08:00 PM en USA. Por lo que los que estamos en España el cambio nos afectará el día 10 de Mayo a las 05:00 AM, así que debemos estar atentos al cambio. Básicamente debe preocuparnos lo siguiente:

Rápida actualización del DNS: Aquí nosotros poco podemos hacer, puesto que será el servidor DNS público que os resuelva las consultas DNS de nombres externos (por ejemplo los servidores DNS de Google: 8.8.8.8 y 4.4.4.4) quien debe actualizar la caché del registro sipfed.microsoft.com
Actualización del filtrado en los Firewall corporativos: Si tenemos filtradas las direcciones IP las cuales permitimos las federaciones de entrada y salida, debemos cambiar la IP 65.55.30.130 por la IP 131.107.255.86

El registro SIPFED.MICROSOFT.COM se corresponde con el HOST que nos permite federarnos con Microsoft, de ahí la importancia de que nuestro EDGE resuelva correctamente ese nombre. Si utilizamos el nslookup para resolver el registros SRV _sipfederationtls._tcp.microsoft.com podemos ver que el host es sipfed.microsoft.com y si resolvemos ese nombre podemos observar que la dirección IP actual es la 65.55.30.130, que será la IP que el día 10 de Mayo en España cambiará a la IP 131.107.255.86. En la siguiente captura podéis ver como utilizar nlsookup para resolver nombres de dominio de cualquier tipo en función de lo que le solicitéis:

Como veis debemos estar atentos para cambiar los filtrados en nuestros Firewalls (si los tenemos activos) y luego que nuestro EDGE resuelva la nueva IP del registro sipfed.microsoft.com, pero esto dependerá del TTL del registro. Si queréis comprobar por curiosidad el tiempo de vigencia del registro en caché de vuestro servidor DNS público, podéis hacerlo también con NSLOOKUP, para ello debéis ejecutar el siguiente comando: nslookup -type=A -debug sipfed.microsoft.com

texto borrado *******************************************

continuación ….

QUESTIONS:

sipfed.microsoft.com, type = A, class = IN

ANSWERS:

-> sipfed.microsoft.com

internet address = 65.55.30.130

ttl = 2667 (44 mins 27 secs)

————

Respuesta no autoritativa:

Nombre: sipfed.microsoft.com

Address: 65.55.30.130

Ahí tenéis el TTL del registro DNS sipfed.microsoft.com (ttl = 2667 (44 mins 27 secs)), cuando expire este tiempo los servidores DNS que han consultado ese registro, volverán a solictárselo al servidor DNS que lleve esa zona, de tal forma que en el momento que MSFT cambie la dirección IP aun es posible que durante un breve espacio de tiempo veamos la IP antigua. Pero una vez expire el TTL y el servidor DNS al que le consultamos por el registro sipfed.microsoft.com lo haya vuelto a consultar, ya tendremos el registro actualizado con la nueva IP. Igualmente, sería conveniente vaciar la caché dns del EDGE (ipconfig /flushdns) y reiniciar el servicio de acceso de Lync.

Espero que os sea de utilidad!!!

Cómo asignar rutas estáticas desde un servidor DHCP (Opción 121)

abril 3rd, 2014 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

En este artículo no mostraré como configurar un servidor DCHP, únicamente me centraré en una de las opciones del servidor DHCP (121 Rutas Estáticas Sin Clase) muy interesante a mi entender y que he visto que se utiliza muy poco. La finalidad de utilizar esta opción es la posibilidad crear rutas estáticas a los clientes desde el servidor DHCP, es especialmente útil en redes pequeñas con hardware L3 con opciones reducidas. Si vemos el siguiente esquema de red, podemos apreciar una red que tiene dos enrutadores y que ambos nos llevarán a redes diferentes: Internet y Sedes remotas conectada por VPN (Cisco VPN IPSec Site-to-Site con Certificados Digitales)

Rutas_Estáticas_DHCP.png

Cuando configuramos un servidor DHCP siempre pensamos en los parámetros básicos:

Dirección IP
Máscara de Subred
Puerta de Enlace
DNS Primario
DNS Secundario
Etc….

Lógicamente con estos parámetros podemos conectarnos a la red y tener acceso a resolución DNS por lo que a buen seguro tendremos acceso a los recursos de la compañia e Internet. Pero es posible que entornos más pequeños en vez de tener un sistema en HA a nivel de comunicaciones, tengamos dos routers/firewalls que estén funcionando de forma independiente cada uno con su conexión a Internet y cada uno de ellos con servicios diferentes (Internet y VPN). Según el esquema anterior, estos serían los datos de nuestra redes:

Servidor DHCP

Pool 10.100.100.50 – 10.100.100.80
DNS: 10.100.100.x
Gateway: 10.100.100.1

Sedes Remotas

192.168.250.0/24
192.168.251.0/24

Router 1 (Servicio de Internet): 10.100.100.1
Router 2 (Servicio de VPN): 10.100.100.10

Todos los equipos de la red están configurados mediante DHCP, facilitando así la configuración de los parámetros de red. Como el router 1 solo nos ofrece la conexión a Internet, este será el que configuraremos como puerta de enlace (10.100.100.1) en los equipos, para que todo el tráfico para el cual el equiop no tenga ruta conocida (rutas estáticas o red local) lo envié al router y este enrute la petición hacia Internet (por que es lo único que tiene configurado este dispositivo). Esto nos vale para conectarnos a destinos "no conocidos" previamente, por ejemplo Internet. El Router 2 (10.100.100.10) es un router en el cual hemos configurado nuestras VPN, y solo lo utilizaremos para esto. Este router es el que "sabe" como llegar a las subredes de las otras sedes, y será el encargado de conectarnos con ellas. Llegado a este punto podemos realizar varias configuraciones:

Configurar rutas estáticas en todos los equipos de forma manual: route add 192.168.250.0 mask 255.255.255.0 10.100.100.10 -p y route add 192.168.251.0 mask 255.255.255.0 10.100.100.10 -p
Configura rutas estáticas en el router 1: de esta forma los equipos enviarán las peticiones dirigidas a su puerta de enlace (10.100.100.1) y el router 1 (10.100.100.1) se las enviará al router 2 (10.100.100.10), de tal forma que el enrutamiento lo harán entre los routers 1 y 2
Configurar rutas estáticas vía DHCP: podemos enviar actualizaciones a la tabla local de ruteo de los equipos a través del DHCP

De estas tres opciones, me quedo con la tercera y os comento el porqué. La primera opción es viable si tenemos 5 equipos, si tenemos 30 lo complicamos y si tenemos 100 no tiene sentido. El proceso es manual (aunque podamos configurar GPO para actualizar las rutas o automatizar el proceso de alguna forma), no dejará de ser un sistema manual siempre muy propenso a fallos. El segundo sistema funciaría perfectamente, podríamos tener un problema de rendimiento, puesto que añadimos un salto más (aunque sea una red local) de una interface LAN del Router 1 al Router 2, puesto que la comunicación sería de la siguiente forma (pulsar en la imagen para verlo a tamaño original):

Con esta configuración, cuando algún equipo necesite conectarse a algún recurso de las sedes remotas (192.168.250.0/24 y 192.168.251.0/24) se conectarál Router 1 (10.100.100.1) y este al Router 2 (10.100.100.10) y de ahí las sedes. El tráfico de retorno se le devolverá de igual forma, porque es el gateway por donde los equipos pueden conectarse a las sedes (esto también es discutible, pero dejémoslo así). Ahora bien, si logramos que todos los equipos tengan una ruta estática definiendo que para llegar a las sedes conectar por VPN se conectarán mediante el Router 2 (10.100.100.10) el tráfico será directo entre los clientes y el router, esto evitará latencias indeseadas y menos puntos de falla, este seria el esquema (pulsar en la imagen para verlo a tamaño original):

Como podéis apreciar en el esquema anterior, vemos que por defecto el tráfico dirigido a las sedes se envirá directamente al Router 2 (10.100.100.10), esto evitará pasar por la interface del Router 1 (10.100.100.1) y añadiendo latencia en el enlace hacia el Router 2 (10.100.100.10). Siendo esta la configuración deseada, ahora debemos ver como configurarlo de forma automática y para ello vamos a utilizar la opción 121 de nuestro servidor DHCP (en este caso un Windows Server). Para ello configuramos nuestro ámbito DHCP y luego añadimos la opción 121 desde las Opciones de ámbito:

Esta opción debemos buscarla en las Opciones del Ámbito, está al final de la lista (por defecto) y habilitamos la casilla de 121 Rutas estáticas si clase

Ahora únicamente debemos configurar las rutas que queramos enviar a los clientes DHCP, debemos especificar la red de destino, la máscara y la puerta de enlace por la que queremos llegar a esa subred:

Destino: 192.168.250.0
Máscara de red: 255..255.255.0
Puerta de Enlace: 10.100.100.10

Debemos agregar tantas rutas como necesitamos

Como podemos apreciar ya tenemos una ruta agregada, si queremos más rutas estáticas pues las agregamos

Antes de aplicar esta configuración en el DHCP, veamos que tabla de ruteo tenía un equipo sin la opción 121 del DHCP, para ello desde una línea de comandos escribimos route print:

Y sí analizamos los distintos paquetes del DHCP vía WiresHark podemos ver como nos entrega los parámetros que hemos configurado en el DHCP Server y el número de opción

Como vemos no tiene ruta alguna para la red 192.168.250.0/24 y la puerta de enlac es la 10.100.100.1 (este router no tendría configuración alguna de ruteo hacia las sedes conectadas por VPN, únicamente local (LAN) E internet (WAN). Si ahora aplicamos la configuración al DHCP con la opción 121 vemos que el equipo recibe la ruta estática en su tabla de ruteo, no está como permanente porque la recibe del servidor cada vez que solicite una IP. Como vemos ya tenemos una ruta hacia la red 192.168.250.0/24 y la puerta de enlace para el tráfico sin destino conocido (0.0..0.0 0.0.0.0) tiene para nosotros la la IP del Router 1 (10.100.100.1)

Si ahora abrimos una traza de Wireshark nos encontramos lo siguiente, vemos que tenemos la opción 121 con la ruta estática creada y que con el route print podemos ver en el equipo. En mi caso yo he utilizado la IP 10.100.100.1 como servidor DHCP pero este sería la del router por el cual salimos a Internet (es un LAB y hay que aprovechar recursos). Pero a todos los efectos es operativo, por lo que la IP 10.100.100.1 es nuestra puerta de enlace para el tráfico de Internet, y sin embargo ahora teenemos una ruta hacia la red 192.168.250.0/24 a través del Router 2 (10.100.100.10). Lo que está claro que es la interface LAN de ambos routers debe estar en la misma subred que los clientes, sino … no podremos llegar directamente sin otro enrutador de por medio. En este caso hablamos siempre de un escenario muy simple, un switch y dos routers con una interface LAN y WAN.

Pues con esto tenemos todo configurado, como vemos es muy sencillo configurar "rutas estáticas" en los equipos de nuestra red desde nuestro servidor DHCP. Ya os digo que es muy útil para muchos entornos en donde no tengamos un hardware de L3 adecuado, puesto que si tenemos un switch L3 ya podemos hacer el ruteo a nivel de este switch y no tocamos el DHCP, etc…

Espero que haya quedado mas o menos claro el concepto, y el porqué elegir una opción y no otra, cuestión de optimización, automatización y simplicidad. En un servidor DHCP tenemos muchas opciones de configuración muy interesantes, así que ahora os toca explorarlas a vosotros …

Publicar los servicios web de Lync con Web Application Proxy en Windows Server Technical Preview

Windows Server 2012 R2: Discos Virtuales iSCSI (Actualizado 30-01-2015)

Service Pack 1 para Microsoft Office Web Apps Server (KB 2880558)

Importante: Microsoft cambiará la IP del registro SIPFED.MICROSOFT.COM

Cómo asignar rutas estáticas desde un servidor DHCP (Opción 121)

Santiago Buitrago

Entradas recientes

Comentarios recientes

Archivos

Categorías

Únete y comparte tu conocimiento

Sígueme en Twitter