SharePoint Latin Rotating Header Image

14728

¿Cuál es la primer lección de un administrador SharePoint 2010?

Por ahí un compañero me comentó que tenía el siguiente error cada que intentaba agregar una solución SharePoint 2010 en su granja de desarrollo.

El error era:

Insufficient SQL database permissions for user ‘Name: DOMAIN\spadmin SID: S-1-5-21-1455513522-927615373-1062434389-54912302 ImpersonationLevel: None’ in database ‘DEV_SharePoint_Config’ on SQL Server instance ‘SPMACHINE’. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object ‘proc_putObject’, database ‘DEV_SharePoint_Config’, schema ‘dbo’.

Y bueno, al averiguar cómo estaba haciendo el deploy me dí cuenta que estaba trabajando con stsadm.exe –o addsolution sobre SharePoint 2010, este comando se sigue soportando y sin duda alguna es de mucha utilidad para aquellos administradores que gestionaban granjas de SharePoint 2007.

Se supone que en SharePoint 2010 la manera más adecuada de realizar este tipo de operaciones es usando Power Shell ya que el Snap In de SharePoint se encarga de otorgar los permisos necesarios a la cuenta en cuestión para ejecutar comandos sobre los objetos de base de datos requeridos, como por ejemplo el rol “SharePoint_Shell_Access” sobre la base de datos de configuración de la granja como se especifica aqui http://technet.microsoft.com/en-us/library/ee806878.aspx.

Ante este escenario tenemos varias opciones.

Opción 1: Hacer el deploy usando SharePoint 2010 Management Shell

Aquí se indica como hacer deploy usando Power Shell. http://technet.microsoft.com/en-us/library/cc262995.aspx#Importing el cual al cargar el Snap In de SharePoint sobre la consola de Power Shell de forma automática establece los permisos requeridos para ejecutar operaciones de configuración.

Opción 2: Asignar el rol requerido en SQL Server

1. Acceder a SQL Server Management Studio

2. Expandir el árbol para buscar la carpeta de Security y después Logins

3. Acceder a las Properties de la cuenta con la cual estamos haciendo el deploy

4. Elegir User Mappings

5. Elegir la base de datos de configuración de la granja SharePonit_Config

6. Elegir de los roles que se tienen en la base de datos el de SharePoint Shell Access y dar clic en Ok.

image

7. Ejecutar el deploy usando la consola de Windows y ejecutando el comando stsadm.exe –o addsolution –filename “path del wsp”

Opción 3: ejecutar el comando stsadm.exe usando la consola SharePoint 2010 Management Shell

La primer lección que un administrador SharePoint 2010 debe aprender es siempre utilizar SharePoint 2010 Management Shell como su principal herramienta de adminsitración SharePoint. :)

image

HG
SharePoint Developer! :)

Cuantos ingenieros se necesitan para cambiar una bombilla o crear sitios SharePoint

No es curioso, es un hecho que en el ambiente laboral relacionado con tecnologías de información y seguramente en muchos otros, nos encontramos con diversas personalidades, temperamentos y arquetipos colaborando día con día para resolver algún problema técnico o de negocio. Las personas tenemos toda una historia distinta, además de cualidades que en parte de forma consiente o inconsciente constituye la forma muy particular de ver y reaccionar ante vida, en algunos casos estas cualidades son las adecuadas para ciertos escenarios pero que en definitiva en otros no lo son.

Entonces la pregunta es, ¿cómo aprovechar lo que cada quien aporta para generar valor empresarial?, esa es una pregunta que especialistas en Management, Leadership y Coaching podrían responder sin ningún problema. Sin embargo, desde mi óptica por lo menos compartir constantemente una visión compartida con lineamientos claros es esencial para organizar y aprovechar lo que cada persona con su historia histeria y experiencia aporta.

En esta historia, el requerimiento es crear un conjunto finito de sitios con las siguientes características:

  • Cada sitio se basa en la plantilla de sitio de Trabajo en Equipo
  • Cada sitio no deberá tener herencia de permisos
  • Cada sitio deberá contar con 4 grupos “Owners, Visitors, Members, Permissions” bajo la nomenclatura “Sitio + Nombre de grupo
  • Cada sitio cuenta con usuarios específicos para cada grupo.

Lo que piensan los miembros del equipo de TI:

  • Miembro 1 – Vamos a lucirnos con la solución, hagamos un WSP con feature receiver a nivel sitio web para que cuando le den activar en las características del sitio, programáticamente los construya y configure.
  • Miembro 2 – ¿Hay urgencia por parte del cliente como para dedicar tiempo a construir y probar un WSP?, ¿se va a reutilizar la jerarquía en algún otro sitio en el futuro?, ¿conviene dejar archivos en el 12 hive y un ensamblado en el GAC con full trust assembly?, ¿vamos a implementar en DEV, QA, UAT y PROD el WSP? Yo digo que construyamos los sitios manualmente usando el UI de SharePoint.
  • Miembro 3 – Usemos scripts en un archivos *.bat que ejecute el comando stsadm.exe para crear los sitios y grupos, pasamos parámetros e nivel comando y creamos un solo archivo que cuente con todas las instrucciones necesarias.

Después los miembros dan inicio a los argumentos técnico-personales para defender su postura a capa y espada, como si fueran program managers de microsoft, correos electrónicos empiezan a fluir con preguntas que toman minutos leer y escribir de regreso para ser enviados de nuevo. El tiempo pasa, el tema sube de nivel, siguen estancados, el usuario pregunta por sus sitios y en eso Miembro 2 lo toma personal, sube de nivel su contestación y claudica ante su postura. Miembro 1 ratifica la postura de Miembro 2 con el afán de no afectar al equipo y Miembro 3 procede a ejecutar la postura del Miembro 2. Tiempo total transcurrido 2.5 horas.

Si lo analizamos, todos pierden. El espíritu del equipo se deteriora, definitivamente se ve mal y el usuario de plano esperando. Realmente cualquier postura es aceptable y totalmente factible, cada una con sus peculiaridades, estimaciones, esfuerzos y consecuencias.

Dicho esto, tengo 2 preguntas:

  1. ¿Cómo podríamos contextualizar las cosas para asegurar que antes de dar inicio a una solución construida por ingenieros, todos estén viendo hacia el mismo lugar? Esa es una respuesta que probablemente podamos encontrar aquí http://www.crecenegocios.com/los-objetivos-de-una-empresa/
  2. ¿Qué estrategia técnica conviene utilizar para un escenario donde el resultado se requiere de inmediato? A veces me pregunto si mi trabajo es preguntar, sin embargo haciendo un intento de posible respuesta, dejo algunos cuestionamientos respecto al escenario planteado y claro, su implementación.

Construyendo sitios de forma manual

Pros

  • Rápida ejecución usando UI de SharePoint
  • Cero dependencia a código, ensamblado o XMLs, todo queda en la base de datos usando los site definitions y templates propietarios de SharePoint que si están considerados para ser migrados y respaldados

Cons

  • No es repetible
  • Requiere de intervención manual para replicar en cada ambiente y por lo tanto hay margen de error

Implementación

Ubicados en el sitio en cuestión accedemos a Acciones de sitio, Configuración del sitio, Toda la configuración del sitio y al de final las galerías elegimos crear sitios o área de trabajo. Especificamos el nombre, url y los siguientes puntos:

Crear sitio Configurar grupos
image image

 

Construyendo sitios programáticamente

Pros

  • Total portabilidad a múltiples ambientes y sitios con mínimo esfuerzo de implementación
  • Aprovisionamiento y des aprovisionamiento flexible de la funcionalidad y dependencias

Cons

  • Crea una dependencia a un WSP, ensamblado en GAC y archivos en 12 hive
  • Requiere de construcción, pruebas, empaquetamiento y puesta en marcha en cada ambiente
  • Pasa a control de versiones y gestión

Implementación

En este caso vemos que utilizamos una colección especial de tipo diccionario para almacenar la URL y Nombre del sitio que deseamos crear. Existen varias formas de hacer lo mismo, en este caso recorremos la colección de plantillas SharePoint para poder elegir la que usaremos “Team Sites”. Recorremos la colección de nuestro diccionario y utilizamos la colección Webs para agregar un nuevo site pasando los argumento recolectados, lo mas importante destacar en este punto es que el ultimo argumento false indica que no se mantiene la herencia y a continuación ya dentro del sitio rompemos la herencia, posteriormente recorremos el arreglo que tiene el nombre de los grupos que estaremos construyendo programáticamente, ese código se los debo y si alguien quiere compartirlo adelante.

           uint        lcid_english = 1033;
            string      siteUrl = "http://portal.litwareinc.com";
            string[]    groupTypeNames = {"Owners","Members","Permissions","Visitors"};

            Dictionary<string, string> targetSites = new Dictionary<string, string>();
            targetSites.Add("demo1", "Sitio de demostracion 1");
            targetSites.Add("demo2", "Sitio de demostracion 2");
            targetSites.Add("demo3", "Sitio de demostracion 3");
                    
                using (SPSite site = new SPSite(siteUrl))
                {
                    SPWebTemplate siteTemplate = null;
                    SPWebTemplateCollection templateCollection = site.GetWebTemplates(lcid_english);
                    
                    foreach (SPWebTemplate template in templateCollection)
                    {
                        if (template.Title.Equals("Team Site"))
                        {
                            siteTemplate = template; 
                            break;
                        }
                    }

                    using (SPWeb web = site.OpenWeb())
                    {
                        foreach (KeyValuePair<string, string> siteInfo in targetSites)
                        {
                            using (SPWeb newWeb = web.Webs.Add(
siteInfo.Key, 
siteInfo.Value, 
string.Empty, 
lcid_english, siteTemplate, false, false))
                            {
                                newWeb.BreakRoleInheritance(false);
                                newWeb.Update();

                                foreach(string groupTypeName in groupTypeNames)
                                {
                                    string groupType = string.Format("{0} {1}",siteInfo.Value,groupTypeName);
                                    
                                    // aqui deberas crear el grupo y asignar los permisos         
                                }                                                                  
                            }                            
                        }
                    }                
                } 



Construyendo sitios con comandos stsadm.exe


Pros


  • Reutilización moderada e intervención manual para especificar sites, groups que se aprovisionaran por los comandos
  • Fácil de corregir y reaccionar ante cualquier error
  • La forma recomendada por Microsoft

Cons


  • Crea una dependencia al script que ejecuta los comandos de staadm.exe para la estructura solicitada
  • Pasa a control de versiones y gestión

Implementación


En esta alternativa utilizamos las sentencias del comando stsadm.exe ubicado en c:\program files\common files\microsoft shared\web server extensions\12\bin especificando mediante –o la opción que deseamos y mediante los parámetros especificamos lo que requerimos. Específicamente –unique describe que no queremos heredar los permisos. Subrayo en rojo la parte donde especificamos el URL del sitio que estaremos creando. En este caso estamos creando un sitio llamado Sitio 1 y posteriormente creando cuatro grupos en donde los grupos Visitors y Members tienen como dueño al grupo Permissions.


stsadm.exe -o createweb –url “el url del sitio donde crearemos/url del nuevo sitio -lcid 1033 -sitetemplate STS#0  -title “Sitio 1″ -description “” –unique


stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Permissions” -description “Permissions of the site” -ownerlogin “administrator@litwareinc.com” -type “Owner”


stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Owners” -description “Owners of the site” -ownerlogin “administrator@litwareinc.com” -type “Owner”


stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Visitors” -description “Visitors of the site” -ownerlogin “Sitio 1 Permissions” -type “Visitor”


stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Members” -description “Members of the site” -ownerlogin “Sitio 1 Permissions” -type “Member”


 


Personalmente en ocasiones he llegado a pensar, ¿qué es mas complejo?, la tecnología o la psicología, en fin.


¿Cuál es la mejor alternativa? Depende Sonrisa

Como deshabilitar el uso predeterminado de marca de InfoPath Form Services

Seguro lo has visto y hasta tus usuarios te han preguntado por qué razón en los formularios electrónicos se cuenta con el logotipo de InfoPath Form Services. Yo me pregunto cuál fue el argumento del equipo de producto de Microsoft para dejar habilitada esta opción de manera automática.  

image
La realidad es que posiblemente este sería un buen lugar para colocar nuestro logotipo de empresa, sin embargo, no se cuenta con ninguna opción disponible o soportada para modificar este logotipo. Incluso cuando contamos con un control para subir un archivos se tiene la misma imagen de InfoPath Form Serivces.

Si quieres deshabilitar estas imágenes puedes utilizar la siguiente instrucción:

stsadm -o setformsserviceproperty -pn AllowBranding -pv false


Y el resultado es que se deshabilita el uso de la imagen de marca de InfoPath Form Services en nuestra barra de opciones.

image
Así como también en la ventana para adjuntar archivos y algunas otras mas.
 

image

Para mas informacion sobre los comandos disponibles para manipulación de Form Services puedes ver aquí:  http://blogs.msdn.com/b/michael_yeager/archive/2008/12/01/using-stsadm-to-set-form-services-properties.aspx