Me centraré en MOSS 2007, que es el que presenta más dificultades. Obviamente y como recomendación inicial siempre que sea posible hay que probar la actualización en nuestros entornos de pruebas, desarrollo o máquinas virtuales. Los pasos a seguir serían los siguientes:
- Revisar copia de seguridad de las bases de datos y de las colecciones de sitios para asegurarnos de estar al día en caso de una recuperación de desastres (tema del que pretendo escribir en berve):
Con el comando "stsadm –o backup -url http://servidor/ruta -filename ruta_backup.bak" efectuamos la copia a nivel de colecciones de sitios.
Y con "stsadm -o backup -directory ruta_backup -backupmethod full -backupthreads 3" lanzamos una copia de nuestra granja.
- Debemos aprovechar para actualizar parches del sistema operativo bien vía Windows Update o con el sistema del que se disponga. Es recomendable, aunque no necesario, desactivar las actualizaciones automáticas de Windows en caso de que están habilitadas en el momento de instalar los parches de producto de WSS y MOSS.
- Es conveniente detener el servicio W3SVC (Servicio de publicación World Wide Web), si bien el algún momento de la instalación se detendrá Internet Information Services.
- Comprobar la versión de MOSS 2007 actual previa al parche desde la administración central de SharePoint.
Una vez hechas estas comprobaciones previas, procedemos a instalar:
- Ejecutar el parche de WSS 3.0 y después seguir el wizard en los distintos servidores de la granja al mismo tiempo*.- Ejecutar el parche de MOSS 2007 y después seguir el wizard en los distintos servidores de la granja al mismo tiempo*.
Dependiendo del parche, algunos lanzan el asistente automáticamente y otros tras una primera instalación, nos requieren que ejecutemos manualmente a continuación el Asistente para Configuración de Productos y Tecnologías de Sharepoint (wizard).
- Una vez instalado sin mensajes de error, comprobar que el cambio de versión há sido efectivo desde la administración central de Sharepoint -> Operaciones -> Servidores del conjunto.
- Desde la administración central de SharePoint, ver el estado de trabajos de temporizador en Operaciones -> Definiciones de los trabajos (proceso OWSTIMER )**
Para detener ese servicio: net stop sptimerv3
*Hay que llegar al mismo punto de instalación en todos los servidores que nos va a indicar en el primero de ellos (se recomienda el indexador primero y frontales después).
**En caso de error, revisar LOGs de instalación (PSCDiagnostics_) y el fichero UPGRADE.LOG (por defecto en la ruta C:\Archivos de programa\Archivos comunes\Microsoft Shared\web server extensions\12\LOGS), y se pueden volver a lanzar los trabajos desde la administración central o eliminarlos en caso de que se queden sin respuesta.
***Cómo buscar un "job " concreto para pararlo: En la base de datos de configuración de Sharepoint, buscamos en la tabla "dbo.timerunningjobs" por la columna "jobtitle" algún trabajo de "actualización". Usaremos el campo "jobid" de ese registro en la url de nuestra administración central del tipo: http://servidor:XXXXX/_admin/JobEdit.aspx?JobId=YYYYYYYYYYYYYYYYYYYYYYYY
Donde las "X" representan el puerto de administración y las "Y" el jobid que recuperamos de ,la base de datos.
Se puede forzar el Asistente para configuración de Productos y Tecnologías de SharePoint, con la herramienta de línea de comandos psconfig.exe
Desde la ruta “C:\Archivos de programa\Archivos comunes\Microsoft Shared\web server extensions\12\BIN”:
> psconfig –cmd upgrade –force
La referencia de la herramienta está en:
http://technet.microsoft.com/es-es/library/cc288944.aspx
0 Otro problema que podemos encontrar es la actualización de las bases de datos de SharePoint. Con errores del tipo:
En fichero UPGRADE.LOG
[SPManager] [ERROR] [5/20/2009 3:48:55 PM]: Upgrade [SPSearchDatabase Name=WSS_Search_PRECASAPLI01 Parent=SPDatabaseServiceInstance Name=TestSql01] failed.
[SPManager] [ERROR] [5/20/2009 3:48:55 PM]: An update conflict has occurred, and you must re-try this action. The object SPSearchDatabase Name=WSS_Search_PRECASAPLI01 Parent=SPDatabaseServiceInstance Name=TestSql01 is being updated by CASTELLANA\PreMossAdmin, in the OWSTIMER process, on machine PRECASAPLI01. View the tracing log for more information about the conflict.
[SPManager] [ERROR] [5/20/2009 3:48:55 PM]: at Microsoft.SharePoint.Administration.SPConfigurationDatabase.StoreObject(SPPersistedObject obj, Boolean storeClassIfNecessary, Boolean ensure)
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.PutObject(SPPersistedObject obj, Boolean ensure)
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPDatabase.Update()
at Microsoft.SharePoint.Search.Administration.SPSearchDatabase.CleanupIf()
at Microsoft.SharePoint.Search.Administration.SPSearchDatabase.Synchronize()
at Microsoft.SharePoint.Search.Administration.SPSearchServiceInstance.ProvisionDatabase()
at Microsoft.SharePoint.Search.Administration.SPSearchServiceInstance.Provision()
at Microsoft.SharePoint.Upgrade.SPSearchDatabaseSequence.EnableAndProvisionSearchNTService()
at Microsoft.SharePoint.Upgrade.SPSearchDatabaseSequence.PostUpgrade()
at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
Y coincidiendo con la misma hora del error, en ficheros de LOG en modo detallado (verbose) de SharePoint
Current user before SqlConnection.Open: Name: USER SID: S-1-5-21-3430773834-3238300530-293674551-41970 ImpersonationLevel: None
Current user after SqlConnection.Open: Name: USER SID: S-1-5-21-3430773834-3238300530-293674551-41970 ImpersonationLevel: None
SqlCommand: 'select @is_member = case when exists (select null from dbo.sysmembers m inner join dbo.sysusers u on u.uid = m.memberuid inner join dbo.sysusers r on r.uid = m.groupuid where (r.name = @role_name and r.issqlrole = 1) and (u.sid = SUSER_SID(@user_name))) then 1 else 0 end' CommandType: Text CommandTimeout: 1800 Parameter: '@is_member' Type: Int Size: 0 Direction: Output Value: '' Parameter: '@role_name' Type: NVarChar Size: 128 Direction: Input Value: 'db_owner' Parameter: '@user_name' Type: NVarChar Size: 128 Direction: Input Value: 'CASTELLANA\PreMossAdmin'
ConnectionString: 'Data Source=PreClusSql\TestSql01;Initial Catalog=WSS_Search_PRECASAPLI01;Integrated Security=True;Enlist=False;Connect Timeout=15' ConnectionState: Closed ConnectionTimeout: 15
Reverting to process identity
Ante esto, podemos:
Comprobar la versión del esquema de la base de datos que no permite ser actualizada con la consulta: SELECT * FROM Versions
Revisar permisos del usuario con el que estamos ejecutando el asistente de configuración de SharePoint para completar la instalación del parche. Debe ser el mismo usuario con el que se instaló la granja.
En caso de errores con las bases de datos de búsquedas de WSS, lo más rápido y sencillo es volver a crearlas desde la administración central de SharePoint (previo backup de la base de datos actual). Para ello detenemos el servicio y volvemos a arrancarlo con el nombre de la nueva base de datos que vamos a generar desde Administración Central -> Operaciones -> Servicios del Servidor -> Windows SharePoint Services Help Search
NOTA IMPORTANTE: Pueden instalarse los parches durante la instalación de MOSS en red para evitar tener que aplicarlos máquina por máquina una vez instalado el producto.
Para ello hay que extraer los parches deseados a la ruta “\Updates” del directorio de la instalación. Dicha extracción se realiza ejecutando el nombre del archivo del parche seguido del parámetro “/extract:” y la ruta de instalación relativa. P.e.:
X:\>wss-kb960010-fullfile-x86-glb.exe /extract:\MOSS\x86\Updates
Como comentario adicional, mencionar que el servicio mssearch.exe también puede dar problemas durante las instalaciones, si bien no es algo habitual, pero sí me ha sucedido puntualmente.
Podéis encontrar todo tipo de recursos y documentación acerca de la actualización de Sharepoint Server en: http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx
No hay comentarios:
Publicar un comentario