Office 365: Como solucionar los problemas para mapear bibliotecas de SharePoint Online en el explorador de Windows!

Como el mapeo de bibliotecas de documentos de SharePoint Online en el explorador de Windows tiene su complicación, y gracias a la solución aportada por Jordi Rosell en este thread del foro de Office 365, he querido dejar constancia de los pasos que solucionan los problemas que se dan al realizar dicho mapeo:

• Habilitar de manera automática el servicio Webclient de Windows. Este servicio lo podremos acceder desde la administración de nuestro equipo:
  • Para abrir la administración, simplemente vamos a inicio, hacemos clic con el botón derecho del ratón sobre “Equipo” (esto es para Windows 7) y pulsamos “Administrar”.
  • En la aplicación “Administración de equipos” nos vamos a la sección “Servicios y Aplicaciones” y pulsamos sobre “Servicios”.
  • Localizamos el servicio “Cliente Web” y nos aseguramos que está configurado para que se inicie de forma automática.

• Instalar el instalador de aplicaciones de Office365 que tendremos disponible en el área de descargas del portal de Office 365:
  • El área de descargas la tenemos disponible en la sección Recursos.
  • El instalador de aplicaciones de escritorio aparece al final de la página con las descargas disponibles.

• Para Windows 7, instalar la siguiente actualización de Windows 7:
  • Paquete acumulativo de actualizaciones para el Ayudante para el inicio de sesión de Microsoft Online Services (KB2630976).
  • Más información:
    • support.microsoft.com/…/2630976
    • Ayuda y soporte técnico: support.microsoft.com/…/15834

Y en principio esto sería todo, el último paso para equipos con Windows XP o Windows Vista en principio no sería necesario.

SharePoint 2010: Niveles de arquitectura (I)!

Un tema con mucha “miga” en SharePoint es el los niveles de arquitectura de los que podemos hablar cuando nos referimos a una implementación tipo.  Por eso, responder a la pregunta ¿Qué niveles de arquitectura tenemos en SharePoint? no es tan sencillo como a priori puede parecer y la respuesta es que “depende del contexto en el que estemos hablando”. Básicamente, y en mi opinión, al menos podemos identificar los siguientes niveles de arquitectura:

• Arquitectura en N-Capas tradicional tal en la que se trataría de “mapear” las capas con elementos de SharePoint como se ha comentado.
• Arquitectura lógica en la que introducimos elementos claves de la jerarquía lógica de SharePoint:
  • Aplicaciones Web.
  • Bases de datos de contenido.
  • Colecciones de sitios.
  • Sitios.
  • Listas y bibliotecas de documentos.
  • …

Junto con las aplicaciones Web, lo que podemos pintar son los servicios que van a ser usadas por las mismas:

• Aplicaciones de servicio elegidas a la carta por aplicaciones web.
• Administración Central de SharePoint.
• Otros servicios.

Un ejemplo de esta idea es el que se muestra en el siguiente diagrama de arquitectura para SharePoint 2007.

A nivel de arquitectura lógica, incluso podemos proponer un diseño de ejemplo y al detalle:

• Arquitectura x roles de servidor en la que identificaremos los distintos roles de servidor de SharePoint:
  • Frontales Web.
  • Servidores de aplicaciones.
  • Servidores de Bases de Datos.
  • …

La arquitectura x roles es la que luego nos permite definir la topología del despliegue de SharePoint a realizar. Por ejemplo, una topología compleja en la que tenemos grupos de servidores es la siguiente:

• Arquitectura física, dónde identificamos a nivel físico los distintos servidores que tenemos disponibles.
• Arquitectura de información en la que ya identificamos de forma clara las aplicaciones web, colecciones de sitios, listas y bibliotecas que se necesitan.

Referencias:

• Arquitectura lógica de SharePoint:
  • http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?PageType=4&ListId={72C1C85B-1D2D-4A4A-90DE-CA74A7808184}&pID=786
  • http://www.etechplanet.com/blog/logical-architecture-of-sharepoint-application.aspx
  • http://www.thesharepointdude.com/?p=730
  • http://www.informit.com/articles/article.aspx?p=1657659
• Ejemplos de diseños de arquitectura:
  • http://technet.microsoft.com/en-us/library/cc261995.aspx
  • http://www.harbar.net/archive/2008/09/17/Investing-in-Logical-Architecture-Design-Samples.aspx
  • http://www.astaticstate.com/2010/03/sharepoint-2o10-logical-architecture.html
• Diagramas de arquitectura:
  • http://www.mikethearchitect.com/2009/11/new-sharepoint-2010-architecture-models.html
  • http://sharemypoint.in/2009/10/25/sharepoint-2010-resources-on-architecture-planning-search-sdk/

SharePoint 2010: ¿Qué BD’s puedo mover y como?

Dejando claro que las BD’s de SharePoint 2010 se pueden mover, y por estas entiendo BD’s de contenido y aplicaciones de servicio, esta pregunta puede surgir cuando nos planteamos mover BD’s de ciertas aplicaciones de servicio a otro servidor bien porque estamos creando otro entorno o bien porque estamos moviendo ciertas aplicaciones de servicio a otro servidor. Por suerte, Microsoft  dispone de documentación relativa a que BD’s se pueden mover como podéis ver en este enlace y el proceso a seguir que se indica en este otro enlace.

SharePoint 2010: ¿Uno o varios grupos de aplicaciones?

Otro de los conceptos básicos en SharePoint 2010 es el de grupo de aplicaciones (más comúnmente conocidos como Applications Pools) que se encargan de manejar las peticiones realizadas a SharePoint. Un grupo de aplicaciones viene a ser  un espacio aislado en memoria que se asocia a una o varias aplicaciones web y a una o varias aplicaciones de servicio y cuya identidad suele estar asociada con una cuenta manejada de SharePoint 2010. Cada vez que creaos una aplicación web o un proxy de aplicación de servicio, se nos pide que creemos o especifiquemos el correspondiente grupo de aplicaciones…y es aquí dónde viene la pregunta que da el título al post: ¿Uno o varios grupos de aplicaciones? La respuesta, como siempre, es qué depende:

• Por definición, un grupo de aplicaciones es un espacio aislado por lo que si tenemos dos aplicaciones web cada una ejecutándose con el correspondiente grupo de aplicaciones nos aseguraremos aislamiento máximo a este nivel. De esta forma, si en una aplicación web se han desplegado artefactos con código “malo” que hagan que se rompa, la otra aplicación web no se verá afectada.
• Entonces, ¿creo un nuevo grupo de aplicaciones web para cada nueva aplicación web? Pues no, ya que existe un límite recomendado de máximo de grupo de aplicaciones disponibles por frontal web que es de 10 (http://technet.microsoft.com/en-us/library/cc262787.aspx), es decir, son un recurso en principio escaso. Si bien es cierto que este límite está condicionado por la cantidad de memoria RAM disponible en los frontales y el uso que se esté haciendo de los mismos.
• Por lo tanto, como recomendación general compartiremos grupos de aplicaciones entre aplicaciones web.

SharePoint 2010: ¿Una o varias aplicaciones web?

Esta pregunta es una de las muchas que nos tenemos que hacer a la hora de diseñar una solución SharePoint. La respuesta a la misma viene dada, desde una perspectiva de alto nivel, por el grado de aislamiento e independencia que necesitemos en la solución a diseñar. Así, optaremos por disponer de varias aplicaciones web en supuestos como:

• Se requiere un aislamiento completo de contenidos internos / externos de manera que es necesario dividir el contenido en aplicaciones web separadas, cada una de las cuáles dispone de un sitio web de ISS, un nombre único de dominio, una o varias BD’s separadas, etc.
• Las conexiones de aplicaciones de servicio difieren entre aplicaciones web.
• La configuración de la papelera de reciclaje tiene que ser diferente por aplicación web.
• Se quiere habilitar la creación de colecciones de sitios por parte del usuario en ciertas aplicaciones web.
• Los tipos de ficheros a bloquear cambian en función de la aplicación web.
• …

En general, si queremos dar soporte a configuraciones diferentes a nivel de aplicación web tendremos que recurrir a crear más de una aplicación web. Y por supuesto, todo esto se tiene que recoger en el plan de gobernanza correspondiente.

Office 365: Algunos videos de uso de la plataforma!

En esta ocasión quería dejaros algunos videos sobre Office 365 que tenéis disponibles en YouTube y que permiten como usuario sacar el máximo partido a la suite de productividad de Microsoft en la nube:

• Trabajo con permisos en Office 365.

• Diseño de sitios web públicos con Office 365.

• Como invitar a usuarios externos a sitios de SharePoint Online en Office 365.

Finalmente os dejo un par de referencias a más videos sobre Office 365 disponibles en Youtube:

• Canal Get started with SharePoint Online.
• Canal Office 365 Tutorials and Help.

SharePoint 2010: Como configurar la búsqueda de archivos PDF!

Como sabéis, uno de los puntos fuertes de la plataforma SharePoint es el de las búsquedas ya que cuando un usuario indica un cierto término de búsqueda, el motor de la plataforma va a buscar dentro del contenido indexado dicho término devolviendo aquellos elementos de lista y documentos en cuyo nombre se incluya. Además, en el caso de los documentos, devolverá aquellos en los que encuentre el término buscado como parte de su contenido. Ahora bien, para que esto sea posible es necesario disponer de los correspondientes iFilter instalados en nuestros frontales web que habilitan la búsqueda dentro de documentos de distintos formatos: office, pdf, TIFF, etc. Por defecto, la plataforma incorpora de serie los iFilter para documentos Office, pero no para un formato tan típico como es el de Adobe PDF. Por este motivo, tendremos que instalar el iFilter de Adobe en nuestros frontales web y realizar las configuraciones necesarias para que el motor de búsqueda de SharePoint 2010 pueda buscar en el contenido de archivos PDF. El resumen de pasos necesarios para configurar la búsqueda de archivos PDF es el siguiente:

• Descargar e instalar el Adobe iFilter 9 para plataformas de 64 bits (http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025) en los frontales web de nuestro despliegue de SharePoint.
• Añadir en la configuración de la aplicación de servicio de búsquedas el tipo de archivo “PDF”.
• Comprobar en la entrada de registro correspondiente (http://www.adobe.com/special/acrobat/configuring_pdf_ifilter_for_ms_sharepoint_2007.pdf) que el iFilter para Adobe PDF se ha añadido de forma correcta. En caso contrario, tendremos que añadirla manualmente.
• Realizar un rastreo completo desde la página de administración de las búsquedas en la administración central.
• Realizar un IISReset.

A continuación os dejo algunas referencias en las que se explica de forma detallada el proceso a seguir:

• http://nickgrattan.wordpress.com/2010/06/14/adobe-pdf-ifilter-indexing-with-sharepoint%C2%A02010/
• http://www.sharepointsharon.com/2010/03/sharepoint-2010-and-adobe-pdf/
• http://www.gavinadams.org/blog/2010/05/06/sharepoint-2010-and-pdf-ifilter-adobe
• http://blogs.msdn.com/b/opal/archive/2009/10/20/index-and-search-pdf-files-in-sharepoint-server-2010.aspx
• http://www.codeproject.com/KB/sharepoint/PDFiFIlterSharePoint2010.aspx

SharePoint 2010: Como usar el SPSecurityTrimmedControl en una WebPart!

En SharePoint 2010, como en SharePoint 2007 tenemos la posibilidad de controlar como se muestra la información al usuario (controles, secciones, partes del menú vertical, etc) usando un control especial: SPSecurityTrimmedControl. Se trata de un control especial que nos permite envolver elementos de SharePoint como pueden ser controles o elementos estáticos de forma segura de manera que sólo estén accesibles para usuarios que tengan unos ciertos permisos. En particular, vamos a ver como usar este control en una WebPart:

• En VS 2010 creamos un proyeto de SharePoint 2010 de tipo “Empty SharePoint Project”. En el asistente de configuración elegimos como tipo de despliegue “Deploy as a farm solution”.
• Añadimos al proyecto un elemento de tipo WebPart que codificamos de la siguiente forma:

   1: using System;

   2: using System.ComponentModel;

   3: using System.Web;

   4: using System.Web.UI;

   5: using System.Web.UI.WebControls;

   6: using System.Web.UI.WebControls.WebParts;

   7: using Microsoft.SharePoint;

   8: using Microsoft.SharePoint.WebControls;

   9:  

  10: namespace SPSecurityTrimmedWP.SPSecurityTrimmedWP

  11: {

  12:     [ToolboxItemAttribute(false)]

  13:     public class SPSecurityTrimmedWP : WebPart

  14:     {

  15:         protected override void CreateChildControls()

  16:         {

  17:             SPSecurityTrimmedControl spstcControl = new SPSecurityTrimmedControl();

  18:             spstcControl.Permissions = SPBasePermissions.EditListItems;

  19:             Label lblInformation = new Label();

  20:             lblInformation.Text = 

  21:                 "Información solo visiable para ciertos usarios";

  22:             spstcControl.Controls.Add(lblInformation);

  23:             this.Controls.Add(spstcControl);

  24:         }

  25:     }

  26: }

• Desplegamos la WebPart y la añadimos en una página de WebParts. Comprobamos que un usuario con permisos puede visualizarla sin problemas.
• En cambio, un usuario sin permisos no visualiza el contenido de la WebPart debido al uso del SPSecurityTrimmedControl.

SharePoint 2010: Permisos, niveles de permisos y dependencias (II)!

Siguiendo con la serie de artículos sobre permisos y niveles de permisos en SharePoint 2010, en esta ocasión quería dejaros constancia de como programáticamente podemos hacer exactamente lo mismo que se puede hacer en la interfaz de usuario. La clave de trabajar con permisos y niveles de permisos mediante el modelo de objetos reside en conocer los objetos correspondientes:

• El objeto SPWeb y el miembro SiteGroups que nos permite añadir nuevos grupos a un sitio de SharePoint en concreto a través del método Add(). El miembro AssociatedGroups nos permitirá establecer la asociación entre el grupo creado y el sitio.
• SPRoleAssignment para poder definir cuál es el nivel de permisos que le vamos a asociar al grupo que acabamos de crear. Para poder añadir un nivel de permisos (por ejemplo Read), necesitaremos utilizar SPRoleDefinition y vincularlo con el correspondiente SPRoleAssignment a través de RoleDefinitionBidings.
• SPGroup para añadir un usuario (SPUser) al grupo creado.
• …

A modo de ejemplo, os dejo como hacer una gestión de grupos u niveles de permisos mediante el modelo de objetos de servidor de SharePoint 2010:

   1: static void ManageGroupsRolesUsers(string sManagementOption)

   2: {

   3:     using (SPSite spssSitio=

   4:         new SPSite("http://demo2010a:100/"))

   5:     {

   6:         using (SPWeb spwWeb=spssSitio.OpenWeb())

   7:         {

   8:             switch (sManagementOption)

   9:             {

  10:                 case "Create":

  11:                     //Creación de un grupo

  12:                     SPMember spmMiembro= spwWeb.SiteAdministrators["contoso\\Administrator"];

  13:                     spwWeb.SiteGroups.Add("CustomSPGroup", 

  14:                         spmMiembro,null, "Custom SharePoint Group");

  15:                     spwWeb.AssociatedGroups.Add(spwWeb.SiteGroups["CustomSPGroup"]);

  16:                     spwWeb.Update();

  17:  

  18:                     //Asignación de un nivel de permisos

  19:                     SPRoleAssignment sprAsignacionRol =

  20:                         new SPRoleAssignment(spwWeb.SiteGroups["CustomSPGroup"]);

  21:                     SPRoleDefinition sprdDefinicionRol =

  22:                         spwWeb.RoleDefinitions["Read"];

  23:                     sprAsignacionRol.RoleDefinitionBindings.Add(sprdDefinicionRol);

  24:                     spwWeb.RoleAssignments.Add(sprAsignacionRol);

  25:  

  26:                     //Asignación de un usuario

  27:                     SPUser spUsuario = 

  28:                         spwWeb.EnsureUser("contoso\\Cesarg");

  29:                     if (spUsuario!=null)

  30:                     {

  31:                         SPGroup spGrupo =

  32:                             spwWeb.Groups["CustomSPGroup"];

  33:                         spGrupo.AddUser(spUsuario);

  34:                     }

  35:  

  36:                     break;

  37:                 case "Update":

  38:                     SPRoleAssignmentCollection sprColeccionRoles =

  39:                         spwWeb.RoleAssignments;

  40:                     

  41:                     foreach (SPRoleAssignment sprAsignacionR in sprColeccionRoles)

  42:                     {

  43:                         if (sprAsignacionR.Member.Name=="CustomSPGroup")

  44:                         {

  45:                             SPRoleDefinitionBindingCollection sprdcRoleDefinitionCollection =

  46:                                 sprAsignacionR.RoleDefinitionBindings;

  47:                             foreach (SPRoleDefinition sprd in sprdcRoleDefinitionCollection)

  48:                             {

  49:                                 if (sprd.Name=="Read")

  50:                                 {

  51:                                     sprdcRoleDefinitionCollection.Remove(sprd);

  52:                                     break;

  53:                                 }                                        

  54:                             }                                   

  55:  

  56:                             //Añadimos una nueva definición

  57:                             SPRoleDefinition sprNewDefinionRol =

  58:                                 spwWeb.RoleDefinitions["Contribute"];

  59:                             sprAsignacionR.RoleDefinitionBindings.Add(sprNewDefinionRol);

  60:                             //Actualizamos todo

  61:                             sprAsignacionR.Update();

  62:                             spwWeb.Update();

  63:                         }

  64:                     }

  65:                     break;

  66:                 case "Delete":

  67:                                                 

  68:                     spwWeb.SiteGroups.Remove("CustomSPGroup");

  69:                     spwWeb.Update();

  70:                     break;

  71:                 default:

  72:                     break;

  73:             }

  74:         }

  75:     }

  76: }

SharePoint 2010: ¿Se pueden copiar flujos de trabajo entre colecciones de sitios diferentes?

La respuesta, como “casi siempre” que hablamos de algo relacionado con SharePoint es que sí…en este caso nos estamos refiriendo a flujos de trabajo creados o disponibles en SharePoint Designer 2010 (SPD 2010) que necesitemos mover a otro sitio para poder usarlos:

• Abrimos los sitios origen y destino con SPD 2010. En el sitio origen, seleccionamos el flujo a copiar.
• Arrastramos el flujo desde el sitio origen al sitio destino.
• De esta forma, se muestra un diálogo indicando que el flujo se está copiando en destino.

• El resultado es que el flujo se ha copiado sin problemas en el sitio de destino.