Estos últimos meses he estado bastante ocupado y la verdad es que apenas he tenido tiempo de investigar un poco con la nueva versión de SharePoint Server. 
Ya está disponible la versión RTM, así que es tiempo de bajarla, montarla en una máquina virtual y sacar conclusiones :)
Si aún no la habéis obtenido, podéis hacerlo a través del siguiente enlace: http://technet.microsoft.com/en-US/evalcenter/hh973397
El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Octubre de 2012.
Una vez instalado, hay que:
Si en el post anterior vimos cómo configurar el entorno de TFS y el Servidor de SharePoint para permitir la ejecución remota de scripts de PowerShell, ahora vamos a ver cómo realizar en un siguiente paso dentro de una Build de TFS el despliegue automatizado.
La idea es la siguiente: generar un paquete, o paquetes en la Build, y llamar a un script “maestro” de PowerShell que se encargue de lanzar una llamada al script de despliegue de dichos paquetes. Gráficamente, esto es lo que queremos conseguir:
El Script Maestro, va a ser genérico, por lo tanto habrá unas cuantas reglas que se deberán cumplir, como por ejemplo, que el nombre del script de despliegue sea “Install.ps1”, aunque podremos cambiarlo.
El script de deploy, que se desplegará con el resto del paquete en la máquina de SharePoint, podrá tener lo necesario para ejecutar el despliegue.
La generación de paquete es importante, ya que si se sigue un cierto orden, este mecanismo de despliegue puede ser válido para los proyectos que se desee. Un ejemplo de un paquete generado por la Build es el siguiente:
En este paquete por ejemplo se incluye una documentación, el paquete de solución WSP, un archivo de configuración del que se alimenta el script de “Install.ps1”, y un script común con funciones genéricas.
En Visual Studio, se podría organizar el proyecto de la siguiente forma:
No voy a entrar a detallar cómo organizar un proyecto, porque cada uno tendrá su propia metodología o estará mas acostumbrado a realizarlo de otra forma. De cualquier manera, la idea del despliegue automatizado sigue siendo igual de válida.
Bien, lo que haremos será generar una nueva plantilla para Build de TFS:
Dentro de la secuencia principal, vamos a entrar en la de Run On Agent, para añadir dos secuencias más:
Después de la secuencia de Try, Compile and Test, vamos a añadir la secuencia de generar el paquete, y posteriormente la de lanzar el despliegue automatizado, similar a la siguiente:
No voy a describir entero el proceso de crear el paquete de despliegue, pero el objetivo es generar una carpeta de deploy, que contenga lo necesario para el despliegue, como vimos en el dibujo anterior. Un ejemplo podría ser:
Yo recomiendo generar tantas secuencias como sean necesarias a fin de que podamos hacer seguimiento de cada una de forma cómoda.
Es importante que de las secuencias anteriores, creemos el directorio donde se dejarán los ficheros. La variable que creemos para generar el directorio debería ser similar a la siguiente:
Es importante que indiquemos a la Build que queremos generar los paquetes WSP. Para ello, hay que indicar en su atributo MSBuild Arguments lo siguiente:
El resto de ficheros basta copiarlos usando las secuencias de FindMatchingItems y la de InvokeProcess llamando a “xcopy.exe” para copiar al “PackageFolder” que se definió en la variable anterior.
Ahora, para configurar la secuencia de despliegue automático, hay que indicar en qué ruta vamos a dejar el script maestro de instalación. Por ejemplo de la siguiente manera:
Dentro de la secuencia tendremos un proceso de invocación como el siguiente (InvokeProcess):
Con una configuración similar a la siguiente:
De tal forma que se llame al script maestro, indicando la máquina donde se va a realizar el despliegue, y la ruta del paquete que contiene los ficheros. En este caso yo el paquete lo estoy generando en la máquina de SharePoint en lugar de generarlo en la de TFS.
Es necesario el nombre de la máquina de SharePoint para iniciar una sesión de PowerShell remota sobre ella.
De tal forma que nuestro script maestro de PowerShell puede ser similar al siguiente:
Es importante dar permisos de administrador a la cuenta de usuario que ejecuta el proceso de Build en la máquina de SharePoint, para que deje ejecutar el script.
Este proceso, es bastante complejo y no sale bien siempre a la primera. Lo ideal es ir poco a poco partiendo de lo más básico y si es necesario ir metiendo trazas de mensajes en el WorkFlow de la plantilla de Build.
Los problemas suelen venir por la configuración de permitir la ejecución de scripts de forma remota (que lo vimos en el post anterior), por la configuración de las llamadas a los scripts maestros (si no se escapan bien las dobles comillas, se puede romper la llamada al script), y por los permisos del usuario de TFS sobre la máquina de SharePoint, que pueden no ser suficientes para permitir ciertas acciones, y habrá que asignarlos manualmente.
Con este post se cierra el tema de los despliegues automatizados. Espero que os sirva de ayuda.
El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Junio de 2012.
Una vez instalado, hay que:
La capacidad que tiene PowerShell para ejecutar acciones es muy alta. Desde comandos simples, hasta la posibilidad de hacer scripts complejos. El módulo que incorpora SharePoint de comandos de PowerShell tiene una amplia gama de comandos que permiten realizar una cantidad muy grande de operaciones de todo tipo. 
Si en otro post vimos como preparar un paquete de despliegue con una Build para SharePoint con Team Foundation, existe una posibilidad que va mas allá, permitiendo realizar el despliegue automatizado del paquete generado, como parte de la tarea de la Build. No es una tarea trivial, y hay ciertas configuraciones y conceptos que deben entenderse antes.
Como primera parte de la introducción a los despliegues automatizados de SharePoint con TFS, vamos a ver la capacidad de ejecutar comandos de PowerShell de forma remota, que va a ser el mecanismo que se usará para realizar dichos despliegues.
La idea es que desde una máquina, abramos PowerShell, y a través de una serie de comandos, podamos ejecutar acciones sobra otra máquina (que también cuenta con PowerShell, claro). Vamos con un ejemplo:
Supongamos que tenemos dos máquinas, una con SharePoint 2010 (“demossp2010dc”), y otra una máquina por ejemplo con Windows 7 (“mv7”), y queremos desde ésta última, lanzar una serie de comandos para obtener información de la Web Application y de paso crear un SPWeb dentro de una colección de sitios existente y luego eliminarla.
Lo primero que haremos, será una pequeña comprobación para ver que desde cada máquina tenemos visibilidad sobre la otra, por ejemplo mediante un ping:
En este caso ambas están en el mismo dominio, y en la máquina MV7 está ejecutando la sesión el usuario: DNSLAB\AdminW7, mientras que en la otra el usuario es: DNSLAB\AdminDe.
Ahora, en la máquina de SharePoint hay que realizar una configuración para habilitar la opción de conexión remota, y modificar la política de ejecución de scripts. Para ello, en dicha máquina:
Ejecución del comando: Enable-PSRemoting, y aceptar las confirmaciones:
Posteriormente, el comando: Enable-WSManCredSSP –Role Client * –Force
El siguiente no es obligatorio, pero si recomendable, para ampliar la memoria de ejecución: Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024
Y para la ejecución de scripts se cambia la política. Dependiendo de las necesidades y de lo permisivos que queramos ser hay distintos niveles. Yo voy a poner la más permisiva: Set-ExecutionPolicy ByPass, y aceptar la confirmación:
En principio ya estaría listo en cuanto a configuración de PowerShell, pero si intentamos desde la máquina MV7 iniciar una sesión remota, podremos ver un error como el siguiente:
Esto es debido a que el usuario de la máquina MV7 no tiene permisos sobre la otra máquina para establecer la sesión.
Solo faltaría añadir al usuario (DNSLAB\AdminW7) de la máquina desde donde se ejecutan los comandos (MV7 ) al grupo de administradores de la máquina contra la que se atacará:
Y ahora volver a hacer la prueba (siempre ejecutando el Shell de PowerShell en modo Administrador). El comando: New-PSSession –ComputerName <nombre>
Ahora podemos conectar de forma remota contra el Shell de la otra máquina para lanzar comandos.
Vamos a comprobar que efectivamente podemos por ejemplo lanzar comandos de SharePoint para obtener información, en este caso obtener las Web Application:
Nos aparece un mensaje de acceso denegado. Efectivamente, aunque hemos configurado permisos para ejecutar comandos remotamente, en cuanto a la parte de permisos de SharePoint no hemos hecho nada, y este comando está necesitando permisos de la base de datos de SharePoint para obtener la información. Por lo tanto, vamos a darle permisos al usuario de la máquina MV7 en SQL Server:
Primero añadiendo el login del usuario en caso de no existir:
Y posteriormente, en la tabla de configuración con permisos en el rol de acceso al Shell de SharePoint y como db_owner:
Aceptamos, y volvemos a hacer la prueba en la otra máquina:
Ahora si que nos ha dado la información. Vamos por ejemplo a sacar la colección de sitios principal, con idea de luego crear un SPWeb en ella:
Y ahora la creación del SPWeb:
Ha vuelto a aparecer un nuevo error. En este caso, estamos intentando atacar con el usuario AdminW7 la base de datos de contenido de la Web Application, y en esa base de datos no hemos dado ningún tipo de permiso al usuario. Por lo tanto, vamos a dárselos. Db_owner sobre la base de datos de contenido:
Volvemos a ejecutar el comando:
Y un nuevo error aparece. En este caso da menos información que el anterior. Lo que está ocurriendo es que este usuario ahora tiene permisos para hacer cambios en la base de datos, pero estamos creando un SPWeb dentro de una colección de sitios, y las colecciones de sitios tienen permisos propios. Deberemos dar permisos al usuario dentro de la colección de sitios. Yo le voy a incluir como parte de los administradores de la colección:
Y vuelvo a probar:
Ahora el resultado es el esperado. Para comprobar que también puedo eliminar la web creada:
También ha sido correcta la ejecución. Podemos terminar la sesión usando Exit-PSSession:
Hemos podido comprobar la capacidad de ejecución de comandos de forma remota con PowerShell contra SharePoint. La parte de los permisos es lo que más problemas puede causarnos, y dependiendo de lo permisivos que seamos podemos ahorrar tiempo o no. Podríamos haber dado permisos al usuario sobre toda la instancia de base de datos como db_sysadmin y no tener que ir buscando las necesarias y dar el permiso correcto.
Podéis probar a unificar los comandos lanzados en un script, ubicar dicho script en la máquina de SharePoint, y a través de una sesión remota ejecutarlo y ver el resultado, ya que hemos configurado la política para que nos deje ejecutar scripts por remoto.
El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Abril de 2012.
Una vez instalado, hay que:
En una entrada anterior vimos cómo hacer una migración de contenidos mediante DB Attach, pero efectivamente sólo se limitaba a migrar contenidos a nivel de Web Application. En esta entrada vamos a ver cómo ampliar esa migración, pudiendo realizar también la migración de los perfiles de usuario existentes en la granja de SharePoint 2007 a SharePoint 2010.
Es importante recalcar que este proceso sólo va a migrar los perfiles de usuario, pero no de las conexiones que tengamos configuradas para realizar la sincronización de perfiles. Estas conexiones hay que replicarlas de forma manual (tanto en la migración mediante DB Attach como en la migración en contexto o In Place).
Vamos a ver cómo se realizaría. Supongamos que tenemos una serie de perfiles importados, como muestra la siguiente imagen:
- Paso 1: En la granja actual, localizamos la base de datos que contiene la información de los perfiles de usuario. Por lo general tendría un nombre similar a <Nombre del SSP>_DB. Y realizamos un backup de dicha base de datos:
- Paso 2: Una vez hayamos copiado el fichero de backup a la nueva granja, procedemos a restaurarlo de la siguiente manera:
Es importante el nombre que establezcamos a la base de datos restaurada, puesto que luego ese nombre le usaremos cuando creemos el servicio de User Profile en SharePoint 2010.
- Paso 3: Si teníamos pre-creado el servicio de User Profile, lo eliminamos, junto con las bases de datos, y procedemos a crear uno nuevo que será el que usará la base de datos que acabamos de restaurar:
En la sección de Profile Database, debemos poner a la base de datos el mismo nombre que pusimos cuando la restauramos. Sino, creará una nueva y no se realizará la migración. El resto de las bases de datos las podemos dejar como están:
Una vez que termina el proceso, podemos entrar dentro del servicio para comprobar que efectivamente se ha realizado la migración correctamente:
Recordad, este proceso no migra las conexiones de importación de perfiles de usuario, sólo los perfiles y propiedades que ya estuvieran creados o importados. Manualmente habría que volver a configurar esas conexiones.
En los siguientes pasos vamos a ver el caso más simple de restauración, que es cuando únicamente se va a migrar el contenido, sin incluir las personalizaciones.
Escenario:
1. Ejecutamos la herramienta de preupgradecheck:
2. Analizamos los resultados:
En principio todo el test ha ido bien, salvo los prerequisitos del Sistema Operativo, puesto que no tenemos una arquitectura preparada para instalar Windows Server 2008. El detalle del error en el informe es este:
3. Hacer una copia de la base de datos de contenido:
De la aplicación o aplicaciones que queremos migrar, realizamos una copia de seguridad. En el ejemplo la copia la creo desde SQL Server Management:
4. El fichero de Backup lo dejamos en una ubicación de red para poder acceder a él desde la nueva plataforma.
De esta forma ya estaría lista la copia del contenido que se quiere migrar.En la nueva plataforma:
1. Desde SQL Server Management Studio restauramos la copia:
Para ello, sobre la carpeta de Databases, hacemos clic derecho y seleccionamos la opción de Restore Database:
Indicamos un nombre de base de datos que no exista, y seleccionamos el fichero de backup que hemos copiado:
2. Desde la Administración Central de SharePoint, creamos una nueva Web Application, pero teniendo en cuenta que el nombre de la base de datos que pongamos no debe coincidir con el que hemos puesto a la base de datos migrada. Nos vale la de por defecto, WSS_Content:
Una vez creada la Web Application, no debemos crear ningún Site Collection, ya que el proceso de migración va a crear los necesarios.
3. El siguiente paso es bastante importante. Vamos a lanzar un test para verificar que a la base de datos restaurada no le falta ninguna dependencia en la Web Application que acabamos de crear. Para realizar el test usamos Test-SPContentDatabase, pasando el nombre de la base de datos, y la Web Application donde va a ser migrada:
Aparece un error causado por una dependencia, que es la de “Microsoft.Office.Excel.WebUI.dwp”, pero es debido a un problema con ese WebPart, y podemos ignorarla. Cualquier otro error debería ser resuelto antes de proceder a la migración.
4. Montar la nueva base de datos en la aplicación creada:
Desde una consola de PowerShell, y en modo administrador, desmontamos la base de datos que se ha creado al crear la Web Application, que es la WSS_Content:
Seguidamente, montamos la base de datos migrada en la Web Application, y esperamos a que termine:
Tanto si ha ido bien como si no, podemos ejecutar el siguiente comando que nos dará información de los problemas que puede haber con la base de datos montada. Si no aparece resultado, es que no hay problema:
De esta forma estaría terminada la migración. Sólo nos quedaría navegar al sitio para ver que está correcto (si tenéis algún problema al iniciar sesión en el sitio, probad a hacer un iisreset):
Obviamente, el aspecto de la aplicación sigue siendo el de la versión de SharePoint 2007. Si queremos cambiar el aspecto para que tenga la apariencia de SharePoint 2010, incluyendo la cinta Ribbon, basta con hacer la “Actualización visual”. Para ello:
De esta forma ya tendría la apariencia de SharePoint 2010:
