Management History helps you in tracking the changes made to directory data, including the time and the initiator of the change. As such, Management History is not intended for auditing changes in data or exploring large volumes of data changes that occurred during a long period of time.
For this reason—in addition to the Management History feature—Active Roles also provides a suite of reports for change tracking and auditing, which is part of the Active Roles Report Pack.
Both the Management History and Report Pack options have their own advantages and limitations. Consider the following before choosing the one that best suits your needs.
Use the Management History functionality to examine changes that were made to directory data via Active Roles. Management History is designed to help you answer the following typical questions:
-
Who made the most recent changes to a given user or group object?
-
Who modified a given user or group object during a set time period?
-
What changes were made to a given user object in the specified time period?
-
If any modifications have been planned for a given user or group object, were those modifications actually performed?
-
What objects did a given delegated administrator modify during the specified time period?
Management History best practices
To investigate or troubleshoot a problem that results from the inappropriate modifications of directory data, use Management History.
Management History includes a dedicated repository to store information about data changes, referred to as the Change Tracking log, and a GUI to retrieve and display information from that repository. No additional actions, such as collecting or consolidating information, are required to build Management History results.
However, Management History also has some limitations. Because of this, before you start using Management History, consider the following.
Management History limitations
The main factor to consider is the size of the Change Tracking log. To ensure real-time update of the log on all Administration Service instances, the log is normally stored in the Active Roles configuration database. This imposes some limitations on the log size.
By default, the Change Tracking log is configured to store information about changes that occurred within the last 30 days.
IMPORTANT: If you increase this setting, do it carefully. Otherwise, you might encounter the following problems:
-
Increasing the log size excessively will significantly increase the time required to build and display Change History and User Activity results.
-
As the log size grows, so does the size of the Configuration database. This considerably increases the time required to back up and restore the database. When you join an additional Administration Service instance to Active Roles replication, this also causes high network traffic during the database replication process.
-
The graphical user interface (GUI) is not suitable to represent large volumes of Management History results. As there are no filtering or paging capabilities, it can be difficult to sort through the results.
To address the limitations of Management History, Active Roles provides different means for change auditing and change-tracking reports, as a part of the Active Roles Report Pack. These reports are designed to help answer the following questions:
-
What management tasks were performed on a given object within a certain period of time?
-
What management tasks were performed on a given object during the object’s entire existence?
-
When was a certain attribute of a given object modified?
Change tracking report best practices
Change-tracking reports are based on data collected from event logs. A separate log is stored on each computer running the Administration Service, and each log only contains events generated by one Administration Service instance. Therefore, to use reports, the events from all event logs must be consolidated to form a complete audit trail.
The process of consolidating events, referred to as the data collection process, is performed by a separate Active Roles component, the Collector. With the Collector wizard, you can configure and run data collection jobs, and schedule them to run on a regular basis.
Change tracking report limitations
The main limitation of change-tracking reports is that the information must be collected and consolidated in a separate database before you can build the reports. However, the data collection process also has the following disadvantages:
-
Collecting data might be a very lengthy operation and the database size might grow unacceptable when collecting all events that occurred within a long period of time in a large environment.
-
Collecting data is impossible over slow WAN links. This limitation is inherent to the Active Roles component intended to collect data for reporting.
In certain environments, a dedicated job server might help offset the load from the Active Roles server. Processes such as dynamic group processing and tasks might use a lot of CPU and memory that would be otherwise used by other Active Roles components. In such cases, using an isolated and dedicated server for those processes can help take the burden off the main Active Roles server.
