Heavy WAN and domain controller CPU usage when you perform system state backups

Applies to: Windows Server 2012 R2 DatacenterWindows Server 2012 R2 StandardWindows Server 2012 R2 Essentials

This article describes how system state backups by Active Directory domain controllers transitively update reference attributes that cause Active Directory Service Interfaces (ADSI) clients to download the aggregate schema. This download process potentially increases load on domain controller role computers and the underlying network.


The following issues may occur when you perform system state backup of the schema partition on any domain controller in an Active Directory forest:

  • Increased CPU usage on domain controller role computers when Windows-based computers query reference Active Directory attributes that are used for the following purposes:
    • To detect updates to the aggregate schema
    • To copy the aggregate schema from domain controllers if a change is detected
  • Increased Lightweight Directory Access Protocol (LDAP) traffic on the network when ADSI clients copy the contents of the aggregate schema from domain controllers.


This issue occurs because the DSA-Signature attribute is updated on the schema naming context (schema NC) when you perform a system state backup of a domain controller that is running Windows Server 2003 Service Pack 1 (SP1) or a later version.

When the DSA-Signature attribute is updated by a system state backup, date stamps are updated on two reference attributes. One of these attributes is located on the schema NC head, and the other is located on the CN=Aggregate,CN=Schema object.

Windows clients that run ADSI applications and scripts query these reference attributes to detect updates to the aggregate schema. When they detect such updates, ADSI clients download an updated copy of the aggregate schema from a domain controller through an LDAP read.

For more information about detecting the aggregate schema that is related to LDAP queries and network I/O, see the "More Information" section.


A server-side workaround and a client-side workaround provide partial relief by reducing but not eliminating the number of times that ADSI clients download the aggregate schema. The client-side and server-side workarounds may be implemented independently of one another. This means that you can implement the client-side workaround only, the server-side change, or both workarounds at the same time.

More Information

Information about ADSI

An ADSI client is a programmatic implementation that accesses Active Directory in order to conform to the Component Object Model (COM).

Windows-based computers that are running ADSI applications and scripts maintain a local copy of the aggregate Active Directory schema. At the beginning of every ADSI client session, the reference schema attribute is checked for changes. Because no explicit attribute in Active Directory uniquely identifies all possible changes to the Active Directory schema, proxy attributes are used to determine when Windows-based computers should copy an updated copy of the aggregate schema over the network from a domain controller in the client's respective domain. Examples of ADSI applications include the following:
  • Active Directory Administrative Center Microsoft Management Console (MMC) snap-in
  • Active Directory Domains and Trusts MMC snap-in
  • Active Directory Sites and Services MMC snap-in
  • Active Directory Users and Computers MMC snap-in
  • ADSI Edit MMC snap-in
  • DHCP MMC snap-in
  • DNS Manager MMC snap-in
  • Exchange Management Console
  • Group Policy Management MMC snap-in
  • Squery.exe