13.9 Auditing Management Events

Auditing the management events for the Dynamic File Service, pairs, and policies is integrated with DynamicFS and is provided as a basic benefit. The purpose of the audit log is to record which logged-in user performs major management operations, such as create, delete, and modify (which includes association and disassociation of the policies with pairs).

All Dynamic File Services management actions are audited. All authentication and authorization events are audited, including both authorized and non-authorized management actions. No sensitive information is placed in the audit log. The audit log also reports when the Service is stopped and started.

The audit log reports the user’s IP address, name, and the time of access for management events. It reports System as the user when scheduled policies are run.

The audit file is protected so that it cannot be deleted or accessed by unauthorized users.

13.9.1 Viewing Audit Log Events

Dynamic File Services automatically audits the management tasks for creating and managing the Service, pairs, and policies. The following files are used for auditing:



C:\ProgramData\Dynamic File Services\audit\DswAuditLog.xml

Logs the management events for the Dynamic File Service, pairs, and policies.

AuditAndNotificationControl.xml in the C:\Program Files\Dynamic File Services\ folder, or in the folder where you installed the software.

Controls the logging behavior for the audit log.

There is no special way to view this DswAuditLog.xml file. It is an XML file, and most HTTP browsers can display well-formed XML in a readable form. You can also view the file in a text editor.

It is necessary to review information about the audited management events in combination with information reported in the Service log (DswMpcCore.log). There might be related Service events that are automatically generated from a single management task. For information about viewing the Service log, see Section 13.8, Viewing Service Events.

For example, if a pair is deleted, the deletion event is recorded in the audit log, and the related automatic disassociations of policies from the deleted pair are recorded in the Service log. The logged disassociation message lists all of the policies with a Boolean true or false indication for each of whether the disassociation occurred for that policy. You would expect a previously associated policy to report a value of true after a successful disassociation.

13.9.2 Detecting and Resolving a Corrupted Audit Log

If the audit log file becomes corrupted so that it contains malformed XML, scheduled policies might not run or the local drive history might not function.

Dynamic File Services automatically checks that the audit log file contains well-formed XML whenever an audited event is added to the Audit log file. If malformed XML is detected, the following events automatically occur:

  1. The corrupted audit log is renamed by adding a GUID to the end of the file name.

    This allows for multiple instances of the file to be saved in the …\Dynamic File Services folder.

  2. A new audit log file is started.

  3. An entry is added in the new log stating that the audit log was detected to have a problem and a new one was started.

  4. An event is sent to the Windows Event Logger stating that an improperly formatted audit log file was detected, and providing the name of the renamed log file.

  5. The audited event is written to the new audit log file.

If you are notified of a corrupted audit log event in the Windows Event Logger, you can view the old renamed audit log file in a text editor to assess the extent of the corruption. No further administrator action is required.