Instalación de SharePoint Server 2013

Vamos a realizar la instalación de la nueva versión de SharePoint Server en una máquina virtual con el objeto de conocer las nuevas características y echar un vistazo a la nueva apariencia visual del producto.

Lo primero que vamos a hacer es buscar información sobre los requisitos de hardware y software que necesitaremos.

En la siguiente tabla se intenta recoger un resumen:

Lo primero que llama la atención es el hardware necesario, en cuanto a memoria RAM sobretodo. En esta nueva versión se necesita más hardware para tener SharePoint operativo con buen rendimiento.

Dependiendo del hardware que tengamos, yo recomiendo montar la máquina virtual con la versión de Windows Server 2008 y SQL Server 2008.

Para que os hagáis una idea, lo tengo instalado en una máquina virtual con unos 5,5 GB de RAM y 2 núcleos de CPU.

Lo siguiente va a ser montar la máquina virtual. Yo uso VirtualBox, y no he tenido problema alguno. Uso una máquina adicional como Controlador de Dominio y alguna característica más, pero no es necesario si se usan usuarios de la propia máquina o si se instala el controlador de dominio en la máquina de SharePoint. Es un post antiguo contaba como hacerlo (http://sharepointracks.blogspot.com.es/2012/03/sharepoint-server-2010-con-controlador.html)

La ventaja de la nueva versión de SharePoint es que en cuanto a arquitectura no difiere de su antecesor, por lo que el tema de configuración de servicios nos va a resultar muy familiar, así como el interfaz de la administración central.

Lo mismo ocurre con la instalación. Serán tres partes, instalación de prerrequisitos, instalación del producto, y configuración de la granja. El método de instalación es igual que en la versión 2010. Os pongo algunas pantallas:

En cuanto se lance el wizard de configuración de la granja empezaremos a ver los primeros cambios en la interfaz de la versión 2013 de SharePoint.

En general me parece bastante atractiva la nueva interfaz. Muy limpia e intuitiva. Seguimos teniendo la cinta de Ribbon con un ligero lavado de cara.

Como observación, comentar que si no disponéis de una máquina con suficiente RAM y buen procesador, va a resultar muy pesado trabajar con esta versión. Una buena oportunidad para ampliar o cambiar el equipo ;)

Más adelante veremos qué nuevos Service Applications o Servicios de Aplicaciones aparecen con esta nueva versión, y qué cambios importantes sufren algunos de los existentes.

Fuentes:

Requisitos de hardware y software para SharePoint 2013

Planear la compatibilidad con exploradores en SharePoint 2013

SharePoint 2013

Disponible la versión RTM de SharePoint 2013

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. Pero espero a partir de ahora poder dedicarle algo de tiempo y compartirlo con vosotros.

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

Cumulative Update de Octubre de 2012

El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Octubre de 2012.
Una vez instalado, hay que:

• Reiniciar el servicio de User Profile Synchronization
• Lanzar el Wizard de configuración del producto.

Aquí tenéis los enlaces, dependiendo de la versión:

SharePoint Server 2010: http://support.microsoft.com/kb/2687564
SharePoint Foundation 2010: http://support.microsoft.com/kb/2687566

Introducción a los despliegues automatizados. Parte II: Despliegue remoto

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.

Cumulative Update de Junio de 2012

El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Junio de 2012.
Una vez instalado, hay que:

• Reiniciar el servicio de User Profile Synchronization
• Lanzar el Wizard de configuración del producto.

Aquí tenéis los enlaces, dependiendo de la versión:

SharePoint Server 2010: http://support.microsoft.com/kb/2598354
SharePoint Foundation 2010: http://support.microsoft.com/kb/2598373

Introducción a los despliegues automatizados. Parte I: PowerShell remoto

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.