jueves, 18 de febrero de 2010

Instalar SharePoint 2010 mediante PowerShell

Antes de comenzar esta entrada, y sobretodo para los que no me conozcan, deciros que no soy sospechoso de ser IT Pro (aka. tío de sistemas). Desde que tengo uso de razón me he decantado por el camino del desarrollo y he dejado las cosas serias como PowerShell para los profesionales de la materia. Esto que os cuento era cierto en todos los sentidos, menos en uno: el despliegue. Siempre he estado obsesionado con automatizar los procesos de despliegue lo máximo posible con el objetivo de simplificar los procesos a la vez que minimizar posibles errores. Cuando empecé a oir hablar de SharePoint 2010 y de lo que se podía hacer con PowerShell una idea comenzó a rondarme por la cabeza. Los desarrolladores de SharePoint siempre hemos tenido una dependencia con el departamento de sistemas debido a la necesidad de crearnos máquinas virtuales de desarrollo. La instalación de MOSS no era compleja pero requería de unos mínimos conocimientos, y eso era un handicap para los desarrolladores sobretodo al comenzar a trabajar con SharePoint. La idea que me rondaba era: ¿se podrá instalar SharePoint 2010 mediante un script de PowerShell eliminando así esa dependencia directa? Desde hoy os puedo decir, con conocimiento de causa, que es posible.

Todo comienza con esta entrada de Zach Rosenfield, que contiene un enlace a unos interesantes scripts. Os recomiendo que les echéis un vistazo con tranquilidad. En concreto, os voy a explicar los pasos necesarios para utilizar dichos scripts para instalar SharePoint 2010.

Lo primero que tenemos que hacer es descargar los scripts mencionados anteriormente y dejarlos en alguna ubicación de nuestro disco (p. ejemplo, en C:\SPModule). Como no tenemos SharePoint instalado será necesario que firmemos todos los scripts que acabamos de copiar. Si no tenéis claro como llevar esto a cabo, una manera fácil es utilizar la herramienta makecert.exe. Encontraréis el ejecutable en vuestro disco si tenéis instado Visual Studio, Windows Platform SDK o Fiddler, entre otros. Una vez dispongamos de la herramienta podemos utilizar los siguientes comandos de PowerShell.

Primero, para crear una local certificate authority utilizaremos el siguiente comando:

./makecert.exe -n "CN=PowerShell Local Certificate Root" -a sha1 -eku 1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer -ss Root -sr localMachine

Después, para crear el certificado personal, utilizaremos el siguiente comando:

./makecert.exe -pe -n "CN=PowerShell User" -ss MY -a sha1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk -ic root.cer

Podemos comprobar que el certificado se ha creado correctamente de la siguiente manera:

Get-ChildItem cert:\CurrentUser\My –codesign

Finalmente, para firmar todos los scripts que hemos descargado anteriormente ejecutaremos lo siguiente:

function Add-Signing($file){ Set-AuthenticodeSignature $file @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0] }
 
Set-ExecutionPolicy AllSigned
 
ls -r -Include ("*.ps1","*.psd1","*.psm1") |%{ Add-Signing $_ }
 

Una vez hecho esto ya estamos preparados para importar los módulos que hemos descargado. Para hacerlo, bastará con ejecutar los siguientes comandos:

$env:PSModulePath = “C:\SPModule;” + $env:PSModulePath
 
Import-Module SPModule.misc
Import-Module SPModule.setup

Finalmente, para instalar SharePoint 2010, incluyendo los prerequisitos, utilizaremos los siguientes comandos:

Install-SharePoint -SetupExePath "c:\SharePoint2010-Beta\setup.exe" -PIDKey “XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
New-SharePointFarm –DatabaseAccessAccount (Get-Credential DOMAIN\username) –DatabaseServer "SQL" –FarmName "MyFarm"
Tened en cuenta que para ejecutar estos comandos necesitáis tener antes algunas cosas preparadas.
  • Los archivos de instalación de SharePoint 2010 (si habéis descargado el ejecutable completo deberéis extraer los archivos previamente)
  • La clave del producto
  • El nombre del servidor donde habéis instalado SQL 2008 SP1 CU2 o superior
  • La cuenta de dominio con los permisos necesarios de acceso a base de datos

miércoles, 17 de febrero de 2010

Variaciones de sitio en SharePoint 2010

Una de las facetas de MOSS con las que más tuve que luchar fue con sus características multilenguaje. En entradas anteriores me habréis visto escribir sobre alguna de las carencias que tenía este sistema, y sobre cómo se podía hacer algo al respecto. Con SharePoint 2010 el salto en este aspecto es enorme. Se podría decir que en MOSS únicamente era posible trabajar en varios idiomas en entornos de publicación, mientras que en entornos de colaboración lo que se nos ofrecía era más bien escaso. A partir de ahora, con SharePoint 2010 podremos disfrutar de una interfaz realmente multilenguaje en cualquier tipo de sitio. Esta afirmación es bastante arriesgada porque todavía no disponemos de la versión final del producto y porque no he tenido tiempo de probar todas y cada una de las plantillas de sitio existentes pero, por ahora, yo me arriesgaría a pensar de ese modo.

En cualquier caso, esta entrada no habla sobre las características multilenguaje de SharePoint en general, sinó sobre las variaciones de sitio que, aparentemente, no han sufrido grandes cambios. Alguno se preguntará por qué voy a hablar de algo que no ha variado demasiado desde la versión anterior. Pues bien, os voy a explicar un cambio que sí ha habido y que es importante tener en cuenta para todos aquellos que ya habíamos trabajado con variaciones en el pasado.

Si establecéis todas las propiedades necesarias para el disponer de variaciones de sitio, llegará un momento en el que creéis las jerarquías, tal y como se muestra en la figura:

image

Cuando pulsemos el botón Create Hierarchies observaremos el cambio que ha habido en este sistema. En lugar de crearse una Long Running Operation se creará un Scheduled Job que se ejecutará según una planificación determinada.

image

¿Qué tiene esto de bueno, y qué tiene de malo? Bien, para comenzar, esto tiene bastante impacto en el rendimiento de SharePoint. Si habéis trabajado con variaciones de sitio en el pasado sabréis que esta operación cargaba los servidores hasta que el proceso terminaba correctamente. Además, si por lo que sea, la operación daba algún tipo de error, el proceso se paraba y dejaba las jerarquías inconsistentes. Tampoco era posible saber el grado de finalización de la tarea. La única manera de lanzar el proceso en un momento de baja utilización de los servidores era tener una persona para darle al botón en el momento necesario, o implementar una característica que emulara esta acción, lo cual conlleva un desarrollo bastante complejo. En fin, era un proceso bastante problemático. Pero, ¿qué tiene de malo? Yo creo que esta solución no tiene problemas, pero cuando estás desarrollando lo que necesitas es que las variaciones se creen en el preciso instante en que las necesitas. En condiciones naturales no debería importarnos esperar al día siguiente para ver el resultado de nuestro trabajo pero, ¿qué pasa si no nos podemos esperar?

Siempre podemos ir a la Administración Central de SharePoint, a la sección Monitoring / Check job status / Scheduled Jobs

image

Ahí veremos el trabajo que se ha creado, bajo el nombre de Variations Create Hierarchies Job Definition. Si accedemos a las propiedades de ese trabajo podremos cambiar la planificación según nuestras necesidades o incluso lanzar la tarea manualmente pulsando el botón Run now.

image

Además, si accedemos a la sección Monitoring / Check job status / Running Jobs podremos ver el estado en el que se encuentra la tarea. No sabremos cuanto tiempo queda exactamente para completar el trabajo, pero tendremos una idea aproximada del punto en el que se encuentra.

image

En resumen, un pequeño cambio que debería mejorar el tratamiento de las variaciones de sitio y nuestro control sobre éstas.