Una vez que creamos un Web  Site en IIS, tenemos la opción de crear directorios virtuales (Virtual Directory) o aplicaciones (Application). Vamos a ver las diferencias más significativas entre ambos y cuando elegir uno u otro.

Directorio virtual (Virtual directory)

Comenzamos con el directorio virtual ya que es más simple que una aplicación. Básicamente un directorio virtual es un mapeo a una ruta local del servidor o remota en un directorio de nuestro website. Un ejemplo:

• Web Site: test.com (c:\inetpub\test.com\wwwroot)
• Virtual Directory: /test
• Mapeado a c:\test

En este ejemplo, cuando accedamos a www.test.com/test, en lugar de ir a su ruta lógica si no estuviera el directorio virtual creado, que sería c:\inetpub\test.com\wwwroot\test, accedemos a c:\test, gracias al mapeo del virtual directory. Esta es la característica principal del DV. A diferencia de lo que veremos a continuación con la aplicación, el directorio virtual se sirve a través del mismo application pool que el Web Site, y hereda por ello todas sus configuraciones a nivel de aplicación.

Aplicación (Application)

Las diferencias con el Virtual Directory ya se intuyen. Cuando conviertes un directorio en aplicación, permites que se ejecute con un application pool independiente al del website. Esto permite añadir un mayor nivel de personalización, de seguridad y de configuración. Respecto a la configuración, por ejemplo es muy útil en ASP.NET, ya que se buscará el web.config en esta ruta en lugar de en el raíz del Web Site. Podríamos considerar entonces el directorio virtual un mero puntero/mapeo a una ruta de almacenamiento, la aplicación por contra permite aislar del resto del Web Site las aplicaciones que lo contienen.

A groso modo esta es la explicación más básica de las diferencias entre ambos, cualquier puntualización será bienvenida, no soy para nada un experto en IIS ;)

Habilitar los certificados de cliente a nivel de website permite que aquel que conecte al sitio web necesite la utilización de un certificado seguro para poder acceder. De este modo podremos proteger los accesos al sitio web y sus recursos frente a accesos no deseados y permitir especificamente a un grupo concreto el acceso.

En este caso los vamos a activar a nivel de website, de modo que accederemos a la consola de gestión de IIS (Internet Information Services Manager) y desplegaremos el servidor local, después Web Sites y pincharemos con el botón derecho en el website a configurar seleccionando Properties. Una vez dentro accederemos a la pestaña “Directory Security” y pincharemos en “Edit” dentro de la sección de comunicaciones seguras (Secure Communications).

Una vez dentro encontraremos las siguientes opciones. Lo primero que debemos activar es el requerimiento de un canal seguro SSL (Require Secure Channel SSL). De este modo forzamos al usuario a conectar vía HTTPS. Posteriormente podemos configurar si habilitamos los certificados de cliente o si obligamos a usarlo. La última opción forzará al usuario a utilizarlo mientras que la segunda lo permitirá. Finalmente podemos habilitar una lista de certificados de confianza (Enable Certificate Trust List) a la cual podremos añadir los certificados a utilizar para la comunicación con el cliente, certificados CA intermedios, etc.

Finalmente reiniciamos el website y ya debería estar habilitada la funcionalidad de certificados de cliente.

Microsoft Web Platform Installer 2.0 es una aplicación disponible desde el sitio web de Microsoft a través de la cual podemos descargar, instalar y actualizar los componentes diferentes componentes que componen el entorno de un servidor web Windows.

Actualmente, este programa, que se ejecuta como un asistente en el cual solo hay que marcar lo que queremos instalar, permite la instalación de la última versión estable de PHP, Internet Information Services 7.5 (IIS), aplicaciones creadas en asp.net o php como WordPress o Drupal, SQL Server, Visual Web Developer, etc.

Únicamente hay que descargar la aplicación, que pesa 1MB y ejecutarla en el equipo. Seleccionamos lo que queremos instalar y automáticamente será descargado en instalado.

Descarga Microsoft Web Platform Installer 2.0.

Sistemas Operativos compatibles: Windows 7, Windows Vista, Windows Vista SP1, Windows XP SP2+, Windows Server 2003 SP1+, Windows Server 2008, Windows Server 2008 R2.

Activar la compresión HTTP en IIS 6.0 permite optimizar y reducir el uso de ancho de banda del servidor y acelerar la carga de los sitios web. Es posible comprimir tanto contenido estático como dinámico.

Lo que sucederá al activar la compresión, es que las páginas cacheadas y comprimidas se almacenarán en un directorio temporal y se servirán desde ahí. Para activarlo (tenemos que ser administrador) hacemos lo siguiente:

1) Accedemos a la administración de IIS (IIS Manager)
2) Desplegamos el servidor (local computer), y pinchamos con el botón derecho en “Web Sites”, una vez dentro, accedemos a la pestaña “Services”:

En la imagen se puede ver la posibilidad de activar la compresión para ficheros estáticos, ficheros de aplicación y especificar el directorio temporal así como su tamaño máximo.

Guardamos los cambios y la compresión quedará activada, podremos ver como el directorio temporal comienza a almacenar ficheros.

Vamos a ver como realizar una redirección tipo 301 (Página movida permanentemente) para un sitio web alojado en un servidor con IIS (Internet Information Services) corriendo.

Necesitamos acceso por Terminal Service al servidor en el que tenemos el sitio web alojado. Una vez dentro accederemos a “Internet Services Manager” para modificar el website:

Start -> Programs -> Administrative Tools -> Internet Services Manager
Inicio -> Programas -> Herramientas administrativas -> Administrador de Internet Information Services (IIS)

Una vez dentro accedemos al servidor pinchando en él (normalmente local computer) y después pinchamos en websites. Ahora tendremos todos los websites que hay configurados en ese servidor. Pinchamos con botón derecho sobre el que nos interese y pinchamos en “Propiedades“.

Ahora, en la sección “Home Directory“, tenemos que seleccionar “A redirection to a URL” o “Redirección a una URL”. En el cuadro de texto escribimos la URL de destino para la redirección 301 y nos aseguramos de pinchar en “A permanent Redirection for this resource“. Esta última opción es la que configurará el 301.

Ahora solamente queda guardar y reiniciar el website para que los cambios refresquen. Esta sería una redirección básica 301. IIS permite también redirigir páginas individuales del website o pasar variables como haríamos con mod_rewrite y apache. Esto lo veremos en otra entrada.

En IIS (Internet Information Services) tenemos la opción de importar y exportar Web Sites, o lo que es lo mismo, sus configuraciones. Esto es muy útil para migraciones entre distintas máquinas y evitar tener que configurar a mano de nuevo cada uno de los Web Sites que compongan nuestro servidor Web.

El proceso es muy sencillo, abrimos el Internet Information Services (IIS) Manager, pinchamos en la sección de Web Sites y clickamos con el botón derecho en el Web Site que queramos exportar. All Tasks –> Save Configuration To a File…

Y eso es todo, para hacer la tarea inversa simplemente accederemos también al IIS Manager, pincharemos en Web Sites con el botón derecho, y clickaremos en New –> Web Site (From File) para importarlo en nuestro servidor.

Seguimos con las comprobaciones a través de TELNET de los diferentes servicios que nos encontramos normalmente en un servidor. Ayer vimos como hacer pruebas contra un servidor SMTP, y hoy vamos a hacerlo contra un servidor web, concretamente contra un servidor web bajo Apache y otro bajo IIS, aunque el modo de operar es el mismo y muy sencillo.

Simplemente conectamos al servidor/host vía TELNET a través del puerto 80:

$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to www.apache.org.
Escape character is '^]'.

Ya estamos dentro, lo que es una buena señal, ahora vamos a lanzar una petición HTTP (HTTP/1.0, HTTP/1.1) en la que solicitamos solamente las cabeceras (HEAD) de la misma. Si quisieramos solicitar el documento completo en vez de HEAD utilizaríamos GET.

Nota: Hay que presionar ENTER dos veces tras escribir la petición HEAD/GET:

Ejemplo de un servidor Apache con respuesta correcta:

$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to www.apache.org.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 02 Oct 2009 09:26:01 GMT
Server: Apache/2.2.12 (Unix) mod_fcgid/2.3.2-dev
Last-Modified: Mon, 03 Aug 2009 13:41:54 GMT
ETag: "700a74-4e05-4703ceed30c80"
Accept-Ranges: bytes
Content-Length: 19973
Cache-Control: max-age=86400
Expires: Sat, 03 Oct 2009 09:26:01 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Ejemplo de un servidor IIS con respuesta correcta:

$ telnet www.microsoft.com 80
Trying 207.46.192.254...
Connected to lb1.www.ms.akadns.net.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 1020
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "67991fbd76a6c91:0"
Server: Microsoft-IIS/7.5
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Fri, 02 Oct 2009 09:27:36 GMT
Connection: keep-alive

Es posible que tengáis un servidor Windows 2003 server con IIS funcionando correctamente, los websites ejecutan sin problemas php o perl, pero en el momento que aislamos un website (Application Pool Isolation) tanto PERL como PHP dejan de funcionar, dando normalmente el siguiente error:

HTTP Error 403 – Forbidden: Access is denied

Este problema es debido a que cada identidad de application pool (usuario configurado en la aplicación para ejecución de scripts, php, etc) debe ser miembro del grupo IIS_WPG de modo que nos aseguremos que tenga permisos para ejecutar php o perl.

Realizaremos las siguientes modificaciones en las políticas de seguridad para solventar el problema, iremos a:

START > Administrative Tools > Local Security Policy

Seleccionamost Local Policies > User Rights Assignment

En el listado que aparezca, buscamos Adjust memory quotas for a process y pinchamos en las propiedades. Posteriormente Add User or Group > Object Types marcando la casilla de  Groups y OK the Object Types dialogue. Ahora en la ventana Enter the object names to select introduce IIS_WPG y pincha OK.

El mismo proceso debe ser ejecutado en Replace a process level token. Reiniciaremos la máquina y ya debería funcionar correctamente. Todos los miembros de IIS_WPG pueden ejecutar aplicaciones CGI sin problemas.

Vía | Asimo Support