Mantención de Bases de Datos de Tecnologías SharePoint previa una Actualización de Versión

Si te encuentras en camino a realizar una Actualización a SharePoint 2013, o incluso recién a SharePoint 2010. Más vale la pena que le pongas la atención a este artículo.

SharePoint Database Restoration ProcessUno de los descuidos más grandes que enfrentan los administradores de Plataforma SharePoint, tiene relación con las bases de datos y su mantenimiento. A pesar de que la tarea, desde SharePoint 2010 es más liviana (porque el Health Analyzer tomó parte de la responsabilidad), no deja de ser preocupante las tareas de Mantención que se deben realizar en las bases de datos de SharePoint, más aun cuando nos enfrentamos a una Actualización (Upgrade).

Nuestra Realidad

La realidad Latinoamericana, en cuando a Implementación de Upgrade o simples Implementaciones a SharePoint 2013, es un poco más lenta que en los países del norte. Tenemos clientes que recién se están subiendo a SharePoint 2010, o incluso aquellos que desde MOSS 2007, quieren darse el salto directo a SharePoint 2013.

Frente a esta situación, vale la pena revisar los mantenimientos previos y preparaciones necesarias, en nuestras bases de Datos, para el próximo desafío de la Actualización; ya sea a 2013, desde 2010; o incluso vía un pivote (2010) desde MOSS 2007.

Desde MOSS 2007 a SP 2013

La primera gran consideración, es que no está permitida la actualización directa entre estas dos versiones. Siempre será necesario pasar por un pívote de SP2010.

A pesar de aquello, se debe considerar una preparación y mantenimiento de estas bases de datos antes de pasarlas a este pívote en SP2010.

Como en MOSS 2007 no existía ningún procedimiento automático de Mantención de las Bases de Datos, este proceso lo debemos asegurar manualmente. Una de estas mantenciones es la DEFRAGMENTACIÓN.  Ya sea en Windows SharePoint Services 3.0. o MOSS2007, las bases que se consideran como parte de esta operación son: • Base de datos de búsqueda • Base de datos de perfiles • Base de datos de contenido.

Una de las formas de preparar las bases para un Upgrade, es generar el correspondiente procedimiento de Defragmentación. La Fragmentación en Bases de Datos de SharePoint tiene una tasa alta, debido al tipo de uso.

Basado en el KB http://support.microsoft.com/kb/943345/ , aquí les presento un Procedimiento SQL de Defragmentación, que es capaz de detrminar el nivel de Fragmentación de los Indices y ejecutar la operación rectificadora. La siguiente secuencia de comandos intenta realizar una desfragmentación con conexión en primer lugar y, a continuación, se pasa a una desfragmentación sin conexión si se requiere una desfragmentación sin conexión.

CREATE PROCEDURE [dbo].[proc_DefragmentIndices]
AS
    SET NOCOUNT ON
    DECLARE @objectid int
    DECLARE @indexid int
    DECLARE @command varchar(8000)
    DECLARE @baseCommand varchar(8000)
    DECLARE @schemaname sysname
    DECLARE @objectname sysname
    DECLARE @indexname sysname
    DECLARE @currentDdbId int
    SELECT @currentDdbId = DB_ID()

    PRINT CONVERT(nvarchar, GETDATE(), 126) + ‘: Starting’

    — Loop over each of the indices
    DECLARE indexesToDefrag CURSOR FOR
    SELECT
        i.object_id,
        i.index_id,
        i.name
    FROM
        sys.indexes AS i
    INNER JOIN
        sys.objects AS o
    ON
        i.object_id = o.object_id
    WHERE
        i.index_id > 0 AND
        o.type = ‘U’

    OPEN indexesToDefrag
    — Loop through the partitions.
    FETCH NEXT
    FROM
        indexesToDefrag
    INTO
        @objectid,
        @indexid,
        @indexname
    WHILE @@FETCH_STATUS = 0
    BEGIN
        — Lookup the name of the index
        SELECT
            @schemaname = s.name
        FROM
            sys.objects AS o
        JOIN
            sys.schemas AS s
        ON
            s.schema_id = o.schema_id
        WHERE
            o.object_id = @objectid

        PRINT CONVERT(nvarchar, GETDATE(), 126) + ‘: ‘ + @schemaname + ‘.’ + @indexname + ‘ is now being rebuilt.’

        — Fragmentation is bad enough that it will be more efficient to rebuild the index
        SELECT @baseCommand =
            ‘ ALTER INDEX ‘ +
                @indexname +
            ‘ ON ‘ +
                @schemaname + ‘.’ + object_name(@objectid) +
            ‘ REBUILD WITH (FILLFACTOR = 80, ONLINE = ‘

        — Use dynamic sql so this compiles in SQL 2000
        SELECT @command =
            ‘ BEGIN TRY ‘ +
               @baseCommand + ‘ON) ‘ +
            ‘ END TRY ‘ +
            ‘ BEGIN CATCH ‘ +
               — Indices with image-like columns can’t be rebuild online, so go offline
               @baseCommand + ‘OFF) ‘ +
            ‘ END CATCH ‘

        PRINT CONVERT(nvarchar, GETDATE(), 126) + ‘: Rebuilding’
        EXEC (@command)
        PRINT CONVERT(nvarchar, GETDATE(), 126) + ‘: Done’

        FETCH NEXT FROM indexesToDefrag INTO @objectid, @indexid, @indexname
    END
    CLOSE indexesToDefrag
    DEALLOCATE indexesToDefrag

    RETURN 0
GO

Desde SP 2010 a SP 2013

Ahora, ya sea por un pivote desde 2007, o estás en proceso de actualización desde 2010, debes considerar primeramente que ya no existe el tipo de Upgrade “IN-PLACE”, por lo tanto si estabas pensando en transformar ese SP2010 en un SP 2013, directamente; te comento que debes olvidarlo. Aunque es un método sencillo, una actualización IN PLACE presenta problemas de rendimiento y control para un administrador de granjas. No había manera de controlar el orden de actualización de contenido y un error en una colección de sitios determinada podía detener todo el proceso. Por lo tanto, y con mayor razón, debemos considerar el correcto mantenimiento de las Bases de Datos, para su proceso Upgrade vías Attach Database.

Contenidos y Servicios

Una de las novedades del Upgrade de SP2010 a SP2013, es que con el método ATTACH DATABASE es posible integrar a este movimiento de Bases a alguna Aplicaciones de Servicio. Estás son:

  • Aplicación Servicio de conectividad a datos empresariales
  • Aplicación del servicio de metadatos administrados
  • Aplicación de servicio PerformancePoint
  • Aplicación de servicio de búsqueda
  • Aplicación Servicio de almacenamiento seguro
  • Aplicación del servicio de perfiles de usuario

¿Mantenimiento Automático o Manual en SP2010 DBs?

Como vimos anteriormente, tanto en WSSv3 y MOSS2007, el mantenimiento de las Bases de Datos, debía hacerse manualmente. En SP2010, el proceso es automático gracias a las Reglas de Mantenimiento, sin embargo, esto no es para todas las bases de datos.

A pesar de que algunas reglas del analizador de mantenimiento de SharePoint automatizan este proceso en las bases de SP 2010, las bases de datos que se incluyen en este mantenimiento automático son:

Base de datos de configuración

  • Bases de datos de contenido
  • Base de datos de perfiles de la aplicación de servicio de perfiles de usuario
  • Base de datos de sistemas sociales de la aplicación de servicio de perfiles de usuario
  • Bases de datos de informes de la aplicación de servicio Web Analytics
  • Bases de datos provisionales de la aplicación de servicio Web Analytics
  • Bases de datos de Word Automation Services

Esto, deja fuera a algunas de las bases de datos de Aplicaciones de Servicios, que podemos mover para el Upgrade. ¿Qué podemos hacer con ellas entonces?

En el caso de las bases de datos que no son parte de esta automatización, suelen ser bases de datos que no poseen de una gran fragmentación. En todo caso, vale la pena que se esté monitoreando que esta fragmentación no sobrepase el 30%.

En este caso necesitarás de todo tu expertise en la mantención Manual de las bases de Datos. Aquí las operaciones con ALTER INDEX, DBCC SHRINKDATABASE, DBCC SHRINKFILE y el propio Management Studio serán clave.

Pero recuerda que las bases de datos de SharePoint, no son bases cualquiera, y existen operaciones compatibles y otras no. Para ver este detalle, refiérete al KB http://support.microsoft.com/kb/841057/es-es , que se aplica a tecnologías SharePoint 2007, 2010 y 2013.

¿Ya te sientes listo para el Upgrade? Adelante!

Saludos,

Charla Presencial: El que busca siempre encuentra: Tecnologías de Búsqueda Empresarial en SharePoint Server 2010

Después de mucho tiempo, finalmente, en las próximas semanas regreso a dictar charlas presenciales en Microsoft. Esta vez tendré el honor de compartir la oratoria con Cristian Vallarino, con quién repasaremos los principales temas respecto a la Búsqueda Empresarial en SP2010.

Aquí les dejo el resumen y los vínculos de registro y agenda.

Muchas organizaciones han desplegado Sharepoint Server 2010 como solución para habilitar la colaboración y manejo documental dentro de las organizaciones, dentro de estas implementaciones generalmente las configuraciones por defecto quedan establecidas como definitivas. Uno de los componentes claves de esta solución es la búsqueda empresarial.
Ven a esta charla donde repasaremos los aspectos más importantes del nuevo Servicios de Búsqueda de SharePoint Server 2010.
Lugar: Mariano Sánchez Fontecilla 310, piso 6. Microsoft Chile
Fecha: Martes 24 de Julio de 2012
Horario: 18:30 a 21:30 hrs.
Orador: Juan A. Valenzuela y Cristián Vallarino
REGISTRATE AQUI AGENDALO AQUI
SIGUELO AQUI

Servicios InterGranjas para Gobiernos Corporativos y Administrativos con Sharepoint 2010

Las aplicaciones de servicios intergranjas, nos entregan la gran potencialidad de poder optar por una implementación de Granja de Servicios, que esté disponible para proveer las funcionalidades de muchas granjas de contenidos necesarias en un gran Holding Empresarial o un Gobierno Administrativo Nacional. La eficiencia de la administración de los recursos tecnológicos como humanos; como también la eliminación de la “redundancia funcional” son claves para optar a este tipo de arquitectura, que también apoyan la Gestión del Conocimiento de las Organizaciones.

Las aplicaciones de servicio para SharePoint 2010 son tan trascendentes para la soluciones de contenido, que sin estas aplicaciones (desde un visto de muy personal), las aplicaciones de contenido de SharePoint serían casi, simples repositorios de datos.

En el contexto del ecosistema de Granja SharePoint, las Aplicaciones de Contenidos se van desencadenando en una jerarquía desde la Aplicación Web, para seguir con la Colección de Sitio que contiene finalmente el contenido de los usuarios. A la par de este modelo jerárquico de contenidos, se encuentran las Aplicaciones de Servicio. Metaforicamente, éstas aplicaciones de Servicio son verdaderos “Engranajes” de esta “Máquina” llamada SharePoint y que permite el proceso, movimiento, interacción, integración, entre otros tantos verbos, para las soluciones de contenido.

clip_image001

Ilustración 1

Esta arquitectura fundamental de la Granja SharePoint, hace necesario que las implementaciones de SharePoint supongan un tiempo, análisis y dedicación bastante extensa para disponer estas aplicaciones de servicio; que dependiendo de la necesidad del negocio del cliente, tendrán una forma de configuración determinada.

Esto también, con fines de la administración posterior, significará un esfuerzo para mantener estas aplicaciones de servicio, en un correcto estado y funcionamiento. Como se trata de elementos de la arquitectura que no están a la “luz” de los usuarios – como sí lo están los contenidos – es más fácil caer en el descuido o la poca dedicación de su monitoreo, mantención, respaldo y administración en general.

“N” Granjas, “N” Administraciones de Servicios

Cuando a esto sumamos, que en diferentes corporaciones globales, o incluso Gobiernos Administrativos, pueden existir diferentes implementaciones de Granjas SharePoint, el esfuerzo de la Administración sobre las Aplicaciones de Servicio también debe extenderse.

Tan sólo imaginemos una gran organización distribuida geográficamente, ya sea una gran corporación o un Gobierno que tiene diferentes instalaciones de SharePoint dependiendo de la repartición pública; ya sean Secretarías, Ministerios, Institutos u otras Instituciones; requieren necesariamente de varias instalaciones de Granja de SharePoint para cumplir con sus necesidades de Negocio individual. Esta misma nomenclatura se debe repartir también para las diferentes aplicaciones de Servicio que existen en cada una de estas granjas.

clip_image002

Ilustración 2

En cada una de estas Granjas de SharePoint, se deben definir los esfuerzos para Administrar las Aplicaciones de Servicio, que en último objetivo, está cumpliendo con una necesidad de negocio única.

Dos casos puntuales pueden ser:

1. El uso del servicio de Metadata Administrada, para disponer de los términos y jerarquia de la división política del país, que generalmente se puede dividir en Regiones, Estados, Provincias, Comunas, Condados, etc. Pero que finalmente es una disposición de términos jerarquizados, que siempre tendrá “una sola versión oficial”. (Ver ilustración 3)

clip_image004

2. Diferentes Servicios de Búsqueda en las diferentes reparticiones, que finalmente tienen Orígenes de Contenido en Común.

En ambos casos, las Aplicaciones de Servicios en las diferentes Granjas de las Reparticiones Gubernamentales, requerirán tener configurado y disponible este servicio; y como se trata de una necesidad en múltiples instituciones, cada configuración será redundante.

Una Solución Global

Independiente a que las Soluciones de Contenido, requieren de una administración en cada institución, existen casos, como los ejemplificados anteriormente, que podrían estar centralizados en una instancia de servicio y no redundantes.

Aquí aparece la tesis ya mencionada en la Introducción de este artículo, en la cual podemos aprovechar las condiciones y avances de arquitectura tecnológica que han logrado las Aplicaciones de Servicio en SharePoint Server 2010.

Como definición base de la plataforma de SharePoint 2010, existen ciertas Aplicaciones de Servicio que dada su arquitectura pueden estar disponibles para ser publicadas y compartidas con otras granjas de SharePoint. La concepción de esta cualidad es la misma que se ha estado planteando en este artículo, y que es poder optimizar los recursos (físicos, administrativos y humanos) y evitar la redundancia de conocimiento. Estos servicios son: Conectividad a datos empresariales (BCS), Metadados administrados (Managed Metadata), Sincronización de Perfiles de Personas (User profile Services), Búsqueda, Almacenamiento seguro de Accesos (Secure Store Services) y Web Analytics.

Esta capacidad es posible implementarla de dos formas diferentes, considerando la posibilidad de “compartir” el Servicio entre diferentes Implementaciones de Granja.

Escenario A: Dos granjas corporativas o Departamentales, con soluciones de contenidos poseen diferentes servicios, que entre ellos no se redundan, y por lo contrario comparten los servicios no disponibles en la “granja vecina”.

clip_image006

Escenario B: Este segundo escenario permite centralizar los servicios que son transversales a la organización desde una sola Granja dedicada exclusivamente a los Servicios. A este tipo de granja se le llama Granja de Publicación. Mientras tanto, aquellas granjas de contenido, donde se encuentran las soluciones de negocio son llamadas Granjas de Consumo.

clip_image008

Consideraciones de las Granjas de Publicación de Servicios

Ahora que hemos logrado evidenciar la gran oportunidad que tiene trabajar con una arquitectura de Servicios de SharePoint, en esta nomenclatura; debemos recalcar algunas consideraciones que debemos tomar para llevar a cabo esta decisión.

a) Intercambio de certificados: Para lograr la “confianza” entre las Granjas de Publicación y Consumo, necesariamente debemos generar intercambio de certificados de confianza que permitan la comunicación fluida entre ambas entidades. Para esto se debe contar con un certificado raíz y un certificado de token de seguridad (STS). El mecanismo de copia, exportación e implementación de estos certificados, requiere de privilegios que permitan la interacción con PowerShell, método con el cual se realizarán las actividades. (El detalle de estas actividades, se encuentra publicado en las Bibliotecas Técnicas de TechNet http://technet.microsoft.com/es-ar/library/ee704552.aspx )

b) Publicación del servicio en la Granja de Publicación: Esto permitirá identificar individualmente la Aplicación de Servicio que requerimos consumir desde la Granja de Contenidos (de Consumo). Si la Aplicación de Servicio no es publicada, sólo estará disponible en la propia Granja de Publicación, y para nuestro objetivo, no es viable. Esta actividad requiere necesariamente de privilegios de Administrador de la Granja. (El detalle de estas actividades, se encuentra publicado en las Bibliotecas Técnicas de TechNet http://technet.microsoft.com/es-ar/library/ee704545.aspx ).

c) Conexión desde la Granja de Consumo: Esta actividad permitirá, que desde nuestra Granja de Consumo (Contenidos), podamos generar la asociación con el servicio recién publicado desde la Granja de Publicación. Para este tipo de actividades, igual que el caso anterior, requiere ser parta de los Administradores de la Granja. Además contamos de la posibilidad de generar las actividades conducentes a la conexión, a través de Administración Central y PowerShell. (El detalle de estas actividades, se encuentra publicado en las Bibliotecas Técnicas de TechNet http://technet.microsoft.com/es-ar/library/ee704558.aspx ).

d) La nueva Aplicación de Servicio en un Grupo Proxy de la Granja de Consumo: Tal como es requerido en una Aplicación de Servicio regular en una granja simple, la Aplicación de Servicio “intergranja” debe ser considerada en un Grupo Proxy de la Granja de Consumo, de tal manera que pueda satisfacer los requerimientos de una Aplicación Web y todos los contenidos que están bajo ella. (Esta operación también es posible verla en detalle en la documentación Technet correspondiente http://technet.microsoft.com/es-ar/library/ee704550.aspx ).

Conclusión

Las aplicaciones de Servicio intergranjas, son una posibilidad tecnológica bastante potente e interesante de implementar en grandes corporaciones o administraciones de gobiernos políticos de una Nación o Estado. Cada día, las implementaciones de Granja de SharePoint 2010, ganan terrenos en estos dos ámbitos de organización, y no es un secreto que la definición de multigranjas de contenidos, dependiendo de sucursales, matrices (por el lado de corporaciones empresariales) y secretarías, ministerios, entre otros (por el lado de Gobiernos Nacionales); son una realidad recurrente. Por lo mismo, se vuelve forzoso para la eficiencia de la administración de los recursos de estas organizaciones, entender las capacidades de esta arquitectura.

Disponer de una Granja de Publicación de Servicios para una gran Organización, puede ser tan trascendente, que impactará directamente sobre el éxito y eficiencia del resto de las Granjas de Contenido disponibles en todo el ecosistema de SharePoint en aquella corporación. Los esfuerzos de estas Granjas de Contenido (Consumo) se centrarán en la administración y mantención del objetivo directo de éstas, pudiendo obviar y confiar la administración de los servicios a una entidad superior, que si puede poseer los recursos técnicos y humanos; evitando así la duplicidad de esfuerzos.

La duplicidad de esfuerzo de administración y la adecuada Gestión del Conocimiento Organizacional, dependen de aprovechar estas cualidades que SharePoint Server 2010 nos ofrece.

Abrir archivo HTML en SharePoint

Frente a alguna necesidad funcional, en ocasiones podemos necesitar subir a Bibliotecas de nuestro Sharepoint 2010, algunos archivos HTML. Sin embargo, puede presentarse el problema que al querer abrir el documento desde la biblioteca se produce la ejecución de bajada (DOWNLOAD).

Frente a esta definición debemos considerar dos configuraciones, para que la ejecución se realice directamente en el Explorador.

1. Que en las Opciones avanzadas de la Biblioteca quede especificado que queremos manejar la ejecución del archivo desde el explorador y,

image

2. Que la Aplicación Web donde se aloja la solución este configurada en las “Configuraciones Generales” como “permissive” el “Browser File Handling”.

 

image

Ambas opciones permitirán la ejecución del HTML en el explorador, aun cuando esté ubicado en una biblioteca de SharePoint.

Error en Compilación de Workflow en SharePoint Designer

error_workflow

Error: “Se han encontrado errores al compilar el flujo de trabajo. Los archivos de flujo de trabajo se han guardado pero no se pueden ejecutar” “Se ha producido un error inesperado en el servidor al asociar el flujo de trabajo”

Desde el CU de Febrero de 2011, y obviamente incluido en el SP1 de SharePoint 2010, se agrega una validación y control en el número de Types que se crean durante el proceso de compilación de un flujo. Este numero queda seteado por defecto en la plataforma en “7000”, pero puede ser configurada su ampliación a través de PowerShell. Un ejemplo de ejecución es el siguiente:

$app = get-spwebapplication “[web app url]“
$app.UserDefinedWorkflowMaximumComplexity = 8000
$app.Update()

El detalle técnico, Microsoft lo ha publicado como KB en el siguiente vínculo:

http://support.microsoft.com/kb/2557533

Webcast Technet: Charla con los expertos de Sharepoint 2010 de habla hispana

Los grupos de usuarios de SharePoint de habla hispana os proponemos un evento online un tanto diferente: os proponemos durante aproximadamente 90 minutos charlar con los principales expertos de la plataforma en países de habla de hispana. Ven con nosotros, plantéanos tus dudas y cuestiones sobre nuestro servidor favorito y averigua todo aquello que siempre quisiste saber, pero nunca te atreviste a preguntar.

Entre los participantes en la charla contaremos con algunos de los mayores conocedores de la plataforma SharePoint como: Gustavo Vélez, David Martos, Ricardo Muñoz, Juan Andrés Valenzuela, Juan Carlos González, Alberto Díaz, Daniel Seara, Héctor Insua, Manuel Herrera, Haarón González Fabian Imaz, Mario Cortés Flores, Juan Pablo Pussacq Laborde.

 

Fecha: 14-Marzo-2012
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032506778&Culture=es-ES

“Sharing The Point” en Santiago de Chile – 24/01/12

Este martes 24 de enero tendremos la posibilidad de asistir a un evento único en nuestro país. Sharing The Point, es una iniciativa de comunidades y un grupo de reconocidos expertos y speakers internacionales que han realizado charlas en Asia, Africa, Europa y Norteamerica, ahora es el turno de Chile y otros paises de Latinoamerica.

No te pierdas el nutrido grupo de expertos que estarán en el tour tales como: Joel Oleson. Paul Swider, Mark Miller, Dan Holme y Ricardo Muñoz entre otros. Ellos estarán compartiendo experiencias, mejores prácticas y lecciones aprendidas durante una gran cantidad de implementaciones de SharePoint de diversos tipos y tamaños realizadas en múltiples países.
 
Si quieres aprender mas sobre SharePoint y al mismo tiempo aprovechar la experiencia de los expertos te invitamos a reservar tu lugar en alguna de las paradas de la gira.
 
Te esperamos.

Inscribete desde aquí: http://www.sharingthepoint.org/SitePages/Home2012.aspx