Chat now with support
Chat with Support

Unified Communications Analytics 8.6 - Deployment Guide

Prerequisites for your installation Installing UC Analytics Configuring UC Analytics Adding data sources for Active Directory or Azure Active Directory Adding data sources, chargeback costs, and thresholds for Exchange and Exchange Online
Permissions needed to collect Exchange on-premises or hybrid data Permissions needed to collect from native Exchange Online Creating an Exchange Configuration data source Creating an Exchange Tracking Logs data source Creating an Exchange Mailbox Contents data source Do I need both Exchange Tracking Logs and Exchange Mailbox Contents collections? Creating an Exchange IIS Logs data source Creating an Exchange Mailbox Content Summary data source Creating an Exchange Calendar data source Creating an Exchange Public Folders data source Adding Exchange Online hybrid data sources for hybrid Office 365 Adding Exchange Online data sources for native Office 365 Setting chargeback costs for Exchange Setting thresholds for Exchange metrics Omitting words when filtering by subject or body
Adding data sources, chargeback costs, and thresholds for Skype for Business/Lync Adding data sources, chargeback, and thresholds for Cisco Managing which insights can seen by users Configuring and managing subscriptions Making changes to your deployment Appendix A:Configuring Impersonation Appendix B:Configuring the Skype for Business or Lync Server Appendix C:Configuring IIS Log Files to capture ActiveSync or OWA events Appendix D:PowerShell cmdlets used by data sources Appendix E:Custom configurations and backup and recovery options Appendix F: Questions and answers about configuration

Registry settings that affect service shutdown and startup

The UC Analytics servers may be rebooted for different reasons, such as Windows Update installations. Sometimes, for computers that are heavily loaded, a reboot may cause issues if services are not allowed enough time to shut down or to start.

As of release 8.5.1, two sections in the Windows registry are updated during installation to mitigate the effects of shutting services down too quickly or not allowing services enough time to start.

Some users experienced an issue where the monthly Windows Update installation and computer reboot caused a corrupted Commit log (size is 0 kilobytes) which stopped the Storage Engine service from restarting. The computer would reboot and the Storage engine service would restart but then quickly shut down.

The issue can occur when the Storage Engine is shut down too quickly, either by Windows Update or by an administrator. A registry value controls how many milliseconds Windows will wait for services to clean up and save data before closing. The default value is 5000 milliseconds (5 seconds) for most operating systems which may not be enough time if a computer is heavily loaded.

As of release 8.5.1, the WaitToKillServiceTimeout registry setting has been updated to allow the UC Analytics Storage Engine enough time to properly shut down.

The registry key is at the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control > WaitToKillServiceTimeout

After installation, the new value is set to 900000 (milliseconds).

As of release 8.5.1, another Windows registry setting was updated to allow UC Analytics services enough time to restart. Some customers would experience system timeouts when the Data Engine service was restarting.

The timeout value for the service startup in the Windows registry has been changed. In the following registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control, a new DWORD Value, was created for ServicesPipeTimeout.

The value of ServicesPipeTimeout is set to 60000 (milliseconds).​

Appendix F: Questions and answers about configuration


This section includes common questions and provides detailed answers to help you understand and troubleshoot your UC Analytics deployment.

How often do the data collections actually gather data and when do they run?

Does a data collection only collect data once per UTC day? When I set the frequency for how often a collection will run, does the counter start at midnight (UTC/local) or does it start when the Data Engine service starts?

By default, user-created data sources that collect a once-a-day snapshot of the data run aligned with UTC midnight and, when you enable the data source or start the Data Engine, at the interval specified in the data source. You can set an execution interval for all data sources. The default interval is different for each data source, but all are more frequent than once a day.

The snapshot-type data sources, such as the Configuration data sources (Exchange/Lync/Cisco/Domain Controllers), only collect data once a day (first run in the UTC day). Even if you schedule the collections to run more than once a day, they take a “snapshot” of the data only once per UTC day. You might schedule the data sources to run multiple times per day to handle any situation when data collection fails.

For example, suppose you add an Exchange Configuration data source, schedule it to run every 6 hours, and you created the data source at 8:00 am UTC. The data source job will run (in UTC) as follows:

If an Exchange Configuration data source job is scheduled every 24 hours, and was created at 8:00 a.m. (UTC), then the data source will run (in UTC) as follows:

If a data source job is still running during its next scheduled execution time, the job execution is skipped.

Some data sources (such as the Mailbox Contents data source) collect data continuously, only collecting data that is new or changed since the previous run. These data sources do not have a run interval time that is aligned on UTC midnight. The Mailbox Contents collection job runs continuously, with a minimum interval between the job execution start times. The start time is unpredictable. If the job execution takes less time than the minimum interval, the job will start X minutes (minimum interval) after the previous job execution started. Otherwise, job execution starts immediately after the previous execution completes.

For information about which data sources collect snapshot data and which data sources collect data continuously, see How often do collections update the data? .

As of release 8.5.1, you have the option to set a explicit schedule for a data source, specifying the time and day on which the data source collection job will run.

The main advantage of setting an explicit schedule for a data source collection is that it allows you to have jobs run separately over different time periods. For environments with a large number of configured data source collections, staggering the data source jobs can improve performance.

One difference between explicitly scheduled jobs and jobs using interval scheduling is that when the service restarts, jobs with an explicit schedule will not start immediately but will wait until the next scheduled time. Interval scheduled jobs will all run immediately after the service restarts.

If the real-time requirement for some data is not high, and the running of jobs together results in performance issues, you might set certain data source jobs to run once every two days.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating