Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

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


View products that this article applies to.


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.

↑ Back to the top


Symptoms

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.

↑ Back to the top


Cause

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.

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

↑ Back to the top


Workarounds

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.
Server-side workaround
 

Editing DSA-signature

The server-side workaround consists of preventing system state backups of the schema partition from updating the DSA-Signature attribute. The DSA-Signature attribute contains a DRA_INHIBIT_BACKUP_AUTO_STAMP flag to determine whether a system state backup updated this attribute. However, because the DSA-Signature attribute is stored in binary large format, it cannot be changed easily by using a tool such as LDP.EXE or ADSIEDIT.MSC.

To work around this issue, run a Windows PowerShell script or an executable that prevents system state backups from updating the DSA-Signature attribute on the schema partition and, in turn, the whenChanged attribute on the schema NC head and the whenModified attribute on the CN=Aggregate objects.

See the Edit dSASignature attribute PowerShell script on the Microsoft Script Center site.

You can also compile and run the following sample code to set or clear the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in the DSA-Signature attribute on the schema NC.

Regardless of whether a PowerShell or programmatic fix is used, there is a negative side effect of enabling the DRA_INHIBIT_BACKUP_AUTO_STAMP flag. This side effect is documented in the "More Information" section.

Note This sample code must be run under a schema admin security context on a domain controller.

Making sure that definitions are up to date 

Finally, make sure that IPv4 and IPv6 subnet, site, and subnet-to-site definitions are up to date in your Active Directory forest and cover all subnets of your enterprise in all forests. Doing this makes sure that computers that are running ADSI applications that are querying and copying updated versions of the aggregate schema do this from site-optimal domain controllers. For more information about how to configure site settings, go to the following Microsoft TechNet website:  

Sample code

//+-------------------------------------------------------------------------
//
//
// File: dsasignaturemod.c
//
// This is a sample program for setting or clearing the
// DRA_INHIBIT_BACKUP_AUTO_STAMP flag in the dSASignature
// attribute on the schema NC.
//
//--------------------------------------------------------------------------
#include <windows.h>
#include <winldap.h>
#include <winber.h>
#include <strsafe.h>
#include <stdio.h>
#include <conio.h>
#define CHECKLDAP(result, op) if (result) { printf("%s failed with LDAP error=0x%x(%d)\n", op, result, result); goto Exit; }
#define CHECKLDAPLE(result, op) if (!result) { printf("%s failed with LDAP error=0x%x(%d)\n", op, LdapGetLastError(), LdapGetLastError()); goto Exit; }
//
// Type definitions for the dsaSignature attribute
//
#define DRA_INHIBIT_BACKUP_AUTO_STAMP (0x1)
typedef struct _BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1 {
DWORD dwFlags;
LONGLONG BackupErrorLatencySecs;
UUID dsaGuid;
} BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1;
typedef struct _BACKUP_NC_HEAD_DSA_SIGNATURE_STATE {
DWORD dwVersion;
DWORD cbSize;
union
{
BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1 V1;
};
} BACKUP_NC_HEAD_DSA_SIGNATURE_STATE;
// Whether we are setting or clearing the bit
BOOL gfSet = FALSE;
// Whether we are querying the bit
BOOL gfGet = FALSE;
// Whether we are automating and want to skip PromptForOK()
BOOL skipPrompt = FALSE;
// Copy of the schema NC DN
LPWSTR pszSchemaNCCopy = NULL;
BOOL PromptForOK()
{
int prompt;
BOOL ret = skipPrompt;
printf("\n");
printf("This program is about to %s the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in\n", gfSet ? "set" : "clear");
printf("the dSASignature attribute on the following directory NC:\n");
printf("\n");
printf(" %S\n", pszSchemaNCCopy);
printf("\n");
if (!skipPrompt) {
printf("Do you wish to continue? (Y\\N)");
prompt = _getch();
printf("\n");
ret = (prompt == 'Y' || prompt == 'y') ? TRUE : FALSE;
}
return ret;
}
void Usage()
{
CHAR szExeName[MAX_PATH];
ZeroMemory(szExeName, sizeof(szExeName));
GetModuleFileNameA(NULL, szExeName, ARRAYSIZE(szExeName));
printf("Usage:\n");
printf("\n");
printf("%s [/get | /set | /clear] [/auto]\n", szExeName);
printf("\n");
printf(" /get - queries current state of the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");
printf(" /set - sets the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");
printf(" /clear - clears the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");
printf(" /auto - skips the prompt for proceeding (for automation purposes)\n");
printf("\n");
}
BOOL ParseArgs(int argc, __in char ** argv)
{
BOOL ret = FALSE;
if (argc >= 2)
{
if (!_stricmp("/get", argv[1])) {
gfGet = TRUE;
ret = TRUE;
}
else if (!_stricmp("/set", argv[1])) {
gfSet = TRUE;
ret = TRUE;
}
else if (!_stricmp("/clear", argv[1])) {
gfSet = FALSE;
ret = TRUE;
}
if (argc >= 3)
{
if (!_stricmp("/auto", argv[2])) {
skipPrompt = TRUE;
}
}
}
return ret;
}
 
void __cdecl main(int argc, __in char ** argv)
{
BOOL fFoundDSASignature = FALSE;
BOOL fFlagSet = FALSE;
LDAP* ldap = NULL;
ULONG cb = 0;
ULONG cch = 0;
ULONG result = 0;
LPWSTR pszAttrs[2] = { 0 };
LPWSTR* ppszSchemaNC = NULL;
LDAPMod mod;
LDAPMod* mods[2];
LDAPMessage* pldapMsg = NULL;
LDAPMessage* pldapResults = NULL;
struct berval valMod;
struct berval* vals[2];
struct berval** val = NULL;
BACKUP_NC_HEAD_DSA_SIGNATURE_STATE dsaSignature;
ZeroMemory(&dsaSignature, sizeof(dsaSignature));
if (!ParseArgs(argc, argv)) {
Usage();
return;
}
printf("\n");
//
// Init connection handle
//
ldap = ldap_init(NULL, LDAP_PORT);
CHECKLDAPLE(ldap, "ldap_init");
//
// Connect to DC
//
result = ldap_connect(ldap, NULL);
CHECKLDAP(result, "ldap_connect");
//
// Retrieve schema NC name
//
pszAttrs[0] = L"schemaNamingContext";
pszAttrs[1] = NULL;
result = ldap_search_sW(ldap,
NULL,
LDAP_SCOPE_BASE,
L"(objectclass=*)",
pszAttrs,
0,
&pldapResults);
CHECKLDAP(result, "ldap_search_s for schemaNamingContext");
pldapMsg = ldap_first_entry(ldap, pldapResults);
CHECKLDAPLE(pldapMsg, "ldap_first_entry");
//
// Make a copy of the schema NC name
//
ppszSchemaNC = (LPWSTR*)ldap_get_valuesW(ldap, pldapMsg, L"schemaNamingContext");
cch = wcslen(ppszSchemaNC[0]) + 1;
pszSchemaNCCopy = (LPWSTR)malloc(cch * sizeof(WCHAR));
StringCchCopy(pszSchemaNCCopy, cch, ppszSchemaNC[0]);
ldap_value_free(ppszSchemaNC);
ppszSchemaNC = NULL;
ldap_msgfree(pldapResults);
pldapResults = NULL;
//
// Bind to the DC
//
result = ldap_bind_s(ldap, pszSchemaNCCopy, NULL, LDAP_AUTH_NEGOTIATE);
CHECKLDAP(result, "ldap_bind_s");
//
// Retrieve current value of the dSASignature attribute
//
pszAttrs[0] = L"dSASignature";
pszAttrs[1] = NULL;
result = ldap_search_sW(ldap,
pszSchemaNCCopy,
LDAP_SCOPE_BASE,
L"(objectclass=*)",
pszAttrs,
0,
&pldapResults);
CHECKLDAP(result, "ldap_search_s for dSASignature");
pldapMsg = ldap_first_entry(ldap, pldapResults);
CHECKLDAPLE(pldapMsg, "ldap_first_entry");
//
// Make a copy of the dSASignature attribute.
//
val = (struct berval**)ldap_get_values_len(ldap, pldapMsg, L"dSASignature");
// Make sure that the value was there and seems to be the correct size.
if (val && val[0]) {
if (val[0]->bv_len == sizeof(BACKUP_NC_HEAD_DSA_SIGNATURE_STATE)) {
memcpy(&dsaSignature, val[0]->bv_val, val[0]->bv_len);
fFoundDSASignature = TRUE;
}
}
ldap_value_free_len(val);
val = NULL;
ldap_msgfree(pldapResults);
pldapResults = NULL;
//
// Sanity check
//
if (!fFoundDSASignature ||
dsaSignature.dwVersion != 1) {
printf("The dSASignature attribute was either not\n");
printf("found or was in an unexpected format.\n");
goto Exit;
}
//
// Cache whether the flag is set already or not
//
fFlagSet = (DRA_INHIBIT_BACKUP_AUTO_STAMP & dsaSignature.V1.dwFlags) ? TRUE : FALSE;
//
// If query-only mode, display current setting and leave
//
if (gfGet) {
printf("The target directory %s have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.\n",
fFlagSet ? "DOES" : "DOES NOT");
goto Exit;
}
//
// If doing a modification, see whether there is anything to do.
//
if (gfSet && fFlagSet) {
printf("The /set operation was specified but the target directory already\n");
printf(" has the flag set. Exiting with no changes.\n");
goto Exit;
}
else if (!gfSet && !fFlagSet) {
printf("The /clear operation was specified but the target directory already\n");
printf(" has the flag cleared. Exiting with no changes.\n");
goto Exit;
}
//
// Yes there is work to do; prompt the admin
// for approval before you continue.
//
if (!PromptForOK()) {
goto Exit;
}
//
// Set or clear the bit in our local copy
//
if (gfSet) {
dsaSignature.V1.dwFlags |= DRA_INHIBIT_BACKUP_AUTO_STAMP;
}
else {
dsaSignature.V1.dwFlags &= (~DRA_INHIBIT_BACKUP_AUTO_STAMP);
}
//
// Prepare for the modify
//
ZeroMemory(&valMod, sizeof(valMod));
valMod.bv_len = sizeof(dsaSignature);
valMod.bv_val = (PCHAR)&dsaSignature;
vals[0] = &valMod;
vals[1] = NULL;
ZeroMemory(&mod, sizeof(mod));
mod.mod_op = LDAP_MOD_REPLACE | LDAP_MOD_BVALUES;
mod.mod_type = L"dSASignature";
mod.mod_vals.modv_bvals = vals;
mods[0] = &mod;
mods[1] = NULL;
//
// And do it:
//
result = ldap_modify_s(ldap,
pszSchemaNCCopy,
mods);
CHECKLDAP(result, "ldap_modify_s for dSASignature");
printf("\n");
printf("Modification succeeded!\n");
Exit:
if (pszSchemaNCCopy) {
free(pszSchemaNCCopy);
}
if (ldap) {
ldap_unbind(ldap);
}
printf("\n");
return;
}

Sample program output

The following are the sample program outputs:
C:\>dsasignaturemod.exe /get

The target directory DOES NOT have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.
C:\>dsasignaturemod.exe /set


This program is about to set the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in
the dSASignature attribute on the following directory NC:

CN=Schema,CN=Configuration,DC=rootdomain,DC=com

Do you wish to continue? (Y\N)

Modification succeeded!
C:\>dsasignaturemod.exe /set /auto


This program is about to set the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in
the dSASignature attribute on the following directory NC:

CN=Schema,CN=Configuration,DC=rootdomain,DC=com


Modification succeeded!
C:\>dsasignaturemod.exe /get

The target directory DOES have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.
C:\>dsasignaturemod.exe /clear


This program is about to clear the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in
the dSASignature attribute on the following directory NC:

CN=Schema,CN=Configuration,DC=rootdomain,DC=com

Do you wish to continue? (Y\N)

Modification succeeded!
C:\>dsasignaturemod.exe /clear /auto


This program is about to clear the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in
the dSASignature attribute on the following directory NC:

CN=Schema,CN=Configuration,DC=rootdomain,DC=com


Modification succeeded!

Client-side workaround

Optimizing domain controller selection

Some applications explicitly connect to a specific domain controller and then download the updated schema cache from this domain controller. However, applications usually leave it to Domain Controller Locator to find the best domain controller for a certain LDAP naming context. Clients may experience a noticeable delay in updating the schema cache because they target domain controllers over a slow network connection. This is likely to occur across forest boundaries. Your goal should always be to download the schema cache from the closest domain controller in terms of the network.

Workaround

The client-side workaround consists of configuring computers that are running Windows Vista, Windows Server 2008, or later versions to use a per-machine-based store for the aggregate schema.

On Windows XP-based computers, the aggregate schema cache used a per-machine store. This means that the download of the aggregate schema was shared among all users who were logging on to the local computer, as long as either the users have administrative rights granted or the local stores in the file system and the registry have write permissions granted to authenticated users. Otherwise, the schema cache had to be downloaded into the RAM during each ADSI session and was discarded after the ADSI session ended.

On Windows Vista and later versions, the ADSI schema cache is implemented in a per-user store. Although security is improved with the per-user cache, each unique user who is logging on to a Remote Desktop Protocol (RDP) or Terminal Server AQ, kiosk, or other multiuser system may cause the same computer to download the ADSI schema cache.

You can force a fallback to the per-machine store configuration on computers that are running Windows Vista and later versions by setting the REG-DWORD PerMachine in the HKLM\SYSTEM\CurrentControlSet\Services\ADSI\Cache registry path to a value of 1. Additionally, you must grant write access on %systemroot%\SchCache and HKLM\Software\Microsoft\ADs\Providers\LDAP to authenticated users. For more information, see ADSI and User Account Control.

Note Using the "per machine" store is especially helpful in scenarios in which a user's roaming profile is deleted when the user logs off. Such users have to build a new roaming profile and may have to download the aggregate schema. Specific scenarios that cause the deletion of a roaming profile include the following:
  • Users who are configured to log on by using mandatory user profiles.
  • Users who are subject to the "delete user profiles older than a specified number of days on system startup" policy.
  • Users who are subject to the "delete cached copies of roaming profiles" policy.
  • A user whose cached profile was deleted by a script or tool such as DELPROF.EXE or an equivalent.

↑ Back to the top


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
Attributes that are used to detect changes to the aggregate schema
The following table provides an overview of the attributes that are used to detect aggregate schema changes for each version of Windows:

ADSI client operating system versionCondition for ADSI schema cache download
Windows XP
Windows Server 2003
Windows Server 2003 R2
Windows Vista / Windows Server 2008
Windows 7 / Windows Server 2008 R2
Update of modifyTimeStamp attribute on aggregate schema object
Windows 8 / Windows Server 2012
Windows 8.1 / Windows Server 2012 R2
Update of whenChanged schema attribute
If a change is detected on one of these proxy attributes, the ADSI client downloads a new copy of aggregate schema.

Computers that are running operating systems earlier than Windows 8 or Windows Server 2012 query the modifyTimeStamp attribute on the aggregate schema. The modifyTimeStamp was updated by restarts of the Active Directory service so that restarting a domain controller or restarting the Active Directory service caused some ADSI clients to download the aggregate schema cache from a domain controller when no legitimate schema change had occurred. This was less of an issue early on, because Active Directory became a restartable service in Windows Server 2008.

Computers that are running Windows 8, Windows Server 2012, or a later version query the whenChanged attribute on the schema NC head. The whenChanged attribute has the side effect of being updated when a system state backup updates the DSA-Signature attribute on the schema naming context. This in turn updates the time stamp on the whenChanged attribute of the schema NC head.

Detecting aggregate schema cache updates by ADSI clients
To detect high CPU and network usage, use the Network Monitor 3.4 tool to capture network usage, and then follow these steps to analyze the results:
  1. Use one of the following display filters in the tool, depending on your Windows operating system.

    Note In these filters, please replace the string "CN=Schema,CN=Configuration,DC=Contoso,DC=com" with the distinguished name (DN) path of the Active Directory schema naming context in question.
    Windows 7 and earlier clients
    Use the following display filter to query the modifyTimeStamp attribute value on the aggregate schema object in the captured network traffic:
    (LDAPMessage.SearchRequest.BaseObject.OctetStream == "CN=Aggregate,CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchRequest.Attributes.Attribute.OctetStream == "modifyTimeStamp") OR
    (LDAPMessage.SearchResultEntry.ObjectName.OctetStream == "CN=Aggregate,CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchResultEntry.Attributes.PartialAttribute.Type.OctetStream == "modifyTimeStamp")
    Windows 8 and later clients

    Use the following display filter to query the whenChanged attribute value on the schema NC head in the captured network traffic:

    (LDAPMessage.SearchRequest.BaseObject.OctetStream == "CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchRequest.Attributes.Attribute.OctetStream == "whenChanged") OR 
    (LDAPMessage.SearchResultEntry.ObjectName.OctetStream == "CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchResultEntry.Attributes.PartialAttribute.Type.OctetStream == "whenChanged")

    By default, this value is compared with the Time value in the registry of the client in the following key:

    HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=<root domain>,DC=com
    The client downloads an updated schema cache if the time in the modifyTimeStamp or whenChanged attribute is later than the value that is stored in the registry. (This attribute depends on the client operating system.)

    The following is a sample screen shot of the tool:

    This screenshot is an example that if the time in the modifyTimeStamp or whenChanged attribute is later than the value that is stored in the registry

    From the screen shot, you can see the following:
    • The ADSI client binds to the domain controller in Frame Name 8.
    • The LDAP search for the schema changed proxy attribute is stored in one of the early LDAPSASLBuffer frames that follow the bind.
    • The LDAP traffic is encrypted in several LDAPSASLBuffer frames (target port on DC = TCP 389).
    • The domain controller continues to send additional encrypted data over many TCP frames that have a TCP payload length of 1460.
  2. After you have identify the correct conversation in the network trace that is exhibiting this behavior, you can filter on the TCP port that the client is using. In the example, the conversation is initiated from the client over TCP port 65237. A Network Monitor filter such as "tcp.port == 65237" could be used to isolate related frames.
  3. If you copy all frames in this conversation and paste into Microsoft Excel, you see that the default aggregate schema copy has a TCP payload size of 2 megabytes (MB) of data on the wire. The file size of the default aggregate schema is around 4 MB after encoding.

Correlating network traffic to client-side process
You can use System Monitor (Sysmon) to determine the process on the client that initiated this conversation. Event ID 3 is logged in the Microsoft-Windows-Sysmon Operation event log when Sysmon is installed and configured to log LDAP connections. This lets you relate the network traffic to a client-side process because it logs source IP and port together with the ProcessID and Image name.

Process Monitor logging on the client
Process Monitor logging on the client provides rich contextual information. Filter the Process Monitor log on the Process ID that is logged in the event logged by Sysmon.

The screenshot filters the Process Monitor log on the Process ID logged in the event logged by Sysmon

You will find the following operations of interest.
OperationPath
RegOpenKeyHKLM\SYSTEM\CurrentControlSet\Services\ADSI\Cache
RegQueryValueHKCU\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=child domain,DC=root domain,DC=com\Time
TCP Receive<HOSTNAME>:Port -> <DCName>:LDAP
RegCreateKeyHKCU\SOFTWARE\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=child domain,DC=root domain,DC=com
WriteFileC:\Users\<username>\AppData\Local\Microsoft\Windows\SchCache\child domain.root domain.com.sch
Note One way to check whether Windows-based computers are updating the local copy of the aggregate schema cache is to watch for changes in the date stamp of the *.sch file in the local file system of the ADSI client.

You can use the data in the following table to refine your filter for very large Process Monitor logs.

Additional optional filters:
ColumnRelationValue
PathContainsSchCache
OperationIsWriteFile
The screenshot is Process Monitor Filter

Configuring Sysmon to log LDAP connections
  1. Download Sysmon on the client.
  2. Create a new text file for the Sysmon configuration, save the file as Sysmonconfig.xml, and add the following contents:

    <Sysmon schemaversion="2.0">
    <!-- Capture all hashes -->
    <HashAlgorithms>*</HashAlgorithms>
    <EventFiltering>
    <!-- Log all drivers except if the signature -->
    <!-- contains Microsoft or Windows -->
    <DriverLoad onmatch="exclude">

    <Signature condition="contains">microsoft</Signature>
    <Signature condition="contains">windows</Signature>
    </DriverLoad>
    <!-- Do not log process termination -->
    <ProcessTerminate onmatch="include" />
    <!-- Log network connection if the destination port equal 443 -->
    <NetworkConnect onmatch="include">
    <DestinationPort>389</DestinationPort>
    <DestinationPort>636</DestinationPort>
    <DestinationPort>3268</DestinationPort>
    <DestinationPort>3269</DestinationPort>
    </NetworkConnect>
    </EventFiltering></Sysmon>
  3. Run the following command to install Sysmon:
    Sysmon -i sysmonconfig.xml

Side effect of enabling the DRA_INHIBIT_BACKUP_AUTO_STAMP flag
One side effect of enabling the DRA_INHIBIT_BACKUP_AUTO_STAMP flag is that event ID 2089 will incorrectly indicate that the schema partition is not being captured in forests that are creating system state backups.

A sample event ID 2089 that resembles the following is logged in the Application log: Note Event ID 2089 is not logged for other key partitions such as CN=Configuration or the domain directory partition because there is no method to perform partition-specific backups. For more information, see the following Microsoft Knowledge Base article:
914034 NTDS Replication Event 2089 is logged if Windows Server 2003 SP1 and later domain controllers are not backed up in a given time period

↑ Back to the top


Keywords: kb, kbexpertiseadvanced, kbsurveynew, kbbug, kbprb, kbtshoot

↑ Back to the top

Article Info
Article ID : 2789917
Revision : 1
Created on : 1/7/2017
Published on : 7/28/2015
Exists online : False
Views : 974