Hola comunidad!

 

Esperando que estén muy bien, paso a contarles  que durante esta semana he estado trabajando en un caso que quisiera compartir con ustedes y  aquí va:

 

Nos topamos con un escenario de una granja SharePoint 2010 SP1 con una topología de 3 capas, vale decir Servidores dedicados para Web Layer, Application Layer y Database Layer. El problema que ocurría es que cada cierto tiempo, en los distintos ambientes de la plataforma (Desarrollo, Test y Producción) algunos  Application Pools  sufrían un "Crash" y estos quedaban "Stopped", lo que obviamente resultaba en que los clientes no pudieran ver sus sitios con un error 503.

 

Y bien, comenzamos a investigar qué ocurre y descubrimos inicialmente que el log ULS para uno de los Web Servers y para uno de los App Servers presentaban un error del tipo "Performance Counter OS (pdh) call failed with error code PDH_CSTATUS_NO_MACHINE." inicialmente no vimos mucha relación entre un tema y el tema de fondo, básicamente porque este error se produce cuando no se pueden generar los contadores de performance  utilizados por la granja con la ayuda de Performance Data Helper.

 

 Más info acá: http://support.microsoft.com/kb/983081 y http://msdn.microsoft.com/en-us/library/aa939698(v=winembedded.5).aspx

 

Bien, aún así no ignoramos estos issues y detectamos que "curiosamente" el IIS Worker Process (W3WP.exe) relacionado al Application Pool caído es justamente el que inunda el Log con el error antes descrito, por lo cual ambos caminos comienzan a unirse.

 

Aquí es donde se pone entretenido:

 

Para este error en particular, existen recetas conocidas que ayudan a mitigarlo, una de ellas está en el artículo que les pasé más arriba, y otras tienen que ver también con permisos, de los servicios SharePoint 2010 Timer  ó la "Farm Account"; también puede encontrarse con llaves de registro que no existen, parámetros de manejo de nombres de los contadores de performance, o incluso las políticas que se hayan aplicado a su server mediante GPO's. por lo cual, ahora les daré una lista de ítems a revisar ordenados desde lo más típico a lo más "sofisticado" con lo que podría encontrarse en un escenario como este.

 

  1. Revisión de permisos.

 

  • Asegúrese de que las cuentas de servicio para  SharePoint 2010 Timer y SharePoint User Code Host cuentan con los privilegios suficientes dentro del server, es probable que necesite agregarlos a los grupos (Administrators, Performance Monitor Users y Performance Logs Users)

 

  • Asegúrese que las cuentas antes descritas pueden ejecutar Perfmon sin toparse con problemas de creación de contadores.

 

Si esto ya lo hizo y aún  persiste el problema, y además detectó problemas con la ejecución de Perfmon en el paso anterior, intente lo siguiente:

 

  1. Reconstrucción manual de biblioteca de contadores de performance.

 

 

  • Básicamente consiste en ejecutar el comando Lodctr.exe /R con lo cual, podrán probar nuevamente si les es posible ejecutar correctamente Perfmon.

 

¿Todavía con Issues?, continuemos…

 

  1. Process Name Format para Performance.

 

En todos los servers de la granja:

 

  • Verificar que la siguiente llave existe \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PerfProc\Performance  y dentro...  Key: REG_DWORD Nombre:  ProcessNameFormat   Valor: 1, Si no existe, crearla.

 

Reiniciar servicios SharePoint  y Probar.

 

¿Persiste aún?

 

  1. Revisión de Security Policy.

 

  • Siga el siguiente procedimiento según su escenario para llegar a editar la configuración de seguridad adecuada (Es posible que necesite ayuda de sus Administradores de Dominio Active Directory) http://technet.microsoft.com/en-us/library/cc736516(v=ws.10).aspx   fíjese en  "User Rights Assignment" buscando lo siguiente: 

Las cuentas antes mencionadas (Timer service y User code host) estén listadas para los  settings.

 

  • Replace a process level token
  • Logon as a service
  • Impersonate a client after authentication
  • Adjust memory quotas for a process

 

Espero les sea útil!

 

Saludos.

 

Gonzalo