Archivo

Archivo para la categoría ‘Server 2012’

Internet Information Server: ARR (Application Request Routing)

domingo, 15 de mayo de 2016 Comments off

He estado unos días configurando, con la ayuda del inestimable José Manuel Tella, el servicio de enrutamiento en IIS, de tal forma que nos va a permitir tener un servidor IIS de cara a Internet mostrando el frontend de varios sitios web que vamos a poder tener instalados en diversos servidores de nuestra red interna.

En el servidor que vamos a tener de cara a Internet vamos a montar un Server 2012 R2, y una vez finalizada la instalación del server le añadimos el rol de IIS. En principio le añadí todas sus características, aunque en un servidor en producción podemos afinar más e instalarle sólo aquello que vayamos a necesitar. Así mismo, en las pruebas le instalé un servidor DNS para resolver correctamente los dominios internos, aunque también se puede emplear un DNS ya existente.

Una vez instalado IIS, el siguiente paso es instalar ARR. Para ello lo primero es instalar Web Platform Installer, que podemos encontrar en el siguiente enlace:

https://www.microsoft.com/en-us/download/details.aspx?id=6164 

image 

Tras completar la instalación, abrimos la consola de administración de IIS y veremos que nos ha aparecido un nuevo icono para administrar la instalación de componentes de la plataforma web.

image

Lo ejecutamos y en “Productos” buscamos el complemento “Enrutamiento de solicitud de aplicaciones 3.0” (Application Request Routing 3.0 si el servidor lo tenemos en inglés). Tras la instalación reiniciamos el servicio IIS.

image

En el árbol de la izquierda vemos que nos ha aparecido una rama “Server Farms”, que aunque no es objeto de este artículo, nos permitirá distribuir la carga de trabajo recibida en el servidor web frontend entre varios servidores. La opción que nos interesa ahora es la de “Reescritura de dirección URL”, dentro de la web por defecto.

 image

Una vez estamos dentro de “Reescritura de dirección URL” seleccionamos en “Acciones” del panel derecho la opción “Ver variables de servidor”

image

Y añadimos las dos que muestro a continuación:

HTTP_ACCEPT_ENCODING

HTTP_X_ORIGINAL_ACCEPT_ENCODING

y volvemos a reglas

image

Es el momento de añadir la primera regla, que nos permitirá redirigir las solicitudes http que entren en nuestro frontend con el encabezado “http://www.gericom.es/” al servidor interno 192.168.1.32. Si al añadir la regla nos pide confirmación para iniciar el proxy de enrutamiento, le decimos que sí.

Creamos una regla en blanco, le damos un nombre y le indicamos que la url solicitada coincide con el patrón, usando expresiones regulares y poniendo como patrón (.*)

Con esto conseguimos que lo que se solicite en la url de entrada tras el primer “/” coincida exactamente con lo que se redirige al servidor interno.

En cuanto a las condiciones, le agregamos una de tipo {HTTP_HOST} que coincida con el patrón “www.gericom2.es”. Este es el dominio que tendremos que tener registrado en Internet apuntando a la IP de nuestro servidor web frontend y que vamos a redirigir al servidor interno 192.168.1.32.

En variables de servidor añadimos a la regla las dos que hemos definido anteriormente, como podemos ver en la imagen. Por fin, añadimos una acción de tipo reescribir que apunte a la dirección de nuestro servidor interno

http://192.168.1.32/{R:1} 

image

image

No debemos olvidar pinchar en “Aplicar” para que se guarden los cambios.

Seguidamente creamos una regla de salida en blanco que relacione los nombres de dominio internos (o direcciones ip del servidor interno) al nombre de la url externa que nos habían solicitado. Le ponemos como condición “ResponseIsHtml1”, marcamos todas las coincidencias de contenido y le ponemos como patrón ^http(s)?://192.168.1.32/(.*) y como acción que reescriba a  http{R:1}://gericom2.es/{R:2}

 

image

image

 

Volvemos a crear una nueva regla en blanco, ahora con condición “NeedsRestoringAcceptEncoding”, y los valores que vemos a continuación.

image 

image

Una vez hecho todo lo indicado, veremos que el servidor web enruta las solicitudes que recibe de la dirección “www.gericom2.es” al servidor interno, que las resuelve y las devuelve al frontend para que las devuelva a su vez al cliente que las solicitó. El cliente siempre ve en su navegador que la url coincide con “www.gericom2.es”, y no ve la url o dirección del servidor interno que ejecuta la aplicación web.

Podemos realizar esto para múltiples aplicaciones web soportadas por más de un servidor web interno, añadiendo al servidor frontend tantas reglas de entrada y salida como necesitemos.

Como resultado de lo indicado en este artículo, el web.config del sitio por defecto del servidor frontend queda como sigue:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule4" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://192.168.1.32/{R:1}" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="www.gericom2.es" />
                    </conditions>
                    <serverVariables>
                        <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
                        <set name="HTTP_ACCEPT_ENCODING" value="" />
                    </serverVariables>
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule4" preCondition="ResponseIsHtml1">
                    <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://192.168.1.32/(.*)" />
                    <action type="Rewrite" value="http{R:1}://gericom2.es/{R:2}" />
                </rule>
                <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
                </rule>
                  <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="NeedsRestoringAcceptEncoding">
                        <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <httpErrors>
            <remove statusCode="404" subStatusCode="-1" />
            <error statusCode="404" prefixLanguageFilePath="" path="http://www.gericom2.es" responseMode="Redirect" />
        </httpErrors>
        <urlCompression doStaticCompression="false" doDynamicCompression="false" />
    </system.webServer>
</configuration>

Categories: Server 2012, Server 2012 R2 Tags:

Configuración de un ámbito DHCP

miércoles, 3 de julio de 2013 1 comentario

A petición de un usuario de los foros TechNet, pongo el paso a paso de la creación de un nuevo ámbito DHCP v4.

Partimos de un servidor 2012 con el servicio DHCP instalado y autorizado en el dominio. En versiones anteriores es prácticamente idéntico.

En primer lugar, con el botón derecho seleccionamos “ámbito nuevo”

dhcp01

Se iniciará el asistente para la creación de un ámbito nuevo

dhcp02

Daremos un nombre al ámbito, y si lo deseamos, una descripción

dhcp03

El siguiente paso es definir el rango de direcciones del ámbito, definido por las direcciones inicial y final. En el ejemplo vamos a crear un ámbito de 512 direcciones, por lo que una vez establecidas las direcciones inicial y final, tenemos que decirle que la longitud de la máscara es de 23 bits (para que no nos pregunte si queremos crear un superámbito con dos ámbitos de 256). Indicar que la dirección de definición de la red (192.168.0.0) y la de Broadcast (192.168.1.255) no se pueden usar en la definición del ámbito.

dhcp04

Hemos definido el rango total del ámbito, pero seguramente no querremos que todas las direcciones se puedan asignar automáticamente a los clientes, excluyendo partes del ámbito de esta asignación automática, de tal forma que estas direcciones las podamos asignar de forma manual a servidores, routers, impresoras, switches, etc, sin peligro de que se pudieran asignar a un cliente. Para ello, en la siguiente pantalla, definimos las direccines inicial y final de cada rango que queramos excluir, y, muy importante, pulsamos el botón “agregar” para que nos añada a la lista inferior el rango excluido. Es un error muy común escribir las direcciones a excluir y pinchar el botón “siguiente”, con lo que realmente no las hemos excluido. En el ejemplo hemos excluido 20 direcciones del inicio, y tenemos pendiente de agregar otra exclusión de 14 direcciones al final del ámbito.

dhcp05

El siguiente dato que nos pide el asistente es la duración máxima de las concesiones de direcciones. El valor a indicar depende del total de direcciones disponibles en el ámbito para asignar automáticamente y del número total de equipos que podrán solicitar dirección. Un proveedor de servicios de Internet tiene que estudiar muy bien este dato, con tiempos de concesión pequeños si tiene un rango limitado y muchos clientes. En una red local no sueles tener ese problema, por lo que puedes usar tiempos de concesión mucho más grandes. El valor por defecto es suficiente en la mayoría de los casos.

dhcp06

Si no hemos configurado las opciones DHCP de forma global para todo el servidor DHCP y queremos personalizarlas para cada ámbito que creemos en el servidor, es el momento de hacerlo, aunque también lo podemos configurar a posteriori.

dhcp07

Añadimos la dirección de la puerta de enlace. Sólo una, pues los clientes Windows ignorarán el resto si ponemos más. No olvidemos, como antes, pulsar el botón “agregar”.

dhcp08

Indicamos el nombre de dominio que usarán por defecto los clientes (y zona DNS en que los registrará el servidor DHCP por defecto) y añadimos las direcciones de los servidores DNS a usar. Si no sabemos las direcciones pero sí el nombre del servidor, lo escribimos y nos intentará resolver su dirección).

dhcp09

En muchas organizaciones se sigue usando el servicio WINS. Si es el caso, añadir las direcciones de los servidores WINS que vayan a usar los clientes. Si no se usan, dejar la lista vacía y pinchar “siguiente”.

dhcp10

Una vez hemos definido las principales opciones del ámbito nos pide si activarlo de inmediato o dejarlo para después. Hasta que el ámbito no esté activado no comenzará a asignar direcciones a los clientes que pidan configuración. Si tenemos el servidor conectado ya a la red que tiene que servir, podemos activarlo de inmediato.

dhcp11

Una vez terminado el asistente, ya podemos ver en la consola DHCP el nuevo ámbito que hemos creado, con las opciones definidas en el mismo. Si es el caso, podemos añadir nuevas opciones, añadir o quitar exclusiones, crear reservas, etc.

dhcp12

Una reserva nos va a permitir que el servidor DHCP asigne siempre la misma dirección a un equipo en particular, y nunca a otro. Esto es muy útil para impresoras, o para equipos que tengan que tener siempre la misma dirección por algún motivo y no queremos configurarlos de forma manual

 

dhcp13

Para crear una reserva nueva, damos un nombre a la reserva, la dirección IP que le queremos asignar siempre, escribimos la MAC del dispositivo y una descripción. En tipos compatibles marcamos ambos o sólo DHCP. Normalmente no nos encontraremos ya dispositivos tan antiguos que requieran sólo BOOTP.

dhcp14

Una vez terminado ya podemos ver la reserva creada, y si lo necesitamos, modificar sus propiedades.

dhcp15

La principal ventaja de usar una reserva en lugar de configurar estáticamente la dirección ip en el dispositivo es que si en el futuro necesitamos cambiar el rango de direcciones de la red, tan sólo tenemos que crear un ámbito nuevo y definir en el mismo la nueva configuración. Evidentemente tendremos que modificar a mano oportunamente las direcciones de servidores, routers, switches, etc, pero todos los dispositivos como impresoras o equipos con reserva cogerán automáticamente la nueva configuración sin tener que hacerles nada (como mucho apagarlos y volver a encenderlos).

 

 

Categories: Server 2012 Tags:

Windows 8.1 Preview

domingo, 9 de junio de 2013 Comments off

Microsoft ha anunciado la preview de Windows 8.1 para el próximo 21 de junio. Esta preview es pública, con lo que cualquier usuario de Windows 8 tendrá opción a instalarla. No obstante, es preciso tener en cuenta algo muy importante: si bien desde Windows 8 RTM será posible actualizar a Windows 8.1 RTM directamente y manteniendo tanto configuración personal como todas las aplicaciones instaladas, si optamos por actualizar a la preview, en su momento podremos instalar desde ésta la actualización a Windows 8.1 RTM, pero aunque mantendremos la configuración personal, será imprescindible reinstalar todas las aplicaciones, tanto las de escritorio como las de la interfaz moderna.

Esto hace que haya que pensarse mucho hacer la instalación de la preview en nuestro ordenador principal, más si las aplicaciones venían instaladas de fábrica y no tenemos los discos de instalación de las mismas, sino un disco de recuperación de todo el equipo.

Para probar la preview, lo más aconsejable es usar una instalación secundaria de Windows 8, bien en una partición distinta de la principal, o bien en una máquina virtual, lo que nos permitirá preservar nuestra instalación principal de Windows 8 y actualizarla en su momento a 8.1 manteniendo todas nuestras aplicaciones.

Por último, confirmar que la actualización a Windows 8.1 será gratuita para cualquier versión de Windows 8 (sea RT, W8, Pro o Enterprise), y que estará disponible a través de la tienda de Windows.

Categories: Server 2012, Windows 8 Tags:

Mejoras de la Red en Server 2012 – II

martes, 4 de junio de 2013 Comments off

Continuando con la entrada anterior, tenemos algunas mejoras más de la red en Windows Server 2012

SR-IOV (Single Root Input Output Virtualization)

SR_IOV es una especificación que define como un dispositivo hardware expone varias  “superficies hardware ligeras” llamadas Funciones Virtuales (VF) a las máquinas virtuales. Una VF está asociada a una PF del dispositivo físico, aunque el host no va a usar las VF. Las VF se usan solo por las VMs. Un dispositivo físico puede exponer varias PF (una tarjeta de red multipuerto) cada una con su set de VFs.

Las VF son recursos hardware, no software. Con SR-IOV, una parte del adaptador hardware (la VF) es expuesto a la máquina virtual, lo que implica instalar un driver del fabricante en la VM.

Esto permite a las VM disponer de una ruta directa con la tarjeta de red física para el intercambio de datos, reduciendo la sobrecarga de la CPU, mejorando el rendimiento.

Es necesario que el chipset soporte remapeado de IRQ y DMA (vt-d), y también que permita asignar a la VM las VF del adaptador.

Resource Metering

Windows Server 2012 introduce Medición de Recursos, una tecnología que permite hacer seguimiento del uso en el tiempo de las VM.

Los datos obtenidos se pueden usar para planear capacidades, monitorizar el consumo de departamentos o personas, redistribuir los costes de ejecución de trabajos. También se puede aprovechar para realizar una facturación a los clientes en función del consumo de recursos.

Dynamic Virtual Machine Queue

Virtual Machine Queue (VMQ) es una característica disponible en equipos que tengan hardware de red compatible VMQ. VMQ usa un filtrado de paquetes por hardware para enviar paquetes de una red externa directamente a las MV, lo que reduce la sobrecarga de enrutar paquetes y copiarlos desde el sistema operativo del host a la máquina virtual. Con VMQ se establece una cola dedicada en el adaptador de red físico para cada adaptador de red virtual que lo solicita. Cuando llegan paquetes para un adaptador de red virtual, el adaptador de red físico los coloca en la cola particular de ese adaptador virtual, para después transferirlos directamente al citado adaptador virtual.

Los paquetes que llegan para adaptadores que no tienen una cola dedicada, igual que todos los multicast y broadcast, se envían al switch virtual a través de la cola por defecto. Éste enruta los paquetes al adaptador virtual de red como haría normalmente.

Quality of Service (QoS, Calidad de Servicio)

QoS es un conjunto de tecnologías presentes desde hace tiempo en Windows para administrar el tráfico de red de forma eficiente, para mejorar la experiencia de usuario en entornos empresariales, así como en casa y pequeñas oficinas. QoS permite medir el ancho de banda, detectar condiciones de red cambiantes (como congestión o disponibilidad del ancho de banda) y priorizar o acelerar el tráfico. Por ejemplo, se puede usar QoS para priorizar el tráfico de aplicaciones sensibles a la latencia (como las de voz o video) y controlar el impacto de tráfico no sensible a la misma (como una transferencia de datos).

En Windows Server 2012 QoS se ha diseñado para ayudar a administrar el tráfico de red tanto en la red física como en las redes virtuales, designándose como Hyper-V QoS a la nueva funcionalidad dedicada a administrar el tráfico en estas últimas.

SMB Direct y Multicanal

SMB Multicanal permite la agregación de ancho de banda y tolerancia a fallos de la red si se dispone de múltiples rutas entre clientes SMB 3.0 y el servidor SMB 3.0. Esto permite a las aplicaciones servidor aprovechar al máximo el ancho de banda de la red y ser resistente a fallos de red.

SMB Direct soporta el uso de adaptadores de red que tienen capacidad RDMA y pueden funcionar a su máxima velocidad con una latencia muy pequeña y usando muy pocos recursos de CPU. Para servicios como Hyper-V o SQL Server, esto permite que un servidor remoto de ficheros parezca almacenamiento local.

Categories: Server 2012 Tags:

Mejoras de la Red en Server 2012 – I

martes, 4 de junio de 2013 Comments off

Las capacidades de red de Windows Server 2012 tienen muchas características nuevas y mejoras a las ya existentes. Vamos a ver algunas de ellas

NIC Teaming

El Teaming de tarjetas de red permite aumentar el ancho de banda, al tiempo que se protegen los servicios alojados en el servidor de interrupciones de red o de hardware. Además de ser independiente del vendedor, las capacidades de teaming de Server 2012 están integradas completamente en el Sistema operativo, por lo que no se requiere la instalación de software o drivers especiales, y además todos los teams creados se administran desde la misma herramienta.

Virtualización de Redes

La virtualización de redes extiende el concepto de virtualización de servidores para permitir múltiples redes virtuales, potencialmente con direcciones ip similares, desplegadas en la misma red física. Con Virtualización de redes Hyper-V se puede aislar el tráfico en una red virtual dedicada, independientemente de la infraestructura física, para obtener una experiencia multicliente segura y aislada.

La virtualización de redes también proporciona portabilidad de direcciones ip y la posibilidad de mover máquinas virtuales entre subredes físicas sin cambiar el espacio de direcciones. Las máquinas virtuales movidas pueden mantener su dirección ip aunque se cambien de servidor host, rack, edificio o ciudad, e incluso si se mueven aun hosting en la nube. Ya no es necesario reconfigurar complejas VLANs o cambiar el espacio de direcciones para adaptarse al entorno de destino.

DHCP server failover (réplica de DHCP)

Windows Server 2012 soporta los estándares de failover DHCP especificados en el Internet Engineering Task Force (IETF) Internet Draft.

Mediante este protocolo, la réplica de dos servidores DHCPv4 para sincronizar la información de concesión de direcciones de forma prácticamente instantánea y proporcionar alta disponibilidad del servicio DHCP sin necesidad de cluster. Si uno de los servidores cae, el otro asume la responsabilidad para servir a los clientes de la misma subred.

IP Address Management (IPAM)

IPAM en Windows Server 2012 es una herramienta nueva para descubrir, monitorizar, auditar y administrar el espacio de direcciones IP usado en una red corporativa. IPAM permite administrar y monitorizar servidores DHCP y DNS, e incluye componentes para:

  • Descubrimiento automático de la infraestructura IP: IPAM descubre DCs, servidores DHCP y DNS en los dominios seleccionados, permitiendo seleccionar que servidores se administran o no.
  • Administración, Informes y exposición del espacio de direcciones, altamente personalizable, así como seguimiento detallado del uso de datos IP. Los espacios de direcciones IPv4 e IPv6 se organizan en bloques de direcciones IP, rangos y direcciones individuales, permitiendo usar campos predefinidos o definidos por el usuario para posteriormente organizar el espacio en grupos jerárquicos o lógicos.
  • Auditoría de cambios en la configuración de servidores y seguimiento del uso de direcciones IP, mostrando los eventos en el servidor IPAM, en conjunto con datos de usuario, máquina e IP obtenidos de servidores DHCP, DCs y Network Policy Servers (NPS)
  • Monitorización y administración de la disponibilidad de los servicios DNS y DHCP en todo el bosque, mostrando la salud de las zonas DNS y permitiendo administrar de forma detallada los servidores y ámbitos DHCP desde la consola IPAM

BranchCache

Branchcache, disponible desde 2008 R2, es una tecnología de optimización del ancho de banda WAN. Para optimizar este ancho de banda WAN cuando los usuarios acceden a contenido en servidores remotos, Branchcache copia el contenido de la sede principal o servidores alojados en la nube y cachea el contenido en las sucursales, permitiendo a los equipos de los clientes de las sucursales acceder al contenido cacheado localmente en lugar de remotamente a través de la WAN.

En las sucursales, el contenido se almacena en servidores configurados para alojar la cache (2012 ó 2008R2), o si no hay servidores disponibles, en clientes que ejecuten Windows 8 ó Windows 7. Una vez que un cliente solicita y recibe contenido desde la sede remota y éste se aloja en la cache de la sucursal, otros equipos de la misma sucursal pueden obtener el contenido localmente en lugar de volver a descargarlo a través de la WAN.

En posteriores solicitudes para el mismo contenido, el cliente descarga del servidor remoto “content information” en lugar del contenido completo. Esta información de contenido consiste en hashes que se calculan usando “chunks” del contenido original, y son muchísimo más pequeños que el contenido cacheado en el servidor Branchoffice. Este mecanismo, además mejora la seguridad ante el posible acceso a los datos de usuarios no autorizados.

Branchcache mejora la productividad al mejorar los tiempos de respuesta a los clientes y servidores en las sucursales, y mejora el rendimiento de la red al reducir el tráfico a través de enlaces WAN.

 

Categories: Server 2012 Tags:

Evento 6 de junio en Barcelona. Virtualización en Windows Server

viernes, 24 de mayo de 2013 Comments off

Javier Sánchez (MVP de Virtual Machine) está organizando un evento en Barberá del Vallés (Barcelona) sobre virtualización con Citrix y Windows Server, con participación de Microsoft, para el próximo 6 de Junio. Cuenta con un auditorio espectacular, con capacidad para 300 personas, y promete ser de lo más interesante.

Para participar os podéis registrar desde la siguiente dirección:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032552873&Culture=es-ES&community=0

 

Categories: Server 2012 Tags:

Server Core vs MinShell

martes, 18 de diciembre de 2012 Comments off

Otra de las cosas que se resisten a muchos administradores es la instalación de servidores en modo Core, opción disponible desde Windows Server 2008. Como ya he comentado en otro post, a muchos administradores les da pavor la línea de comandos, y buscan en el entorno gráfico toda la administración de sus equipos.

Sin embargo, el hecho de tener un entorno gráfico (GUI, Graphical User Interface) instalado en la máquina, junto con su escritorio con el explorador, barra de tareas y área de notificación, Internet Explorer, etc., no solo supone una sobrecarga generalmente innecesaria en el uso de los recursos del equipo, sino que además nos va a suponer un trabajo adicional de parcheado para evitar vulnerabilidades y fallos diversos; a más software instalado en un servidor, vamos a obtener más posibilidades de problemas y menor rendimiento.

Pero si además nos ponemos en un entorno virtualizado, necesitamos que nuestras máquinas virtuales consuman la menor cantidad de recursos posible, y ahí es donde entra en juego las versiones Core. Si no necesitamos las funcionalidades que nos da un GUI completo (y generalmente tras la instalación inicial ya no las vamos a usar), ¿para qué tenerlas gastando recursos? Todo lo que nos ahorremos redundará en más recursos disponibles para el host y resto de máquinas virtuales.

Y ahí es donde entra Windows Server 2012. ¿Quién no ha corrido a instalar un Server 2012 y cuando se ha dado cuenta se le ha instalado un Server Core? Ahora es la opción que muestra por defecto la instalación del servidor, y está hecho así a propósito, de tal forma que seamos nosotros los que elijamos la instalación con GUI si de verdad la necesitamos.

Con Server 2012 ha aumentado el número de roles de servidor que funcionan en Server Core, y se incluye por defecto soporte para aplicaciones que use .NET Framework 4.5. De hecho, también podemos instalar un SQL Server 2012 en modo Core.

Seguimos teniendo el comando sconfig para realizar la configuración inicial, y asignar de forma sencilla nombre y configuración IP, así como unirlo a un dominio y otras tareas básicas, tal como podemos ver en la siguiente figura.

sconfig

Por otro lado, Server Core tiene habilitada por defecto la administración remota (WinRM) y PowerShell, por lo que en cuanto tenga conectividad IP podremos directamente administrar de forma remota el servidor. Esto quiere decir que si añadimos un Server Core a la consola del Administrador del Servidor de nuestro equipo de administración, podremos administrar y configurar prácticamente totalmente nuestro servidor Core remoto sin necesidad de entrar en su consola para nada.

Pero una de las novedades más interesantes en este área de Windows Server 2012 es que en cualquier momento podemos cambiar de un Server Core a un servidor con GUI de forma sencilla y sin necesidad de reinstalar el servidor, del mismo modo que podemos hacer la operación inversa. Además, Windows Server 2012 nos ofrece un paso intermedio, el MinShell, que nos facilitará en cierto modo la administración si nos conectamos a la consola del equipo.

MinShell (Minimal Server Interface) es una solución intermedia entre un Server Core y un servidor con GUI en el que conjugamos el ahorro de recursos que nos proporciona el Core con la facilidad que nos proporcionan las herramientas de administración gráficas. MinShell habilita la mayor parte de las herramientas gráficas, incluida la mmc, sin necesidad de tener cargado el Shell gráfico completo.

Básicamente, el MinShell es una instalación de servidor completa al que se le quita lo siguiente:

  • Internet Explorer
  • Los componentes del Shell de Windows, como el escritorio y barra de tareas
  • El Explorador de Windows
  • La experiencia de usuario y multimedia
  • Soporte de aplicaciones Modernas (Metro), ni la pantalla de inicio.

O si lo queremos ver de otro modo, es un Server Core al que le hemos añadido el Administrador del Servidor, la mmc con las herramientas administrativas y algunas applets del panel de control.

Podemos pasar un servidor a MinShell añadiendo características desde un Core o quitándoselas a un servidor con GUI, y lo podemos hacer desde el asistente de Roles y Características o con PowerShell:

   > Install-WindowsFeature Server-Gui-Mgmt-Infra

 

Categories: Server 2012 Tags:

PowerShell 3 en Windows 8 y Server 2012

domingo, 16 de diciembre de 2012 Comments off

Hace unos días pregunté a los asistentes a una conferencia cuántos de ellos, IT pros la mayoría, usaban PowerShell en sus tareas de administración. No me llevé mucha sorpresa cuando ninguno levantó la mano, lo que me llevó a preguntarme el por qué;  la respuesta podría ser el miedo a lo desconocido, la comodidad de usar una herramienta gráfica en lugar de la línea de comandos. Y la verdad es que los administradores de más edad son mucho más abiertos a usar scripts y la línea de comandos que los más noveles.

Para ayudar a cambiar esta situación, PowerShell 3.0, la versión incluida en Windows 8 y Server 2012 trae muchísimas mejoras, gran parte de las mismas enfocadas a facilitar la curva de aprendizaje de los administradores que se acercan por primera vez a este lenguaje. Y me han sorprendido gratamente sus nuevas funcionalidades y mejoras de otras existentes que hacen que el trabajo con PowerShell se haga más cómodo que nunca.

Además de la propia ventana de comandos de PowerShell, tenemos una nueva versión del ISE (Integrated Script Environment), que hará las delicias de más de uno.

ISE 3.0 proporciona, además de la ventana de línea de comando, un panel de scripts donde podemos editar los mismos, y en ambas disponemos ahora de la funcionalidad “Intellisense”, que nos va a mostrar información sensible al contexto sobre los comandos que estamos escribiendo, permitiéndonos completarlos con los parámetros, propiedades y funciones que nos va proponiendo mediante listas desplegables que aparecen automáticamente. Además, tiene facilidades para la edición como la numeración de líneas y las regiones de código que se pueden contraer y expandir a voluntad.

También tiene la posibilidad de añadir estructuras de código predefinidas, pulsando la combinación de teclas CTRL-J, tanto para las estructuras de control clásicas (for, if, do-while,…) como para los nuevos “Workflows” de los que hablaré más adelante.

También se incluye a la derecha un panel de comandos, donde podemos consultar todos los disponibles (más de 2400 en esta versión), viendo sus parámetros y con la posibilidad de preparar de forma gráfica y sencilla el comando e insertarlo en nuestro código una vez completado, o ejecutarlo directamente en la ventana de comandos inferior.

ISE3.0

Una opción añadida de lo más interesante está en el menú Complementos – Abrir sitio web de herramientas de complemento, que nos lleva a una página en la que podemos encontrar diversos packs añadidos por la comunidad que proporcionan funcionalidad adicional a nuestro sistema, y en particular y proporcionada por Microsoft, el Script Explorer, que una vez instalado, nos da acceso a multitud de scripts y funciones de ejemplo, clasificadas por temas, que son totalmente funcionales, y que podemos adaptar a nuestras necesidades para a su vez construir nuestros propios scripts.

ScriptExplorer

Por lo que respecta al lenguaje en sí, PowerShell 3.0 incluye más de 2.400 cmdlets, en un total de 239 módulos, y que contemplan la mayoría de funcionalidades de Windows Server (Networking, Active Directory, Seguridad, DHCP, DNS, etc). Además, ya no es necesario cargar un módulo para usar los cmdlets definidos en el mismo, sino que se carga automáticamente al ejecutar el cmdlet.

La ayuda de PowerShell no está disponible al principio, salvo una ayuda básica que enumera los parámetros de cada comando. Para obtener la ayuda completa y actualizada se usa el comando Update-Help desde un equipo conectado a Internet. Este comando descarga la ayuda al equipo local, donde la podemos guardar posteriormente en una carpeta compartida con el comando Save-Help, de tal forma que después podremos ejecutar en otros ordenadores de nuestra red el comando Update-Help -SourcePath para descargar los archivos de ayuda desde esa carpeta compartida en lugar de desde Internet.

 Para facilitar la búsqueda de comandos disponemos del comando Get-Command, al que pasándole como parámetro el texto a buscar (incluyendo wildcards) nos va a mostrar la lista de comandos que cumplen con la expresión.

> Get-Command *-Net*

Una vez localizado el comando buscado, con Get-Help obtendremos ayuda detallada sobre el mismo.

> Get-Help  Disable-NetAdapter

Por fin, desde la ventana de comando de PowerShell también podemos acceder al panel de comandos (similar al del ISE), desde donde podemos rellenar y lanzar cualquier comando, salvo con la diferencia de que no podemos mantenerlo abierto constantemente, pues es necesario cerrarlo para poder continuar en la ventana de comando.

> Show-Command

En cuanto a mejoras del lenguaje, a los ya conocidos cmdlets, scripts y funciones, se añaden ahora los Workflows, que no son otra cosa que scripts preparados para ejecutarse durante largo tiempo y obtener información o realizar acciones en unos pocos o en cientos de equipos. Además, sus actividades (así se llaman los grupos de código que componen el Workflow) se pueden ejecutar en serie o de forma paralela, y si es necesario reiniciar un equipo durante la ejecución del Worlflow, éste puede esperar a que el equipo arranque, o a que tras el arranque esté disponible Windows PowerShell, la red o un servicio en particular, para continuar la ejecución del Workflow.

Otra de las nuevas características de PowerShell 3 es la Conectividad Robusta de Sesiones, que permite que una conexión PowerShell remota permanezca en estado de conexión durante pequeñas pérdidas de conectividad de red, hasta cuatro minutos. Los comandos continúan ejecutándose en el equipo de destino, y la sesión puede ser recuperada desde el mismo equipo (de forma automática o manual si se ha reiniciado el mismo) o desde otro equipo diferente. Si se sobrepasan los cuatro minutos sin que se haya restablecido la conectividad, la ejecución de comandos se suspende sin pérdida de datos y la sesión remota pasa a un estado desconectado, pudiéndose reconectar una vez restablecida la conectividad.

También se ha añadido nueva funcionalidad para realizar una programación avanzada para ejecución de scripts, mediante el uso de desencadenadores (triggers) para definir la periodicidad o causalidad de ejecución de los scripts (a una hora, diario, al inicio del equipo, etc).

Por fin, también como novedad disponemos de la característica “PowerShell Web Access”, instalable desde el asistente de roles y características, que nos va a permitir en el equipo en que la hayamos instalado publicar una página web desde la que tendremos acceso mediante PowerShell remoto a otros equipos de nuestra red. El escenario típico para usar esta característica es instalar este servidor en nuestra red perimetral, de tal forma que un usuario con los permisos adecuados pueda acceder a esa página PowerShell Web Access desde Internet, y a través de la misma administrar mediante PowerShell equipos de nuestra red interna.

Como hemos visto en este pequeño baño, PowerShell 3 incluye numerosas funcionalidades, gran parte de ellas encaminadas a hacer que los administradores se familiaricen con el lenguaje y se acostumbren a usarlo.

Categories: Server 2012, Windows 8 Tags:

El nuevo Administrador del Servidor de Server 2012

sábado, 15 de diciembre de 2012 Comments off

La administración de Windows Server tiene muchas características nuevas, así como mejoras sustanciales a otras ya existentes en versiones anteriores. El nuevo Administrador del Servidor (Server Manager) ha pasado de ser una herramienta útil prácticamente para la configuración inicial del servidor, a ser un punto centralizado de administración y seguimiento de todos los servidores de nuestra empresa u organización.

Una gran diferencia del nuevo Administrador del Servidor respecto del de Server 2008 R2 es que, mientras que éste está diseñado con un enfoque de conexión a un servidor, y entonces configuramos sus roles y características, el Administrador de Servidor de Windows Server 2012, sin perder la posibilidad de seguir usando este enfoque, usa por defecto un enfoque por rol, mostrándonos para cada tipo de rol el estado de cada uno de los servidores en que lo tengamos instalado. La ventaja de este nuevo diseño es que, en función de nuestras necesidades en cada momento, podemos usar una u otra forma de trabajar, siempre a nuestro gusto.

Hasta ahora, si queríamos administrar otros servidores, o nos conectábamos directamente a la consola del servidor, o establecíamos una conexión RDP al mismo, y trabajábamos en la sesión remota. Ahora con Windows Server 2012, esto ya no es necesario. En cualquier momento podemos añadir a nuestro Administrador del Servidor otros servidores de nuestra empresa, y automáticamente pasan a estar administrados desde nuestra consola, sin necesidad de establecer conexiones remotas.

Por otro lado, una vez hayamos añadido los distintos equipos a nuestro Administrador del Servidor, éste nos da la posibilidad de definir grupos de servidores, de tal forma que además de las distintas vistas por roles instalados, podemos ver así mismo nuestros equipos organizados según la estructura de nuestra empresa, ubicación física, sistema operativo o cualquier otro criterio que se ajuste a nuestras necesidades.

Otra novedad que nos ofrece es el nuevo asistente de instalación de roles y características, que ahora ya no se instalan por separado, sino que el mismo asistente nos permite configurar roles y características en un solo paso. Además, podemos realizar esta instalación no sólo en un servidor de los que tenemos conectados, sino también en un disco virtual sin necesidad de poner la máquina virtual online. El asistente tiene una apariencia muy similar a la que ya hemos visto en sistemas operativos anteriores, pero las modificaciones en este caso van por dentro. Para poder soportar esta instalación en discos vhd o vhdx, el asistente omite parte de la configuración realizada durante el propio asistente para que se ejecute una vez levantamos la máquina virtual.

Por otro lado, desde el Administrador del Servidor vamos a tener acceso a todo tipo de herramientas administrativas necesarias para administrar nuestros servidores.  Bien de forma contextual o desde el menú superior podemos lanzar las mismas para administrar cualquiera de los servidores conectados con el rol correspondiente.

En la siguiente figura podemos ver la pantalla principal del Administrador del Servidor, en la que podemos observar como el panel izquierdo está dispuesto por roles, de tal forma que al pinchar en cada uno de ellos veremos a la derecha información de estado referente a los servidores administrados que tengan instalado ese rol. El panel derecho, además de darnos acceso directo a las tareas de agregar servidores que administrar (de 2003 en adelante), crear grupos de servidores y lanzar el asistente de instalación de roles y características, nos muestra de forma resumida el estado por roles de todos los servidores administrados, y como podemos ver en rojo en la imagen, si en alguno de ellos se ha producido algún error o si está requiriendo atención para realizar alguna acción sobre el mismo.

ServerManager

En las siguientes imágenes vemos como al seleccionar un rol o un grupo de servidores (en este caso el grupo “Infraestructura para SharePoint”) nos muestra a la derecha gran cantidad de información, sobre el estado de los mismos (no olvidéis desde el nombre del servidor iniciar los contadores de rendimiento), eventos producidos en los servidores seleccionados, estado de los servicios, resultados del analizador de procedimientos recomendados que podemos ejecutar desde allí mismo, gráficos de rendimiento de los servidores y un resumen de los roles y características instalados.

ServerManagerGrupoInfraSharepoint

ServerManagerGrupoInfraSharepoint2

En resumen, si antes gran parte de los administradores usaban el administrador del servidor tan solo para la configuración inicial del equipo y poco más, deshabilitando a continuación el arranque automático de la aplicación, ahora vemos que el valor añadido que se le ha incorporado va a hacer las delicias de más de uno, por el grado de centralización de la administración que nos proporciona.

 Por otro lado, aunque se pueden instalar en un cliente las herramientas administrativas, no vamos a poder disponer de parte de las funcionalidades, como la instalación de roles y características desde el equipo de administración, por lo que es más que recomendable seleccionar un servidor Windows Server 2012 como equipo de administración con la consola del Administrador del Servidor y configurarla para que administre todos los servidores de nuestra organización.

Categories: Server 2012 Tags:

Windows Server 2012 Community Roadshow en Sevilla

jueves, 13 de diciembre de 2012 Comments off

El 12 de diciembre se ha celebrado en Sevilla el Windows Server 2012 Community Roadshow, en el que dos MVPs, Marc Rubiño y un servidor, hemos hecho una presentación de las principales características del nuevo servidor de Microsoft.La jornada ha tenido lugar en el Clouding Point de Microsoft en Sevilla, a lo largo de toda la mañana del jueves, y se han realizado las siguientes presentaciones:

– Managing your Core Infraestructure (MVP José Antonio Quílez)

– Web and Application Platform (MVP Marc Rubiño)

– Server Virtualization (MVP José Antonio Quílez)

En próximas fechas se van a realizar más eventos del Roadshow de Windows Server 2012 en otras ciudades de España. Si estáis interesados podéis verlos en el siguiente enlace:

http://ws2012rocks.msregistration.com/Default.aspx

Categories: Server 2012 Tags: