Buenas,
En este post vamos a hablar del excelente artículo que nuestro colega, y mentor Marc Biarnes, ha publicado recientemente en su blog:
http://blogs.technet.com/b/frenchpjblog/archive/2012/12/24/3542467.aspx
acerca de un problema que encontró, donde los servicios de Project Server 2010, de Eventos y Cola, se paraban misteriosamente, con una frecuencia determinada.
01.- DESCRIPCIÓN DEL PROBLEMA:
Sin ningún motivo aparente, y sin que nadie hiciera nada, los servicios de Project Server 2010 de Eventos y Cola se paraban y aparecían como deshabilitados. El síntoma llamativo detectado es que los trabajos de publicación, archivado, etc, quedaban en la cola como trabajos pendientes. Al ir a mirar como estaban estos servicios, teníamos lo siguiente:
ADMINISTRACIÓN CENTRAL DE SHAREPOINT (aparece arrancado):
CONSOLA DE SERVICIOS DE WINDOWS (aparecen deshabilitados):
Aunque insistamos en modificar las propiedades, indicando el arranque automático, la habilitación de dichos servicios y corroboremos estén arrancados, esto será por un rato, ya que nos volveremos a encontrar dichos servicios parados y deshabilitados al de un rato. Aunque reinstalar la granja era una opción que hacía desaparecer el problema, resultaba más interesante tratar de entender qué era lo que lo había causado..
02.- LA CAUSA:
Después de analizar varios ficheros de log de los logs ULS, nos pudimos dar cuenta que el fenómeno no era tan aleatorio como habíamos podido pensar inicialmente. La interrupción del servicio y su posterior deshabilitación se producen de manera periódica.
De hecho, se puede ver que una de las reglas de la tarea de verificación de salud, ejecutado cada hora, por el servicio de temporizador de SharePoint (el Timer) es el causante de éste asunto:
Específicamente, se trata de esta regla:
Para comprobar que, efectivamente tenemos razón, podemos hacer lo siguiente: teniendo los servicios arrancados, ejecutamos esta regla. Justo entonces veremos cómo los servicios se han detenido y deshabilitado, además de encontrar lo siguiente en los logs ULS:
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | Health | ag78 | Verbose | Checking the Microsoft Project Server Queuing Service windows service instance. |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | General | 0000 | Verbose | Entered SPAdvApi32.IsServiceRunning(ProjectQueueService14) |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | Health | ag7d | Verbose | The service is not disabled, but should be. |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | Health | 8fs1 | Verbose | Finished invoking the Check() method. The rule Failed. |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | Health | 8fs4 | Medium | Automatic repair is being attempted. |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | General | 0000 | Verbose | Entered SPAdvApi32.IsServiceRunning(SPAdminV4) |
OWSTIMER.EXE (0x1A60) | 0x0C48 | SharePoint Foundation | General | 0000 | Verbose | Entered SPAdvApi32.StopService(ProjectQueueService14) |
Microsoft.Office.Project.Server (0x1A08) | 0x22B0 | Project Server | General | 8zdx | High | [SERVICE] ProjectQueueService14: shutting down |
Resulta interesante observar que esta regla detiene y deshabilita los servicios de Project Server 2010 porque piensa que el estado de los servicios debe ser así. Esto es posible sólo si la regla detecta que hay un problema entre el estado de los servicios y la instancia.
Éste es el caso, precisamente. Si vamos a la Administración Central de SharePoint, comprobamos que el estado del servicio es “Arrancado”, pero si ejecutamos los comandos equivalentes de Powershell:
((Get-SPFarm).Services| where {$_.Name -match "ProjectQueueService14"}).instances
((Get-SPFarm).Services| where {$_.Name -match "ProjectEventService14"}).instances
Se obtiene una respuesta equivocada: “Deshabilitado”
Por lo tanto, es aquí donde se localiza la inconsistencia en los estados que está tratando de corregir esta regla.
03.- LA SOLUCIÓN:
Aunque el escenario para reproducir este fenómeno sigue siendo un misterio, uno puede imaginar que esto es debido a un error de configuración al iniciar los servicios de Project Server 2010 por primera vez después de la instalación. Independientemente, esto se puede corregir ejecutando el comando de Powershell en todos los servidores donde estén estos servicios instalados:
Start-SPServiceInstance -Identity <Id>
Si esto no funcionara en algún servidor, el siguiente enlace puede ofrecer información relevante al respecto: http://support.microsoft.com/kb/939308
y además tendremos que ejecutar de nuevo los sigueintes comandos de Powershell:
Stop-SPServiceInstance -Identity <Id>
Start-SPServiceInstance -Identity <Id>
donde <Id> es el identificador de la instancia del servicio, que se obtiene ejecutando el comando mencionado anteriormente: Get-SPFarm
Esperamos os resulte de utilidad
Un saludo
Jorge Puig