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

Configuración SharePoint 2010 - User Profile Application Service Error

Uno de los tantos errores que podemos obtener al intentar configurar el nuevo servicio de aplicación para perfiles de usuario(User Profile Application Service), al querer acceder a la página de administración de este servicio nos aparece este mensaje:

Y al revisar los logs de SharePoint encontramos una entrada como la siguiente:

UserProfileServiceUserStatisticsWebPart:LoadControl failed, Exception: System.IO.FileLoadException: The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.InitializeIlmClient(String ILMMachineName, Int32 FIMWebClientTimeOut)
at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)
at Microsoft.SharePoint.Portal.WebControls.UserProfileServiceStatisticsWebPartBase.LoadControl(Object sender, EventArgs e)

Y es que he de admitir que si bien es cierto que este servicio sufrió grandes modificaciones y adiciones de nuevas características para la versión 2010, también es cierto que se volvió más difícil de configurar, administrar, y diagnosticar al momento de implementarlo. Y no difícil por la cantidad de pasos o procedimientos que se tienen que ejecutar, sino por la cantidad de errores con que nos podemos encontrar al intentar hacerlo trabajar.

Sin embargo este error, en especial, es muy conocido y fácil de solucionar. El escenario en el que se presenta muy usualmente es el siguiente.

Escenario
El servicio User Profile Application Service y el Sitio Central de Administración han sido provisionados en el mismo servidor.

Solución
Ejecute un IISRESET después de iniciar el servicio, eso es todo!.

Desarrollo SharePoint 2010 - The Web application at [Url] could not be found

El siguiente es un error que aparece con mucha frecuencia  cuando comenzamos a desarrollar para SharePoint 2010, por lo menos esa es mi impresión en los equipos de desarrollo en que he participado.

The Web application at [Url] could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

La excepción se presenta cuando accedemos programáticamente a un sitio SharePoint ("http://sp2010"), obviamente después de habernos asegurado que la url esta correcta.

Y es que sí creamos algún proyecto desde las plantillas de proyecto que vienen por default en Visual Studio 2010 especiales para desarrollo SharePoint, como lo son "Visual Web Part", "List Definition", "Sequential Workflow", etc. no obtendremos este error.

Sin embargo si creamos, por ejemplo, una aplicación de consola ó Windows Forms y después de agregar las referencias necesarias para trabajar con la API de SharePoint, muy probablemente nos aparecerá este error. Y esto es debido a que este tipo de aplicaciones al crearse especifican el valor de configuración de Platform target a x86, lo que indica que nuestra aplicación intentara ejecutarse como un proceso de 32 bits.

Para solucionar ó prevenir este comportamiento solo se debe establecer este valor de configuración a x64 ó Any CPU(si estamos desarrollando en un ambiente x64) y nuestro código funcionará correctamente.

Por cierto, no se olviden de establecer el parámetro de configuración Target framework a: .Net Framework 3.5

Recursos adicionales:
Visual Studio .NET Platform Target Explained

Happy Coding!

SharePoint DisableLoopbackCheck security feature

Hace unos días algunos desarrolladores me comentaban acerca de un "error" que ellos describían de la siguiente manera: "No podemos ver ninguna de los sitios SharePoint en el Servidor".

El problema

Cada vez que intentaban ver alguno de los sitios SharePoint, que se habían creado previamente, les pedía en repetidas ocasiones (las tres de rigor) su usuario y contraseña antes de mandar un error 401.1 Access Denied y una entrada en el EventViewer, todo esto solo cuando accedían a alguno de los sitios desde el servidor, desde cualquier cliente todo funcionaba correctamente.

Consideraciones a tomar

En primera instancia esto no es un gran problema porque ningún usuario usa alguno de los servidores de la granja de SharePoint para ver los sitios ahí hosteados. Pero y si es un servidor de pruebas? ó si ese servidor del que hablamos es nuestro entorno de desarrollo?. En estos casos es obligatorio que podamos acceder a los sitios sin que este comportamiento ocurra.

Un poco de historia

Este característica de seguridad fue introducida desde el Service Pack 1 de Windows Server 2003 y está presente hasta las versiones actuales de Windows Server 2008 R2. Básicamente lo que hace es bloquear el acceso a una web application usando el FQDN, si esto sucede la característica entra en acción y bloquea este acceso enviando un error 401.1, que por cierto no es muy adecuado.

¿Por qué se introdujo esta característica? Pues porque existían varios ataques que se basaban en reflección para engañar a IE y hacerle creer que se estaba trabajando de manera local y así burlar muchas restricciones de seguridad.

Algunos otros escenarios

Otros escenarios en los que esta característica de seguridad puede causar problemas, es en los servidores que además de tener el rol de WFE, también tienen el rol de Index. Esto porque básicamente el servidor Index intenta hacer un crawling (peticiones http) a sí mismo. Este comportamiento es fácilmente detectable porque los logs de crawling muestran cientos de errores del tipo 401.

Las soluciones

Pues muy fácil, seguimos las instrucciones del Microsoft's KB article 896861. Pero entonces para que todo este rollo que acaban de leer?

La solución dependerá en gran medida de lo que quieran hacer y el entorno en el que se encuentren. Como comentaba anteriormente, si se trata de un servidor de pruebas o de desarrollo, adelante!! Sigan el artículo y deshabiliten la característica LoopBackCheck.

Pero en un servidor productivo esto no es aceptable, ya que se constituye en un hueco de seguridad importante. Pero entonces, no es posible solucionar este problemilla en un servidor productivo? Por supuesto que sí!, sin embargo la solución no va por el camino de deshabilitar la característica LoopBackCheck, lo ideal es utilizar el Método dos descrito en el KB 896861, el cual indica la forma de agregar una entrada en el registro llamada BackConnectionHostNames, dentro de esta nueva entrada se agregarán host names que serán excluidos del funcionamiento de esta característica.

Algunas referencias adicionales

DisableLoopbackCheck?  Lets do it the right way
Groundhog Day: Configuring Back Connection Host Names using Group Policy
Setting Back Connection Host Names for SharePoint 2007 Using STSADM
You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version

The list cannot be displayed in Datasheet view with Office 2010

Si aún están utilizando Office 2007, y están intentado ver la vista de hoja de datos (datasheet view) de una lista que se encuentre en un sitio de SharePoint 2007, este artículo puede resolver su problema.

Sin embargo, si ustedes como yo, están utilizando ya Office 2010 e intentan acceder a su vieja intranet corporativa(por poner un ejemplo), desplegada sobre SharePoint 2007, podrían obtener también este error.

La solución a este pequeño inconveniente es instalar el 2007 Office System Driver: Data Connectivity Components, tal como refiere el KB 2266203.

Y con este sencillo paso, ahora ya podrán abrir las listas de SharePoint 2007 en modo "datasheet view" aún cuando no tengan instalado Office 2007 y si el poderoso Office 2010.