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.
