Compartilhar via


PROJECT SERVER 2010. SE PARAN Y DESACTIVAN LOS SERVICIOS DE EVENTOS Y COLA.

Buenas,

En este post vamos a hablar del excelente artículo que nuestro colega, y mentor Marc Biarnes, ha publicado recientemente en su blog:

https://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):

clip_image001

CONSOLA DE SERVICIOS DE WINDOWS (aparecen deshabilitados):

clip_image002

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:

 

clip_image003

 

Específicamente, se trata de esta regla:

 

clip_image004

 

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: https://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