Manage User Access Logging

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

This document describes how to manage User Access Logging (UAL).

UAL is a feature that can help server administrators quantify the number of unique client requests of roles and services on a local server.

UAL is installed and enabled by default and collects data on a nearly real-time basis. There are only a few configuration options for UAL. This document describes these options and their intended purpose.

To learn more about the benefits of UAL, see the Get Started with User Access Logging.

In this document

The configuration options covered in this document include:

Disabling and enabling the UAL service

Collecting and removing data

Deleting data logged by UAL

Managing UAL in high volume environments

Recovering from a corrupt state

Enable Work Folders usage license tracking

Disabling and enabling the UAL service

UAL is enabled and runs by default when a computer running Windows Server 2012, or later, is installed and started for the first time. Administrators may want to turn off and disable UAL to comply with privacy requirements or other operational needs. You can turn off UAL using the Services console, from the command line, or by using PowerShell cmdlets. However, to ensure that UAL does not run again the next time the computer is started, you also need to disable the service. The following procedures describes how to turn off and disable UAL.

You can use the Get-Service UALSVC PowerShell cmdlet to retrieve information about the UAL Service including whether it is running or stopped and whether it is enabled or disabled.

To stop and disable the UAL service by using the Services console

Sign in to the server with an account that has local administrator privileges.

In Server Manager, point to Tools, and then click Services.

Scroll down and select User Access Logging Service.Click Stop the service.

Right-click the service name and select Properties. On the General tab, change the Startup type to Disabled, and then click OK.

To stop and disable UAL from the command line

Sign in to the server with an account that has local administrator privileges.

Press the Windows logo + R, then type cmd to open a Command Prompt window.

If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

Type net stop ualsvc, and then press ENTER.

Type netsh ualsvc set opmode mode=disable, and then press ENTER.

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

You can also stop and disable UAL by using the Stop-service and Disable-Ual Windows PowerShell commands.

If at a later date you want to restart and re-enable UAL you can do so with the following procedures.

To start and enable the UAL service by using the Services console

Sign in to the server an account that has local administrator privileges.

In Server Manager, point to Tools, and then click Services.

Scroll down and select User Access Logging Service.Click Start the service.

Right-click the service name and select Properties. On the General tab, change the Startup type to Automatic, and then click OK.

To start and enable UAL from the command line

Sign in to the server with local administrator credentials.

Press the Windows logo + R, then type cmd to open a Command Prompt window.

If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

Type net start ualsvc, and then press ENTER.

Type netsh ualsvc set opmode mode=enable, and then press ENTER.

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

You can also start and reenable UAL by using the Start-service and Enable-Ual Windows PowerShell commands.

Collecting UAL data

In addition to the PowerShell cmdlets described in the previous section, 12 additional cmdlets can be used to collect UAL data:

Get-UalOverview: Provides UAL related details and history of installed products and roles.

Get-UalServerUser: Provides client user access data for the local or targeted server.

Get-UalServerDevice: Provides client device access data for the local or targeted server.

Get-UalUserAccess: Provides client user access data for each role or product installed on the local or targeted server.

Get-UalDeviceAccess: Provides client device access data for each role or product installed on the local or targeted server.

Get-UalDailyUserAccess: Provides client user access data for each day of the year.

Get-UalDailyDeviceAccess: Provides client device access data for each day of the year.

Get-UalDailyAccess: Provides both client device and user access data for each day of the year.

Get-UalHyperV: Provides virtual machine data relevant to the local or targeted server.

Get-UalDns: Provides DNS client specific data of the local or targeted DNS server.

Get-UalSystemId: Provides system specific data to uniquely identify the local or targeted server.

Get-UalSystemId is meant to provide a unique profile of a server for all other data from that server to be correlated with.В If a server experiences any change in the in one of the parameters of Get-UalSystemId a new profile is created.В Get-UalOverview is meant to provide the administrator with a list of roles installed and being used on the server.

Basic features of Print and Document Services and File Services are installed by default. Therefore administrators can expect to always see information on these displayed as if the full roles are installed.В Separate UAL cmdlets are included for Hyper-V and DNS because of the unique data that UAL collects for these server roles.

A typical use case scenario for UAL cmdlets would be for an administrator to query UAL for unique client accesses over the course of a date range.В This can be done in a variety of ways.В The following is a recommended method to query unique device accesses over a date range.

This will return a verbose listing of all unique client devices, by IP address, that have made requests of the server in that date range.

‘ActivityCount’ for each unique client is limited to 65,535 per day.В Also, calling into WMI from PowerShell is only required when you query by date.В All other UAL cmdlet parameters can be used within PS queries as expected, as in the following example:

UAL retains up to two years’ worth of history. To allow retrieval of UAL data by an administrator when the service is running, UAL makes a copy of the active database file, current.mdb, to a file named GUID.mdb every 24 hours for the WMI provider’s use.

On the first day of the year, UAL will create a new GUID.mdb. The old GUID.mdb is retained as an archive for the provider’s use. After two years, the original GUID.mdb will be overwritten.

The following procedure should be performed only by an advanced user and would commonly be used by a developer testing their own instrumentation of UAL application programming interfaces.

To adjust the default 24-hour interval to make data visible to the WMI provider

Sign in to the server with an account that has local administrator privileges.

Press the Windows logo + R, then type cmd to open a Command Prompt window.

Add the registry value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WMI\AutoLogger\Sum\PollingInterval (REG_DWORD).

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

The following example shows how to add a two-minute interval (not recommended as a long term running state): REG ADD HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\Sum /v PollingInterval /t REG_DWORD /d 120000 /F

Time values are in milliseconds. The minimum value is 60 seconds, the maximum is seven days, and the default is 24 hours.

Use the Services console to stop and restart the User Access Logging Service.

Deleting data logged by UAL

UAL is not intended to be a mission critical component. Its design is intended to impact local system operations as little as possible while maintaining a high level of reliability. This also allows the administrator to manually delete UAL database and supporting files (every file in \Windows\System32\LogFiles\SUM\ directory) to meet operational needs.

To delete data logged by UAL

Stop the User Access Logging Service.

Open Windows Explorer.

Go to \Windows\System32\Logfiles\SUM\.

Delete all files in the folder.

Managing UAL in high volume environments

This section describes what an administrator can expect when UAL is used on a server with high client volume:

The maximum number of accesses that can be recorded with UAL is 65,535 per day.В UAL is not recommended for use on servers that are connected directly to the Internet, such as web servers that are connected directly to the Internet, or in scenarios where extremely high performance is the primary function of the server (such as in HPC workload environments). UAL is primarily intended for small, medium, and enterprise intranet scenarios where high volume is expected, but not as high as many deployment that serve Internet-facing traffic volume on a regular basis.

UAL in Memory: Because UAL uses the Extensible Storage Engine (ESE), UAL’s memory requirements will increase over time (or by quantity of client requests). But memory will be relinquished as the system requires it to minimize impact on system performance.

UAL on Disk: UAL’s hard disk requirements are approximately as shown below:

0 unique client records: 22M

50,000 unique client records: 80 M

500,000 unique client records: 384M

1,000,000 unique client records: 729M

Recovering from a corrupt state

This section discusses UAL’s use of the Extensible Storage Engine (ESE) at a high level and what an administrator can do if UAL data is corrupted or unrecoverable.

UAL uses ESE to optimize use of system resources and for its resistance to corruption. For more information about the benefits of ESE, see Extensible Storage Engine on MSDN.

Each time the UAL service starts ESE performs a soft recovery. For more information, see Extensible Storage Engine Files on MSDN.

If there is a problem with the soft recovery, ESE will perform a crash recovery. For more information, see JetInit Function on MSDN.

If UAL is still unable to start with the existing set of ESE files, it will delete all files in the \Windows\System32\LogFiles\SUM\ directory. After these files are deleted, the User Access Logging Service will restart and new files are created. The UAL service will then resume as if on a freshly installed computer.

The files in UAL database directory should never be moved or modified. Doing so will initiate the recovery steps, including the cleanup routine described in this section. If backups of the\Windows\System32\LogFiles\SUM\ directory are needed, then every file in this directory must be backed up together in order for a restore operation to function as expected.

Enable Work Folders usage license tracking

Work Folders server can use UAL to report client usage. Unlike UAL, Work Folder logging is not turned on by default. You can enable it with the following regkey change:

After the regkey is added, you must restart the SyncShareSvc service on the server, to enable logging.

After logging is enabled, 2 informational events get logged to the Windows Logs\Application channel each time a client connects to the server. For Work Folders, each user may have one or more client devices that connect to the server and check for data updates every 10 minutes. If the server is experiencing 1000 users, each with 2 devices the application logs will overwrite every 70 minutes, making troubleshooting unrelated issues difficult. To avoid this, you can disable the User Access Logging service temporarily, or increase the size of the server’s Windows Logs\Application channel.

Практическое руководство. Запись сведений о службах в журнал How to: Log Information About Services

По умолчанию все проекты служб Windows могут взаимодействовать с журналом событий приложения и записывать в него сведения и исключения. By default, all Windows Service projects have the ability to interact with the Application event log and write information and exceptions to it. Чтобы указать, что эта функциональность должна быть в вашем приложении, можно использовать свойство AutoLog . You use the AutoLog property to indicate whether you want this functionality in your application. По умолчанию ведение журнала включено для любой службы, созданной с помощью шаблона проекта службы Windows. By default, logging is turned on for any service you create with the Windows Service project template. Можно использовать статическую форму класса EventLog для записи сведений в журнал, и тогда не потребуется создавать экземпляр компонента EventLog или вручную регистрировать источник. You can use a static form of the EventLog class to write service information to a log without having to create an instance of an EventLog component or manually register a source.

Установщик службы автоматически регистрирует каждую службу в проекте как допустимый источник событий для журнала приложений на компьютере, где установлена служба, если включено ведение журнала. The installer for your service automatically registers each service in your project as a valid source of events with the Application log on the computer where the service is installed, when logging is turned on. Служба записывает сведения каждый раз, когда служба запускается, останавливается, приостанавливается, возобновляется, устанавливается или удаляется. The service logs information each time the service is started, stopped, paused, resumed, installed, or uninstalled. Она также записывает все возникающие ошибки. It also logs any failures that occur. Вам не нужно писать никакой код для записи в журнал при использовании этого поведения по умолчанию; служба обрабатывает это автоматически. You do not need to write any code to write entries to the log when using the default behavior; the service handles this for you automatically.

Если вы хотите выполнять запись в другой журнал событий, отличный от журнала приложения, то необходимо задать для свойства AutoLog значение false , создать собственный пользовательский журнал событий в коде службы и зарегистрировать службу в качестве источника записей для этого журнала. If you want to write to an event log other than the Application log, you must set the AutoLog property to false , create your own custom event log within your services code, and register your service as a valid source of entries for that log. Затем вам придется написать код для выполнения записи в журнал всякий раз, когда происходит интересующее вас действие. You must then write code to record entries to the log whenever an action you’re interested in occurs.

Если вы используете пользовательский журнал событий и настроили службу для записи в этот журнал, не пытайтесь обратиться к этому журналу до установки свойства ServiceName службы в коде. If you use a custom event log and configure your service application to write to it, you must not attempt to access the event log before setting the service’s ServiceName property in your code. Журналу событий нужно значение этого свойства, чтобы зарегистрировать службу в качестве допустимого источника событий. The event log needs this property’s value to register your service as a valid source of events.

Включение ведения журнала событий по умолчанию для службы To enable default event logging for your service

Установите для свойства AutoLog вашего компонента значение true . Set the AutoLog property for your component to true .

По умолчанию для свойства задано значение true . By default, this property is set to true . Вам не нужно задавать это явно, если только вы не создаете более сложную обработку, такую как оценка условия и последующая установка свойства AutoLog в зависимости от результата этого условия. You do not need to set this explicitly unless you are building more complex processing, such as evaluating a condition and then setting the AutoLog property based on the result of that condition.

Отключение ведения журнала событий для службы To disable event logging for your service

Установите для свойства AutoLog вашего компонента значение false . Set the AutoLog property for your component to false .

Настройка ведения пользовательского журнала To set up logging to a custom log

Задайте для свойства AutoLog значение false . Set the AutoLog property to false .

Чтобы использовать пользовательский журнал, необходимо задать в свойстве AutoLog значение false. You must set AutoLog to false in order to use a custom log.

Настройте экземпляр компонента EventLog в приложении службы Windows. Set up an instance of an EventLog component in your Windows Service application.

Создайте пользовательский журнал, вызвав метод CreateEventSource и задав исходную строку и имя файла журнала, который хотите создать. Create a custom log by calling the CreateEventSource method and specifying the source string and the name of the log file you want to create.

Укажите в свойстве Source компонента EventLog исходную строку, созданную на шаге 3. Set the Source property on the EventLog component instance to the source string you created in step 3.

Выполняйте запись в журнал, вызывая метод WriteEntry в экземпляре компонента EventLog . Write your entries by accessing the WriteEntry method on the EventLog component instance.

Следующий код показывает, как настроить ведение пользовательского журнала. The following code shows how to set up logging to a custom log.

В этом примере кода экземпляр компонента EventLog называется eventLog1 ( EventLog1 в Visual Basic). In this code example, an instance of an EventLog component is named eventLog1 ( EventLog1 in Visual Basic). Если на шаге 2 вы создали экземпляр с другим именем, измените код соответствующим образом. If you created an instance with another name in step 2, change the code accordingly.