El Día del Flujo de Trabajo de SharePoint 2010 para Desarrolladores

Solo para invitarlos cordialmente a la serie de webcast sobre flujos de trabajo en SharePoint 2010 que se estará llevando acabo el día 15 de Diciembre del presente año, en donde estaré participando con una charla acerca del uso de Visio Services para el desarrollo de workflows.

Sin duda es una muy buena oportunidad para conocer todo lo referente a los flujos de trabajo en SP 2010, lo que siempre quisiste preguntar pero no habías podido. Esta por demás decir que los expositores son el Jet Set del Desarrollo en SharePoint (excepto yo, que solo estoy de colado)

El miércoles 15 de diciembre del presente año varios MVPs estaran celebrando el día del flujo de trabajo SharePoint 2010 para desarrolladores en donde presentaran los conceptos mas relevantes a relacionados con el desarrollo de flujos de trabajo con Microsoft SharePoint Server 2010 mediante presentaciones abiertas en línea de forma continua durante el transcurso del día.

Conociendo los Flujos de Trabajo Pre Construidos en SharePoint 2010 En esta sesión conoceremos la propuesta de flujos de trabajo que SharePoint 2010 pone en la mesa y las características de cada uno de los flujos de trabajo pre construidos en el producto. Cuando y donde genera valor utilizarlo para automatizar algún proceso u operación empresarial y mejor aún cómo es posible extenderlos para personalizar algún proceso. 15 de Diciembre 2010 a las 10:00 AM Tiempo de México https://www.livemeeting.com/cc/mvp/join?id=wfday1&role=attend Construyendo Flujos de Trabajo en SharePoint 2010 utilizando SharePoint Designer 2010 En esta sesión veremos el soporte que SharePoint Designer 2010 tiene para la creación y manipulación de flujos de trabajo para SharePoint. Conozca el nuevo diseñador de flujos de trabajo, las actividades y condiciones disponibles en esta versión y como programar tus propias condiciones y acciones para SharePoint Designer 2010. 15 de Diciembre 2010 a las 11:30 AM Tiempo de México https://www.livemeeting.com/cc/mvp/join?id=wfday&role=attend Construyendo Flujos de Trabajo en SharePoint 2010 utilizando Visio Services En esta sesión veremos el valor que Visio Services aporta al mundo de los flujos de trabajo. Al fin contamos con una alternativa mucho más rica para poder mostrar de forma gráfica el estado de los flujos en ejecución y brindar opciones al usuario para consultar información contextual de una instancia en ejecución del flujo de trabajo. 15 de Diciembre 2010 a las 3:00 PM Tiempo de México https://www.livemeeting.com/cc/mvp/join?id=wfday3&role=attend Construyendo Flujos de Trabajo en SharePoint 2010 utilizando Visual Studio 2010 Esta es una sesión para desarrolladores .NET que construyen flujos de trabajo para SharePoint 2007 y buscan conocer cómo construir flujos de trabajo en SharePoint 2010. Exploraremos las nuevas características relacionadas con flujos dentro de SharePoint 2010 y el soporte simplificado Visual Studio 2010 aporta para facilitar su construcción y despliegue. 15 de Diciembre 2010 a las 4:30 PM Tiempo de México https://www.livemeeting.com/cc/mvp/join?id=wfday4&role=attend

Puedes seguir la cuenta del evento aqui:

Happy Coding!

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