Instalar SharePoint 2010 de forma desatendida con AutoSPInstaller

Brian Lalancette es el señor al que hay que hacer un monumento por haber materializado un sueño que muchos anhelábamos pero creíamos utópico: la instalación y configuración de una granja SharePoint mediante scripts.

El proyecto se llama AutoSPInstaller y para aquellos escépticos que duden si vale la pena invertir tiempo en ello os diré: habéis estado perdiendo el tiempo viviendo sin ello. Más vale tarde que nunca.

http://autospinstaller.codeplex.com/

http://blogs.technet.com/b/heyscriptingguy/archive/2010/03/23/hey-scripting-guy-march-23-2010.aspx

De forma resumida, todo el proceso de instalación de prerequisitos, binarios de SharePoint, wizard de SharePoint Technologies, wizard de configuración de granja, servicios, my site, aplicaciones web iniciales, indexación de PDF con iFilter y otros tweaks de configuración (disable loopback adapter, comprimir las carpetas de logs) queda automatizado en un PowerShell que podemos invocar y al que proporcionamos un fichero de configuración XML que contiene todos los parámetros necesarios: URLs, conexión a BD, nombres de BD, cuentas de servicio, servicios a provisionar… Este es el aspecto de SQL Server una vez configurado todo.

Esto sí que es tenerlo todo bien ordenadito, ¿eh? Y la guinda es que, al terminar todo el proceso, abrirá un navegador con tres pestañas tres, para que os maravilléis de cómo os deja funcionando el Central Administration, el My Site y el portal de inicio.

Este script requiere por nuestra parte de la confección de una carpeta con el slipstream de todos los instaladores y actualizaciones a ejecutar (incluyendo Service Packs, Cumulative Updates y Language Packs). También requiere temporalmente desactivar la UAC de Windows y deshabilitar las alertas sobre descarga de ficheros .EXE. Y por supuesto, de la creación de los usuarios de dominio para las cuentas de servicio con sus permisos iniciales

Estos requisitos quedan mucho mejor explicados en este post de Tobias Lekman. Seguidlo y comprobaréis qué facil es instalar una granja desde cero.

http://blog.lekman.com/2010/11/automated-sharepoint-2010-installations.html

Tips:

1) Recordad a ejecutar el script desde sesión de Windows iniciada con el usuario de instalación (típicamente spsetup)

2) Contad con espacio libre suficiente en disco antes de empezar la instalación (mínimo 2-3GB).

3) Usad una PassPhrase de granja compleja que contenga al menos tres de estos cuatro tipos de carácteres: mayúscula, minúscula, número, carácter no alfabético. Si no es así, el proceso fallará.

User Profile Synchronization Service de SharePoint 2010 no arranca

Para evitar teneros media hora dando vueltas por los posts de social.technet buscando las dos soluciones más típicas a este problema, intentaré resumirlas en este post.

Contexto: vamos a crear conexiones de sincronización de perfiles (User Profile Service > Configure Synchronization Connections) y el central admin nos dice, con buen criterio, que el User Profile Syncronization Service (Servicio de sincronización de perfiles de usuario) está parado.

Vamos a arrancarlo desde Services on server pero, después de un rato en Starting, se vuelve a quedar parado. Entonces consultamos Event Viewer y… imagen del drama.

The Execute method of job definition Microsoft.Office.Server.Administration.ProfileSynchronizationSetupJob (ID 745c5ecf-f4b2-4497-9526-48e18e0118c0) threw an exception. More information is included below.

An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by XXX\xxxxx, in the OWSTIMER (2572) process, on machine ESDCMOS201.  View the tracing log for more information about the conflict.

Bien, lo más probable es que la cuenta de servicio de granja (Farm Account) no esté incluida en el grupo local de Administradores del servidor. La solución pasa por incluirla y, acto seguido, reiniciar el SharePoint Timer Service (desde Services.msc o, por ejemplo, con el comando net stop sptimerv4 && net start sptimerv4 desde una consola de comandos ejecutada como administrador). Podría, en algunos casos, necesitarse del reboot completo del servidor.

Una vez superado esto, puede que el servicio siga un rato largo a Starting y luego siga parándose. En el momento en que finalmente para, si vamos al log de SharePoint podemos ver un evento del tipo:

10/20/2011 09:58:00.70     OWSTIMER.EXE (0x0B38)                       0x1164    SharePoint Portal Server          User Profiles                     g145    Unexpected    Maximum number of retries done for starting FIM SpService. Please look at ULS logs and event viewer to look for the root cause of the failure.    b34705e0-4941-485a-8faf-6c372858364c

El FIM no es otra cosa que el Forefront Identity Manager Service. Éste y el Forefront Identity Manager Synchronization Service son arrancados automáticamente por el User Profile Synchronization Service y él mismo les establece como cuenta de servicio la cuenta de sincronización de perfiles que hemos especificado al arrancar el servicio.

Con lo cual, si hacemos la inútil intentona de arrancarlos manualmente, bofetada:

¿Qué debemos garantizar entonces? Que la cuenta que estemos especificando tenga el password correcto. ¿Lo tiene? Estupendo. ¿Seguro al 100%? Mejor comprobarlo. En mi caso no era correcto y he perdido mucho tiempo comprobando otras cosas.

Si ninguno de estos dos trucos os funcionan, empezad a plantearos otras alternativas más allá de este post, como por ejemplo la que brinda mi colegui David Martos:

http://david-martos.blogspot.com/2011/05/el-servicio-de-sincronizacion-de.html

Recordad, esto es solo para conseguir (por lo menos) arrancar el servicio; lo que viene después ya es otra historia. Y como siempre, referiros a la literatura oficial que debería seguirse al pie de la letra:

• Configure Profile Synchronization: http://technet.microsoft.com/en-us/library/ee721049.aspx
• Plan account permissions: http://technet.microsoft.com/en-us/library/ff182925.aspx#permission

Habilitar edición de documentos Office desde SharePoint 2010 en Windows Server 2008

Es muy sencillo y lo hemos hecho todos ya, pero lo procedimento para que quede para la posteridad:

 

Habilitar el servicio WebClient: esto se consigue activando la Feature “Desktop Experience” de Windows Server.

• Server Manager > Features > Add Feature > Desktop Experience > Next > Install
• Pedirá reiniciar la máquina después de instalar la Feature.
• Si queréis pantallazos, aquí se los han currado mucho en la primera parte de http://www.tech-recipes.com/rx/2576/windows_server_2008_install_desktop_experience_vista_theme/
• Nota: qué conseguimos habilitando WebClient? Pues básicamente estamos habilitando la interfaz cliente WebDav para poder acceder a las colecciones de sitios del servidor de SharePoint. Una vez habilitado, podréis acceder a la raíz de un sitio a través de la ruta de red \\servidor:puerto\davwwwroot

 

Deshabilitar la opción “Enable Protected View for files located in potentially unsafe locations” de los programas cliente de Office (habrá que hacerlo para cada aplicación: Word, Excel…).

• File > Options > Trust Center > Protected View > Desmarcar la opción “Enable Protected View for files located in potentially unsafe locations”
• Pantallazos deluxe en: http://maspoint.wordpress.com/2011/03/30/office-integration-problem-with-sharepoint-2010/
• Nota: qué conseguimos deshabilitando esto? Que Office pueda abrir correctamente ficheros desde la ubicación del servidor sin mostrar los molestos mensajes:
• Word experienced an error trying to open the file
• Word has encountered a problem: There is a problem saving the file […]

Habilitar/deshabilitar los ficheros Javascript de debug de SharePoint

SharePoint viene con versiones de debug de los ficheros estándar .JS. : core.debug.js, init.debug.js… Estas versiones contienen el mismo código que los originales pero con las líneas formateadas y las funciones y variables con nomenclatura inteligible. Los JS originales tienen el código reducido al máximo para pesar el tamaño mínimo.

Alguna vez te preguntarás por qué las páginas de tu portal están cargando las versiones debug en lugar de las versiones reducidas. Por ejemplo, puedes constatar este hecho con las Internet Explorer Development Tools:

La explicación es muy simple y proviene de la configuración del atributo debug del nodo <compilation> dentro de <system.web> del web.config de tu portal.

<compilation batch="false" debug="false">   –> Ficheros JS originales

<compilation batch="false" debug="true">   –> Ficheros JS debug

Otro motivo muy importante para no olvidarse de poner debug=”false” en los entornos de producción.