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