Host-named SiteCollections

En esta ocasión quiero hablar un poco acerca de los Host-Named SiteCollections (ó host-headers sitecollections). Que son, para que se utilizan, cuando no usarlos y como crearlos.

¿Que son los Host-Named SiteCollections?

Es la capacidad que brinda la infraestructura de SharePoint para crear SiteCollections, con lo que los amigos norteamericanos gustan nombrar como “vanity urls”. Es decir la capacidad de crear SiteCollections con un host-header personalizado e independiente de la url de la aplicación web, por ejemplo, consideremos las siguientes urls de sitecollections.

http://sales.contoso.com/
http://team.development.com/
http://research/

Si intentáramos utilizar el método de Path-based SiteCollection para formar estas urls, no nos quedaría más remedio que crear cada uno de estos sitecollection en una web application diferente para permitir que cada sitecollection tenga la url que se requiere.

¿Qué problema resuelven los Host-Named SiteCollections?

Gracias a esta característica podemos crear sitecollections con las urls que antes vimos, y todas vivir en una misma web application, sin necesidad de crear una web application independiente solo para resolver el tema de la url.

¿Para qué se utilizan los Host-Named SiteCollections?

Como comentamos antes, el uso principal es proveer la habilidad de nombrar sitecollections con una url que no tiene que ver en nada con la url de la web application en la cual vive.

Tiene un uso muy extendido en el área de hosting empresarial, o sea las empresas que se dedican a proveer hospedaje de sitios SharePoint, y es que, por medio de esta característica pueden construir una solución altamente escalable, ya que basta con crear una sitecollection con una url específica y asignar esa url a una entrada particular en sus DNS’s.

Otro uso es claramente, cuando una organización quiere dar identidad propia a cada una de sus áreas y/o suborganizaciones, y esto lo refleja en cada uno de los sitios de las mismas, que no solo tienen un aspecto visual distinto sino también una url única y acorde a sus funciones.

¿Cómo crear Host-Named SiteCollections?

Al igual que en la versión anterior, solo se pueden crear host-named sitecollections a través scripting, para generar los sitecollections antes mencionados podemos usar el siguiente script de ejemplo.

$web=Get-SPWebApplication http://sp2010:5300/

New-SPSite "http://sales.contoso.com" -OwnerAlias "moss\administrator" -HostHeaderWebApplication $web -Template "STS#0"

New-SPSite "http://team.development.com" -OwnerAlias "moss\administrator" -HostHeaderWebApplication $web -Template "STS#0"

New-SPSite "http://research" -OwnerAlias "moss\administrator" -HostHeaderWebApplication $web -Template "STS#0"

Ventajas y Desventajas

Como un buen amigo dice, todo siempre es un trade-off, y este tema no sería la excepción. Algunas de las desventajas de usar esta características versus usar el tradicional path-based sitecollections son:

Desventajas

• No soportan AAM (Alternate Access mappings)
• Se consideran siempre en la zona Default, por lo que no pueden responder a dos o más urls diferentes.

Ventajas:

• Alta escabilidad en soluciones de hosting
• Url personalizadas

Mención especial merece el hecho de que, por residir varios sitecollections en una misma web application, se comparte el web.config, esto es una ventaja o desventaja según se quiera o no compartir/aislar funcionalidad entre los sitecollections

Por último quisiera mencionar una utilería creada por Sharad Kumar, para agregar a la interfaz del sitio central de administración una opción para crear estos host-named sitecollections de manera visual

Recursos Adicionales:

Plan for host-named site collections (SharePoint Server 2010)

SharePoint 2010 – Central Admin tooling to create host header site collections

Establecer el host-header de una web application con https binding en IIS 7

Expondré un escenario que nos ocurrió hace poco en una implementación de SharePoint:

Creamos una nueva SharePoint web application, de la forma que ya conocemos, esta web application llamada SecureWebApplication, usara ssl y vivirá en el puerto 80, por lo que la url que da de la siguiente forma: https://securewebaaplication. Al crear esta web application le asignamos un host header, ya que conocemos previamente de la existencia de otra aplicación que se está ejecutando en este puerto.

Después de que la creación de la web application y site collection se llevaron a cabo satisfactoriamente, nos percatamos que la web application no responde, vamos al IIS y encontramos con que el sitio está detenido, intentamos iniciarlo, pero aparece un mensaje indicándonos que existe otro sitio que se encuentra utilizando el mismo puerto.

Efectivamente, existen otros sitios que se encuentra en el puerto 80, pero con host-headers diferentes, entonces, ¿por qué no puede iniciar nuestro sitio web?

Un poco de aburrida teoría…

Existen tres datos que definen la unicidad de un sitio web, los cuales son:

• Dirección IP
• Puerto
• Host name (host-header)

A la suma de estos tres datos se le conoce como binding,  y define a un sitio web que escucha en una ip:puerto con un host-header especifico.

Cuando se recibe una petición, el componente HTTP.sys lee las propiedades de  configuración del sitio al cual se hace la petición, tales como: tiempo de timeout, limite de conexiones y el certificado que utiliza el sitio

Pero para saber a qué sitio se está haciendo la petición, HTTP.sys utiliza el binding (los tres componentes arriba mencionados),  recordemos que el certificado es necesario para desencriptar los datos encriptados que el cliente envía (en donde viene el host-header)

O sea, que tenemos una dependencia circular. Por una parte necesitamos el certificado para desencriptar la información enviada y de ahí recuperar el binding para a su vez poder leer las propiedades de configuración. Y por otro lado necesitamos primero leer las propiedades de configuración para obtener el certificado y así desencriptar la información que viene del cliente. WTF!

En IIS 7, cuando nosotros creamos un binding https en un sitio web,  este automáticamente deshabilita el que nosotros podamos escribir el host-header, porque el host-header esta embebido en el certificado

 





Y después de toda esta reseña, la solución a esto es una pequeña utilería que se encuentra en la carpeta %windir%\system32\inetsrv, llamada appcmd, con la cual podemos forzar a que el host-header del https binding sea establecido. Con algo más o menos asi:

appcmd.exe set site /site.name:securewebaaplication /bindings.[protocol='https',bindingInformation='*:443:'].bindingInformation:*:443:securewebaaplication

Y el resultado final

Pueden revisar este enlace, para mas detalles.