Los Perfiles de Usuarios permiten identificar a los usuarios de SharePoint (o de nuestro dominio) con su información laboral y personal. Pasaremos de conocer a un usuario como “adiaz” a “Alberto Diaz Martin” con teléfono XXXX del departamento XXXX con el puesto XXXX con la foto XXXX con, con, con…

Esta información se puede introducir manualmente, desde la administración de perfiles en la administración central de nuestro SharePoint, o utilizando las capacidades de sincronización con otros orígenes externos (LDAP, Active Directory, un servicio Web, una base de datos, etc.).

Una de las novedades de SharePoint 2010, es que podemos realizar importaciones (ya podíamos hacerlas con SharePoint 2007) y exportaciones de los datos de los perfiles de los usuarios; esto es, vamos a ser capaces de traernos datos y almacenarlos en la base de datos (o algo parecido) de SharePoint y enviar los datos que se encuentran en SharePoint hacia un origen externo (por ejemplo, enviar la foto o el teléfono a nuestro Active Directory).

Suena bien, ¿no?

Pongamos como ejemplo el siguiente escenario: tenemos nuestra granja de SharePoint 2010, nuestro Directorio Activo y la aplicación de RRHH (Recursos in-Humanos). Lo normal, con estos 3 sistemas, es que la información de la aplicación de RRHH la podamos consultar desde los perfiles de nuestro SharePoint, esto es, que podamos ver la fecha de alta en la empresa de un empleado, su centro de trabajo, su formación profesional, sus números de teléfonos, Departamento al que pertenece, etc. También sería deseable, ya que SharePoint 2010 nos ofrece esta opción, que la información que importemos con la aplicación de RRHH sea exportada al Directorio Activo y así la podamos consultar también desde nuestro Outlook.

Pues siento deciros que va a ser que no, desde la administración de propiedades de usuarios en SharePoint 2010, no nos permite habilitar un campo para importación y exportación al mismo tiempo. Con lo bien que sonaba y el potencial que tenía. No podemos tener actualizada la información de nuestro Directorio Activo (no he visto uno en el que los técnicos de IT lo mantengan al día con la información necesaria) desde los perfiles en SharePoint junto con la aplicación de RRHH.

¿Y no podemos hacer nada?

Sabemos que SharePoint 2010 utiliza para la sincronización, una versión de FIM (Microsoft Forefront Identity Manager 2010) y conociendo este producto, ¿cómo es que no puedo? FIM es un gestor empresarial de identidades, credenciales y políticas de acceso que unifica distintos orígenes. En SharePoint 2010, de una forma transparente, configuramos los agentes de sincronización de FIM que son los que el Servicio de Sincronización utiliza para mantener actualizada la información, en ambos sentidos.

Si abrimos la ruta C:Program FilesMicrosoft Office Servers14.0Synchronization ServiceBin, tenemos el Service Manager (miiskmu.exe) que nos ofrece la información de la sincronización, la configuración de los agentes y otras opciones como el esquema del metaverse, etc.

Desde esta consola podemos analizar la sincronización de nuestros perfiles de usuarios y modificar los agentes creados en la administración de SharePoint. ¿Modificar los agentes? ¿Podemos configurar un atributo para que sea importable y exportable a la vez?

La respuesta es sí, pero mucho cuidado donde tocamos. Vemos un ejemplo: hemos configurado desde SharePoint que el campo teléfono se importe desde un BCS que es la aplicación de RRHH. Fíjense que nos permite importar de varios orígenes, pero no importar y exportar a la vez.

Una vez comprobada que la importación se realiza correctamente, vamos a modificar el agente GSC AD (el agente que se ha creado para el Directorio Activo) para que se exporta el atributo Teléfono del trabajo a uno de los atributos de nuestro Directorio Activo. Para esto, nos vamos al Service Manager de FIM, y en la pestaña de Management Agents, abrimos el agente encargado del Active Directory Domain Services.

En la configuración del agente, podemos ver el bosque de directorio al que está conectado, los atributos que se obtienen en la consulta de los usuarios, los filtros de consulta, y, la sección que nos interesa, el flujo de los atributos. En esta opción, es donde tenemos que seleccionar los atributos de ambos lados y añadirlos a la sincronización utilizando la opción de Export. Esta opción, que no tenemos habilitada en SharePoint si hemos elegido importarlo desde otro origen, nos permite configurar la exportación de los atributos del perfil hacia los atributos del directorio activo, a la vez que lo estamos importando con el agente de BCS original.

Ya tenemos configurada nuestra sincronización, aunque debemos tener mucho cuidado ya que estamos modificando al agente y estos cambios no los vamos a ver desde la administración en SharePoint, así que habrá que documentar bien estos procesos para no cambiar o equivocarnos con algún atributo.

Saludos a todos…

Parece que han saltado las alarmas en Microsoft. Unos Argentinos han mostrado una vulnerabilidad de ASP.NET en la ekoparty que afecta a las aplicaciones web ASP.NET. David Salgado no ha tardado en publicar un artículo sobre él y debemos de tenerlo muy en cuenta.

En el blog de ScottGu también se ha publicado un artículo sobre la vulnerabilidad y unas recomendaciones para asegurar nuestras aplicaciones.

La recomendación de Scott pasa por habilitar los errores personalizados, en nuestras aplicaciones, con un default redirect y sin especificar páginas personalizadas los códigos de error que se puedan producir y añadir un código de ofuscación a la carga de la página que utilicemos para mostrar el error.

También tenemos un script, en el artículo de Scott, que nos permite conocer que aplicaciones se pueden ver afectadas en un servidor web.

Este script es que he utilizado para revisar unos servidores SharePoint que tenemos a mano y me he llevado alguna que otra sorpresa. SharePoint utiliza la etiqueta para las páginas personalizadas de error pero no especifica cuál es la página de error por defecto.

<customErrors mode="On"/>

Tenemos un problema. Hay que modificar los web.config de las aplicaciones web de SharePoint para que incluyan una página de error por defecto. Si esto lo aplicamos a una granja de 1 o 2 servidores, la tarea es sencilla, pero cuando estamos hablando de varios frontales web, se complica ya que tenemos que ir uno por uno modificando los web.config de cada una de las aplicaciones web de SharePoint para que tengan la configuración ideal.

Lo ideal sería tener un script o una característica que realice los cambios en el web.config de todos los servidores de nuestra granja. Si optamos por la opción mas limpia y elegante, nos crearemos una característica con Visual Studio y añadimos en el evento de activación de la característica FeatureActivated el código siguiente que modifica el web.config y se asegura de que las modificaciones se repliquen a todos los servidores de  nuestra granja.

public override void FeatureActivated(SPFeatureReceiverProperties properties)

{

    SPSite site = properties.Feature.Parent as SPSite;

    SPWebApplication app = site.WebApplication;

    if (app != null)

    {

        //Añadimos el mode ON en el web.config

        SPWebConfigModification mod = new SPWebConfigModification("mode", "configuration/system.web/customErrors");

        mod.Sequence = 0;

        mod.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;

        mod.Value = "On";

        app.WebConfigModifications.Add(mod);

        //Añadimos el defaultRedirect

        SPWebConfigModification mod2 = new SPWebConfigModification("defaultRedirect", "configuration/system.web/customErrors");

        mod2.Sequence = 0;

        mod2.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;

        mod2.Value = "/_layouts/error.aspx";

        app.WebConfigModifications.Add(mod2);

        app.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

        app.Update(true);

    }

}

Habrá que estar pendiente de esta vulnerabilidad a la espera de que salga un parche y de confirmar que con este método es más que suficiente para estar seguros.

Saludos a todos…

Acaba de llegar la primera beta pública de Internet Explorer 9 y nos trae muchas novedades, tanto para los usuarios como para los desarrolladores (Aceleración de Hardware de los gráficos y el texto, una nueva interfaz de usuario más limpia, soporte para HTML5, un nuevo y mejorado motor de JavaScript, etc.)

Una de las nuevas funcionalidades que más me ha llamado la atención es la de los Site Pinning (Anclado de Sitios). Esto nos permite integrar cualquier sitio web en la barra de tareas o en el menú de inicio de nuestro Windows 7.

Intentando cambiar el concepto de sitio web hacia el de aplicación, nos permite tener nuestros sitios favoritos anclados en nuestro Windows 7 e identificados con su favicon. Arrastrando la pestaña podemos ver como hemos integrado el portal de mi empresa y el sitio web de Twitter.

Una vez que nuestro sitio web es anclado, Internet Explorer 9 nos provee de un API para añadir funcionalidades y añadir enlaces a la Jump List de nuestra aplicación web. Por ejemplo, Twitter incluye las opciones de New Tweet, Direct Mentions, etc.

Para personalizar la Jump List de nuestro sitio podemos utilizar una serie de etiquetas meta o unas funciones del navegador en JavaScript. Estas últimas nos permiten añadir dinámicamente los enlaces.

<META name="msapplication-task" content="name=Task 1;action-uri=http://host/Page1.html;icon-uri=http://host/icon1.ico"/>

// Creamos la Categoría

window.external.msSiteModeCreateJumplist('List1');

// Añadimos elementos a la Categoría

window.external.msSiteModeAddJumpListItem('Item 1', 'http://host/Item1.html', 'http://host/images/item1.ico');

window.external.msSiteModeAddJumpListItem('Item 2', 'http://host/Item2.html', 'http://host/images/item2.ico');

window.external.msSiteModeAddJumpListItem('Item 3', 'Item3.html', 'images/item3.ico');

// Mostramos la Categoría con sus elementos

window.external.msSiteModeShowJumplist();

Integrándolo con SharePoint 2010

Vamos a aprovechas las nuevas funcionalidades sociales de SharePoint 2010 para crearnos una Jump List de nuestro portal con enlaces a elementos relevantes para los usuarios dentro del mismo.

Estas capacidades sociales permiten al usuario etiquetar el contenido o decidir si un elemento es de su agrado o no, con la acción Me gusta. Esta acción, realmente, etiqueta el contenido seleccionado con una etiqueta del sistema llamada Me gusta.

Para consultar los elementos que has etiquetado existen una serie de Web Parts y un sitio, Mi Perfil, que nos muestra la información:

Ahora con los Pinned Sites y el Jump List de Internet Explorer 9 podemos extender nuestro SharePoint y convertirlo en una aplicación con algunas funcionalidades interesantes que vamos a poder programar.

Descartemos, por el momento, la posibilidad de utilizar etiquetas meta ya que no nos permite añadir enlaces personalizados para el usuario y centrémonos en el API de JavaScript. Sería interesante que a nuestros usuarios le integremos los últimos elementos (documentos, páginas, artículos de blog, etc) que les han gustado en la Jump List.

Para hacer esto necesitamos utilizar el API de Perfiles de Usuarios y el de Taxonomía para obtener los elementos que le gustan a un usuarios.

SPWeb web = SPContext.Current.Web;

using (SPSite site = web.Site)

{

    SPServiceContext context = SPServiceContext.GetContext(site); //Obtenemos el contexto del servicio

    UserProfileManager myUserProfileManager = new UserProfileManager(context); //Obtenemos el Manager de User Profile

    UserProfile myUserProfile = myUserProfileManager.GetUserProfile(this.Context.User.Identity.Name); //Obtenemos el Pérfil del usuario actual

    SocialTagManager mySocialTagManager = new SocialTagManager(context); //Obtenemos el Manager de las Social Tag

    List<SocialTag> tags = new List<SocialTag>();

    tags.AddRange(mySocialTagManager.GetTags(myUserProfile)); //Obtenemos las etiquetas del usuario

    foreach (SocialTag tag in tags.FindAll(p => p.Term.GetDefaultLabel(3082).Equals("Me gusta")))    

    {

    }

}

Lo siguiente que tenemos que hacer es recorrer esta lista de etiquetas y ejecutar las funciones JavaScript que añadan estos enlaces a la Jump List. En SharePoint, tenemos varias opciones para insertar código a nuestros sitios. Podríamos utilizar un Web Part pero estos nos limitarían al ámbito de ejecución del mismo, o sea, la página en la que el Web Part estuviera instanciado.

La otra opción sería crearnos un Custom Delegate, que es un control que reside en el AdditionalPageHead de la Master Page de nuestro site y nos permite registrar código JavaScript en esta sección.

Bien, pues añadimos al código anterior la capacidad de registrar el código JavaScript necesario para crearnos un grupo y los elementos del Jump List.

//Creamos el grupo

callbackScript.AppendLine("window.external.msSiteModeCreateJumplist('Me gusta');");

foreach (SocialTag tag in tags.FindAll(p => p.Term.GetDefaultLabel(3082).Equals("Me gusta")))

{

    //Creamos cada uno de los elementos que se encuentran etiquetados con 'Me gusta'

    callbackScript.Append("window.external.msSiteModeAddJumpListItem('");

    callbackScript.Append(tag.Title);

    callbackScript.Append("', '");

    callbackScript.Append(tag.Url);

    callbackScript.Append("', '");

    callbackScript.Append("/_layouts/images/favicon.ico');");

    callbackScript.AppendLine("");

}

//Mostramos la lista

callbackScript.AppendLine("window.external.msSiteModeShowJumplist();");

}

Sólo nos queda registrar el script con nuestro control delegado.

// Registramos el callbacks del cliente para que se ejecute el JavaScript que generamos anteriormente

ClientScriptManager cm = this.Page.ClientScript;

cm.RegisterClientScriptBlock(this.GetType(), "CreateJumpList", callbackScript.ToString(), true);

Con lo que obtenemos un grupo llamado ‘Me gusta’ en la Jump List de nuestro Pinned Site con los elementos que el usuario ha etiquetado en el SharePoint.

Con este simple control le ofrecemos a los usuarios una gran funcionalidad que le facilitará la vida a la hora de acceder a su contenido. Pensemos en crear otros grupos como Mis Enlaces, Mi Sitio, etc., que permitan al usuario tener a mano sus contenidos.

Saludos a todos…

SharePoint 2007 tenía muchas capacidades dentro de la gestión de documentos. Las bibliotecas de documentos permitían a los usuarios hacer check-in/check-out, control de versiones, permisos a nivel de elemento de lista, procesos empresariales con flujos de trabajos, papelera de reciclaje, etc. Con SharePoint 2010 se han ampliado estas funcionalidades consiguiendo mejorar sustancialmente el producto. Vamos a hacer un recorrido por alguna de ellas.

Document ID

Todos los elementos de lista tienen una columna ID que es un autonumérico. Este ID es único a nivel de lista y no a nivel de colección de sitios. Document ID nos permite activar a nivel de colección de sitios la capacidad de identificar nuestros documentos con un ID único para esta colección. Con esta funcionalidad, se nos activa un servicio que nos permite obtener cualquier documento utilizando su ID, mediante la url (/DocIdRedir.aspx?ID=uniquedocid).

Cuando activamos la característica podemos configurar el identificador común para cada documento (esto nos permitirá tener ids de documentos únicos por cada colección de sitios) y el ámbito de búsqueda de los mismos.

Ahora, cada vez que creemos o subamos un documento a una biblioteca de esta colección de sitios, automáticamente se le asigna un identificador único y es accesible a través de la página DocIdRedir.aspx.

Document Sets

Los Document Sets, o conjuntos de documentos, son una característica que nos permite tener un tipo de contenido especial con la capacidad de agrupar diversos tipos de documentos en un conjunto.

Por ejemplo, para elaborar una oferta en una empresa se necesitan varios documentos, el word con la oferta, el excel con la hoja de costes, el project con la planificación, etc. Document Sets nos permite tener un tipo de contenido que cree estos documentos a partir de una plantilla específica y los mantenga agrupados y asociados mediante información común. Al permanecer agrupados, podemos aplicar flujos de trabajo al conjunto de documentos, control de versiones, etc.

Vamos a crearnos un nuevo tipo de contenido utilizando Document Sets. Lo primero que tenemos que hacer es activar la característica Conjunto de Documentos a nivel de colección de sitio.

A continuación, nos creamos una biblioteca de documentos y activamos la opción de administración de los tipos de contenido. Una vez que podemos administrar los tipos de contenido, agregamos el tipo de contenido Conjunto de documentos.

Ahora tenemos en nuestra biblioteca un tipo de contenido de Document Sets, si vamos a la configuración del tipo de contenido, podemos seleccionar los documentos que van a formar parte del conjunto, las columnas compartidas, la página de bienvenida, etc.

Rating, Tag/Notes

Sin necesidad de hacer un check-out de un documento, podemos clasificarlo, etiquetarlo o agregarle anotaciones. Para clasificarlo tenemos que activar la configuración en las opciones de la lista. Esto nos incluirá una nueva columna que, utilizando las estrellitas, nos permite clasificar el documento.

Etiquetar y anotar añade una nueva funcionalidad de colaboración en nuestros documentos.

Content Organizer

La organización de contenidos nos permite definir reglas basadas en los metadatos de los documentos. Cuando activamos la característica, se crea una biblioteca de documentos, llamada Biblioteca Temporal, que es la que se encarga de recibir los documentos y moverlos en función de las reglas definidas.

En las Reglas del organizador de contenido podemos definir los filtros que se tienen que aplicar y la biblioteca de documentos de destino para los documentos que se suban a esta biblioteca. Estos filtros se basan en los tipos de contenido de los documentos y las propiedades que este tiene.

Cuando cargamos un documento, nos advierte que, en función de las reglas definidas, será movido a otra biblioteca una vez que sean recopiladas todas las propiedades necesarias.

Estas son algunas de las nuevas posibilidades que vienen para la gestión de documentos en SharePoint 2010. Junto con estas podemos incluir la nueva capacidad de gestión de metadatos, las Office Web Apps, la rediseñada funcionalidad de gestión de registros, etc.

Si ya con SharePoint 2007 las empresas podían mantener una muy buena gestión documental, con esta nueva versión se amplían las capacidades y seguimos teniendo uno de los mejores productos con muchas funcionalidades y capacidades.

Saludos a todos…

El equipo de producto de CRM acaba de llegar a la primera release en Beta de la nueva versión del producto de CRM de Microsoft. Esta beta está disponible para descarga desde la web de download de Microsoft en múltiples idiomas.

Otra noticia importante es la posibilidad de probar Online, previo registro, y que estará disponible para un número mayor de mercados (por ejemplo, en la actualidad no tenemos disponible CRM Online para España).

Para los desarrolladores también tenemos muchas y nuevas novedades, entre las que destacamos el desarrollo con Visual Studio y Silverlight.

También, y no menos importante, se deja ver (que estamos pendientes de probar) una integración con SharePoint (versión 2010 o 2007). Está integración nos va a permitir ver los datos del CRM en la gestión documental de nuestro SharePoint.

Saludos a todos…

Ya hace unos meses que tenemos disponible SharePoint 2010 y es un buen momento de empezar a plantearse la actualización de nuestro viejo SharePoint 2007 a esta nueva y mejorada versión SharePoint 2010.

Para la actualización, tenemos que tener en cuentas ciertos aspectos:

Plataforma de 64-bit y Windows Server 2008

SharePoint 2010 sólo se puede instalar en servidores x64, incluyendo al servidor SQL Server. Desde que salió el SP2 de SharePoint 2007, ya se comentó este requisito y para los que no hayan cambiado de plataforma, es una necesidad para pasarse a la versión 2010.

Windows Server 2008 o Windows Server 2008 R2 es otro requisito imprescindible para SharePoint 2010.

Pueden consultar el documento de Planning.

Métodos de actualización

Se plantean dos procesos para la actualización:

• In-place upgrade. Este proceso nos permite realizar la actualización en nuestra actual plataforma de SharePoint 2007. Este proceso nos permitiría mantener las personalizaciones y configuraciones de nuestra granja, sin embargo, los servidores permanecen offline durante el proceso.
• Database attach upgrade. No se actualiza la granja, se realiza la instalación en una nueva plataforma y se adjunta y actualiza las bases de datos de contenido. El principal problema de este proceso es que primero hay que instalar todas las personalizaciones, características y demás en el nuevo servidor.

Podemos descargar el documento con los procesos.

Antes de la actualización

Antes de realizar la actualización, debemos de realizar una serie de comprobaciones y copias de seguridad para asegurarnos que el proceso de realizará de forma segura y satisfactoria.

• Pre-Upgrade checker. Con el SP2 de SharePoint 2007 tenemos un comando administrativo que nos permite realizar una serie de comprobaciones para conocer si podemos realizar una migración sin problemas a SharePoint 2010. Muy importante identificar las personalizaciones que no serán soportadas en SharePoint 2010.
• Elegir un método de actualización. Habrá que elegir entre uno de los métodos de actualización disponibles o realizar un proceso híbrido que nos permita utilizar los mejores pasos que se adapten a nuestra granja. Por ejemplo, en una de las actualizaciones que estamos realizando, vamos a clonar las máquinas virtuales para realizar una actualización In-place y así conseguir actualizar las bases de datos de contenido al nuevo esquema de SharePoint 2010. Una vez que tenemos esta actualización, realizar exportaciones del contenido para importarlo en la nueva estructura que se ha definido en el nuevo servidor de SharePoint 2010.
• Identificar las personalizaciones. Este punto es importante, ya que tenemos que volver a instalarlas o comprobar que la actualización se ha realizado correctamente, una vez finalizado el proceso de actualización.
• Backup. Creo que este punto lo dice todo, cualquier proceso de actualización es candidato a fallar, aunque lo hayamos comprobado todo dos veces.

Durante la actualización

Después de realizar el pre-upgrade y comprobar que todo el proceso se realizará satisfactoriamente, debemos empezar con el proceso seleccionado.

• Configurar todos los servidores de la granja
• Instalar los paquetes de idiomas necesarios
• Decidir si vamos a realizar el Visual Upgrade a la nueva versión o vamos a mantener la imagen anterior de SharePoint 2007.

Después de la actualización

Este paso es muy importante. Tenemos que comprobar y asegurarnos que la actualización se ha realizado correctamente.

• Revisa los logs, tanto de SharePoint (ahora están en la 14) como de Windows.
• Comprueba los sitios, contenidos y seguridad.
• Reestructura el contenido de la granja. Este es el momento ideal, los usuarios están esperando a que terminemos con la migración y podemos aprovechar para mejorar la estructura y hacer limpieza.

Todos estos pasos están muy bien, pero siempre va a fallar algo. Tengamos en cuenta que los procesos de actualización que funcionan correctamente son sobre aquellas granjas en las que no se hayan realizado muchas personalizaciones o se hayan utilizado características compatibles o no se hayan jugado al límite implementando formularios no soportados o ensamblados en el gac.

Yo soy partidario de realizar las actualizaciones manuales, aprovechando para reestructurar la granja, los sitios y asegurándonos que todas las personalizaciones se migran a Visual Studio 2010 y se mejora el código de SharePoint 2010.

Saludos a todos…