Las instalaciones por defecto de IIS7 tienen desactivada la visualización de errores por pantalla para ASP (Classic ASP) y en su defecto muestran un mensaje genérico, el siguiente:

An error occurred on the server when processing the URL. Please contact the system administrator

Tenemos dos opciones para cambiar este comportamiento y poder activar temporal o permanentemente el debug por pantalla. La forma rápida es desde línea de comandos:

Activar DEBUG ASP:

%windir%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:true

Desactivar DEBUG ASP:

%windir%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:false

La otra opción es desde el IIS Manager, donde podremos hacerlo tanto de forma general para todos los sites o para uno en concreto. Para ello accedemos a la sección ASP y editamos el mensaje de error genérico o activamos el debug, son los parámetros scriptErrorMessage y scriptErrorSentToBrowser respectivamente.

Imágenes sacadas de learn.iis.net

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 ;)

Para bloquear el acceso a un sitio web en IIS a una determinada IP o rango debemos acceder a la gestión de IIS a través del Internet Information Services Manager, expandir los Web Sites y pinchar en propiedades del que queramos gestionar. Una vez dentro de la gestión, accedemos a la pestaña Directory Security y pinchamos editar en la sección “Grant Or deny access to this resource using IP addresses or Domains names“.

Una vez dentro ya podemos visualizar configurar el comportamiento por defecto (permitir o denegar acceso a todo el mundo) y las excepciones:

Aquí es donde podemos añadir nombres de dominio, rangos e IPs tanto para denegar acceso como permitir (según la configuración por defecto establecida).

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