IntelliTrace Collector–Sharepoint 2013

Siempre es útil debuggear apps en producción, pero no siempre nos dejan instalar Visual Studio para hacer el debugging. En estos casos podemos usar IntelliTrace collector para guardar información de diagnóstico en un Intellitrace log file (.iTrace files). Nos permite registrar que pasa en nuestra app sin instalar Visual Studio o hacer cambios en el ambiente.

• Creamos un folder en nuestro servidor de producción, C:\IntelliTraceCollector (supongo que estamos con una cuenta de administrador del servidor, sino habrá que setear permisos, ver el siguiente link:http://msdn.microsoft.com/en-us/library/vstudio/hh398365.aspx#BKMK_Create_and_Configure_a_Log_File_Directory)
• Descargo la tool desde http://www.microsoft.com/en-us/download/details.aspx?id=44909
• Instalo la tool

Folder: C:\IntelliTraceCollector

Abro una consola de powershell con permisos de administrador, y ejecuto lo siguiente:

cd C:\IntelliTraceCollector

expand /f:* IntelliTraceCollection.cab. C:\IntelliTraceCollector

Ejecuto el siguiente comando en la consola de powershell:
Import-Module C:\IntelliTraceCollector\Microsoft.VisualStudio.IntelliTrace.PowerShell.dll

Para saber sobre que App Pool voy a ejecutar el tracer, ejecuto el siguiente comando:

[Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | ft Name

Este nos retorna todos los app pools de los web application. En el caso que quieras debuggear alguna feature del Central Administration, ejecuta el siguiente comando:

[Microsoft.SharePoint.Administration.SPWebService]::AdministrationService.ApplicationPools | ft Name

El mismo nos retorna el nombre del pool del Central Administration.

Ahora ejecuto lo siguiente:

Start-IntelliTraceCollection "DefaultAppPool (6.20.2014 10.27.31 AM)" "C:\IntelliTraceCollector\collection_plan.ASP.NET.default.xml" "C:\IntelliTraceCollector"

Ahora ejecuto el siguiente comando

Get-IntelliTraceCollectionStatus

El cual nos lista todos los App Pool y el estado del trace.

collection_plan.ASP.NET.default.xml: Colecciona solo IntelliTrace events y SharePoint events, incluyendo exceptions, database calls, y Web server requests. Si queres tener un trace más detallado tenes que ejecutarlo con collection_plan.ASP.NET.trace.xml

DefaultAppPool (6.20.2014 10.27.31 AM) –> es el nombre del Pool

C:\IntelliTraceCollector –> es el output de salida del archivo iTrace

Después de haber verificado que está OK el trace , reproduzco el problema, y recorro un poco el sitio de Sharepoint para coleccionar datos.

Una vez que reproduje el error, ejecuto el siguiente comando:

Checkpoint-IntelliTraceCollection "DefaultAppPool (6.20.2014 10.27.31 AM)"

Para finalizar el trace, ejecuto el comando:

Stop-IntelliTraceCollection "DefaultAppPool (6.20.2014 10.27.31 AM)"

Get-IntelliTraceCollectionStatus

En el directorio, está el archivo iTrace. El cual se puede abrir con Visual Studio 2013.

Después puedo recorrer el trace

Por ejemplo, puedes agregar el correlation ID de la excepción de Sharepoint para buscar la sección del trace que le corresponde.

Puedes ver las excepciones, web request, la información del sistema en el momento que ejecutaste el trace, la lista de threads que se dispararon y los modulos que se cargaron (.dll)

Para mayor información: http://msdn.microsoft.com/en-us/library/vstudio/hh398365.aspx

http://blogs.msdn.com/b/visualstudioalm/archive/2012/12/11/debugging-sharepoint-apps-with-intellitrace-in-visual-studio.aspx

Simple tip: qué son los archivos PSCDiagnostics y Upgrades Logs?

Los archivos PSCDiagnostics son los logs que se generan después de realizar alguna configuración sobre la granja de Sharepoint. Cada vez que abres la página del Central Administration se genera un nuevo archivo PSCDiagnostics. Estos archivos se generan en el mismo directorio de los trace logs (ULS logs).

Tienen el siguiente formato: PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log

Ejemplo:

PSCDiagnostics_8_30_2014_10_35_20_548_2921718791.log

Además estos logs son usados y analizados durante la instalación, patching, upgrades y ejecución del Sharepoint Configuration Wizard.

Cuando realizas upgrades especificamente de tu plataforma también te aparecerán los logs de upgrade, estos tienen el formato

Upgrade-DATE[YYYYMMDD]-TIME[HHMMSS-SSS].log

En el caso que el upgrade haya generado algún error, también te aparecerá otro tipo de archivo, el cual tiene el formato

Upgrade-DATE[YYYYMMDD]-TIME[HHMMSS-SSS]-error.logs

Ejemplos

Upgrade-20140825-103021-151.log

Upgrade-20140825-103021-151-error.log

 

La locación por default de estos logs son:

En SharePoint 2007: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS

En SharePoint 2010: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

En SharePoint 2013: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS

Logs de Sharepoint: problemas con GPO

En el event viewer, me aparecería el mensaje:  Tracing Service failed to create the usage log file at 'D:\Data\Logs\Sharepoint\'.  Error 0x5: Access is denied.

Claramente era por problemas de permisos. Entonces ingreso a la carpeta donde se guarda los ULS logs de Sharepoint, y agrego los grupos WSS_WPG/WSS_ADMIN_WPG/Performance Log Users con permisos de full control, y la cuenta Local System también con permisos de full control (se puede bajar un poco los permisos, pero te recomiendo estos permisos)

Pero después de un tiempo, de nuevo empezaban a aparecer los access denied en el Event Viewer. Los mismos aparecerían después de un evento de información: SceCli – Security policy in the Group policy objects has been applied successfully.

Lo que me llevo a pensar que era alguna GPO que reemplazaba los permisos de la carpeta.

Ejecuté en cmd con permisos de administrador: GPRESULT /h C:\GPreport.html

Revisé el html, y vi que había una política que reemplazaba los permisos. Hablé con los administradores del AD para modificar esta GPO, setee de nuevo los permisos, y todo quedo perfecto.

Problemas con contadores de performance (Performance counter)

Esta semana tuve que resolver un problema de alto consumo de CPU y RAM de los procesos de Sharepoint, ej: owstimer y w3wp.

El CPU variaba entre 25% a 100 % continuamente, ocasionando que nos lance el siguiente error al ingresar: HTTP Error 503. The services is unavailable

Despúes de hacer un iisreset, y reiniciar el owstimer, volvia a la normalidad, pero por un tiempo, ya que volvía a consumir cpu y ram casi al 100%.

Revisando los logs veo que hay algún problema con los contadores del sistema, ya que no podía crear contadores: Unable to create system performance counter

PDH failure on counter \NOMBRESERVIDOR\ASP.NET\\Requests Current with error Unknown error (0xc0000bbc)

Performance Counter OS (pdh) call failed with error code PDH_INVALID_HANDLE.

Unable to create system performance counter NOMBRESERVIDOR\Memory\Available Mbytes\.  The following exception was thrown: System.ComponentModel.Win32Exception: Unknown error (0xc0000bbc)   
at Microsoft.SharePoint.Win32.SPPdh.CheckReturnValue(PDH_STATUS status, Boolean throwOnError)   
at Microsoft.SharePoint.Utilities.SPPerformanceCounter.NextValue(Int32 retry, Int32 retryInterval)   
at Microsoft.SharePoint.Utilities.SPPerformanceCounterMonitorInternal.UpdateValue()   
at Microsoft.SharePoint.Utilities.SPPerformanceCounterMonitorInternal.Create(String computer, String category, String counter, String instance)

Entonces lo primero que hice es revisar si estos contadores estaban en el performance monitor, al ingresar me lanzó el siguiente error.

Revisando más en detalle con Process Monitor, veo que w3wp y owstimer está continuamente consultando por el archivo perfc409.dat

Este archivo es uno de la base de contadores del sistema. Puede haber varios archivos de este estilo perfcNNN.dat, perfdNNN.dat, perfhNNN.dat, y perfiNNN.dat. donde NNN representa el lenguaje del archivo (Ej perfc409.dat o perfc409.dat)

Perfc y perfd ​​contienen los nombres para mostrar de un grupo de contadores, perfh y perfi contienen las descripciones correspondientes. Perfc, perfd, perfh y perfi inicialmente son idénticos, durante la configuración de Windows, perfc y perfh se actualizan cotinuamente. Perfd y perfi se utilizan para el servicio, por lo que cuando se instala un nuevo paquete de servicio, los contadores de bases de perfc y perfh se sustituyen con la información en el perfd ​​actualizada y perfi.

Soluciones probadas

1. Reconstruir manualmente los contadores del sistema mediante el siguiente KB http://support.microsoft.com/kb/300956/es y el comando Lodctr.exe /R
2. Reconstruir los contadores mediante LodCtr.exe /R:PerfStringBackup.INI, donde PerfStringBackup.ini. Ver el siguiente artículo: http://blogs.technet.com/b/yongrhee/archive/2009/10/06/how-to-rebuild-performance-counters-on-windows-vista-server2008-7-server2008r2.aspx
3. Copiar los archivos perfcNNN.dat, perfdNNN.dat, perfhNNN.dat, y perfiNNN.dat de otro servidor que esté funcionando OK, y renombrarlos a los que busca el sistema. Ejecutar de nuevo Lodctr.exe /R.
4. Revisar group policies (Replace a process level token, Logon as a service, Impersonate a client after authentication, Adjust memory quotas for a process)
5. Revisar permisos. Agregar los usuarios de los application pools usados por w3wp y el usuario de farm (seteado para owstimer.exe en services.msc). Agregarlos a los grupos Administrators (temporalmente),Performance Monitor Users, Performance Logs Users.

Ninguna de las soluciones previas funcionó, por lo que seguí revisando con process monitor,y me encontré que los procesos llamaban continuamente al la siguiente clave de registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\Disable Performance Counters

Veo que tiene el valor 1, que significa en este caso que están deshabilitados la creación de contadores.

La solución final fue cambiarlo a 0, y reiniciar el server. Después del reinicio todo volvió a la normalidad.

Links útiles #46 Sharepoint 2010

1-Comparación de herramientas de ULS log viewer

http://www.jeremytaylor.net/2012/07/14/sharepoint-uls-log-viewer-tool-comparison-and-verdict/

2-BDC y ORACLE

http://msdn.microsoft.com/en-us/library/ff464424.aspx

http://jmhogua.blogspot.com.ar/2010/10/conectando-oracle-con-sharepoint.html

http://www.c-sharpcorner.com/uploadfile/anavijai/integrating-oracle-into-sharepoint-2010-using-business-data-connectivity-model/

http://sharepointjournals.wordpress.com/2011/06/06/business-connectivity-services-bcs-with-oracle-using-visual-studio-2010-part-1/

http://www.c-sharpcorner.com/uploadfile/anavijai/how-to-connect-to-the-oracle-database-using-business-connectivity-services-bcs-in-sharepoint-2010/

3-Configurar la Búsqueda federada en Sharepoint 2010

http://blog.techgalaxy.net/archives/3599

http://technet.microsoft.com/en-us/sharepoint//ff727944.aspx

4-Incoming Email en Sharepoint 2010

http://jmhogua.blogspot.com.ar/2012/07/creando-entradas-de-blog-en-sharepoint.html

5-Deployar una solution sin tener perdida de servicio en Sharepoint 2010

http://blog.ithinksharepoint.com/2012/07/16/deploying-sharepoint-wsp-solutions-without-downtime/

6-Distintos tipos de carga de balanceo (load balancing)

https://devcentral.f5.com/weblogs/dmacvittie/archive/2009/03/31/intro-to-load-balancing-for-developers-ndash-the-algorithms.aspx

7-Sharepoint Oject Model: queries data

http://extreme-sharepoint.com/2012/07/17/data-access-via-caml-queries/

8-Crear un web part asincrónico Sharepoint 2010

http://sadomovalex.blogspot.com.ar/2012/07/create-asynchronous-web-parts-for.html

9-Migrar aplicaciones web de autentificación classic a claims

http://geeks.ms/blogs/marchena/archive/2012/07/20/migrando-aplicaciones-web-de-modo-cl-225-sico-de-autenticaci-243-n-a-modo-basados-en-claims.aspx

10-Infopath y Sandboxed solutions

http://msdn.microsoft.com/en-us/library/aa946986

http://msdn.microsoft.com/en-us/library/office/ee526360.aspx

http://www.slideshare.net/aymanelhattab/sharepoint-sandboxed-solutions-and-infopath-teched-middle-east

Configuración correcta de ULS (Diagnostic Log)

En primer lugar, consideramos que los registros de ULS están diseñados con un propósito singular en cuenta: Para permitir que un administrador identifique y resuleva problemas en SharePoint. No se utilizan para ningún otro propósito dentro de SharePoint. Desde esta perspectiva, si el entorno es "perfecto" (si es posible), entonces la mejor respuesta para usted es simplemente apagarlo. Consumen una pequeña cantidad del sistema de recursos del sistema, y pueden consumir una cantidad considerable de espacio en disco.

Por otro lado, algunos clientes lo tienen seteado a verbose (detallado),todo el tiempo. Esto es un poco ridículo, si no estás investigando un problema. Está consumiendo enormes cantidades de espacio en disco y recursos del sistema potencialmente significativo y el rendimiento un poco degradado para los usuarios finales para capturar los datos que no tienen interés en realidad de mirarlo. Le sugiero que restablecer la configuración predeterminada o incluso apagar esta funcionalidad.