This documentation is archived and is not being maintained.

Managing Audit Collection Services in Operations Manager 2007

Updated: May 31, 2011

Applies To: Operations Manager 2007 R2, Operations Manager 2007 SP1

This topic explains how to configure, use, and maintain an Audit Collection Services (ACS) implementation in your environment. This includes ACS Reporting and how to configure auditing of objects and folders. Auditing for applications, objects and folders is accomplished through group policy at the domain and local level. It does not cover ACS planning and deployment tasks. For planning and deployment guidance, see the Operations Manager 2007 Deployment Guide. This topic presumes a deployed and functioning ACS infrastructure.

Configuring and using ACS consists of the following steps:

  1. Planning and implementing your audit policy

  2. Setting the filter on the ACS Collector

  3. Configuring and using ACS reporting

  4. Maintenance

Developing an Audit Plan

ACS collects and stores all the security event log entries from computers on which it is enabled. It does so with no regard to what those events are or what they mean. It is up to you to determine what events you need captured and stored to fulfill your organization’s auditing requirements. The process of determining what those requirements are and how they translate into something that is actionable is called developing an audit plan. From the audit plan, you implement an audit policy via Group Policy objects at the domain or local level. It is the configuration of Group Policy objects that tells the security subsystem to write events to the security event log when a particular event or change occurs on a computer or in your environment. This process creates the trail of audited events that ACS collects.

Determine What Needs to be Audited

Companies are implementing ACS in response to various legal and regulatory requirements and for their own security, so you will not be able to determine by yourself what needs to be audited. You need to involve individuals from several different areas of your company to develop an effective audit plan.

  • IT Security—This team includes people who are responsible for responding to security incidents in your company and for developing the IT security policy. They should already have a good idea of the types of events and changes that need to be captured to satisfy the legal and regulatory needs of your company.

  • Management and Legal—These individuals are responsible for ensuring your company is in compliance with regulatory policies. They likely have a deep understanding of those policies and can help clarify the type of information that they need.

  • Business Process Owners—The business process owners will have the best understanding of the types of activities and events that occur in the applications that they use to run their business. These events and activities are then matched to the requirements from the legal and management areas. You need to understand these events and activities and where they occur to be able to audit them.

In general, it is not effective or efficient to audit all activity and changes and to capture all events. This approach results in gathering a great deal of noise events, which can obscure the data that is really needed when reconstructing a series of events, thereby impeding the overall process.

Audit Best Practices

Each company’s business requirements and IT environments are unique. As such, each company’s audit policy is also unique. What you choose to audit is up to you. Here are some general recommendations on what to audit:

  • Audit success and failure events in the system event category.

  • Audit success events in the policy change event category on domain controllers.

  • Audit success events in the account management category.

  • Audit success events in the logon event category.

  • Audit success events in the account logon event category on domain controllers.

  • Be specific when setting up auditing on an object.

For additional suggestions related to auditing security events, see Auditing Security Events Best practices (

Implementing Your Audit Policy

Audit plans are implemented in your environment through the modification and application of the Domain Controller Audit Group Policy, Domain Audit Group Policy, and local Audit Group Policy as needed. If your auditing plan calls for tracking interactions with Active Directory or with objects such as files, you will also need to configure the System Access Control List (SACL) on those objects. For in-depth information about Auditing and Windows security, see Windows Server 2003 Product Help Auditing Policy ( and Special Coverage: Windows Server 2008: Auditing and Compliance in Windows Server 2008 (

Audit policy settings are found in the Local Security settings in the Administrative tools folder. Audit policies for domain controllers are defined once and applied to all domain controllers. This is done via the Domain Controller Security Policy tool in the Administrative Tools folder. Audit policy for the rest of the domain member computers can be defined at the domain level in the Domain Security Policy tool, which is located in the Administrative Tools folder on all domain controllers. There are nine common audit policy categories for Windows Server 2003 and Windows Vista, as shown in the following list, and a few more for Windows Server 2008:

  • Audit account logon events

  • Audit account management

  • Audit directory service access

  • Audit logon events

  • Audit object access

  • Audit policy change

  • Audit privilege use

  • Audit process tracking

  • Audit system events

On a member server, each of these audit policy categories can be set to Success, Failure, or No auditing. On a domain controller, in both the domain controller security policies and domain security policies, the options are to Define these policy settings, Success, Failure, or No auditing. In this case, the value of No auditing indicates that the Define these policy settings option has been selected, but that neither success nor failure options have been selected. Note that the Success and Failure options are not mutually exclusive, both can be selected. For the audit directory service access and audit object access audit policy categories, you must also configure the SACLs for the objects you want audited.

To access the Audit Policy categories on a standalone server

  1. Click Start, and select Administrative Tools, Local Security Policy.

  2. Expand the Local Policies node to expose the Audit Policy node. The nine audit policy categories are listed in the results pane.

  3. Double-click the audit policy that you are interested in to open its property page. Here you can select to audit success and failure attempts at interaction, as well as get an explanation of the audit policy category on the Explain This Setting tab.

  4. Click OK to save your settings.

To access the Domain Controller Security Policy

  1. Log on to a domain controller with domain administrator rights.

  2. Click Start, and select Administrative Tools, Domain Controller Security Policy.

  3. Expand the Local Policies node to expose the Audit Policy node. The nine audit policy categories are listed in the results pane.

  4. Double-click the audit policy that you are interested in to open its property page. Here you can select to Define these policy settings and then select to audit Success and/or Failure attempts as desired.

To access the domain security policy, follow the same procedure as accessing the domain controller security policy except select Domain Security Policy in step 2 of the “To access the Domain Controller Security Policy” procedure.

Preparing the Environment

This topic presumes that you have already successfully deployed the ACS collector server role and database in your Operations Manager 2007 environment. In addition to this, you should have already deployed Operations Manager 2007 agents to the computers that you will be collecting auditing information from. These computers should appear under the Agent Managed folder in the Operations Manager 2007 Operations console Administration view.

Security Event Log Sizing

The ACS forwarder sends all security events from a monitored computer to the ACS collector server in near real time. As it does so, it updates a watermark that indicates which event was last successfully sent to the ACS collector. The ACS collector server buffers the incoming events for performance and reliability. If the ACS forwarder cannot communicate with the ACS collector, security events will not be lost to ACS as long as they can be written to the security event log. Then, when communications are restored, the ACS forwarder consults the watermark and picks up sending events where it left off. In effect, the security event log is the buffer that the ACS forwarder can use if needed.

For the security event log buffering process to work, the log must be of sufficient size to accommodate all the events that could be written to it in the case of a forwarder-to-collector communication failure. This is true regardless of which of the following security log retention methods is used: Overwrite events by days, Overwrite events as needed, or Do not overwrite events (clear log manually).

The maximum size for the security event log in Windows Server 2003 (any edition) is 4 GB. This can be set locally in the properties of the log itself, or it can be set at the domain level for domain-joined computers in the Domain Security Policy and for all domain controllers in the Domain Controller Security Policy.

Enabling ACS Forwarders

Now that you have developed your audit plan and implemented it via an audit policy, you can begin collecting audited events from the security logs of the desired computers. The ACS forwarder component is embedded in the Operations Manager agent and is disabled by default. After it is enabled, the ACS forwarder will send all security event log events to the ACS collector they are configured to send to. ACS forwarders can be enabled either through the Operations console or programmatically by using the Operations Manager 2007 command shell extension to the Windows PowerShell.

To enable the ACS forwarder via the Operations console

  1. Log on to the Operations console with an account that is scoped to manage the agents that you want to enable ACS forwarding on. This account does not need to have local administrator rights on each agent computer that you want to enable as an ACS forwarder. You can provide these credentials when you run the Enable Audit Collection task.

  2. In the Operations console, click the Monitoring button.

  3. In the Monitoring pane, expand Operations Manager, expand Agent, and then click Agent Health State. This view has two panes, and the actions in this procedure are performed in the pane on the right side.

  4. In the details pane, click all agents that you want to enable as ACS forwarders. You can make multiple selections by pressing CTRL or SHIFT.

  5. In the Actions pane, under Health Service Tasks, click Enable Audit Collection. The Run Task - Enable Audit Collection dialog box displays.

  6. In the Task Parameters section, click Override. The Override Task Parameters dialog box displays.

  7. In the Override the task parameters with the new values section, click the CollectorServer parameter; in the New Value column, type the fully qualified domain name (FQDN) of the ACS collector and then click Override.

  8. In the Task credentials section, click Other. In the User Name box, type the name of a user account that belongs to the local Administrators group on the agent computers. In the Password box, type the password for this user account. Click to expand the Domain drop-down list to view the available domains, and then click the domain of the user account.

  9. Click Run Task. The Task Status dialog box displays, tracking the progress of the task.

  10. When the task completes successfully, click Close.

If you need to change which ACS collector that an ACS forwarder is assigned to, use this same procedure except in the Override the task parameters with the new values field you need to type the FQDN of the new, desired ACS collector.

On the product CD, Windows PowerShell scripts have been included for enabling and disabling the ACS forwarder. These scripts require a set of credentials that have administrator rights on every machine for which you want to enable ACS and the name of the ACS collector server. These scripts are located on the product CD under \acs\amd64 or acs\i386. They are called EnableForwarding.ps1 for enabling ACS forwarders and DisableForwarding.ps1 for disabling ACS forwarders.

To target enabled ACS forwarders for a computer group

  1. Log on to the Operations console with an account that is in the Administrator role, and navigate to the Monitoring view.

  2. In the Monitoring view, select the Discovered Inventory object, and in the Actions pane select Change target type….

  3. Ensure that the View all targets option is selected, and in the Target column, select Computer Group. Doing this lists all the discovered computer groups in your management group.

  4. Select the computer group that you want to enable the ACS forwarder for, and right-click to open the context menu.

  5. From the context menu, select Open and Command Shell…. This sets the focus of the command shell window to the selected computer group. If you want to see specifically which computers are included in the selected group, type dir for a listing.

  6. At the command shell command prompt, type the full path to the script you want to use, followed by the name of the server that the ACS collector is installed on—for example: d:\selectcdimage\acs\i386\enableforwarding.ps1 ContosoACSCollector. You will be prompted for credentials that have administrative rights on all the computers that are agent monitored in the management group in which you are working. You must provide these credentials in domain\username format.

If you need to change which ACS collector that an ACS forwarder is assigned to, use this same procedure except type d:\selectcdimage\acs\i386\enableforwarding.ps1 <NameOfDesiredCollectorContosoACSCollector>.

Setting the Collector-Side Filter

The first step in implementing ACS was to make sure that the events you want get written to the security event logs on the desired computers. All of these events plus all the events that are written to the security event log by default are sent to the ACS collector. This can result in a very large volume of events being sent to the collector, which processes them and inserts them into the ACS database.

To reduce the volume of data being sent and to help eliminate noise events, you can configure a filter on the ACS collector. The filter is formatted as a Windows Management Instrumentation Query Language (WQL) query. The default filter is select * from AdtsEvent, which means accept all incoming events. The filter is controlled through the AdtAdmin command-line utility. The filter that can be defined is exclusive in nature only. This means you can configure the filter only to exclude events based on eventid or service name.

The AdtAdmin utility is found in the \Windows\System32\Security\AdtServer folder. For a full listing of AdtAdmin parameters and options, see the Operations Manager 2007 online help. AdtAdmin has 12 parameters in total. Only two of these switches are relevant to setting the collector site filter, as described in the following list. For a complete listing of the AdtAdmin switches, run the AdtAdmin command with the /? switch.


parameter description


Displays the WQL queries that are active on an ACS collector


Configures the WQL query that the ACS collector uses to filter audit event data

To Determine What Events to Filter Out

When you developed your audit plan and implemented your audit policy, you defined the events that you needed to capture and save. All events except those are noise events and can be filtered out. Although you make the final determination about what noise events are and what valuable events are, a list of suggested noise events can be found in Appendix A of the Security Monitoring and Attack Detection Planning Guide ( This list gives you a good place to start your filtering planning from, and it provides descriptions of the events. In addition to this list, you should consult the Planning_-_Event_Counts report under the Audit Reports folder in the Reporting view of the Operations console. This report groups all the audit events that have been received by event ID. It includes the number of events by ID and what percentage of the total number of events any single event type is. After you start collecting events and you know what each event type means, you can use this report to help you identify the most frequently occurring noise events.

There is some risk in excluding any information from an audit, but you must evaluate the magnitude of that risk against the cost in both performance and hardware that results from increased event collection load and agent load.

How to Set the Filter

You use the AdtAdmin –setquery command to set the query for the filter. This command has two subparameters, –collector, and –query, that must be used to specify which collector to connect to and to specify the syntax of the query, respectively.

To configure the ACS collector filter using AdtAdmin-setquery

  1. Log on to the ACS collector server on which you want to configure the filter with an account that is a member of the Operations Manager 2007 Administrator role.

  2. Open a command prompt, and navigate to the \Windows\System32\Security\AdtServer folder.

  3. Type the command following this syntax: adtadmin –setquery –collector:<collectorname> -query:<querysyntax>

For example, the following query filters out events generated by System, Local Service, and Network Service services, and it also filters events that have specified event ID numbers:

adtadmin -setquery -collector:"Collector Name" /query:"SELECT * FROM AdtsEvent WHERE NOT ((HeaderUser='SYSTEM' OR HeaderUser='LOCAL SERVICE' OR HeaderUser='NETWORK SERVICE') OR (EventId=538 OR EventId=566 OR EventId=672 OR EventId=680 OR (EventId>=541 AND EventId<=547)))"

To verify the filter is valid

  1. Open the Operations console, and open the Microsoft Audit Collection Services folder in the Monitoring view.

  2. Open the Collector folder, open the State View, and confirm that the collector is in a healthy state.

  3. If the collector is not in a healthy state, look in the collector’s Event View for event OpppsMgr log\ADtServer 4670 The collector was unable to start because it was unable to initialize the WMI provider.

For more information about the WQL query syntax, see Querying with WQL ( and WMI and SQL (

ACS Reporting

After auditing data is received by the ACS collector and the inbound events are filtered, the events are processed to combine common fields and remove extraneous data and then they are inserted into the ACS database. By default, ACS data is kept in the database for 14 days, though this can be modified. Operations Manager makes this data visible and consumable through its reporting feature. There is a set of report definition files specifically for ACS data that must be installed to be able to access the ACS data. This procedure presumes that you have already installed ACS reporting. For more information about installing ACS reports, see Deploying Operations Manager 2007 ACS Reporting (

ACS reports are accessible in the Reporting view of the Operations console. They are in the Audit Reports folder under the Reporting folder. ACS reporting installs 18 reports and two audit report templates. The audit report templates are used when you want to create an entirely new audit report in Microsoft SQL Server Report Builder. Report Builder is accessed by clicking the Design a new report link in the Actions pane. Here is the list of reports:

  • Access_Violation_-_Unsuccessful _Logon_Attempts

  • Account_Management_-_Domain_and_Built-in_Administrators_Changes

  • Account_Management_-_Passwords_Change_Attempts_by_Non-owner

  • Account_Managment_-_User_Accounts_Created

  • Account_Management_-_User_Accounts_Deleted

  • Forensic_-_All_Events_For_Specified_Computer

  • Forensic_-_All_Events_For_Specified_User

  • Forensic_-_All_Events_With_Specified_Event_ID

  • Planning_-_Event_Counts

  • Planning_-_Event_Counts_By_Computer

  • Planning_-_Hourly_Event_Distribution

  • Planning_-_Logon_Counts_of_Privileged_Users

  • System_Integrity_-_Audit_Failure

  • System_Integrity_-_Audit_Log_Cleared

  • Usage_-_Object_Access

  • Usage_-_Privileged_Logon

  • Usage_-_Sensitive_Security_Groups_Changes

  • Usage_-_User_Logon

  • Audit_Report_Template

  • Audit5_Report_Template

Working with Reports

In the Reporting view, there are four folders:

  • Reporting—This folder contains all reports that have been published to the SQL Server Reporting Services (SSRS) site. This includes all reports that are imported as components of management packs, reports that are designed and saved using the Report Builder tool, and any reports that you customize, save, and publish so that they are publicly available.

  • Authored Reports—This folder contains reports that you have modified from the Reporting folder and published to the SSRS site. By default, these reports are not viewable to the public, only to the publisher of the report. This is true when the report is accessed via the Operations console or the SSRS Web site, where it will appear in the My Reports folder.

  • Favorites—This folder is for reports that you use frequently and that you want to be available in the Operations Manager Web console. You can preset parameters for a published report, run the report, and then from the reports’ File menu, select Save to favorites… .

  • Scheduled Reports—This folder is for reports that you want to run on a one-time or recurring basis. Scheduling reports is useful for delivering rendered reports to a variety of locations, such as file shares, or to an e-mail address in a variety of formats, such as Microsoft Office Excel, .PDF, TIFF, CSV, and so forth.

For more information about running, publishing, and working with reports, see Managing Reporting in Operations Manager 2007 in this guide and the Reporting in Operations Manager 2007 topic in the Operations Users guide (

ACS reporting has not been fully integrated with Operations Manager Reporting yet; therefore, use of functions such as scheduling and relative dates in the generation of ACS reports might not give the desired results.


The day-to-day care and feeding of your ACS infrastructure is minimal. Most commonly, you might need to change the data-retention period that you configured during setup and change which collector a forwarder works with. For more information about how to change the ACS collector that an ACS forwarder is reporting to, see the Enabling ACS Forwarders section earlier in this topic.

Changing the ACS Data-Retention Period

Operations Manager grooms, or removes, data from its various databases at regular configurable intervals. For the Operations database, this is done in the Operations console. For the ACS database, these settings are configured during setup with a default value of 14 days. This means that every day, all database partitions (and their data) that are older than 14 days are dropped or deleted. Because of the volume of data that ACS can accumulate, 14 days is not an unreasonable setting. However, some companies might need to retain data for longer periods and they must have already planned for that when making the sizing and performance calculations for their environment. You can change the retention period for the ACS data by following this procedure.

To change the ACS data-retention period

  1. Log on to the computer running SQL Server that hosts the ACS database with an account that has administrative rights to the ACS database.

  2. Open the SQL Server Management Studio tool, and connect to the database engine.

  3. Expand the Databases folder, and select the OperationsManagerAC database.

  4. Right-click to open the context menu and select New Query….

  5. In the Query pane, type the following, where number of days to retain data + 1 equals the number of days you want to pass before data that has aged past that point is deleted. For example, if you want to retain data for 30 days, type 31

    USE OperationsManagerAC UPDATE dtConfig SET Value = <number of days to retain data + 1> WHERE Id = 6 and then click the Execute button on the toolbar. This runs the query and then opens the Messages pane, which should read (1 row(s) affected).

  6. To view the new setting, delete the previous query text from the Query pane and type SELECT * FROM dtConfig. This opens the Results pane below the Query pane.

  7. Look at the value in the sixth row; it should now equal the value you entered for <number of days to retain data + 1>.

  8. Restart the Operations Manager Audit Collection Service for this to take effect.