Chat now with support
Chat with Support

Change Auditor 7.1.1 - Installation Guide

Installation Overview Install Change Auditor Add Users to Change Auditor Security Groups Connecting to the Clients Deploy Change Auditor Agents Upgrade Change Auditor Installation Notes and Best Practices Multi-Forest Deployments Foreign Forest Agent Deployment Workstation Agent Deployment Agent Comparison Install an agent to audit ADAM (AD LDS) on workgroup servers Active Roles Integration Quest GPOADmin Integration Windows Installer Command Line Options

Change Auditor agents

Once you have installed the coordinators and client, you are ready to deploy agents to the servers and workstations.

Quest recommends that you deploy a server agent to all servers (domain controllers and member servers) to track configuration changes in real time. For workstations, deploy a workstation agent to only those that you want to monitor for login activity. See Agent behavior notes for information about how the different types of agents connect to the coordinators in your environment and the limits set for agent connections.

When a change is made on a server running an agent, the change information (audited event) is captured and forwarded to the specified database.

NOTE: See the Installation Notes and Best Practices for notes on deploying agents for Change Auditor for Exchange and Change Auditor for Authentication Services.

The Deployment page in the client displays all the servers and workstations discovered in your Active Directory environment. From here, you specify the servers (and workstations) to host an agent. For a description of the Deployment page, see the Change Auditor User Guide.

Deploy agents

Starting with Change Auditor 7.0.2, you cannot install an agent on Windows 2008 SP2 operating system. During an agent install, if this operating system is detected, the latest version of the agent that supports the operating system is installed.

For example, when you install an agent on a Windows 2012 server, the latest 7.x agent is deployed. When you deploy an agent on a Windows 2008 SP2 server, the latest 6.8 agent is installed.

The following procedures step you through the process of deploying agents. See the Change Auditor User Guide for procedures on using the advanced options and setting up auto deployment of new servers.

3
Open the client. If agents have not yet been deployed, select the Deployment tab. Otherwise, use View | Deployment.
4
From this list, select an entry and select Credentials | Set to enter the proper user credentials for installing agents on the selected domain.
On the Domain Credentials dialog, select the domain from the list and click Set. On the Logon Credentials dialog, enter the credentials of a user with administrator rights on the selected domain.
5
After entering the proper credentials, select the entry back on the Deployment page and select Credentials | Test. If you get a Valid Creds status in the Deployment Result column, you can start deploying agents to that domain.
If you get a Logon Failure status in the Deployment Result column, use the Credentials | Set command to enter the proper credentials for installing agents.
If you select the When option, enter the date and time when you want the deployment task to initiate. Click OK to initiate or schedule the deployment task.
Back on the Deployment page, the Agent Status column displays ‘Pending’ and the When column displays the date and time specified.
NOTE: To cancel a pending deployment task, select the server or workstation and then click Install or Upgrade. On the Install or Upgrade dialog, click Clear Pending.
9
As agents are successfully connected to the coordinator, the corresponding Deployment Result cell displays ‘Success’, the Agent Status cell displays ‘Active’ and a desktop notification displays in the lower right-hand corner of your screen.
NOTE: To deactivate these desktop notifications, select Action | Agent Notifications.

Upgrade Change Auditor

This section contains information about upgrading Change Auditor. Before proceeding with an upgrade, read the following information carefully and consider all steps that apply to your deployment.

You can upgrade to Change Auditor 7.1 from the following upgrade paths.

Change Auditor 6.0, 6.5, 6.6, 6.7, 6.8, 6.9, 7.0

You can upgrade directly to version 7.1.

If the upgrade cannot proceed because 5.x events are still present in the database, upgrade to 6.8 first to complete the upgrade of the 5.x events, then upgrade to 7.1. Ensure that upgrade of the 5.x events has fully completed before you upgrade.

Change Auditor 5.9 or below

You cannot upgrade directly to version 7.1. You must upgrade to 6.8 first.

Pre-upgrade considerations

Review these special considerations before running an upgrade.

Coordinator upgrades

Coordinator upgrades may take longer than expected due to additions to the Changes Auditor database schema. The duration of the upgrade is dependent on the number of events generated in the last 45 days prior to the upgrade. The estimated time is approximately 1 minute for 1 million events.

Larger, more active environments should prepare for coordinator downtime of several hours during the upgrade process. You can view the upgrade progress in the coordinator logs or by connecting the upgraded client to the coordinator.

Upgrading a coordinator that is using Azure SQL Managed Instance for the database configuration

Single User Mode is not supported during installation or upgrade when using Azure SQL Managed Instance.

Upgrading a coordinator that is using SQL AlwaysOn Availability Groups for the database configuration

When upgrading Change Auditor databases that are part of a SQL AlwaysOn Availability Group, the upgrade can be performed while connected to the availability group listener. The upgrade will take place on the primary database and SQL will replicate any changes to the other databases in the availability group. Ensure that all SQL connections to the primary database are closed before and during the upgrade.

Stop any services that use the Change Auditor SDK, such as Active Roles or GPOADmin, before starting the upgrade process.

Starting with Change Auditor 6.0, on the coordinator startup the database collation is checked against SQL server collation. If they are different, the coordinator stops and logs the “Database collation differs from server collation” warning. If it is not possible to update collation of the SQL server, use the AllowCollationSwitch registry key to allow proceeding with rebuilding Change Auditor database according to the new collation. However, using this in environment with large number of events in the database significantly increases the load on SQL server. See the Change Auditor Technical Insight Guide for more information about setting this registry key.

It is critical that Change Auditor for Exchange agent upgrades be scheduled for maintenance intervals or other periods of low user mailbox activity for any configuration of Exchange Server. Change Auditor for Exchange agent upgrades should not be attempted on an active Exchange Server cluster node in any case. Attempting to upgrade the agent on a busy Exchange Server may result in:

To eliminate the possibility of unscheduled Exchange Server downtime, perform agent upgrades to Exchange Servers during periods of low or no mailbox activity. When upgrading agents on busy Exchange Servers, it is also recommended that you manually stop the agent before upgrading to avoid a possible timeout on the stop command. Verify that the Change Auditor agent service is stopped on the Exchange Server before proceeding with the agent upgrade.

This setting is no longer available. If you want to reduce the amount of email produced from alert-enabled searches, you must set the "AlertScanPeriod" registry key setting on the coordinator computer:

HKLM\SOFTWARE\Quest\ChangeAuditor\Coordinator

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating