Reporte de Uso en SharePoint 2016 reporta ceros en visitas y usuarios únicos más no en las consultas de búsqueda

Este error ha sido muy común desde la versión SharePoint Server 2013, al parecer unificar en el servicio de búsqueda con las estadísticas de uso del portal, no ha sido una experiencia muy positiva ni para los que administramos las granjas de SharePoint ni para los usuarios que analizan la información que es brinda el reporte de consumo si la comparamos con las gráficas de SharePoint 2010 que nos daban mucho más información.

Primero veamos el diseño de la arquitectura de los componentes que intervienen en las estadísticas de SharePoint.

Este diagrama es de SharePoint 2010, pero en 2013 y 2016 no ha cambiado mucho.   Aunque es parte de el servicio de Search de SharePoint, los componentes que lo integran aún son parte del diseño que viene de la versión 2010.  Ahora en el diagrama modifque algunas etiquetas para actualizarlo más posible a la versión reciente y entendamos que componentes intervienen en las estádisticas de uso de SharePoint 2016.

La arquitectura del servicio de búsqueda de SharePoint 2016 a nivel mas amplio puede revisarse en los diagramas disponibles de arquitectura del sitio de technet.  Para apreciar mejor la imagen puedes visitar el siguiente enlace:

https://msdn.microsoft.com/en-us/library/office/jj163300.aspx. el proceso Analytics Processing Component es responsable de procesar las estadísticas tanto de uso como de consulta.

Para comprender donde puede fallar las estadísticas de uso de SharePoint 2016, necesitamos  evaluar cada componente y servicio que integra la solución para generar las estadísticas de uso.   Por ello veremos cada parte que la integra a continación:

Por Aplicación de Servicios

Por Aplicación de Servicios los componentes involucrados para que el reporte de uso funciona son

Search Service o Servicio de Búsqueda

Aplicación de Servicio de busqueda compuesto por los siguientes componentes:

Administration, Crawler, Content Processing, Analytics Processing, Query Processing, Index Partition.

WSS_UsageApplication

Servicio para capturar la salud de la granja y uso de las aplicaciones Web.

State Service Application

Servicio para almacenar temporalmente la información de las sesiones de los usuarios, requerido por servicios como InfoPath y WSS_UsageApplication

Por Bases de Datos

Search_Service_Application_AnalyticsReportingStoreDB 

Base de datos del servicio de búsqueda del componente

WSS_Logging

Base de datos derl servicio WSS_UsageApplication

SharePoint_StateService

Almacena temporalmente la sesión del usuario

Por Timer Jobs de la granja

Microsoft SharePoint Foundation Usage Data Import

Importa los archivos usage log para la base de datos WSS_Logging.

Microsoft SharePoint Foundation Usage Data  Maintenance

Ejecuta mantenimiento a la base de datos WSS_Logging

Microsoft SharePoint Foundation Usage Data Processing

Registra el uso de las aplicaciones web en los archivos de usage log 

Por archivos en el file system

Los archivos .usage almacenados en la ubicación configurada en Usage and Health data Collection.  Si no fue modificada la ubicación predeterminada puede ubicarla en la siguente ruta: %SytemDrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\[SharePoint Version]\Bin\Logs.

Estos archivos son trasladados a la base de datos wss_logging.

Los archivos .log almacenados en la carpeta EventStore que de forma predeterminada la ubicación es %SystemDrive%\Program Files\Microsoft Office Servers\[SharePoint Version]\Data\Office Server\Analytics_[Guid]\EventStore\[Day of the Date]

Finalmente ahora veamos que validaciones debemos de hacer cuando el reporte nos despliega cero en las visitas y usuarios únicos.

VALIDACIONES

1. Configuración de Usage and Health data Collection

Para ello debe ir al Central Administration, Monitoring, Configure usage and health data collection

Validar que este seleccionado el checkbox Enable Usage data collection 

Validar que esten seleccionados los eventos por lo menos Page Requests

Validar la ubicación del directorio donde se almacenan los archivos usage en: Usage Data Collection Settings, Log file location:

Validar que este configurado Logging DataBase la casilla Databaseserver y DatabaseName

Referencia: https://technet.microsoft.com/en-us/library/ee663480(v=office.16).aspx

2. Definición de Trabajos en el TimerJob de SharePoint

Validar que las definiciones de trabajo del Timer Job esten habilitadas y calendarizadas de la siguiente forma:

3. Ejecución del State Service o Servicio de Estado de Sesión

Validar que el State service este creado sino ejecutar en SharePoint 2016 Management Shell la sigientes líneas de comando:

$serviceApp = New-SPStateServiceApplication -Name "StateService App"

New-SPStateServiceDatabase -Name "SharePoint_StateService" -ServiceApplication $serviceApp

New-SPStateServiceApplicationProxy -Name "StateService App Proxy" -ServiceApplication $serviceApp -DefaultProxyGroup

4. WSS_UsageApplication Proxy este Iniciado

Si el proxy de este servicio aparece not started es necesario provisionarlo de nuevo con las siguientes líneas:

Get-SPServiceApplicationProxy

$usage = Get-SPServiceApplicationProxy -Identity [Guid de WSS_UsageApplication]

$usage.Provision()

5. Existencia de Archivos .usage

Verificar la ubicación de los archivos .usage y la fecha ultima de creación de los archivos

Monitoring, 

Para ello debe ir al Central Administration, Monitoring, Configure usage and health data collection

Validar la ubicación del directorio donde se almacenan los archivos usage en: Usage Data Collection Settings, Log file location:

Luego validar que los archivos .usage existan con fecha actual.  En caso de no estar deberá validar que este habilitado la configuración de Usage and Health data Collection (punto no.1).

6. Validar si los reportes ya generan datos un día después

Lamentablemente no hay forma de visualizar esta información sino un día después, asi que habrá que esperar.

SharePoint4Fun,

Juan Manuel Herrera Ocheita