Tell us about your PDF experience.

Windows Server troubleshooting

This library provides solutions enabling IT Pros to troubleshoot and support Windows
Server operating systems. To bring you the most accurate content, this library is
managed by a team that works directly with the Windows product group and support
professionals.

Identity and Access

ｃ HOW-TO GUIDE

Active Directory

Group Policy

UserProfiles and Logon

Networking

ｃ HOW-TO GUIDE

Networking

Software Defined Networking

Storage and High Availability

ｃ HOW-TO GUIDE

Backup and Storage

High Availability

Virtualization

Containers

User Experience

ｃ HOW-TO GUIDE
Application Management

Printing

Remote Desktop Services

System Management Components

Windows Performance

ｃ HOW-TO GUIDE

Performance

Shell Experience

Windows Security

ｃ HOW-TO GUIDE

Windows Security

Security and Malware

Management

ｃ HOW-TO GUIDE

Admin Development

Virtual Support Agent

ｃ HOW-TO GUIDE

Introducing Virtual Support Agent for Windows Commercial

Active Directory documentation
Article • 03/18/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Active Directory-related issues. The topics are divided into
subcategories. Browse the content or use the search feature to find relevant content.

Active Directory sub categories

Active Directory backup, restore, or disaster recovery
Active Directory Certificate Services
Active Directory database issues and domain controller boot failures
Active Directory domain or forest functional level updates
Active Directory Federation Services (AD FS)
Active Directory FSMO
Active Directory Lightweight Directory Services (AD LDS) and Active Directory
Application Mode (ADAM)
Active Directory Migration Tool (ADMT)
Active Directory replication
Active Directory Rights Management Services
Active Directory topology (sites, subnets, and connection objects)
DCPromo and the installation of domain controllers
Domain controller scalability or performance (including LDAP)
Domain join issues
LDAP configuration and interoperability
Schema update - known issues, best practices, workflow review
Schema update failure or conflict
Transport Layer Security (TLS)
User, computer, group, and object management
Virtualized domain controller (errors and questions)
Windows Time Service

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain controller does not start,
c00002e2 error occurs, or "Choose an
option" is displayed
Article • 02/19/2024

This article helps to fix the error c00002e2 or "Choose an option" when Domain
controller does not start.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2737463

Symptoms
A domain controller does not start or does not display the logon screen. After you
restart the domain controller and watch the start process, you notice the following
symptoms, according to your operating system.

Windows Server 2008 R2 or Windows Server 2008

1. At startup, the server experiences a Stop error and briefly displays the following
error message:

STOP: c00002e2 Directory Services could not start because of the following
error:
The specified procedure could not be found
Error status: 0xc000007a.

2. The server then switches to the startup menu for recovery or for a regular startup.

Windows Server 2012 and later versions

At startup, the server switches to the Choose an option menu that offers to continue or
troubleshoot.

Cause
This issue happens because the Active Directory Domain Services role was removed
from a domain controller without first demoting it. Using Dism.exe, Pkgmgr.exe, or
Ocsetup.exe to remove the DirectoryServices-DomainController role will succeed, but
these servicing tools do not validate whether the computer is a domain controller.

Resolution

７ Note

These steps assume that you have other working domain controllers, and you only
want to remove Active Directory Domain Services from this server. If you do not
have other working domain controllers, and this is the only domain controller in the
domain, you must restore an earlier system state backup.

Windows Server 2008 R2 or Windows Server 2008

1. Restart the server while you hold Shift+F8.

2. Select Directory Services Repair Mode (DSRM), and then log on by using the
DSRM account.

3. Validate that the role was removed. For example, to do it on Windows Server 2008
R2, use the following command:

Console

dism.exe /online /get-features

4. Add the DirectoryServices-DomainController role back to the server. For example,

to do it on Windows Server 2008 R2, use the following command:

Console

dism.exe /online /enable-feature /featurename:DirectoryServices-

DomainController

5. Restart and select Directory Services Restore Mode again.

6. Apply a /forceremoval parameter to remove Active Directory Domain Services from

the domain controller. To do it, run the following command:

Console

dcpromo.exe /forceremoval
 7. To remove the domain controller metadata, use the ntdsutil.exe or dsa.msc tool.

Windows Server 2012 and later versions

1. From the Choose an option menu, select Troubleshoot, click Startup Settings, and
then click Restart.

2. Select Directory Services Repair Mode (DSRM), and then log on by using the
DSRM password.

3. Validate that the role was removed. To do it, use the following command:

Console

dism.exe /online /get-features

4. Add the DirectoryServices-DomainController role back to the server. To do it, use

the following command:

Console

dism.exe /online /enable-feature /featurename:DirectoryServices-

DomainController

5. Restart, select Directory Services Restore Mode again, and log on by using the
DSRM account.

6. Use Server Manager or Windows PowerShell, and apply a -ForceRemoval

parameter to remove Active Directory Domain Services from the domain controller.
To do it, run the following command:

PowerShell

Uninstall-AddsDomaincontroller -ForceRemoval

7. To remove the domain controller metadata, use the ntdsutil.exe or dsa.msc tool.

More information
Always use Server Manager or the ServerManager Windows PowerShell module to
remove the Active Directory Domain Services role binaries. These tools validate whether
a server is an active domain controller and do not let you remove critical files.
For more information about how to remove domain controller metadata, go to the
following Microsoft TechNet website:
Clean Up Server Metadata
If it is the only server domain in the domain, do not remove the Active Directory Domain
Services from the server. Instead, restore its system state from the most recent backup.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A Windows Server domain controller
logs Directory Services event 2095 when
it encounters a USN rollback
Article • 02/19/2024

This article describes how to detect and recover if a Windows Server domain controller
is incorrectly rolled back by using an image-based installation of the operating system.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 875495

７ Note

This article is intended for only technical support agents and IT professionals. If
you're looking for help with a problem, please ask the Microsoft Community .

Summary
This article describes a silent Active Directory replication failure that is caused by an
update sequence number (USN) rollback. A USN rollback occurs when an older version
of an Active Directory database is incorrectly restored or pasted into place.

When a USN rollback occurs, modifications to objects and attributes that occur on one
domain controller do not replicate to other domain controllers in the forest. Because
replication partners believe that they have an up-to-date copy of the Active Directory
database, monitoring and troubleshooting tools such as Repadmin.exe don't report any
replication errors.

Domain Controllers log Directory Services Event 2095 in the Directory Services event log
when they detect a USN rollback. The text of the event message directs administrators
to this article to learn about recovery options.

Example of Event 2095 log entry

Output

Log Name: <Service name> Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
 Event ID: 2095
Task Category: Replication
Level: Error
Keywords: Classic
User: <USER NAME>
Computer: SERVER.contoso.com
Description:

During an Active Directory Domain Services replication request, the local

domain controller (DC) identified a remote DC which has received replication
data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory

Domain Services database than the local DC, the remote DC will not apply
future changes to its copy of the Active Directory Domain Services database
or replicate them to its direct and transitive replication partners that
originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in

the Active Directory Domain Services databases of this source DC and one or
more direct and transitive replication partners. Specifically the
consistency of users, computers and trust relationships, their passwords,
security groups, security group memberships and other Active Directory
Domain Services configuration data may vary, affecting the ability to log
on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using

http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active
Directory Domain Services on the local domain controller.

User Actions:

If this situation occurred because of an improper or unintended restore,

forcibly demote the DC.

The following topics discuss how to detect and recover from a USN rollback in a
Windows Server-based domain controller.

Supported methods to back up Active

Directory on domain controllers that are
running Windows Server 2012 and later
versions
Windows Server 2012 adds support for Hyper-Visor Generation ID (GenID). This allows
the virtual guest to detect the disk volumes that have a new ID, and respond to the new
GenID. In Active Directory, Directory Services reacts as if the domain controller was
restored from a backup. It then generates a new Invocation ID. By using the new
Invocation ID, the database instance can safely re-enter replication in the forest.

This is one of the scenarios that is covered in Virtualized Domain Controller Deployment
and Configuration.

Supported methods to back up Active

Directory on domain controllers that are
running Windows Server 2003 or later versions
of Windows Server
Over a domain controller's life cycle, you may have to restore, or "roll back," the
contents of the Active Directory database to a known good point in time. Or, you may
have to roll back elements of a domain controller's host operating system, including
Active Directory, to a known good point.

The following are supported methods that you can use to roll back the contents of
Active Directory:

Use an Active Directory-aware backup and restoration utility that uses Microsoft-
provided and Microsoft-tested APIs. These APIs non-authoritatively or
authoritatively restore a system state backup. The backup that is restored should
originate from the same operating system installation and from the same physical
or virtual computer that is being restored.

Use an Active Directory-aware backup and restoration utility that uses Microsoft
Volume Shadow Copy Service APIs. These APIs back up and restore the domain
controller system state. The Volume Shadow Copy Service supports creating single
point-in-time shadow copies of single or multiple volumes on computers that are
running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.
Single point-in-time shadow copies are also known as snapshots. For more
information, search "Volume Shadow Copy Service" in Microsoft Support .

Restore the system state. Evaluate whether valid system state backups exist for this
domain controller. If a valid system state backup was made before the rolled-back
domain controller was incorrectly restored, and if the backup contains recent
changes that were made on the domain controller, restore the system state from
the most recent backup.
Typical behavior that occurs when you restore
an Active Directory-aware system state backup
Windows Server domain controllers use USNs together with the invocation IDs to track
updates that must be replicated between replication partners in an Active Directory
forest.

Source domain controllers use USNs to determine what changes have already been
received by the destination domain controller that is requesting changes. Destination
domain controllers use USNs to determine what changes should be requested from
source domain controllers.

The invocation ID identifies the version or the instantiation of the Active Directory
database that is running on a given domain controller.

When Active Directory is restored on a domain controller by using the APIs and
methods that Microsoft has designed and tested, the invocation ID is correctly reset on
the restored domain controller. domain controllers in the forest receive notification of
the invocation reset. Therefore, they adjust their high watermark values accordingly.

Software and methodologies that cause USN

rollbacks
When the following environments, programs, or subsystems are used, administrators
can bypass the checks and validations that Microsoft has designed to occur when the
domain controller system state is restored:

Starting an Active Directory domain controller whose Active Directory database file
was restored (copied) into place by using an imaging program such as Norton
Ghost.

Starting a previously saved virtual hard disk image of a domain controller. The
following scenario can cause a USN rollback:

1. Promote a domain controller in a virtual hosting environment.

2. Create a snapshot or alternative version of the virtual hosting environment.
3. Let the domain controller continue to inbound replicate and to outbound
replicate.
4. Start the domain controller image file that you created in step 2.

Examples of virtualized hosting environments that cause this scenario include

Microsoft Virtual PC 2004, Microsoft Virtual Server 2005, and EMC VMWARE. Other
 virtualized hosting environments can also cause this scenario.

For more information about the support conditions for domain controllers in
virtual hosting environments, see Things to consider when you host Active
Directory domain controllers in virtual hosting environments.

Starting an Active Directory domain controller that is located on a volume where

the disk subsystem loads by using previously saved images of the operating
system without requiring a system state restoration of Active Directory.

Scenario A: Starting multiple copies of Active Directory that are located on a

disk subsystem that stores multiple versions of a volume

1. Promote a domain controller. Locate the Ntds.dit file on a disk subsystem

that can store multiple versions of the volume that hosts the Ntds.dit file.
2. Use the disk subsystem to create a snapshot of the volume that hosts the
Ntds.dit file for the domain controller.
3. Continue to let the domain controller load Active Directory from the
volume that you created in step 1.
4. Start the domain controller that the Active Directory database saved in
step 2.

Scenario B: Starting Active Directory from other drives in a broken mirror

1. Promote a domain controller. Locate the Ntds.dit file on a mirrored drive.

2. Break the mirror.
3. Continue to inbound replicate and outbound replicate by using the
Ntds.dit file on the first drive in the mirror.
4. Start the domain controller by using the Ntds.dit file on the second drive
in the mirror.

Even if not intended, each of these scenarios can cause domain controllers to roll back
to an older version of the Active Directory database by unsupported methods. The only
supported way to roll back the contents of Active Directory or the local state of an
Active Directory domain controller is to use an Active Directory-aware backup and
restoration utility to restore a system state backup that originated from the same
operating system installation and the same physical or virtual computer that is being
restored.

Microsoft does not support any other process that takes a snapshot of the elements of
an Active Directory domain controller's system state and copies elements of that system
state to an operating system image. Unless an administrator intervenes, such processes
cause a USN rollback. This USN rollback causes the direct and transitive replication
partners of an incorrectly restored domain controller to have inconsistent objects in
their Active Directory databases.

The effects of a USN rollback

When USN rollbacks occur, modifications to objects and attributes aren't inbound
replicated by destination domain controllers that have previously seen the USN.

Because these destination domain controllers believe they're up to date, no replication

errors are reported in Directory Service event logs or by monitoring and diagnostic
tools.

USN rollback may affect the replication of any object or attribute in any partition. The
most frequently observed side effect is that user accounts and computer accounts that
are created on the rollback domain controller do not exist on one or more replication
partners. Or, the password updates that originated on the rollback domain controller
don't exist on replication partners.

The following steps show the sequence of events that may cause a USN rollback. A USN
rollback occurs when the domain controller system state is rolled back in time using an
unsupported system state restoration.

1. An administrator promotes three domain controllers in a domain. (In this example,

the domain controllers are DC1, DC2, and DC2, and the domain is Contoso.com.)
DC1 and DC2 are direct replication partners. DC2 and DC3 are also direct
replication partners. DC1 and DC3 aren't direct replication partners but receive
originating updates transitively through DC2.

2. An administrator creates 10 user accounts that correspond to USNs 1 through 10

on DC1. All these accounts replicate to DC2 and DC3.

3. A disk image of an operating system is captured on DC1. This image has a record
of objects that correspond to local USNs 1 through 10 on DC1.

4. The following changes are made in Active Directory:

The passwords for all 10 user accounts that were created in step 2 are reset
on DC1. These passwords correspond to USNs 11 through 20. All 10 updated
passwords replicate to DC2 and DC3.
10 new user accounts that correspond to USNs 21 through 30 are created on
DC1. These 10 user accounts replicate to DC2 and DC3.
10 new computer accounts that correspond to USNs 31 through 40 are
created on DC1. These 10 computer accounts replicate to DC2 and DC3.
 10 new security groups that correspond to USNs 41 through 50 are created
on DC1. These 10 security groups replicate to DC2 and DC3.

5. DC1 experiences a hardware failure or a software failure. The administrator uses a

disk imaging utility to copy the operating system image that was created in step 3
into place. DC1 now starts with an Active Directory database that has knowledge of
USNs 1 through 10.

Because the operating system image was copied into place, and a supported
method of restoring the system state wasn't used, DC1 continues to use the same
invocation ID that created the initial copy of the database and all changes up to
USN 50. DC2 and DC3 also maintain the same invocation ID for DC1 well as an up-
to-date vector of USN 50 for DC1. (An up-to-date vector is the current status of the
latest originating updates to occur on all domain controllers for a given directory
partition.)

Unless an administrator intervenes, DC2 and DC3 don't inbound replicate the
changes that correspond to local USN 11 through 50 that originate from DC1. Also,
according to the invocation ID that DC2 uses, DC1 already has knowledge of the
changes that correspond to USN 11 to 50. Therefore, DC2 doesn't send those
changes. Because the changes in step 4 do not exist on DC1, logon requests fail
with an "access denied" error. This error occurs either because passwords do not
match or because the account does not exist when the newer accounts randomly
authenticate with DC1.

6. Administrators who monitor replication health in the forest note the following
situations:

The Repadmin /showreps command-line tool reports that two-way Active

Directory replication between DC1 and DC2 and between DC2 and DC3 is
occurring without error. This situation makes any replication inconsistency
difficult to detect.

Replication events in the directory service event logs of domain controllers

that are running Windows Server do not indicate any replication failures in
the directory service event logs. This situation makes any replication
inconsistency difficult to detect.

Active Directory Users and Computers or the Active Directory Administration

Tool (Ldp.exe) show a different count of objects and different object
metadata when the domain directory partitions on DC2 and DC3 are
compared to the partition on DC1. The difference is the set of changes that
map to USN changes 11 through 50 in step 4.
 ７ Note

In this example, the different object count applies to user accounts,

computer accounts, and security groups. The different object metadata
represents the different user account passwords.

User authentication requests for the 10 user accounts that were created in
step 2 occasionally generate an "access denied" or "incorrect password" error.
This error may occur because a password mismatch exists between these user
accounts on DC1 and the accounts on DC2 and DC3. The user accounts that
experience this problem correspond to the user accounts that were created in
step 4. The user accounts and password resets in step 4 didn't replicate to
other domain controllers in the domain.

7. DC2 and DC3 start to inbound-replicate originating updates that correspond to

USN numbers that are greater than 50 from DC1. This replication proceeds
normally without administrative intervention because the previously recorded up-
to-dateness vector threshold, USN 50, has been exceeded. (USN 50 was the up-to-
dateness vector USN recorded for DC1 on DC2 and DC3 before DC1 was taken
offline and restored.) However, the new changes that corresponded to USNs 11
through 50 on the originating DC1 after the unsupported restore will never
replicate to DC2, DC3, or their transitive replication partners.

Although the symptoms that are mentioned in step 6 represent some of the effect that a
USN rollback can have on user and computer accounts, a USN rollback can prevent any
object type in any Active Directory partition from replicating. These object types include
the following:

The Active Directory replication topology and schedule

The existence of domain controllers in the forest and the roles that these domain
controllers hold

７ Note

These roles include the global catalog, relative identifier (RID) allocations, and
operations master roles. (Operations master roles are also known as flexible
single master operations or FSMO.)

The existence of domain and application partitions in the forest

The existence of security groups and their current group memberships

 DNS record registration in Active Directory-integrated DNS zones

The size of the USN hole may represent hundreds, thousands, or even tens of thousands
of changes to users, computers, trusts, passwords, and security groups. (The USN hole is
defined by the difference between the highest USN number that existed when the
restored system state backup was made and the number of originating changes that
were created on the rolled-back domain controller before it was taken offline.)

Detect a USN rollback on a Windows Server

domain controller
Because a USN rollback is difficult to detect, a Windows Server 2003 SP1 or later version
domain controller logs event 2095 when a source domain controller sends a previously
acknowledged USN number to a destination domain controller without a corresponding
change in the invocation ID.

To prevent unique originating updates to Active Directory from being created on the
incorrectly restored domain controller, the Net Logon service is paused. When the Net
Logon service is paused, user and computer accounts can't change the password on a
domain controller that will not outbound-replicate such changes. Similarly, Active
Directory administration tools will favor a healthy domain controller when they make
updates to objects in Active Directory.

On a domain controller, event messages that resemble the following are recorded if the
following conditions are true:

A source domain controller sends a previously acknowledged USN number to a

destination domain controller.
There is no corresponding change in the invocation ID.

These events may be captured in the Directory Service event log. However, they may be
overwritten before they're observed by an administrator.

You may suspect that a USN rollback has occurred. However, you don't see the
correlating events in the Directory Service event log. In this scenario, check for the Dsa
Not Writable registry entry. This entry provides forensic evidence that a USN rollback
has occurred.

Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Registry entry: Dsa Not Writable

Value: 0x4
Deleting or manually changing the Dsa Not Writable registry entry value puts the
rollback domain controller in a permanently unsupported state. Therefore, such changes
are not supported. Specifically, modifying the value removes the quarantine behavior
added by the USN rollback detection code. The Active Directory partitions on the
rollback domain controller will be permanently inconsistent with direct and transitive
replication partners in the same Active Directory forest.

Recover from a USN rollback

There are three approaches to recover from a USN rollback.

Remove the Domain Controller from the domain. To do this, follow these steps:

1. Remove Active Directory from the domain controller to force it to be a

standalone server. For more information, see Domain controllers do not
demote gracefully when you use the Active Directory Installation Wizard to
force demotion.

2. Shut down the demoted server.

3. On a healthy domain controller, clean up the metadata of the demoted

domain controller. For more information, see Clean up Active Directory
Domain Controller server metadata.

4. If the incorrectly restored domain controller hosts operations master roles,

transfer these roles to a healthy domain controller. For more information, see
Transfer or seize Operation Master roles in Active Directory Domain Services.

5. Restart the demoted server.

6. If you are required to, install Active Directory on the stand-alone server again.

7. If the domain controller was previously a global catalog, configure the

domain controller to be a global catalog. For more information, see How to
create or move a global catalog .

8. If the domain controller previously hosted operations master roles, transfer

the operations master roles back to the domain controller. For more
information, see Transfer or seize Operation Master roles in Active Directory
Domain Services.

Restore the system state of a good backup.

 Evaluate whether valid system state backups exist for this domain controller. If a
valid system state backup was made before the rolled-back domain controller was
incorrectly restored, and the backup contains recent changes that were made on
the domain controller, restore the system state from the most recent backup.

Restore the system state without system state backup.

You can use the snapshot as a source of a backup. Or you can set the database to
give itself a new invocation ID by using the procedure in the To restore a previous
version of a virtual domain controller VHD without system state data backup
section of Running Domain Controllers in Hyper-V.

References
Things to consider when you host Active Directory domain controllers in virtual
hosting environments

Virtualized domain controller Architecture

Feedback
Was this page helpful?  Yes  No

Provide product feedback

NTDS Replication Event 2089 is logged
if Windows Server 2003 SP1 and later
domain controllers aren't backed up in a
given time period
Article • 02/19/2024

This article discusses the problem where a new event error message is logged if you
don't back up a Windows Server 2003 Service Pack 1 (SP1)-based domain controller in a
given time period that is called the backup latency interval.

Applies to: Window Server 2003

Original KB number: 914034

Introduction
When you back up a domain controller that is running Microsoft Windows Server 2003
Service Pack 1 (SP1), a new event error message is logged for each writable domain or
application partition that the domain controller hosts. This is true if the partition isn't
backed up in a given time period. The time period is called a backup latency interval.
You can set a registry value to specify this interval in days.

More information

New behavior in Windows Server 2003 SP1

The DSA Signature attribute is modified every time that a system state backup is made.
The operating system monitors this attribute. An event error message is logged when
the backup latency interval criteria are met. Any Windows Server 2003 SP1-based
domain controller may log the event because the DSA Signature attribute is a replicated
attribute.

７ Note

The new event error message is not logged until a backup is made on a Windows
Server 2003-based domain controller that is running Windows Server 2003 SP1.
 Only Windows Server 2003 SP1-based domain controllers log this event error
message.

The default time period of the backup latency interval is half of the Tombstone Lifetime
(TSL) for logging the event error message on the domain controller. The following list
shows the difference in the default TSL values for a forest that is created on Windows
Server 2003 and a forest that is created on Windows Server 2003 SP1:

Windows Server 2003

By default, the TSL value in Windows Server 2003 is 60 days. Therefore, the event error
message isn't logged until 30 days after the last backup.

Windows Server 2003 SP1

By default, the TSL value in new forest created by Windows Server 2003 SP1 is 180 days.
The TSL value is 60 days in all other cases. The event error message in a forest with a
180-day TSL isn't logged until 90 days after the last backup.

７ Note

If you just install Windows Server 2003 SP1 on Windows Server 2003-based
computers, this doesn't increase the TSL to 180 days. The forest must be created on
a server that has Windows Server 2003 SP1 installed at the time that you create it.
For more information, click the following article number to view the article in the
Microsoft Knowledge Base:
216993 Useful shelf life of a system-state backup of Active Directory

Deployment Strategy
The default value for the backup latency interval in a forest that uses the default TSL is
insufficient to correctly warn administrators that partitions aren't being backed up with
sufficient frequency.

In the registry, administrators can specify a value for the Backup Latency Threshold
(days) entry. This provides a simple method to adjust how soon event ID 2089, is logged
if a backup isn't made in a certain time period. Therefore, the time period reflects the
backup strategies of the administrators. This event error message serves as a warning to
administrators that domain controllers aren't being backed up before the TSL expires.
This event error message is also a useful tracking event to monitor applications such as
Microsoft Operations Manager (MOM).
We recommend that you take system state backups that include each forest, domain,
and application partition on at least two computers every day. We also recommend that
you configure this event to occur every other day if a backup isn't made. Third-party
backup programs may use a method that calls the backup API that updates the
attribute. When these programs use this method, it causes the DSA Signature attribute
to be updated.

An event ID 2089 error message is logged in the Directory Service event log when a
partition isn't backed up during the backup latency interval. Only one event error
message is logged each day for each partition that a domain controller hosts. The event
error message is similar to the following:

Event Type: Warning

Event Source: NTDS Replication
Event Category: Backup Event ID: 2089
Description: This directory partition has not been backed up since at least the
following number of days.

Directory partition:
DC=domainDC=com

"Backup latency interval" (days):

30

It's recommended that you take a backup as often as possible to recover from
accidental loss of data. However, if you haven't taken a backup since at least the
"backup latency interval" number of days, this message will be logged every day until a
backup is taken. You can take a backup of any replica that holds this partition.

By default the "Backup latency interval" is set to half the "Tombstone Lifetime Interval". If
you want to change the default "Backup latency interval", you could do so by adding the
following registry key.

"Backup latency interval" (days) registry key:

System\CurrentControlSet\Services\NTDS\Parameters\Backup Latency Threshold (days) .

７ Note

The value of Backup Latency Threshold (days) is a registry entry but not a key as
stated in the event error message. The backup latency interval is half the value of
the TSL of the forest. When this value is reached, the operating system logs event
ID 2089 in the Directory Service event log. This event ID warns administrators to
 monitor applications and to make sure that domain controllers are backed up
before the TSL expires. To set the interval that the operating system waits before an
event ID 2089 is logged, use Registry Editor to set the value of the Backup Latency
Threshold (days) entry. To do this, follow these steps:

1. Start Registry Editor.

2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

3. Right-click Parameters, point to New, and then click DWORD Value.

4. Type Backup Latency Threshold (days), and then press ENTER.
5. Right-click Backup Latency Threshold (days), and then click Modify.
6. In the Value data box, type the number of days to use as a threshold, and
then click OK.

References
https://blogs.msdn.com/brettsh/archive/2006/02/09/528708.aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to remove orphaned domains from
Active Directory
Article • 02/19/2024

Applies to: Windows 10, Windows Server 2012 R2

Original KB number: 230306

Summary
Typically, when the last domain controller for a domain is demoted, the administrator
selects the This server is the last domain controller in the domain option in the
DCPromo tool. This procedure removes the domain metadata from Active Directory.
This article describes how to remove domain metadata from Active Directory if this
procedure isn't used, or if all domain controllers are taken offline but not demoted first.

Ｕ Caution

The administrator must verify that replication has occurred since the demotion of
the last domain controller before manually removing the domain meta-data. Using
the NTDSUTIL tool improperly can cause partial or complete loss of Active
Directory functionality.

Removing orphaned domains from Active

Directory
1. Determine the domain controller that holds the Domain Naming Master Flexible
Single Master Operations (FSMO) role. To identify the server holding this role:
a. Start the Active Directory Domains and Trusts Microsoft Management Console
(MMC) snap-in from the Administrative Tools menu.
b. Right-click the root node in the left pane titled Active Directory Domains and
Trusts, and then select Operations Master.
c. The domain controller that currently holds this role is identified in the Current
Operations Master frame.

７ Note
 If it's changed recently, not all computer may have received this change yet
due to replication.

For more information about FSMO roles, see Active Directory FSMO roles in
Windows.

2. Verify that all servers for the domain have been demoted.

3. Open a command prompt window.

4. At the command prompt, type ntdsutil , and then press Enter.

5. Type metadata cleanup , and then press Enter.

6. Type connections , and then press Enter. This menu is used to connect to the
specific server on which the changes will occur. If the currently logged-on user isn't
a member of the Enterprise Admins group, alternate credentials can be supplied by
specifying the credentials to use before making the connection. To do so, type: set
creds <domainname> <username> <password> , and then press Enter. For a null

password, type null for the password parameter.

7. Type connect to server <servername> , where <servername> is the name of the

domain controller that holds the Domain Naming Master FSMO Role. Then press
Enter. You should receive confirmation that the connection is successfully
established. If an error occurs, verify that the domain controller used in the
connection is available. And verify that the credentials you supplied have
administrative permissions on the server.

8. Type quit , and then press Enter. The Metadata Cleanup menu is displayed.

9. Type select operation target , and then press Enter.

10. Type list domains , and then press Enter. A list of domains in the forest is
displayed, each with an associated number.

11. Type select domain <number> , and then press Enter, where number is the number
associated with the domain to be removed.

12. Type quit , and then press Enter. The Metadata Cleanup menu is displayed.

13. Type remove selected domain , and then press Enter. You should receive
confirmation that the removal was successful. If an error occurs, see the Microsoft
Knowledge Base for articles on specific error messages.
 14. Type quit at each menu to quit the NTDSUTIL tool. You should receive
confirmation that the connection disconnected successfully.

References
For more information about the NTDSUTIL tool, see the Support Tools documentation
located in the Support\Reskit folder on the Windows 2000 CD-ROM. The Help files
included with the Microsoft Windows 2000 Resource Kit contain a Books Online link. You
can click the link for information that describes the NTDSUTIL tool in greater detail.

For more information about removing domain controllers from the domain that you're
attempting to delete, see the following article:

216498 How to remove data in Active Directory after an unsuccessful domain

controller demotion

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to restore deleted user accounts
and their group memberships in Active
Directory
Article • 02/19/2024

This article provides information on how to restore deleted user accounts and group
memberships in Active Directory.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 840001

Introduction
You can use several methods to restore deleted user accounts, computer accounts, and
security groups. These objects are known collectively as security principals.

The most common method is to enable the AD Recycle Bin feature supported on
domain controllers based on Windows Server 2008 R2 and later. For more information
on this feature including how to enable it and restore objects, see Active Directory
Recycle Bin Step-by-Step Guide.

If this method isn't available to you, the following three methods can be used. In all
three methods, you authoritatively restore the deleted objects, and then you restore
group membership information for the deleted security principals. When you restore a
deleted object, you must restore the former values of the member and memberOf
attributes in the affected security principal.

７ Note

Recovering deleted objects in Active directory can be simplified by enabling the AD

Recycle Bin feature supported on domain controllers based on Windows Server
2008 R2 and later. For more information on this feature including how to enable it
and restore objects, see Active Directory Recycle Bin Step-by-Step Guide.

More information
Methods 1 and 2 provide a better experience for domain users and administrators.
These methods preserve the additions to security groups that were made between the
time of the last system state backup and the time the deletion occurred. In method 3,
you don't make individual adjustments to security principals. Instead, you roll back
security group memberships to their state at the time of the last backup.

Most large-scale deletions are accidental. Microsoft recommends that you take several
steps to prevent others from deleting objects in bulk.

７ Note

To prevent the accidental deletion or movement of objects (especially

organizational units), two Deny access control entries (ACEs) can be added to the
security descriptor of each object (DENY DELETE & DELETE TREE) and one Deny
access control entries (ACEs) can be added to the security descriptor of the PARENT
of each object (DENY DELETE CHILD). To do it, use Active Directory Users and
Computers, ADSIEdit, LDP, or the DSACLS command-line tool. You can also change
the default permissions in the AD schema for organizational units so that these
ACEs are included by default.

For example, to protect the organization unit that is called CONTOSO.COM from
accidentally being moved or deleted out of its parent organizational unit that is called
MyCompany, make the following configuration:

For the MyCompany organizational unit, add DENY ACE for Everyone to DELETE CHILD
with This object only scope:

Console

DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"/

For the Users organizational unit, add DENY ACE for Everyone to DELETE and DELETE
TREE with This object only scope:

Console

DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"

The Active Directory Users and Computers snap-in in Windows Server 2008 includes a
Protect object from accidental deletion check box on the Object tab.

７ Note
 The Advanced Features check box must be enabled to view that tab.

When you create an organizational unit by using Active Directory Users and Computers
in Windows Server 2008, the Protect container from accidental deletion check box
appears. By default, the check box is selected and can be deselected.

Although you can configure every object in Active Directory by using these ACEs, it's
best suited for organizational units. Deletion or movements of all leaf objects can have a
major effect. This configuration prevents such deletions or movements. To really delete
or move an object by using such a configuration, the Deny ACEs must be removed first.

This article discusses how to restore user accounts, computer accounts, and their group
memberships after they have been deleted from Active Directory. In variations of this
scenario, user accounts, computer accounts, or security groups may have been deleted
individually or in some combination. In all these cases, the same initial steps apply. You
authoritatively restore, or auth restore, those objects that were inadvertently deleted.
Some deleted objects require more work to be restored. These objects include objects
such as user accounts that contain attributes that are back links of the attributes of
other objects. Two of these attributes are managedBy and memberOf .

When you add security principals, such as a user account, a security group, or a
computer account to a security group, you make the following changes in Active
Directory:

1. The name of the security principal is added to the member attribute of each
security group.
2. For each security group that the user, the computer, or the security group is a
member of, a back link is added to the security principal's memberOf attribute.

Similarly, when a user, a computer, or a group is deleted from Active Directory, the
following actions occur:

1. The deleted security principal is moved into the deleted objects container.
2. A few attribute values, including the memberOf attribute, are stripped from the
deleted security principal.
3. Deleted security principals are removed from any security groups that they were a
member of. In other words, the deleted security principals are removed from each
security group's member attribute.

When you recover deleted security principals and restore their group memberships,
each security principal must exist in Active Directory before you restore its group
membership. The member may be a user, a computer, or another security group. To
restate this rule more broadly, an object that contains attributes whose values are back
links must exist in Active Directory before the object that contains that forward link can
be restored or modified.

This article focuses on how to recover deleted user accounts and their memberships in
security groups. Its concepts apply equally to other object deletions. This article's
concepts apply equally to deleted objects whose attribute values use forward links and
back links to other objects in Active Directory.

You can use either of the three methods to recover security principals. When you use
method 1, you leave in place all security principals that were added to any security
group across the forest. And you add only security principals that were deleted from
their respective domains back to their security groups. For example, you make a system
state backup, add a user to a security group, and then restore the system state backup.
When you use methods 1 or 2, you preserve any users who were added to security
groups that contain deleted users between the dates that the system state backup was
created and the date that the backup was restored. When you use method 3, you roll
back security group memberships for all the security groups that contain deleted users
to their state at the time of the system state backup.

Method 1 - Restore the deleted user accounts,

and then add the restored users back to their
groups by using the Ntdsutil.exe command-line
tool
The Ntdsutil.exe command-line tool allows you to restore the backlinks of deleted
objects. Two files are generated for each authoritative restore operation. One file
contains a list of authoritatively restored objects. The other file is a .ldf file that is used
with the Ldifde.exe utility. This file is used to restore the backlinks for the objects that
are authoritatively restored. An authoritative restoration of a user object also generates
LDAP Data Interchange Format (LDIF) files with the group membership. This method
avoids a double restoration.

When you use this method, you perform the following high-level steps:

1. Check if a global catalog in the user's domain hasn't replicated in the deletion. And
then prevent that global catalog from replicating. If there's no latent global
catalog, locate the most current system state backup of a global catalog domain
controller in the deleted user's home domain.
2. Auth restore all the deleted user accounts, and then permit end-to-end replication
of those user accounts.
 3. Add all the restored users back to all the groups in all the domains that the user
accounts were a member of before they were deleted.

To use method 1, follow this procedure:

1. Check whether there's a global catalog domain controller in the deleted user's
home domain that hasn't replicated any part of the deletion.

７ Note

Focus on the global catalogs that have the least frequent replication
schedules.

If one or more of these global catalogs exist, use the Repadmin.exe command-line
tool to immediately disable inbound replication by following these steps:

a. Select Start, and then select Run.

b. Type cmd in the Open box, and then select OK.

c. Type the following command at the command prompt, and then press ENTER:

Console

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

７ Note

If you can't issue the Repadmin command immediately, remove all network
connectivity from the latent global catalog until you can use Repadmin to
disable inbound replication, and then immediately return network
connectivity.

This domain controller will be referred to as the recovery domain controller. If

there is no such global catalog, go to step 2.

2. It's best to stop making changes to security groups in the forest if all the following
statements are true:

You're using method 1 to authoritatively restore deleted users or computer

accounts by their distinguished name (dn) path.
The deletion has replicated to all the domain controllers in the forest except
the latent recovery domain controller.
 You're not auth restoring security groups or their parent containers.

If you're auth restoring security groups or organizational unit (OU) containers that
host security groups or user accounts, temporarily stop all these changes.

Notify administrators and help desk administrators in the appropriate domains in

addition to domain users in the domain where the deletion occurred about
stopping these changes.

3. Create a new system state backup in the domain where the deletion occurred. You
can use this backup if you have to roll back your changes.

７ Note

If system state backups are current up to the point of the deletion, skip this
step and go to step 4.

If you identified a recovery domain controller in step 1, back up its system state
now.

If all the global catalogs located in the domain where the deletion occurred
replicated in the deletion, back up the system state of a global catalog in the
domain where the deletion occurred.

When you create a backup, you can return the recovery domain controller back to
its current state. And perform your recovery plan again if your first try isn't
successful.

4. If you can't find a latent global catalog domain controller in the domain where the
user deletion occurred, find the most recent system state backup of a global
catalog domain controller in that domain. This system state backup should contain
the deleted objects. Use this domain controller as the recovery domain controller.

Only restorations of the global catalog domain controllers in the user's domain
contain global and universal group membership information for security groups
that reside in external domains. If there's no system state backup of a global
catalog domain controller in the domain where users were deleted, you can't use
the memberOf attribute on restored user accounts to determine global or universal
group membership or to recover membership in external domains. Additionally,
it's a good idea to find the most recent system state backup of a non-global
catalog domain controller.
5. If you know the password for the offline administrator account, start the recovery
domain controller in Disrepair mode. If you don't know the password for the
offline administrator account, reset the password using ntdsutil.exe while the
recovery domain controller is still in normal Active Directory mode.

You can use the setpwd command-line tool to reset the password on domain
controllers while they are in online Active Directory mode.

７ Note

Microsoft no longer supports Windows 2000.

Administrators of Windows Server 2003 and later domain controllers can use the
set dsrm password command in the Ntdsutil command-line tool to reset the

password for the offline administrator account.

For more information about how to reset the Directory Services Restore Mode
administrator account, see How To Reset the Directory Services Restore Mode
Administrator Account Password in Windows Server .

6. Press F8 during the startup process to start the recovery domain controller in
Disrepair mode. Sign in to the console of the recovery domain controller with the
offline administrator account. If you reset the password in step 5, use the new
password.

If the recovery domain controller is a latent global catalog domain controller, don't
restore the system state. Go to step 7.

If you're creating the recovery domain controller by using a system state backup,
restore the most current system state backup that was made on the recovery
domain controller now.

7. Auth restore the deleted user accounts, the deleted computer accounts, or the
deleted security groups.

７ Note

The terms auth restore and authoritative restore refer to the process of using
the authoritative restore command in the Ntdsutil command-line tool to
increment the version numbers of specific objects or of specific containers
and all their subordinate objects. As soon as end-to-end replication occurs,
the targeted objects in the recovery domain controller's local copy of Active
Directory become authoritative on all the domain controllers that share that
 partition. An authoritative restoration is different from a system state
restoration. A system state restoration populates the restored domain
controller's local copy of Active Directory with the versions of the objects at
the time that the system state backup was made.

Authoritative restorations are performed with the Ntdsutil command-line tool, and
refer to the domain name (dn) path of the deleted users or of the containers that
host the deleted users.

When you auth restore, use domain name (dn) paths that are as low in the domain
tree as they have to be. The purpose is to avoid reverting objects that aren't
related to the deletion. These objects may include objects that were modified after
the system state backup was made.

Auth restore deleted users in the following order:

a. Auth restore the domain name (dn) path for each deleted user account,
computer account, or security group.

Authoritative restorations of specific objects take longer but are less destructive
than authoritative restorations of a whole subtree. Auth restore the lowest
common parent container that holds the deleted objects.

Ntdsutil uses the following syntax:

Console

ntdsutil "authoritative restore" "restore object <object DN path>" q

q

For example, to authoritatively restore the deleted user John Doe in the
Mayberry OU of the Contoso.com domain, use the following command:

Console

ntdsutil "authoritative restore" "restore object

cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

To authoritatively restore the deleted security group ContosoPrintAccess in the

Mayberry OU of the Contoso.com domain, use the following command:

Console
 ntdsutil "authoritative restore" "restore object
cn=ContosoPrintAccess,ou=Mayberry,dc=contoso,dc=com" q q

） Important

The use of quotes is required.

For each user that you restore, at least two files are generated. These files have
the following format:

ar_YYYYMMDD-HHMMSS_objects.txt
This file contains a list of the authoritatively restored objects. Use this file with
the ntdsutil authoritative restore create ldif file from command in any other
domain in the forest where the user was a member of Domain Local groups.

ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf
If you perform the auth restore on a global catalog, one of these files is
generated for every domain in the forest. This file contains a script that you can
use with the Ldifde.exe utility. The script restores the backlinks for the restored
objects. In the user's home domain, the script restores all the group
memberships for the restored users. In all other domains in the forest where the
user has group membership, the script restores only universal and global group
memberships. The script doesn't restore any Domain Local group memberships.
These memberships are not tracked by a global catalog.

b. Auth restore only the OU or Common-Name (CN) containers that host the
deleted user accounts or groups.

Authoritative restorations of a whole subtree are valid when the OU targeted by

the ntdsutil authoritative restore command contains most of the objects that
you're trying to authoritatively restore. Ideally, the targeted OU contains all the
objects that you're trying to authoritatively restore.

An authoritative restoration on an OU subtree restores all the attributes and

objects that reside in the container. Any changes that were made up to the time
that a system state backup is restored are rolled back to their values at the time
of the backup. With user accounts, computer accounts, and security groups, this
rollback may mean the loss of the most recent changes to:

passwords
the home directory
the profile path
 location
contact info
group membership
any security descriptors that are defined on those objects and attributes.

Ntdsutil uses the following syntax:

Console

ntdsutil "authoritative restore" "restore subtree <container DN

path>" q q

For example, to authoritatively restore the Mayberry OU of the Contoso.com

domain, use the following command:

Console

ntdsutil "authoritative restore" "restore subtree ou=Mayberry,

dc=contoso,dc=com" q q

７ Note

Repeat this step for each peer OU that hosts deleted users or groups.

） Important

When you restore a subordinate object of an OU, all the deleted parent
containers of the deleted subordinate objects must be explicitly auth
restored.

For each organizational unit that you restore, at least two files are generated.
These files have the following format:

ar_YYYYMMDD-HHMMSS_objects.txt
This file contains a list of the authoritatively restored objects. Use this file with
the ntdsutil authoritative restore create ldif file from command in any other
domain in the forest where the restored users were members of Domain Local
groups.

ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf
This file contains a script that you can use with the Ldifde.exe utility. The script
 restores the backlinks for the restored objects. In the user's home domain, the
script restores all the group memberships for the restored users.

8. If deleted objects were recovered on the recovery domain controller because of a

system state restore, remove all the network cables that provide network
connectivity to all the other domain controllers in the forest.

9. Restart the recovery domain controller in normal Active Directory mode.

10. Type the following command to disable inbound replication to the recovery
domain controller:

Console

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

Enable network connectivity back to the recovery domain controller whose system
state was restored.

11. Outbound-replicate the auth-restored objects from the recovery domain controller
to the domain controllers in the domain and in the forest.

While inbound replication to the recovery domain controller remains disabled, type
the following command to push the auth-restored objects to all the cross-site
replica domain controllers in the domain and to all the global catalogs in the
forest:

Console

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

If all the following statements are true, group membership links are rebuilt with the
restoration and the replication of the deleted user accounts. Go to step 14.

７ Note

If one or more of the following statements isn't true, go to step 12.

Your forest is running at the Windows Server 2003 and later or later forest
functional level or at the Windows Server 2003 and later or later Interim
forest functional level.
Only user accounts or computer accounts were deleted, and not security
groups.
 The deleted users were added to security groups in all the domains in the
forest after the forest was transitioned to Windows Server 2003 and later, or
later forest functional level.

12. On the console of the recovery domain controller, use the Ldifde.exe utility and the
ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf file to restore the user's group
memberships. To do it, follow these steps:

Select Start, select Run, type cmd in the Open box, and then select OK.

At the command prompt, type the following command, and then press
ENTER:

Console

ldifde -i -f ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf

13. Enable inbound replication to the recovery domain controller by using the
following command:

Console

repadmin /options <recovery dc name> -DISABLE_INBOUND_REPL

14. If deleted users were added to local groups in external domains, take one of the
following actions:

Manually add the deleted users back to those groups.

Restore the system state and auth restore each of the local security groups
that contains the deleted users.

15. Verify group membership in the recovery domain controller's domain, and in
global catalogs in other domains.

16. Make a new system state backup of domain controllers in the recovery domain
controller's domain.

17. Notify all the forest administrators, delegated administrators, help desk
administrators in the forest, and users in the domain that the user restore is
complete.

Help desk administrators may have to reset the passwords of auth-restored user
accounts and computer accounts whose domain password changed after the
restored system was made.
 Users who changed their passwords after the system state backup was made will
find that their most recent password no longer works. Have such users try to log
on by using their previous passwords if they know them. Otherwise, help desk
administrators must reset the password and select the user must change
password at next logon check box. Do it preferably on a domain controller in the
same Active Directory site as the user is located in.

Method 2 - Restore the deleted user accounts,

and then add the restored users back to their
groups
When you use this method, you perform the following high-level steps:

1. Check if a global catalog in the user's domain hasn't replicated in the deletion. And
then prevent that global catalog from replicating. If there is no latent global
catalog, locate the most current system state backup of a global catalog domain
controller in the deleted user's home domain.
2. Auth restore all the deleted user accounts, and then permit end-to-end replication
of those user accounts.
3. Add all the restored users back to all the groups in all the domains that the user
accounts were a member of before they were deleted.

To use method 2, follow this procedure:

1. Check whether there's a global catalog domain controller in the deleted user's
home domain that hasn't replicated any part of the deletion.

７ Note

Focus on the global catalogs that have the least frequent replication
schedules.

If one or more of these global catalogs exist, use the Repadmin.exe command-line
tool to immediately disable inbound replication. To do it, follow these steps:
a. Select Start, and then select Run.
b. Type cmd in the Open box, and then select OK.
c. Type the following command at the command prompt, and then press ENTER:

Console
 repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

７ Note

If you can't issue the Repadmin command immediately, remove all network
connectivity from the latent global catalog until you can use Repadmin to
disable inbound replication, and then immediately return network
connectivity.

This domain controller will be referred to as the recovery domain controller. If

there is no such global catalog, go to step 2.

2. Decide whether additions, deletions, and changes to user accounts, computer

accounts, and security groups must be temporarily stopped until all the recovery
steps have been completed.

To maintain the most flexible recovery path, temporarily stop making changes to
the following items. Changes include password resets by domain users, help desk
administrators, and administrators in the domain where the deletion occurred, in
addition to group membership changes in the deleted users' groups. Consider
halting additions, deletions, and modifications to the following items:
a. User accounts and attributes on user accounts
b. Computer accounts and attributes on computer accounts
c. Service accounts
d. Security groups

It's best to stop making changes to security groups in the forest if all the following
statements are true:

You're using method 2 to authoritatively restore deleted users or computer

accounts by their domain name (dn) path.
The deletion has replicated to all the domain controllers in the forest except
the latent recovery domain controller.
You're not auth restoring security groups or their parent containers.

If you're auth restoring security groups or organizational unit (OU) containers that
host security groups or user accounts, temporarily stop all these changes.

Notify administrators and help desk administrators in the appropriate domains in

addition to domain users in the domain where the deletion occurred about
stopping these changes.
3. Create a new system state backup in the domain where the deletion occurred. You
can use this backup if you have to roll back your changes.

７ Note

If system state backups are current up to the point of the deletion, skip this
step and go to step 4.

If you identified a recovery domain controller in step 1, back up its system state
now.

If all the global catalogs located in the domain where the deletion occurred
replicated in the deletion, back up the system state of a global catalog in the
domain where the deletion occurred.

When you create a backup, you can return the recovery domain controller back to
its current state. And perform your recovery plan again if your first try isn't
successful.

4. If you can't find a latent global catalog domain controller in the domain where the
user deletion occurred, find the most recent system state backup of a global
catalog domain controller in that domain. This system state backup should contain
the deleted objects. Use this domain controller as the recovery domain controller.

Only restorations of the global catalog domain controllers in the user's domain
contain global and universal group membership information for security groups
that reside in external domains. If there is no system state backup of a global
catalog domain controller in the domain where users were deleted, you can't use
the memberOf attribute on restored user accounts to determine global or universal
group membership or to recover membership in external domains. Additionally,
it's a good idea to find the most recent system state backup of a non-global
catalog domain controller.

5. If you know the password for the offline administrator account, start the recovery
domain controller in Disrepair mode. If you don't know the password for the
offline administrator account, reset the password while the recovery domain
controller is still in normal Active Directory mode.

You can use the setpwd command-line tool to reset the password on domain
controllers that are running Windows 2000 Service Pack 2 (SP2) and later while
they are in online Active Directory mode.
 ７ Note

Microsoft no longer supports Windows 2000.

Administrators of Windows Server 2003 and later domain controllers can use the
set dsrm password command in the Ntdsutil command-line tool to reset the

password for the offline administrator account.

For more information about how to reset the Directory Services Restore Mode
administrator account, see How To Reset the Directory Services Restore Mode
Administrator Account Password in Windows Server .

6. Press F8 during the startup process to start the recovery domain controller in
Disrepair mode. Sign in to the console of the recovery domain controller with the
offline administrator account. If you reset the password in step 5, use the new
password.

If the recovery domain controller is a latent global catalog domain controller, don't
restore the system state. Go to step 7.

If you're creating the recovery domain controller by using a system state backup,
restore the most current system state backup that was made on the recovery
domain controller now.

7. Auth restore the deleted user accounts, the deleted computer accounts, or the
deleted security groups.

７ Note

The terms auth restore and authoritative restore refer to the process of using
the authoritative restore command in the Ntdsutil command-line tool to
increment the version numbers of specific objects or of specific containers
and all their subordinate objects. As soon as end-to-end replication occurs,
the targeted objects in the recovery domain controller's local copy of Active
Directory become authoritative on all the domain controllers that share that
partition. An authoritative restoration is different from a system state
restoration. A system state restoration populates the restored domain
controller's local copy of Active Directory with the versions of the objects at
the time that the system state backup was made.

Authoritative restorations are performed with the Ntdsutil command-line tool, and
refer to the domain name (dn) path of the deleted users or of the containers that
host the deleted users.

When you auth restore, use domain name (dn) paths that are as low in the domain
tree as they have to be. The purpose is to avoid reverting objects that aren't
related to the deletion. These objects may include objects that were modified after
the system state backup was made.

Auth restore deleted users in the following order:

a. Auth restore the domain name (dn) path for each deleted user account,
computer account, or security group.

Authoritative restorations of specific objects take longer but are less destructive
than authoritative restorations of a whole subtree. Auth restore the lowest
common parent container that holds the deleted objects.

Ntdsutil uses the following syntax:

Console

ntdsutil "authoritative restore" "restore object <object DN path>" q

q

For example, to authoritatively restore the deleted user John Doe in the
Mayberry OU of the Contoso.com domain, use the following command:

Console

ntdsutil "authoritative restore" "restore object

cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

To authoritatively restore the deleted security group ContosoPrintAccess in the

Mayberry OU of the Contoso.com domain, use the following command:

Console

ntdsutil "authoritative restore" "restore object

cn=ContosoPrintAccess,ou=Mayberry,dc=contoso,dc=com" q q

） Important

The use of quotes is required.

 ７ Note

This syntax is available only in Windows Server 2003 and later. The only
syntax in Windows 2000 is to use the following:

Console

ntdsutil "authoritative restore" "restore subtree object DN path"

７ Note

The Ntdsutil authoritative restore operation isn't successful if the

distinguished name path (DN) contains extended characters or spaces. In
order for the scripted restore to succeed, the restore object <DN path>
command must be passed as one complete string.

To work around this problem, wrap the DN that contains extended characters
and spaces with backslash-double-quotation-mark escape sequences. Here is
an example:

Console

ntdsutil "authoritative restore" "restore object \"CN=John

Doe,OU=Mayberry NC,DC=contoso,DC=com\"" q q

７ Note

The command must be modified further if the DN of objects being

restored contain commas. See the following example:

Console

ntdsutil "authoritative restore" "restore object \"CN=Doe\,

John,OU=Mayberry NC,DC=contoso,DC=com\"" q q

７ Note

If the objects were restored from tape, marked authoritative and the
restore did not work as expected and then the same tape is used to restore
 the NTDS database once again, the USN version of objects to be restored
authoritatively must be increased higher than the default of 100000 or the
objects will not replicate out after the second restore. The syntax below is
needed to script an increased version number higher than 100000 (default):

Console

ntdsutil "authoritative restore" "restore object \"CN=Doe\,

John,OU=Mayberry NC,DC=contoso,DC=com\" verinc 150000\"" q q

７ Note

If the script prompts for confirmation on each object being restored you
can turn off the prompts. The syntax to turn off prompting is:

Console

ntdsutil "popups off" "authoritative restore" "restore object

\"CN=John Doe,OU=Mayberry NC,DC=contoso,DC=com\" verinc 150000\"" q
q

b. Auth restore only the OU or Common-Name (CN) containers that host the
deleted user accounts or groups.

Authoritative restorations of a whole subtree are valid when the OU targeted by

the ntdsutil authoritative restore command contains most of the objects that
you're trying to authoritatively restore. Ideally, the targeted OU contains all the
objects that you're trying to authoritatively restore.

An authoritative restoration on an OU subtree restores all the attributes and

objects that reside in the container. Any changes that were made up to the time
that a system state backup is restored are rolled back to their values at the time
of the backup. With user accounts, computer accounts, and security groups, this
rollback may mean the loss of the most recent changes to passwords, to the
home directory, to the profile path, to location and to contact info, to group
membership, and to any security descriptors that are defined on those objects
and attributes.

Ntdsutil uses the following syntax:

Console
 ntdsutil "authoritative restore" "restore subtree <container DN
path>" q q

For example, to authoritatively restore the Mayberry OU of the Contoso.com

domain, use the following command:

Console

ntdsutil "authoritative restore" "restore subtree ou=Mayberry,

dc=contoso,dc=com" q q

７ Note

Repeat this step for each peer OU that hosts deleted users or groups.

） Important

When you restore a subordinate object of an OU, all the deleted parent
containers of the deleted subordinate objects must be explicitly auth
restored.

8. If deleted objects were recovered on the recovery domain controller because of a

system state restore, remove all the network cables that provide network
connectivity to all the other domain controllers in the forest.

9. Restart the recovery domain controller in normal Active Directory mode.

10. Type the following command to disable inbound replication to the recovery
domain controller:

Console

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

Enable network connectivity back to the recovery domain controller whose system
state was restored.

11. Outbound-replicate the auth-restored objects from the recovery domain controller
to the domain controllers in the domain and in the forest.
 While inbound replication to the recovery domain controller remains disabled, type
the following command to push the auth-restored objects to all the cross-site
replica domain controllers in the domain and to all the global catalogs in the
forest:

Console

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

If all the following statements are true, group membership links are rebuilt with the
restoration and the replication of the deleted user accounts. Go to step 14.

７ Note

If one or more of the following statements isn't true, go to step 12.

Your forest is running at the Windows Server 2003 and later forest functional
level, or at the Windows Server 2003 and later Interim forest functional level.
Only user accounts or computer accounts were deleted, and not security
groups.
The deleted users were added to security groups in all the domains in the
forest after the forest was transitioned to Windows Server 2003 and later
forest functional level.

12. Determine which security groups the deleted users were members of, and then
add them to those groups.

７ Note

Before you can add users to groups, the users who you auth restored in step 7
and who you outbound-replicated in step 11 must have replicated to the
domain controllers in the referenced domain controller's domain and to all
the global catalog domain controllers in the forest.

If you have deployed a group-provisioning utility to repopulate membership for

security groups, use that utility to restore deleted users to the security groups that
they were members of before they were deleted. Do it after all the direct and
transitive domain controllers in the forest's domain and global catalog servers have
inbound-replicated the auth-restored users and any restored containers.
If you don't have the utility, the Ldifde.exe and Groupadd.exe command-line tools
can automate this task for you when they are run on the recovery domain
controller. These tools are available from Microsoft Product Support Services. In
this scenario, Ldifde.exe creates an LDAP Data Interchange Format (LDIF)
information file that contains the names of the user accounts and their security
groups. It starts at an OU container that the administrator specifies. Groupadd.exe
then reads the memberOf attribute for each user account that's listed in the .ldf file.
It then generates separate and unique LDIF information for each domain in the
forest. This LDIF information contains the names of the security groups associated
with the deleted users. Use the LDIF information to add the information back to
the users so that their group memberships can be restored. Follow these steps for
this phase of the recovery:

a. Sign in to the recovery domain controller's console by using a user account that
is a member of the domain administrator's security group.

b. Use the Ldifde command to dump the names of the formerly deleted user
accounts and their memberOf attributes, starting at the topmost OU container
where the deletion occurred. The Ldifde command uses the following syntax:

Console

ldifde -d <dn path of container that hosts deleted users> -r "

(objectClass=user)" -l memberof -p subtree -f
user_membership_after_restore.ldf

Use the following syntax if deleted computer accounts were added to security
groups:

Console

ldifde -d <dn path of container that hosts deleted users> -r "

(objectClass=computer)" -l memberof -p subtree -f
computer_membership_after_restore.ldf

c. Run the Groupadd command to build more .ldf files that contain the names of
domains and the names of global and universal security groups that the deleted
users were a member of. The Groupadd command uses the following syntax:

Console

Groupadd / after_restore users_membership_after_restore.ldf

 Repeat this command if deleted computer accounts were added to security
groups.

d. Import each Groupadd _fully.qualified.domain.name.ldf file that you created in

step 12c to a single global catalog domain controller that corresponds with
each domain's .ldf file. Use the following Ldifde syntax:

Console

Ldifde -i -k -f Groupadd_<fully.qualified.domain.name>.ldf

Run the .ldf file for the domain that the users were deleted from on any domain
controller except the recovery domain controller.

e. On the console of each domain controller that's used to import the

Groupadd_<fully.qualified.domain.name>.ldf file for a particular domain,
outbound-replicate the group membership additions to the other domain
controllers in the domain, and to the global catalog domain controllers in the
forest. To do it, use the following command:

Console

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

13. To disable outbound replication, type the following text, and then press ENTER:

Console

repadmin /options +DISABLE_OUTBOUND_REPL

７ Note

To re-enable outbound replication, type the following text, and then press
ENTER:

Console

repadmin /options -DISABLE_OUTBOUND_REPL

14. If deleted users were added to local groups in external domains, take one of the
following actions:
 Manually add the deleted users back to those groups.
Restore the system state and auth restore each of the local security groups
that contains the deleted users.

15. Verify group membership in the recovery domain controller's domain, and in
global catalogs in other domains.

16. Make a new system state backup of domain controllers in the recovery domain
controller's domain.

17. Notify all the forest administrators, delegated administrators, help desk
administrators in the forest, and users in the domain that the user restore is
complete.

Help desk administrators may have to reset the passwords of auth-restored user
accounts and computer accounts whose domain password changed after the
restored system was made.

Users who changed their passwords after the system state backup was made will
find that their most recent password no longer works. Have such users try to log
on by using their previous passwords if they know them. Otherwise, help desk
administrators must reset the password and select the user must change
password at next logon check box. Do it preferably on a domain controller in the
same Active Directory site as the user is located in.

Method 3 - Authoritatively restore the deleted

users and the deleted users' security groups
two times
When you use this method, you perform the following high-level steps:

1. Check if a global catalog in the user's domain hasn't replicated in the deletion. And
then prevent that domain controller from inbound-replicating the deletion. If there
is no latent global catalog, locate the most current system state backup of a global
catalog domain controller in the deleted user's home domain.
2. Authoritatively restore all deleted user accounts and all security groups in the
deleted user's domain.
3. Wait for the end-to-end replication of the restored users and the security groups
to all the domain controllers in the deleted user's domain, and to the forest's
global catalog domain controllers.
4. Repeat steps 2 and 3 to authoritatively restore deleted users and security groups.
(You restore the system state only one time.)
 5. If the deleted users were members of security groups in other domains,
authoritatively restore all the security groups that the deleted users were members
of in those domains. Or, if system state backups are current, authoritatively restore
all the security groups in those domains. To satisfy the requirement that deleted
group members must be restored before security groups to fix up group
membership links, you restore both object types twice in this method. The first
restoration puts all the user accounts and group accounts in place. The second
restoration restores deleted groups and repairs the group membership
information, including membership information for nested groups.

To use method 3, follow this procedure:

1. Check whether a global catalog domain controller exists in the deleted users home
domain and hasn't replicated in any part of the deletion.

７ Note

Focus on global catalogs in the domain that has the least frequent replication
schedules. If these domain controllers exist, use the Repadmin.exe command-
line tool to immediately disable inbound replication. To do it, follow these
steps:

a. Select Start, and then select Run.

b. Type cmd in the Open box, and then select OK.
c. Type repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL at the
command prompt, and then press ENTER.

７ Note

If you cannot issue the Repadmin command immediately, remove all network
connectivity from the domain controller until you can use Repadmin to
disable inbound replication, and then immediately return network
connectivity.

This domain controller will be referred to as the recovery domain controller.

2. Avoid making additions, deletions, and changes to the following items until all the
recovery steps have been completed. Changes include password resets by domain
users, help desk administrators, and administrators in the domain where the
deletion occurred, in addition to group membership changes in the deleted users'
groups.
 a. User accounts and attributes on user accounts

b. Computer accounts and attributes on computer accounts

c. Service accounts

d. Security groups

７ Note

Especially avoid changes to group membership for users, computers,

groups, and service accounts in the forest where the deletion occurred.

e. Notify all the forest administrators, the delegated administrators, and the help
desk administrators in the forest of the temporary stand-down. This stand-down
is required in method 2 because you're authoritatively restoring all the deleted
users' security groups. Therefore, any changes that are made to groups after the
date of system state backup are lost.

3. Create a new system state backup in the domain where the deletion occurred. You
can use this backup if you have to roll back your changes.

７ Note

If your system state backups are current up to the time that the deletion
occurred, skip this step and go to step 4.

If you identified a recovery domain controller in step 1, back up its system state
now.

If all the global catalogs that are located in the domain where the deletion
occurred replicated the deletion, back up the system state of a global catalog in
the domain where the deletion occurred.

When you create a backup, you can return the recovery domain controller back to
its current state. And perform your recovery plan again if your first try isn't
successful.

4. If you can't find a latent global catalog domain controller in the domain where the
user deletion occurred, find the most recent system state backup of a global
catalog domain controller in that domain. This system state backup should contain
the deleted objects. Use this domain controller as the recovery domain controller.
 Only databases of the global catalog domain controllers in the user's domain
contain group membership information for external domains in the forest. If
there's no system state backup of a global catalog domain controller in the
domain where users were deleted, you can't use the memberOf attribute on
restored user accounts to determine global or universal group membership, or to
recover membership in external domains. Go to the next step. If there is an
external record of group membership in external domains, add the restored users
to security groups in those domains after the user accounts have been restored.

5. If you know the password for the offline administrator account, start the recovery
domain controller in Disrepair mode. If you don't know the password for the
offline administrator account, reset the password while the recovery domain
controller is still in normal Active Directory mode.

You can use the setpwd command-line tool to reset the password on domain
controllers that are running Windows 2000 SP2 and later while they are in online
Active Directory mode.

７ Note

Microsoft no longer supports Windows 2000.

Administrators of Windows Server 2003 and later domain controllers can use the
set dsrm password command in the Ntdsutil command-line tool to reset the

password for the offline administrator account.

For more information about how to reset the Directory Services Restore Mode
administrator account, see How To Reset the Directory Services Restore Mode
Administrator Account Password in Windows Server .

6. Press F8 during the startup process to start the recovery domain controller in
Disrepair mode. Log on to the console of the recovery domain controller with the
offline administrator account. If you reset the password in step 5, use the new
password.

If the recovery domain controller is a latent global catalog domain controller, don't
restore the system state. Go directly to step 7.

If you're creating the recovery domain controller by using a system state backup,
restore the most current system state backup that was made on the recovery
domain controller that contains the deleted objects now.
7. Auth restore the deleted user accounts, the deleted computer accounts, or the
deleted security groups.

７ Note

The terms auth restore and authoritative restore refer to the process of using
the authoritative restore command in the Ntdsutil command-line tool to
increment the version numbers of specific objects or of specific containers
and all their subordinate objects. As soon as end-to-end replication occurs,
the targeted objects in the recovery domain controller's local copy of Active
Directory become authoritative on all the domain controllers that share that
partition. An authoritative restoration is different from a system state
restoration. A system state restoration populates the restored domain
controller's local copy of Active Directory with the versions of the objects at
the time that the system state backup was made.

Authoritative restorations are performed with the Ntdsutil command-line tool by

referencing the domain name (dn) path of the deleted users, or of the containers
that host the deleted users.

When you auth restore, use domain name paths that are as low in the domain tree
as they have to be. The purpose is to avoid reverting objects that aren't related to
the deletion. These objects may include objects that were modified after the
system state backup was made.

Auth restore deleted users in the following order:

a. Auth restore the domain name (dn) path for each deleted user account,
computer account, or deleted security group.

Authoritative restorations of specific objects take longer but are less destructive
than authoritative restorations of a whole subtree. Auth restore the lowest
common parent container that holds the deleted objects.

Ntdsutil uses the following syntax:

Console

ntdsutil "authoritative restore" "restore object <object DN path>" q

q

For example, to authoritatively restore the deleted user John Doe in the
Mayberry OU of the Contoso.com domain, use the following command:
 Console

ntdsutil "authoritative restore" "restore object

cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

To authoritatively restore the deleted security group ContosoPrintAccess in the

Mayberry OU of the Contoso.com domain, use the following command:

Console

ntdsutil "authoritative restore" "restore object

cn=ContosoPrintAccess,ou=Mayberry,dc=contoso,dc=com" q q

） Important

The use of quotes is required.

By using this Ntdsutil format, you can also automate the authoritative
restoration of many objects in a batch file or a script.

７ Note

This syntax is available only in Windows Server 2003 and later. The only
syntax in Windows 2000 is to use: ntdsutil "authoritative restore"
"restore subtree object DN path" .

b. Auth restore only the OU or Common-Name (CN) containers that host the
deleted user accounts or groups.

Authoritative restorations of a whole subtree are valid when the OU targeted by

the Ntdsutil Authoritative restore command contains most of the objects that
you're trying to authoritatively restore. Ideally, the targeted OU contains all the
objects that you're trying to authoritatively restore.

An authoritative restore on an OU subtree restores all the attributes and objects

that reside in the container. Any changes that were made up to the time that a
system state backup is restored are rolled back to their values at the time of the
backup. With user accounts, computer accounts, and security groups, this
rollback may mean the loss of the most recent changes to passwords, to the
home directory, to the profile path, to location and to contact info, to group
 membership, and to any security descriptors that are defined on those objects
and attributes.

Ntdsutil uses the following syntax:

Console

ntdsutil "authoritative restore" "restore subtree <container DN

path>" q q

For example, to authoritatively restore the Mayberry OU of the Contoso.com

domain, use the following command:

Console

ntdsutil "authoritative restore" "restore subtree

ou=Mayberry,dc=contoso,dc=com" q q

７ Note

Repeat this step for each peer OU that hosts deleted users or groups.

） Important

When you restore a subordinate object of an OU, all the parent containers
of the deleted subordinate objects must be explicitly auth restored.

8. Restart the recovery domain controller in normal Active Directory mode.

9. Outbound-replicate the authoritatively restored objects from the recovery domain

controller to the domain controllers in the domain and in the forest.

While inbound replication to the recovery domain controller remains disabled, type
the following command to push the authoritatively restored objects to all the
cross-site replica domain controllers in the domain and to global catalogs in the
forest:

Console

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

 After all the direct and transitive domain controllers in the forest's domain and
global catalog servers have replicated in the authoritatively restored users and any
restored containers, go to step 11.

If all the following statements are true, group membership links are rebuilt with the
restoration of the deleted user accounts. Go to step 13.

Your forest is running at the Windows Server 2003 and later forest functional
level, or at the Windows Server 2003 and later interim forest functional level.
Only security groups were not deleted.
All the deleted users were added to all the security groups in all the domains
in the forest.

Consider using the Repadmin command to accelerate the outbound replication of

users from the restored domain controller.

If groups were also deleted, or if you can't guarantee that all the deleted users
were added to all the security groups after the transition to the Windows Server
2003 and later interim or forest functional level, go to step 12.

10. Repeat steps 7, 8, and 9 without restoring the system state, and then go to step 11.

11. If deleted users were added to local groups in external domains, take one of the
following actions:

Manually add the deleted users back to those groups.

Restore the system state and auth restore each of the local security groups
that contains the deleted users.

12. Verify group membership in the recovery domain controller's domain, and in
global catalogs in other domains.

13. Use the following command to enable inbound replication to the recovery domain
controller:

Console

repadmin /options recovery dc name -DISABLE_INBOUND_REPL

14. Make a new system state backup of domain controllers in the recovery domain
controller's domain and global catalogs in other domains in the forest.

15. Notify all the forest administrators, the delegated administrators, the help desk
administrators in the forest, and the users in the domain that the user restore is
complete.
 Help desk administrators may have to reset the passwords of auth restored user
accounts and computer accounts whose domain password changed after the
restored system was made.

Users who changed their passwords after the system state backup was made will
find that their most recent password no longer works. Have such users try to log
on by using their previous passwords if they know them. Otherwise, help desk
administrators must reset the password with the user must change password at
next logon check box checked. Do it preferably on a domain controller in the same
Active Directory site as the user is located in.

How to recover deleted users on a domain

controller when you do not have a valid system
state backup
If you lack current system state backups in a domain where user accounts or security
groups were deleted, and the deletion occurred in domains that contain Windows
Server 2003 and later domain controllers, follow these steps to manually reanimate
deleted objects from the deleted objects container:

1. Follow the steps in the following section to reanimate deleted users, computers,
groups, or all of them:
How to manually undelete objects in a deleted objects container
2. Use Active Directory Users and Computers to change the account from disabled to
enabled. (The account appears in the original OU.)
3. Use the bulk reset features in the Windows Server 2003 and later version of Active
Directory Users and Computers to perform bulk resets on the password must
change at next logon policy setting, on the home directory, on the profile path,
and on group membership for the deleted account as required. You can also use a
programmatic equivalent of these features.
4. If Microsoft Exchange 2000 or later was used, repair the Exchange mailbox for the
deleted user.
5. If Exchange 2000 or later was used, reassociate the deleted user with the Exchange
mailbox.
6. Verify that the recovered user can log on and access local directories, shared
directories, and files.

You can automate some or all of these recovery steps by using the following methods:

Write a script that automates the manual recovery steps that are listed in step 1.
When you write such a script, consider scoping the deleted object by date, time,
 and last known parent container, and then automating the reanimation of the
deleted object. To automate the reanimation, change the isDeleted attribute from
TRUE to FALSE, and change the relative distinguished name to the value that is
defined either in the lastKnownParent attribute or in a new OU or common name
(CN) container that is specified by the administrator. (The relative distinguished
name is also known as the RDN.)
Obtain a non-Microsoft program that supports the reanimation of deleted objects
on Windows Server 2003 and later domain controllers. One such utility is
AdRestore. AdRestore uses the Windows Server 2003 and later undelete primitives
to undelete objects individually. Aelita Software Corporation and Commvault
Systems also offer products that support undelete functionality on Windows Server
2003 and later-based domain controllers.

To obtain AdRestore, see AdRestore v1.1.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft doesn't guarantee the
accuracy of this third-party contact information.

How to manually undelete objects in a deleted

object's container
To manually undelete objects in a deleted object's container, follow these steps:

1. Select Start, select Run, and then type ldp.exe.

ldp.exe is available:

On computers where the Domain Controller role has been installed.

On computers where Remote Server Administration Tools (RSAT) has been
installed.

2. Use the Connection menu in Ldp to perform the connect operations and the bind
operations to a Windows Server 2003 and later domain controller.

Specify domain administrator credentials during the bind operation.

3. On the Options menu, select Controls.

4. In the Load Predefined list, select Return Deleted Objects.

７ Note
 The 1.2.840.113556.1.4.417 control moves to the Active Controls window.

5. Under Control Type, select Server, and the select OK.

6. On the View menu, select Tree, type the distinguished name path of the deleted
objects container in the domain where the deletion occurred, and then select OK.

７ Note

The distinguished name path is also known as the DN path. For example, if
the deletion occurred in the contoso.com domain, the DN path would be the
following path:
cn=deleted Objects,dc=contoso,dc=com

7. In the left pane of the window, double-click the Deleted Object Container.

７ Note

As a search result of Idap query, only 1000 objects are returned by default. Fot
example, if more than 1000 objects exist in the Deleted Objects container, not
all objects appear in this container. If your target object doesn't appear, use
ntdsutil, and then set the maximum number by using maxpagesize to get the
search results .

8. Double-click the object that you want to undelete or reanimate.

9. Right-click the object that you want to reanimate, and then select Modify.

Change the value for the isDeleted attribute and the DN path in a single
Lightweight Directory Access Protocol (LDAP) modify operation. To configure the
Modify dialog, follow these steps:

a. In the Edit Entry Attribute box, type isDeleted. Leave the Value box blank.

b. Select the Delete option button, and then select Enter to make the first of two
entries in the Entry List dialog.

） Important

Don't select Run.

 c. In the Attribute box, type distinguishedName.

d. In the Values box, type the new DN path of the reanimated object.

For example, to reanimate the JohnDoe user account to the Mayberry OU, use
the following DN path: cn= JohnDoe,ou= Mayberry,dc= contoso,dc= com

７ Note

If you want to reanimate a deleted object to its original container, append

the value of the deleted object's lastKnownParent attribute to its CN value,
and then paste the full DN path in the Values box.

e. In the Operation box, select REPLACE.

f. Select ENTER.

g. Select the Synchronous check box.

h. Select the Extended check box.

i. Select RUN.

10. After you reanimate the objects, select Controls on the Options menu, select the
Check Out button to remove (1.2.840.113556.1.4.417) from the Active Controls
box list.

11. Reset user account passwords, profiles, home directories, and group memberships
for the deleted users.

When the object was deleted, all the attribute values except SID , ObjectGUID ,
LastKnownParent , and SAMAccountName were stripped.

12. Enable the reanimated account in Active Directory Users and Computers.

７ Note

The reanimated object has the same primary SID as it had before the deletion,
but the object must be added again to the same security groups to have the
same level of access to resources. The first release of Windows Server 2003
and later doesn't preserve the sIDHistory attribute on reanimated user
accounts, computer accounts, and security groups. Windows Server 2003 and
 later with Service Pack 1 does preserve the sIDHistory attribute on deleted
objects.

13. Remove Microsoft Exchange attributes and reconnect the user to the Exchange
mailbox.

７ Note

The reanimation of deleted objects is supported when the deletion occurs on

a Windows Server 2003 and later domain controller. The reanimation of
deleted objects isn't supported when the deletion occurs on a Windows 2000
domain controller that is subsequently upgraded to Windows Server 2003 and
later.

７ Note

If the deletion occurs on a Windows 2000 domain controller in the domain,

the lastParentOf attribute isn't populated on Windows Server 2003 and later
domain controllers.

How to determine when and where a deletion

occurred
When users are deleted because of a bulk deletion, you may want to learn where the
deletion originated. To do so, follow these steps:

1. To locate deleted security principals, follow steps 1 to 7 in the How to manually

undelete objects in a deleted object's container section. If a tree was deleted,
follow these steps to locate a parent container of the deleted object.

2. Copy the value of the objectGUID attribute to the Windows clipboard. You can
paste this value when you enter the Repadmin command in step 4.

3. At the command line, run the following command:

Console

repadmin /showmeta GUID=<objectGUID> <FQDN>

 For example, if the objectGUID of the deleted object or container is 791273b2-
eba7-4285-a117-aa804ea76e95 and the fully qualified domain name (FQDN) is
dc.contoso.com , run the following command:

Console

repadmin /showmeta GUID=791273b2-eba7-4285-a117-aa804ea76e95

dc.contoso.com

The syntax of this command must include the GUID of the deleted object or
container and the FQDN of the server that you want to source from.

4. In the Repadmin command output, find the originating date, time, and domain
controller for the isDeleted attribute. For example, information for the isDeleted
attribute appears in the fifth line of the following sample output:

ﾉ Expand table

Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute

134759 Default-First-Site- 134759 DateTime 1 objectClass

Name\NA-DC1

134760 Default-First-Site- 134760 DateTime 2 ou

Name\NA-DC1

134759 Default-First-Site- 134759 DateTime 1 instanceType

Name\NA-DC1

134759 Default-First-Site- 134759 DateTime 1 whenCreated

Name\NA-DC1

134760 Default-First-Site- 134760 DateTime 1 isDeleted

Name\NA-DC1

134759 Default-First-Site- 134759 DateTime 1 nTSecurityDescriptor

Name\NA-DC1

134760 Default-First-Site- 134760 DateTime 2 name

Name\NA-DC1

134760 Default-First-Site- 134760 DateTime 1 lastKnownParent

Name\NA-DC1

134760 Default-First-Site- 134760 DateTime 2 objectCategory

Name\NA-DC1
 5. If the name of the originating domain controller appears as a 32-character alpha-
numeric GUID, use the Ping command to resolve the GUID to the IP address and
the name of the domain controller that originated the deletion. The Ping
command uses the following syntax:

Console

ping -a <originating DC GUID>._msdomain controllers.<fully qualified

path for forest root domain>

７ Note

The -a option is case sensitive. Use the fully qualified domain name of the
forest root domain regardless of the domain that the originating domain
controller resides in.

For example, if the originating domain controller resided in any domain in the
Contoso.com forest and had a GUID of 644eb7e7-1566-4f29-a778-4b487637564b,

run the following command:

Console

ping -a 644eb7e7-1566-4f29-a778-4b487637564b._msdomain
controllers.contoso.com

The output returned by this command is similar to the following one:

Console

Pinging na-dc1.contoso.com [65.53.65.101] with 32 bytes of data:

Reply from 65.53.65.101: bytes=32 time<1ms TTL=128

Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128

How to minimize the impact of bulk deletions

in the future
The keys to minimize the impact of the bulk deletion of users, computers, and security
groups are:
 Make sure that you have up-to-date system state backups.
Tightly control access to privileged user accounts.
Tightly control what those accounts can do.
Practice recovery from bulk deletions.

System state changes occur every day. These changes may include:

Password resets on user accounts and computer accounts

Group membership changes
Other attribute changes on user accounts, computer accounts, and security groups.

If your hardware or software fails, or your site experiences another disaster, you'll want
to restore the backups that were made after each significant set of changes in each
Active Directory domain and site in the forest. If you don't maintain current backups,
you may lose data, or may have to roll back restored objects.

Microsoft recommends that you take the following steps to prevent bulk deletions:

1. Don't share the password for the built-in administrator accounts, or permit
common administrative user accounts to be shared. If the password for the built-in
administrator account is known, change the password, and define an internal
process that discourages its use. Audit events for shared user accounts make it
impossible to determine the identity of the user who is making changes in Active
Directory. Therefore, the use of shared user accounts must be discouraged.

2. It's rare that user accounts, computer accounts, and security groups are
intentionally deleted. It's especially true of tree deletions. Disassociate the ability of
service and delegated administrators to delete these objects from the ability to
create and manage user accounts, computer accounts, security groups, OU
containers, and their attributes. Grant only the most privileged user accounts or
security groups the right to perform tree deletes. These privileged user accounts
may include enterprise administrators.

3. Grant delegated administrators access only to the class of object that those
administrators are permitted to manage. For example, a help desk administrator's
primary job is to modify properties on user accounts. He doesn't have permissions
to create and delete computer accounts, security groups, or OU containers. This
restriction also applies to delete permissions for the administrators of other
specific object classes.

4. Experiment with audit settings to track delete operations in a lab domain. After
you're comfortable with the results, apply your best solution to the production
domain.
5. Wholesale access-control and audit changes on containers that host tens of
thousands of objects can make the Active Directory database grow significantly,
especially in Windows 2000 domains. Use a test domain that mirrors the
production domain to evaluate potential changes to free disk space. Check the
hard disk drive volumes that host the Ntds.dit files and the log files of domain
controllers in the production domain for free disk space. Avoid setting access-
control and audit changes on the domain network controller head. Making these
changes would needlessly apply to all the objects of all the classes in all the
containers in the partition. For example, avoid making changes to Domain Name
System (DNS) and distributed link tracking (DLT) record registration in the
CN=SYSTEM folder of the domain partition.

6. Use the best-practice OU structure to separate user accounts, computer accounts,

security groups, and service accounts, in their own organizational unit. When you
use this structure, you can apply discretionary access control lists (DACLs) to
objects of a single class for delegated administration. And you make it possible for
objects to be restored according to object class if they have to be restored. The
best-practice OU structure is discussed in the Creating an Organizational Unit
Design section of the following article:
Best Practice Active Directory Design for Managing Windows Networks

7. Test bulk deletions in a lab environment that mirrors your production domain.
Choose the recovery method that makes sense to you, and then customize it to
your organization. You may want to identify:

The names of the domain controllers in each domain that is regularly backed
up
Where backup images are stored
Ideally, these images are stored on an extra hard disk that's local to a global
catalog in each domain in the forest.
Which members of the help desk organization to contact
The best way to make that contact

8. Most of the bulk deletions of user accounts, of computer accounts, and of security
groups that Microsoft sees are accidental. Discuss this scenario with your IT staff,
and develop an internal action plan. Focus on early detection. And return
functionality to your domain users and business as quickly as possible. You can
also take steps to prevent accidental bulk deletions from occurring by editing the
access control lists (ACLs) of organizational units.

For more information about how to use Windows interface tools to prevent
accidental bulk deletions, see Guarding Against Accidental Bulk Deletions in Active
 Directory.

Tools and scripts that may help you recover

from bulk deletions
The Groupadd.exe command-line utility reads the memberOf attribute on a collection of
users in an OU and builds a .ldf file that adds each restored user account to the security
groups in each domain in the forest.

Groupadd.exe automatically discovers the domains and security groups that deleted
users were members of and adds them back to those groups. This process is explained
in more detail in step 11 of method 1.

Groupadd.exe runs on Windows Server 2003 and later domain controllers.

Groupadd.exe uses the following syntax:

Console

groupadd / after_restore ldf_file [/ before_restore ldf_file ]

Here, ldf_file represents the name of the .ldf file to be used with the previous
argument, after_restore represents the user file data source, and before_restore
represents the user data from the production environment. (The user file data source is
the good user data.)

To obtain Groupadd.exe, contact Microsoft Product Support Services.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

References
For more information on how to use the AD Recycle Bin feature included in Windows
Server 2008 R2, see Active Directory Recycle Bin Step-by-Step Guide.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

No logon servers are available error
after cloning domain controller
Article • 02/19/2024

This article provides a solution to an error that occurs after you clone a new VDC, and
try to sign in interactively.

Applies to: Windows Server 2016, Windows Server 2019

Original KB number: 2742908

Symptoms
You use the Virtualized Domain Controller (VDC) cloning feature introduced in Windows
Server 2012. After you clone a new VDC, you try to sign in interactively. However, you
receive the following error:

There are currently no logon servers are available to service the logon request

Cause
The cloning process failed, and the server has started in Directory Services Repair Mode
(DSRM). There's no visual indication that the domain controller has started in DSRM on
the Ctrl+Alt+Delete sign-in page of Windows Server.

Resolution
1. Select the Left Arrow key, or press the Esc key.
2. Select Other User.
3. Type the user name as follows: .\administrator
4. Provide the DSRM user password that is currently set on the source domain
controller and that was used to clone this computer. This password was specified
during the original promotion. Notice that this password might have been
changed later by using NTDSUTIL.EXE.
5. When you sign in, the server will display SAFE MODE in all four corners of the
screen. Resolve the issues that prevented cloning, remove the DSRM boot flag, and
then try to clone the domain controller again

More information
This visual behavior and the error aren't specific to cloning. This behavior and error are
specific only to DSRM. DSRM is intentionally invoked as part of the cloning process to
safeguard the network and domain from duplicated domain controllers.

Directory Services Repair Mode was called Directory Services Restore Mode in previous
Windows operating systems.

For more information about how to configure and troubleshoot VDC together with
details and step-by-step guidance, see Virtualized Domain Controller Technical
Reference (Level 300).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Perform offline defragmentation of the
Active Directory database
Article • 02/19/2024

This article describes how to perform offline defragmentation of the Active Directory
database.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 232122

Summary
Active Directory automatically performs online defragmentation of the database at
certain intervals as part of the Garbage Collection process. (By default, this occurs every
12 hours.) Online defragmentation does not reduce the size of the database file
(Ntds.dit) but instead optimizes data storage in the database and reclaims space in the
directory for new objects.

Performing an offline defragmentation creates a new version of the database file

without internal fragmentation. It also re-creates all indexes. Depending on how
fragmented the original database file was, the new file may be much smaller.

Perform offline defragmentation of Active

Directory database
To perform offline defragmentation of the Active Directory database, follow these steps:

1. Back up Active Directory. Windows Server Backup natively supports backing up

Active Directory while online. This occurs automatically when you select the option
to back up everything on the computer in the Backup Wizard, or independently by
selecting to back up the System State in the wizard.

2. Take one of the following actions:

Stop the Active Directory Domain Services or LDS instance.

Start msconfig, and go to the boot pane. Select the OS installation that you
want to configure. Select Safe Boot in the Boot options section, and also
select the Active Directory repair item. After you click OK, the tool asks you
to restart. Restart the computer.
3. Log on to the administrator account by using the password that is defined for the
local administrator account in the Directory Service Restore Mode SAM.

4. Open a Command Prompt window.

5. NTDSUTIL uses the TEMP and TMP environment variables to create a temporary
database during defragmentation. If the free space on your standard volume used
is less than the size of the compacted database, you receive the following error:

file maintenance: compact to d:\compactDB

Initiating DEFRAGMENTATION mode...
Source Database: D:\windows\NTDS\ntds.dit
Target Database: d:\compactDB\ntds.dit

Defragmentation Status (% complete)

0 10 20 30 40 50 60 70 80 90 100

|----|----|----|----|----|----|----|----|----|----|

..........................Operation terminated with error -1808( JET_errDiskFull, No space

left on disk).

In this case, set the environment variables TMP and TEMP to a volume that has
enough free space for the task. For example, use the following settings:

Console

Md d:\temp
Set tmp=d:\temp
Set temp=d:\temp

７ Note

This problem can also occur during an integrity check of the database.

6. Run NTDSUTIL.

7. Type activate instance ntds to select the Active Directory database instance. Use
the LDS instance name if you want to compact an LDS database.

8. Type files, and then press Enter.

 9. Type info, and then press Enter. This displays current information about the path
and size of the Active Directory database and its log files. Note the path.

10. Establish a location that has sufficient drive space for the compacted database to
be stored.

11. Type compact to <drive>:\<directory> , and then press Enter. In this command, the
placeholders <drive> and <directory> represent the path of the location that you
established in the previous step.

７ Note

You must specify a directory path. If the path contains any spaces, the whole
path must be enclosed in quotation marks. For example, type compact to
"c:\new folder".

12. A new database that is named Ntds.dit or AdamNtds.dit is created in the path that
you specified.

13. Type quit, and then press Enter. Type quit again to return to the command prompt.

14. If defragmentation succeeds without errors, follow the Ntdsutil.exe on-screen

instructions. Delete all the log files in the log directory by typing the following
command del drive :\ pathToLogFiles \*.log .

Copy the new Ntds.dit or AdamNtds.dit file over the old database file in the
current database path that you noted in step 5.

７ Note

You do not have delete the Edb.chk file.

15. If you stopped Active Directory Domain Services or LDS instance, you can restart it
now.

16. If you are working in the Active Directory Restore mode, start msconfig and go to
the boot pane. Select the operating system installation that you want to configure.
Click to clear Safe Boot in the Boot options section. When you click OK, the tool
asks you to restart. Restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to relocate a SYSVOL tree that uses
FRS for replication
Article • 02/19/2024

This article describes two options for relocating the system volume (SYSVOL) tree on
your domain controller.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 842162

Summary
The SYSVOL is a collection of folders, file system reparse points, and Group Policy
settings that are replicated by the File Replication Service (FRS). Replication distributes a
consistent copy of Group Policy settings and scripts among domain controllers in a
domain. Member computers and domain controllers access the contents of the SYSVOL
tree through two shared folders, Sysvol and Netlogon.

This article describes how to move the SYSVOL tree and its shares to a different logical
or physical drive letter.

This section discusses how to move the SYSVOL tree from the C:\Winnt\Sysvol folder to
the X:\Winnt\Sysvol folder. In this example, the domain controller is named DC1, and the
domain name is CONTOSO.COM .

Use the Active Directory Installation Wizard to

demote and to repromote the domain
controller
1. Confirm that inbound and outbound replication is occurring for the Active
Directory directory service and for the SYSVOL tree.

2. Use the Active Directory Installation Wizard to do a network-based demotion of

the DC1 domain controller. Restart DC1 immediately after the demotion.

3. Before you repromote DC1, wait for the following events to occur:

All domain controllers in the forest must inbound replicate the removal of the
demoted domain controller's NTDS file system settings object. This object is
 located in the configuration partition. The NTDS settings object is the parent
of Active Directory connection objects that are visible in the Active Directory
Sites and Services snap-in.

All global catalog domain controllers in the forest must inbound replicate the
read-only copy of DC1's domain partition.

4. Use the Active Directory Installation Wizard to specify a new drive and path on an
NTFS-formatted partition. Demotion and repromotion of a domain controller is a
simple and supported option for relocating the SYSVOL tree and its shares if the
following conditions are true:

A small-to-medium number of objects exist in Active Directory.

Local area network (LAN)-speed connectivity is available.
Additional domain controllers are available in the affected Active Directory
domain and Active Directory site.

However, network-based Active Directory Installation Wizard promotions in domains

with multi-gigabyte Active Directory databases may take 2-7 days if network
connectivity is slow.

To avoid delays when you promote replica domain controllers that are running Windows
Server 2003 or later, you can do installations from media-based promotions, where the
bulk of Active Directory is sourced from a locally restored system state backup.

To estimate the required time for a network-based promotion, compare the start and
end times for a previous promotion that was comparable in scope. These times are
available in the %Systemroot%\Debug\Dcpromo.log file.

Manually relocate an existing SYSVOL tree to a

new location
In the life cycle of a domain controller that is using the File Replication Service (FRS), you
may have to relocate the SYSVOL tree to a different logical or physical drive. You may
relocate the SYSVOL tree to enhance system performance or to obtain more free disk
space for the SYSVOL tree or for the FRS staging folder.

For more information about changing the FRS staging folder to a location that is
independent of the SYSVOL tree, see How to reset the File Replication service staging
folder to a different logical drive.

To move a SYSVOL tree to a new drive, use one of the following options:
 Do a network-based Active Directory Installation Wizard (Dcpromo.exe) demotion.
Specify a new drive and path for the SYSVOL tree during promotion.

Modify the registry and manually move the SYSVOL tree to a new drive.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To manually move the SYSVOL tree, move the SYSVOL tree from its drive and path to a
new destination drive and path by modifying several registry keys and by resetting
reparse points in the file system. To do this task, follow these steps:

1. Prepare your domain controller. To do this task, follow these steps:

a. Confirm that inbound and outbound Active Directory replication is occurring on

the domain controller.

b. Confirm that inbound and outbound FRS replication of the SYSVOL replica set is
occurring on the domain controller.

c. Turn off antivirus programs or other services that create locks on files or on
folders that reside in the SYSVOL tree.

d. Back up the system state of the domain controller. Back up the file system part
of the SYSVOL tree on the domain controller so that you can return the
computer to its current configuration if you experience problems with the
relocation process.

e. Stop the FRS.

2. Use Windows Explorer or an equivalent program to copy the original SYSVOL

domain tree to the Clipboard.

For example, if the SYSVOL domain tree is located in the C:\Winnt\Sysvol folder,
click to select this folder, click Edit on the menu bar, and then click Copy.

3. Use Windows Explorer or an equivalent program to paste the contents of the

Clipboard in the new path.
 For example, to move the SYSVOL tree to the X:\Winnt\Sysvol folder, click to
select this folder, click Edit, and then click Paste.

The parent folder for the moved SYSVOL tree may be modified. However, we
recommend that you maintain the same relative path for the moved SYSVOL tree.
For example, if the SYSVOL tree was originally located in the C:\Winnt\Sysvol
folder and you want to moved the SYSVOL tree on logical drive X, create a
X:\Winn t folder, and then paste the SYSVOL tree in that folder.

4. Use the Ldp.exe or ADSIedit.msc editors to modify the value of the FRSRootPath
attribute in Active Directory. The FRSRootPath attribute must reflect the new
replica set root drive and the folder that you specified in step 3. In this example,
you would modify the FRSRootPath attribute as follows:

DN Path: cn=Domain System Volume (SYSVOL share),CN=NTFRS

Subscriptions,CN=DC1,OU=Domain Controller,DC=CONTOSO.COM

FRSRootPath Value: X:\Winnt\Sysvol\Domain

5. Use the Ldp.exe or ADSIedit.msc editors to modify the value for the
FRSStagingPath attribute. This attribute must reflect the new staging path,
including the new drive and folder that you selected in step 3.

DN path: cn=Domain System Volume (SYSVOL share),CN=NTFRS

Subscriptions,CN=DC1,OU=Domain Controller,DC=CONTOSO.COM

FRSStagingPath Value: X:\Winnt\Sysvol\Staging\Domain

6. Modify the registry to reflect the new staging drive and folder. To do this task,
follow these steps.
a. Click Start, click Run, type regedt32, and then click OK.
b. Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

c. Right-click the SYSVOL value, and then click Modify. Type a new path for the
SYSVOL replica set root. For example, type X:\Winnt\sysvol\sysvol .

7. Configure FRS to do a non-authoritative restore of the SYSVOL replica set. To do

this task, follow these steps:

a. Locate and then select the following registry subkey:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Back

up/Restore\Process at Startup

b. Right-click the BurFlags value, and then select Modify. Set the value to D2
hexadecimal if there are other domain controllers in the same domain. Set the
 BurFlags value to D4 hexadecimal if only one domain controller exists in the
domain.

） Important

Do not restart FRS now.

７ Note

If the domain controller hosts any FRS-replicated DFS roots or links, you may
want to set the replica set-specific BurFlags registry key to prevent a
temporary service outage and re-replication of data in FRS-replicated DFS
roots or links.

For more information, see Use the BurFlags registry key to reinitialize File
Replication Service.

8. Apply default permissions to the new path of the SYSVOL tree. To do this task,
copy the following text, and then paste it in a Notepad file:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Profile Description]
Description=default perms for sysvol
[File Security]
;"%SystemRoot%\SYSVOL",0,"D:AR(A;OICI;FA;;;BA)"
; -------------------------------------------------------------------------------------
--------
;Sysvol. THIS ENVIRONMENT VARIABLE MUST BE SET!!!!!!!!!!!!!!!!!!!!!!!!!
; -------------------------------------------------------------------------------------
--------
"%Sysvol%",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)(A;CIOI;GA;;;BA)
(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"
"%Sysvol%\domain\policies",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)
(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)(A;CIOI;GRGWGXSD;;;PA)"
 9. Use the following parameters to save the contents of the Notepad file that you
created in step 8:

File name: %systemroot%\security\templates\sysvol.inf

Save as type: All Files
Encoding: Unicode

７ Note

The SYSVOL environment variable must be set to point to the new location.
Otherwise, the Secedit command does not run successfully.

10. Import the SYSVOL security template. To do this operation, select Start, select Run,
type cmd, and then select OK. Type the following, and then press ENTER:

Console

secedit /configure /cfg %systemroot%\security\templates\sysvol.inf /db

%systemroot%\security\templates\sysvol.db /overwrite

11. Use the Linkd command to update the reparse points in the file system to reflect
the new path of the SYSVOL tree. For example, if your domain controller is in the
CONTOSO.COM domain, and the SYSVOL tree is located in the X:\Windows\Sysvol

folder, type the following commands at the command prompt on your domain
controller. Press ENTER after each command.

Console

linkd X:\Winnt\Sysvol\Sysvol\CONTOSO.COM X:\Winnt\Sysvol\Domain

linkd X:\Winnt\Sysvol\Staging areas\CONTOSO.COM
X:\Winnt\Sysvol\Staging\Domain

７ Note

Make sure that the SYSVOL directory tree is created before you run the Linkd
command. The command fails if there is data in the CONTOSO.COM directory
or subdirectories.

12. Restart FRS.

13. Look for events in the FRS event log that indicate that the replica set is joined and
that the SYSVOL folder is changed.
 14. On the domain controller, use the net logon command or the net view command
to verify that the domain controller has shared the Netlogon and Sysvol folders. If
the shared folders don't exist, follow these steps:

a. If the value for the

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\S

ysvolready registry subkey is 1, restart the Netlogon service. If this subkey value

is 0, go to step c.

b. Look for the shared folders again. If the folders are still not available, type the
nltest /dbflag:2080FFFF command at a command prompt, and then press

ENTER:

Look for errors in the %Systemroot%\Debug\Netlogon.log file.

c. If the value for the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\Sy
svolready registry subkey is 0, don't set the registry value to 1. Review the FRS

debug logs in the %Systemroot%\Debug folder to verify that inbound and

outbound FRS replication is occurring.

15. Restart any services that you stopped in step 1c.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

RODC replicates passwords when it's
granted incorrect permissions in
Windows Server
Article • 02/19/2024

This article addresses an issue in which RODC replicates passwords when it's granted
incorrect permissions in Windows Server.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 4050867

Symptom
Normally, Read Only Domain Controllers (RODCs) only replicate user passwords for user
accounts that are a member of the Allowed RODC Password Replication Group or are
listed in the RODC account's msDS-RevealOnDemandGroup attribute.

However, for some user accounts that are not members of Allowed RODC Password
Replication Group or are not listed in the RODC account's msDS-
RevealOnDemandGroup attribute, you may find that passwords for those accounts that
are authenticated by the RODC may be cached by the RODC.

For example, when you compare the output of the Advanced Password Replication
Policy property by using Active Directory Users and Computers and the output of
repadmin /prp view RODC_name reveal , the entries listed differ between the two.

Cause
This problem is caused by incorrect permission configuration.

By default, the Enterprise Domain Controllers group that contains only writeable DCs
has the permission Replicating Directory Changes All on the domain partition. For
example, on "DC=contoso,DC=com" in Active Directory.

However, when the issue occurs, the problem RODC also has the Replicating Directory
Changes All permission on the domain because it was granted by an administrator
either to the Enterprise Read-only Domain Controllers group or to the RODC object
directly or indirectly via some other group membership.
Normally, RODCs will only replicate user passwords if the user accounts are a member of
the Allowed RODC Password Replication Group or are listed in the RODC account's
msDS-RevealOnDemandGroup attribute.

With the Replicating Directory Changes All permission, all user attributes, including
passwords, are replicated from the source DC to the RODC as if the RODC were a
normal Read Write DC (RWDC).

Resolution
To resolve this issue, change the Replicating Directory Changes All permission that is
granted to the Enterprise Read-only Domain Controllers object to Replicating Directory
Changes.

More information
Follow these steps to help validate the permissions and determine where the wrong
permissions are coming from.

Step 1
Use LDP to view the "control access" permissions on the domain. To do this, following
these steps:

1. Run the LDP.exe command on a domain controller.

2. Connect to the tree (for example, DC=contoso,DC=com).
3. Right-click the DC=contoso,DC=com node, select Advanced, and then select
Security Descriptor.
4. Choose the option Text dump for a text view of the permissions or leave it
unchecked to get a GUI security editor.
5. Verify the permissions to make sure that the Enterprise Read-only Domain
Controllers group only has permission Replicating Directory Changes.

Step 2
Verify the group memberships of the RODC to determine whether Replicating Directory
Changes All is being granted through another group.

To obtain the true membership of the RODC, you can use a query for the TokenGroups
attribute to retrieve the effective group list of the user by using the LDP tool.
Make sure that you select Base scope and add the required attribute. When you are
scoping the search on an individual user, you get the list for that user. If the user is in
many groups, you must extend the amount of data that LDP prints into the window on
the right, select Options\General from the menu, and adjust the Chars per field to a
higher value:

Step 3
On Windows Server 2008 R2, Windows 7, Windows Server 2008, or Windows Vista,
check whether you encounter the issue that is outlined in the following article:
The "Active Directory Users and Computers" MMC snap-in does not list all the accounts
that have passwords cached on the RODC in Windows
Step 4
Confirm the consistency of the RODC's computer account properties on all domain
controllers in the domain.

One method is to use repadmin to export the replication metadata of the RODC's
computer account from all domain controllers. To do this, use the following command:

Console

repadmin /showobjmeta *<dn of RODC account>' > rodc_meta.txt

Step 5
Similarly to step 4, confirm the consistency of the Allowed RODC Password Replication
Group and any other group configured on the msDS-RevealOnDemandGroup attribute
to see if the incorrectly cached user passwords can be explained by inconsistent group
membership on different DCs that may be caused by a replication problem.

Step 6
Verify that users who have their passwords cached by the RODC aren't accidentally a
member of a group that is configured to have their passwords cached.

７ Note

The MMC will gather the password replication policy information from any domain
controller (even the RODC itself), while the repadmin /prp command will always
interrogate a read-write domain controller.

If there are any replication inconsistencies between the RODC and an RW DC, this may
explain the difference in output of these two utilities/methods.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Syskey.exe utility is no longer supported
in Windows 10, Windows Server 2016,
and later versions
Article • 02/19/2024

Windows 10, version 1709, Windows Server, version 2004 and later versions of Windows
no longer support the syskey.exe utility.

Applies to: Windows 10 - all editions, Windows Server 2019, Windows Server 2016
Original KB number: 4025993

Changes detail
The following changes are made:

The syskey.exe utility is no longer included in Windows.

Windows will never prompt for a syskey password during startup.
Windows will no longer support installing an Active Directory domain controller by
using Install-From-Media (IFM) that was externally encrypted by the syskey.exe
utility.

If an operating system (OS) was externally encrypted by the syskey.exe utility, you can't
upgrade it to Windows 10 version 1709, Windows Server version 2004, or a later version
of Windows.

Workaround
If you want to use boot-time OS security, we recommend that you use BitLocker or
similar technologies instead of the syskey.exe utility.

If you use Active Directory IFM media to install replica Active Directory domain
controllers, we recommend that you use BitLocker or other file encryption utilities to
protect all IFM media.

To upgrade an OS that's externally encrypted by the syskey.exe utility to Windows 10

RS3 or Windows Server 2016 RS3, the OS should be configured not to use an external
syskey password. For more information, see step 5 in How to use the SysKey utility to
secure the Windows Security Accounts Manager database .
More information
Syskey is a Windows internal root encryption key that's used to encrypt other sensitive
OS state data, such as user account password hashes. The SysKey utility can be used to
add an extra layer of protection, by encrypting the syskey to use an external password.
In this state, the OS blocks the boot process and prompt users for the password (either
interactively or by reading from a floppy disk).

Unfortunately, the syskey encryption key and the use of syskey.exe are no longer
considered secure. Syskey is based on weak cryptography that can easily be broken in
modern times. The data that's protected by syskey is limited and doesn't cover all files
or data on the OS volume. The syskey.exe utility has also been known to be used by
hackers as part of ransomware scams.

Active Directory previously supported the use of an externally encrypted syskey for IFM
media. When a domain controller is installed by using IFM media, the external syskey
password had to be provided as well. Unfortunately, this protection suffers from the
same security flaws.

Reference
The syskey.exe utility and its underlying support in the Windows OS was first introduced
in Windows 2000 and backported to Windows NT 4.0. For more information, see How to
use the SysKey utility to help secure the Windows Security Accounts Manager
database .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 13552 and 13555 are logged in
the File Replication Service log on a
Windows-based domain controller
Article • 02/19/2024

This article helps resolve an issue in which the SYSVOL folder isn't replicated between
domain controllers that are running Windows Server 2012 R2, Windows Server 2012,
Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2986364

Symptoms
This issue can occur in one of the following conditions on a domain controller that is
running Windows Server:

You change the configuration of system devices or, the configuration of system
devices fails.
Corruption occurs in File Replication Service (FRS) database.

Event information

The two events resemble the following:

Event 13555:
File Replication Service is in an error state

Event 13552:
The File Replication Service is unable to add this computer to the following replica
set: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

These event logs indicate that the SYSVOL folder isn't replicated between domain
controllers. Therefore, this issue causes inconsistent Group Policy settings and the
incorrect policy result is set on each client computer.

Cause
This issue occurs because NTFS detects a firmware update as a configuration change in
disks and then changes the journal ID. Therefore, a file ID for data in the FRS database
doesn't match the file ID for the data in the update sequence number (USN) journal
database.

Workaround

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

To work around this issue, on domain controllers that the events are logged follow these
steps:

1. Take full or system state backup for each domain controller.

2. Stop the FRS. To do this, at the command prompt on each domain controller, type
the following command, and then press ENTER: net stop ntfrs

７ Note

At this point, select a reference domain controller that can be based on

connectivity and physical server resources. This domain controller will be the
"reference domain controller" in all subsequent steps.

3. Delete files in the following three folders to initialize the FRS on the reference
domain controller.
Don't delete the three folders. Delete subfolders and files in these three folders:

%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domainIf these folders and files aren't shown,
perform the additional steps to show the hidden files or folders.

4. Force synchronization of FRS on the reference domain controller. To do this, follow

these steps:
a. Open Registry Editor and locate to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backu

p/Restore\Process at Startup
 b. Right-click the BurFlags entry, and then click Modify.
c. In the Value data box, type D4, and then click OK.
d. Exit Registry Editor.

5. At the command prompt on the reference domain controller, run the following
command to restart the FRS: net start ntfrs

７ Note

Step 6 through step 10 should be done only on other domain controller.

6. Download and install the PsTools tool on other domain controllers. This tool
contains the PsExec command-line tools that can be used to delete folders under
the SYSVOL folder.

7. Delete files in the three folders below to initialize the FRS on other domain
controllers.
Don't delete the three folders. Delete subfolders and files in the following three
folders:

%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domainIf these folders and files aren't shown,
perform the additional steps to show the hidden files or folders.

8. Delete the following folders under the "%systemroot%\sysvol\domain" path:

%systemroot%\sysvol\domain\policies
%systemroot%\sysvol\domain\scripts
%systemroot%\sysvol\domain\policies_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\scripts_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\NtFrs_PreExisting__See_Evntlog

７ Note

"xxxxxxx" is a placeholder that represents alphanumeric characters. Skip this

step if there are not such folders and files.

Additionally, if the folders and files can't be deleted, follow these steps to delete
them by using the PsExec tool.

Steps to delete folders and files by using the PsExec tool:

 a. Run command prompt with Administrative rights.
b. Change current directory to the drive where the PsTools tool setup files are (for
example, run cd c:\PsTools).
c. Run the following command: Psexec.exe -i -s cmd .
d. At new command prompt, type rd /s to delete the following files and folders
under the SYSVOL folder (for example, run rd
%systemroot%\sysvol\domain\policies /s):

%systemroot%\sysvol\domain\policies
%systemroot%\sysvol\domain\scripts
%systemroot%\sysvol\domain\policies_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\scripts_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\NtFrs_PreExisting__See_Evntlog

７ Note

"xxxxxxx" is a placeholder that represents alphanumeric characters. Skip this

step if there are not such folders and files.

9. Force synchronization of FRS on other domain controllers. To do this, follow these

steps:
a. Open Registry Editor and locate to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backu

p/Restore\Process at Startup

b. Right-click the BurFlags entry, and then click Modify.

c. In the Value data box, type D2, and then click OK.
d. Exit Registry Editor.

10. At command prompt, run the following command to restart FRS on other domain
controllers: net start ntfrs

11. Confirm the replication.

"Error" or "Warning" log entries will now not be recorded in event log. If
replication succeeded, event ID 13516 is recorded.
Check consistency by comparing files and folders in the SYSVOL folders
between all domain controllers.

12. Restart the FRS on the reference domain controller by running the following
command: net stop ntfrs && net start ntfrs
 ７ Note

Domain controller that has "BurFlags = D4" works as reference domain

controller until service is restarted. The value of the BurFlags entry is reset by
restarting FRS.
For domain controllers that have "BurFlags = D2," the value of the BurFlags
entry is also reset automatically by restarting FRS.

After you complete all steps, check the FRS event log. Event IDs 13553, 13554 and 13516
are recorded within few minutes. These logs indicate SYSVOL replication finishes
correctly.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
Show hidden files and folders in Windows Explorer:

1. In Windows Explorer, on the Tools menu, click Folder Options.

2. From the Display tab, enable the Show hidden files and folders option.

７ Note

In Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008
R2, enable the Show hidden files, folders, and drives option in the View tab.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive an "access is denied" error
message on a domain controller when
you try to replicate the Active Directory
directory service
Article • 02/19/2024

This article helps to fix the error "access is denied" on a domain controller when you try
to replicate the Active Directory directory service.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 895085

） Important

This article contains information about modifying the registry. Before you modify
the registry, make sure to back it up and make sure that you understand how to
restore the registry if a problem occurs. For information about how to back up,
restore, and edit the registry, click the following article number to view the article in
the Microsoft Knowledge Base: 256986 Description of the Microsoft Windows
Registry

Symptoms
When you try to replicate the Active Directory directory service to a domain controller
that is running Microsoft Windows Server 2003 with Service Pack 1 (SP1) or an x64-
based version of Microsoft Windows Server 2003, you receive the following error
message on the destination domain controller:

access is denied

Cause
This problem occurs when the value of the RestrictRemoteClients registry entry is 2.

Windows Server 2003 SP1 and x64-based versions of Windows Server 2003 read remote
procedure call (RPC) settings from this entry. If the entry has a value of 2, RPC traffic
must be authenticated. Therefore, Active Directory replication does not succeed. Other
RPC services on the domain controller may also be affected.

Resolution

２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.

To resolve this problem, enable port 135 on Windows Firewall, and then use one of the
following methods:

Set the value of the RestrictRemoteClients registry entry to 0 or 1.

Disable the Restrictions for Unauthenticated RPC Clients Group Policy object.

To do this, follow these steps.

７ Note

By default, port 135 is blocked in Windows Server 2003 SP1 and in x64-based
versions of Windows Server 2003.

1. Click Start, click Run, type firewall.cpl, and then click OK.

2. Click the Exceptions tab, and then click Add Port.

3. In the Name box, type a name for the port.

For example, type TCP 135.

4. In the Port number box, type 135.

5. Click TCP, and then click OK.

The new port appears on the Exceptions tab.

6. Click to select the check box next to the new port, and then click OK.

7. Click Start, click Run, type regedit, and then click OK.
 8. Use one of the following methods:

Set the value of the RestrictRemoteClients registry entry to 0 or 1. To do this, follow

these steps:

1. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc

2. In the right pane, click the RestrictRemoteClients entry.

７ Note

If this entry does not exist, follow these steps:

a. On the Edit menu, point to New, and then click DWORD Value.
b. Type RestrictRemoteClients , and then press ENTER.

3. On the Edit menu, click Modify.

4. In the Value data box, type 0 or 1, and then click OK.

5. Quit Registry Editor.

Use Group Policy Object Editor to disable the Restrictions for Unauthenticated RPC
Clients Group Policy object. To do this, follow these steps:

1. Click Start, click Run, type gpedit.msc, and then click OK.
2. In the console tree, double-click Computer Configuration, double-click
Administrative Templates, double-click System, and then click Remote
Procedure Call.
3. Double-click Restrictions for Unauthenticated RPC clients, click Disable, and
then click OK.
4. Quit Group Policy Object Editor.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
For additional information about the RestrictRemoteClients registry entry, visit the
following Microsoft Web site: RestrictRemoteClients registry key is enabled
Technical support for Windows x64 editions
Your hardware manufacturer provides technical support and assistance for Microsoft
Windows x64 editions. Your hardware manufacturer provides support because a
Windows x64 edition was included with your hardware. Your hardware manufacturer
might have customized the Windows x64 edition installation with unique components.
Unique components might include specific device drivers or might include optional
settings to maximize the performance of the hardware. Microsoft will provide
reasonable-effort assistance if you need technical help with your Windows x64 edition.
However, you might have to contact your manufacturer directly. Your manufacturer is
best qualified to support the software that your manufacturer installed on the hardware.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory communication fails on
multihomed domain controllers
Article • 02/19/2024

This article describes an issue in which Active Directory communication, including

replication fails intermittently.

Applies to: Windows 2000

Original KB number: 272294

Symptoms
In a Windows 2000 domain that has multihomed domain controllers, Active Directory
communication, including replication, may fail intermittently.

Cause
This issue can occur if one of the network adapters is attached to an external network
(such as the Internet) on the multihomed domain controller, and if Lightweight Directory
Access Protocol (LDAP) and Kerberos traffic between the internal and external networks
is partially or completely restricted because of a Proxy, ISA Server, NAT Server, or
another firewall device.

In this scenario, network adapters on the multihomed domain controllers are registering
both the inside and outside Internet Protocol (IP) addresses with the DNS server. DNS
name resolution lookup requests return records in a "round robin" fashion, alternating
the internal and external IP addresses. Replication operations require multiple lookup
requests of SRV records. In this case, half of the DNS lookup requests return an IP
address that can't be contacted, and the replication operation fails.

Resolution
To resolve this issue:

1. Disable registration on the outside network adapter on the multihomed domain

controller. To do so:
a. Click Start, click Settings, and then click Network and Dial-Up Connections.
b. Right-click the outside local area network (LAN) connection, and then click
Properties.
 c. Click TCP/IP, and then click Properties.
d. Click Advanced, and then click to clear the Register DNS for this connection
check box.

2. Disable the round robin functionality on the DNS server. To do so:

a. Click Start, click Settings, click Administrative Tools, and then click DNS.
b. Open the properties for the DNS server's name.
c. Click the Advanced tab, and then click to clear the Enable round robin check
box.

3. Remove the existing entries in DNS. To do so:

a. Browse to the following location: Under DNS\DNS Servername \Forward
Lookup Zones\Domain Name
b. Remove Host (A) record entries that refer to the domain controller's computer
name for the outside network adapter IP addresses.
c. Remove Host (A) record entries for the same name as the parent folder for the
network adapter IP addresses.

4. Start the DNS Management Console, right-click the server name, and then click
Properties.

5. Click the Interfaces tab, and then remove the external IP address so that DNS does
not listen on it.

6. Open a command prompt, type ipconfig /flushdns, press ENTER, type ipconfig
/registerdns, and then press ENTER.

7. Change the binding order of your network adapters so that the Internal adapter is
the first bound adapter. To do this, follow these steps:
a. Click Start, click Settings, and then click Network and Dial-Up Connections.
b. On the Advanced menu, click Advanced.
c. Verify that the internal network adapter is listed first in the Connections box.

Status
This behavior is by design.

More information
For more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
246804 How to enable or disable DNS updates in Windows 2000 and in Windows
Server 2003

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADWS service crashes after you
upgrade
Article • 02/19/2024

This article provides a resolution to an issue where Active Directory Web Services
(ADWS) service crashes after you upgrade.

Applies to: Windows Server 2012 R2

Original KB number: 3019069

Symptoms
After you perform an in-place upgrade of a Microsoft Windows Server 2008 R2 domain
controller to Windows Server 2012 R2, the Active Directory Web Services (ADWS) service
crashes upon start.

Cause
This is a known issue concerning the product.

Resolution
To resolve this issue, reinstall the Microsoft .NET Framework 4.5.2 package .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Active Directory database garbage
collection process and calculation of
allowed intervals
Article • 02/19/2024

This article describes the Active Directory database garbage collection process and
calculation of allowed intervals.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Original KB number: 198793

Summary
The Active Directory database incorporates a garbage collection process that runs
independently on each domain controller in the enterprise.

More information
Garbage collection is a housekeeping process that is designed to free space within the
Active Directory database. This process runs on every domain controller in the enterprise
with a default lifetime interval of 12 hours. You can change this interval by modifying the
garbageCollPeriod attribute in the enterprise-wide DS configuration object (NTDS).

The path of the object in the Contoso.com domain would resemble the following:
CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=CONTOSO,DC=COM

Use an Active Directory editing tool to set the garbageCollPeriod attribute. Supported
tools include Adsiedit.msc, Ldp.exe, and Active Directory Service Interfaces (ADSI)
scripts.

When an object is deleted, it is not removed from the Active Directory database. Instead,
the object is instead marked for deletion at a later date. This mark is then replicated to
other domain controllers. Therefore, the garbage collection process starts by removing
the remains of previously deleted objects from the database. These objects are known
as tombstones. Next, the garbage collection process deletes unnecessary log files.
Finally, the process starts a defragmentation thread to claim additional free space.
In addition, there are two methods to defragment the Active Directory database. One
method is an online defragmentation operation that runs as part of the garbage
collection process. The advantage of this method is that the server does not have to be
taken offline for the operation to run. However, this method does not reduce the size of
the Active Directory database file (Ntds.dit). The other method takes the server offline
and defragments the database by using the Ntdsutil.exe utility. This approach requires
that the database to start in repair mode. The advantage of this method is that the
database is resized and unused space is removed. Therefore, and the size of the Ntds.dit
file is reduced. To use this method, the domain controller must be taken offline.

Limits for garbageCollPeriod:

The minimum value is 1, and the maximum is 168 for one week. The default for the
value is 12 hours.

Minimum for Tombstone Lifetime:

The minimum for Tombstone Lifetime is 2 days for the purposes of the KCC stay of
execution calculation.

The AD database layer enforces an additional metric. TSL days must not be smaller than
three times the garbage collector interval. Based on the Default of 12 hours, TSL is a
minimum of 2 days. If GC interval is 20 hours, the TSL minimum is 3 days (must be
bigger than 60 hours). If the GC interval is 25 hours, you get beyond three days (with 75
hours) and the TSL minimum is 4 days.

The catch with the checks both DB layer and KCC perform is that if TSL is lower than the
allowed minimum, it does not revert to the minimum value of 2 or more days, but to the
default of 60 or 180 days.

） Important

In case TSL is corrected to the default because of a mismatch, the value for the
garbage collection interval is also set to the default of 12 hours.

Tombstone lifetime defaults

History
The default tombstone lifetime (TSL) in Windows Server 2003 was 60 days and was
proven to be too short. For example, a prestaged domain controller may be in transit for
longer than 60 days. An administrator may not resolve a replication failure or bring an
offline domain controller into operation until the TSL is exceeded. Windows Server 2003
Service Pack 1 (SP1) increased the TSL from 60 to 180 days in the following scenarios:

A Windows NT 4.0 domain controller is upgraded to Windows Server 2003 by

using Windows Server 2003 SP1 installation media to create a new forest.
A Windows Server 2003 SP1 computer creates a new forest.

Windows Server 2003 SP1 does not modify the value of TSL when either of the following
conditions is true:

A Windows 2000 domain is upgraded to Windows Server 2003 by using

installation media for Windows Server 2003 with SP1.
Windows Server 2003 SP1 is installed on a domain controller that is running the
original release version of Windows Server 2003.

Increasing the TSL for a domain to 180 days has the following benefits:

Backups that are used in data recovery scenarios have a longer useful life.
System state backups that are used for installation from media promotions have a
longer useful life.
Domain controllers can be offline longer. Prestaged computers approach TSL
expiration less frequently.
A domain controller can successfully return to the domain after a longer time
offline.
Knowledge of deleted objects is retained longer on the originating domain
controller.

The default setting in your forest will depend on the OS at the 'birth' of the forest and
the upgrade methods from there as above.

If you are unsure about the value of TSL used in your forest, we recommend to explicitly
set it, and also msDS-deletedObjectLifetime as needed.
Reference: The AD Recycle Bin: Understanding, Implementing, Best Practices, and
Troubleshooting

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you start your Windows-
based domain controller: Directory
Services cannot start
Article • 02/19/2024

This article explains how to recover from a corrupted Active Directory database or from
a similar problem that prevents your computer from starting in normal mode.

Applies to: Windows Server 2003

Original KB number: 258062

Summary
This article leads you through a series of steps that may help you diagnose the cause of
the Directory Services cannot start system error. These steps may include:

Verifying that the Active Directory directory service files exist.

Verifying that the file system permissions are correct.
Checking the integrity of the Active Directory database.
Performing a semantic database analysis.
Repairing the Active Directory database.
Removing and recreating the Active Directory database.

This article also tells you how to use Ntdsutil or Esentutl to perform a lossy repair of the
Active Directory database. Because a lossy repair deletes data and may introduce new
problems, only perform a lossy repair if it's the only available option.

Symptoms
When you start your domain controller, the screen may go blank, and you may receive
the following error message:

LSASS.EXE - System Error, security accounts manager initialization failed because of

the following error: Directory Services cannot start. Error status 0xc00002e1.

Please click OK to shutdown this system and reboot into directory services restore
mode, check the event log for more detailed information.

Additionally, the following event ID messages may appear in the event log:
 Event ID: 700
Description: "NTDS (260) Online defragmentation is beginning a pass on database
NTDS.DIT."
Event ID: 701
Description: "NTDS (268) Online defragmentation has completed a full pass on
database 'C:\WINNT\NTDS\ntds.dit'."
Event ID: 101
Description: "NTDS (260) the database engine stopped."
Event ID: 1004
Description: "The directory was shut down successfully."
Event ID: 1168
Description: "Error: 1032 (fffffbf8) has occurred. (internal ID 4042b). Please contact
Microsoft product support services for assistance."
Event ID: 1103
Description: "The windows directory services database could not be initialized and
returned error 1032. Unrecoverable error, the directory can't continue."

Cause
This problem occurs because one or more of the following conditions are true:

The NTFS file system permissions on the root of the drive are too restrictive.
The NTFS file system permissions on the NTDS folder are too restrictive.
The drive letter of the volume that contains the Active Directory database has
changed.
The Active Directory database (Ntds.dit) is corrupted.
The NTDS folder is compressed.

Resolution
To resolve this problem, follow these steps:

1. Restart the domain controller.

2. When the BIOS information appears, press F8.

3. Select Directory Services Restore Mode, and then press ENTER.

4. Log on by using the Directory Services Restore Mode password.

5. Click Start, select Run, type cmd in the Open box, and then click OK.
6. At the command prompt, type ntdsutil files info.

Output that is similar to the following appears:

Drive Information:

C:\ NTFS (Fixed Drive ) free(533.3 Mb) total(4.1 Gb)

DS Path Information:

Database : C:\WINDOWS\NTDS\ntds.dit - 10.1 Mb Backup dir :

C:\WINDOWS\NTDS\dsadata.bak Working dir: C:\WINDOWS\NTDS Log dir :
C:\WINDOWS\NTDS - 42.1 Mb total temp.edb - 2.1 Mb res2.log - 10.0 Mb
res1.log - 10.0 Mb edb00001.log - 10.0 Mb edb.log - 10.0 Mb

７ Note

The file locations that are included in this output are also found in the
following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

The following entries in this key contain the file locations:

Database Backup path

Database Log files path
DSA Working Directory

7. Verify that the files that are listed in the output in step 6 exist.

8. Verify that the folders in the Ntdsutil output have the correct permissions. The
correct permissions are specified in the following tables.

Windows Server 2003

ﾉ Expand table

Account Permissions Inheritance

System Full Control This folder, subfolders, and files

Administrators Full Control This folder, subfolders, and files

Creator Owner Full Control Subfolders and Files only

Local Service Create Folders / Append Data This folder and subfolders
 Windows 2000

ﾉ Expand table

Account Permissions Inheritance

Administrators Full Control This folder, subfolders, and files

System Full Control This folder, subfolders, and files

７ Note

Additionally, the System account requires Full Control permissions on the

following folders:

The root of the drive that contains the Ntds folder

The %WINDIR% folder

In Windows Server 2003, the default location of the %WINDIR% folder is

C:\WINDOWS. In Windows 2000, the default location of the %WINDIR% folder
is C:\WINNT.

9. Check the integrity of the Active Directory database. To do this, type ntdsutil files
integrity at the command prompt.

If the integrity check indicates no errors, restart the domain controller in normal
mode. If the integrity check doesn't finish without errors, continue to the following
steps.

10. Perform a semantic database analysis. To do this, type the following command at
the command prompt, including the quotation marks:

Console

ntdsutil "sem d a" go

11. If the semantic database analysis indicates no errors, continue to the following
steps. If the analysis reports any errors, type the following command at the
command prompt, including the quotation marks:

Console

ntdsutil "sem d a" "go f"

12. Follow the steps in the following Microsoft Knowledge Base article to perform an
offline defragmentation of the Active Directory database:

232122 Performing offline defragmentation of the Active Directory database

13. If the problem still exists after the offline defragmentation, and there are other
functional domain controllers in the same domain, remove Active Directory from
the server, and then reinstall Active Directory. To do this, follow the steps in the
"Workaround" section in the following Microsoft Knowledge Base article:

332199 Domain controllers do not demote gracefully when you use the Active
Directory Installation Wizard to force demotion in Windows Server 2003 and in
Windows 2000 Server

７ Note

If your domain controller is running Microsoft Small Business Server, you

cannot perform this step, because Small Business Server cannot be added to
an existing domain as an additional domain controller (replica). If you have a
system state backup that is newer than the tombstone lifetime, restore that
system state backup instead of removing Active Directory from the server. By
default, the tombstone lifetime is 60 days.

14. If no system state backup is available, and there are no other healthy domain
controllers in the domain, we recommend that you rebuild the domain by
removing Active Directory and then reinstalling Active Directory on the server,
creating a new domain. You can use the old domain name again or use a new
domain name. You can also rebuild the domain by reformatting and reinstalling
Windows on the server. However, removing Active Directory is quicker, and
effectively removes the corrupted Active Directory database.

If no system state backup is available, there are no other healthy domain

controllers in the domain, and you must have the domain controller working
immediately, perform a lossy repair by using either Ntdsutil or Esentutl.

７ Note

Microsoft doesn't support domain controllers after Ntdsutil or Esentutl is used

to recover from Active Directory database corruption. If you perform this kind
of repair, you must rebuild the domain controller for Active Directory to be in
a supported configuration. The repair command in Ntdsutil uses the Esentutl
utility to perform a lossy repair of the database. This kind of repair fixes
 corruption by deleting data from the database. Only use this kind of repair as
a last resort.

Although the domain controller may start and may appear to function correctly
after the repair, its state is unsupported because the data that is deleted from the
database can cause any number of problems that may not surface until later.
There's no way to determine what data was deleted when the database was
repaired. As soon as possible after the repair, you must rebuild the domain to
return Active Directory to a supported configuration. If you only use the offline
defragmentation or semantic database analysis methods that are referenced in this
article, you don't have to rebuild the domain controller afterward.

15. Before you perform a lossy repair, contact Microsoft Product Support Services to
confirm that you've reviewed all possible recovery options and to verify that the
database truly is in an unrecoverable state. For a complete list of Microsoft Product
Support Services phone numbers and information about support costs, visit the
following Microsoft Web site:

Contact Microsoft Support

On a Windows 2000 Server-based domain controller, use Ntdsutil to recover the

Active Directory database. To do this, type ntdsutil files repair at a command
prompt in Directory Service Restore Mode.

To perform a lossy repair of a Windows Server 2003-based domain controller, use

the Esentutl.exe tool to recover the Active Directory database. To do this, type
esentutl /p at a command prompt on the Windows Server 2003-based domain
controller.

16. After the repair operation is complete, rename the .log files in the NTDS folder by
using a different extension such as .bak, and try to start the domain controller in
normal mode.

17. If you can start the domain controller in normal mode after the repair, migrate
relevant Active Directory objects to a new forest as soon as possible. Because this
lossy repair method fixes corruption by deleting data, it can cause later problems
that are extremely difficult to troubleshoot. At the first opportunity after the repair,
you must rebuild the domain to bring Active Directory back to a supported
configuration.

You can migrate users, computers, and groups by using the Active Directory
Migration Tool (ADMT), Ldifde, or a non-Microsoft migration tool. ADMT can
migrate user accounts, computer accounts, and security groups with or without the
 security identifier (SID) history. ADMT also migrates user profiles. To use ADMT in a
Small Business Server environment, review the "Migrating from Small Business
Server 2000 or Windows 2000 Server" white paper. To obtain this white paper, visit
the following Microsoft Web site:

Migrating from Small Business Server 2000 or Windows 2000 Server to Windows
Small Business Server 2003

You can use Ldifde to export and import many types of objects from the damaged
domain to the new domain. These objects include user accounts, computer
accounts, security groups, organization units, Active Directory sites, subnets, and
site links. Ldifde can't migrate the SID history. Ldifde is part of Windows 2000
Server and Windows Server 2003.

For more information about how to use Ldifde, click the following article number
to view the article in the Microsoft Knowledge Base:

237677 Using Ldifde to import and export directory objects to Active Directory

You can use the Group Policy Management Console (GPMC) to export the file
system and the Active Directory part of the group policy object from the damaged
domain to the new domain.

To obtain the GPMC, visit the following Microsoft Web site:

Cloud Computing Services

For information about how to migrate group policy objects by using the GPMC,
review the "Migrate GPOs across domains with GPMC" white paper. To obtain this
white paper, visit the following Microsoft Web site:

Migrating GPOs Across Domains

18. After the recovery, evaluate your current backup plan to make sure that you have
scheduled system state backups frequently enough. Schedule system state
backups at least every day, or after every significant change. System state backups
must contain the required level of fault tolerance. For example, don't store backups
on the same drive as the computer that you're backing up. Whenever possible, use
more than one domain controller to avoid a single point of failure. Store backups
in an off-site location so that site disaster (fire, theft, flood, computer theft) doesn't
affect your ability to recover. The following Microsoft Web sites can help you
develop a backup plan.

Windows Server 2003: Creating a Backup and Recovery Plan

Windows 2000: Chapter 14 - Data Backup and Recovery
 Windows Small Business Server: Windows Server Essentials (Small Business
Server)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ESENT event IDs 1000, 1202, 412, and
454 are logged repeatedly in the
Application log
Article • 02/19/2024

This article provides a solution to an issue where ESENT event IDs 1000, 1202, 412, and
454 are logged repeatedly in the Application log.

Applies to: Windows 2000

Original KB number: 278316

Symptoms
The following event IDs are logged every five minutes in the Application log:

1000
1202
412
454

Cause
This issue occurs if the local Group Policy database file is corrupt.

Resolution
To resolve this issue, use the procedure described in this section to re-create the local
Group Policy file.

） Important

Implementing a security template on a domain controller may change the settings

of the Default Domain Controller Policy or Default Domain Policy. The applied
template may overwrite permissions on new files, registry keys and system services
created by other programs. Restoring these policies might be necessary after
applying a security template. Before performing these steps on a domain controller,
create a backup of the SYSVOL share.
 ７ Note

When you use the following procedure, your computer is returned to the original
installation state where the Local Security Policy is not defined. You may have to
start your computer in Safe mode to rename or move files. For more information
about how to do this, see Windows 2000 Help.

1. Open the %SystemRoot%\Security folder, create a new folder, and then name it
"OldSecurity".
2. Move all of the files ending in .log from the %SystemRoot%\Security folder to the
OldSecurity folder.
3. Find the Secedit.sdb file in the %SystemRoot%\Security\Database folder, and then
rename this file to "Secedit.old".
4. Click Start, click Run, type mmc, and then click OK.
5. Click Console, click Add/Remove Snap-in, and then add the Security and
Configuration snap-in.
6. Right-click Security and Configuration and Analysis, and then click Open
Database.
7. Browse to the %TEMP% folder, type Secedit.sdb in the File name box, and then
click Open.
8. When you are prompted to import a template, click Setup Security.inf, and then
click Open.
9. Copy %TEMP%\Secedit.sdb %SystemRoot%\Security\Database.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event IDs 5788 and 5789 occur on a
Windows-based computer
Article • 02/19/2024

This article provides solutions to an issue where event ID 5788 and event ID 5789 are
logged when the DNS domain name and the Active Directory domain name differ on a
Windows-based computer.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 258503

Symptoms
You may experience one of the following problems:

On Windows Vista and later versions, you receive the following error message
during interactive logon:

The security database on the server does not have a computer account for this
workstation trust relationship.

Interactive logons with domain-based accounts don't work. Only logons with local
accounts are functioning.

The following event messages are logged in the System log:

Event Type: Error

Event Source: NETLOGON
Event Category: None
Event ID: 5788
Computer: ComputerName
Description:
Attempt to update Service Principal Name (SPN) of the computer object in
Active Directory failed. The following error occurred: <Detailed error message
that varies, depending on the cause.>

Event Type: Error

Event Source: NETLOGON
Event Category: None
Event ID: 5789
 Computer: Computer
Description:
Attempt to update DNS Host Name of the computer object in Active Directory
failed. The following error occurred: <Detailed error message that varies,
depending on the cause.>

７ Note

Detailed error messages for these events are listed in the "Cause" section.

Cause
This behavior occurs when a computer tries but does not write to the dNSHostName
and servicePrincipalName attributes for its computer account in an Active Directory
Domain Services (AD DS) domain.

A computer tries to update these attributes if the following conditions are true:

Immediately after a Windows-based computer joins a domain, the computer tries

to set the dNSHostName and servicePrincipalName attributes for its computer
account in the new domain.
When the security channel is established on a Windows-based computer that is
already a member of an AD DS domain, the computer tries to update the
dNSHostName and servicePrincipalName attributes for its computer account in the
domain.
On a Windows-based domain controller, the Netlogon service tries to update the
servicePrincipalName attribute every 22 minutes.

There are two possible causes of the update failures:

The computer does not have sufficient permission to complete an LDAP modify
request of the dNSHostName or servicePrincipalName attributes for its computer
account.

In this case, the error messages that correspond to the events that are described in
the "Symptoms" section are as follows:

Event 5788

Access is denied.
 Event 5789

The system cannot find the file specified.

The primary DNS suffix of the computer does not match the DNS name of the AD
DS domain of which the computer is a member. This configuration is known as a
"Disjoint namespace."

For example, the computer is a member of the Active Directory domain

contoso.com . However, its DNS FQDN name is member1.nyc.contoso.com . Therefore,

the primary DNS suffix does not match the Active Directory domain name.

The update is blocked in this configuration because the prerequisite write

validation of the attribute values fails. The write validation fails because, by default,
the Security Accounts Manager (SAM) requires that a computer's primary DNS
suffix matches the DNS name of the AD DS domain of which computer is a
member.

In this case, the error messages that correspond to the events that are described in
the "Symptoms" section are as follows:

Event 5788

The attribute syntax specified to the directory service is invalid.

Event 5789

The parameter is incorrect.

Resolution
To resolve this problem, find the most likely cause as described in the "Cause" section.
Then, use the resolution that is appropriate for the cause.

Resolution for Cause 1

To resolve this issue, you must make sure that the computer account has sufficient
permissions to update its own computer object.

In the ACL Editor, make sure that there is an access control entry (ACE) for the trustee
account "SELF" and that it has "Allow" access for the following extended rights:

Validated write to DNS host name

 Validated write to service principal name

Then, verify any Deny permissions that may apply. Excluding the group memberships of
the computer, the following trustees also apply to the computer:

Everyone
Authenticated Users
SELF

The ACEs that apply to these trustees may also deny access to write to attributes, or
they may deny the "Validated write to DNS host name" or "Validated write to service
principal name" extended rights.

Resolution for Cause 2

To resolve this issue, use one of the following methods, as appropriate:

Method 1: Correct an unintentional disjoint namespace

If the disjoint configuration is unintentional, and if you want to revert to a contiguous
namespace, use this method.

For more information about how to revert to a contiguous namespace on Windows

Server 2003, see the following Microsoft TechNet article:
Transition from a Disjoint Namespace to a Contiguous Namespace
For Windows Server 2008 and for Windows Vista and later versions, see the following
Microsoft TechNet article:
Reverse an Accidentally Created Disjoint Namespace

Method 2: Verify that the disjoint namespace configuration is

working correctly
Use this method, if you want to keep the disjoint namespace. To do this, follow these
steps to make some configuration changes to resolve the errors.

For more information about how to verify that the disjoint namespace is working
correctly on Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 with
Service Pack 1 (SP1), and Windows Server 2003 with Service Pack 2 (SP2), see the
following Microsoft TechNet article: Create a Disjoint Namespace
For more information about how to verify that the disjoint namespace is working
correctly on Windows Server 2008 R2 and Windows Server 2008, see the following
Microsoft TechNet article: Create a Disjoint Namespace
By extending the example that is mentioned in the last major bullet point in the "Cause"
section, you would add nyc.contoso.com as an allowed suffix to the attribute.

More information
Older versions of this article mentioned changing the permissions on the computer
objects to enable general write access to resolve this problem. This was the only
approach that existed in Windows 2000. However, it is less secure than using msDS-
AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes restrict the client from writing arbitrary SPNs into Active
Directory. The "Windows 2000 method" enables the client to write SPNs that block
Kerberos from working with other important servers (create duplicates). When you use
msDS-AllowedDNSSuffixes, SPN collisions such as those can occur only when the other
server has the same host name as the local computer.

A network trace of the response to the LDAP modify request displays the following
information:
win: 17368, src: 389 dst: 1044

LDAP: ProtocolOp: ModifyResponse (7)

LDAP: MessageID

LDAP: ProtocolOp = ModifyResponse

LDAP: Result Code = Constraint Violation

LDAP: Error Message = 0000200B: AtrErr: DSID-03151E6D In this network trace, 200B
hexadecimal is equal to 8203 decimal.

The net helpmsg 8203 command returns the following information: The attribute syntax
specified to the directory service is invalid." Network Monitor 5.00.943 displays the
following result code: "Constraint Violation." Winldap.h maps error 13 to
"LDAP_CONSTRAINT_VIOLATION.

The DNS domain name and the Active Directory domain name can differ if one or more
of the following conditions are true:

The TCP/IP DNS configuration contains a DNS domain that differs from the Active
Directory domain of which the computer is a member, and the Change primary
DNS suffix when domain membership changes option is disabled. To view this
option, right-click My Computer, click Properties, and then click the Network
Identification tab.
 Windows Server 2003-based or Windows XP Professional-based computers may
apply a Group Policy setting that sets the primary suffix to a value that differs from
the Active Directory domain. The Group Policy setting is as follows: Computer
Configuration\Administrative Templates\Network\DNS Client: Primary DNS Suffix

The domain controller is located in a domain that was renamed by the Rendom.exe
utility. However, the administrator did yet change the DNS suffix from the previous
DNS domain name. The domain rename process does not update the primary DNS
suffix to match the current DNS domain name following renames of DNS domain
names. Domains in an Active Directory forest that do not have the same
hierarchical domain name are in a different domain tree. When different domain
trees are in a forest, the root domains are not contiguous. However, this
configuration does not create a disjoint DNS namespace. You have multiple DNS
or even Active Directory DNS root domains. A disjoint namespace is characterized
by a difference between the primary DNS suffix and the Active Directory domain
name of which the computer is a member.

Disjoint namespace can be used with caution in some scenarios. However, it is not
supported in all scenarios.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to complete a semantic database
analysis for the Active Directory
database by using Ntdsutil.exe
Article • 02/19/2024

This article describes the steps to complete a semantic database analysis for the Active
Directory database by using Ntdsutil.exe

Applies to: Windows Server 2012 R2

Original KB number: 315136

Summary
This step-by-step article describes how to run the semantic checker on the Active
Directory database. Unlike the file management commands, which test the integrity of
the database with respect to the ESENT database semantics, the semantic analysis
analyzes the data with respect to Active Directory semantics. You can use this process to
generate reports on the number of records present, including deleted and phantom
records.

The Windows 2000 Directory service opens its files in Exclusive mode. This means that
the files can't be managed while the computer is operating as a domain controller. The
first procedure is to boot your server into Directory Services Restore mode.

Boot into Directory Services Restore Mode

1. Reboot the server.
2. After the BIOS information appears, press F8.
3. Select Directory Services Restore Mode (Windows 2000 domain controllers only),
and then press ENTER.
4. Select your server, and then press ENTER.
5. Log on by using your Restore Administrative account that was made when this
domain controller was promoted.

Starting Ntdsutil.exe
1. Click Start, and then click Run.
 2. In the Open box, type ntdsutil, and then press ENTER. Note that you can view
Ntdsutil.exe Help by typing ? at the command prompt, and then pressing ENTER.

Complete a database analysis

This procedure starts the semantic analysis of the Ntds.dit file. A report is generated and
written to a file that is named Dsdit.dmp. n, in the current folder, where n is an integer
that is incremented each time that you run the command.

1. At the Ntdsutil.exe command prompt, type Semantic database analysis, and then
press ENTER.
2. At the Semantic Checker command prompt, type Go, and then press ENTER.
3. Verification is displayed. To exit, type q, press ENTER, type q, and then press ENTER.

Retrieve a specific record

This procedure retrieves a specific record number from the Ntds.dit file by using the
DNT record number variable. One of the functions of the database layer is to translate
each distinguished name into an integer structure that is called the distinguished name
tag, which is used for all internal accesses. The database layer guarantees the
uniqueness of the distinguished name tag for each database record. To display indices
and their associated DNT, use the integrity command in the Files menu of Ntdsutil.exe.

1. At the Ntdsutil.exe command prompt, type Semantic database analysis, and then
press ENTER.
2. At the Semantic Checker command prompt, type Go, and then press ENTER.
3. At the Semantic Checker command prompt, type Get DNT record number, and then
press ENTER.
4. Verification is displayed. To exit, type q, press ENTER, type q, and then press ENTER.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Ntdsutil to manage Active
Directory files from the command line in
Windows Server 2003
Article • 02/19/2024

This article describes how to manage the Active Directory (AD) database file, Ntds.dit,
from the command line.

Applies to: Windows Server 2003

Original KB number: 816120

How to start your computer in Directory

Services Restore mode
Windows Server 2003 Directory Service opens its files in exclusive mode, which means
that the files can't be managed while the server is operating as a domain controller.

To start the server in Directory Services Restore mode, follow these steps:

1. Restart the computer.

2. After the BIOS (Basic Input/Output System) information is displayed, press F8.
3. Use the DOWN ARROW to select Directory Services Restore Mode(Windows
Server 2003 domain controllers only), and then press ENTER.
4. Use the UP and DOWN ARROWS to select the Windows Server 2003 operating
system, and then press ENTER.
5. Sign in with your administrative account and password.

How to install Support Tools and start Ntdsutil

To install Windows Support Tools, follow these steps:

1. Insert the Windows Server 2003 installation CD in the CD-ROM or DVD-ROM drive.
2. Select Start, select Run, type drive_letter :\Support\Tools\suptools.msi , and
then press ENTER.

To start Ntdsutil, select Start, select Run, type ntdsutil in the Open box, and then press
ENTER.
 ７ Note

To access the list of available commands, type ?, and then press ENTER.

How to move the database

You can move the Ntds.dit data file to a new folder. If you do so, the registry is updated
so that Directory Service uses the new location when you restart the server.

To move the data file to another folder, follow these steps:

1. Select Start, select Run, type ntdsutil in the Open box, and then press ENTER.
2. At the Ntdsutil command prompt, type files, and then press ENTER.
3. At the file maintenance command prompt, type move DB to new location (where
new location is an existing folder that you've created for this purpose), and then
press ENTER.
4. To quit Ntdsutil, type quit, and then press ENTER.
5. Restart the computer.

How to move log files

Use the move logs to command to move the directory service log files to another folder.
For the new settings to take effect, restart the computer after you move the log files.

To move the log files, follow these steps:

1. Select Start, select Run, type ntdsutil in the Open box, and then press ENTER.
2. At the Ntdsutil command prompt, type files, and then press ENTER.
3. At the file maintenance command prompt, type move logs to new location (where
new location is an existing folder that you've created for this purpose), and then
press ENTER.
4. Type quit, and then press ENTER.
5. Restart the computer.

How to recover the database

To recover the database, follow these steps:

1. Select Start, select Run, type ntdsutil in the Open box, and then press ENTER.
2. At the Ntdsutil command prompt, type files, and then press ENTER.
 3. At the file maintenance command prompt, type recover, and then press ENTER.
4. Type quit, and then press ENTER.
5. Restart the computer.

７ Note

You can also use Esentutl.exe to perform database recovery when the procedure
described earlier in this article fails (for example, the procedure may fail when the
database is inconsistent). To use Esentutl.exe to perform database recovery, follow
these steps:

1. Select Start, select Run, type cmd in the Open box, and then press ENTER.
2. Type esentutl /r path \ntds.dit, and then press ENTER. path refers to the current
location of the Ntds.dit file.
3. Delete the database log files (.log) from the WINDOWS\Ntds folder.
4. Restart the computer.

For additional information about the esentutl.exe utility, at the command prompt, type
esentutl /?, and then press ENTER.

７ Note

This procedure involves transaction logs to recover data. Transaction logs are used
to make sure that committed transactions are not lost if your computer fails or if it
experiences unexpected power loss. Transaction data is written first to a log file,
and then it is written to the data file. After you restart the computer after it fails,
you can rerun the log to reproduce the transactions that were committed but that
were not recorded to the data file.

How to set paths

You can use the set path command to set the path for the following items:

Backup: Use this parameter with the set path command to set the disk-to-disk
backup target to the folder that is specified by the location variable. You can
configure Directory Service to do an online disk-to-disk backup at scheduled
intervals.
Database: Use this parameter with the set path command to update the part of the
registry that identifies the location and file name of the data file. Use this
 command only to rebuild a domain controller that has lost its data file and that
isn't being restored by means of typical restoration procedures.
Logs: Use this parameter with the set path command to update the part of the
registry that identifies the location of the log files. Use this command only if you're
rebuilding a domain controller that has lost its log files and isn't being restored by
means of typical restoration procedures.
Working Directory: Use this parameter with the set path command to set the part
of the registry that identifies Directory Service's working folder to the folder that is
specified by the location variable. To run the set path command, follow these steps:

1. Select Start, select Run, type ntdsutil in the Open box, and then press ENTER.

2. At the Ntdsutil command prompt, type files, and then press ENTER.

3. At the file maintenance command prompt, type set path object location, and then
press ENTER. object refers to one of the following items:

Backup
Database
Logs
Working Directory

location refers to the location (folder) to which you want to set the object
identified in the command.

4. Type quit, and then press ENTER.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ISMServ.exe does not start when a
domain controller starts
Article • 02/28/2024

This article provides a workaround for an issue where the IsmServ service doesn't start
correctly when a domain controller starts.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4530043

Symptoms
When you start a Windows Server domain controller (DC), it does not start correctly.
When you check the System log in Event Viewer, you find the following entry for Event
ID 7023:

Log Name: System

Source: Service Control Manager​
Event ID: 7023​
Level: Error​
Description:​
The IsmServ service terminated with the following error:
The specified server cannot perform the requested operation.​
Event Xml:​
<Event xmlns=" http://schemas.microsoft.com/win/2004/08/events/event ">
...​
<EventData>​
<Data Name="param1">IsmServ</Data>​
<Data Name="param2">%%58</Data>​
</EventData>​
</Event>​

This event includes the following data parameters:

The param1 parameter value, IsmServ: This represents the Intersite Messaging
service (ISMserv.exe).
The param2 parameter value, 58: This maps to the ERROR_BAD_NET_RESP
message ("The specified server cannot perform the requested​operation").
To collect more information about this problem, you can configure LDAP Event Tracing
for Windows (ETW) to run at system startup. (For details about how to do this, see More
information.) After you restart the DC, you should see the following lines in the log:

[Microsoft-Windows-LDAP-Client/Debug] Message=LDAP connection 0xec4b08a8

successfully resolved 'localhost' using GetHostByName.
...
[Microsoft-Windows-LDAP-Client/Debug] Message=gethostbyname collected 2
records for ' dc1.contoso.com '[Microsoft-Windows-LDAP-Client/Debug]
Message=LdapParallelConnect called for connection 0xec4b08a8 with timeout 45
sec 0 usec. Total count is 2.
[Microsoft-Windows-LDAP-Client/Debug] Message=No response yet...
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapParallelConnect finished
for connection 0xec4b08a8. Time taken was 1 sec. Original timeout specified was 45
sec 0 usec.
...
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapConnect failed to open
connection 0xec4b08a8, error = 0x5b.
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapConnect thread 0xce0 has
connection 0xec4b08a8 as down.

In this event, the value of the error parameter (0x5b or 91) maps to the
LDAP_CONNECT_ERROR message.

Cause
ISMServ depends on Active Directory Domain Services (AD DS). However, during system
startup, ISMServ may try to create an LDAP connection to AD DS before AD DS finishes
coming online. When this happens, the LDAP port (TCP port 389) is not available when
ISMServ tries to connect. Because the port is not listening, ISMServ determines that the
connection has failed without waiting for the connection time-out period (45 seconds).
Therefore, ISMServ does not start.

Workaround
To immediately work around this problem, manually restart ISMServ.

To avoid this problem in the future, use the Services and Applications MMC snap-in to
change the Startup Type of ISMServ from Automatic to Automatic (Delayed Start).
More information
To configure LDAP ETW, follow these steps:

1. Use Registry Editor to create the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap\Tracing\ISMSERV.EXE

2. Open an elevated Command Prompt window, and run the following commands:

Console

logman create trace "autosession\g_os" -ow -o c:\boot-ldap.etl -p

"Microsoft-Windows-LDAP-Client" 0xffffffffffffffff 0xff -nb 16 16 -bs
1024 -mode Circular -f bincirc -max 4096 -ets
reg add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\g_os
/v FileMax /t REG_DWORD /d 2 /F

3. Restart the computer.

4. After the computer starts, run the following command at an elevated command
prompt:

Console

logman stop "g_os" -ets

5. When you finish collecting data, run the following command at an elevated
command prompt to stop tracing:

Console

logman delete "autosession\g_os" -ets

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

References
How to turn on debug logging of the LDAP client (Wldap32.dll)
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you run the Adprep
/rodcprep command in Windows Server
2008: Adprep could not contact a
replica for partition
DC=DomainDnsZones,DC=Contoso,DC
=com
Article • 02/19/2024

This article solves a problem that the Adprep /rodcprep command isn't completed
successfully because the infrastructure master for one or more active directory NDNCs
isn't reachable.

Applies to: Windows Server 2012 R2

Original KB number: 949257

Symptoms
When you run the Adprep /rodcprep command on Windows Server 2008, you receive
the following error message:

Adprep could not contact a replica for partition

DC=DomainDnsZones,DC=Contoso,DC=com

Adprep failed the operation on partition

DC=DomainDnsZones,DC=Contoso,DC=com Skipping to next partition.

Adprep could not contact a replica for partition

DC=ForestDnsZones,DC=Contoso,DC=com

Adprep encountered an LDAP error. Error code: 0x0. Server extended error code:
0x0, Server error message: (null).

Adprep failed the operation on partition DC=ForestDnsZones,DC=Contoso,DC=com

Skipping to next partition.

Adprep completed with errors. Not all partitions are updated.

Cause
This problem occurs when the Adprep /rodcprep command tries to contact the
infrastructure master for each application partition in the forest. The command does it
to set the permissions that are required for Read-Only Domain Controller (RODC)
replication. The Adprep /rodcprep command fails if one of the following conditions is
true:

The partition or the partitions that are referenced in the error message no longer
exist.
The infrastructure master for the referenced partition or partitions has been
forcefully demoted or is offline.

Resolution
To resolve this problem if the partition no longer exists, do a metadata cleanup for the
orphaned partition using the "remove nc" parameter of the Dsmgmt tool. For more
information, visit the following Microsoft Web site:

partition management

If the specified partition exists, specify an infrastructure role owner that is online for the
partition. You can do it by manually modifying the fSMORoleOwner attribute on the
object, as described in the "More information" section.

More information
The following script sample modifies the fSMORoleOwner attribute on the
infrastructure object of the specified Non-Domain Naming Context (NDNC) to an active,
or contactable, server. The NDNC in this sample is the
DomainDnsZones,DC=contoso,DC=com NDNC naming context. The script uses the
following command:

VB

cscript fixfsmo.vbs DC=DomainDnsZones,DC=contoso,DC=com

VB

'-------fixfsmo.vbs------------------
const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
 const ADS_NAME_TYPE_CANONICAL = 2

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
' Assume the command line argument is the NDNC (in DN form) to use.
NdncDN = inArgs(0)
Else
Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
End if

if (NdncDN <> "") then

' Convert the DN form of the NDNC into DNS dotted form.
Set objTranslator = CreateObject("NameTranslate")
objTranslator.Init ADS_NAME_INITTYPE_GC, ""
objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)

Wscript.Echo "DNS name: " & strDomainDNS

' Find a domain controller that hosts this NDNC and that is online.
set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
strDnsHostName = objRootDSE.Get("dnsHostName")
strDsServiceName = objRootDSE.Get("dsServiceName")
Wscript.Echo "Using DC " & strDnsHostName

' Get the current infrastructure fsmo.

strInfraDN = "CN=Infrastructure," & NdncDN
set objInfra = GetObject("LDAP://" & strInfraDN)
Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner

' If the current fsmo holder is deleted, set the fsmo holder to this
domain controller.

if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then

' Set the fsmo holder to this domain controller.

objInfra.Put "fSMORoleOwner", strDsServiceName
objInfra.SetInfo

' Read the fsmo holder back.

set objInfra = GetObject("LDAP://" & strInfraDN)
Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner

End if

End if

To determine the infrastructure master for a partition, query the fSMORoleOwner

attribute on the infrastructure object under the naming context root in question. For
example, query the fSMORoleOwner attribute on the
CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com naming context root
to determine the infrastructure master for the
DC=DomainDnsZones,DC=contoso,DC=com partition. Similarly, query the
fSMORoleOwner attribute on the
CN=Infrastructure,DC=ForestDnsZones,DC=contoso,DC=com naming context root to
determine the infrastructure master for the DC=ForestDnsZones,DC=contoso,DC=com
partition.

You can use tools such as the LDP tool, the Active Directory Service Interfaces (ADSI) Edit
tool, and the ldifde tool to do these queries. For example, the following query uses the
Idifde tool:

ldifde -f Infra_DomainDNSZones.ldf -d
"CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com" -l fSMORoleOwner

This query returns the infrastructure master role owner for the
DC=DomainDnsZones,DC=contoso,DC=com partition to the
Infra_DomainDNSZones.ldf file.

７ Note

You can run the Adprep /rodcprep command multiple times without harming the
forest. Operations that were completed in earlier executions of the rodcprep
command aren't repeated.

If you try to run the rodcprep command in an isolated environment, the infrastructure
master for each domain and for each application directory partition must be available
within the environment for the operation to succeed.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure Kerberos Constrained
Delegation for Web Enrollment proxy
pages
Article • 02/19/2024

The article provides step-by-step instructions to implement Service for User to Proxy
(S4U2Proxy) or Kerberos Only Constrained Delegation on a custom service account for
Web Enrollment proxy pages.

Applies to: Window Server 2016, Window Server 2019, Windows Server 2012 R2
Original KB number: 4494313

Summary
This article provides step-by-step instructions to implement Service for User to Proxy
(S4U2Proxy) or Kerberos-only constrained delegation for Web Enrollment proxy pages.
This article describes the following configuration scenarios:

Configuring delegation for a custom service account

Configuring delegation to the NetworkService account

７ Note

The workflows that are described in this article are specific to a particular
environment. The same workflows may not work for a different situation. However,
the principles remain the same. The following figure summarizes this environment.

Scenario 1: Configure constrained delegation

for a custom service account
This section describes how to implement Service for User to Proxy (S4U2Proxy) or
Kerberos-only constrained delegation when you use a custom service account for the
Web Enrollment proxy pages.

1. Add an SPN to the service account

Associate the service account with a Service Principal Name (SPN). To do this, follow
these steps:

1. In Active Directory Users and Computers, connect to the domain, and then select
PKI > PKI Users.

2. Right-click the service account (for example, web_svc), and then select Properties.

3. Select Attribute Editor > servicePrincipalName.

4. Type the new SPN string, select Add (as shown in the following figure), and then
select OK.

You can also use Windows PowerShell to configure the SPN. To do this, open an
elevated PowerShell window, and then run setspn -s SPN Accountname . For
example, run the following command:

Console

setspn -s HTTP/webenroll2016.contoso.com web_svc

2. Configure the delegation
1. Configure S4U2proxy (Kerberos only) constrained delegation on the service
account. To do this, in the Properties dialog box of the service account (as
described in the previous procedure), select Delegation > Trust this user for
delegation to specified services only. Make sure that Use Kerberos only is
selected.

2. Close the dialog box.

3. In the console tree, select Computers, and then select the computer account of the
Web Enrollment front-end server.

７ Note

This account is also known as the "machine account."

4. Configure S4U2self (Protocol Transition) constrained delegation on the computer

account. To do this, right-click the computer account, and then select Properties >
 Delegation > Trust this computer for delegation to specified services only. Select
Use any authentication protocol.

3. Create and bind the SSL certificate for web enrollment

To enable the web enrollment pages, create a domain certificate for the website, and
then bind it to the Default Web Site. To do this, follow these steps:

1. Open Internet Information Services (IIS) Manager.

2. In the console tree, select <HostName>, and then select Server Certificates.

７ Note
 <HostName> is the name of the front-end web server.

3. In the Actions menu, select Create a Domain Certificate.

4. After the certificate is created, select Default Web Site in the console tree, and
then select Bindings.

5. Make sure that Port is set to 443. Then under SSL certificate, select the certificate
that you created in step 3.

6. Select OK to bind the certificate to port 443.

4. Configure the Web Enrollment front-end server to use
the service account

） Important

Make sure that the service account is part of either the local administrators or
IIS_Users group on the web server.

1. Right-click DefaultAppPool, and then select Advanced Settings.

2. Select Process Model > Identity, select Custom account, and then select Set.
Specify the name and password of the service account.
 3. Select OK in the Set Credentials and Application Pool Identity dialog boxes.

4. In Advanced Settings, locate Load User Profile, and make sure that it's set to True.

5. Restart the computer.

Scenario 2: Configure constrained delegation

on the NetworkService account
This section describes how to implement S4U2Proxy or Kerberos-only constrained
delegation when your use the NetworkService account for the Web Enrollment proxy
pages.
Optional step: Configure a name to use for connections
You can assign a name to the Web Enrollment role that clients can use to connect. This
configuration means that incoming requests do not have to know the computer name
of the Web Enrollment front-end server, or other routing information such as the DNS
canonical name (CNAME).

For example, suppose the computer name of your Web Enrollment server is
WEBENROLLMAC (in the Contoso domain). You want incoming connections to use the
name ContosoWebEnroll instead. In this case, the connection URL would be the
following:

https://contosowebenroll.contoso.com/certsrv

It would not be the following:

https://WEBENROLLMAC.contoso.com/certsrv

To use such a configuration, follow these steps:

1. In the DNS zone file for the domain, create an alias record or a host name record
that maps the new connection name to the Web Enrollment role IP address. Use
the Ping tool to test the routing configuration.

In the example that was previously discussed, the Contoso.com zone file has an
alias record that maps ContosoWebEnroll to the IP address of the Web Enrollment
role.

2. Configure the new name as an SPN for the Web Enrollment front-end server. To do
this, follow these steps:
a. In Active Directory Users and Computers, connect to the domain, and then
select Computers.
b. Right-click the computer account of the Web Enrollment front-end server, and
then select Properties.

７ Note

This account is also known as the "machine account."

c. Select Attribute Editor > servicePrincipalName.

d. Type HTTP/<ConnectionName>.<DomainName.com>, select Add, and then
select OK.
 ７ Note

In this string, <ConnectionName> is the new name that you have defined,
and <DomainName> is the name of the domain. In the example, the string
is HTTP/ContosoWebEnroll.contoso.com.

1. Configure the delegation

1. If you haven't already connected to the domain, do this now in Active Directory
Users and Computers, and then select Computers.

2. Right-click the computer account of the Web Enrollment front-end server, and
then select Properties.

７ Note

This account is also known as the "machine account."

3. Select Delegation, and then select Trust this computer for delegation to specified
services only.

７ Note

If you can guarantee that clients will always use Kerberos authentication when
they connect to this server, select Use Kerberos only. If some clients will use
other authentication methods, such as NTLM or forms-based authentication,
select Use any authentication protocol.
2. Create and bind the SSL certificate for web enrollment
To enable the web enrollment pages, create a domain certificate for the website, and
then bind it to the default first site. To do this, follow these steps:

1. Open IIS Manager.

2. In the console tree, select <HostName>, and then select Server Certificates in the
actions pane.

７ Note
 <HostName> is the name of the front-end web server.

3. In the Actions menu, select Create a Domain Certificate.

4. After the certificate is created, select Default Web Site, and then select Bindings.

5. Make sure that Port is set to 443. Then, under SSL certificate, select the certificate
that you created in step 3. Select OK to bind the certificate to port 443.

3. Configure the Web Enrollment front-end server to use

the NetworkService account
1. Right-click DefaultAppPool, and then select Advanced Settings.
2. Select Process Model > Identity. Make sure that Built-in account is selected, and
then select NetworkService. Then, select OK.

3. In Advanced Properties, locate Load User Profile, and then make sure that it's set
to True.
 4. Restart the IIS service.

Related topics
For more information about these processes, see Authenticating Web Application Users.

For more information about the S4U2self and S4U2proxy protocol extensions, see the
following articles:

[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained

Delegation Protocol
4.1 S4U2self Single Realm Example
4.3 S4U2proxy Example

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Domain controller promotion process
shows the Windows Server Technical
Preview option in the Domain and
Forest functional level list
Article • 02/19/2024

This article provides a resolution to an issue where Domain controller promotion

process shows "Windows Server Technical Preview" in the Domain and Forest functional
level list.

Applies to: Windows Server 2016

Original KB number: 3202325

Symptoms
Consider the following scenario:

You have a computer that's running Windows Server 2016.

You install the Active Directory Domain Service (AD DS) role.
After the role is installed, you run the domain controller (DC) promotion process
on the server.

However, on the second page of the DC promotion Wizard, you notice that both the
Forest and Domain functional levels show an incorrect version of Windows, as in the
following screenshot:
You expect the DC Promotion Wizard to show Windows Server 2016 instead of
Windows Server Technical Preview.

７ Note

The Windows Server 2016 Domain and Forest functional levels are not affected
functionally.

Cause
This issue occurs because the display string was not updated in the Forest and Domain
functional levels before the release of Windows Server 2016.

Resolution
To resolve this issue, apply the latest cumulative update for Windows Server 2016 from
Windows Update before you promote a computer to a domain controller.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure a firewall for Active
Directory domains and trusts
Article • 02/19/2024

This article describes how to configure a firewall for Active Directory domains and trusts.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Standard, Windows Server 2012 Standard
Original KB number: 179442

７ Note

Not all the ports that are listed in the tables here are required in all scenarios. For
example, if the firewall separates members and DCs, you don't have to open the
FRS or DFSR ports. Also, if you know that no clients use LDAP with SSL/TLS, you
don't have to open ports 636 and 3269.

More information

７ Note

The two domain controllers are both in the same forest, or the two domain
controllers are both in a separate forest. Also, the trusts in the forest are Windows
Server 2003 trusts or later version trusts.

ﾉ Expand table

Client Port(s) Server Port Service

1024-65535/TCP 135/TCP RPC Endpoint Mapper

1024-65535/TCP 1024-65535/TCP RPC for LSA, SAM, NetLogon (*)

1024-65535/TCP/UDP 389/TCP/UDP LDAP

1024-65535/TCP 636/TCP LDAP SSL

1024-65535/TCP 3268/TCP LDAP GC

1024-65535/TCP 3269/TCP LDAP GC SSL

 Client Port(s) Server Port Service

53,1024-65535/TCP/UDP 53/TCP/UDP DNS

1024-65535/TCP/UDP 88/TCP/UDP Kerberos

1024-65535/TCP 445/TCP SMB

1024-65535/TCP 1024-65535/TCP FRS RPC (*)

NetBIOS ports as listed for Windows NT are also required for Windows 2000 and
Windows Server 2003 when trusts to domains are configured that support only
NetBIOS-based communication. Examples are Windows NT-based operating systems or
third-party Domain Controllers that are based on Samba.

For more information about how to define RPC server ports that are used by the LSA
RPC services, see:

Restricting Active Directory RPC traffic to a specific port .

The Domain controllers and Active Directory section in Service overview and
network port requirements for Windows .

Windows Server 2008 and later versions

Windows Server 2008 newer versions of Windows Server have increased the dynamic
client port range for outgoing connections. The new default start port is 49152, and the
default end port is 65535. Therefore, you must increase the RPC port range in your
firewalls. This change was made to comply with Internet Assigned Numbers Authority
(IANA) recommendations. This differs from a mixed-mode domain that consists of
Windows Server 2003 domain controllers, Windows 2000 server-based domain
controllers, or legacy clients, where the default dynamic port range is 1025 through
5000.

For more information about the dynamic port range change in Windows Server 2012
and Windows Server 2012 R2, see:

The default dynamic port range for TCP/IP has changed .

Dynamic Ports in Windows Server .

ﾉ Expand table

Client Port(s) Server Port Service

49152-65535/UDP 123/UDP W32Time

 Client Port(s) Server Port Service

49152-65535/TCP 135/TCP RPC Endpoint Mapper

49152-65535/TCP 464/TCP/UDP Kerberos password change

49152-65535/TCP 49152-65535/TCP RPC for LSA, SAM, NetLogon (*)

49152-65535/TCP/UDP 389/TCP/UDP LDAP

49152-65535/TCP 636/TCP LDAP SSL

49152-65535/TCP 3268/TCP LDAP GC

49152-65535/TCP 3269/TCP LDAP GC SSL

53, 49152-65535/TCP/UDP 53/TCP/UDP DNS

49152-65535/TCP 49152-65535/TCP FRS RPC (*)

49152-65535/TCP/UDP 88/TCP/UDP Kerberos

49152-65535/TCP/UDP 445/TCP SMB (**)

49152-65535/TCP 49152-65535/TCP DFSR RPC (*)

NetBIOS ports as listed for Windows NT are also required for Windows 2000 and Server
2003 when trusts to domains are configured that support only NetBIOS-based
communication. Examples are Windows NT-based operating systems or third-party
Domain Controllers that are based on Samba.

(*) For information about how to define RPC server ports that are used by the LSA RPC
services, see:

Restricting Active Directory RPC traffic to a specific port .

The Domain controllers and Active Directory section in Service overview and
network port requirements for Windows .

(**) For the operation of the trust this port is not required, it is used for trust creation
only.

７ Note

External trust 123/UDP is only needed if you have manually configured the
Windows Time Service to Sync with a server across the external trust.

Active Directory
The Microsoft LDAP client uses ICMP ping when a LDAP request is pending for extended
time and it waits for a response. It sends ping requests to verify the server is still on the
network. If it does not receive ping responses, it fails the LDAP request with
LDAP_TIMEOUT.

The Windows Redirector also uses ICMP Ping messages to verify that a server IP is
resolved by the DNS service before a connection is made, and when a server is located
by using DFS. If you want to minimize ICMP traffic, you can use the following sample
firewall rule:

<any> ICMP -> DC IP addr = allow

Unlike the TCP protocol layer and the UDP protocol layer, ICMP does not have a port
number. This is because ICMP is directly hosted by the IP layer.

By default, Windows Server 2003 and Windows 2000 Server DNS servers use ephemeral
client-side ports when they query other DNS servers. However, this behavior may be
changed by a specific registry setting. Or, you can establish a trust through the Point-to-
Point Tunneling Protocol (PPTP) compulsory tunnel. This limits the number of ports that
the firewall has to open. For PPTP, the following ports must be enabled.

ﾉ Expand table

Client Ports Server Port Protocol

1024-65535/TCP 1723/TCP PPTP

In addition, you would have to enable IP PROTOCOL 47 (GRE).

７ Note

When you add permissions to a resource on a trusting domain for users in a trusted
domain, there are some differences between the Windows 2000 and Windows NT
4.0 behavior. If the computer cannot display a list of the remote domain's users,
consider the following behavior:

Windows NT 4.0 tries to resolve manually typed names by contacting the PDC
for the remote user's domain (UDP 138). If that communication fails, a
Windows NT 4.0-based computer contacts its own PDC, and then asks for
resolution of the name.
Windows 2000 and Windows Server 2003 also try to contact the remote user's
PDC for resolution over UDP 138. However, they do not rely on using their
 own PDC. Make sure that all Windows 2000-based member servers and
Windows Server 2003-based member servers that will be granting access to
resources have UDP 138 connectivity to the remote PDC.

Reference
Service overview and network port requirements for Windows is a valuable resource
outlining the required network ports, protocols, and services that are used by Microsoft
client and server operating systems, server-based programs, and their subcomponents
in the Microsoft Windows Server system. Administrators and support professionals may
use the article as a roadmap to determine which ports and protocols Microsoft
operating systems and programs require for network connectivity in a segmented
network.

You should not use the port information in Service overview and network port
requirements for Windows to configure Windows Firewall. For information about how
to configure Windows Firewall, see Windows Firewall with Advanced Security.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to raise Active Directory domain
and forest functional levels
Article • 02/19/2024

This article describes how to raise Active Directory domain and forest functional levels.

Applies to: Windows Server 2003

Original KB number: 322692

Summary
For information about Windows Server 2016 and new features in Active Directory
Domain Services (AD DS), see What's new in Active Directory Domain Services for
Windows Server 2016.

This article discusses raising the domain and forest functional levels that are supported
by Microsoft Windows Server 2003-based or newer domain controllers. There are four
releases of Active Directory, and only the levels that have changed from Windows NT
Server 4.0 require special consideration. Therefore, the other level changes are
mentioned by using the newer, current, or older versions of the domain controller
operating system, of the domain, or of the forest functional level.

Functional levels are an extension of the mixed mode and the native mode concepts
that were introduced in Microsoft Windows 2000 Server to activate new Active Directory
features. Some additional Active Directory features are available when all the domain
controllers are running the newest Windows Server version in a domain or in a forest,
and when the administrator activates the corresponding functional level in the domain
or in the forest.

To activate the newest domain features, all the domain controllers must be running the
newest Windows Server operating system version in the domain. If this requirement is
met, the administrator can raise the domain functional level.

To activate the newest forest-wide features, all the domain controllers in the forest must
be running the Windows Server operating system version that corresponds to the
desired forest functional level. Additionally, the current domain functional level must
already be at the newest level. If these requirements are met, the administrator can raise
the forest functional level.

Generally, the changes to the domain and forest functional levels are irreversible. If the
change can be undone, a forest recovery must be used. With the Windows Server 2008
R2 operating system, the changes to domain functional levels and to forest functional
levels can be rolled back. However, the rollback can be performed in only the specific
scenarios that are described in the Technet article about the Active Directory functional
levels.

７ Note

The newest domain functional levels and the newest forest functional levels affect
only the way that the domain controllers operate together as a group. The clients
that interact with the domain or with the forest are unaffected. Additionally,
applications are unaffected by changes to the domain functional levels or to the
forest functional levels. However, applications can take advantage of the newest
domain features and of the newest forest features.

For more information, view the TechNet article about the features associated with
the various functional levels.

Raising the functional level

Ｕ Caution

Do not raise the functional level if the domain has or will have a domain controller
that is of an earlier version than the version that is cited for that level. For example,
a Windows Server 2008 functional level requires that all domain controllers have
Windows Server 2008 or a later operating system installed in the domain or in the
forest. After the domain functional level is raised to a higher level, it can only be
changed back to an older level by using a forest recovery. This restriction exists
because the features often change the communication between the domain
controllers, or because the features change the storage of the Active Directory data
in the database.

The most common method to enable the domain and forest functional levels is to use
the graphical user interface (GUI) administration tools that are documented in the
TechNet article about Windows Server 2003 Active Directory functional levels. This
article discusses Windows Server 2003. However, the steps are the same in the newer
the operating system versions. Additionally, the functional level can be manually
configured or can be configured by using Windows PowerShell scripts. For more
information about how to manually configure the functional level, see the "View and set
the functional level" section.
For more information about how to use Windows PowerShell script to configure the
functional level, view Raise the Forest Functional Level.

View and set the functional level manually

The Lightweight Directory Access Protocol (LDAP) tools such as Ldp.exe and
Adsiedit.msc can be used to view and to modify the current domain and forest
functional level settings. When you change the functional level attributes manually, the
best practice is to make attribute changes on the Flexible Single Master Operations
(FSMO) domain controller that is normally targeted by the Microsoft administrative
tools.

Domain functional level settings

The msDS-Behavior-Version attribute is on the naming context (NC) head for the
domain, that is, DC=corp, DC=contoso, DC=com.

You can set the following values for this attribute:

Value of 0 or not set=mixed level domain

Value of 1=Windows Server 2003 domain level
Value of 2=Windows Server 2003 domain level
Value of 3=Windows Server 2008 domain level
Value of 4=Windows Server 2008 R2 domain level

Mixed mode and native mode settings

The ntMixedDomain attribute is on the naming context (NC) head for the domain, that
is, DC=corp, DC=contoso, DC=com.

You can set the following values for this attribute:

Value of 0=Native level domain

Value of 1=Mixed level domain

Forest level setting

The msDS-Behavior-Version attribute is on the CN=Partitions object in the Configuration

naming context (NC), that is, CN=Partitions, CN=Configuration, DC= ForestRootDomain.

You can set the following values for this attribute:

 Value of 0 or not set=mixed level forest

Value of 1=Windows Server 2003 interim forest level

Value of 2=Windows Server 2003 forest level

７ Note

When you increase the msDS-Behavior-Version attribute from the 0 value to

the 1 value by usingAdsiedit.msc, you receive the following error message:
Illegal modify operation. Some aspect of the modification is not permitted.

Value of 3=Windows Server 2008 domain level

Value of 4=Windows Server 2008 R2 domain level

After you use the Lightweight Directory Access Protocol (LDAP) tools to edit the
functional level, click OK to continue. The attributes on the partitions container and on
the domain head are correctly increased. If an error message is report by the Ldp.exe
file, you can safely ignore the error message. To verify that the level increase was
successful, refresh the attribute list, and then check the current setting. This error
message may also occur after you have performed the level increase on the
authoritative FSMO if the change has not yet replicated to the local domain controller.

Quickly view the current settings by using the Ldp.exe file

1. Start the Ldp.exe file.
2. On the Connection menu, click Connect.
3. Specify the domain controller that you want to query, or leave the space blank to
connect to any domain controller.

After you connect to a domain controller, the RootDSE information for the domain
controller appears. This information includes information on the forest, domain, and
domain controllers. The following is an example of a Windows Server 2003-based
domain controller. In the following example, assume that the domain mode is Windows
Server 2003 and that the forest mode is Windows 2000 Server.

７ Note

The domain controller functionality represents the highest possible functional level
for this domain controller.
 1> domainFunctionality: 2=(DS_BEHAVIOR_WIN2003)
1> forestFunctionality: 0=(DS_BEHAVIOR_WIN2000)
1> domainControllerFunctionality: 2=(DS_BEHAVIOR_WIN2003)

Requirements when you manually change the functional

level
You must change the domain mode to native mode before you raise the domain
level if one of the following conditions is true:
The domain functional level is programmatically raised to the second functional
level by directly modifying the value of the msdsBehaviorVersion attribute on
the domainDNS object.
The domain functional level is raised to the second functional level by using the
Ldp.exe utility or the Adsiedit.msc utility.

If you do not change the domain mode to native mode before you raise the
domain level, the operation is not completed successfully, and you receive the
following error messages:

SV_PROBLEM_WILL_NOT_PERFORM

ERROR_DS_ILLEGAL_MOD_OPERATION

Additionally, the following message is logged in the Directory Services log:

Output

Active Directory could not update the functional level of the following
domain because the domain is in mixed mode.

In this scenario, you can change the domain mode to native mode by using the
Active Directory Users & Computers snap-in, by using the Active Directory
Domains & Trusts UI MMC snap-in, or by programmatically changing the value of
the ntMixedDomain attribute to 0 on the domainDNS object. When this process is
used to raise the domain functional level to 2 (Windows Server 2003), the domain
mode is automatically changed to native mode.

The transition from mixed mode to native mode changes the scope of the Schema
Administrators security group and the Enterprise Administrators security group to
universal groups. When these groups have been changed to universal groups, the
following message is logged in the System log:
 Output

Event Type: Information

Event Source: SAM
Event ID: 16408
Computer:Server Name
Description: "Domain operation mode has been changed to Native Mode.
The change cannot be reversed."

When the Windows Server 2003 administrative tools are used to invoke the
domain functional level, both the ntmixedmode attribute and the
msdsBehaviorVersion attribute are modified in the correct order. However, this
does not always occur. In the following scenario, the native mode is implicitly set
to a value of 0 without changing the scope for the Schema Administrators security
group and the Enterprise Administrators security group to universal:
The msdsBehaviorVersion attribute that controls the domain functional mode is
manually or programmatically set to the value of 2.
The forest functional level is set to 2 by using any method. In this scenario, the
Domain controllers block the transition to the forest functional level until all of
the domains that are in the local area network are configured to native mode
and the required attribute change is made in the security group scopes.

Functional levels relevant to Windows 2000 Server

Windows 2000 Server supports only mixed mode and native mode. Additionally, it only
applies these modes to the domain functionality. The following sections list the
Windows Server 2003 domain modes because these modes affect how Windows NT 4.0
and Windows 2000 Server domains are upgraded.

There are many considerations when raising the operating system level of the domain
controller. These considerations are caused by the storage and replication limitations of
the linked attributes in Windows 2000 Server modes.

Windows 2000 Server mixed (default)

Supported domain controllers: Microsoft Windows NT 4.0, Windows 2000 Server,

Windows Server 2003
Activated features: local and global groups, global catalog support

Windows 2000 Server native

 Supported domain controllers: Windows 2000 Server, Windows Server 2003,
Windows Server 2008, Windows Server 2008 R2
Activated features: group nesting, universal groups, Sid History, converting groups
between security groups and distribution groups, you can raise domain levels by
increasing the forest level settings

Windows Server 2003 interim

Supported domain controllers: Windows NT 4.0, Windows Server 2003
Supported features: There are no domain-wide features activated at this level. All
domains in a forest are automatically raised to this level when the forest level
increases to interim. This mode is only used when you upgrade domain controllers
in Windows NT 4.0 domains to Windows Server 2003 domain controllers.

Windows Server 2003

Supported domain controllers: Windows Server 2003, Windows Server 2008,

Windows Server 2008 R2
Supported features: domain controller rename, logon timestamp attribute updated
and replicated. User password support on the InetOrgPerson objectClass.
Constrained delegation, you can redirect the Users and Computers containers.

Domains that are upgraded from Windows NT 4.0 or created by the promotion of a
Windows Server 2003-based computer operate at the Windows 2000 mixed functional
level. Windows 2000 Server domains maintain their current domain functional level
when Windows 2000 Server domain controllers are upgraded to the Windows Server
2003 operating system. You can raise the domain functional level to either Windows
2000 Server native or Windows Server 2003.

Interim level - upgrade from a Windows NT 4.0 domain

Windows Server 2003 Active Directory permits a special forest and domain functional
level that is named Windows Server 2003 interim. This functional level is provided for
upgrades of existing Windows NT 4.0 domains where one or more Windows NT 4.0
backup domain controllers (BDCs) must function after the upgrade. Windows 2000
Server domain controllers are not supported in this mode. Windows Server 2003 interim
applies to the following scenarios:

Domain upgrades from Windows NT 4.0 to Windows Server 2003.

Windows NT 4.0 BDCs do not upgrade immediately.
 Windows NT 4.0 domains that contain groups with more than 5000 members
(excluding the domain users group).
There are no plans to implement Windows Server2000 domain controllers in the
forest at any time.

Windows Server 2003 interim provides two important enhancements while still
permitting replication to Windows NT 4.0 BDCs:

1. Efficient replication of security groups, and support for more than 5000 members
per group.
2. Improved KCC inter-site topology generator algorithms.

Because of the efficiencies in group replication that is activated in the interim level, the
interim level is the recommended level for all Windows NT 4.0 upgrades. See the "Best
Practices" section of this article for more details.

Setting Windows Server 2003 interim forest functional level

Windows Server 2003 interim can be activated in three different ways. The first two
methods are highly recommended. This is because security groups use linked value
replication (LVR) after the Windows NT 4.0 domain's primary domain controller (PDC)
has been upgraded to a Windows Server 2003 domain controller. The third option is less
highly recommended because membership in security groups uses a single multi-valued
attribute, which may result in replication issues. The ways in which Windows Server 2003
interim can be activated are:

1. During the upgrade.

The option is presented in the Dcpromo installation wizard when you upgrade the
PDC of a Windows NT 4.0 domain that serves as the first domain controller in the
root domain of a new forest.

2. Before you upgrade the Windows NT 4.0 PDC of a Windows NT 4.0 as the first
domain controller of a new domain in an existing forest by manually configuring
the forest functional level by using Lightweight Directory Access Protocol (LDAP)
tools.

Child domains inherit the forest-wide functionality settings from the forest they are
promoted into. Upgrading the PDC of a Windows NT 4.0 domain as a child domain
in an existing Windows Server 2003 forest where interim forest functional levels
had been configured by using the Ldp.exe file or the Adsiedit.msc file permits
security groups to use linked value replication after the operating system version
upgrade.
 3. After the upgrade by using LDAP tools.

Use the last two options when you join an existing Windows Server 2003 forest
during an upgrade. This is a common scenario when an "empty root" domain is in
position. The upgraded domain is joined as a child of the empty root and inherits
the domain setting from the forest.

Best practices
The following section discusses the best practices for increasing functional levels. The
section is broken into two parts. "Preparation Tasks" discusses the work that you must
do before the increase and "Optimal Paths Increase" discusses the motivations and
methods for different level increase scenarios.

To discover Windows NT 4.0 domain controllers, follow these steps:

1. From any Windows Server 2003-based domain controller, open Active Directory
Users and Computers.

2. If the domain controller is not already connected to the appropriate domain,

follow these steps to connect to the appropriate domain:
a. Right-click the current domain object, and then click Connect to domain.
b. In the Domain dialog box, type the DNS name of the domain that you want to
connect to, and then click OK. Or, click Browse to select the domain from the
domain tree, and then click OK.

3. Right-click the domain object, and then click Find.

4. In the Find dialog box, click Custom Search.

5. Click the domain for which you want to change the functional level.

6. Click the Advanced tab.

7. In the Enter LDAP query box, type the following and leave no spaces between any
characters: (&(objectCategory=computer)(operatingSystem Version=4*)
(userAccountControl:1.2.840.113556.1.4.803:=8192))

７ Note

This query is not case sensitive.

8. Click Find Now.

 A list of the computers in the domain that are running Windows NT 4.0 and
functioning as domain controllers appears.

A domain controller may appear in the list for any of the following reasons:

The domain controller is running Windows NT 4.0 and must be upgraded.

The domain controller is upgraded to Windows Server 2003 but the change is not
replicated to the target domain controller.
The domain controller is no longer in service but the computer object of the
domain controller is not removed from the domain.

Before you can change the domain functional level to Windows Server 2003, you must
physically locate any domain controller in the list, determine the current status of the
domain controller, and then either upgrade or remove the domain controller as
appropriate.

７ Note

Unlike the Windows Server 2000 domain controllers, the Windows NT 4.0 domain
controllers do not block a level increase. When you change the domain functional
level, replication to the Windows NT 4.0 domain controllers will stop. However,
when you try to increase to Windows Server 2003 forest level with domains in
Windows Server 2000, the mixed level is blocked. The lack of Windows NT 4.0 BDCs
is implied by meeting the forest level requirement of all domains at Windows
Server 2000 native level or later.

Example: Preparation tasks before the level increase

In this example, the environment is raised from Windows Server 2000 mixed mode to
Windows Server 2003 forest mode.

Inventory the forest for earlier versions of domain controllers.

If an accurate server list is not available, follow these steps:

1. To discover mixed level domains, Windows Server 2000 domain controllers, or

domain controllers with damaged or missing objects, use Active Directory domains
and the Trusts MMC snap-in.
2. In the snap-in, click Raise Forest Functionality, and then click Save As to generate
a detailed report.
3. If no problems were found, the option to increase to Windows Server 2003 forest
level is available from the "Available Forest Functional Levels" drop-down list.
 When you try to raise the forest level, the domain controller objects in the
configuration containers are searched for any domain controllers that do not have
msds-behavior-version set to the desired target level. These are assumed to be
either Windows Server 2000 domain controllers or newer Windows Server domain
controller objects that are damaged.
4. If earlier version domain controllers or domain controllers that have damaged or
missing computer objects were found, they are included in the report. The status
of these domain controllers must be investigated, and the domain controller
representation in Active Directory must be repaired or removed by using the
Ntdsutil file.

For more information, click the following article number to view the article in the
Microsoft Knowledge Base:
216498 How to remove data in active directory after an unsuccessful domain
controller demotion

Verify that End to End replication is working in the forest

To verify that End to End replication is working in the forest, use the Windows Server
2003 or newer version of Repadmin against the Windows Server 2000 or the Windows
Server 2003 domain controllers:

Repadmin/Replsum * /Sort:Delta[/Errorsonly] for initial inventory.

Repadmin/Showrepl * /CSV>showrepl.csv . Import to Excel, and then use the Data-

>Autofilter to identify replication features.

Use replication tools such as Repadmin to verify that forest-wide replication is

working correctly.

Verify the compatibility of all programs or services with the newer Windows Server
domain controllers and with the higher Windows Server domain and forest mode. Use a
lab environment to thoroughly test production programs and services for compatibility
issues. Contact vendors for confirmation of capability.

Prepare a back-out plan that includes of one of the following actions:

Disconnect at least two domain controllers from each domain in the forest.
Create a system state backup of at least two domain controllers from each domain
in the forest.

Before the back-out plan can be used, all domain controllers in the forest must be
decommissioned before the recovery process.
 ７ Note

Level increases cannot be authoritatively restored. This means that all domain
controllers that have replicated the level increase must be decommissioned.

After all the previous domain controllers are decommissioned, bring up the
disconnected domain controllers or restore the domain controllers from the backup.
Remove the metadata from all the other domain controllers, and then repromote them.
This is a difficult process and must be avoided.

Example: How to get from Windows Server 2000 mixed

level to Windows Server 2003 forest level
Increase all domains to Windows Server 2000 native level. After this is completed,
increase the functional level for the forest root domain to Windows Server 2003 forest
level. When the forest level replicates to the PDCs for each domain in the forest, the
domain level is automatically increased to Windows Server 2003 domain level. This
method has the following advantages:

The forest-wide level increase is only performed one time. You do not have to
manually increase each domain in the forest to the Windows Server 2003 domain
functional level.
A check for Windows Server 2000 domain controllers is performed before the level
increase (see preparation steps). The increase is blocked until problem domain
controllers are removed or upgraded. A detailed report can be generated by listing
the blocking domain controllers and providing actionable data.
A check for domains in Windows Server 2000 mixed or Windows Server 2003
interim level is performed. The increase is blocked until the domain levels are
increased to at least Windows Server 2000 native. Interim level domains must be
increased to Windows Server 2003 domain level. A detailed report can be
generated by listing the blocking domains.

Windows NT 4.0 upgrades

Windows NT 4.0 upgrades always use interim level during the upgrade of the PDC
unless Windows Server 2000 domain controllers have been introduced into the forest
the PDC is upgraded into. When interim mode is used during the upgrade of the PDC,
the existing large groups use LVR replication immediately, avoiding the potential
replication issues that are discussed earlier in this article. Use one of the following
methods to get to interim level during the upgrade:
 Select interim level during Dcpromo. This option is only presented when the PDC is
upgraded into a new forest.
Set the forest level of an existing forest to interim, and then join the forest during
the upgrade of the PDC. The upgraded domain inherits the forest setting.
After all the Windows NT 4.0 BDCs are upgraded or removed, each domain must
be transitioned to forest level and can be transitioned to Windows Server 2003
forest mode.

A reason to avoid using interim mode is if there are plans to implement Windows Server
2000 domain controllers after the upgrade, or at any time in the future.

Special consideration for large groups in Windows NT 4.0

In mature Windows NT 4.0 domains, security groups that contain far more than 5000
members may exist. In Windows NT 4.0, when a member of a security group changes,
only the membership single change is replicated to the backup domain controllers. In
Windows Server 2000, group memberships are linked attributes stored in a single multi-
valued attribute of the group object. When a single change is made to the membership
of a group, the whole group is replicated as a single unit. Because the group
membership is replicated as a single unit, there is a potential for updates to group
membership to be "lost" when different members are added or removed at the same
time at different domain controllers. Additionally, the size of this single object may be
more than the buffer used to commit an entry into the database. For more information,
see the "Version Store Issues with Large Groups" section of this article. For these
reasons, the recommended limit for group members is 5000.

The exception to the 5000 member rule is the primary group (by default this is the
"Domain Users" group). The primary group uses a "computed" mechanism based on the
"primarygroupID" of the user to determine membership. The primary group does not
store members as multi-valued linked attributes. If the primary group of the user is
changed to a custom group, their membership in the Domain Users group is written to
the linked attribute for the group and is no longer calculated. The new primary group
Rid is written to "primarygroupID" and the user is removed from the member attribute
of the group.

If the administrator does not select the interim level for the upgrade domain, you must
follow these steps before the upgrade:

1. Inventory all large groups and identify any groups over 5000, except the domain
users group.
2. All groups that have more than 5000 members must be broken into smaller groups
of less than 5000 members.
 3. Locate all Access Control Lists where the large groups were entered and add the
small groups that you created in step 2.Windows Server 2003 interim forest level
relieves administrators from having to discover and reallocate global security
groups with more than 5000 members.

Version store issues with large groups

During long-running operations such as deep searches or commits to a single, large

attribute, Active Directory must make sure that the state of the database is static until
the operation is finished. An example of deep searches or commits to large attributes is
a large group that uses legacy storage.

As updates to the database are continually occurring locally and from replication
partners, Active Directory provides a static state by queuing up all incoming changes
until the long-running operation is finished. As soon as the operation is finished, the
queued changes are applied to the database.

The storage location for these queued changes is referred to as the "version store," and
is approximately 100 megabytes. The size of version store varies and is based on the
physical memory. If a long-running operation does not finish before the version store is
exhausted, the domain controller will stop accepting updates until the long-running
operation and the queued changes are committed. Groups that reach large numbers
(more than 5000 members) put the domain controller at risk of exhausting the version
store as long as the large group is committed.

Windows Server 2003 introduces a new replication mechanism for linked multi-valued
attributes that is called link value replication (LVR). Instead of replicating the whole
group in a single replication operation, LVR addresses this issue by replicating each
group member as a separate replication operation. LVR becomes available when the
forest functional level is raised to Windows Server 2003 interim forest level or to
Windows Server 2003 forest level. In this functional level, LVR is used to replicate groups
among Windows Server 2003 domain controllers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot domain controller
deployment
Article • 02/19/2024

This article covers detailed methodology on troubleshooting domain controller

configuration and deployment.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016

Try our Virtual Agent - It can help you quickly identify and fix common Active

Directory replication issues.

Introduction to troubleshooting

Built-in logs for troubleshooting

The built-in logs are the most important instrument for troubleshooting issues with
domain controller promotion and demotion. All of these logs are enabled and
configured for maximum verbosity by default.

ﾉ Expand table
 Phase Log

Server Manager or - %systemroot%\debug\dcpromoui.log

ADDSDeployment Windows
PowerShell operations - %systemroot%\debug\dcpromoui.log*

Installation/Promotion of the - %systemroot%\debug\dcpromo.log

domain controller
- %systemroot%\debug\dcpromo*.log

- Event Viewer\Windows Logs\System

- Event Viewer\Windows Logs\Application

- Event Viewer\Applications and Services Logs\Directory

Service

- Event Viewer\Applications and Services Logs\File

Replication Service

- Event Viewer\Applications and Services Logs\DFS

Replication

Forest or domain upgrade - %systemroot%\debug\adprep\<datetime>\adprep.log

- %systemroot%\debug\adprep\<datetime>\csv.log

- %systemroot%\debug\adprep\<datetime>\dspecup.log

- %systemroot%\debug\adprep\<datetime>\ldif.log*

Server Manager ADDSDeployment - Event Viewer\Applications and Services

Windows PowerShell deployment Logs\Microsoft\Windows\DirectoryServices-
engine Deployment\Operational

Windows Servicing - %systemroot%\Logs\CBS\*

- %systemroot%\servicing\sessions\sessions.xml

- %systemroot%\winsxs\poqexec.log

- %systemroot%\winsxs\pending.xml

Tools and commands for troubleshooting domain

controller configuration
To troubleshoot issues not explained by the logs, use the following tools as a starting
point:

Dcdiag.exe
Repadmin.exe
 AutoRuns.exe, Task Manager, and MSInfo32.exe
Network Monitor 3.4 (or a third party network capture and analysis tool)

General methodology for troubleshooting domain

controller configuration
1. Did a syntax issue cause the error?
a. Did you mistype or forget to provide an argument to ADDSDeployment
Windows PowerShell? For example, if using ADDSDeployment Windows
PowerShell, did you forget to add required argument -domainname with a valid
name?
b. Examine the Windows PowerShell console output carefully to see exactly why it's
failing to parse the command-line provided.

2. Is the error a prerequisite failure?

a. Many errors that used to appear as fatal promotion results are now prevented by
the prerequisite checker.
b. Examine the text of the prerequisite errors carefully, they provide the necessary
guidance to resolve most issues, as they're controlled scenarios.

3. Is the error in promotion and therefore fatal?

a. Examine the results carefully: many errors have explanations such as bad
passwords, network name resolution, or critical offline domain controllers.

b. Examine the Dcpromoui.log and dcpromo.log for the errors shown in the output,
then work backwards from them to see indications of why the failure occurred.
i. Always compare to a working sample log
ii. Examine the ADPrep logs for errors only if the results indicate a problem
extending the schema or preparing the forest or domain.
iii. Examine the DirectoryServices-Deployment event log for errors only if the
Dcpromoui.log lacks detail or ends arbitrarily due to an unhandled exception
in the configuration process.

c. Examine the Directory Services, System, and Application event logs for other
indicators of a configuration issue. Often, the domain controller promotion is
just a symptom of other network misconfiguration that would affect all
distributed systems.

d. Use dcdiag.exe and repadmin.exe to validate the overall forest health and
indicate subtle misconfigurations that may prevent further domain controller
promotion.
 e. Use AutoRuns.exe, Task Manager, or MSinfo32.exe to examine the computer for
third party software that may be interfering.

Remove third party software (don't disable the software; that doesn't prevent
drivers loading).

f. Install NetMon 3.4 on the computer that fails to promote as well the replication
partner domain controller and analyze the promotion process with double-sided
network captures.
i. Compare this to your working lab environment to understand what a healthy
promotion looks like and where it's failing.
ii. At this point, the errors are likely with the forest objects, nondefault security
changes, or the network, and this new domain controller is a victim of
misconfigurations in DNS, firewalls, host intrusion protection software, or
other outside factors.

Troubleshooting events and error messages

Domain controller promotion and demotion always return a code at the end of operation
and unlike most programs, don't return zero for success. To see the code at the end of a
domain controller configuration, you have several options:

1. When using Server Manager, examine the promotion results in the 10 seconds prior
to automatic reboot.

2. When using ADDSDeployment Windows PowerShell, examine the promotion results

in the 10 seconds prior to automatic reboot. Alternatively, choose not to restart
automatically on completion. You should add the format-list pipeline to make the
output easier to read. For example:

PowerShell

Install-addsdomaincontroller <options> -norebootoncompletion:$true |

format-list

Errors in prerequisite validation and verification don't continue on to a reboot, so

they're visible in all cases. For example:
 3. In any scenario, examine the dcpromo.log and dcpromoui.log.

７ Note

Some of the errors listed below are no longer possible due to operating
system and domain controller configuration changes in later operating
systems. The new ADDSDeployment Windows PowerShell codes also prevents
certain errors, but the dcpromo.exe /unattend does not; this is another
compelling reason to switch all of your current automation from the
deprecated DCPromo to ADDSDeployment Windows PowerShell.

Promotion and demotion success codes

ﾉ Expand table

Error Explanation Note

code

1 Exit, success You still must reboot, this just notes that the automatic
restart flag was removed.

2 Exit, success, need to reboot

3 Exit, success, with a Typically seen when returning the DNS Delegation
noncritical failure warning. If not configuring DNS delegation, use:
 Error Explanation Note
code

-creatednsdelegation:$false .

4 Exit, success, with a Typically seen when returning the DNS Delegation
noncritical failure, need to warning. If not configuring DNS delegation, use:
reboot -creatednsdelegation:$false .

Promotion and demotion failure codes

Promotion and demotion return the following failure message codes. There's also likely
to be an extended error message; always read the entire error carefully, not just the
numeric portion.

ﾉ Expand table

Error Explanation Suggested resolution

code

11 Domain controller promotion is Don't run more than one instance of domain controller
already running promotion at the same time for the same target
computer.

12 User must be administrator Logon as a member of the built-in Administrators

group and ensure you're elevating with UAC.

13 Certification Authority is You can't demote this domain controller, as it's also a
installed Certification Authority. Don't remove the CA before you
carefully inventory its usage. If it's issuing certificates,
removing the role will cause an outage. Running CAs
on domain controllers is discouraged.

14 Running in safe-boot mode Boot the server into normal mode.

15 Role change is in progress or You must restart the server (due to prior configuration
needs reboot changes) before promotion.

16 Running on wrong platform Not likely to get this error.

17 No NTFS 5 drives exist This error isn't possible in Windows Server 2012, which
requires at least the %systemdrive% be formatted with
NTFS.

18 Not enough space in windir Free up space on the %systemdrive% volume using
cleanmgr.exe.

19 Name change pending, needs Reboot the server.

reboot
Error Explanation Suggested resolution
code

20 Computer name is invalid Rename the computer with a valid name.

syntax

21 This domain controller holds Add -demoteoperationmasterrole when using -

FSMO roles, is a GC, and/or is a forceremoval .
DNS server

22 TCP/IP needs to be installed or Verify computer has TCP/IP configured, bound, and
isn't functioning working correctly.

23 DNS client needs to be Set a primary DNS server when adding a new domain
configured first controller to a domain.

24 Supplied credentials are invalid Verify your user name and password is correct.
or missing required elements

25 Domain controller for the Validate DNS client settings, firewall rules.
specified domain couldn't be
located

26 List of domains couldn't be Validate DNS client settings, LDAP functionality, firewall
read from the forest rules.

27 Missing domain name Specify a domain when promoting or demoting.

28 Bad domain name Choose a different, valid DNS domain name when
promoting.

29 Parent domain doesn't exist Verify the parent domain specified when creating a new
child domain or tree domain.

30 Domain not in forest Verify the domain name provided.

31 Child Domain already exists Specify a different domain name.

32 Bad NetBIOS domain name Specify a valid NetBIOS domain name.

33 Path to the IFM files is invalid Validate your path to the Install From Media folder.

34 The IFM database is bad Use the correct Install From Media for this operating
system and role (same operating system version, same
type of domain controller - RODC versus RWDC).

35 Missing SYSKEY The Install from Media is encrypted and you must
provide a valid SYSKEY to use it.

37 Path for NTDS Database or its Change path of Database and Logs to a fixed NTFS
logs is invalid volume, not a mapped drive or UNC path.
Error Explanation Suggested resolution
code

38 Volume doesn't have enough Free up space using cleanmgr.exe, add more disk space,
space for NTDS database or manually clear space by moving unnecessary data
logs elsewhere.

39 Path for SYSVOL is invalid Change path of SYSVOL folder to a fixed NTFS volume,
not a mapped drive or UNC path.

40 Invalid site name Provide a site name that exists.

41 Need to specify a password for Provide a password for the DSRM account, it can't be
safe-mode blank no matter how the password policy is configured.

42 Safe-mode password doesn't Provide a password for the DSRM account that meets
meet criteria (promotion only) the password policy's configured rules.

43 Admin password doesn't meet Provide a password for the local administrator account
criteria (demotion only) that meets the password policy's configured rules.

44 The specified name for the Specify a valid forest root DNS domain name.
forest is invalid

45 A forest with the specified Choose a different forest root DNS domain name.
name already exists

46 The specified name for the tree Specify a valid tree DNS domain name.
is invalid

47 A tree with the specified name Choose a different tree DNS domain name.
already exists

48 The tree name doesn't fit into Choose a different tree DNS domain name.
the forest structure

49 The specified domain doesn't Verify your typed domain name.

exist

50 During demote, last domain Don't specify Last Domain Controller in the Domain ( -
controller was detected even lastdomaincontrollerindomain ) unless it's true. Use -
though it isn't, or last domain ignorelastdcindomainmismatch to override if this is truly
controller was specified, but it the last domain controller and there's phantom domain
isn't controller metadata.

51 App partitions exist on this Specify to Remove Application Partitions ( -

domain controller removeapplicationpartitions ).

52 Required command-line Only seen with dcpromo /unattend , which is deprecated.

argument is missing (that is, an See older documentation.
answer file must be specified
on the command-line)
Error Explanation Suggested resolution
code

53 The promotion/demotion Examine the extended error and logs.

failed, machine must be
rebooted to clean up

54 The promotion/demotion failed Examine the extended error and logs.

55 The promotion/demotion was Examine the extended error and logs.

canceled by the user

56 The promotion/demotion was Examine the extended error and logs.

canceled by the user, machine
must be rebooted to clean up

58 A site name must be specified You must specify a site for an RODC, it will not
during RODC promotion automatically detect one like an RWDC.

59 During demote, this domain Specify that this is the Last DNS Server in the Domain
controller is the last DNS server or use -ignorelastdnsserverfordomain .
for one of its zones

60 A domain controller running Promote at least one Windows Server 2008 or later
Windows Server 2008 or later model writable domain controller.
must be present in the domain
in order to promote RODC

61 You can't install Active Directory Not possible to get this error.
Domain Services with DNS in an
existing domain that doesn't
already host DNS

62 Answer file doesn't have a Only seen with dcpromo /unattend , which is deprecated.
[DCInstall] section See older documentation.

63 Forest functional level is below Raise the forest functional level to at least Windows
windows server 2003 Server 2003 Native. Windows 2000 and Windows NT
4.0 are no longer supported operating systems.

64 Promo failed because Install the AD DS role.

component binary detection
failed

65 Promo failed because Install the AD DS role.

component binary installation
failed

66 Promo failed because operating Examine the extended error and logs; the server is
system detection failed failing to return its operating system version. It's likely
Error Explanation Suggested resolution
code

that the computer will need to be reinstalled, as its

overall health is highly suspect.

68 Replication partner is invalid Use repadmin.exe or the Get-ADReplication\* Windows

PowerShell to validate partner domain controller health.

69 Required Port is already in use Use netstat.exe -anob to locate processes that are
by some other application incorrectly assigned to reserved AD DS ports.

70 The forest root domain Only seen with dcpromo /unattend , which is deprecated.
controller must be a GC See older documentation.

71 DNS server is already installed Don't specify to install DNS ( -installDNS ) if the DNS
service is already installed.

72 Computer is running Remote You can't promote this domain controller, as it's also a
Desktop Services in nonadmin RDS server configured for more than two admin users.
mode Don't remove RDS before you carefully inventory its
usage. If it's being used by applications or end-users,
removal will cause an outage.

73 The specified forest functional Specify a valid forest functional level.

level is invalid.

74 The specified domain functional Specify a valid domain functional level.

level is invalid.

75 Unable to determine the Validate that the RODC password replication policy
default password replication exists and is accessible.
policy.

76 Specified replicated/non- Validate that you have typed in valid domain and user
replicated security groups are accounts when specifying a password replication policy.
invalid

77 The specified argument is Examine the extended error and logs.

invalid

78 Failed to examine Active Examine the extended error and logs.

Directory Forest

79 RODC can't be promoted Use Windows Server 2012 to prepare the forest or use
because rodcprep has not been adprep.exe /rodcprep .
performed

80 Domainprep has not been Use Windows Server 2012 to prepare the domain or
performed use adprep.exe /domainprep .
Error Explanation Suggested resolution
code

81 Forestprep has not been Use Windows Server 2012 to prepare the forest or use
performed adprep.exe /forestprep .

82 Forest schema mismatch Use Windows Server 2012 to prepare the forest or use
adprep.exe /forestprep .

83 Unsupported SKU Not likely to get this error.

84 Unable to detect a domain Validate that existing domain controllers have correct
controller account user account control attribute set.

85 Unable to select a domain Returned if you specify "Use Existing Account" but
controller account for stage 2 either no account found or there's an error during
account lookup. Ensure you provided the correct RODC
staged account.

86 Need to run stage 2 promotion Returned if you promote an additional domain

controller but an existing account exists and "Allow
Reinstall" wasn't specified.

87 A domain controller account of Rename the computer before promoting, if not trying
conflicting type exists to attach to an unoccupied domain controller. You must
attach to the unoccupied domain controller account
using -useexistingaccount and the correct read-only or
writable argument, depending on account type.

88 The specified server admin isn't You specified an invalid account for RODC admin
valid delegation. Verify that the account specified is a valid
user or group.

89 RID master for the specified Use netdom.exe query fsmo to detect the RID master.
domain is offline. Bring it online and make it accessible to the domain
controller you're promoting.

90 Domain naming master is Use netdom.exe query fsmo to detect the domain
offline. naming master. Bring it online and make it accessible to
the domain controller you're promoting.

91 Failed to detect if the process is Not possible to get this error anymore, the operating
wow64 system is 64-bit.

92 Wow64 process isn't supported Not possible to get this error anymore, the operating
system is 64-bit.

93 Domain controller service isn't Start the AD DS service.

running for nonforceful
demotion
 Error Explanation Suggested resolution
code

94 Local admin password doesn't Provide a nonblank password and ensure that the local
meet requirement: either blank password policy requires a password.
or not required

95 Can't demote last Windows You must first demote all RODCs before you can
Server 2008 or later domain demote all Windows Server 2008 or later writable
controller in the domain where domain controllers.
live RODCs exist

96 Unable to uninstall DS binaries Only seen with dcpromo /unattend , which is deprecated.
See older documentation.

97 Forest functional level version Provide a child domain functional the same or higher
higher than that of the child than the forest functional level.
domain operating system

98 Component binary Only seen with dcpromo /unattend , which is deprecated.

install/uninstall is in progress. See older documentation.

99 Forest functional level is too Raise the forest functional level to at least Windows
low (error is Windows Server Server 2003 native. Windows 2000 and Windows NT 4.0
2012 only) are no longer supported operating systems.

100 Domain functional level is too Raise the domain functional level to at least Windows
low (error is Windows Server Server 2003 native. Windows 2000 and Windows NT 4.0
2012 only) are no longer supported operating systems.

Known issues and common support scenarios

The following are common issues seen during the Windows Server 2012 development
process. All of these issues are "by design" and have either a valid workaround or more
appropriate technique to avoid them in the first place. Many of these behaviors are
identical in Windows Server 2008 R2 and older operating systems, but the rewrite of AD
DS deployment brings heightened sensitivity to issues.

ﾉ Expand table

Issue Demoting a domain controller leaves DNS running with no zones

Symptoms Server still responds to DNS requests but has no zone information

Resolution When removing the AD DS role, also remove the DNS Server role or set the DNS
and Notes Server service to disabled. Remember to point the DNS client to another server
than itself. If using Windows PowerShell, run the following after you demote the
server:
Issue Demoting a domain controller leaves DNS running with no zones

Code - uninstall-windowsfeature dns

or

Code - set-service dns -starttype disabled

stop-service dns

ﾉ Expand table

Issue Promoting a Windows Server 2012 into an existing single-label domain

doesn't configure updatetopleveldomain=1 or allowsinglelabeldnsdomain=1

Symptoms DNS dynamic record registration doesn't occur

Resolution Set these values using the Netlogon and DNS group policies. Microsoft began
and Notes blocking single-label domain creation in Windows Server 2008; you can use ADMT
or the Domain Rename Tool to change to an approved DNS domain structure.

ﾉ Expand table

Issue Demotion of last domain controller in a domain fails if there are pre-created,
unoccupied RODC accounts

Symptoms Demotion fails with message:

Dcpromo.General.54

Active Directory Domain Services couldn't find another Active Directory Domain
Controller to transfer the remaining data in directory partition
CN=Schema,CN=Configuration,DC=corp,DC=contoso,DC=com.

"The format of the specified domain name is invalid."

Resolution Remove any remaining pre-created RODC accounts before demoting a domain,
and Notes using Dsa.msc or Ntdsutil.exe metadata cleanup.

ﾉ Expand table

Issue Automated forest and domain preparation doesn't run GPPREP

Symptoms Cross-domain planning functionality for Group Policy, Resultant Set of Policy (RSOP)
Planning Mode, requires updated file system and Active Directory permissions for
existing GP. Without Gpprep, you can't use RSOP Planning across domains.

Resolution Run adprep.exe /gpprep manually for all domains that weren't previously prepared
and Notes for Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.
Administrators should run GPPrep only once in the history of a domain, not with
every upgrade. It isn't run by automatic adprep because if you have already set
Issue Automated forest and domain preparation doesn't run GPPREP

adequate custom permissions, it would cause all SYSVOL contents to re-replicate on

all domain controllers.

ﾉ Expand table

Issue Install from media fails to verify when pointing to a UNC path

Symptoms Error returned:

Code - Couldn't validate media path. Exception calling "GetDatabaseInfo" with
"2" arguments. The folder isn't valid.

Resolution and You must store IFM files on a local disk, not a remote UNC path. This intentional
Notes block prevents partial server promotion due to a network interruption.

ﾉ Expand table

Issue DNS delegation warning shown twice during domain controller promotion

Symptoms Warning returned twice when promoting using ADDSDeployment Windows

PowerShell:
Code - A delegation for this DNS server can't be created because the
authoritative parent zone can't be found or it doesn't run Windows DNS server.
If you're integrating with an existing DNS infrastructure, you should manually
create a delegation to this DNS server in the parent zone to ensure reliable
name resolution from outside the domain. Otherwise, no action is required.

Resolution Ignore. ADDSDeployment Windows PowerShell shows the warning first during
and Notes prerequisite checking, then again during configuration of the domain controller. If
you don't wish to configure DNS delegation, use argument:
Code - -creatednsdelegation:$false

Don't skip the prerequisite checks in order to suppress this message.

ﾉ Expand table

Issue Specifying UPN or nondomain credentials during configuration returns

misleading errors

Symptoms Server Manager returns error:

Code - Exception calling "DNSOption" with "6" Arguments

ADDSDeployment Windows PowerShell returns error:

Code - Verification of user permissions failed. You must supply the name
of the domain to which this user account belongs.
Issue Specifying UPN or nondomain credentials during configuration returns
misleading errors

Resolution and Ensure you're providing valid domain credentials in the form of <domain>\
Notes <user>.

ﾉ Expand table

Issue Removing the DirectoryServices-DomainController role using Dism.exe leads

to unbootable server

Symptoms If using Dism.exe to remove the AD DS role before demoting a domain controller
gracefully, the server no longer boots normally and shows error:

Code - Status: 0x000000000

Info: An unexpected error has occurred.

Resolution Boot into Directory Services Repair Mode using Shift + F8 . Add the AD DS role
and Notes back, and then forcibly demote the domain controller. Alternatively, restore the
System State from backup. Don't use Dism.exe for AD DS role removal; the utility
has no knowledge of domain controllers.

ﾉ Expand table

Issue Installing a new forest fails when setting forestmode to Win2012

Symptoms Promotion using ADDSDeployment Windows PowerShell returns error:

Code - Test.VerifyDcPromoCore.DCPromo.General.74

Verification of prerequisites for Domain Controller promotion failed. The

specified domain functional level is invalid.

Resolution Don't specify a forest functional mode of Win2012 without also specifying a
and Notes domain functional mode of Win2012. Here's an example that will work without
errors:
Code - -forestmode Win2012 -domainmode Win2012

ﾉ Expand table

Issue Selecting Verify in the Install from Media selection area appears to do
nothing

Symptoms When you specify a path to an IFM folder, selecting the Verify button never
returns a message or appears to do anything.

Resolution The Verify button only returns errors if there are issues. Otherwise, it makes the
and Notes Next button selectable if you have provided an IFM path. You must select Verify
to proceed if you have selected IFM.
 ﾉ Expand table

Issue Demoting with Server Manager doesn't provide feedback until completed.

Symptoms When using Server Manager to remove the AD DS role and demote a domain
controller, there's no ongoing feedback given until the demotion completes or
fails.

Resolution and This is a limitation of Server Manager. For feedback, use ADDSDeployment
Notes Windows PowerShell cmdlet:
Code - Uninstall-addsdomaincontroller

ﾉ Expand table

Issue Install from Media Verify doesn't detect that RODC media provided for
writable domain controller, or vice versa.

Symptoms When promoting a new domain controller using IFM and providing incorrect
media to IFM - such as RODC media for a writable domain controller, or RWDC
media for an RODC - the Verify button doesn't return an error. Later, promotion
fails with error:

Code - An error occurred while trying to configure this machine as a domain

controller.
The Install-From-Media promotion of a Read-Only DC can't start because the
specified source database isn't allowed. Only databases from other RODCs can be
used for IFM promotion of a RODC.

Resolution Verify only validates the overall integrity of IFM. Don't provide the wrong IFM type
and Notes to a server. Restart the server before you attempt promotion again with the
correct media.

ﾉ Expand table

Issue Promoting an RODC into a precreated computer account fails

Symptoms When using ADDSDeployment Windows PowerShell to promote a new RODC with a staged
computer account, receive error:
Code - Parameter set can't be resolved using the specified named parameters.
InvalidArgument: ParameterBindingException
+ FullyQualifiedErrorId :
AmbiguousParameterSet,Microsoft.DirectoryServices.Deployment.PowerShell.Commands.Install

Resolution Don't provide parameters already defined already on a precreated RODC account. These
and Notes include:
Code -
-readonlyreplica
-installdns
-donotconfigureglobalcatalog
Issue Promoting an RODC into a precreated computer account fails

-sitename
-installdns

ﾉ Expand table

Issue Deselecting/selecting "Restart each destination server automatically if

required" does nothing

Symptoms If selecting (or not selecting) the Server Manager option Restart each destination
server automatically if required when demoting a domain controller through role
removal, the server always restarts, regardless of choice.

Resolution This is intentional. The demotion process restarts the server regardless of this
and Notes setting.

ﾉ Expand table

Issue Dcpromo.log shows "[error] setting security on server files failed with 2"

Symptoms Demotion of a domain controller completes without issues, but examination

of the dcpromo log shows error:
Code - [error] setting security on server files failed with 2

Resolution and Ignore, error is expected and cosmetic.

Notes

ﾉ Expand table

Issue Prerequisite adprep check fails with error "Unable to perform Exchange
schema conflict check"

Symptoms When attempting to promote a Windows Server 2012 domain controller into an
existing Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
forest, prerequisite check fails with error:
Code - Verification of prerequisites for AD prep failed. Unable to perform
Exchange schema conflict check for domain <domain name> (Exception: the RPC
server is unavailable)

The adprep.log shows error:

Code - Adprep couldn't retrieve data from the server <domain controller>

through Windows Management Instrumentation (WMI).

Resolution The new domain controller can't access WMI through DCOM/RPC protocols
and Notes against the existing domain controllers. To date, there have been three causes for
this:
Issue Prerequisite adprep check fails with error "Unable to perform Exchange
schema conflict check"

- A firewall rule blocks access to the existing domain controllers.

- The NETWORK SERVICE account is missing from the "Logon as a service"
(SeServiceLogonRight) privilege on the existing domain controllers.
- NTLM is disabled on domain controllers, using security policies described in
Introducing the Restriction of NTLM Authentication.

ﾉ Expand table

Issue Creating a new AD DS forest always shows DNS warning

Symptoms When creating a new AD DS forest and creating the DNS zone on the new
domain controller for itself, you always receive warning message:
Code - An error was detected in the DNS configuration.
None of the DNS servers used by this computer responded within the timeout
interval.
(error code 0x000005B4 "ERROR_TIMEOUT")

Resolution and Ignore. This warning is intentional on the first domain controller in the root
Notes domain of a new forest, in case you intended to point to an existing DNS server
and zone.

ﾉ Expand table

Issue Windows PowerShell -whatif argument returns incorrect DNS server

information

Symptoms If you use the -whatif argument when configuring a domain controller with
implicit or explicit -installdns:$true , the resulting output shows:

Code - DNS Server: No

Resolution and Ignore. DNS is installed and configured correctly.

Notes

ﾉ Expand table

Issue After promotion, logon fails with "Not enough storage is available to process
this command"

Symptoms After you promote a new domain controller and then log off and attempt to log
on interactively, you receive error:
Code - Not enough storage is available to process this command

Resolution The domain controller wasn't rebooted after promotion, either due to an error or
and Notes because you specified the ADDSDeployment Windows PowerShell argument -
Issue After promotion, logon fails with "Not enough storage is available to process
this command"

norebootoncompletion . Restart the domain controller.

ﾉ Expand table

Issue The Next button isn't available on the Domain Controller Options page

Symptoms Even though you have set a password, the Next button on the Domain Controller
Options page in Server Manager isn't available. There's no site listed in the Site
name menu.

Resolution You have multiple AD DS sites and at least one is missing subnets; this future
and Notes domain controller belongs to one of those subnets. You must manually select the
subnet from the Site name dropdown menu. You should also review all AD sites
using DSSITE.MSC or use the following Windows PowerShell command to find all
sites missing subnets:

Code - "get-adreplicationsite -filter * -property subnets | where-object {!$_.subnets

-eq "*"} | format-table name"

ﾉ Expand table

Issue Promotion or demotion fails with message "the service can't be started"

Symptoms If you attempt promotion, demotion, or cloning of a domain controller you receive
error:
Code - The service can't be started, either because it's disabled or it has no
enabled devices associated with it" (0x80070422)

The error may be interactive, an event, or written to a log like dcpromoui.log or

dcpromo.log.

Resolution The DS Role Server service (DsRoleSvc) is disabled. By default, this service is
and Notes installed during AD DS role installation and set to a Manual start type. Don't
disable this service. Set it back to Manual and allow the DS role operations to start
and stop it on demand. This behavior is by design.

ﾉ Expand table

Issue Server Manager still warns that you need to promote DC

Symptoms If you promote a domain controller using the deprecated dcpromo.exe /unattend
or upgrade an existing Windows Server 2008 R2 domain controller in place to
Windows Server 2012, Server Manager still shows the post-deployment
configuration task Promote this server to a domain controller.
Issue Server Manager still warns that you need to promote DC

Resolution select the post-deployment warning link and the message will disappear for good.
and Notes This behavior is cosmetic and expected.

ﾉ Expand table

Issue Server Manager deployment script missing role installation

Symptoms If you promote a domain controller using Server Manager and save the Windows
PowerShell deployment script, it doesn't include the role installation cmdlet and
arguments ( install-windowsfeature -name ad-domain-services -
includemanagementtools ). Without the role, the DC can't be configured.

Resolution Manually add that cmdlet and arguments to any scripts. This behavior is expected
and Notes and by design.

ﾉ Expand table

Issue Server Manager deployment script isn't named PS1

Symptoms If you promote a domain controller using Server Manager and save the Windows
PowerShell deployment script, the file is named with a random temporary name
and not as a PS1 file.

Resolution and Manually rename the file. This behavior is expected and by design.
Notes

ﾉ Expand table

Issue Dcpromo /unattend allows unsupported functional levels

Symptoms If you promote a domain controller using dcpromo /unattend with the following
sample answer file:

Code -

[DCInstall]
NewDomain=Forest

ReplicaOrNewDomain=Domain

NewDomainDNSName=corp.contoso.com

SafeModeAdminPassword=Safepassword@6

DomainNetbiosName=corp

DNSOnNetwork=Yes
Issue Dcpromo /unattend allows unsupported functional levels

AutoConfigDNS=Yes

RebootOnSuccess=NoAndNoPromptEither

RebootOnCompletion=No

DomainLevel=0

ForestLevel=0

Promotion fails with the following errors in the dcpromoui.log:

Code - dcpromoui EA4.5B8 0089 13:31:50.783 Enter

CArgumentsSpec::ValidateArgument DomainLevel

dcpromoui EA4.5B8 008A 13:31:50.783 Value for DomainLevel is 0

dcpromoui EA4.5B8 008B 13:31:50.783 Exit code is 77

dcpromoui EA4.5B8 008C 13:31:50.783 The specified argument is invalid.

dcpromoui EA4.5B8 008D 13:31:50.783 closing log

dcpromoui EA4.5B8 0032 13:31:50.830 Exit code is 77

Level 0 is Windows 2000, which isn't supported in Windows Server 2012.

Resolution Don't use the deprecated dcpromo /unattend and understand that it allows you to
and Notes specify invalid settings that later fail. This behavior is expected and by design.

ﾉ Expand table

Issue Promotion "hangs" at creating NTDS settings object, never completes

Symptoms If you promote a replica DC or RODC, the promotion reaches "creating NTDS
settings object" and never proceeds or completes. The logs stop updating as well.

Resolution This is a known issue caused by providing credentials of the built-in local
and Notes Administrator account with a matching password to the built-in domain
Administrator account. This causes a failure down in the core setup engine that
doesn't error, but instead waits indefinitely (quasi-loop). This is expected - albeit
undesirable - behavior.
To fix the server:

1. Reboot it.

1. In AD, delete that server's member computer account (it will not yet be a DC
account)

2. On that server, forcibly disjoin it from the domain

 Issue Promotion "hangs" at creating NTDS settings object, never completes

3. On that server, remove the AD DS role.

4. Reboot

5. Readd the AD DS role and reattempt promotion, ensuring that you always
provide the <domain>\<admin> formatted credentials to DC promotion and not
just the built-in local administrator account.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADFS 2.0 certificate error: An error
occurred during an attempt to build the
certificate chain
Article • 02/19/2024

This article helps to fix ADFS 2.0 certificate error during an attempt to build the
certificate chain.

Applies to: Windows Server 2012 R2

Original KB number: 3044974

Summary
Most Active Directory Federated Services (AD FS) 2.0 problems belong to one of the
following main categories. This article contains step-by-step instructions to troubleshoot
certificate problems.

Connectivity problems (KB 3044971)

ADFS service problems (KB 3044973)
Certificate problems (KB 3044974)
Authentication problems (KB 3044976)
Claim rules problems (KB 3044977)

Symptoms
This issue starts after an AD FS certificate is changed or replaced.

The program stops accepting the token that is issued by AD FS.

AD FS returns one of the following errors when it receives a signed request or

response, or if it tries to encrypt a token that is to be issued to a Rely Party
Application:
Event ID 316
An error occurred during an attempt to build the certificate chain for the relying
party trust signing certificate.
Event ID 315
An error occurred during an attempt to build the certificate chain for the claims
provider trust signing certificate.
 Event ID 317
An error occurred during an attempt to build the certificate chain for the relying
party trust encryption certificate.

The following certificate-related event IDs are logged in AD FS event log:

Event ID 133
Description: During processing of the Federation Service configuration, the
element 'serviceIdentityToken' was found to have invalid data. The private key
for the certificate that was configured couldn't be accessed. The following are
the values of the certificate:Element: serviceIdentityToken
Event ID 385
AD FS 2.0 detected that one or more certificates in the AD FS 2.0 configuration
database need to be updated manually.
Event ID 381
An error occurred during an attempt to build the certificate chain for
configuration certificate.
Event ID 102
There was an error in enabling endpoints of the Federation Service.
Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
Event ID: 387
AD FS 2.0 detected that one or more of the certificates specified in the
Federation Service were not accessible to the service account used by the AD FS
2.0 Windows Service.
User Action: Ensure that the AD FS service account has read permissions on the
certificate private keys.
Additional Details:
Token-signing certificate with thumbprint 'xxxxxxxx'

Resolution
To resolve this problem, follow these steps in the order given. These steps will help you
to determine the cause of the problem. Make sure that you check whether the problem
is resolved after every step.

Step 1: Check for private keys

Check whether all AD FS certificates (Service communications, token-decrypting, and
token-signing) are valid and have a private key associated with them. Also, make sure
that the certificate is within its validity period.

Where to find the certificates

For Service communications certificates:

1. On the AD FS server, click Start, click Run, type MMC.exe, and then press
Enter.

2. In the Add/Remove Snap-in dialog box, click OK.

3. On the Certificates snap-in screen, click the Computer account certificate

store.
 4. To view the properties of the Service Communications certificate, expand
Certificate (Local Computer), expand Personal, and then click Certificates.

For token-signing and token-decrypting certificates:

If the certificates are self-signed certificates that are added by ADFS server by
default, Logon interactively on the ADFS server using the ADFS Service account,
and check the user's certificate store (certmgr.msc).
If the certificated are from a certificate authority (CA), configured by ADFS
admins post disabling the AutoCertificateRollover, then you should be able to
find it under the ADFS server's certificate store.

Step 2: Make sure that the certificates are not using a

Cryptographic Next Generation (CNG) private key
Certificates that use the CNG private key are not supported for Token Signing and Token
Decryption. If AD FS generated the self-signed certificate, that certificate does not use
CNG. For a certificate that is issued by a CA, make sure that the certificate is not CNG-
based.

If the CA template is using any of the listed cryptographic service providers, the
certificate that is issued by this CA is not supported by the AD FS server.

Step 3: Check whether SSL binding of the Service

communication certificates in IIS is bound to port 443
How to check and fix
1. Start IIS Manager. To do it, click Start, click Administrative Tools, and then click
Internet Information Services (IIS) Manager.

2. Click the server name, and then expand the Sites folder.

3. Locate your website (typically, it is known as "Default Web Site"), and then select it.

4. On the Actions menu on the right side, click Bindings. Make sure that the https
biding type is bound to port 443. Otherwise, click Edit to change the port.

Step 4: Make sure that service communication certificate

is valid, trusted, and passes a revocation check

How to check

1. Open AD FS 2.0 Management.

2. Expand Service, click Certificate, right-click the service communications certificate,

and then click View certificate.

3. In the details pane, click Copy to file, and save the file as Filename.cer.

4. At a command prompt, run the following command to determine whether the

service communication certificate is valid:

Console

Run 'Certutil -verify -urlfetch certificate.CER >

cert_cerification.txt'

5. Open the output file that is created above "cert_verification.txt."

 6. Go to the end of the file, and check whether it includes the following for a
successful revocation test:

Leaf certificate revocation check passed

CertUtil: -verify command completed successfully.

7. If the file indicates that the revocation checks failed or that the revocation server
was offline, check the log to determine which certificate in the certificate chain
could not be verified.

Check whether any AIA or CDP path failed. In a scenario in which multiple paths
are specified under one type of file, both paths should be marked as verified.

---------------- Certificate AIA ----------------

Verified "Certificate (0)" Time: 0
[0.0] http://www.contoso.com/pki/mswww(6).crt

Failed "AIA" Time: 0

Error retrieving URL: The server name or address could not be resolved
0x80072ee7 (WIN32: 12007)
http://corppki/aia/mswww(6).crt

---------------- Certificate CDP ----------------

Verified "Base CRL (5a)" Time: 0
[0.0] http://mscrl.contoso.com/pki/crl/mswww(6).crl

Verified "Base CRL (5a)" Time: 0

[1.0] http://crl.contoso.com/pki/crl/mswww(6).crl

Failed "CDP" Time: 0

Error retrieving URL: The server name or address could not be resolved
0x80072ee7 (WIN32: 12007)
http://corppki/crl/mswww(6).crl

Collecting a network trace may help if any of the AIA or CDP or OCSP path is
unavailable.

8. If the log entry indicates that the certificate is revoked, you must request another
certificate that is valid and is not revoked.

Step 5: Make sure that the ADFS service accounts has the
Read permission for the private key of the ADFS
certificates

How to check the read permission

1. On the AD FS server, click Start, click Run, enter MMC.exe, and then press Enter.

2. In the Add/Remove Snap-in dialog box, click OK.

3. In the Console Root window, click Certificates (Local Computer) to view the
computer certificate stores.

4. Right-click the AD FS service, point to All Tasks, and then click Manage private
keys.

5. Check whether the AD FS account has the Read permission.

Step 6: Check whether ADFS AutoCertificateRollover

feature is enabled for token-signing and token-
decrypting certificates

How to check ADFS AutoCertificateRollover feature

 If AutoCertificateRollover is disabled, the token-signing and token-decrypting
certificates will not be renewed automatically. Before these certificates expire,
make sure that a new certificate is added to the AD FS configuration. Otherwise,
the relying party will not trust the token that is issued by the AD FS server.
If AutoCertificateRollover is enabled, new token-signing and token-decrypting
certificates will be generated 20 days before the expiration of the old certificates.
The new certificates will obtain Primary status five days after they are generated.
After the new set of certificates is generated, make sure that the same information
is updated on the relying party and claim provider trusts.

For more information about the AD FS AutoCertificateRollover feature, see the following
TechNet topics:

AD FS 2.0: How to Enable and Immediately Use AutoCertificateRollover

Step 7: Add the federation service name in the certificate

SAN
If the certificate has the SAN (Subject Alternative Name) attribute enabled, the
federation service name should also be added in the SAN of the certificate, together
with other names. For more information, see SSL Certificate Requirements .

Step 8: Check service account permissions for the (CN=

<GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=
<Domain>,DC=<COM>) certificate sharing container

How to check and fix service account permission

1. On a domain controller (DC), open Adsiedit.msc.

2. Connect to the Default naming context.

3. Locate CN=<GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=

<Domain>,DC=<COM>.

７ Note

In this container name, the parameters in brackets represent the actual values.
An example of a GUID is "62b8a5cb-5d16-4b13-b616-06caea706ada."
 4. Right-click the GUID, and then click Properties. If there is more than one GUID,
follow these steps:

a. Start Windows PowerShell on the server that is running the AD FS service.

b. Run the following command:

PowerShell

Add-PSSnapin microsoft.adfs.powershellGet-ADFSProperties

c. Locate the GUID of the running AD FS service under

CertificateShareingContainer.

5. Make sure that the ADFS service account has the Read, Write, and "Create All child
objects" permissions granted to this object and to all descendent object.

Step 9: Check claims providers and relying parties for

certificate updates
If the token-signing and token-decrypting certificates have changed, make sure that the
claims providers and relying parties are updated to have the new certificates. If the
claims providers and relying parties are not updated, they cannot trust the AD FS
service.

After the change is made, share the Federationmetadata.xml with the claims
provider and the relying party.
The claims provider and the relying party might require only that the new token-
signing and token-decrypting certificates (without a private key) are updated in the
federation trust on their end.

Step 10: Check for a signed request and response from

the claims provider or relying party
The signed request and response might be received by the AD FS server from the claims
provider or the relying party. In this scenario, the AD FS server may check the validity of
the certificate that is used for signing and fail. AD FS also checks the validity of the
certificate that is related to the relying party that is used to send an encrypted token to
the AD FS server.

Scenarios
 AD FS 2.0 receives a signed SAML-P request that is sent by a relying party.

７ Note

Requiring signing of sign-in requests is a configurable option. To set this

requirement for a relying party trust, use the RequireSignedSamlRequests
parameter together with the Set-ADFSRelyingPartyTrust cmdlet.

AD FS 2.0 receives a signed SAML sign-out request from the relying party. In this
scenario, the signout request must be signed.

AD FS 2.0 receives a sign-out request from a claims provider, and encrypts a sign-
out request for the relying party. In this scenario, the claims provider initiates the
sign-out.

AD FS 2.0 issues an encrypted token for a relying party.

AD FS 2.0 receives an issued token from a claims provider.

AD FS 2.0 receives a signed SAML sign-out request from a claims provider. In this
scenario, the signout request must be signed.

What to check to resolve the issue

Make sure that the claims provider trust's signing certificate is valid and has not
been revoked.

Make sure that AD FS 2.0 can access the certificate revocation list if the revocation
setting doesn't specify "none" or a "cache only" setting.

７ Note

You can use Windows PowerShell cmdlets for AD FS 2.0 to configure the
following revocation settings:
SigningCertificateRevocationCheck parameter of the Set-
ADFSClaimsProviderTrust or Set-ADFSRelyingPartyTrust cmdlet
EncryptionCertificateRevocationCheck parameter of the Set-
ADFSRelyingPartyTrust or Set-ADFSClaimsProviderTrust cmdlet

For more information, see Troubleshooting certificate problems with AD FS 2.0.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADFS 2.0 error: 401 The requested
resource requires user authentication
Article • 02/19/2024

This article discusses an issue where you're prompted for credentials and event 111 is
logged when you authenticate an account in Active Directory Federation Services (AD
FS) 2.0.

Applies to: Windows Server 2012 R2

Original KB number: 3044976

Summary
Most Active Directory Federated Services (AD FS) 2.0 problems belong to one of the
following main categories. This article contains step-by-step instructions to troubleshoot
authentication problems.

Connectivity problems (KB 3044971)

ADFS service problems (KB 3044973)
Certificate problems (KB 3044974)
Authentication problems (KB 3044976)
Claim rules problems (KB 3044977)

Symptoms
When you try to authenticate an account in Active Directory Federation Services (AD FS)
2.0, the following errors occur:

The AD FS server returns the following error message:

Not Authorized-HTTP error 401. The requested resource requires user

authentication.

On a form-based login screen, the server returns the following error message:

The user name or password is incorrect.

You're continually prompted for credentials.

Event 111 is logged in the AD FS Admin log, as follows:

 Log Name: AD FS 2.0/Admin
Event ID: 111
Level: Error
Keywords: AD FS
Description:
The Federation Service encountered an error while processing the WS-Trust
request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
Exception details:
Microsoft.IdentityModel.SecurityTokenService.FailedAuthenticationException:
MSIS3019: Authentication failed. --->
System.IdentityModel.Tokens.SecurityTokenValidationException: ID4063:
LogonUser failed for the 'user1' user. Ensure that the user has a valid Windows
account. ---> System.ComponentModel.Win32Exception: Logon failure:
unknown user name or bad password

Resolution
To resolve this problem, follow these steps, in the order given. These steps will help you
determine the cause of the problem.

Step 1: Assign the correct AD FS Federation service name

record
Make sure that the DNS has a HOST (A) record for the AD FS Federation service name,
and avoid using a CNAME record. For more information, see Internet Explorer behaviors
with Kerberos Authentication .

Step 2: Check Federation Service name registration

Locate the Federation Service Name, and check whether the name is registered under
the AD FS service account. To do this, follow these steps:

1. Locate the HOST/<Federation Service Name> name:

a. Open AD FS 2.0 Manager.

b. Right-click ADFS 2.0, and then select Edit Federation Service Properties.

c. On the General tab, locate the Federation Service name field to see the name.
2. Check whether HOST/<Federation Service Name> name is registered under the
AD FS service account:

a. Open the Management snap-in. To do this, click Start, click All Programs, click
Administrative Tools, and then click Services.

b. Double-click AD FS (2.0) Windows Service.

c. On the Log On tab, note the service account that's displayed in the This
account field.
 d. Click Start, click All Programs, click Accessories, right-click Command Prompt,
and then click Run as administrator.

e. Run the following command:

Console

SETSPN -L domain\<ADFS Service Account>

If the Federation Service name doesn't already exist, run the following command to add
the service principal name (SPN) to the AD FS account:

Console

SetSPN -a host/<Federation service name> <username of service account>

Step 3: Check for duplicate SPNs
Verify that there are no duplicate SPNs for the AD FS account name. To do this, follow
these steps:

1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.

2. Run the following command to make sure that there are no duplicate SPNs for the
AD FS account name:

Console

SETSPN -X -F

Step 4: Check whether the browser uses Windows

Integrated Authentication
Make sure that the Internet Explorer browser that you're using is configured to use
Windows Integrated Authentication. To do this, start Internet Explorer, click Settings,
click Internet Options, click Advanced, and then click Enable IntegratedWindows
Authentication.

Step 5: Check the authentication type

Make sure that the default authentication type on the AD FS server is configured
correctly. To do this, follow these steps:

1. In Windows Explorer, navigate to C:\inetpub\adfs\ls (this assumes that inetpub is

located on drive C).
2. Locate Web.config, and then open the file in Notepad.
3. In the file, locate (Ctrl+F) <localAuthenticationTypes>.
4. Under <localAuthenticationTypes>, locate the four lines that represent the local
authentication types.
5. Select and delete your preferred local authentication type (the whole line). Then,
paste the line at the top of the list (under <localAuthenticationTypes>).
6. Save and close the Web.config file.

For more information about the Local Authentication Type, see the following TechNet
topic:

AD FS 2.0: How to Change the Local Authentication Type

Step 6: Check authentication settings
Make sure that the AD FS virtual directories are configured correctly for authentication
in Internet Information Services (IIS).

In the Default Web Site/adfs node, open the Authentication setting, and then
make sure the Anonymous Authentication is enabled.
In the Default Web Site/adfs/ls node, open the Authentication setting, and then
make sure that both Anonymous and Windows Authentication are enabled.

Step 7: Check proxy trust settings

If you have an AD FS proxy server configured, check whether proxy trust is renewed
during the connection intervals between the AD FS and AD FS Proxy servers.

The Proxy server automatically renews trust with AD FS Federation Service. If this
process fails, event 394 is logged in Event Viewer and you receive the following error
message:

The federation server proxy could not renew its trust with the Federation Service.

To resolve this problem, try to run the AD FS proxy configuration wizard again. As the
wizard runs, make sure that valid domain user name and passwords are used. These
credentials aren't stored on the AD FS Proxy server. When entering credentials for the
proxy trust configuration wizard, you have two choices.

Use domain credentials that have local administrative rights on the AD FS servers.
Use the AD FS service account credentials

Step 8: Check IIS extended protection settings

Certain browsers can't authenticate if extended protection (that is, Windows
Authentication) is enabled in IIS as shown in Step 5. Try to disable Windows
Authentication to determine whether this resolves the problem.

You would also see Extended protection not allowing Windows Authentication when SSL
proxy is being done by tools like Fiddler or some intelligent load balancers.

For example: You may see repeated authentication prompts if you have Fiddler Web
Debugger running on the client.

To disable extended protection for authentication, follow the appropriate method,

depending on the client type.
For passive clients
Use this method for the "Default Web Site/adfs/ls" virtual applications on all servers in
the AD FS federation server farm. To do this, follow these steps:

1. Open IIS Manager, and then locate the level that you want to manage.

For more information about how to open IIS Manager, see Open IIS Manager (IIS
7) .

2. In Features View, double-click Authentication.

3. On the Authentication page, select Windows Authentication.

4. In the Actions pane, click Advanced Settings.

5. When the Advanced Settings dialog box appears, click Off on the Extended
Protection menu.

For active clients

Use this method for the primary AD FS server:

1. Start Windows PowerShell.

2. To load the Windows PowerShell for AD FS snap-in, run the following command:

PowerShell

Add-PsSnapIn Microsoft.Adfs.Powershell

3. To disable extended protection for authentication, run the following command:

PowerShell

Set-ADFSProperties -ExtendedProtectionTokenCheck "None"

Step 9: Check the secure channel status between ADFS

server and DCs
Make sure that the secure channel between AD FS and the DCs is good. To do this, run
the following command:

Console
 Nltest /dsgetdc:domainname

If the response is anything other than "success," you must troubleshoot the netlogon
secure channel. To do this, make sure that the following conditions are true:

The domain controller (DC) is reachable

DC names can be resolved
Passwords on the computer and its account on the Active Directory site are in sync.

Step 10: Check for bottlenecks

Check whether you're experiencing authentication-related bottlenecks per the
MaxconcurrentAPI setting on the AD FS server or on the DCs. For more information
about how to check this setting, see the following Knowledge Base article:

How to do performance tuning for NTLM authentication by using the

MaxConcurrentApi setting

Step 11: Check whether the ADFS proxy server is

experiencing congestion
Check whether the ADFS proxy server is throttling connections because it has received
many requests or delayed response from the AD FS server. For more information, see
the following TechNet topic:

AD FS 2.x: Troubleshooting Proxy Server Event ID 230 (Congestion Avoidance Algorithm)

In this scenario, you may note intermittent login failures on ADFS.

Step 12: Check proxy trust settings

If you have an ADFS proxy server configured, check whether proxy trust is renewed
during the connection intervals between the AD FS and AD FS Proxy servers.

The Proxy server automatically renews trust with AD FS Federation Service. If this
process fails, event 394 is logged in Event Viewer and you receive the following error
message:

The federation server proxy could not renew its trust with the Federation Service.
To resolve this problem, try to run the AD FS proxy configuration wizard again. As the
wizard runs, make sure that valid domain user name and passwords are used. These
credentials aren't stored on the AD FS Proxy server.

Step 13: Enable ADFS auditing together with Audit logon

events - success and failure
For more information, see Configuring ADFS Servers for Troubleshooting .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 180 is logged and AD FS
endpoints are missing in Windows
Server 2016
Article • 02/19/2024

This article describes a problem in which Active Directory Federation Services (AD FS)
features such as Device Authentication and OAuth Discovery do not work.

Applies to: Windows Server 2012 R2, Windows Server 2016

Symptoms
You may experience any of the following symptoms:

AD FS-registered endpoints are lost intermittently.

Event ID 180 is logged every five minutes in the AD FS/Admin event log, as follows:

Output

Log Name: AD FS/Admin

Source: AD FS
Event ID: 180
Task Category: None
Level: Error
Keywords: AD FS
Description: An error occurred while upgrading FarmBehaviorLevel
'Max' from Minor Version '0' to Minor Version '3'.
Exception details: Object reference not set to an instance of an
object.

Running the Get-AdfsGlobalAuthenticationPolicy PowerShell cmdlet reveals that

no client authentication methods are set, as shown on the bottom line of the
following output:

PowerShell

Get-AdfsGlobalAuthenticationPolicy

AdditionalAuthenticationProvider : {AzureMfaAuthentication}
DeviceAuthenticationEnabled : True
DeviceAuthenticationMethod : All
TreatDomainJoinedDevicesAsCompliant : False
PrimaryIntranetAuthenticationProvider : {FormsAuthentication,
 WindowsAuthentication, AzurePrimaryAuthentication,
MicrosoftPassportAuthentication}
PrimaryExtranetAuthenticationProvider : {FormsAuthentication,
AzurePrimaryAuthentication, MicrosoftPassportAuthentication}
WindowsIntegratedFallbackEnabled : True
ClientAuthenticationMethods : None

This problem occurs in an AD FS farm that the following conditions apply to:

One or more Windows Server 2016 (WS2016) AD FS servers have been added to a
Windows Server 2012 R2 (WS2012R2) AD FS server farm that has KB 4041685 (or
later Monthly or Preview releases) installed.
The server farm was upgraded to the WS2016 Farm Behavior Level.
The KB 4088787 update was installed on the WS2016 AD FS farm.

Cause
Installing the March 13, 2018, KB 4088787 update on a primary node in an AD FS farm
whose FBL was raised from 1 (WS2012R2) to 3 (WS2016) can cause AD FS regression
and a reordering of rows in the AD FS database. This problem leaves the database in a
state in which some data elements have duplicate occurrences. This state causes AD FS
server start failures and other errors.

Resolution
To resolve this problem, follow these steps.

Step 1: Verify the problem

Determine whether the openid-configuration endpoint can be reached by running the
following command at a PowerShell command prompt:

PowerShell

Get-AdfsEndpoint -AddressPath "/adfs/.well-known/openid-configuration"

If the endpoint is not found, you see the following output that indicates that the
problem likely exists:

Output

Get-AdfsEndpoint : PS0137: No Endpoint found with Address '/adfs/.well-

known/openid-configuration'.
 At line:1 char:1
+ Get-AdfsEndpoint -AddressPath "/adfs/.well-known/openid-configuration ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Get-AdfsEndpoint],
ArgumentException
+ FullyQualifiedErrorId :
PS0137,Microsoft.IdentityServer.Management.Commands.GetEndpointCommand

Step 2: Save the script found at the end of this article as

"KB4088787_Fix.ps1"
The AD FS team has developed a PowerShell script that you can run on an AD FS server
to fix the AD FS configuration settings in the database that is associated with KB
4088787.

This script is found at the end of this article. Save the script as "KB4088787_Fix.ps1" and
copy it to the primary node in your AD FS farm.

Step 3: Back up AD FS configuration databas

Before you run the KB4088787_Fix.ps1 script, it is important that you back up your AD
FS configuration. This AD FS configuration is stored either in the Windows Internal
Database (WID) or in a Microsoft SQL Server database.

If you are using WID to store AD FS configuration, you can use the ADFS Rapid Restore
Tool (available from the Microsoft Download Center ) to back up the configuration
data. If you are using SQL Server to store the AD FS configuration database, you should
create an additional SQL Server backup before you run the script. The database state
can be restored from one of these backups, if it is necessary.

Step 4: Run the script KB4088787_Fix.ps1

In File Explorer, right-click the KB4088787_Fix.ps1 file that you just saved to the primary
node in your AD FS farm, and then select Run with PowerShell.

The script first verifies that the current AD FS server database has been corrupted by the
upgrade problem that is described. If so, the script will locate the broken properties and
fix them. The KB4088787_Fix.ps1 script will ask you to confirm any database changes,
and the script will then restart AD FS if needed.

７ Note
 Every time that the script is run, a copy of the service settings XML is saved. The
data is saved in the working directory in the following name format:

serviceSettingsXml_<yyyy>-<MM>-<dd>-<hh>-<mm>-<ss>.xml

For example, if the script is run on April 14, 2021 at 10:14:53 AM, it is saved as the
following:

serviceSettingsXml_2021-04-14-10-14-53.xml

After the script is finished, and an AD FS restart occurs, all device authentication and
endpoint failures should be fixed.

More information
If applying the script fix and restarting the system does not correct the problem, go to
the Microsoft Support website .

PowerShell Script: KB4088787_Fix.ps1

PowerShell

#
# Version 2.0.0
#

# Helper function - serializes any DataContract object to an XML string

function Get-DataContractSerializedString()
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory = $true, HelpMessage="Any object serializable
with the DataContractSerializer")]
[ValidateNotNull()]
$object
)

$serializer = New-Object
System.Runtime.Serialization.DataContractSerializer($object.GetType())
$serializedData = $null

try
{
# No simple write to string option, so we have to write to a memory
stream
# then read back the bytes...
 $stream = New-Object System.IO.MemoryStream
$writer = New-Object System.Xml.XmlTextWriter($stream,
[System.Text.Encoding]::UTF8)

$null = $serializer.WriteObject($writer, $object);

$null = $writer.Flush();

# Read back the text we wrote to the memory stream

$reader = New-Object System.IO.StreamReader($stream,
[System.Text.Encoding]::UTF8)
$null = $stream.Seek(0, [System.IO.SeekOrigin]::Begin)
$serializedData = $reader.ReadToEnd()
}
finally
{
if ($reader -ne $null)
{
try
{
$reader.Dispose()
}
catch [System.ObjectDisposedException] { }
}

if ($writer -ne $null)

{
try
{
$writer.Dispose()
}
catch [System.ObjectDisposedException] { }
}

if ($stream -ne $null)

{
try
{
$stream.Dispose()
}
catch [System.ObjectDisposedException] { }
}
}

return $serializedData
}

function Write-XmlIndent
{
param
(
$xmlData
)

$strWriter = New-Object System.IO.StringWriter

$xmlWriter = New-Object System.XMl.XmlTextWriter $strWriter
 # Default = None, change Formatting to Indented
$xmlWriter.Formatting = "indented"

# Gets or sets how many IndentChars to write for each level in

# the hierarchy when Formatting is set to Formatting.Indented
$xmlWriter.Indentation = 1

$xmlData.WriteContentTo($xmlWriter)
$xmlWriter.Flush()
$strWriter.Flush()
$strWriter.ToString()
}

function Get-ADFSXMLServiceSettings
{
param
(
$saveData
)

$doc = new-object Xml

$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
)
$connString =
$doc.configuration.'microsoft.identityServer.service'.policystore.connection
String
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cli.Open()
try
{
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = "Select ServiceSettingsData from
[IdentityServerPolicy].[ServiceSettings]"
$cmd.Connection = $cli
$configString = $cmd.ExecuteScalar()
$configXml = new-object XML
$configXml.LoadXml($configString)

if($saveData)
{
$script:originalPath = "original_serviceSettingsXml_$(get-date -
f yyyy-MM-dd-hh-mm-ss).xml"
Write-XmlIndent($configXml) | Out-File $script:originalPath
Write-Host "Original XML saved to: $script:originalPath"
}

write-output $configXml
}
finally
{
$cli.CLose()
}
}

# Gets internal ADFS settings by extracting them Get-AdfsProperties

function Get-AdfsInternalSettings()
{
$settings = Get-AdfsProperties
$settingsType = $settings.GetType()
$propInfo = $settingsType.GetProperty("ServiceSettingsData",
[System.Reflection.BindingFlags]::Instance -bor
[System.Reflection.BindingFlags]::NonPublic)
$internalSettings = $propInfo.GetValue($settings, $null)

return $internalSettings
}

function Set-AdfsInternalSettings()
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory = $true, HelpMessage="Settings object fetched
from Get-AdfsInternalSettings")]
[ValidateNotNull()]
$InternalSettings
)

$settingsData = Get-DataContractSerializedString -object

$InternalSettings

$doc = new-object Xml

$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
)
$connString =
$doc.configuration.'microsoft.identityServer.service'.policystore.connection
String
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cli.Open()
try
{
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = "update [IdentityServerPolicy].[ServiceSettings]
SET ServiceSettingsData=@content,[ServiceSettingsVersion] =
[ServiceSettingsVersion] + 1,[LastUpdateTime] = GETDATE()"
$cmd.Parameters.AddWithValue("@content", $settingsData) | out-null
$cmd.Connection = $cli
$rowsAffected = $cmd.ExecuteNonQuery()

# Update service state table for WID sync if required

if ($connString -match "##wid")
{
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = "UPDATE [IdentityServerPolicy].
[ServiceStateSummary] SET [SerialNumber] = [SerialNumber] + 1,
[LastUpdateTime] = GETDATE() WHERE ServiceObjectType='ServiceSettings'"

$cmd.Connection = $cli
$widRowsAffected = $cmd.ExecuteNonQuery()
}
}
finally
{
$cli.CLose()
}
}

function Create-EndpointConfiguration()
{
Param
(
[ValidateNotNull()]
$xmlData
)

# EndpointConfiguration
$enabled = Create-BoolFromString($xmlData.Enabled)
$proxy = Create-BoolFromString($xmlData.Proxy)
$canProxy = Create-BoolFromString($xmlData.CanProxy)

$endpointConfig = New-Object -TypeName

Microsoft.IdentityServer.PolicyModel.Configuration.EndpointConfiguration -
ArgumentList $xmlData.Address, $enabled ,
([Microsoft.IdentityServer.PolicyModel.Configuration.EndpointMode]
$xmlData.ModeValue), $proxy, $xmlData.Version, $canProxy

return $endpointConfig
}

function Create-ClientSecretSettings()
{
Param
(
[ValidateNotNull()]
$xmlData
)

# ClientSecretSettings
$clientSecretSettings = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Client.ClientSecretSettings
$clientSecretSettings.ClientSecretRolloverTimeMinutes =
$xmlData.ClientSecretRolloverTimeMinutes
$clientSecretSettings.ClientSecretLockoutThreshold =
$xmlData.ClientSecretLockoutThreshold;
$clientSecretSettings.SaltedHashAlgorithm = $xmlData.SaltedHashAlgorithm
$clientSecretSettings.SaltSize = $xmlData.SaltSize
$clientSecretSettings.SecretSize = $xmlData.SecretSize
return $clientSecretSettings
}
function Create-IdTokenIssuer()
{
Param
(
[ValidateNotNull()]
$xmlData
)

#IdTokenIssuer
$idTokenIssuerConfig = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.IdTokenIssuerConfiguratio
n
$idTokenIssuerConfig.Address = $xmlData.Address
return $idTokenIssuerConfig
}

function Create-CertificateAuthorityConfiguration()
{
Param
(
[ValidateNotNull()]
$xmlData
)

# CertificateAuthorityConfiguration
$certAuthorityConfig = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityConfi
guration

$certAuthorityConfig.Mode.Value =
[Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityMode
] $xmlData.ModeValue
$certAuthorityConfig.GenerationThresholdInMinutes =
$xmlData.GenerationThresholdInMinutes
$certAuthorityConfig.PromotionThresholdInMinutes =
$xmlData.PromotionThresholdInMinutes
$certAuthorityConfig.CertificateLifetimeInMinutes =
$xmlData.CertificateLifetimeInMinutes
$certAuthorityConfig.RolloverIntervalInMinutes =
$xmlData.RolloverIntervalInMinutes
$certAuthorityConfig.CriticalThresholdInMinutes =
$xmlData.CriticalThresholdInMinutes

# Create Cert reference

if ($xmlData.PrimaryIssuerCertificate.IsEmpty -ne $true)
{
$certReference = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.CertificateReference
$certReference.IsChainIncluded = Create-
BoolFromString($xmlData.PrimaryIssuerCertificate.IsChainIncluded)
$certReference.IsChainIncludedSpecified = Create-
BoolFromString($xmlData.PrimaryIssuerCertificate.IsChainIncludedSpecified)
$certReference.FindValue =
$xmlData.PrimaryIssuerCertificate.FindValue
$certReference.RawCertificate =
$xmlData.PrimaryIssuerCertificate.RawCertificate
$certReference.EncryptedPfx =
$xmlData.PrimaryIssuerCertificate.EncryptedPfx
$certReference.StoreName.Value =
[System.Security.Cryptography.X509Certificates.StoreName]
$xmlData.PrimaryIssuerCertificate.StoreNameValue
$certReference.StoreLocation.Value =
[System.Security.Cryptography.X509Certificates.StoreLocation]
$xmlData.PrimaryIssuerCertificate.StoreLocationValue
$certReference.X509FindType.Value =
[System.Security.Cryptography.X509Certificates.X509FindType]
$xmlData.PrimaryIssuerCertificate.X509FindTypeValue
$certAuthorityConfig.PrimaryIssuerCertificate = $certReference
}

if ($xmlData.QueuedIssuerCertificate.IsEmpty -ne $true){

# Create PromotionCert
$promotionCert = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.PromotionCertificate
$promotionCert.ObjectId = $xmlData.QueuedIssuerCertificate.ObjectId
$certAuthorityConfig.QueuedIssuerCertificate = $promotionCert
}

$certAuthorityConfig.CriticalThresholdInMinutes =
$xmlData.CriticalThresholdInMinutes

if ($xmlData.CertificateAuthority.IsEmpty -ne $true){

$certAuthorityConfig.CertificateAuthority =
$xmlData.CertificateAuthority
}

if ($xmlData.EnrollmentAgentCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.EnrollmentAgentCertificateTemplateName =
$xmlData.EnrollmentAgentCertificateTemplateName
}

if ($xmlData.LogonCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.LogonCertificateTemplateName =
$xmlData.LogonCertificateTemplateName
}

if ($xmlData.VPNCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.VPNCertificateTemplateName =
$xmlData.VPNCertificateTemplateName
}

if ($xmlData.WindowsHelloCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.WindowsHelloCertificateTemplateName =
$xmlData.WindowsHelloCertificateTemplateName
}
 $certAuthorityConfig.AutoEnrollEnabled = Create-
BoolFromString($xmlData.AutoEnrollEnabled)
$certAuthorityConfig.WindowsHelloCertificateProxyEnabled = Create-
BoolFromString($xmlData.WindowsHelloCertificateProxyEnabled)

return $certAuthorityConfig
}

function Create-OAuthClientAuthenticationMethods()
{
Param
(
[ValidateNotNull()]
$xmlData
)

# OAuthClientAuthenticationMethods
return 15
}

function Create-BoolFromString()
{
Param
(
[ValidateNotNull()]
$xmlData
)

if ($xmlData -eq $null -or $xmlData.ToLower() -eq "false")

{
return 0
}else{
return 1
}
}

function Get-ObjectFromElement()
{
Param
(
[Parameter(Mandatory = $true, HelpMessage="Settings object fetched from
Get-AdfsInternalSettings")]
[ValidateNotNull()]
$xmlData,
[Parameter(Mandatory = $true, HelpMessage="Settings object fetched
from Get-AdfsInternalSettings")]
[ValidateNotNull()]
$elementName
)

$endpointConfigs = "DeviceRegistrationEndpoint", "OAuthJwksEndpoint",

"OAuthDiscoveryEndpoint", "WebFingerEndpoint",
"CertificateAuthorityCrlEndpoint", "UserInfoEndpoint"
#
Microsoft.IdentityServer.PolicyModel.Configuration.EndpointConfiguration

$clientSecretSettings = "ClientSecretSettings"
# Microsoft.IdentityServer.PolicyModel.Client.ClientSecretSettings

$oauthClientAuthMethod = "OAuthClientAuthenticationMethods"
#
Microsoft.IdentityServer.PolicyModel.Configuration.ClientAuthenticationMetho
d

$certAuthorityConfig = "CertificateAuthorityConfiguration"
#
Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityConfi
guration

$idTokenIssuer = "IdTokenIssuer"
#
Microsoft.IdentityServer.PolicyModel.Configuration.IdTokenIssuerConfiguratio
n

$boolObjs = "EnableIdPInitiatedSignonPage", "IgnoreTokenBinding",

"EnableOauthLogout"

$basicObjs = "DeviceUsageWindowInSeconds", "MaxLdapUserNameLength",

"FarmBehaviorMinorVersion", "PromptLoginFederation",
"PromptLoginFallbackAuthenticationType"

if ($endpointConfigs.Contains($elementName))
{
return Create-EndpointConfiguration($xmlData)
}elseif ($clientSecretSettings.Contains($elementName))
{
return Create-ClientSecretSettings($xmlData)
}elseif ($oauthClientAuthMethod.Contains($elementName))
{
return Create-OAuthClientAuthenticationMethods($xmlData)
}elseif ($certAuthorityConfig.Contains($elementName))
{
return Create-CertificateAuthorityConfiguration($xmlData)
}elseif ($idTokenIssuer.Contains($elementName))
{
return Create-IdTokenIssuer($xmlData)
}elseif ($boolObjs.Contains($elementName))
{
return Create-BoolFromString($xmlData)
}else{
return $xmlData
}
}

$role = (Get-AdfsSyncProperties).Role
if($role -ne "PrimaryComputer")
{
Write-Host "This script must execute on the primary node in the AD FS
farm. Cannot continue."
 exit
}

Add-Type -Path ('C:\\Windows\\ADFS\\Microsoft.IdentityServer.dll')

$script:originalPath = $null

# Get the XML of the Service Settings blob, and look for duplicate elements
$xmlData = Get-ADFSXMLServiceSettings($true)
$dataObj = Get-AdfsInternalSettings

if($dataObj.SecurityTokenService.DeviceRegistrationEndpoint.Length -ne 1)
{
if(($xmlData.ServiceSettingsData.SecurityTokenService | Select-Object
"DeviceRegistrationEndpoint").DeviceRegistrationEndpoint.IsEmpty[0] -ne
$True)
{
# In this case, the service settings object is showing an issue, but
the XML data is not.
# This is possible in the case that the sequence of KB applications
has occurred, but no Service Settings write oparation
# has occured.
# To handle this, we will prompt the user to allow us to throttle a
Service Setting to force a write operation

# Do a no-op service settings action so that the duplicates are

populated in the database (if issue exists)
$message = "Confirmation required"
$question = "To ensure data detection is possible, we need to
perform an AD FS Properties operation. `nIf you continue, this script will
add 1 minute to the value of 'ProxyTrustTokenLifetime', and then the value
of 'ProxyTrustTokenLifetime' will be returned to its original setting. `nIf
you wish to make a Set-AdfsProperties operation yourself, answer 'No', and
perform the operation yourself. `n`nAre you sure you want to proceed?"

$choices = New-Object
Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescript
ion]
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes'))
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&No'))

$decision = $Host.UI.PromptForChoice($message, $question, $choices,

1)

if ($decision -eq 0) {
$prop = Get-AdfsProperties
$original = $prop.ProxyTrustTokenLifetime
Set-AdfsProperties -ProxyTrustTokenLifetime ($original + 1)
Set-AdfsProperties -ProxyTrustTokenLifetime $original

# Refresh the XML and data obj

$xmlData = Get-ADFSXMLServiceSettings($false)
$dataObj = Get-AdfsInternalSettings
}else{
 Write-Host "We did not perform a service settings operation.
Please make some service settings change by performing a Set-AdfsProperties
command, and try the script again."
}
}
}

if(($xmlData.ServiceSettingsData.SecurityTokenService | Select-Object
"DeviceRegistrationEndpoint").DeviceRegistrationEndpoint.IsEmpty[0] -eq
$True)
{
$possibleDuplicateElements = "DeviceRegistrationEndpoint",
"DeviceUsageWindowInSeconds", "OAuthClientAuthenticationMethods",
"MaxLdapUserNameLength", "EnableIdPInitiatedSignonPage",
"ClientSecretSettings", "OAuthDiscoveryEndpoint", "OAuthJwksEndpoint",
"IdTokenIssuer", "CertificateAuthorityConfiguration", "WebFingerEndpoint",
"CertificateAuthorityCrlEndpoint", "UserInfoEndpoint",
"IgnoreTokenBinding", "FarmBehaviorMinorVersion", "EnableOauthLogout",
"PromptLoginFederation", "PromptLoginFallbackAuthenticationType"

$existingDups = @()
foreach( $dup in $possibleDuplicateElements )
{
$object = $xmlData.ServiceSettingsData.SecurityTokenService |
Select-Object $dup

if( $object.$dup.Count -gt 1 )

{
# We have an element with duplicate values
# Take the last one in the list
$newObj = $object.$dup[$object.$dup.Count - 1]

$savableObj = Get-ObjectFromElement -xmlData $newObj -

elementName $dup

$existingDups += $dup

$dataObj.SecurityTokenService.$dup = $savableObj
}
}

# Write the modified Service Settings data object back to the database
if($existingDups.Count -gt 0)
{
$filename = "modified_serviceSettingsXml_$(get-date -f yyyy-MM-dd-
hh-mm-ss).xml"
$modifiedData = Get-DataContractSerializedString -object $dataObj
Write-XmlIndent([xml]$modifiedData) | Out-File $filename
Write-Host "Modifed XML saved to: $filename"

$message = "Confirmation required"

$question = "We have located duplicate data in Service Settings, and
need to make a modification to the configuration database. `nIf you
continue, the values of some elements will be updated in your database. `nIf
you wish to see the difference, you can compare the following two files from
the working directory: `n`n$script:originalPath `n$filename `n`nAre you sure
you want to proceed?"

$choices = New-Object
Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescript
ion]
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes'))
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&No'))

$decision = $Host.UI.PromptForChoice($message, $question, $choices,

1)
if ($decision -eq 0) {
Write-Host "Performing update to Service Settings"
Set-AdfsInternalSettings -InternalSettings $dataObj
Write-Host "Updated Service Settings`n`n"

Write-Host "The following elements in the service settings data

were modified:`n"
foreach($d in $existingDups)
{
Write-Host $d
}

Write-Host "`nAll nodes in this farm should be restarted. This

script will attempt to restart the current node, but no other nodes."
Write-Host "Please manually restart all nodes in your AD FS
farm.`n`n"

$message = "Confirmation required"

$question = "An AD FS Service restart is required. Proceed with
restart?"

$choices = New-Object
Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescript
ion]
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes'))
$choices.Add((New-Object
Management.Automation.Host.ChoiceDescription -ArgumentList '&No'))

$decision2 = $Host.UI.PromptForChoice($message, $question,

$choices, 1)

if($decision2 -eq 0){

Write-Host "Stopping AD FS"
net stop adfssrv

Write-Host "Starting AD FS"

net start adfssrv
}else{
Write-Host "You chose not to restart AD FS. Please manually
restart AD FS to allow the changes to take effect."
}
 } else {
Write-Host "Cancelling"
}
}else{
Write-Host "No Operations Needed"
}

}else
{
Write-Host "No issues detected. Terminating script."
}

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADFS 2.0 error: This page cannot be
displayed
Article • 02/19/2024

This article provides a solution to an error when you try to access an application on a
website that uses AD FS 2.0.

Applies to: Windows Server 2012 R2

Original KB number: 3044971

Summary
Most Active Directory Federated Services (AD FS) 2.0 problems belong to one of the
following main categories. This article contains step-by-step instructions to troubleshoot
connectivity problems.

ADFS 2.0 service fails to start (KB 3044971)

ADFS service problems (KB 3044973)
Certificate problems (KB 3044974)
Authentication problems (KB 3044976)
Claim rules problems (KB 3044977)

Symptoms
Symptom 1

When you try to access a web application on a website that uses Active Directory
Federation Services (AD FS) 2.0, you receive the following error message:

This page cannot be displayed.

Symptom 2

You can't access the following IDP-initiated sign-on page and AD FS metadata:

https://ADFSServiceName/federationmetadata/2007-06/federationmetadata.xml

https://ADFSServiceName/adfs/ls/idpinitiatedsignon.aspx
Resolution
To resolve this problem, follow these steps in the order. These steps will help you to
determine the cause of the problem. Make sure that you check whether the problem is
resolved after every step.

Step 1: Check whether the client is redirected to the

correct AD FS URL
How to check

1. Start Internet Explorer.

2. Press F12 to open the developer tools window.
3. On the Network tab, select the start button or press Start capturing to
enable network traffic capturing.
4. Browse to the URL of the web application.
5. Examine the network traces to see that the client is redirected to the URL of
the AD FS service for authentication. Make sure that the AD FS service URL is
correct.

In the following screenshot, the first URL is for the web application, and the second
URL is for the AD FS service.
 How to fix

If you're redirected to an incorrect address, you likely have incorrect AD FS

federation settings in your web application. Check these settings to make sure that
the AD FS federation service (SAML service provider) URL is correct.

Step 2: Check whether the AD FS Service name can be

resolved to the correct IP address
How to check

On a client computer and AD FS proxy server (if you've this), use a ping or
nslookup command to determine whether the AD FS service name is resolved to
the correct IP address. Use the following guidelines:

Intranet: The name should resolve to the Internal AD FS server IP or the load
balanced IP of the AD FS server (Internal).

External: The name should resolve to the External/Public IP of the AD FS service.

In this situation, the Public DNS is used to resolve the name. If you notice that
 different public IPs are returned from different computers for the same AD FS
service name, the recent change in the Public DNS may not yet be propagated
across all public DNS servers worldwide. Such a change may require up to 24
hours to be replicated.

） Important

On all AD FS servers, make sure that the AD FS proxy servers can resolve
the name of the AD FS service to the internal AD FS server IP or to the
internal AD FS server's load-balanced IP. The best way to do this is to add
an entry in the HOST file on the AD FS proxy server or to use a split DNS
configuration in a perimeter network (also known as "DMZ," "demilitarized
zone," and "screened subnet").

Example of the nslookup command:

Console

Nslookup sts.contoso.com

How to fix

Check the record for AD FS service name through the DNS server or Internet
service provider (ISP). Make sure that the IP address is correct.

Step 3: Check whether TCP port 443 on the AD FS server

can be accessed
How to check
 Use Telnet or PortQryUI - User Interface for the PortQry Command Line Port
Scanner to query the connectivity of port 443 on the AD FS server. Make sure
that 443 port is listening.

How to fix

If the AD FS server isn't listening on 443 port, follow these steps:

1. Make sure that the AD FS 2.0 Windows Service is started.

2. Check the Windows firewall setting on the AD FS server to make sure that the
TCP 433 port is allowed to make connections.
3. If a load balancer is used ahead of the AD FS services, try to bypass the load-
balancing process to verify that this isn't the cause of the issue. (Load
balancing is a common cause.)

Step 4: Check whether you can use an IdP-initiated sign-

on page to authenticate to ADFS
How to check

Start Internet Explorer, and then browse to the following web address. If you
receive a certificate warning when you try to open this page, select Continue.

http://<YourADFSServiceName>/adfs/ls/idpinitiatedsignon.aspx

７ Note
 In this URL, <YourADFSServiceName> represents the actual AD FS service
name.

Typically, you access a sign-in screen, and then you can sign in by using your
credentials.

How to fix

If you can successfully do Step 1 through Step 3 but you still can't access the web
application, follow these steps:

1. Use another client computer and browser to do the tests. There may an issue
that affects the client.
2. Do the following advanced troubleshooting steps:
3. Collect Fiddler Web Debugger trace and network capture information while
you're accessing the IDPInitiatedsignon page. For more information, see AD
FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation
Passive Sign-In .
4. Collect network traces from the client computer to check whether the SSL
handshake completed successfully, whether there's an encrypted message,
whether you're accessing the correct IP address, and so on. For more
information, see How to enable Schannel event logging in Windows and
Windows Server .
Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

AD FS 2.0 service fails to start
Article • 02/19/2024

This article provides troubleshooting steps for ADFS service configuration and startup
problems.

Applies to: Windows Server 2012 R2

Original KB number: 3044973

Summary
Most of ADFS 2.0 problems belong to one of the following main categories. This article
contains the step-by-step instructions to troubleshoot ADFS service problems.

Connectivity problems
ADFS service problems (KB 3044973)
Certificate problems
Authentication problems
Claim rules problems

Symptoms
The AD FS service does not start.

The AD FS service starts, but the following errors are logged in the AD FS Admin
log after a restart:
Event ID: 220
The Federation Service configuration could not be loaded correctly from the AD
FS configuration database.
Event ID: 352
A SQL Server operation in the AD FS configuration database with connection
string %1 failed.
Event ID: 102
There was an error in enabling endpoints of the Federation Service.

Resolution
To resolve this problem, follow these steps, in the order given. These steps will help you
determine the cause of the problem. Make sure that you check whether the problem is
resolved after every step.
Step 1: Check whether the AD FS service times out during
startup
If the AD FS service times out when it tries to start, you receive the following error
message:

The service did not respond to the start or control request in a timely fashion.

Fix AD FS service times

Change the value data for the ServicesPipeTimeout DWORD value to 60000 in the
Control key. To do this, follow these steps:

1. On the AD FS server, open Registry Editor.

2. Locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

3. Click the Control subkey.

4. Right-click the ServicesPipeTimeout DWORD value, and then click Modify. If there
is no ServicesPipeTimeout value, create it.

5. Click Decimal.

6. Type 60000, and then click OK. For more information about this time-out error, see
AD FS 2.0: The Service Fails to Start: "The service did not respond to the start or
control request in a timely fashion" .

Step 2: Check whether the AD FS configuration database

is running
If you are using Windows Internal Database (WID) as an AD FS configuration
database, open services.msc, and check whether the Windows Internal Database
service is running.

If you are using the SQL Server service as an AD FS configuration database, open
services.msc. Check whether the SQL Server service is running. You can also create
a Test.udl file and populate the connection string to test connectivity to Microsoft
SQL Server.

How to fix
Open Services.msc, and then start the Windows Internal Database service or SQL Server
service.

For an AD FS server that uses SQL Server as configuration database, you must also check
two security settings, as follows:

1. Connect to the server that is running SQL Server by using SQL Management
Studio.

2. Check whether the AD FS 2.0 Windows service identity exists on the SQL Server
console on the Security > Logins node. If it doesn't, add it.

3. Check whether the AD FS 2.0 Windows service identity exists under Databases >
AdfsConfiguration > Security > Users, and that it owns the IdentityServerPolicy
schema. If it doesn't, add it.

Step 3: Check the AD FS Service account

1. Check whether the AD FS service and the IIS AppPool are running under a valid
service account. If you changed the password of the service account, make sure
that the new password is updated in the AD FS service and in the IIS AppPool.

a. Open Services.msc, right-click AD FS 2.0 Service, and then click Properties. On

the Log on tab, make sure that the new AD FS service account is listed in the
This account box.

b. Open IIS Manager, navigate to Application Pools, right-click ADFSAppPool, and

then click Advanced Settings. In Process Model section, make sure that the new
AD FS service account is listed as Identity.

2. Check whether the service account has sufficient permissions in the AD FS

database. You should be concerned about the permission if you have changed the
service account the ADFS is running under.

If you are using SQL Server as configuration server, follow these steps to reset the
permission for service account:

a. At a command prompt, run the following command:

Console

fsconfig.exe /CreateSQLScripts /ServiceAccount <ADFS service

account> /ScriptDestinationFolder <path to create scripts>
 b. Copy the script that you created to the server that is running SQL Server.

c. Run the script on the server.

3. Check whether the service account has read and modify permissions on the (CN=
<GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=<Domain>,DC=
<COM>) Certificate Sharing container.

a. On a domain controller, open ADSIEDIT.msc.

b. Connect to the Default naming context.

c. Navigate to CN=<GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=

<Domain>,DC=<COM>. An example of a GUID is 62b8a5cb-5d16-4b13-b616-
06caea706ada.

d. Right-click the GUID, and then click Properties. If there is more than one GUID,
follow these steps to find the GUID for the server that is running the AD FS
service.

i. On the server that is running the AD FS service, start Windows PowerShell.

ii. Run the following commands:

PowerShell

Add-PSSnapin microsoft.adfs.powershell

Get-ADFSProperties

iii. The GUID is listed under CertificateShareingContainer.

4. Check whether the new service account has the Read permission on the AD FS
service communication certificate's private key.
a. Create a Microsoft Management Console (MMC) by using the Certificates snap-
in that targets the Local Machine certificate store.
b. Expand the MMC, and then select Manage Private Keys.
c. On the Security tab, add the AD FS service account, and grant the Read
permission to this account.

5. Check whether the AD FS Service Principal Name (SPN) HOST/ADFSServiceName

was added under the service account and was removed from the previous account
(in case the service account changed).
a. Right-click Command Prompt, and then click Run as administrator.
b. Type SetSPN -f -q host/ <Federation service name> , and then press Enter.
 In this command, <Federation service name> represents the fully qualified domain
name (FQDN) service name of the AD FS service endpoint. You can find the service
name in the Federation Service Properties dialog box:

To add or remove the SPN from the account, follow these steps:

a. On a domain controller, open ADSIEDIT.msc.

b. Connect to the Default naming context.

c. Expand to CN=Users,CN=Microsoft,CN=Program Data,DC=<Domain>,DC=

<COM>.

d. Locate the service account. Right-click the service account, and then click
Properties.

e. Locate the servicePrincipalName attribute, and then click Edit.

f. Add or remove the AD FS service SPN. Here is an example of an AD FS service

SPN:

HOST/newadfs.contoso.com

6. If you change the password of the service account, make sure that the new
password is updated in the AD FS service and in IIS AD FS AppPool.
 7. Check whether the AD FS service account is in the local Admin group. To avoid any
potential issues, grant the AD FS service account local administrator rights.

Step 4: Update the AD FS service to the latest version

Check whether the following updates are installed. If they are not, install them.

Rollup Update 2 for ADFS 2.0

Rollup update 3 for ADFS 2.0
Update is available to fix several issues after you install security update 2843638 on
an AD FS server

Step 5: Fix an intermittent AD FS service failure

If you encounter an intermittent AD FS service failure, check whether the problem
started after security update 2894844 was applied. In such a situation, AD FS fails and
generates a reference number when it is accessed from an external network or through
a form-based communication.

If the problem did start after security update 2894844 was applied, you may be
experiencing the problem that is described in the Cause 1: The web application is
running in a farm (multi-server environment) section in Resolving view state message
authentication code (MAC) errors .

To fix this problem, set the same static machine key on all the AD FS servers and the AD
FS proxy:

1. In IIS Manager, locate and then open the adfs/ls folder.

2. In the ASP.NET section, click Machine Key.
3. Clear the Automatically generate at runtime and Generate a unique key for each
application check boxes for both the Validation key and the Decryption key.
4. Click Generate Keys.
5. Click Apply.
6. Copy the validation and decryption keys from the first AD FS server, and then
paste these keys to all the other servers.

Step 6: Make sure that the ADFS service communication,

token-signing, and token-decrypting certificates are
configured correctly
For more information, see ADFS 2.0 certificate error: An error occurred during an
attempt to build the certificate chain .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Availability and description of Active
Directory Federation Services 2.0
Article • 02/19/2024

This article provides availability and description of Active Directory Federation Services
2.0.

Applies to: Windows Server 2012 R2

Original KB number: 974408

Introduction
Active Directory Federation Services (AD FS) 2.0 helps IT enable users to collaborate
across organizational boundaries and easily access applications on-premises and in the
cloud. And, AD FS helps maintain application security. Through a claims-based
infrastructure, IT can enable a single sign-on experience for end-users to applications.
Such a claims-based infrastructure does not require a separate account or password,
whether applications are located in partner organizations or hosted in the cloud.

System requirements
To implement AD FS 2.0, the computer must run one of the following Windows
operating systems:

Windows Server 2008 R2 (64-bit):

Datacenter Edition
Enterprise Edition
Standard Edition
Embedded Solution Edition
Small Business Solutions Edition
Small Business Solutions EM Edition
Small Businesses Server Standard Edition
Small Businesses Server Premium Edition
Solutions Premium Edition
Solutions Edition
Solutions EM Edition
Foundation Server Edition
Small Businesses Edition
Essential Additional Edition
 Essential Additional Svc Edition
Essential Management Edition
Essential Management Svc Edition

Windows Server 2008 together with Service Pack 2 (32-bit or 64-bit):

Datacenter Edition
Datacenter without Hyper-V Edition
Enterprise Edition
Enterprise without Hyper-V Edition
Standard Edition
Medium Business Management Edition
Medium Business Messaging Edition
Medium Business Security Edition
Small Business Server Premium Edition
Small Business Server Standard Edition
Small Business Server Prime Edition
Small Businesses Edition
Small Businesses Edition without Hyper-V

To install AD FS 2.0, the following software and hotfixes must be installed. If they are not
installed when AD FS 2.0 is installed, the AD FS 2.0 Setup program installs them
automatically.

The Microsoft .NET Framework 3.5 together with Service Pack 1

７ Note

This software is automatically installed only when the computer is running

Windows Server 2008 R2.

Windows PowerShell

Internet Information Services (IIS) 7

Windows Identity Foundation (WIF)

Software updates and hotfixes

Windows Server 2008 R2

The following hotfix must be installed on computers that are running Windows
Server 2008 R2:
981002 A hotfix rollup is available for Windows Communication Foundation in
 the .NET Framework 3.5 Service Pack 1 for Windows 7 and Windows Server 2008
R2

Windows Server 2008

The following software updates and hotfixes must be installed on computers

that are running Windows Server 2008 SP2:

973917 Description of the update that implements Extended Protection for

Authentication in Internet Information Services (IIS)

Supported languages
AD FS 2.0 is supported in the following languages:

Chinese (Simplified)
Chinese (Traditional)
Czech
Dutch
English
French
German
Hungarian
Italian
Japanese
Korean
Polish
Portuguese (Brazil)
Portuguese (Iberian)
Russian
Spanish
Swedish
Turkish

Download information
The following files are available for download from the Microsoft Download Center:

ﾉ Expand table
 Package name Supported Windows operating system Platform Download file size

AdfsSetup.exe Windows Server 2008 R2 x64 24.04 MB

AdfsSetup.exe Windows Server 2008 SP2 x64 42.64 MB

AdfsSetup.exe Windows Server 2008 SP2 x86 38.66 MB

For more information about how to download Microsoft support files, see How to
obtain Microsoft support files from online services .

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection
software that was available on the date that the file was posted. The file is stored on
security-enhanced servers that help prevent any unauthorized changes to the file.

More information about Active Directory

Federation Services 2.0
For more information about technical details and white papers, see Active Directory
Federation Services 2.0 Overview .

Upgrade information for Windows operating

systems
If you have AD FS 2.0 deployed on a computer that is running Windows Server 2008, AD
FS 2.0 is automatically uninstalled when you upgrade your Windows operating system
to Windows Server 2008 R2. You have to install the AD FS 2.0 installation package for
Windows Server 2008 R2 after you upgrade the Windows operating system.

If you want to preserve the previous configuration data on the federation server and
restore the data after you reinstall AD FS 2.0, follow the steps in the Before you upgrade
Windows and After you upgrade Windows sections.

Before you upgrade Windows

Copy the AD FS service configuration file to a file server on the network before you
upgrade the operating system. And, note the service account that the AD FS 2.0
Windows Service uses. To do this, follow these steps:

1. Locate the following AD FS 2.0 installation folder:

%system drive%\Program Files\Active Directory Federation Service 2.0
 2. Copy the following configuration file to a safe backup location:
Microsoft.IdentityServer.Servicehost.exe.config

3. Click Start, click Run, type services.msc, and then click OK.

4. Right-click AD FS 2.0 Windows Service, and then click Properties.

5. On the Log On tab, note the service account that is used for the AD FS 2.0
Windows Service.

After you upgrade Windows

Reinstall AD FS 2.0, set a registry setting to restore the previous configuration, restore
the service account, and start the appropriate services. To do this, follow these steps.

７ Note

After you finish these steps, the previous installation of AD FS 2.0 that was present
on this federation server before the upgrade is restored.

1. Reinstall AD FS 2.0.

2. Copy the following configuration file that you saved in step 2 of the Before you
upgrade Windows section:
Microsoft.IdentityServer.Servicehost.exe.config

3. Locate the following AD FS 2.0 installation folder, and then copy the file that is
mentioned in step 2 to this location:
%system drive%\Program Files\Active Directory Federation Service 2.0

4. Click Start, click Run, type regedit, and then click OK.

5. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\adfssrv

6. On the Edit menu, point to New, and then click String Value.

7. Type InitialConfigurationCompleted, and then press ENTER.

8. Right-click InitialConfigurationCompleted, and then click Modify.

9. In the Value data box, type TRUE, and then click OK.

10. On the File menu, click Exit to exit Registry Editor.

 11. Click Start, click Run, type services.msc, and then click OK.

12. If you use Windows Internal Database as the AD FS 2.0 configuration database,
follow these steps. Otherwise, bypass step 12, and go to step 13.
a. Right-click Windows Internal Database (MICROSOFT##SSEE), and then click
Properties.
b. On the General tab, if the Service status field does not display Started, click
Start to start the Windows Internal Database service.
c. Click OK.

13. Right-click AD FS 2.0 Windows Service, and then click Properties.

14. On the Log On tab, provide the original backed-up service account name and the
password that is used for the AD FS 2.0 Windows Service.

15. On the General tab, select Automatic in the Startup type box.

16. If the Service status field doesn’t display Started, click Start to start the AD FS 2.0
Windows Service.

17. Click OK.

Privacy statement information

AD FS 2.0 is covered by the following Windows Server privacy statement:

Windows 7 Privacy Statement

Technical revisions
The following table lists significant technical revisions to this article. The revision number
and the last review date in this article might indicate minor editorial revisions or
structural revisions to this article that are not included in the table.

ﾉ Expand table

Date Revision

May 5, 2010 Original publication date

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to change the AD FS 2.0 service
communications certificate after it
expires
Article • 02/19/2024

This article provides the steps to change the Active Directory Federation Services 2.0
service communications certificate.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2921805

Symptoms
A user wants to know how to change the Active Directory Federation Services (AD FS)
2.0 service communications certificate after it expires or for other reasons.

Resolution
Replacing an existing AD FS 2.0 server service certificate is a multistep process.

Step 1
Install the new certificate into the local computer certificate store. To do it, follow these
steps:

1. Select Start, and then select Run.

2. Type MMC.
3. On the File menu, select Add/Remove Snap-in.
4. In the Available snap-ins list, select Certificates, and then select Add. The
Certificates Snap-in Wizard starts.
5. Select Computer account, and then select Next.
6. Select Local computer: (the computer this console is running on), and then select
Finish.
7. Select OK.
8. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9. Right-click Certificates, select All Tasks, and then select Import.
Step 2
Add to the AD FS service account the permissions to access the private key of the new
certificate. To do it, follow these steps:

1. With the local computer certificate store still open, select the certificate that was
imported.

2. Right-click the certificate, select All Tasks, and then select Manage Private Keys.

3. Add the account that is running the ADFS Service, and then give the account at
least read permissions.

７ Note

If you do not have the option to manage private keys, you may have to run
the following command:

Console

certutil -repairstore my *

Step 3
Bind the new certificate to the AD FS website by using IIS Manager. To do it, follow these
steps:

1. Open the Internet Information Services (IIS) Manager snap-in.

2. Browse to Default Web Site.
3. Right-click Default Web Site, and then select Edit Bindings.
4. Select HTTPS, and then select Edit.
5. Select the correct certificate under the SSL certificate heading.
6. Select OK, and then select Close.

Step 4
Configure the AD FS Server service to use the new certificate. To do it, follow these
steps:

1. Open AD FS 2.0 Management.

 2. Browse to AD FS 2.0\Service\Certificates.

3. Right-click Certificates, and then select Set Service Communications Certificate.

4. Select the new certificate from the certificate selection UI.

5. Select OK.

７ Note

You may see a dialog box that contains the following message:
The certificate key length is less than 2048 bits. Certificates with key sizes less
than 2048 bits might present a security risk and are not recommended. Do
you want to continue?

After you read the message, select Yes. Another dialog box appears. It contains the
following message:

Ensure that the private key for the chosen certificate is accessible to the service
account for this Federation Service on each server in the farm.

It was already done in step 2. Select OK.

Still need help? Go to Office 365 Community .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of the Extranet Smart
Lockout feature in Windows Server 2016
Article • 02/19/2024

This article describes the Extranet Smart Lockout feature in Windows Server 2016.

Applies to: Windows Server 2016

Original KB number: 4096478

Overview
As of the March 2018 update for Windows Server 2016, Active Directory Federation
Services (AD FS) has a new feature that is namedExtranet Smart Lockout (ESL). In an era
of increased attacks on authentication services, ESL enables AD FS to differentiate
between sign-in attempts from a valid user and sign-ins from what may be an attacker.
As a result, AD FS can lock out attackers while letting valid users continue to use their
accounts. This prevents denial of service for users and protects against targeted attacks
against known user accounts.

The ESL feature is available for AD FS in Windows Server 2016.

How to install and configure ESL

Install updates on all nodes in the farm

First, make sure that all Windows Server 2016 AD FS servers are up to date as of the
March 2018 Windows Updates.

Update artifact database permissions

Extranet smart lockout requires the AD FS service account to have permissions to create
a new table in the AD FS artifact database. Log in to any AD FS server as an AD FS
admin, and then grant this permission by executing the following commands in a
PowerShell Command Prompt window:

PowerShell

$cred= Get-Credential
Update-AdfsArtifactDatabasePermission -Credential$cred
 ７ Note

The $cred placeholder is an account that has AD FS administrator permissions. This

should provide the write permissions to create the table.

The commands above may fail due to lack of sufficient permission because your AD FS
farm is using SQL Server, and the credential provided above does not have admin
permission on your SQL server. In this case, you can configure database permissions
manually in SQL Server Database by running the following command when you're
connected to the AdfsArtifactStore database.

SQL

ALTER AUTHORIZATION ON SCHEMA::[ArtifactStore] TO [db_genevaservice]

Configure ESL
A new parameter that is named ExtranetLockoutMode is added to support ESL. It
contains the following values:

ADPasswordCounter- This is the legacy AD FS "extranet soft lockout" mode, which

does not differentiate based on location. This is the default value.
ADFSSmartLockoutLogOnly- This is Extranet Smart Lockout. Instead of rejecting
authentication requests, AD FS writes admin and audit events.
ADFSSmartLockoutEnforce- This is Extranet Smart Lockout with full support for
blocking unfamiliar requests when thresholds are reached.

We recommend that you first set the lockout provider to log-only for a short period of
time (1 to 3 days) by running the following cmdlet. Review audits (see below for details)
during this period to determine the number of accounts that may potentially be
impacted as well as the frequency of these events. After successful evaluation of the
audits, set the setting to "ADFSSmartLockoutEnforce" mode:

PowerShell

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

In this mode, AD FS performs the analysis but does not block any requests because of
lockout counters. This mode is used to validate that smart lockout is running
successfully before it enables "enforce" mode.
For the new mode to take effect, restart the AD FS service on all nodes in the farm by
running the following command:

PowerShell

Restart-service adfssrv

Set lockout threshold and observation window

There are two key settings for ESL: lockout threshold and observation window.

Lockout threshold setting

Every time that a password-based authentication is successful, AD FS stores the client
IPs as familiar locations in the account activity table.

If password-based authentication fails and the credentials do not come from a familiar
location, the failed authentication count is incremented.

After the number of failed password attempts from unfamiliar locations reaches the
lockout threshold, if password-based authentication from an unfamiliar location fails,
the account is locked out.

７ Note

Lockout continues to apply to familiar locations separately from this new unfamiliar
lockout counter.

The threshold is set by using Set-AdfsProperties .

Example:

PowerShell

Set-AdfsProperties -ExtranetLockoutThreshold 10

Observation window setting

The observation window setting allows an account to automatically unlock after some
time. After the account unlocks, one authentication attempt is allowed. If the
authentication succeeds, the failed authentication count is reset to 0. If it fails, the
system waits for another observation window before the user can try again.

The observation window is set by using Set-AdfsProperties as in the following example

command:

PowerShell

Set-AdfsProperties -ExtranetObservationWindow ( new-timespan -minutes 5 )

Enable lockout
Extranet lockout can be enabled or disabled by using the EnableExtranetLockout
parameter as in the following examples.

To enable lockout, run the following command:

PowerShell

Set-AdfsProperties -EnableExtranetLockout $true

To disable lockout, run the following command:

PowerShell

Set-AdfsProperties -EnableExtranetLockout $false

Enable enforce mode

After you're comfortable with the lockout threshold and observation window, ESL can be
moved to "enforce" mode by using the following PSH cmdlet:

PowerShell

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

For the new mode to take effect, restart the AD FS service on all nodes in the farm by
using the following command:

PowerShell

Restart-service adfssrv
Managing ESL

Manage user account activity

AD FS provides three cmdlets to manage user account activity data. These cmdlets
automatically connect to the node in the farm that holds the master role.

７ Note

This behavior can be overridden by passing the -Server parameter.

Get-ADFSAccountActivity

Read the current account activity for a user account. The cmdlet always
automatically connects to the farm master by using the Account Activity REST
endpoint. Therefore, all data should always be consistent.

PowerShell

Get-ADFSAccountActivity [email protected]

Set-ADFSAccountActivity

Update the account activity for a user account. This can be used to add new
familiar locations or erase state for any account.

PowerShell

Set-ADFSAccountActivity [email protected] -FamiliarLocation "1.2.3.4"

Reset-ADFSAccountLockout

Resets the lockout counter for a user account.

PowerShell

Reset-ADFSAccountLockout [email protected] -Familiar

Troubleshooting
Updating database permissions
If any errors are returned from the Update-AdfsArtifactDatabasePermission cmdlet,
verify the following:

Verification will fail if nodes are on the farm list but are no longer members of the
farm. This can be fixed by running remove-adfsnode <node name> .
Verify that the update is deployed on all nodes in the farm.
Verify that the credentials that are passed to the cmdlet have permission to modify
the owner of the AD FS artifact database schema.

Logging/auditing
When an authentication request is rejected because the account exceeds the lockout
threshold, AD FS will write an ExtranetLockoutEvent to the security audit stream.

Example logged event

An extranet lockout event has occurred. See XML for failure details.
Activity ID: 172332e1-1301-4e56-0e00-0080000000db
Additional Data
XML: <?xml version="1.0" encoding="utf-16"?> <AuditBase
xmlns:xsd=" http://www.w3.org/2001/XMLSchema "
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xsi:type="ExtranetLockoutAudit"> <AuditType>ExtranetLockout</AuditType>
<AuditResult>Failure</AuditResult>
<FailureType>ExtranetLockoutError</FailureType>
<ErrorCode>AccountRestrictedAudit</ErrorCode>
<ContextComponents>
<Component xsi:type="ResourceAuditComponent">
<RelyingParty> http://contoso.com /adfs/services/trust</RelyingParty>
<ClaimsProvider>N/A</ClaimsProvider>
<UserId>TQDFTD\Administrator</UserId>
</Component>
<Component xsi:type="RequestAuditComponent">
<Server>N/A</Server>
<AuthProtocol>WSFederation</AuthProtocol>
<NetworkLocation>Intranet</NetworkLocation>
<IpAddress>4.4.4.4</IpAddress>
<ForwardedIpAddress />
 <ProxyIpAddress>1.2.3.4</ProxyIpAddress>
<NetworkIpAddress>1.2.3.4</NetworkIpAddress>
<ProxyServer>N/A</ProxyServer>
<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36</UserAgentString>
<Endpoint>/adfs/ls</Endpoint>
</Component>
<Component xsi:type="LockoutConfigAuditComponent">
<CurrentBadPasswordCount>5</CurrentBadPasswordCount>
<ConfigBadPasswordCount>5</ConfigBadPasswordCount>
<LastBadAttempt>02/07/2018 21:47:44</LastBadAttempt>
<LockoutWindowConfig>00:30:00</LockoutWindowConfig>
</Component>
</ContextComponents>
</AuditBase>

Uninstall
SQL Server database farms can uninstall the update by using the Settings application
without issue.

WID database farms must follow these steps because of the updated WID database
verification binary:

1. Run the Uninstall psh script that stops the service and drops the account activity
table.

PowerShell

Stop-Service adfssrv -ErrorAction Stop

$doc = new-object Xml

$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.co
nfig")
$connString =
$doc.configuration.'microsoft.identityServer.service'.policystore.conne
ctionString

if ( -not $connString -like "*##wid*" )

{
Write-Error "SQL installs don't require DB updates, skipping DB
table drop"
}
else
{
$connString = "Data
 Source=np:\\.\pipe\microsoft##wid\tsql\query;Initial
Catalog=AdfsArtifactStore;Integrated Security=True"
stop-service adfssrv
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cli.Open()
try
{
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = "IF EXISTS (SELECT * FROM sys.objects WHERE
object_id = OBJECT_ID(N'[ArtifactStore].[AccountActivity]') AND type in
(N'U')) DROP TABLE [ArtifactStore].[AccountActivity]"
$cmd.Connection = $cli
$cmd.ExecuteNonQuery()
}
finally
{
$cli.CLose()
} write-warning "Finish removing the patch using the Settings app
and then restart the complete to complete the uninstall"
}

2. Uninstall the update by using the settings application.

3. Restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Considerations for disabling and
replacing TLS 1.0 in AD FS
Article • 02/19/2024

This article provides guidance and considerations for disabling and replacing TLS 1.0 in
Active Directory Federation Services (AD FS).

Applies to: Windows Server 2012 R2

Original KB number: 3194197

Summary
Many customers are considering the option to disable TLS 1.0 and RC4 protocol in AD
FS, and replace it with TLS 1.1 or a later version. This article discusses problems that can
occur if you disable TLS 1.0, and provides guidance to help you complete the process.

After you disable TLS 1.0 on AD FS or AD FS proxy (WAP) servers, those servers might
experience some of the following symptoms:

Connectivity between an AD FS proxy and an AD FS server fails. This may cause any
of the following conditions:

The proxy configuration fails either in the wizard or by using Windows

PowerShell.

Events ID 422 is logged on AD FS proxies:

Unable to retrieve proxy configuration from the Federation Service.

Proxies cannot forward traffic to AD FS servers, and the following error message
is generated:

Error HTTP 503 - The service is unavailable.

AD FS cannot update the federation metadata of the Relying Party Trusts or Claims
Provider Trusts that are configured.

You receive an HTTP 503 error message:

The service is unavailable. HTTP 503 accessing to Office 365 services for
federated domains.
 You receive an RDP error message:

RDP connectivity lost to the servers.

Cause
This problem occurs if customers disable old protocols by using SChannel registry keys.
For an example of this practice, see the Disable old protocols in the registry section.

Resolution

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

ADFS is developed by using Microsoft .NET Framework. For .NET applications to support
strong cryptography (that is, TLS 1.1 and above), you must first install the updates that
are described in the following security advisory: Microsoft Security Advisory 2960358.

） Important

Customers who are running .NET Framework 3.5 applications on Windows 10 or

.NET Framework 4.5/4.5.1/4.5.2 applications on systems that have the .NET
Framework 4.6 installed must follow the steps that are provided in this advisory to
manually disable RC4 in TLS. For more information, see the Suggested Actions
section of the advisory.

７ Note

Systems that are running the .NET Framework 4.6 only are protected by
default and do not have to be updated.

The additional steps from the security advisory require that you create the
SchUseStrongCrypto registry key, as described in the advisory article.

Examples of subkeys for this new registry key:

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727]
SchUseStrongCrypto=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
SchUseStrongCrypto=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFrame
work\v4.0.30319] SchUseStrongCrypto=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFrame
work\v2.0.50727] SchUseStrongCrypto=dword:00000001

To apply the change, you must restart the following services and applications:
ADFS Service (adfssrv)
Device Registration Service (drs)
Any other .NET application that might be running in the server
The Internet Information Services (IIS) application pool for ADFS (applies
only to ADFS 2.0 and ADFS 2.1)

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

Disable old protocols in the registry

An example of disabling old protocols by using SChannel registry keys would be to
configure the values in registry subkeys in the following list. These disable SSL 3.0, TLS
1.0, and RC4 protocols. Because this situation applies to SChannel, it affects all the
SSL/TLS connections to and from the server.

reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\SSL 3.0" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\SSL 3.0\Client" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\SSL 3.0\Server" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0\Client" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0\Server" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 40/128" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 40/128" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 56/128" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 56/128" /v Enabled /t REG_DWORD /d 00000000
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 128/128" /f
reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\R
C4 128/128" /v Enabled /t REG_DWORD /d 00000000
 ７ Note

You must restart the computer after you change these values.

To verify that a server that's connected to the Internet has successfully disabled old
protocols, you can use any online SSL Test verifier such as Qualys SSL Labs. For more
information, see SSL Server Test .

Alternative solution
As an alternative to using the SchUseStrongCrypto registry key, you can use the
SystemDefaultTlsVersions registry key when you use the .NET Framework 3.5.1.

SystemDefaultTlsVersions is available after you install update 3154518 .

After the registry keys are set, the ADFS service honors SChannel defaults and work.

Known side effects

Here are know side effects.

Client applications can't connect to ADFS server or ADFS

proxy for authentication
When you disable TLS 1.0 and earlier versions on ADFS servers and proxies, the client
applications that are trying to connect to it must support TLS 1.1 or later versions.

This is true, for example, of Android mobile 4.1.1 when you use the Intune Company
Portal application to enroll that device. The Intune application cannot show the ADFS
sign-in page.

This is expected in this Android version because TLS 1.1 is disabled by default.

You can get more details about these potential problems by collecting network traces
on the ADFS server or proxies while you reproduce the connection failure. In this
scenario, you can work with the client OS vendor or application vendor to verify that
newer TLS versions are supported. ADFS cannot update federation metadata.

Scenario 1
 ADFS cannot automatically retrieve the Federationmetadata.xml from the Relying
Party Trusts or Claims Provider Trusts.

When you try to update the XML file manually, you receive the following error
message:

An error occurred during an attempt to read the federation metadata.

Or, you receive the following error message when you use Windows PowerShell:

The underlying connection was closed. An unexpected error occurred on a

receive.

By analyzing the underlying exception more closely, we can see the following
information:

PS C:> Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity

Platform"
Update-AdfsRelyingPartyTrust : The underlying connection was closed: An
unexpected error occurred on a receive.
At line:1 char:1
+ Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity
Platform ... +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Microsoft.Ident...lyingPartyTrust:RelyingPartyTrust)
[Update-AdfsRelyingP artyTrust], WebException
+ FullyQualifiedErrorId : The underlying connection was closed: An unexpected error
occurred on a receive.,Microso
ft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand

PS C:> $error[0] | fl * -f
writeErrorStream : True
PSMessageDetails :
Exception : System.Net.WebException: The underlying connection was closed: An
unexpected error occurred on a receive. --->
System.ComponentModel.Win32Exception: The client and server cannot
communicate, because they do not possess a common algorithm
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule,
String package, CredentialUse intent, SecureCredential scc)
at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse
credUsage, SecureCredential& secureCredential)
at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)
at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32
count, Byte[]& output)
at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset,
Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count,
AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[]
buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext,
ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext,
ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at
Microsoft.IdentityServer.Management.Resources.Managers.RelyingPartyTrustManage
r.ApplyMeta dataFromUrl(RelyingPartyTrust party, Uri metadataUrl, String&
warnings)
at
Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustComman
d.OperateOnRely ingPartyTrust(RelyingPartyTrust party)
at
Microsoft.IdentityServer.Management.Commands.RemoveRelyingPartyTrustComman
d.ProcessRecord()
TargetObject : Microsoft.IdentityServer.Management.Resources.RelyingPartyTrust
CategoryInfo : NotSpecified: (Microsoft.Ident...lyingPartyTrust:RelyingPartyTrust)
[Update-AdfsRelyingPartyTrust], WebException
FullyQualifiedErrorId : The underlying connection was closed: An unexpected error
occurred on a
receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustC
ommand
ErrorDetails : The underlying connection was closed: An unexpected error occurred
 on a receive. InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

When we analyze the network traces, we don't see any ClientHello. Also, the client itself
(ADFS) is closing the connection (TCP FIN) when we would expect it to send the
ClientHello:

3794 <DateTime> 4.0967400 (4588) adfs1 nexus.microsoftonline-p.com.nsatc.net

TCP 8192 TCP: [Bad CheckSum]Flags=CE....S., SrcPort=56156, DstPort=HTTPS(443)
4013 <DateTime> 4.1983176 (0) nexus.microsoftonline-p.com.nsatc.net adfs1 TCP
2097152 TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=56156
4021 <DateTime> 4.1983388 (0) adfs1 nexus.microsoftonline-p.com.nsatc.net TCP
131328 TCP: [Bad CheckSum]Flags=...A...., SrcPort=56156, DstPort=HTTPS(443)
4029 <DateTime> 4.1992083 (4588) adfs1 nexus.microsoftonline-p.com.nsatc.net
TCP 131328 TCP: [Bad CheckSum]Flags=...A...F, SrcPort=56156, DstPort=HTTPS(443)
4057 <DateTime> 4.2999711 (0) nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 0
TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=56156

The reason for this is that the SChannel registry keys were created. These remove
support for SSL 3.0 or TLS 1.0 as a client.

However, the SchUseStrongCrypto key wasn't created. So after we establish the TCP/IP
session, the ClientHello should be sent by having these conditions:

.NET by using weak cryptography (only TLS 1.0 and earlier versions)
SChannel configured to use only TLS 1.1 or later versions

Resolution: Apply SchUseStrongCrypto and reboot.

HTTP 503 in access to Office 365 services

Scenario 2

Only TLS 1.1 and later versions are supported in the ADFS serviceOffice.
You have a O365 federated domain.
The client is accessing some O365 service that is using proxiedauthentication:
Client application sent the credential using HTTP Basic, and the O365 service is
using those credentials in a new connection to ADFS to authenticate the user.
The cloud service sends a TLS 1.0 to ADFS, and ADFS closes the connection.
The client receives a response HTTP 503.
For example, this is true when you access Autodiscover. In this scenario, Outlook clients
are affected. This can be easily reproduced by opening a web browser and going to
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover .

xmlRequest sent:

GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1

Host: autodiscover-s.outlook.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101
Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Authorization: Basic (REMOVED FOR PRIVACY)

Response received from Exchange Online service:

HTTP/1.1 503 Service Unavailable

Cache-Control: private
Retry-After: 30
Server: Microsoft-IIS/8.0
request-id: 33c23dc6-2359-44a5-a819-03f3f8e85aae
X-CalculatedBETarget: db4pr04mb394.eurprd04.prod.outlook.com
X-AutoDiscovery-Error: LiveIdBasicAuth:FederatedStsUnreachable:<X-forwarded-for:
<IP Address>><FederatedSTSFailure>System.Net.WebException: The underlying
connection was closed: An unexpected error occurred on a send.;
X-DiagInfo: DB4PR04MB394
X-BEServer: DB4PR04MB394
X-AspNet-Version: 4.0.30319
Set-Cookie: X-BackEndCookie2=; expires=<DateTime>; path=/Autodiscover; secure;
HttpOnly
Set-Cookie: X-BackEndCookie=; expires=<DateTime>; path=/Autodiscover; secure;
HttpOnly
X-Powered-By: ASP.NET
X-FEServer: AM3PR05CA0056
Date: <DateTime>
Content-Length: 0

Analyzing network traces in the WAP server, we can see several connections coming
from our cloud, as follows. WAP terminates (TCP RST) these connections soon after it
receives the Client Hello.

3282 <DateTime> 10.8024332 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443

(0x1BB) TCP 52 (0x34) 32 8192 TCP:Flags=CE....S., SrcPort=62047,
DstPort=HTTPS(443), PayloadLen=0, Seq=1681718623, Ack=0, Win=8192 (
Negotiating scale factor 0x8 ) = 8192
3285 <DateTime> 10.8025263 (0) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047
(0xF25F) TCP 52 (0x34) 32 8192 TCP: [Bad CheckSum]Flags=.E.A..S.,
SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0, Seq=3949992650,
Ack=1681718624, Win=8192 ( Negotiated scale factor 0x8 ) = 8192
3286 <DateTime> 10.8239153 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443
(0x1BB) TCP 40 (0x28) 20 517 TCP:Flags=...A...., SrcPort=62047, DstPort=HTTPS(443),
PayloadLen=0, Seq=1681718624, Ack=3949992651, Win=517
3293 <DateTime> 10.8244384 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443
(0x1BB) TLS 156 (0x9C) 136 517 TLS:TLS Rec Layer-1 HandShake: Client Hello.
3300 <DateTime> 10.8246757 (4) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047
(0xF25F) TCP 40 (0x28) 20 0 TCP: [Bad CheckSum]Flags=...A.R.., SrcPort=HTTPS(443),
DstPort=62047, PayloadLen=0, Seq=3949992651, Ack=1681718740, Win=0 (scale
factor 0x0) = 0

We also see that Client Hello is using TLS 1.0:

Frame: Number = 3293, Captured Frame Length = 271, MediaType = NetEvent

+ NetEvent:
+ MicrosoftWindowsNDISPacketCapture: Packet Fragment (170 (0xAA) bytes)
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0D-3A-24-43-
98],SourceAddress:[12-34-56-78-9A-BC]
+ Ipv4: Src = <IP Address>, Dest = <IP Address>, Next Protocol = TCP, Packet ID =
31775, Total IP Length = 156
+ Tcp: Flags=...AP..., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=116,
Seq=1681718624 - 1681718740, Ack=3949992651, Win=517
TLSSSLData: Transport Layer Security (TLS) Payload Data
- TLS: TLS Rec Layer-1 HandShake: Client Hello.
- TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
- Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 111 (0x6F)
- SSLHandshake: SSL HandShake ClientHello(0x01)
HandShakeType: ClientHello(0x01)
 Length: 107 (0x6B)
- ClientHello: TLS 1.0
+ Version: TLS 1.0
+ RandomBytes:
SessionIDLength: 0 (0x0)
CipherSuitesLength: 14
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
+ TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
+ TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
+ TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
CompressionMethodsLength: 1 (0x1)
CompressionMethods: 0 (0x0)
ExtensionsLength: 52 (0x34)
- ClientHelloExtension: Server Name(0x0000)
ExtensionType: Server Name(0x0000)
ExtensionLength: 19 (0x13)
NameListLength: 17 (0x11)
NameType: Host Name (0)
NameLength: 14 (0xE)
ServerName: sts.contoso.net
+ ClientHelloExtension: Elliptic Curves(0x000A)
+ ClientHelloExtension: EC Point Formats(0x000B)
+ ClientHelloExtension: SessionTicket TLS(0x0023)
+ ClientHelloExtension: Unknown Extension Type
+ ClientHelloExtension: Renegotiation Info(0xFF01)

In this scenario, it's expected that ADFS proxy is rejecting the connection. This problem
has been reported to Exchange Online team and is under investigation.

Workarounds:

Use Modern Authentication.

７ Note
 This has not been tested. However, conceptually, the connection to ADFS is
directly from the client application. Therefore, it should work if it supports TLS
1.1.

Re-enable TLS 1.0 Server in WAP/ADFS proxy.

References
Payment Card Industry (PCI) Data Security Standard (DSS)

Error While Configuring WAP–"The Underlying Connection Was Closed"–Part 2

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Workplace Join discovery failed" error
with exit code 0x80072EE7
Article • 02/19/2024

This article provides a solution to an error 0x80072EE7 that occurs when users perform a
Workplace Join.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 3045385

７ Note

Home users: This article is intended for use by support agents and IT professionals,
not by home users. For best search results, change your search keywords to include
the product that's triggering the error and the error code.

Symptoms
When users try to perform a Workplace Join, they receive the following error message:

Confirm you are using the current sign-in info, and that your workplace uses this
feature. Also, the connection to your workplace might not be working right now.
Wait and try again.

Additionally, an administrator may see the following event details in Event Viewer:

Event ID: 102

Log Name: Microsoft-Windows-Workplace Join/Admin
Source: Microsoft-Windows-Workplace Join
Level: Error
Description:
Workplace Join discovery failed.

Exit Code: 0x80072EE7.

The server name or address could not be resolved. Could not connect to
https://EnterpriseRegistration.domainTEST.com:443/EnrollmentServer/contract?
api-version=1.0 .
Cause
This problem occurs if one of the following conditions is true:

The currently signed-in user is from a domain that does not contain a DNS record
for the DRS Service.
A user who has a user principal name (UPN) suffix that uses the initial domain (for
example, [email protected]) and who is not yet enabled as the mobile
device management authority through Microsoft Intune for mobile device
management in Office 365 tries to perform a Workplace Join.

Resolution

Verify DNS
To resolve this problem, follow these steps:

1. Verify the EnterpriseRegistration CNAME record for the UPN suffix of the user
account. This is the part after the "@" character, such as in [email protected].

2. Open a Command Prompt window, and then run the following command:

Console

Nslookup enterpriseregistration.domain.com

If you use Microsoft Entra join

Results should return the CNAME result of

EnterpriseRegistration.windows.net.

If you use Windows Server Workplace Join

Internal host should return internal ADFS node.
External host should return external ADFS Proxy (if present).

References
For more troubleshooting information, see the following article in the Microsoft
Knowledge Base:

3045377 Diagnostic logging for troubleshooting Workplace Join issues

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you use the Set-
MsolADFSContext command: The
connection to <ServerName> Active
Directory Federation Services 2.0 server
failed
Article • 03/25/2024

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Original KB number: 2587730

Symptoms
When you run the Set-MsolADFSContext -Computer command in the Microsoft Azure
Active Directory module for Windows PowerShell, you receive the following error:

Set-MsolADFSContext : The connection to <ServerName> Active Directory

Federation Services 2.0 server failed due to invalid credentials.

７ Note

Azure AD Powershell is planned for deprecation on March 30, 2024. To learn more,
read the deprecation update .

We recommend migrating to Microsoft Graph PowerShell to interact with

Microsoft Entra ID (formerly Azure AD). Microsoft Graph PowerShell allows access
to all Microsoft Graph APIs and is available on PowerShell 7. For answers to
common migration queries, see the Migration FAQ.

Cause
This error occurs if Remote PowerShell isn't enabled on the Active Directory Federation
Services (AD FS) federation server that the -computer parameter references.

When a domain is added correctly and verified in the portal, you can use the Azure
Active Directory module for Windows PowerShell to set up single sign-on (SSO) from a
management workstation by using Remote PowerShell.

However, the Azure Active Directory module for Windows PowerShell can only be
installed on Windows 7 and on Windows Server 2008 SR2. The Azure Active Directory
module for Windows PowerShell can't be installed on Windows Server 2008 Service Pack
2 (SP2). Therefore, this problem is especially relevant where AD FS is installed on a
Windows Server 2008 SP2 platform. In this case, the Azure Active Directory module for
Windows PowerShell command that's related to AD FS must be issued from a remote
computer.

Resolution
To enable Remote PowerShell on the AD FS federation server, follow these steps:

1. Start Windows PowerShell as an administrator. To do this, right-click the Windows

PowerShell shortcut, and then select Run As Administrator.

2. To set up Windows PowerShell for remoting, type the following command, and
then press Enter:

PowerShell

Enable-PSRemoting -force

More information
For more information about Remote PowerShell requirements, see
About_Remote_Requirements.

For more information about Remote PowerShell functionality, see Windows PowerShell:
Dive Deep into Remoting.

Still need help? Go to Microsoft Community or the Microsoft Entra Forums website.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you run the Convert-
MsolDomainToStandard cmdlet: Failed
to connect to Active Directory
Federation Services 2.0 on the local
machine
Article • 03/25/2024

This article provides a resolution to resolve an issue where you receive "Failed to
connect to Active Directory Federation Services 2.0 on the local machine" error when
converting a domain from federated to managed using Convert-MsolDomainToStandard
cmdlet.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012
Original KB number: 3018485

７ Note

Azure AD Powershell is planned for deprecation on March 30, 2024. To learn more,
read the deprecation update .

We recommend migrating to Microsoft Graph PowerShell to interact with

Microsoft Entra ID (formerly Azure AD). Microsoft Graph PowerShell allows access
to all Microsoft Graph APIs and is available on PowerShell 7. For answers to
common migration queries, see the Migration FAQ.

Symptoms
When you run the Convert-MsolDomainToStandard cmdlet to convert a domain from
Federated to Managed, you receive the following error message:

Failed to connect to Active Directory Federation Services 2.0 on the local machine.
Please try running Set-MsolADFSContect before running this command again.

Cause
This problem occurs if the server on which you're running the Convert-
MsolDomainToStandard cmdlet is not running Active Directory Federation Services (AD

FS).

Resolution
Do one of the following, as appropriate for your situation:

If AD FS is still running, use the Set-MsolADFSContext cmdlet to specify the server

on which AD FS is running.

For example:

PowerShell

Set-MsolADFSContext -Computer <ServerName>

For more information about the Set-MsolADFSContext cmdlet, see Set-

MsolADFSContext.

If AD FS is not running, use the Set-MsolDomainAuthentication cmdlet to change

the domain to a managed domain.

For example:

PowerShell

Set-MsolDomainAuthentication -DomainName <DomainName> -Authentication

Managed

For more info about the Set-MsolDomainAuthentication cmdlet, see Set-

MsolDomainAuthentication.

More information
Still need help? Go to Microsoft Community or Microsoft Entra Forums website.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
How to restore IIS and clean up Active
Directory when you uninstall Active
Directory Federation Services 2.0
Article • 02/19/2024

This article describes how to restore Internet Information Services (IIS) and clean up
Active Directory when you uninstall Active Directory Federation Services 2.0.

Applies to: Windows Server 2012 R2

Original KB number: 982813

Introduction
The Active Directory Federation Services 2.0(AD FS 2.0) uninstallation wizard uninstalls
AD FS 2.0 from your computer. However, you may still have to manually restore or
cleanup settings in either of the following situations:

When you uninstall AD FS 2.0 from a federation server or federation server proxy
computer, the uninstall wizard doesn't restore IIS to its original state.
When you uninstall AD FS 2.0 from the last added federation server in a federation
server farm, the uninstall process does not delete the certificate sharing container
that was created in Active Directory.

If you run the AD FS 2.0 Federation Server Configuration Wizard after reinstalling AD FS
2.0 but you have not cleaned up the previous AD FS 2.0 configuration from IIS, you may
see one of the following symptoms:

The Configuration Results page may show the component Deploy browser sign-in
Web site listed with status Configuration finished with warnings. When you click
the status you may see the following warning:

Existing Web site detected. Therefore, the Web site was not reinstalled. If you
are trying to redeploy the default AD FS 2.0 Web sites, see
http://go.microsoft.com/fwlink/?LinkId=181110 for details.

The Configuration Results page may show the component Deploy browser sign-in
Web site listed with status Configuring components... when the following error
message is displayed:
 Cannot copy the Web site files to C:\inetpub\adfs\ls because the directory
already exists. Either remove the directory and rerun the configuration wizard,
or update the existing Web site manually.

You can use the following methods to clean up or restore the original configuration:

Restore IIS on a federation server or federation

server proxy computer
When AD FS 2.0 is installed on a computer that is configured for the federation server or
federation server proxy role, it will create the /adfs and /adfs/ls virtual directories in IIS.
AD FS 2.0 will also create a new application pool named ADFSAppPool. When you
uninstall AD FS 2.0 from a federation server or federation server proxy computer, these
virtual directories aren't removed. Additionally, the application pool is not removed. This
can create problems if AD FS 2.0 is installed again on the same computer.

To manually remove these directories from the decommissioned federation server or

federation server proxy computer, follow these steps:

1. Click Start, select Administrative Tools, and then select IIS Manager.

2. Expand the server name node, expand Sites, and then select Default Web Site.

3. In the Actions pane, select View Applications.

７ Note

You should see the following two virtual directories associated with AD FS 2.0:

/adfs
/adfs/ls

4. Right-click the AD FS 2.0 application that is in each virtual directory, and then click
Remove.

5. In the Actions pane, select Application Pools.

７ Note

You should see an application pool named ADFSAppPool.

6. Right-click ADFSAppPool, and then select Remove.

 ７ Note

The next two steps show how to remove the \adfs directory from the
"inetpub" directory. If you have made custom changes to the content within
this directory, we recommend that you back up this content to another
location before removing the directory.

7. In Windows Explorer, browse to the "inetpub" directory. This directory is located in

the following path:
%systemdrive%\inetpub

8. Right-click the Adfs directory, and then click Delete.

Delete the certificate sharing container in

Active Directory
When you install AD FS 2.0 and use the Federation Server Configuration Wizard to
create a new Federation Server in a new Federation Server farm, the wizard will create a
certificate sharing container in Active Directory. This container is used by all the
federation servers in the farm. When you uninstall AD FS 2.0 from the last added
federation server in a farm, this container is not deleted from Active Directory.

To manually delete this container in Active Directory, follow these steps:

1. Before you remove AD FS 2.0 from the last federation server in the farm, run the
following PowerShell commands on the AD FS 2.0 STS to determine the location of
the certificate sharing container in Active Directory:

PowerShell

Add-PsSnapin Microsoft.Adfs.Powershell
Get-AdfsProperties

2. Note the CertificateSharingContainer property in the output from the previous

step.

3. Log on to a server where the ADSIEdit tool (ADSIEdit.msc) is installed.

4. Click Start, click Run, type ADSIEdit.msc, and then press ENTER.

5. In the ADSIEdit tool, connect to the Default naming context by following these
steps:
 a. Right-click ADSI Edit, and then click Connect to.
b. Under Connection Point, click Select a well-known Naming Context, and then
select Default naming context.
c. Click OK.

6. Expand the following node:

Default naming context, {your domain partition}, CN=Program Data,
CN=Microsoft, CN=ADFS

７ Note

Under CN=ADFS, you see a container named CN={GUID} for each AD FS 2.0
farm that you have deployed, where {GUID} matches the
CertificateSharingContainer property that you captured by using the Get-
AdfsProperties PowerShell command in step 1.

7. Right-click the appropriate {GUID} container, and then select Delete.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADFS 2.0 error: Access is denied
Article • 02/19/2024

This article provides a solution to fix the Active Directory Federated Services (AD FS) 2.0
error.

Applies to: Windows Server 2012 R2

Original KB number: 3044977

Summary
Most AD FS 2.0 problems belong to one of the following main categories. This article
contains step-by-step instructions to troubleshoot claims rules problems.

Connectivity problems (KB 3044971)

ADFS service problems (KB 3044973)
Certificate problems (KB 3044974)
Authentication problems (KB 3044976)

Symptoms
The token that is issued by the AD FS service does not have the appropriate claims
to authorize user access to the application.

The AD FS server returns the following error message:

Access is Denied

If you enable AD FS auditing by using the Configuring ADFS Servers for

Troubleshooting topic, you see the following error logged in the event log:

Event ID 325
The Federation Service could not authorize token issuance for the caller.

Resolution
To resolve this problem, follow these steps in the order given. These steps will help you
to determine the cause of the problem. Make sure that you check whether the problem
is resolved after every step.
Step 1: Obtain details about required claims
Determine which claim types are required in the SAML token from the relying party
owner.
Determine which claims provider was used to authenticate the user.

For example:

A relying party provider may indicate that it wants the Email, Name, and Role
values of the user to be provided.

If the claim provider in this situation is "Active Directory," you should configure an
Acceptance claim rule at the "Active Directory" level.

７ Note

If the claim provider is another Security Token Service (STS), we must create a
Pass Through or Transform claim rule to accept the claim values store in
locally defined claims types that are to be passed to the relying party.

Create a Pass Through claim for these claims at the relying party level.

Step 2: Check whether AD FS is denying the token based

on Authorization rules
To do this, right-click the relying party, click Edit Claim Rules, and then click the
Issuance Authorization Rules tab. When you examine the rules information, consider
the following guidelines:

All authorization claims rules are processed.

If no rules are defined, the AD FS server denies all users.
The allowlist approach can also be used instead of using a Permit All rule. In this
situation, you define a set of rules that specify the conditions under which the user
must be issued a token.
In the blocklist approach, you will need one Permit all Rule, along with one or more
Deny rules that are based on a condition.
A Deny rule always overrides an Allow rule. This means that if both the Allow and
Deny claim conditions are true for the user, the Deny rule will be followed.
For authorization rules that are based on other claim values to allow or deny a
token, those claims should already be pushed into the claim pipeline from the
claim provider trust level.
Step 3: Capture a Fiddler trace
Capture a Fiddler Web Debugger trace to capture the communication to the AD FS
service and determine whether a SAML token was issued. If a SAML token was issued,
decode the token to determine whether the correct set of claims is being issued.

For more information about this process, see AD FS 2.0: How to Use Fiddler Web
Debugger to Analyze a WS-Federation Passive Sign-In .

To find the SAML token that is issued by the AD FS service:

In a fiddler trace, review the response from AD FS to determine where the AD FS

service is setting the MSISAuth and MSISAuthenticated cookies. Or, review the
request after AD FS sets the MSISAuth and MSISAuthenticated cookies.
Select the token, and then start TextWizard in Fiddler. Use URLDecode for an RSTR
(WS-Fed) or FromDeflatedSAML for a SAML 2.0 protocol response.

Step 4: Enable ADFS Auditing and to check if the Token

was issued or denied, along with the list of claims being
processed
Configure the AD FS servers to record the auditing of AD FS events to the Security log.
To configure the Windows Security log to support auditing of AD FS events, follow these
steps:

1. Click Start, point to Administrative Tools, and then click Local Security Policy.
2. Double-click Local Policies, and then click Audit Policy.
3. In the details pane, double-click Audit object access.
4. On the Audit object access Properties page, select either Success or Failure or
both, and then click OK.
5. Close the Local Security Settings snap-in.
6. At a command prompt, type gpupdate /force, and then press Enter to immediately
refresh the local policy.

You can also use the following GPO to configure the Windows Security Log:

Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit

Policy Configuration\Audit Policies\Object Access\Audit Application Generated - Success
and Failure Configure ADFS

This is helpful in a scenario in which AD FS denied a token to the user. The AD FS

auditing process will report the event and the claims that were generated before the
token was denied. This helps you determine which claim caused the Deny rule to be
applied. Examine the Security event log particularly for Event ID 299, 500, 501 and 325.

Step 5: Determine whether you require a custom claim

If the claim issuance requirements cannot be fulfilled by the default claim rule
templates, you may need to write a custom claim. For more information, see
Understanding Claim Rule Language in AD FS 2.0 & Higher .

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot AD FS issues in Microsoft
Entra ID and Office 365
Article • 02/19/2024

This article discusses workflow troubleshooting for authentication issues for federated
users in Microsoft Entra ID or Office 365.

Applies to: Windows Server 2012 R2

Original KB number: 3079872

Symptoms
Federated users can't sign in to Office 365 or Microsoft Azure even though
managed cloud-only users who have a domainxx.onmicrosoft.com UPN suffix can
sign in without a problem.
Redirection to Active Directory Federation Services (AD FS) or STS doesn't occur for
a federated user. Or, a "Page cannot be displayed" error is triggered.
You receive a certificate-related warning on a browser when you try to authenticate
with AD FS. Which states that certificate validation fails or that the certificate isn't
trusted.
"Unknown Auth method" error or errors stating that AuthnContext isn't supported.
Also, errors at the AD FS or STS level when you're redirected from Office 365.
AD FS throws an "Access is Denied" error.
AD FS throws an error stating that there's a problem accessing the site; which
includes a reference ID number.
The user is repeatedly prompted for credentials at the AD FS level.
Federated users can't authenticate from an external network or when they use an
application that takes the external network route (Outlook, for example).
Federated users can't sign in after a token-signing certificate is changed on AD FS.
A "Sorry, but we're having trouble signing you in" error is triggered when a
federated user signs in to Office 365 in Microsoft Azure. This error includes error
codes such as 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06,
8004789A, or BAD request.

Troubleshooting workflow
1. Access Microsoft Office Home , and then enter the federated user's sign-in name
([email protected]). After you press Tab to remove the focus from the login
box, check whether the status of the page changes to Redirecting and then you're
redirected to your Active Directory Federation Service (AD FS) for sign-in.

７ Note

Azure AD Powershell is planned for deprecation on March 30, 2024. To learn

more, read the deprecation update .

We recommend migrating to Microsoft Graph PowerShell to interact with

Microsoft Entra ID (formerly Azure AD). Microsoft Graph PowerShell allows
access to all Microsoft Graph APIs and is available on PowerShell 7. For
answers to common migration queries, see the Migration FAQ.

When redirection occurs, you see the following page:

a. If no redirection occurs and you're prompted to enter a password on the same

page, which means that Microsoft Entra ID or Office 365 doesn't recognize the
user or the domain of the user to be federated. To check whether there's a
federation trust between Microsoft Entra ID or Office 365 and your AD FS server,
run the Get-msoldomain cmdlet from Azure AD PowerShell. If a domain is
federated, its authentication property will be displayed as Federated, as in the
following screenshot:

b. If redirection occurs but you aren't redirected to your AD FS server for sign-in,
check whether the AD FS service name resolves to the correct IP and whether it
can connect to that IP on TCP port 443.
 If the domain is displayed as Federated, obtain information about the
federation trust by running the following commands:

PowerShell

Get-MsolFederationProperty -DomainName <domain>

Get-MsolDomainFederationSettings -DomainName <domain>

Check the URI, URL, and certificate of the federation partner that's configured
by Office 365 or Microsoft Entra ID.

2. After you're redirected to AD FS, the browser may throw a certificate trust-related
error, and for some clients and devices it may not let you establish an SSL (Secure
Sockets Layer) session with AD FS. To resolve this issue, follow these steps:

a. Make sure that the AD FS service communication certificate that's presented to

the client is the same one that's configured on AD FS.

Ideally, the AD FS service communication certificate should be the same as the

SSL certificate that's presented to the client when it tries to establish an SSL
tunnel with the AD FS service.

In AD FS 2.0:

Bind the certificate to IIS->default first site.

Use the AD FS snap-in to add the same certificate as the service
communication certificate.

In AD FS 2012 R2:

Use the AD FS snap-in or the Add-adfscertificate command to add a

service communication certificate.
Use the Set-adfssslcertificate command to set the same certificate for
SSL binding.
 b. Make sure that AD FS service communication certificate is trusted by the client.

c. If non-SNI-capable clients are trying to establish an SSL session with AD FS or

WAP 2-12 R2, the attempt may fail. In this case, consider adding a Fallback entry
on the AD FS or WAP servers to support non-SNI clients. For more information,
see How to support non-SNI capable clients with Web Application Proxy and AD
FS 2012 R2 .

3. You may meet an "Unknown Auth method" error or errors stating that
AuthnContext isn't supported at the AD FS or STS level when you're redirected

from Office 365. It's most common when redirect to the AD FS or STS by using a
parameter that enforces an authentication method. To enforce an authentication
method, use one of the following methods:

For WS-Federation, use a WAUTH query string to force a preferred

authentication method.

For SAML2.0, use the following:

XML

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

When the enforced authentication method is sent with an incorrect value, or if that
authentication method isn't supported on AD FS or STS, you receive an error
message before you're authenticated.

The following table shows the authentication type URIs that are recognized by AD
FS for WS-Federation passive authentication.

ﾉ Expand table

Method of authentication wanted wauth URI

User name and password authentication urn:oasis:names:tc:SAML:1.0:am:password

SSL client authentication urn:ietf:rfc:2246

Windows-integrated authentication urn:federation:authentication:windows

Supported SAML authentication context classes

 ﾉ Expand table

Authentication Authentication context class URI

method

User name and urn:oasis:names:tc:SAML:2.0:ac:classes:Password

password

Password protected urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

transport

Transport Layer urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

Security (TLS) client

X.509 certificate urn:oasis:names:tc:SAML:2.0:ac:classes:X509

Integrated Windows urn:federation:authentication:windows

authentication

Kerberos urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

To make sure that the authentication method is supported at AD FS level, check

the following.

AD FS 2.0

Under /adfs/ls/web.config, make sure that the entry for the authentication type is
present.

XML

<microsoft.identityServer.web>
<localAuthenticationTypes>
< add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0: How to change the local authentication type

AD FS 2012 R2

a. Under AD FS Management, select Authentication Policies in the AD FS snap-in.

b. In the Primary Authentication section, select Edit next to Global Settings. You
can also right-click Authentication Policies and then select Edit Global Primary
Authentication. Or, in the Actions pane, select Edit Global Primary
Authentication.
 c. In the Edit Global Authentication Policy window, on the Primary tab, you can
configure settings as part of the global authentication policy. For example, for
primary authentication, you can select available authentication methods under
Extranet and Intranet.

Make sure that the required authentication method check box is selected.

4. If you get to your AD FS and enter you credentials but you cannot be
authenticated, check for the following issues.

a. Active Directory replication issue

If AD replication is broken, changes made to the user or group may not be

synced across domain controllers. Between domain controllers, there may be a
password, UPN, GroupMembership, or Proxyaddress mismatch that affects the
AD FS response (authentication and claims). You should start looking at the
domain controllers on the same site as AD FS. Running a repadmin /showreps or
a DCdiag /v command should reveal whether there's a problem on the domain
controllers that AD FS is most likely to contact.

You can also collect an AD replication summary to make sure that AD changes
are being replicated correctly across all domain controllers. The repadmin
/showrepl * /csv > showrepl.csv output is helpful for checking the replication

status. For more information, see Troubleshooting Active Directory replication

problems.

b. Account locked out or disabled in Active Directory

When an end user is authenticated through AD FS, he or she won't receive an

error message stating that the account is locked or disabled. From AD FS and
Logon auditing, you should be able to determine whether authentication failed
because of an incorrect password, whether the account is disabled or locked,
and so forth.

To enable AD FS and Logon auditing on the AD FS servers, follow these steps:

i. Use local or domain policy to enable success and failure for the following
policies:

Audit logon event, located in Computer configuration\Windows

Settings\Security setting\Local Policy\Audit Policy

Audit Object Access, located in Computer configuration\Windows

Settings\Security setting\Local Policy\Audit Policy
ii. Disable the following policy:

Audit: Force audit policy subcategory settings (Windows Vista or later) to

override audit policy category settings

This policy is located in Computer configuration\Windows Settings\Security

setting\Local Policy\Security Option .

If you want to configure it by using advanced auditing, see Configuring

Computers for Troubleshooting AD FS 2.0.

iii. Configure AD FS for auditing:

i. Open the AD FS 2.0 Management snap-in.

ii. In the Actions pane, select Edit Federation Service Properties.

iii. In the Federation Service Properties dialog box, select the Events tab.

iv. Select the Success audits and Failure audits check boxes.
 v. Run GPupdate /force on the server.

c. Service Principal Name (SPN) is registered incorrectly

There may be duplicate SPNs or an SPN that's registered under an account

other than the AD FS service account. For an AD FS Farm setup, make sure that
SPN HOST/AD FSservicename is added under the service account that's running
the AD FS service. For an AD FS stand-alone setup, where the service is running
under Network Service, the SPN must be under the server computer account
that's hosting AD FS.
 Make sure that there aren't duplicate SPNs for the AD FS service, as it may
cause intermittent authentication failures with AD FS. To list the SPNs, run
SETSPN -L <ServiceAccount> .

Run SETSPN -A HOST/AD FSservicename ServiceAccount to add the SPN.

Run SETSPN -X -F to check for duplicate SPNs.

d. Duplicate UPNs in Active Directory

A user may be able to authenticate through AD FS when they're using

SAMAccountName but be unable to authenticate when using UPN. In this
scenario, Active Directory may contain two users who have the same UPN. It's
possible to end up with two users who have the same UPN when users are
added and modified through scripting (ADSIedit, for example).

When UPN is used for authentication in this scenario, the user is authenticated
against the duplicate user. So the credentials that are provided aren't validated.
 You can use queries like the following to check whether there are multiple
objects in AD that have the same values for an attribute:

PowerShell

Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

Make sure that the UPN on the duplicate user is renamed, so that the
authentication request with the UPN is validated against the correct objects.

e. In a scenario, where you're using your email address as the login ID in Office
365, and you enter the same email address when you're redirected to AD FS for
authentication, authentication may fail with a "NO_SUCH_USER" error in the
Audit logs. To enable AD FS to find a user for authentication by using an
attribute other than UPN or SAMaccountname, you must configure AD FS to
support an alternate login ID. For more information, see Configuring Alternate
Login ID.

On AD FS 2012 R2

i. Install Update 2919355 .

ii. Update the AD FS configuration by running the following PowerShell cmdlet

on any of the federation servers in your farm (if you have a WID farm, you
must run this command on the primary AD FS server in your farm):

PowerShell

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -

AlternateLoginID <attribute> -LookupForests <forest domain>

７ Note

AlternateLoginID is the LDAP name of the attribute that you want to use
for login. And LookupForests is the list of forests DNS entries that your
users belong to.

To enable the alternate login ID feature, you must configure both the
AlternateLoginID and LookupForests parameters with a non-null, valid value.

f. The AD FS service account doesn't have read access to on the AD FS token

that's signing the certificate's private key. To add this permission, follow these
steps:
 i. When you add a new Token-Signing certificate, you receive the following
warning:

Ensure that the private key for the chosen certificate is accessible to the
service account for this Federation Service on each server in the farm.

ii. Select Start, select Run, type mmc.exe, and then press Enter.

iii. Select File, and then select Add/Remove Snap-in.

iv. Double-click Certificates.

v. Select the computer account in question, and then select Next.

vi. Select Local computer, and select Finish.

vii. Expand Certificates (Local Computer), expand Persona l, and then select
Certificates.

viii. Right-click your new token-signing certificate, select All Tasks, and then
select Manage Private Keys.

ix. Add Read access for your AD FS 2.0 service account, and then select OK.

x. Close the Certificates MMC.

g. The Extended Protection option for Windows Authentication is enabled for the
AD FS or LS virtual directory. It may cause issues with specific browsers.
Sometimes you may see AD FS repeatedly prompting for credentials, and it
might be related to the Extended protection setting that's enabled for Windows
Authentication for the AD FS or LS application in IIS.
 When Extended Protection for authentication is enabled, authentication
requests are bound to both the Service Principal Names (SPNs) of the server to
which the client tries to connect and to the outer Transport Layer Security (TLS)
channel over which Integrated Windows Authentication occurs. Extended
protection enhances the existing Windows Authentication functionality to
mitigate authentication relays or "man in the middle" attacks. However, certain
browsers don't work with the Extended protection setting; instead they
repeatedly prompt for credentials and then deny access. Disabling Extended
protection helps in this scenario.

For more information, see AD FS 2.0: Continuously Prompted for Credentials

While Using Fiddler Web Debugger .

For AD FS 2012 R2

Run the following cmdlet to disable Extended protection:

PowerShell

Set-ADFSProperties -ExtendedProtectionTokenCheck None

h. Issuance Authorization rules in the Relying Party (RP) trust may deny access to
users. On the AD FS Relying Party trust, you can configure the Issuance
Authorization rules that control whether an authenticated user should be issued
a token for a Relying Party. Administrators can use the claims that are issued to
decide whether to deny access to a user who's a member of a group that's
pulled up as a claim.

If certain federated users can't authenticate through AD FS, you may want to
check the Issuance Authorization rules for the Office 365 RP and see whether
the Permit Access to All Users rule is configured.
If this rule isn't configured, peruse the custom authorization rules to check
whether the condition in that rule evaluates "true" for the affected user. For
more information, see the following resources:

Understanding Claim Rule Language in AD FS 2.0 & Higher

Configuring Client Access Policies
Limiting Access to Office 365 Services Based on the Location of the Client

If you can authenticate from an intranet when you access the AD FS server
directly, but you can't authenticate when you access AD FS through an AD FS
proxy, check for the following issues:

Time sync issue on AD FS server and AD FS proxy

Make sure that the time on the AD FS server and the time on the proxy are
in sync. When the time on the AD FS server is off by more than five
minutes from the time on the domain controllers, authentication failures
occur. When the time on AD FS proxy isn't synced with AD FS, the proxy
trust is affected and broken. So a request that comes through the AD FS
proxy fails.
 Check whether the AD FS proxy Trust with the AD FS service is working
correctly. Rerun the proxy configuration if you suspect that the proxy trust
is broken.

5. After your AD FS issues a token, Microsoft Entra ID or Office 365 throws an error. In
this situation, check for the following issues:

The claims that are issued by AD FS in token should match the respective
attributes of the user in Microsoft Entra ID. In the token for Microsoft Entra ID
or Office 365, the following claims are required.

WSFED:
UPN: The value of this claim should match the UPN of the users in Microsoft
Entra ID.
ImmutableID: The value of this claim should match the sourceAnchor or
ImmutableID of the user in Microsoft Entra ID.

To get the User attribute value in Microsoft Entra ID, run the following
command line:

PowerShell

Get-MsolUser -UserPrincipalName <UPN>

SAML 2.0:
IDPEmail: The value of this claim should match the user principal name of the
users in Microsoft Entra ID.
NAMEID: The value of this claim should match the sourceAnchor or
ImmutableID of the user in Microsoft Entra ID.

For more information, see Use a SAML 2.0 identity provider to implement
single sign-on.

Examples:
This issue can occur when the UPN of a synced user is changed in AD but
without updating the online directory. In this scenario, you can either correct
the user's UPN in AD (to match the related user's logon name) or run the
following cmdlet to change the logon name of the related user in the Online
directory:

PowerShell

Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -

 NewUserPrincipalName [DomainUPN-AD]

It might also be that you're using AADsync to sync MAIL as UPN and EMPID
as SourceAnchor, but the Relying Party claim rules at the AD FS level haven't
been updated to send MAIL as UPN and EMPID as ImmutableID.

There's a token-signing certificate mismatch between AD FS and Office 365.

It's one of the most common issues. AD FS uses the token-signing certificate
to sign the token that's sent to the user or application. The trust between the
AD FS and Office 365 is a federated trust that's based on this token-signing
certificate (for example, Office 365 verifies that the token received is signed
by using a token-signing certificate of the claim provider [the AD FS service]
that it trusts).

However, if the token-signing certificate on the AD FS is changed because of

Auto Certificate Rollover or by an admin's intervention (after or before
certificate expiry), the details of the new certificate must be updated on the
Office 365 tenant for the federated domain. It may not happen automatically;
it may require an admin's intervention. When the Primary token-signing
certificate on the AD FS is different from what Office 365 knows about, the
token that's issued by AD FS isn't trusted by Office 365. So the federated user
isn't allowed to sign in.

Office 365 or Microsoft Entra ID will try to reach out to the AD FS service,
assuming the service is reachable over the public network. We try to poll the
AD FS federation metadata at regular intervals, to pull any configuration
changes on AD FS, mainly the token-signing certificate info. If this process is
not working, the global admin should receive a warning on the Office 365
portal about the token-signing certificate expiry and about the actions that
are required to update it.

You can use Get-MsolFederationProperty -DomainName <domain> to dump the

federation property on AD FS and Office 365. Here you can compare the
TokenSigningCertificate thumbprint, to check whether the Office 365 tenant
configuration for your federated domain is in sync with AD FS. If you find a
mismatch in the token-signing certificate configuration, run the following
command to update it:

PowerShell

Update-MsolFederatedDomain -DomainName <domain> -

 SupportMultipleDomain

You can also run the following tool to schedule a task on the AD FS server
that will monitor for the Auto-certificate rollover of the token-signing
certificate and update the Office 365 tenant automatically.

Microsoft Office 365 Federation Metadata Update Automation Installation

Tool

Verify and manage single sign-on with AD FS

Issuance Transform claim rules for the Office 365 RP aren't configured
correctly.

In a scenario where you have multiple TLDs (top-level domains), you might
have logon issues if the Supportmultipledomain switch wasn't used when the
RP trust was created and updated. For more information, see
SupportMultipleDomain switch, when managing SSO to Office 365.

Make sure that token encryption isn't being used by AD FS or STS when a
token is issued to Microsoft Entra ID or to Office 365.

6. There are stale cached credentials in Windows Credential Manager.

Sometimes during login in from a workstation to the portal (or when using
Outlook), when the user is prompted for credentials, the credentials may be saved
for the target (Office 365 or AD FS service) in the Windows Credentials Manager
( Control Panel\User Accounts\Credential Manager ). This helps prevent a
credentials prompt for some time, but it may cause a problem after the user
password has changed and the credentials manager isn't updated. In that scenario,
stale credentials are sent to the AD FS service, and that's why authentication fails.
Removing or updating the cached credentials, in Windows Credential Manager
may help.

7. Make sure that Secure Hash Algorithm that's configured on the Relying Party Trust
for Office 365 is set to SHA1.

When the trust between the STS / AD FS and Microsoft Entra ID / Office 365 is
using SAML 2.0 protocol, the Secure Hash Algorithm configured for digital
signature should be SHA1.

8. If none of the preceding causes apply to your situation, create a support case with
Microsoft and ask them to check whether the User account appears consistently
 under the Office 365 tenant. For more information, see A federated user is
repeatedly prompted for credentials during sign-in to Office 365, Azure or Intune.

9. Depending on which cloud service (integrated with Microsoft Entra ID) you are
accessing, the authentication request that's sent to AD FS may vary. For example:
certain requests may include additional parameters such as Wauth or Wfresh, and
these parameters may cause different behavior at the AD FS level.

We recommend that AD FS binaries always be kept updated to include the fixes for
known issues. For more information about the latest updates, see the following
table.

ﾉ Expand table

AD FS 2.0 AD FS 2012 R2

Description of Update Rollup 3 for Active December 2014 update rollup for
Directory Federation Services (AD FS) Windows RT 8.1, Windows 8.1, and
2.0 Windows Server 2012 R2
Update is available to fix several issues
after you install security update 2843638
on an AD FS server

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot SSO issues with Active
Directory Federation Services (AD FS)
Article • 02/19/2024

This article helps you resolve single sign-on (SSO) issues with Active Directory
Federation Services (AD FS).

Select one of the following section according to the type of issue that you encounter.

Applies to: Active Directory Federation Services

Original KB number: 4034932

NTLM or forms-based authentication prompt

During troubleshooting single sign-on (SSO) issues with Active Directory Federation
Services (AD FS), if users received unexpected NTLM or forms-based authentication
prompt, follow the steps in this article to troubleshoot this issue.

Check Windows Integrated Authentication settings

To troubleshoot this issue, check Windows Integrated Authentication settings in the
client browser, AD FS settings and authentication request parameters.

Check the client browser of the user

Check the following settings in Internet Options:

On the Advanced tab, make sure that the Enable Integrated Windows
Authentication setting is enabled.
Following Security > Local intranet > Sites > Advanced, make sure that the AD FS
URL is in the list of websites.
Following Security > Local intranet > Custom level, make sure that the Automatic
logon only in Intranet Zone setting is selected.

If you use Firefox, Chrome or Safari, make sure the equivalent settings in these browsers
are enabled.

Check the AD FS settings

Check the WindowsIntegratedFallback setting

1. Open Windows PowerShell with the Run as administrator option.

2. Get the global authentication policy by running the following command:

PowerShell

Get-ADFSGlobalAuthenticationPolicy | fl
WindowsIntegratedFallbackEnabled

3. Examine the value of the WindowsIntegratedFallbackEnabled attribute.

If the value is True, forms-based authentication is expected. This means that the
authentication request comes from a browser that doesn't support Windows Integrated
Authentication. See the next section about how to get your browser supported.

If the value is False, Windows Integrated Authentication should be expected.

Check the WIASupportedUsersAgents setting

1. Get the list of supported user agents by running the following command:

PowerShell

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

2. Examine the list of user agent strings that the command returns.

Verify if the user agent string of your browser is in the list. If not, add the user agent
string by following the steps below:

1. Go to http://useragentstring.com/ that detects and shows you the user agent

string of your browser.

2. Get the list of supported user agents by running the following command:

PowerShell

$wiaStrings = Get-ADFSProperties | Select -ExpandProperty

WIASupportedUserAgents

3. Add the user agent string of your browser by running the following command:

PowerShell
 $wiaStrings = $wiaStrings+"NewUAString"

Example:

PowerShell

$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

4. Update the WIASupportedUserAgents setting by running the following command:

PowerShell

Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Check the authentication request parameters

Check if the authentication request specifies forms-based

authentication as the authentication method

1. If the authentication request is a WS-Federation request, check if the request

includes wauth= urn:oasis:names:tc:SAML:1.0:am:password.
2. If the authentication request is a SAML request, check if the request includes a
samlp:AuthnContextClassRef element with value
urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

For more information, see Overview of authentication handlers of AD FS sign-in pages.

Check if the application is Microsoft Online Services for Office

365

If the application that you want to access is not Microsoft Online Services, what you
experience is expected and controlled by the incoming authentication request. Work
with the application owner to change the behavior.

７ Note

Azure AD Powershell is planned for deprecation on March 30, 2024. To learn more,
read the deprecation update .

We recommend migrating to Microsoft Graph PowerShell to interact with

Microsoft Entra ID (formerly Azure AD). Microsoft Graph PowerShell allows access
 to all Microsoft Graph APIs and is available on PowerShell 7. For answers to
common migration queries, see the Migration FAQ.

If the application is Microsoft Online Services, what you experience may be controlled by
the PromptLoginBehavior setting from the trusted realm object. This setting controls
whether Microsoft Entra tenants send prompt=login to AD FS. To set the
PromptLoginBehavior setting, follow these steps:

1. Open Windows PowerShell with the "Run as administrator" option.

2. Get the existing domain federation setting by running the following command:

PowerShell

Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

3. Set the PromptLoginBehavior setting by running the following command:

PowerShell

Set-MSOLDomainFederationSettings -DomainName DomainName -

PromptLoginBehavior
<TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA
<$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

The values for the PromptLoginBehavior parameter are:

a. TranslateToFreshPasswordAuth: Microsoft Entra ID sends wauth and wfresh to
AD FS instead of prompt=login. This leads to an authentication request to use
forms-based authentication.
b. NativeSupport: The prompt=login parameter is sent as is to AD FS.
c. Disabled: Nothing is sent to AD FS.

To learn more about the Set-MSOLDomainFederationSettings command, see Active

Directory Federation Services prompt=login parameter support.

Microsoft Entra scenario

If the authentication request sent to Microsoft Entra ID include the prompt=login
parameter, disable the prompt=login capability by running the following command:

PowerShell

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior

 Disabled

After you run this command, Office 365 applications won't include the prompt=login
parameter in each authentication request.

Non Microsoft Entra scenario

Request parameters like WAUTH and RequestedAuthNContext in authentication
requests can have authentication methods specified. Check if other request parameters
enforcing the unexpected authentication prompt. If so, modify the request parameter to
use the expected authentication method.

Check if SSO is disabled

If SSO is disabled, enable it and test if the issue is resolved.

Multi-factor authentication prompt

To troubleshoot this issue, check if the claim rules in the relying party are correctly set
for multi-factor authentication.

Multi-factor authentication can be enabled at an AD FS server, at a relying party, or

specified in an authentication request parameter. Check the configurations to see if they
are correctly set. If multi-factor authentication is expected but you're repeatedly
prompted for it, check the relying party issuance rules to see if multi-factor
authentication claims are passed through to the application.

For more information about multi-factor authentication in AD FS, see the following
articles:

Under the hood tour on Multi-Factor Authentication in ADFS – Part 1: Policy

Under the hood tour on Multi-Factor Authentication in ADFS – Part 2: MFA aware
Relying Parties

Check the configuration on the AD FS server and the

relying party
To check the configuration on the AD FS server, validate the global additional
authentication rules. To check the configuration on the relying party, validate the
additional authentication rules for the relying party trust.
 1. To check the configuration on the AD FS server, run the following command in a
Windows PowerShell window.

PowerShell

Get-ADFSAdditionalAuthenticationRule

To check the configuration on the relying party, run the following command:

PowerShell

Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -

ExpandProperty AdditionalAuthenticationRules

７ Note

If the commands return nothing, the additional authentication rules are not
configured. Skip this section.

2. Observe the claim rule set configured.

Verify if multi-factor authentication is enabled in the

claim rule set
A claim rule set is composed of the following sections:

The condition statement: C:[Type=``…,Value=…]

The issue statement: => issue (Type=``…,Value=…)

If the issue statement contains the following claim, multi-factor authentication is

specified.
Type =
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",

Value = "http://schemas.microsoft.com/claims/multipleauthn"

Here are examples that require multi-factor authentication to be used for non-
workplace joined devices and for extranet access respectively:

c:[Type ==

"http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser",

Value == "false"] => issue(Type =

 "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod"
, Value = "http://schemas.microsoft.com/claims/multipleauthn")

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork",
Value == "false"] => issue(Type =

"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod"

, Value = "http://schemas.microsoft.com/claims/multipleauthn")

Check the relying party issuance rules

If the user repeatedly receives multi-factor authentication prompts after they perform
the first authentication, it is possible that the replying party is not passing through the
multi-factor authentication claims to the application. To check if the authentication
claims are passed through, follow these steps:

1. Run the following command in Windows PowerShell:

PowerShell

Get-ADFSRelyingPartyTrust -TargetName ClaimApp

2. Observe the rule set defined in the IssuanceAuthorizationRules or

IssuanceAuthorizationRulesFile attributes.

The rule set should include the following issuance rule to pass through the multi-factor
authentication claims:
C:

[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod

, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Check the authentication request parameter

Check if the authentication request specifies multi-factor

authentication as the authentication method
If the authentication request is a WS-Federation request, check if the request
includes wauth= http://schemas.microsoft.com/claims/multipleauthn .
If the authentication request is a SAML request, check if the request includes a
samlp:AuthnContextClassRef element with value
http://schemas.microsoft.com/claims/multipleauthn .

For more information, see Overview of authentication handlers of AD FS sign-in pages.

Check if the application is Microsoft Online Services for Office 365
If the application that you want to access is Microsoft Online Services for Office 365,
check the SupportsMFA domain federation setting.

1. Get the current SupportsMFA domain federation setting by running the following
command:

PowerShell

Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

2. If the SupportsMFA setting is FALSE, set it to TRUE by running the following

command:

PowerShell

Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA

$TRUE

Check if SSO is disabled

If SSO is disabled, enable it and test if the issue is resolved.

Users can't log in the target site or service

This issue can occur at the AD FS sign-in page or at the application side.

If the issue occurs at the AD FS sign-in page, you receive an "An error occurred", "HTTP
503 Service is unavailable" or some other error message. The URL of the error page
shows the AD FS service name such as fs.contoso.com .

If the issue occurs at the application side, the URL of the error page shows the IP
address or the site name of the target service.

Follow the steps in the following section according where you encounter this issue.

This issue occurs at the AD FS sign-in page

To troubleshoot this issue, check if all all users are impacted by the issue, and if the users
can access all the relying parties.
All users are impacted by the issue, and the user can't access any of
the relying parties

Let's check the internal sign-in functionality using IdpInitiatedSignOn. To do this, use the
IdpInititatedSignOn page to verify if the AD FS service is up and running and the
authentication functionality is working correctly. To open the IdpInitiatedSignOn page,
follow these steps:

1. Enable the IdpInitiatedSignOn page by running the following command on the AD

FS server:

PowerShell

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

2. From a computer that is inside your network, visit the following page:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Enter the correct credentials of a valid user on the sign-in page.

The sign-in is successful

If the sign-in is successful, check if the AD FS service state is running.

1. On the AD FS server, open Server Manager.

2. In the Server Manager, click Tools > Services.
3. Check if the Status of Active Directory Federation Services is Running.

Then, check the external sign-in functionality using IdpInitiatedSignOn. Use the
IdpInititatedSignOn page to quickly verify if the AD FS service is up and running and the
authentication functionality is working correctly. To open the IdpInitiatedSignOn page,
follow these steps:

1. Enable the IdpInitiatedSignOn page by running the following command on the AD

FS server:

PowerShell

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

2. From a computer that is outside of your network, visit the following page:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Enter the correct credentials of a valid user on the sign-in page.

If the sign-in is unsuccessful, see Check the AD FS related components and services and
Check the proxy trust relationship.

If the sign-in is successful, continue the troubleshooting with the steps in All users are
impacted by the issue, and the user can access some of the relying parties.

The sign-in is unsuccessful

If the sign-in is unsuccessful, check the AD FS related components and services.

Check if the AD FS service state is running.

1. On the AD FS server, open Server Manager.

2. In the Server Manager, click Tools > Services.
3. Check if the Status of Active Directory Federation Services is Running.

Check if the endpoints are enabled. AD FS provides various endpoints for different
functionalities and scenarios. Not all endpoints are enabled by default. To check the
status of the endpoints, following these steps:

1. On the AD FS server, open the AD FS Management Console.

2. Expand Service > Endpoints.

3. Locate the endpoints and verify if the statuses are enabled on the Enabled column.

Then, check if Microsoft Entra Connect is installed. We recommend that you use
Microsoft Entra Connect which makes SSL certificate management easier.

If Microsoft Entra Connect is installed, ensure that you use it to manage and update SSL
certificates.
If Microsoft Entra Connect is not installed, check if the SSL certificate meets the
following AD FS requirements:

The certificate is from a trusted root certification authority.

AD FS requires that SSL certificates are from a trusted root certification authority. If
AD FS is accessed from non-domain joined computers, we recommend that you
use an SSL certificate from a trusted third-party root certification authority like
DigiCert, VeriSign, etc. If the SSL certificate is not from a trusted root certification
authority, SSL communication can break.

The subject name of the certificate is valid.

The subject name should match the federation service name, not the AD FS server
name or some other name. To get the federation service name, run the following
command on the primary AD FS server:
Get-AdfsProperties | select hostname

The certificate is not revoked.

Check for certificate revocation. If the certificate is revoked, SSL connection can't
be trusted and will be blocked by clients.

If the SSL certificate does not meet these requirements, try to get a qualified certificate
for SSL communication. We recommend that you use Microsoft Entra Connect which
makes SSL certificate management easier. See Update the TLS/SSL certificate for an
Active Directory Federation Services (AD FS) farm.

If the SSL certificate meets these requirements, check the following configurations of the
SSL certificate.

Check if the SSL certificate is installed properly

The SSL certificate should be installed to the Personal store for the local computer on
each federation server in your farm. To install the certificate, double click the .PFX file of
the certificate and follow the wizard.

To verify if the certificate is installed to the correct place, follow these steps:

1. List the certificates that are in the Personal store for the local computer by running
the following command:
dir Cert:\LocalMachine\My

2. Check if the certificate is in the list.

Check if the correct SSL certificate is in use

Get the thumbprint of the certificate that is in use for SSL communication and verify if
the thumbprint matches the expected certificate thumbprint.

To get the thumbprint of the certificate that is in use, run the following command in
Windows PowerShell:

PowerShell

Get-AdfsSslCertificate

If the wrong certificate is used, set the correct certificate by running the following
command:

PowerShell

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Check if the SSL certificate is set as the service communication

certificate

The SSL certificate needs to be set as the service communication certificate in your AD
FS farm. This does not happen automatically. To check if the correct certificate is set,
follow these steps:

1. In the AD FS Management Console, expand Service > Certificates.

2. Verify if the certificate listed under Service communications is the expected
certificate.

If the wrong certificate is listed, set the correct certificate, and then grant the AD FS
service the Read permission to the certificate. To do this, follow these steps:

1. Set the correct certificate:

a. Right-click Certificates, and then click Set Service Communication Certificate.
b. Select the correct certificate.

2. Verify if the AD FS service has the Read permission to the certificate:

a. Add the Certificates snap-in for the local computer account to the Microsoft
Management Console (MMC).
b. Expand Certificates (Local Computer) > Personal > Certificates.
c. Right-click the SSL certificate, click All Tasks > Manage Private Keys.
 d. Verify if adfssrv is listed under Group and user names with the Read
permission.

3. If adfssrv is not listed, grant the AD FS service the Read permission to the
certificate:
a. Click Add, click Locations, click the server, and then click OK.
b. Under Enter the object names to select, enter nt service\adfssrv, click Check
Names, and then click OK.
If you are using AD FS with Device Registration Service (DRS), enter nt
service\drs instead.
c. Grant the Read permission, and then click OK.

Check if Device Registration Service (DRS) is configured in AD FS

If you've configured AD FS with DRS, make sure that the SSL certificate is also properly
configured for RDS. For example, if there are two UPN suffixes contoso.com and
fabrikam.com , the certificate must have enterpriseregistration.contoso.com and

enterpriseregistration.fabrikma.com as the Subject Alternative Names (SANs).

To check if the SSL certificate has the correct SANs, follow these steps:

1. List all the UPN suffixes being used in the organization by running the following
command:

PowerShell

Get-AdfsDeviceRegistratrionUpnSuffix

2. Verify if the SSL certificate has the required SANs configured.

3. If SSL certificate does not have the correct DRS names as SANs, get a new SSL
certificate that has the correct SANs for DRS, and then use it as the SSL certificate
for AD FS.

Then, check the certificate configuration on WAP servers and the fallback bindings:

Check if the correct SSL certificate is set on all WAP servers.

1. Make sure that the SSL certificate is installed in the Personal store for the
local computer on each WAP server.

2. Get the SSL certificate used by WAP by running the following command:

PowerShell
 Get-WebApplicationProxySslCertificate

3. If the SSL certificate is wrong, set the correct SSL certificate by running the
following command:

PowerShell

Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Check the certificate bindings and update them if necessary.

To support non-SNI cases, administrators may specify fallback bindings. Other than
the standard federationservicename:443 binding, look for fallback bindings under
the following application IDs:
{5d89a20c-beab-4389-9447-324788eb944a}: This is the application ID for AD
FS.
{f955c070-e044-456c-ac00-e9e4275b3f04}: This is the application ID for Web
Application Proxy.

For example, if the SSL certificate is specified for a fallback binding like 0.0.0.0:443,
make sure that the binding is updated accordingly when the SSL certificate gets
updated.

All users are impacted by the issue, and the user can access some
of the relying parties

First, let's get the relying party and OAuth client information. If you use a conventional
relying party, follow these steps:

1. On the primary AD FS server, open Windows PowerShell with the Run as

administrator option.

2. Add the AD FS 2.0 component to Windows PowerShell by running the following

command:

PowerShell

Add-PSSnapin Microsoft.Adfs.PowerShell

3. Get the relying party information by running the following command:

PowerShell
 $rp = Get-AdfsRelyingPartyTrust RPName

4. Get the OAuth client information by running the following command:

PowerShell

$client = Get-AdfsClient ClientName

If you use the Application Group feature in Windows Server 2016, follow the steps
below:

1. On the primary AD FS server, open Windows PowerShell with the Run as

administrator option.

2. Get the relying party information by running the following command:

$rp = Get-AdfsWebApiApplication ResourceID

3. If the OAuth client is public, get the client information by running the following
command:

PowerShell

$client = Get-AdfsNativeClientApplication ClientName

If the client is confidential, get the client information by running the following
command:

PowerShell

$client = Get-AdfsServerApplication ClientName

Now continue with the following troubleshooting methods.

Check the settings of the relying party and client

The relying party identifier, client ID and redirect URI should be provided by the owner
of the application and the client. However, there could still be a mismatch between what
the owner provides and what are configured in AD FS. For example, a mismatch could
be caused by a typo. Check if the settings provided by the owner match those
configured in AD FS. The steps in the previous page get you the settings configured in
AD FS via PowerShell.
 ﾉ Expand table

Settings provided by the owner Settings configured in AD FS

Relying party ID $rp.Identifier

Relying party redirect URI A prefix or wildcard match of

$rp.WSFedEndpoint for a WS-Fed relying party

$rp.SamlEndpoints for a SAML relying party

Client ID $client.ClientId

Client redirect URI A prefix match of $client.RedirectUri

If items in the table matches, additionally check if these settings match between what
they appear in the authentication request sent to AD FS and what are configured in AD
FS. Try reproducing the issue during which you capture a Fiddler trace on the
authentication request sent by the application to AD FS. Examine the request
parameters to do the following checks depending on the request type.

OAuth requests

An OAuth request looks like the following:

https://sts.contoso.com/adfs/oauth2/authorize?

response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource
=https://www.TestApp.com

Check if the request parameters match the settings configured in AD FS.

ﾉ Expand table

Request parameters Settings configured in AD FS

client_id $client.ClientId

redirect_uri A prefix match of @client_RedirectUri

The "resource" parameter should represent a valid relying party in AD FS. Get the relying
party information by running one of the following commands.

If you use a conventional relying party, run the following command:

Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
 If you use the Application Group feature in Windows Server 2016, run the following
command:
Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed requests

A WS-Fed request looks like the following:

https://fs.contoso.com/adfs/ls/?

wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2

014-10-21T22:15:42Z

Check if the request parameters match the settings configured in AD FS:

ﾉ Expand table

Request parameters Settings configured in AD FS

wtrealm $rp.Identifier

wreply A prefix match or wildcard match of $rp.WSFedEndpoint

SAML requests

A SAML request looks like the following:

https://sts.contoso.com/adfs/ls/?

SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/0

9/Fxmldsig#rsa-sha1&Signature=Signature

Decode the value of the SAMLRequest parameter by using the "From DeflatedSAML"
option in the Fiddler Text Wizard. The decoded value looks like the following:

XML

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-

28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/ser
vices/trust</Issuer><samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
AllowCreate="true" /></samlp:AuthnRequest>

Do the following checks within the decoded value:

 Check if the host name in the value of Destination matches the AD FS host name.
Check if the value of Issuer matches $rp.Identifier .

Additional notes for SAML:

$rp.SamlEndpoints: Shows all types of SAML endpoints. The response from AD FS

is sent to the corresponding URLs configured in the endpoints. A SAML endpoint
can use redirect, post or artifact bindings for message transmission. All these URLs
can be configured in AD FS.
$rp.SignedSamlRequestsRequired: If the value is set, the SAML request sent from
the relying party needs to be signed. The "SigAlg" and "Signature" parameters
need to be present in the request.
$rp.RequestSigningCertificate: This is the signing certificate used to generate the
signature on the SAML request. Make sure that the certificate is valid and ask the
application owner to match the certificate.

Check the encryption certificate

If $rp.EncryptClaims returns Enabled, relying party encryption is enabled. AD FS uses

the encryption certificate to encrypt the claims. Do the following checks:

$rp.EncryptionCertificate: Use this command to get the certificate and check if it is

valid.
$rp. EncryptionCertificateRevocationCheck: Use this command to check if the
certificate meets the revocation check requirements.

The previous two methods don't work

To continue the troubleshooting, see Use the Dump Token app.

Not all users are impacted by the issue, and the user can't access
any of the relying parties
In this scenario, do the following checks.

Check if the user is disabled

Check the user status in Windows PowerShell or the UI. If the user is disabled, enable the
user.

Check the user status with Windows PowerShell

 1. Log in to any of the domain controllers.

2. Open Windows PowerShell.

3. Check the user status by running the following command:

PowerShell

Get-ADUser -Identity <samaccountname of the user> | Select Enabled

Check the user status in the UI

1. Log in to any of the domain controllers.

2. Open the Active Directory Users and Computers management console.

3. Click the Users node, right-click the user in the right pane, and then click
Properties.

4. Click the Account tab.

5. Under Account options, verify if Account is disabled is checked.

6. If the option is checked, uncheck it.

Check if the user properties were updated recently

If any property of the user is updated in the Active Directory, it results in a change in the
metadata of the user object. Check the user metadata object to see which properties
were updated recently. If changes are found, make sure that they are picked up by the
related services. To check if there were property changes to a user, following these steps:

1. Log in to a domain controller.

2. Open Windows PowerShell.

 3. Get the metadata of the user object by running the following command:
repadmin /showobjmeta <destination DC> "user DN"

An example of the command is:

repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

4. In the metadata, examine the Time/Date column for each attribute for any clue to a
change. In the following example, the userPrincipleName attribute takes a newer
date than the other attributes which represents a change to the user object
metadata.

Check the forest trust if the user belongs to another forest

In a multi-forest AD FS environment, a two-way forest trust is required between the

forest where AD FS is deployed and the other forests which utilize the AD FS
deployment for authentication. To verify if the trust between the forests is working as
expected, follow these steps:

1. Log in to a domain controller in the forest where AD FS is deployed.

2. Open the Active Directory Domains and Trusts management console.

3. In the management console, right-click the domain that contains the trust that you
want to verify, and then click Properties.

4. Click the Trusts tab.

5. Under Domains trusted by this domain (outgoing trusts) or Domains that trust
this domain (incoming trusts), click the trust to be verified, and then click
Properties.
 6. Click Validate.
In the Active Directory Domain Services dialog box, select either of the options.

If you select No, we recommend that you repeat the same procedure for the
reciprocal domain.

If you select Yes, provide an administrative user credential for the reciprocal
domain. There is no need to perform the same procedure for the reciprocal
domain.

If these steps did not help you solve the issue, continue the troubleshooting with the
steps in the Not all users are impacted by the issue, and the user can access some of the
relying parties section.

Not all users are impacted by the issue, and the user can access
some of the relying parties

In this scenario, check if this issue occurs in a Microsoft Entra scenario. If so, do these
checks to troubleshoot this issue. If not, see Use the Dump Token app to troubleshoot
this issue.

Check if the user is synced to Microsoft Entra ID

If a user is trying to log in to Microsoft Entra ID, they will be redirected to AD FS for
authentication for a federated domain. One of the possible reasons for a failed login is
that the user is not yet synced to Microsoft Entra ID. You might see a loop from
Microsoft Entra ID to Active Directory FS after the first authentication attempt at AD FS.
To determine whether the user is synced to Microsoft Entra ID, follow these steps:

1. Download and install the Azure AD PowerShell module for Windows PowerShell.
2. Open Windows PowerShell with the "Run as administrator" option.
 3. Initiate a connection to Microsoft Entra ID by running the following command:
Connect-MsolService

4. Provide the global administrator credential for the connection.

5. Get the list of users in the Microsoft Entra ID by running the following command:
Get-MsolUser

6. Verify if the user is in the list.

If the user is not in the list, sync the user to Microsoft Entra ID.

Check immutableID and UPN in issuance claim rule

Microsoft Entra ID requires immutableID and the user's UPN to authenticate the user.

７ Note

immutableID is also called sourceAnchor in the following tools:

Azure AD Sync
Azure Active Directory Sync (DirSync)

Administrators can use Microsoft Entra Connect for automatic management of AD FS

trust with Microsoft Entra ID. If you are not managing the trust via Microsoft Entra
Connect, we recommend that you do so by downloading Microsoft Entra Connect
Microsoft Entra Connect enables automatic claim rules management based on sync
settings.

To check if the claim rules for immutableID and UPN in AD FS matches what Microsoft
Entra ID uses, follow these steps:

1. Get sourceAnchor and UPN in Microsoft Entra Connect.

a. Open Microsoft Entra Connect.

b. Click View current configuration.

 c. On the Review Your Solution page, make a note of the values of SOURCE
ANCHOR and USER PRINCIPAL NAME.

2. Verify the values of immutableID (sourceAnchor) and UPN in the corresponding

claim rule configured in the AD FS server.

a. On the AD FS server, open the AD FS management console.

b. Click Relying Party Trusts.

c. Right-click the relying party trust with Microsoft Entra ID, and then click Edit
Claim Issuance Policy.

d. Open the claim rule for immutable ID and UPN.

e. Verify if the variables queried for values of immutableID and UPN are the same
as those appear in Microsoft Entra Connect.
 3. If there is a difference, use one of the methods below:

If AD FS is managed by Microsoft Entra Connect, reset the relying party trust

by using Microsoft Entra Connect.
If AD FS is not managed by Microsoft Entra Connect, correct the claims with
the right attributes.

If these checks did not help you solve the issue, see Use the Dump Token app to
troubleshoot this issue.

This issue occurs at the application side

If the token signing certificate was renewed recently by AD FS, check if the new
certificate is picked up by the federation partner. In case AD FS uses a token decrypting
certificate that was also renewed recently, do the same check as well. To check if the
current AD FS token signing certificate on AD FS matches the one on the federation
partner, follow these steps:

1. Get the current token signing certificate on AD FS by running the following

command:

PowerShell

Get-ADFSCertificate -CertificateType token-signing

 2. In the list of certificates returned, find the one with IsPrimary = TRUE, and make a
note of the thumbprint.

3. Get the thumbprint of the current token signing certificate on the federation
partner. The application owner needs to provide you this.

4. Compare the thumbprints of the two certificates.

Do the same check if AD FS uses a renewed token decrypting certificate, except that the
command to get the token decrypting certificate on AD FS is as follows:

PowerShell

Get-ADFSCertificate -CertificateType token-decrypting

The thumbprints of the two certificates match

If the thumbprints match, ensure the partners are using the new AD FS certificates.

If there are certificate mismatches, ensure that the partners are using the new
certificates. Certificates are included in the federation metadata published by the AD FS
server.

７ Note

The partners refer to all your resource organization or account organization

partners, represented in your AD FS by relying party trusts and claims provider
trusts.

The partners can access the federation metadata

If the partners can access the federation metadata, ask the partners to use the new
certificates.

The partners can't access the federation metadata

In this case, you must manually send the partners the public keys of the new
certificates. To do this, follow these steps:

1. Export the public keys as .cert files, or as .p7b files to include the entire
certificate chains.
2. Send the public keys to the partners.
3. Ask the partners to use the new certificates.
The thumbprints of the two certificates don't match
Then, check if there is a token-signing algorithm mismatch. To do this, follow these
steps:

1. Determine the algorithm used by the relying party by running the following
command:

PowerShell

Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

The possible values are SHA1 or SHA256.

2. Check with the application owner for the algorithm used on the application side.

3. Check if the two algorithms match.

If the two algorithms match, check if the Name ID format matches what the application
requires.

1. On the AD FS server, dump the issuance transform rules by running the following
command:

PowerShell

(Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

2. Locate the rule that issues the NameIdentifier claim. If such a rule doesn't exist,
skip this step.

Here is an example of the rule:

c:[Type ==

"http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] =>

issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value

= c.Value,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/for

mat"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

Notice the NameIdentifier format in the following syntax:

Properties["Property-type-URI"] = "ValueURI"
 The possible formats are listed below. The first format is the default.

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient

3. Ask the application owner for the NameIdentifier format required by the
application.

4. Verify if the two NameIdentifier formats match.

5. If the formats don't match, configure the NameIdentifier claim to use the format
that the application requires. To do this, follow these steps:
a. Open the AD FS management console.
b. Click Relying Party Trusts, select the appropriate federation partner, and then
click Edit Claims Issuance Policy in the Actions pane.
c. Add a new rule if there is no rule to issue the NameIdentifier claim, or update an
existing rule. Select Name ID for Incoming claim type, and then specify the
format that the application requires.

If the two algorithms mismatch, update the signing algorithm used by the relying party
trust.

1. Open the AD FS management console.

2. Right-click the relying party trust, and then click Properties.

3. On the Advanced tab, select the algorithm to match what the application requires.
About certificate auto renewal
If the token signing certificate or token decrypting certificate are self-signed,
AutoCertificateRollover is enabled by default on these certificates and AD FS manages
the auto renewal of the certificates when they are close to expiration.

To determine if you're using self-signed certificates, follow these steps:

1. Run the following command:

PowerShell

Get-ADFSCerticate -CertificateType "token-signing"

2. Examine the certificate attributes.

If the Subject and Issuer attributes both start with "CN=ADFS Signing...", the
certificate is self-signed and managed by AutoCertRollover.

To confirm if the certificates renew automatically, follow these steps:

1. Run the following command:

PowerShell
 Get-ADFSProperties | FL AutoCertificateRollover

2. Examine the AutoCertificateRollover attribute.

If AutoCertificateRollover = TRUE, AD FS automatically generates new

certificates (30 days prior to expiration by default) and sets them as the
primary certificates (25 days prior to expiration).
If AutoCertificateRollover = FALSE, you need to manually replace the
certificates.

Check the ADFS-related components and

services
This article introduces how to check the ADFS-related components and services. These
steps could help when you are troubleshooting sign-on (SSO) issues with Active
Directory Federation Services (ADFS).

Check DNS
Accessing ADFS should point directly to one of the WAP (Web Application Proxy) servers
or the load balancer in front of the WAP servers. Do the following checks:

Ping the federation service name (e.g. fs.contoso.com ). Confirm if the IP address
the Ping resolves to is of one of the WAP servers or of the load balancer of the
WAP servers.
Check if there is an A record for the federation service in the DNS server. The A
record should point to one of the WAP servers or to the load balancer of the WAP
servers.

If WAP is not implemented in your scenario for external access, check if accessing ADFS
points directly to one of the ADFS servers or the load balancer in front of the ADFS
servers:

Ping the federation service name (e.g. fs.contoso.com ). Confirm if the IP address
that you get resolves to one of the ADFS servers or the load balancer of the ADFS
servers.
 Check if there is an A record for the federation service in the DNS server. The A
record should point to one of the ADFS servers or to the load balancer of the ADFS
servers.

Check the load balancer if it is used

Check if firewall is blocking traffic between:

The ADFS server and the load balancer.

The WAP (Web Application Proxy) server and the load balancer if WAP is used.

If probe is enabled on the load balancer, check the following:

If you are running Windows Server 2012 R2, ensure that the August 2014 update
rollup is installed.
Check if port 80 is enabled in the firewall on the WAP servers and ADFS servers.
Ensure that probe is set for port 80 and for the endpoint /adfs/probe.

Check the firewall settings

Check if inbound traffic through TCP port 443 is enabled on:

the firewall between the Web Application Proxy server and the federation server
farm.
the firewall between the clients and the Web Application Proxy server.

Check if inbound traffic through TCP port 49443 is enabled on the firewall between the
clients and the Web Application Proxy server when the following conditions are true:

TLS client authentication using X.509 certificate is enabled.

You are using ADFS on Windows Server 2012 R2.

７ Note

The configuration is not required on the firewall between the Web Application
Proxy server and the federation servers.

Check if the endpoint is enabled on the proxy

ADFS provides various endpoints for different functionalities and scenarios. Not all
endpoints are enabled by default. To check the whether the endpoint is enabled on the
proxy, following these steps:
 1. On the ADFS server, open the ADFS Management Console.

2. Expand Service > Endpoints.

3. Locate the endpoint and verify if the status is enabled on the Proxy Enabled
column.

Check the proxy trust relationship

If Web Application Proxy (WAP) is deployed, the proxy trust relationship must be
established between the WAP server and the AD FS server. Check if the proxy trust
relationship is established or starts to fail at some point in time.

７ Note

Information on this page applies to AD FS 2012 R2 and later.

Background information
The proxy trust relationship is client certificate based. When you run the Web
Application Proxy post-install wizard, the wizard generates a self-signed client certificate
using the credentials that you specified in the wizard. Then the wizard inserts the
certificate into the AD FS configuration database and adds it to the AdfsTrustedDevices
certificate store on the AD FS server.

For any SSL communication, http.sys uses the following priority order for SSL certificate
bindings to match a certificate:

ﾉ Expand table
 Priority Name Parameters Description

1 IP IP:port Exact IP and Port match

2 SNI Hostname:port Exact hostname match (connection must specify SNI)

3 CCS Port Invoke Central Certificate Store

4 IPv6 wildcard Port IPv6 wildcard match (connection must be IPv6)

5 IP wildcard Port IP wildcard match (connection can be IPv4 or IPv6)

AD FS 2012 R2 and later are independent of Internet Information Services (IIS) and runs
as a service on top of http.sys. hostname:port SSL certificate bindings are used by AD FS.
During client certificate authentication, AD FS sends a certificate trust list (CTL) based on
the certificates in the AdfsTrustedDevices store. If an SSL certificate binding for your AD
FS server uses IP:port or the CTL store is not AdfsTrustedDevices, proxy trust relationship
may not be established.

Get the SSL certificate bindings for AD FS

On the AD FS server, run the following command in Windows PowerShell:

netsh http show sslcert

In the list of bindings returned, look for those with the Application ID of 5d89a20c-
beab-4389-9447-324788eb944a. Here is an example of a healthy binding. Note the "Ctl
Store Name" line.

Output

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Run script to automatically detect problems

To automatically detect problems with the proxy trust relationship, run the following
script. Based on the problem detected, take the action accordingly.

PowerShell

param
(
[switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for
potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
$ipport = $false
$hostnameport = $false
if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true
}
elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) {
$hostnameport = $true }
## Check for IP specific certificate bindings
if ( ( $ipport -eq $true ) )
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and (
$ipbindingparsed[3].trim() -eq "443") )
{
$warning = "There is an IP specific binding on IP " +
$ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443
cert binding." | Write-Warning
$certbindingissuedetected = $true
}
$i = $i + 14
continue
}
## check that CTL Store is set for ADFS service binding
elseif ( $hostnameport -eq $true )
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and (
$ipbindingparsed[3].trim() -eq "443") -and (
$httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
{
Write-Warning "ADFS Service binding does not have CTL Store
Name set to AdfsTrustedDevices"
$certbindingissuedetected = $true
}
 $i = $i + 14
continue
}
$i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No
certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices
cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-
self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse |
Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
Write-Warning "The following non-self signed certificates are present in
the AdfsTrustedDevices store and should be removed"
$certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in
AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
Param ([bool]$repair=$false)
Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in
sync with ADFS Proxy Trust config")
$doc = new-object Xml

$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
)
$connString =
$doc.configuration.'microsoft.identityServer.service'.policystore.connection
String
$command = "Select ServiceSettingsData from [IdentityServerPolicy].
[ServiceSettings]"
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = $command
$cmd.Connection = $cli
$cli.Open()
$configString = $cmd.ExecuteScalar()
$configXml = new-object XML
$configXml.LoadXml($configString)
$rawCerts =
$configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration.
_subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509
Certificate2
#$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
$store = new-object
System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices"
 ,"LocalMachine")
$store.open("MaxAllowed")
$atLeastOneMismatch = $false
$badCerts = @()
foreach($rawCert in $rawCerts)
{
$rawCertBytes =
[System.Convert]::FromBase64String($rawCert.RawData.'#text')
$cert=New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertByte
s)
$now = Get-Date
if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
{
$certThumbprint = $cert.Thumbprint
$certSubject = $cert.Subject
$ctlMatch = dir
cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction
SilentlyContinue
if ($ctlMatch -eq $null)
{
$atLeastOneMismatch = $true
Write-Warning "This cert is NOT in the CTL: $certThumbprint –
$certSubject"
if ($repair -eq $true)
{
write-Warning "Attempting to repair"
$store.Add($cert)
Write-Warning "Repair successful"
}
else
{
Write-Warning ("Please install KB.2964735 or re-run
script with -syncproxytrustcerts switch to add missing Proxy Trust certs to
AdfsTrustedDevices cert store")
}
}
}
}
$store.Close()
if ($atLeastOneMismatch -eq $false)
{
Write-Host("Check Passed: No mismatched certs found. CTL is in sync
with DB content")
}
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problem 1: There is an IP specific binding

The binding may conflict with the AD FS certificate binding on port 443.

The IP:port binding takes the highest precedence. If an IP:port binding is in the AD FS
SSL certificate bindings, http.sys always uses the certificate for the binding for SSL
communication. To solve this problem, use the following methods.

1. Remove the IP:port binding

Be aware that the IP:port binding may come back after you removed it. For
example, an application configured with this IP:port binding may automatically
recreate it on the next service start-up.

2. Use another IP address for AD FS SSL communication

If the IP:port binding is required, resolve the ADFS service FQDN to another IP
address that is not used in any bindings. That way, http.sys will use the
Hostname:port binding for SSL communication.

3. Set AdfsTrustedDevices as the CTL Store for the IP:port binding

This is the last resort if you can't use the methods above. But it is better to
understand the following conditions before you change the default CTL store to
AdfsTrustedDevices:

Why the IP:port binding is there.

If the binding relies on the default CTL store for client certificate
authentication.

Problem 2: The AD FS certificate binding doesn't have

CTL Store Name set to AdfsTrustedDevices
If Microsoft Entra Connect is installed, use Microsoft Entra Connect to set CTL Store
Name to AdfsTrustedDevices for the SSL certificate bindings on all AD FS servers. If
Microsoft Entra Connect is not installed, regenerate the AD FS certificate bindings by
running the following command on all AD FS servers.

PowerShell

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problem 3: A certificate that is not self-signed exists in

the AdfsTrustedDevices certificate store
If a CA issued certificate is in a certificate store where only self-signed certificates would
normally exist, the CTL generated from the store would only contain the CA issued
certificate. The AdfsTrustedDevices certificate store is such a store that is supposed to
have only self-signed certificates. These certificates are:

MS-Organization-Access: The self-signed certificate used for issuing workplace join

certificates.
ADFS Proxy Trust: The certificates for each Web Application Proxy server.

Therefore, delete any CA issued certificate from the AdfsTrustedDevices certificate store.

Problem 4: Install KB2964735 or re-run the script with -

syncproxytrustcerts
When a proxy trust relationship is established with an AD FS server, the client certificate
is written to the AD FS configuration database and added to the AdfsTrustedDevices
certificate store on the AD FS server. For an AD FS farm deployment, the client certificate
is expected to be synced to the other AD FS servers. If the sync doesn't happen for some
reason, a proxy trust relationship will only work against the AD FS server the trust was
established with, but not against the other AD FS servers.

To solve this problem, use one of the following methods.

Method 1

Install the update documented in KB 2964735 on all AD FS servers. After the update is
installed, a sync of the client certificate is expected to happen automatically.

Method 2
Run the script with the – syncproxytrustcerts switch to manually sync the client
certificates from the AD FS configuration database to the AdfsTrustedDevices certificate
store. The script should be run on all the AD FS servers in the farm.

７ Note

This is not a permanent solution because the client certificates will be renewed on a
regular basis.

Problem 5: All checks are passed. But the problem

persists
Check if there is a time or time zone mismatch. If time matches but the time zone
doesn't, proxy trust relationship will also fail to be established.

Check if there is SSL termination between the AD FS server and the WAP server

If SSL termination is happening on a network device between AD FS servers and the

WAP server, communication between AD FS and WAP will break because the
communication is based on client certificate.

Disable SSL termination on the network device between the AD FS and WAP servers.

Use the Dump Token app

The Dump Token app is helpful when debugging problems with your federation service
as well as validating custom claim rules. It is not an official solution but a good
independent debugging solution that is recommended for the troubleshooting
purposes.

Before using the Dump Token app

Before using the Dump Token app, you need to:

1. Get the information of the relying party for the application you want to access. If
OAuth authentication is implemented, get the OAuth client information as well.
2. Set up the Dump Token app.

Get the relying party and OAuth client information

If you use a conventional relying party, follow these steps:
 1. On the AD FS server, open Windows PowerShell with the Run as administrator
option.

2. Add the AD FS 2.0 component to Windows PowerShell by running the following

command:

PowerShell

Add-PSSnapin Microsoft.Adfs.PowerShell

3. Get the relying party information by running the following command:

PowerShell

$rp = Get-AdfsRelyingPartyTrust RPName

4. Get the OAuth client information by running the following command:

PowerShell

$client = Get-AdfsClient ClientName

If you use the Application Group feature in Windows Server 2016, follow the steps
below:

1. On the AD FS server, open Windows PowerShell with the Run as administrator

option.

2. Get the relying party information by running the following command:

PowerShell

$rp = Get-AdfsWebApiApplication ResourceID

3. If the OAuth client is public, get the client information by running the following
command:

PowerShell

$client = Get-AdfsNativeClientApplication ClientName

If the OAuth client is confidential, get the client information by running the
following command:
 PowerShell

$client = Get-AdfsServerApplication ClientName

Set up the Dump Token app

To set up the Dump Token app, run the following commands in the Windows PowerShell
window:

PowerShell

$authzRules = "=>issue(Type =
`"http://schemas.microsoft.com/authorization/claims/permit`", Value =
`"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol
SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken"
-IssuanceAuthorizationRules $authzRules -IssuanceTransformRules
$issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Now continue with the following troubleshooting methods. At the end of each method,
see if the problem is solved. If not, use another method.

Troubleshooting methods

Check the authorization policy to see if the user is impacted

In this method, you start by getting the policy details, and then use the Dump Token
app to diagnose the policy to see if the user is impacted.

Get the policy details

$rp.IssuanceAuthorizationRules shows the authorization rules of the relying party.

In Windows Server 2016 and later versions, you can use $rp. AccessControlPolicyName
to configure authentication and authorization policy. If $rp. AccessControlPolicyName
has value, an access control policy is in place which governs the authorization policy. In
that case, $rp.IssuanceAuthorizationRules is empty. Use $rp.ResultantPolicy to find out
details about the access control policy.
If $rp.ResultantPolicy doesn't have the details about the policy, look into the actual claim
rules. To get the claim rules, follow these steps:

1. Set the access control policy to $null by running the following command:
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName

$null

2. Get the relying party information by running the following command:

$rp = Get-AdfsRelyingPartyTrust RPName

3. Check $rp.IssuanceAuthorizationRules and $rp. AdditionalAuthenticationRules .

Use the Dump Token app to diagnose the authorization policy

1. Set the Dump Token authentication policy to be the same as the failing relying
party.

2. Have the user open one of the following links depending on the authentication
policy you set.

WS-Fed: https://FederationInstance/adfs/ls?
wa=wsignin1.0&wtrealm=urn:dumptoken

SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?
LoginToRP=urn:dumptoken

Force multi-factor authentication: https://FederationInstance/adfs/ls?

wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/cl
aims/multipleauthn

3. Log in on the Sign-In page.

What you get is the set of claims of the user. See if there is anything in the authorization
policy that explicitly denies or allows the user based on these claims.

Check if any missing or unexpected claim causes access deny to the

resource
1. Configure the claim rules in the Dump Token app to be the same as the claim rules
of the failing relying party.

2. Configure the Dump Token authentication policy to be the same as the failing
relying party.

3. Have the user open one of the following links depending on the authentication
policy you set.
 WS-Fed: https://FederationInstance/adfs/ls?
wa=wsignin1.0&wtrealm=urn:dumptoken

SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?
LoginToRP=urn:dumptoken

Force multi-factor authentication: https://FederationInstance/adfs/ls?

wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/cl
aims/multipleauthn

4. Log in on the Sign-In page.

This is the set of claims the relying party is going to get for the user. If any claims are
missing or unexpected, look at the issuance policy to find out the reason.

If all the claims are present, check with the application owner to see which claim is
missing or unexpected.

Check if a device state is required

If the authorization rules check for device claims, verify if any of these device claims are
missing in the list of claims you get from the Dump Token app. The missing claims could
block device authentication. To get the claims from the Dump Token app, follow the
steps in the Use the Dump Token app to diagnose the authorization policy section in
the Check authorization policy if the user was impacted method.

The following are the device claims. The authorization rules may use some of them.

http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname

http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier

http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion

http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser

http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown

http://schemas.microsoft.com/2014/02/deviceusagetime
http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant

http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

If there is a missing claim, follow the steps in Configure On-Premises Conditional Access
using registered devices to make sure the environment is setup for device
authentication.
If all the claims are present, see if the values of the claims from the Dump Token app
match the values required in the authorization policy.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Users can't sign in to the domain after
password changes on a Remote Domain
Controller
Article • 02/19/2024

This article provides a solution to an issue where users can't sign in to the domain after
password changes on a Remote Domain Controller.

Applies to: Windows 2000

Original KB number: 318364

Symptoms
After you change a user account password on a remote domain controller that holds the
primary domain controller (PDC) Flexible Single Master Operation (FSMO) role, the user
may not be able to sign in to a local domain controller by entering the new password.
However, the user may still be able to sign in to the domain by using their previous
password.

Cause
This behavior may occur when the following conditions are true:

The remote domain controller hasn‘t yet replicated with the local domain
controller.

Kerberos is configured to use User Datagram Protocol (UDP) protocol (the default
configuration).

The user's security token is too large to fit in a UDP Kerberos message.

７ Note

The user's security token may be large if that user is a member of many
groups.

This problem is caused by the anti-replay feature of Kerberos authentication on the local
domain controller. The following steps illustrate this behavior:
 1. The user account password is changed on the remote domain controller, but that
change hasn’t yet been replicated to the local domain controller.
2. The user tries to sign in to the domain by using the new password. The Kerberos
Authentication Service Exchange message (KRB_AS_REQ) is sent to the local
domain controller by using UDP.
3. The local domain controller fails the authentication because it doesn't yet have the
new password information.
4. The local domain controller forwards the request to the remote PDC
( KDCSVC!FailedLogon ).
5. In the FailedLogon function, an entry for the request is entered into the replay-
detection table, and the KRB_AS_REQ message is sent to the remote PDC.
6. The remote PDC successfully authenticates the request, and then returns a positive
reply to the local domain controller.
7. The local domain controller detects that the reply is too large for a UDP packet,
and that's why sends a request to the client computer to resend the request by
using Transmission Control Protocol (TCP).
8. The client computer resubmits the authentication request by using TCP.
9. The local domain controller fails the authentication because it doesn't yet have the
new password information (as in step 3).
10. The local domain controller forwards the request to the remote PDC domain
controller ( KDCSVC!FailedLogon ) (as in step 4).
11. The replay detection check in the FailedLogon function returns a
KRB_AP_ERR_REPEAT message because an entry for this request is already present
in the replay detection table. This is the entry that was created in step 5.

The authentication attempt fails.

Resolution
To resolve this problem, obtain the latest service pack for Windows 2000.

The English version of this fix has the file attributes (or later) that are listed in the
following table. The dates and times for these files are listed in coordinated universal
time (UTC). When you view the file information, it's converted to local time. To find the
difference between UTC and local time, use the Time Zone tab in the Date and Time tool
in Control Panel.

Console

Date Time Version Size File name

-----------------------------------------------------------
22-Mar-2002 23:55 5.0.2195.4959 123,664 Adsldp.dll
 30-Jan-2002 00:52 5.0.2195.4851 130,832 Adsldpc.dll
30-Jan-2002 00:52 5.0.2195.4016 62,736 Adsmsext.dll
22-Mar-2002 23:55 5.0.2195.5201 356,624 Advapi32.dll
22-Mar-2002 23:55 5.0.2195.4985 135,952 Dnsapi.dll
22-Mar-2002 23:55 5.0.2195.4985 95,504 Dnsrslvr.dll
22-Mar-2002 23:56 5.0.2195.5013 521,488 Instlsa5.dll
22-Mar-2002 23:55 5.0.2195.5246 145,680 Kdcsvc.dll
22-Mar-2002 23:50 5.0.2195.5246 199,952 Kerberos.dll
07-Feb-2002 19:35 5.0.2195.4914 71,024 Ksecdd.sys
02-Mar-2002 21:32 5.0.2195.5013 503,568 Lsasrv.dll
02-Mar-2002 21:32 5.0.2195.5013 33,552 Lsass.exe
08-Dec-2001 00:05 5.0.2195.4745 107,280 Msv1_0.dll
22-Mar-2002 23:55 5.0.2195.4917 306,960 Netapi32.dll
22-Mar-2002 23:55 5.0.2195.4979 360,208 Netlogon.dll
22-Mar-2002 23:55 5.0.2195.5221 917,264 Ntdsa.dll
22-Mar-2002 23:55 5.0.2195.5201 386,832 Samsrv.dll
30-Jan-2002 00:52 5.0.2195.4874 128,784 Scecli.dll
22-Mar-2002 23:55 5.0.2195.4968 299,792 Scesrv.dll
30-Jan-2002 00:52 5.0.2195.4600 48,400 W32time.dll
06-Nov-2001 19:43 5.0.2195.4600 56,592 W32tm.exe
22-Mar-2002 23:55 5.0.2195.5011 125,712 Wldap32.dll

Workaround
To work around this issue, do user account password changes on the local domain
controller or force Kerberos to use TCP (Transmission Control Protocol) instead of UDP
(User Datagram Protocol).

For more information, see How to force Kerberos to use TCP instead of UDP in
Windows .

Status
Microsoft has confirmed that it's a problem in the Microsoft products that are listed at
the beginning of this article. This problem was first corrected in Windows 2000 Service
Pack 3.

More information
The Kerberos anti-replay feature prevents the same packet from being received two
times by the authenticating server. A replay attack is an attack in which a valid data
transmission is maliciously or fraudulently repeated, either by the originator or by an
adversary who intercepts the data and retransmits it. An attacker may attempt to
"replay" a valid user's user name and password in an attempt to authenticate by using
that user's credentials.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error Attempting to Seize RID Master
Role with Ntdsutil
Article • 02/19/2024

This article provides help to fix an error that occurs when you seize the relative ID (RID)
Master role with the Ntdsutil tool to a different domain controller.

Applies to: Windows Server 2012 R2

Original KB number: 2001165

Symptoms
Assume the following scenario. The server that holds the RID operations master role is
no longer accessible and must be rebuilt. You attempt to seize the RID Master role with
the Ntdsutil tool to a different domain controller but you receive the following error:

Attempting safe transfer of RID FSMO before seizure.

ldap_modify_sW error 0x34(52 (Unavailable).
Ldap extended error message is 000020AF: SvcErr: DSID-0321093D, problem 5002
(UNAVAILABLE), data 8
Win32 error returned is 0x20af (The requested FSMO operation failed. The current
FSMO holder could not be contacted.)
Depending on the error code this may indicate a connection, ldap, or role transfer
error.
Transfer of RID FSMO failed, proceeding with seizure ...
Search failed to find any Domain Controllers

Cause
The fSMORoleOwner attribute of the RID Manager$ object in Active Directory is invalid.
For example, the following value would result in this error:

CN=NTDS Settings DEL:a586a105-5a9c-4b2f-8289-

bc5b43841ac8,CN=DC01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com

Resolution
To resolve this issue, use the AdsiEdit tool to update the fSMORoleOwner attribute of
the Rid Manager$ object in Active Directory.

1. Open AdsiEdit (AdsiEdit.msc).

2. Expand Domain, then select CN=System.

3. With CN=System selected in the left pane, right-click CN=RID Manager$ and
select Properties.

4. The fSMORoleOwner attribute should correspond to the old RID Master. For
example, if DC01 was the old RID Master (the server that is no longer available),
the fSMORoleOwner attribute would be:

CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com

An example of an invalid value for the fSMORoleOwner attribute that may result in
an error when attempting to seize the role would be:

CN=NTDS Settings DEL:a586a105-5a9c-4b2f-8289-

bc5b43841ac8,CN=DC01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com

5. Change the fSMORoleOwner attribute value to reflect the domain controller that
you want to be the RID Master. For example if DC01 is the failed domain controller,
and DC02 is the domain controller to which you want to seize the RID Master role,
you would change the attribute to reflect that DC02 will be the new RID Master.

CN=NTDS Settings,CN=DC02,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com

6. Changing the fSMORoleOwner attribute accomplishes the same thing as seizing

the role with Ntdsutil. Therefore after changing the attribute manually you do not
need to use Ntdsutil to seize the role.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How To Find Servers That Hold Flexible
Single Master Operations Roles
Article • 02/19/2024

This article describes how to find the servers that hold the Flexible Single Master
Operation (FSMO) roles in a forest.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 234790

Summary
Active Directory defines five FSMO roles:

Schema master
Domain naming master
RID master
PDC master
Infrastructure master

The schema master and the domain naming master are per-forest roles. Therefore, there
is only one schema master and one domain naming master per forest.

The RID master, the PDC master, and the infrastructure master are per-domain roles.
Each domain has its own RID master, PDC master, and infrastructure master. Therefore,
if a forest has three domains, there are three RID masters, three PDC masters, and three
infrastructures masters.

Determine the RID, PDC, and Infrastructure

FSMO Holders of a Selected Domain
1. Click Start, click Run, type dsa.msc, and then click OK.
2. Right-click the selected Domain Object in the top-left pane, and then click
Operations Masters.
3. Click the PDC tab to view the server holding the PDC master role.
4. Click the Infrastructure tab to view the server holding the Infrastructure master
role.
5. Click the RID Pool tab to view the server holding the RID master role.
Determine the Schema FSMO Holder in a
Forest
1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active
Directory Schema, click Close, and then click OK.
3. Right-click Active Directory Schema in the top-left pane, and then click Operations
Masters to view the server holding the schema master role.

７ Note

For the Active Directory Schema snap-in to be available, you may have to register
the Schmmgmt.dll file. To do this, click Start , click Run , type regsvr32
schmmgmt.dll in the Open box, and then click OK . A message is displayed that
states the registration was successful.

Determine the Domain Naming FSMO Holder

in a Forest
1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active
Directory Domains and Trusts, click Close, and then click OK.
3. In the left pane, click Active Directory Domains and Trusts.
4. Right-click Active Directory Domains and Trust, and then click Operations Master
to view the server holding the domain naming master role in the Forest.

Use the Windows 2000 Server Resource Kit

The Windows 2000 Resource Kit contains a .cmd file called Dumpfsmos.cmd that you
can use to quickly list FSMO role owners for your current domain and forest. The .cmd
file uses Ntdsutil.exe to enumerate the role owners. The Dumpfsmos.cmd file contains:

Console

@echo off
REM
REM Script to dump FSMO role owners on the server designated by %1
REM

if ""=="%1" goto usage

 Ntdsutil roles Connections "Connect to server %1" Quit "select Operation
Target" "List roles for connected server" Quit Quit Quit

goto done

:usage

@echo Please provide the name of a domain controller (i.e. dumpfsmos MYDC)
@echo.

:done

Use the NTDSUTIL Tool

NTDSUTIL is a tool included with Windows 2000 Server, Windows 2000 Advanced
Server, and Windows 2000 Datacenter Server. This tool is can be used to verify change
certain aspects of the Active Directory. The following is the steps needed to view the
Flexible Single Master Operation (FSMO) roles on a given Domain Controller.

Ntdsutil.exe is the only tool that shows you all the FSMO role owners. You can view the
PDC emulator, RID master, and infrastructure master role owners in Active Directory
Users and Computers. You can view the schema master role owner in the Active
Directory Schema snap-in. You can view the domain naming master role owner in Active
Directory Domains and Trusts.

1. Click Start, click Run, type cmd in the Open box, and then press ENTER.

2. Type ntdsutil, and then press ENTER.

3. Type domain management, and then press ENTER.

4. Type connections, and then press ENTER.

5. Type connect to server ServerName, where ServerName is the Name of the

Domain Controller you would like to view, and then press ENTER.

6. Type quit, and then press ENTER.

7. Type select operation target, and then press ENTER.

8. Type list roles for connected server, and then press ENTER. A list is displayed
similar to what is listed below. Results may very depending on the roles the
particular Domain Controller may hold. If you receive an error message, check the
spelling of the commands as the syntax of the commands must be exact. If you
need the syntax of a command, type? at each prompt:
 Console

Server "dc1" knows about 5 roles

Schema - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Domain - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=corp,DC=com
PDC - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=corp,DC=com
RID - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Infrastructure - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=corp,DC=com

Use DCDIAG
On a Windows 2000 Domain Controller, run the following command:

Console

DCdiag /test:Knowsofroleholders /v

You must use the /v switch. This lists the owners of all FSMO roles in the enterprise.

References
For additional information, click the article numbers below to view the articles:

197132 Windows 2000 Active Directory FSMO Roles

223346 FSMO Placement and Optimization on Windows 2000 Domains

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory FSMO roles in Windows
Article • 02/19/2024

This article mainly helps you to learn about the Flexible Single Master Operation (FSMO)
roles in Active Directory.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019,
Windows Server 2022
Original KB number: 197132

Summary
Active Directory is the central repository in which all objects in an enterprise and their
respective attributes are stored. It's a hierarchical, multi-master enabled database that
can store millions of objects. Changes to the database can be processed at any given
domain controller (DC) in the enterprise, regardless of whether the DC is connected or
disconnected from the network.

Multi-master model
A multi-master enabled database, such as the Active Directory, provides the flexibility of
allowing changes to occur at any DC in the enterprise. But it also introduces the
possibility of conflicts that can potentially lead to problems once the data is replicated
to the rest of the enterprise. One way Windows deals with conflicting updates is by
having a conflict resolution algorithm handle discrepancies in values. It's done by
resolving to the DC to which changes were written last, which is the last writer wins. The
changes in all other DCs are discarded. Although this method may be acceptable in
some cases, there are times when conflicts are too difficult to resolve using the last
writer wins approach. In such cases, it's best to prevent the conflict from occurring
rather than to try to resolve it after the fact.

For certain types of changes, Windows incorporates methods to prevent conflicting

Active Directory updates from occurring.

Single-master model
To prevent conflicting updates in Windows, the Active Directory performs updates to
certain objects in a single-master fashion. In a single-master model, only one DC in the
entire directory is allowed to process updates. It's similar to the role given to a primary
domain controller (PDC) in earlier versions of Windows, such as Microsoft Windows NT
3.51 and 4.0. In earlier versions of Windows, the PDC is responsible for processing all
updates in a given domain.

Active Directory extends the single-master model found in earlier versions of Windows
to include multiple roles, and the ability to transfer roles to any DC in the enterprise.
Because an Active Directory role isn't bound to a single DC, it's referred to as an FSMO
role. Currently in Windows there are five FSMO roles:

Schema master
Domain naming master
RID master
PDC emulator
Infrastructure master

Typically, an FSMO role ownership is executed only when the domain controller has
replicated the naming context (NC) where the ownership is stored since the Directory
Service started. Make sure that an FSMO role seizure reaches the previous owner before
the role is used.

Schema master FSMO role

The schema master FSMO role holder is the DC responsible for performing updates to
the directory schema, that is, the schema naming context or
LDAP://cn=schema,cn=configuration,dc=<domain>. This DC is the only one that can
process updates to the directory schema. Once the Schema update is complete, it's
replicated from the schema master to all other DCs in the directory. There's only one
schema master per forest.

Initial replication and connectivity requirements

This FSMO role holder is only active when the role owner has inbound replicated
the schema NC successfully since the Directory Service started.
DCs and members of the forest only contact the FSMO role when they update the
schema.

Domain naming master FSMO role

The domain naming master FSMO role holder is the DC responsible for making changes
to the forest-wide domain name space of the directory, that is, the
Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration,
DC=<domain>. This DC is the only one that can add or remove a domain from the
directory. It can also add or remove cross references to domains in external directories.

Initial replication and connectivity requirements

This FSMO role holder is only active when the role owner has inbound replicated
the configuration NC successfully since the Directory Service started.

Domain members of the forest only contact the FSMO role holder when they
update the cross-references. DCs contact the FSMO role holder when:
Domains are added or removed in the forest.
New instances of application directory partitions on DCs are added. For
example, a DNS server has been enlisted for the default DNS application
directory partitions.

RID master FSMO role

The RID master FSMO role holder is the single DC responsible for processing RID Pool
requests from all DCs within a given domain. It's also responsible for removing an object
from its domain and putting it in another domain during an object move.

When a DC creates a security principal object, such as a user or group, it attaches a

unique Security ID (SID) to the object. This SID consists of:

A domain SID that's the same for all SIDs created in a domain.
A relative ID (RID) that's unique for each security principal SID created in a domain.

Each Windows DC in a domain is allocated a pool of RIDs that it's allowed to assign to
the security principals it creates. When a DC's allocated RID pool falls below a threshold,
that DC issues a request for additional RIDs to the domain's RID master. The domain RID
master responds to the request by retrieving RIDs from the domain's unallocated RID
pool, and assigns them to the pool of the requesting DC. There's one RID master per
domain in a directory.

Initial replication and connectivity requirements

This FSMO role holder is active only when the role owner has inbound replicated
the domain NC successfully since the Directory Service started.
DCs contact the FSMO role holder when they retrieve a new RID pool. The new RID
pool is delivered to DCs through AD replication.
PDC emulator FSMO role
The PDC emulator is necessary to synchronize time in an enterprise. Windows includes
the W32Time (Windows Time) time service that is required by the Kerberos
authentication protocol. All Windows-based computers within an enterprise use a
common time. The purpose of the time service is to ensure that the Windows Time
service uses a hierarchical relationship that controls authority. It doesn't permit loops to
ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the
root of the forest becomes authoritative for the enterprise, and should be configured to
gather the time from an external source. All PDC FSMO role holders follow the hierarchy
of domains in the selection of their in-bound time partner.

In a Windows domain, the PDC emulator role holder retains the following functions:

Password changes done by other DCs in the domain are replicated preferentially to
the PDC emulator.
When authentication failures occur at a given DC because of an incorrect
password, the failures are forwarded to the PDC emulator before a bad password
failure message is reported to the user.
Account lockout is processed on the PDC emulator.
The PDC emulator performs all of the functionality that a Windows NT 4.0 Server-
based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary under the following situation:
All workstations, member servers, and domain controllers (DCs) that are running
Windows NT 4.0 or earlier are all upgraded to Windows 2000.

The PDC emulator still does the other functions as described in a Windows 2000
environment.

The following information describes the changes that occur during the upgrade process:

Windows clients (workstations and member servers) and down-level clients that
have installed the distributed services client package don't perform directory writes
(such as password changes) preferentially at the DC that has advertised itself as the
PDC. They use any DC for the domain.
Once backup domain controllers (BDCs) in down-level domains are upgraded to
Windows 2000, the PDC emulator receives no down-level replica requests.
Windows clients (workstations and member servers) and down-level clients that
have installed the distributed services client package use the Active Directory to
locate network resources. They don't require the Windows NT Browser service.
Initial replication and connectivity requirements
This FSMO role holder is always active when the PDC emulator finds the
fSMORoleOwner attribute of the domain NC head points to itself. There is no
inbound replication requirement.

DCs contact the FSMO role holder when they have a new password, or the local
password verification fails. No error occurs when the PDC emulator can't be
reached or the AvoidPdcOnWan registry value is set to 1.

You can use the following cmdlet to run the prerequisites for demoting a DC.

PowerShell

PS C:\Users\Capecodadmin> Test-ADDSDomainControllerUninstallation -
DemoteOperationMasterRole |fl

Here is an output example when the PDC emulator can't be reached.

Message : Verification of prerequisites for Domain Controller promotion failed.

You indicated that this Active Directory domain controller is not the last
domain controller for the domain "contoso.com". However, no other domain
controller for that domain can be contacted. Proceeding will cause any Active
Directory Domain Services changes that have been made on this domain
controller to be lost. To proceed anyway, specify the
'IgnoreLastDCInDomainMismatch' option.
Context : Test.VerifyDcPromoCore.DCPromo.General.50
RebootRequired : False
Status : Error

Infrastructure master FSMO role

When an object in one domain is referenced by another object in another domain, it
represents the reference by:

The GUID
The SID (for references to security principals)
The DN of the object being referenced

The infrastructure FSMO role holder is the DC responsible for updating an object's SID
and distinguished name in a cross-domain object reference.

７ Note
 The Infrastructure Master (IM) role should be held by a DC that is not a Global
Catalog server(GC). If the Infrastructure Master runs on a Global Catalog server it
will stop updating object information because it does not contain any references to
objects that it does not hold. This is because a Global Catalog server holds a partial
replica of every object in the forest. As a result, cross-domain object references in
that domain will not be updated and a warning to that effect will be logged on that
DC's event log.

If all the DCs in a domain also host the global catalog, all the DCs have the current data.
It isn't important which DC holds the infrastructure master role.

When the Recycle Bin optional feature is enabled, every DC is responsible to update its
cross-domain object references when the referenced object is moved, renamed, or
deleted. In this case, there are no tasks associated with the Infrastructure FSMO role.
And it isn't important which domain controller owns the Infrastructure Master role. For
more information, see 6.1.5.5 Infrastructure FSMO Role.

Initial replication and connectivity requirements

This FSMO role holder is active only when the role owner has inbound replicated
the domain NC successfully since the Directory Service started.
There is no connectivity requirement for this FSMO role holder. It is a forest
internal cleanup functionality.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Transfer or seize Operation Master roles
in Active Directory Domain Services
Article • 02/19/2024

This article describes when and how to transfer or seize Operation Master roles, formerly
known as Flexible Single Master Operations (FSMO) roles.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
Original KB number: 255504

More information
Within an Active Directory Domain Services (AD DS) forest, there are specific tasks that
must be performed by only one domain controller (DC). The DCs that are assigned to
perform these unique operations are known as Operation Master role holders. The
following table lists the Operation Master roles, and their placement in Active Directory.

ﾉ Expand table

Role Scope Naming context (Active Directory partition)

Schema master Forest-wide CN=Schema,CN=configuration,DC=<forest root

domain>

Domain naming Forest-wide CN=configuration,DC=<forest root domain>

master

PDC emulator Domain- DC=<domain>

wide

RID master Domain- DC=<domain>

wide

Infrastructure master Domain- DC=<domain>

wide

For more information about the Operation Master role holders and recommendations
for placing the roles, see FSMO placement and optimization on Active Directory domain
controllers.

７ Note
 Active Directory Application partitions that include DNS application partitions have
Operation Master role links. If a DNS application partition defines an owner for the
infrastructure master (IM) role, you can't use Ntdsutil, DCPromo, or other tools to
remove that application partition. For more information, see DCPROMO demotion
fails if unable to contact the DNS infrastructure master.

When a DC that has been acting as a role holder starts to run (for example, after a
failure or a shutdown), it doesn't immediately resume behaving as the role holder. The
DC waits until it receives inbound replication for its naming context (for example, the
Schema master role owner waits to receive inbound replication of the Schema partition).

The information that the DCs pass as part of Active Directory replication includes the
identities of the current Operation Master role holders. When the newly started DC
receives the inbound replication information, it verifies whether it's still the role holder. If
it is, it resumes typical operations. If the replicated information indicates that another
DC is acting as the role holder, the newly started DC relinquishes its role ownership. This
behavior reduces the chance that the domain or forest will have duplicate Operation
Master role holders.

） Important

AD FS operations fail if they require a role holder and if the newly started role
holder is, in fact, the role holder and it doesn't receive inbound replication.
The resulting behavior resembles what would happen if the role holder was offline.

Determine when to transfer or seize roles

Under typical conditions, all five roles must be assigned to "live" DCs in the forest. When
you create an Active Directory forest, the Active Directory Installation Wizard
(Dcpromo.exe) assigns all five Operation Master roles to the first DC that it creates in the
forest root domain. When you create a child or tree domain, the creation mechanism
assigns the three domain-wide roles to the first DC in the domain.

DCs continue to own Operation Master roles until they're reassigned by using one of
the following methods:

An administrator reassigns the role by using a GUI administrative tool.

An administrator reassigns the role by using the ntdsutil /roles command.
An administrator gracefully demotes a role-holding DC by using the Active
Directory Installation Wizard. This wizard reassigns any locally held roles to an
 existing DC in the forest.
An administrator demotes a role-holding DC by using the Uninstall-
ADDSDomainController -ForceRemoval or dcpromo /forceremoval command.

The DC shuts down and restarts. When the DC restarts, it receives inbound
replication information that indicates that another DC is the role holder. In this
case, the newly started DC relinquishes the role (as described previously).

If an Operation Master role holder experiences a failure or is otherwise taken out of

service before its roles are transferred, you must seize and transfer all roles to an
appropriate and healthy DC.

We recommend that you transfer Operation Master roles in the following scenarios:

The current role holder is operational and can be accessed on the network by the
new Operation Master owner.
You're gracefully demoting a DC that currently owns Operation Master roles that
you want to assign to a specific DC in your Active Directory forest.
The DC that currently owns Operation Master roles is being taken offline for
scheduled maintenance, and you have to assign specific Operation Master roles to
live DCs. You may have to transfer roles to perform operations that affect the
Operation Master owner. This is especially true for the PDC Emulator role. This is a
less important issue for the RID master role, the Domain naming master role, and
the Schema master roles.

We recommend that you seize Operation Master roles in the following scenarios:

The current role holder is experiencing an operational error that prevents an

Operation Master-dependent operation from completing successfully, and you
can't transfer the role.

You use the Uninstall-ADDSDomainController -ForceRemoval or dcpromo

/forceremoval command to force-demote a DC that owns an Operation Master

role.

） Important

The force-demote command can leave Operation Master roles in an invalid

state until they're reassigned by an administrator.

The operating system on the computer that originally owned a specific role no
longer exists or has been reinstalled.
 ７ Note

We recommend that you only seize all roles when the previous role holder
isn't returning to the domain.
If Operation Master roles have to be seized in forest recovery scenarios, see
step 5 in Perform initial recovery under the Restore the first writeable
domain controller in each domain section.
After a role transfer or seizure, the new role holder doesn't act immediately.
Instead, the new role holder behaves like a restarted role holder and waits for
its copy of the naming context for the role (such as the domain partition) to
complete a successful inbound replication cycle. This replication requirement
helps make sure that the new role holder is as up to date as possible before it
takes action. It also limits the window of opportunity for errors. This window
includes only changes that the previous role holder did not finish replicating
to the other DCs before it went offline. For a list of the naming context for
each Operation Master role, see the table at the More information section.

Identify a new role holder

The best candidate for the new role holder is a DC that meets the following criteria:

It resides in the same domain as the previous role holder.

It has the most recent replicated writable copy of the role partition.

For example, assume that you have to transfer the Schema master role. The Schema
master role is part of the schema partition of the forest
(CN=Schema,CN=Configuration,DC=<forest root domain>). The best candidate for a
new role holder is a DC that also resides in the forest root domain, and in the same
Active Directory site as the current role holder.

Ｕ Caution

The infrastructure master role isn't needed anymore if the following conditions are
true:

All domain controllers in the domain are Global Catalogs (GCs). In this case,
the GCs get updates that remove cross-domain references.
 The AD Recycle Bin is enabled in the forest. In this case, each DC is
responsible for updating its references.

We recommend you still define a proper owner of the infrastructure master to

avoid errors and warnings from monitoring tools.

If you still need the infrastructure master role:

Don't put the infrastructure master role on the same DC as the global catalog
server. If the infrastructure master runs on a global catalog server, it stops updating
object information because it does not contain any references to objects that it
doesn't hold. This is because a global catalog server holds a partial replica of every
object in the forest.

The infrastructure master role isn't used anymore once you enable Active Directory
Recycle Bin. AD Recycle Bin changes the approach to handling object referrals that
are being removed.

To test whether a DC is also a global catalog server, follow these steps:

Using Active Directory Sites and Services:

1. Select Start > Programs > Administrative Tools > Active Directory Sites and
Services.
2. In the navigation pane, double-click Sites and then locate the appropriate site
or select Default-first-site-name if no other sites are available.
3. Open the Servers folder, and then select the DC.
4. In the DC's folder, double-click NTDS Settings.
5. On the Action menu, select Properties.
6. On the General tab, view the Global Catalog check box to see whether it's
selected.

Using Windows PowerShell:

1. Start PowerShell.

2. Type the following cmdlet, and adjust DC_NAME with your actual DC name:

PowerShell

(Get-ADDomainController -Filter { Name -Eq 'DC_NAME'

}).IsGlobalCatalog
 3. The output will be True or False .

For more information, see:

AD Forest Recovery - Seizing an operations master role

Planning Operations Master Role Placement

Seize or transfer Operation Master roles

You can use Windows PowerShell or Ntdsutil to seize or transfer roles. For information
and examples of how to use PowerShell for these tasks, see Move-
ADDirectoryServerOperationMasterRole.

） Important

To avoid the risk of duplicate SIDs in the domain, Rid Master seizures increment the
next available RID in the pool when you seize the RID master role. This behavior can
cause your forest to consume available ranges of RID values significantly (also
known as RID burn). So seize the Rid Master only when you're sure that the current
Rid Master can't be brought back into service.

If you have to seize the RID master role, consider the following details:

The Move-ADDirectoryServerOperationMasterRole cmdlet increases the next

Rid pool by 30,000 from what it finds in Active Directory.
When you use the Ntdsutil.exe utility with the roles category commands, it
increases the next Rid pool by 10,000.

To seize or transfer the Operation Master roles by using the Ntdsutil utility, follow these
steps:

1. Sign in to a member computer that has the AD RSAT tools installed, or a DC that is
located in the forest where Operation Master roles are being transferred.

７ Note

We recommend that you log on to the DC to which you are assigning

Operation Master roles.
The signed-in user should be a member of the Enterprise Administrators
group to transfer Schema master or Domain naming master roles, or a
 member of the Domain Administrators group of the domain where the
PDC emulator, RID master and the infrastructure master roles are being
transferred.

2. Select Start > Run, type ntdsutil in the Open box, and then select OK.

3. Type roles, and then press Enter.

７ Note

To see a list of available commands at any one of the prompts in the Ntdsutil
utility, type ?, and then press Enter.

4. Type connections, and then press Enter.

5. Type connect to server <servername>, and then press Enter.

７ Note

In this command, <servername> is the name of the DC that you want to

assign the Operation Master role to.

6. At the server connections prompt, type q, and then press Enter.

7. Do one of the following actions:

To transfer the role: Type transfer <role>, and then press Enter.

７ Note

In this command, <role> is the role that you want to transfer.

To seize the role: Type seize <role>, and then press Enter.

７ Note

In this command, <role> is the role that you want to seize.

For example, to seize the RID master role, type seize rid master. Exceptions are for
the PDC emulator role, whose syntax is seize pdc, and the Domain naming master,
whose syntax is seize naming master.
 To see a list of roles that you can transfer or seize, type ? at the fsmo maintenance
prompt, and then press Enter, or see the list of roles at the start of this article.

8. At the fsmo maintenance prompt, type q, and then press Enter to gain access to
the ntdsutil prompt. Type q, and then press Enter to quit the Ntdsutil utility.

Considerations when repairing or removing

previous role holders
If it's possible, and if you're able to transfer the roles instead of seizing them, fix the
previous role holder. If you can't fix the previous role holder, or if you seized the roles,
remove the previous role holder from the domain.

） Important

If you plan to use the repaired computer as a DC, we recommend that you rebuild
the computer into a DC from scratch instead of restoring the DC from a backup.
The restoration process rebuilds the DC as a role holder again.

To return the repaired computer to the forest as a DC:

1. Do one of the following actions:

Format the hard disk of the former role holder, and then reinstall Windows
on the computer.
Forcibly demote the former role holder to a member server.

2. On another DC in the forest, use Ntdsutil to remove the metadata for the
former role holder. For more information, see To clean up server metadata by
using Ntdsutil.

3. After you clean up the metadata, you can repromote the computer to a DC,
and transfer a role back to it.

To remove the computer from the forest after seizing its roles:

1. Remove the computer from the domain.

2. On another DC in the forest, use Ntdsutil to remove the metadata for the
former role holder. For more information, see To clean up server metadata by
using Ntdsutil.
Considerations when reintegrating replication
islands
When part of a domain or forest can't communicate with the rest of the domain or
forest for an extended time, the isolated sections of domain or forest are known as
replication islands. DCs in one island can't replicate with the DCs in other islands. Over
multiple replication cycles, the replication islands fall out of sync. If each island has its
own Operation Master role holders, you may have problems when you restore
communication between the islands.

） Important

In most cases, you can take advantage of the initial replication requirement (as
described in this article) to weed out duplicate role holders. A restarted role holder
should relinquish the role if it detects a duplicate role-holder.
You may encounter circumstances that this behavior does not resolve. In such
cases, the information in this section may be helpful.

The following table identifies the Operation Master roles that can cause problems if a
forest or domain has multiple role-holders for that role:

ﾉ Expand table

Role Potential conflicts between multiple role-holders?

Schema master Yes

Domain naming master Yes

RID master Yes

PDC emulator No

Infrastructure master No

This issue doesn't affect the PDC Emulator master or the infrastructure master. These
role holders don't persist operational data. Additionally, the Infrastructure master
doesn't make changes often. Therefore, if multiple islands have these role holders, you
can reintegrate the islands without causing long-term issues.

The Schema master, the Domain naming master, and the RID master can create objects
and persist changes in Active Directory. Each island that has one of these role holders
could have duplicate and conflicting schema objects, domains, or RID pools by the time
that you restore replication. Before you reintegrate islands, determine which role holders
to keep. Remove any duplicate Schema masters, Domain Naming masters, and RID
masters by following the repair, removal, and cleanup procedures that are mentioned in
this article.

References
For more information, see:

Active Directory FSMO roles in Windows

FSMO placement and optimization on Active Directory domain controllers
Flexible Single Master Operation Transfer and Seizure Process
HOW TO: Use Ntdsutil to find and clean up duplicate security identifiers in
Windows Server
Phantoms, tombstones, and the infrastructure master
Troubleshoot DNS Event ID 4013: The DNS server was unable to load AD
integrated DNS zones
DCPROMO demotion fails if unable to contact the DNS infrastructure master
FSMO Roles
Perform initial recovery
AD Forest Recovery - Seizing an operations master role
To clean up server metadata by using Ntdsutil
Planning Operations Master Role Placement
Move-ADDirectoryServerOperationMasterRole

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to view and transfer FSMO roles
Article • 02/19/2024

This article describes how to view and transfer FSMO roles.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
Original KB number: 324801

Summary
This article describes how to transfer Flexible Single Master Operations (FSMO) roles
(also known as operations master roles) by using the Active Directory snap-in tools in
Microsoft Management Console (MMC).

FSMO Roles
In a forest, there are at least five FSMO roles that are assigned to one or more domain
controllers. The five FSMO roles are:

Schema Master: The schema master domain controller controls all updates and
modifications to the schema. To update the schema of a forest, you must have
access to the schema master. There can be only one schema master in the whole
forest.
Domain naming master: The domain naming master domain controller controls
the addition or removal of domains in the forest. There can be only one domain
naming master in the whole forest.
Infrastructure Master: The infrastructure is responsible for updating references
from objects in its domain to objects in other domains. At any one time, there can
be only one domain controller acting as the infrastructure master in each domain.

７ Note

The Infrastructure Master (IM) role isn't often needed anymore, as it has no
work to do if the environment uses the recommended configuration. Refer to
the articles linked below for details. To summarize, the scenarios are:
All domain controllers in the domain are Global Catalogs.
The forest is configured to use the Recycle Bin.
 The IM role should still always be set to a valid domain controller to avoid
errors being reported in monitoring systems.

Relative ID (RID) Master: The RID master is responsible for processing RID pool
requests from all domain controllers in a particular domain. At any one time, there
can be only one domain controller acting as the RID master in the domain.
PDC Emulator: The PDC emulator is a domain controller that advertises itself as the
primary domain controller (PDC) to workstations, member servers, and domain
controllers that are running earlier versions of Windows. For example, if the
domain contains computers that are not running Microsoft Windows XP
Professional or Microsoft Windows 2000 client software, or if it contains Microsoft
Windows NT backup domain controllers, the PDC emulator master acts as a
Windows NT PDC. It is also the Domain Master Browser, and it handles password
discrepancies. At any one time, there can be only one domain controller acting as
the PDC emulator master in each domain in the forest.

You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using
an MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can
use one of the following three MMC snap-in tools:
Active Directory Schema snap-in
Active Directory Domains and Trusts snap-in
Active Directory Users and Computers snap-in
If a computer no longer exists, the role must be seized. To seize a role, use the
Ntdsutil.exe utility.

For additional information about how to use the Ntdsutil.exe utility to seize FSMO roles,
click the article number below to view the article in the Microsoft Knowledge Base:

255504 Using Ntdsutil.exe to Seize or Transfer the FSMO Roles to a Domain

Use the Active Directory Schema Master snap-in to transfer the schema master role.
Before you can use this snap-in, you must register the Schmmgmt.dll file.

Register Schmmgmt.dll
1. Click Start, and then click Run.
2. Type regsvr32 schmmgmt.dll in the Open box, and then click OK.
3. Click OK when you receive the message that the operation succeeded.

Transfer the Schema Master Role

1. Click Start, click Run, type mmc in the Open box, and then click OK.
 2. On the File, menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Schema, click Add, click Close, and then click OK.
5. In the console tree, right-click Active Directory Schema, and then click Change
Domain Controller.
6. Click Specify Name, type the name of the domain controller that will be the new
role holder, and then click OK.
7. In the console tree, right-click Active Directory Schema, and then click Operations
Master.
8. Click Change.
9. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the Domain Naming Master Role

1. Click Start, point to Administrative Tools, and then click Active Directory Domains
and Trusts.

2. Right-click Active Directory Domains and Trusts, and then click Connect to
Domain Controller.

７ Note

You must perform this step if you are not on the domain controller to which
you want to transfer the role. You do not have to perform this step if you are
already connected to the domain controller whose role you want to transfer.

3. Do one of the following actions:

In the Enter the name of another domain controller box, type the name of
the domain controller that will be the new role holder, and then click OK.
-or-
In the Or, select an available domain controller list, click the domain
controller that will be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Domains and Trusts, and then click
Operations Master.

5. Click Change.

6. Click OK to confirm that you want to transfer the role, and then click Close.
Transfer the RID Master, PDC Emulator, and Infrastructure
Master Roles
1. Click Start, point to Administrative Tools, and then click Active Directory Users and
Computers.

2. Right-click Active Directory Users and Computers, and then click Connect to
Domain Controller.

７ Note

You must perform this step if you are not on the domain controller to which
you want to transfer the role. You do not have to perform this step if you are
already connected to the domain controller whose role you want to transfer.

3. Do one of the following actions:

In the Enter the name of another domain controller box, type the name of
the domain controller that will be the new role holder, and then click OK.
-or-
In the Or, select an available domain controller list, click the domain
controller that will be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Users and Computers, point to All
Tasks, and then click Operations Master.

5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or
Infrastructure), and then click Change.

6. Click OK to confirm that you want to transfer the role, and then click Close.

References
For more information, see:

Active Directory FSMO roles in Windows

FSMO placement and optimization on Active Directory domain controllers
Flexible Single Master Operation Transfer and Seizure Process
HOW TO: Use Ntdsutil to find and clean up duplicate security identifiers
Troubleshoot DNS Event ID 4013 (The DNS server was unable to load AD
integrated DNS zones)
DCPROMO demotion fails if unable to contact the DNS infrastructure master
 FSMO Roles
Perform initial recovery
AD Forest Recovery - Seizing an operations master role
Clean up server metadata using the command line
Planning Operations Master Role Placement
Move-ADDirectoryServerOperationMasterRole

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Password change processing and
conflict resolution functionality in
Windows
Article • 02/19/2024

This article describes a registry value that administrators can use to control when the
primary domain controller (PDC) is contacted, which can help reduce communication
costs between sites and reduce the load on the PDC.

） Important

This article contains information about modifying the registry. Before you modify
the registry, make sure to back it up and make sure that you understand how to
restore the registry if a problem occurs. For information about how to back up,
restore, and edit the registry, see Windows registry information for advanced
users.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
Original KB number: 225511

Summary
By default, when a user password is reset or changed, or when a domain controller
receives a client authentication request using an incorrect password, the Windows
domain controller acting as the PDC Flexible Single Master Operation (FSMO) role
owner for the Windows domain is contacted. This article describes a registry value that
administrators can use to control when the PDC is contacted, which can help reduce
communication costs between sites and reduce the load on the PDC.

This communication to the PDC isn't done for computer accounts. Computers will retry
the authentication with the most recent previous password when the authentication
fails. Along the same line, the computers would try the most recent previous password
when decrypting a Kerberos service ticket they receive.

More information
 ２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.

The following registry value can be modified to control Password Change Notification
and Password Conflict Resolution as described below:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

Registry value: AvoidPdcOnWan

Registry type: REG_DWORD
Registry value data: 0 (or value not present) or 1
0 or value not present = FALSE (to disable)
1 = TRUE (to enable)
Default: (value isn't present)

Password change notification

A Windows writable domain controller receives the user password change or reset
request. The password change is made locally, and then sent immediately to the PDC
FSMO role owner using the Netlogon service as a Remote Procedure Call (RPC). The
password change is then replicated to partners using the Active Directory replication
process by both the PDC and the domain controller (DC) servicing the password change.
If a Windows Read-Only domain controller (RODC) receives the password change
request, it works like an authentication proxy forwarding the request to its hub DC,
which acts as if it's the first DC to receive the request.

If the AvoidPdcOnWan value is set to TRUE and the PDC FSMO is located at another site,
the password change isn't sent immediately to the PDC. However, it's updated with the
change through normal Active Directory replication. If the PDC FSMO is at the same site,
the AvoidPdcOnWan value isn't used, and the password change is immediately
communicated to the PDC.

An updated password may not be sent to the PDC emulator even if AvoidPdcOnWan is
FALSE or not set, if there are problems sending the request to the PDC, for example a
Network outage. There's no error logged in this case. The update is then distributed
using normal AD replication.
Password conflict resolution
By default, Windows domain controllers query the PDC FSMO role owner if a user is
attempting to authenticate using a password that is incorrect according to its local
database. If the password sent from the client by the user is correct on the PDC, the
client is allowed access, and the domain controller replicates the password change.

The AvoidPdcOnWan value can be used by administrators to control when Active

Directory domain controllers attempt to use the PDC FSMO role owner to resolve
password conflicts. The PDC completes the logon, and the authentication is successful
for the authenticating user.

If the AvoidPdcOnWan value is set to TRUE and the PDC FSMO role owner is located at
another site, the domain controller doesn't try to authenticate a client against password
information stored on the PDC FSMO. Note, however, that this results in denying access
to the user. This may cause a productivity impact, as many users aren't going to try the
previous password to authenticate. In some scenarios, they may not know the previous
password.

An incorrect password may not be tried at the PDC emulator even if AvoidPdcOnWan is
FALSE or not set, if there are problems sending the request to the PDC, for example a
Network outage. There's no error logged in this case. The logon attempt is denied in
this case.

The scenario is different when an RODC is involved. If an authentication request on the

RODC fails with a bad password, the RODC sends the request to the hub DC, and in turn,
the hub DC sends it to the PDC. If it succeeds on the PDC, the user authentication
succeeds. If the RODC is allowed to cache the user password, it will request the user
password to be replicated from its hub DC. But the hub DC also still has the old
password only. The RODC only gets the new password through the normal replication
cycle. It will continue to need the hub or the PDC until the new password is replicated.

Password replication handling

When the writable DC forwards the password change to the PDC, the user password is
set on both DCs. Both DCs will include this new password in their outbound replication.

If these two changes arrive at a DC, the normal AD conflict resolution is performed. The
AD version of attributes will be the same, but the time-stamp of the PDC will be a bit
older, and the password of the initial DC will be used.

It makes no difference as the data payload is identical because both DCs have written
the same new password value.
Logging in the Directory Services event log
Windows Server 2022 has added events to track the activity of interactions with the PDC
emulator regarding password update notifications.

Event ID 3035

Event ID 3035 is logged on the PDC at logging level four of the category "27 PDC
Password Update Notifications" in the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 3035
Task Category: PDC Password Updates
Level: Informational
Description:
Active Directory Domain Services successfully processed a password update
notification sent from a Backup Domain Controller (BDC).
The user may experience temporary authentication failures until the updated
credentials are successfully replicated to the PDC via normal replication
schedules.
BDC: <Computer Name>
User: <User Name>
User RID: <RID>

Event ID 3036

Event ID 3036 is logged if there's an error when updating the PDC with the updates in a
call from a Backup Domain Controller (BDC):

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 3036
Task Category: PDC Password Updates
Level: Warning
Description:
Active Directory Domain Services failed to process a password update
notification sent from a Backup Domain Controller (BDC).
The user may experience temporary authentication failures until the updated
credentials are successfully replicated to the PDC via normal replication
schedules.
BDC: <Computer Name>
 User: <User Name>
User RID: <RID>
Error: <Error Code>

Event ID 3037
Event ID 3037 is logged on the BDC at logging level four of the category "27 PDC
Password Update Notifications" in the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 3037
Task Category: PDC Password Updates
Level: Informational
Description:
Active Directory Domain Services successfully sent a password update
notification to the Primary Domain Controller (PDC).
User: <User Name>
User RID: <RID>

Event ID 3038

Event ID 3038 is logged if there's an error when updating the PDC with the updates in a
call from a BDC:

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 3038
Task Category: PDC Password Updates
Level: Warning
Description:
Active Directory Domain Services failed to send a password update
notification to the Primary Domain Controller (PDC).
The user may experience temporary authentication failures until the updated
credentials are successfully replicated to the PDC via normal replication
schedules.
User: <User Name>
User RID: <RID>
Error: <Error Code>
For exmaple, error code c0000225 maps to STATUS_NOT_FOUND. This error is expected
when the user is newly created on the local domain controller, and the user's password
is set within the replication latency of the PDC.

You may also see network or RPC related errors in Event ID 3038. For example, when a
firewall blocks the communication between the BDC and PDC, you may receive this
event.

References
How to configure Active Directory and LDS diagnostic event logging

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Flexible Single Master Operation
transfer and seizure process
Article • 02/19/2024

This article describes how Flexible Single Master Operations (FSMO) roles are transferred
from one domain controller to another and how this role can be forcefully appointed in
the event that the domain controller that previously held the role is no longer available.

Applies to: Windows Server 2012 R2

Original KB number: 223787

Transferring the Flexible Single Master

Operation role
The transfer of an FSMO role is the suggested form of moving a FSMO role between
domain controllers and can be initiated by the administrator or by demoting a domain
controller, but is not initiated automatically by the operating system. This includes a
server in a shut-down state. FSMO roles aren't automatically relocated during the
shutdown process—this must be considered when shutting down a domain controller
that has an FSMO role for maintenance, for example.

In a graceful transfer of an FSMO role between two domain controllers, a

synchronization of the data that is maintained by the FSMO role owner to the server
receiving the FSMO role is performed prior to transferring the role to ensure that any
changes have been recorded before the role change.

Operational attributes are attributes that translate into an action on the server. This type
of attribute isn't defined in the schema, but is instead maintained by the server and
intercepted when a client attempts to read or write to it. When the attribute is read,
generally the result is a calculated result from the server. When the attribute is written, a
pre-defined action occurs on the domain controller.

The following operational attributes are used to transfer FSMO roles and are located on
the RootDSE (or Root DSA Specific Entry--the root of the Active Directory tree for a
given domain controller where specific information about the domain controller is kept).
In the operation of writing to the appropriate operational attribute on the domain
controller to receive the FSMO role, the old domain controller is demoted and the new
domain controller is promoted automatically. No manual intervention is required. The
operational attributes that represent the FSMO roles are:
 becomeRidMaster
becomeSchemaMaster
becomeDomainMaster
becomePDC
becomeInfrastructureMaster

If the administrator specifies the server to receive the FSMO role using a tool such as
Ntdsutil, the exchange of the FSMO role is defined between the current owner and the
domain controller specified by the administrator.

When a domain controller is demoted, the operational attribute

"GiveAwayAllFsmoRoles" is written, which triggers the domain controller to locate other
domain controllers to offload any roles it currently owns. Windows 2000 determines
which roles the domain controller being demoted currently owns and locates a suitable
domain controller by following these rules:

1. Locate a server in the same site.

2. Locate a server to which there is RPC connectivity.
3. Use a server over an asynchronous transport (such as SMTP).

In all transfers, if the role is a domain-specific role, the role can be moved only to
another domain controller in the same domain. Otherwise, any domain controller in the
enterprise is a candidate.

Seizing the Flexible Single Master Operation

role
Administrators should use extreme caution in seizing FSMO roles. This operation, in
most cases, should be performed only if the original FSMO role owner will not be
brought back into the environment.

When the administrator seizes an FSMO role from an existing computer, the
"fsmoRoleOwner" attribute is modified on the object that represents the root of the
data directly bypassing synchronization of the data and graceful transfer of the role. The
"fsmoRoleOwner" attribute of each of the following objects is written with the
Distinguished Name (DN) of the NTDS Settings object (the data in the Active Directory
that defines a computer as a domain controller) of the domain controller that is taking
ownership of that role. As replication of this change starts to spread, other domain
controllers learn of the FSMO role change.

Primary Domain Controller (PDC) FSMO: LDAP://DC=MICROSOFT,DC=COM RID Master

FSMO: LDAP://CN=Rid Manager$,CN=System,DC=MICROSOFT,DC=COM Schema
Master FSMO: LDAP://CN=Schema,CN=Configuration,DC=Microsoft,DC=Com
Infrastructure Master FSMO: LDAP://CN=Infrastructure,DC=Microsoft,DC=Com Domain
Naming Master FSMO: LDAP://CN=Partitions,CN=Configuration,DC=Microsoft,DC=Com
For example, if Server1 is the PDC in the Microsoft.com domain and is retired and the
administrator is unable to demote the computer properly, Server2 needs to be assigned
the FSMO role of the PDC. After the seizure of the role takes place, the value CN=NTDS
Settings,CN=SERVER2,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=Microsoft,DC=Com is present on the following
object: LDAP://DC=MICROSOFT,DC=COM

References
For more information about FSMO roles in general, see the following article in the
Microsoft Knowledge Base:
197132 Windows 2000 Active Directory FSMO Roles

For more information about the correct placement of FSMO roles, see the following
article in the Microsoft Knowledge Base:
223346 FSMO Placement and Optimization on Windows 2000 Domains

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADAM general Event ID 1161 is logged
on an AD LDS server
Article • 02/19/2024

This article describes an issue in which ADAM general Event ID 1161 is logged on an AD
LDS server.

Applies to: Windows Server 2012 R2

Original KB number: 3080830

Symptoms
The following event is logged in the ADAM log every time an instance is restarted on an
AD LDS server that's running Windows Server 2012 R2.

Cause
The address book hierarchy table does not exist in the Active Directory Lightweight
Directory Services (AD LDS) database. Therefore, the event is triggered during service
startup.

This event can be safely ignored on an AD LDS instance.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Change a Windows Active Directory and
LDS user password through LDAP
Article • 02/19/2024

This article describes how to change a Windows Active Directory and LDS user password
through LDAP.

Applies to: Windows Active Directory

Original KB number: 269190

Summary
Based on certain restrictions, you can set a Windows Active Directory and Lightweight
Directory Services (LDS) password through the Lightweight Directory Access Protocol
(LDAP). This article describes how to set or change the password attribute.

These steps also apply to Active Directory Application Mode (ADAM) and LDS users and
userProxy objects in the same way as done with AD users. See additional hints at the
end of the article for details.

More information
The password is stored in the AD and LDS database on a user object in the unicodePwd
attribute. This attribute can be written under restricted conditions but can't be read. The
attribute can only be modified; it can't be added on object creation or queried by a
search.

To modify this attribute, the client must have a 128-bit Transport Layer Security
(TLS)/Secure Socket Layer (SSL) connection to the server. An encrypted session using
SSP-created session keys using Windows New Technology LAN Manager (NTLM) or
Kerberos are also acceptable as long as the minimum key length is met.

For this connection to be possible using TLS/SSL:

The server must possess a server certificate for a 128-bit RSA connection.
The client must trust the certificate authority (CA) that generated the server
certificate.
Both client and server must be capable of 128-bit encryption.
The syntax of the unicodePwd attribute is octet-string; however, the directory service
expects that the octet-string will contain a UNICODE string (as the name of the attribute
indicates). This means that any values for this attribute passed in LDAP must be
UNICODE strings that are BER-encoded (Basic Encoding Rules) as an octet-string. In
addition, the UNICODE string must begin and end in quotes that aren't part of the
desired password.

There are two possible ways to modify the unicodePwd attribute. The first is similar to a
regular user change password operation. In this case, the modify request must contain
both delete and an add operation. The delete operation must contain the current
password with quotes around it. The add operation must contain the desired new
password with quotes around it.

The second way to modify this attribute is analogous to an administrator resetting a

password for a user. To do this, the client must bind as a user with sufficient permissions
to modify another user's password. This modify request should contain a single replace
operation with the new desired password surrounded by quotes. If the client has
sufficient permissions, this password becomes the new password, regardless of what the
old password was.

The following two functions provide examples of these operations:

C++

ULONG ChangeUserPassword(WCHAR* pszUserDN, WCHAR* pszOldPassword,WCHAR*

pszNewPassword)
{
ULONG err = 1;
LDAPMod modNewPassword;
LDAPMod modOldPassword;
LDAPMod *modEntry[3];
BERVAL newPwdBerVal;
BERVAL oldPwdBerVal;
BERVAL *newPwd_attr[2];
BERVAL *oldPwd_attr[2];
WCHAR pszNewPasswordWithQuotes[1024];
WCHAR pszOldPasswordWithQuotes[1024];

// Build an array of LDAPMod.

// For setting unicodePwd, this MUST be a double op.

modEntry[0] = &modOldPassword;
modEntry[1] = &modNewPassword;
modEntry[2] = NULL;

// Build mod struct for unicodePwd Add.

modNewPassword.mod_op = LDAP_MOD_ADD | LDAP_MOD_BVALUES;
modNewPassword.mod_type =L"unicodePwd";
modNewPassword.mod_vals.modv_bvals = newPwd_attr;
 // Build mod struct for unicodePwd Delete.
modOldPassword.mod_op = LDAP_MOD_DELETE | LDAP_MOD_BVALUES;
modOldPassword.mod_type =L"unicodePwd";
modOldPassword.mod_vals.modv_bvals = oldPwd_attr;

// Password will be single valued, so we only have one element.

newPwd_attr[0] = &newPwdBerVal;
newPwd_attr[1]= NULL;
oldPwd_attr[0] = &oldPwdBerVal;
oldPwd_attr[1]= NULL;

// Surround the passwords in quotes.

wsprintf(pszNewPasswordWithQuotes,L"\"%s\"",pszNewPassword);
wsprintf(pszOldPasswordWithQuotes,L"\"%s\"",pszOldPassword);

// Build the BER structures with the UNICODE passwords w/quotes.

newPwdBerVal.bv_len = wcslen(pszNewPasswordWithQuotes) * sizeof(WCHAR);
newPwdBerVal.bv_val = (char*)pszNewPasswordWithQuotes;
oldPwdBerVal.bv_len = wcslen(pszOldPasswordWithQuotes) * sizeof(WCHAR);
oldPwdBerVal.bv_val = (char*)pszOldPasswordWithQuotes;

// Perform single modify.

err = ldap_modify_s(ldapConnection,
pszUserDN,
modEntry
);

if (err == LDAP_SUCCESS )
wprintf(L"\nPassword successfully changed!\n");
else
wprintf(L"\nPassword change failed!\n");

return err;
}

ULONG SetUserPassword(WCHAR* pszUserDN, WCHAR* pszPassword)

{
ULONG err = 1;
LDAPMod modPassword;
LDAPMod *modEntry[2];
BERVAL pwdBerVal;
BERVAL *pwd_attr[2];
WCHAR pszPasswordWithQuotes[1024];

// Build an array of LDAPMod.

// For setting unicodePwd, this MUST be a single op.
modEntry[0] = &modPassword;
modEntry[1] = NULL;

// Build mod struct for unicodePwd.

modPassword.mod_op = LDAP_MOD_REPLACE | LDAP_MOD_BVALUES;
modPassword.mod_type =L"unicodePwd";
modPassword.mod_vals.modv_bvals = pwd_attr;
 // Password will be single valued, so we only have one element.
pwd_attr[0] = &pwdBerVal;
pwd_attr[1]= NULL;

// Surround the password in quotes.

wsprintf(pszPasswordWithQuotes,L"\"%s\"",pszPassword);

// Build the BER structure with the UNICODE password.

pwdBerVal.bv_len = wcslen(pszPasswordWithQuotes) * sizeof(WCHAR);
pwdBerVal.bv_val = (char*)pszPasswordWithQuotes;

// Perform single modify.

err = ldap_modify_s(ldapConnection,
pszUserDN,
modEntry
);

if (err == LDAP_SUCCESS )
wprintf(L"\nPassword succesfully set!\n");
else
wprintf(L"\nPassword set failed!\n");

return err;
}

 Tip

To configure LDS instances using UserProxy objects for password resets, you
have to allow constrained delegation of the LDS service account (default: LDS
computer account) to the domain controllers in case the user logon uses
Kerberos.
If you are using LDAP simple bind, you have to use Windows Server 2022 or a
newer version and set a registry entry to forward the admin LDAP session
credentials to the Active Directory Domain Controller:
Registry Key: HKLM\system\currentcontrolset\services<LDS
Instance>\Parameters
Registry Entry: Allow ClearText Logon Type
Type: REG_DWORD
Data: 0: Don't allow forwarding of credentials (Default)
1: Allow forwarding of credentials for password reset
Note that the change in both cases means that the LDS server should be
considered a Tier-0 device as it can start security-sensitive tasks on the
Domain Controller.
Applies to
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows 8.1 Enterprise
Windows 8.1 Pro
Windows 10
Windows 11

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Hide or Display the InetOrgPerson
Object Class in Active Directory Users
and Computers
Article • 02/19/2024

This article describes how to Hide or Display the InetOrgPerson object class in Active
Directory Users and Computers.

Applies to: Windows Server 2012 R2

Original KB number: 311555

Summary
In Windows Server 2003-and-later versions of Active Directory, an additional object class
is introduced. The InetOrgPerson object class. InetOrgPerson is defined in RFC 2798, and
it has been accepted as the de facto standard in other Lightweight Directory Access
Protocol (LDAP) directory implementations.

Active Directory has been modified to support the InetOrgPerson class, and with the
addition of the User class definition, you can now create InetOrgPerson as security
principals in Active Directory. This greatly enhances an administrator's capabilities to
migrate user accounts from third-party directories into the Active Directory.

However, this change may introduce problems with third-party programs (third-party
programs are defined as any programs that use Active Directory as an authentication
method). Microsoft recommends that you perform complete program compatibility
testing before you use the InetOrgPerson class.

For this reason, and also to avoid confusion, you may want to disable the visible
references to the InetOrgPerson object type in Active Directory Users and Computers.
This will prevent administrators from mistakenly creating InetOrgPerson users instead of
the more accepted User type.

More information
To enable or disable the InetOrgPerson user type in Active Directory Users and
Computers, follow these steps:
 1. Log on to the Windows Server 2003 domain controller that holds the Schema
Master FSMO role as an account with Schema Administrator permissions.
2. Open the Adsiedit Microsoft Management Console (MMC) snap-in.
3. In the Schema folder, locate the CN=InetOrgPersonClass object. Right-click this
object, and then click Properties.
4. Locate the defaultHidingValue attribute, and then modify its value based on your
expected outcome. If you set this value to True, this hides the InetOrgPerson object
type in Active Directory Users and Computers. If you set this value to False, this
displays the object type.
5. After you set the value, click Apply, and then click OK. Allow for standard
replication latency, and then restart any instances of Active Directory Users and
Computers.If you set the defaultHidingValue attribute to False, you can create new
users of the InetOrgPerson type. With DefaultHidingValue set to True, this
functionality is removed.

７ Note

This is true only of Active Directory Users and Computers. You can still create the
InetOrgPerson user types through other means, regardless of this setting.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure Active Directory and LDS
diagnostic event logging
Article • 02/19/2024

This step-by-step article describes how to configure Active Directory diagnostic event logging in
Microsoft Windows Server operating systems.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server
2012 R2, Windows Server 2012
Original KB number: 314980

Summary
Active Directory records events to the Directory Services or LDS Instance log in Event Viewer. You
can use the information that is collected in the log to help you diagnose and resolve possible
problems or monitor the activity of Active Directory-related events on your server.

By default, Active Directory records only critical events and error events in the Directory Service
log. To configure Active Directory to record other events, you must increase the logging level by
editing the registry.

Active Directory diagnostic event logging

The registry entries that manage diagnostic logging for Active Directory are stored in the following
registry subkeys.

Domain controller: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

LDS: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Diagnostics

Each of the following REG_DWORD values under the Diagnostics subkey represents a type of
event that can be written to the event log:

1. Knowledge Consistency Checker (KCC)

2. Security Events
3. ExDS Interface Events
4. MAPI Interface Events
5. Replication Events
6. Garbage Collection
7. Internal Configuration
8. Directory Access
9. Internal Processing
10. Performance Counters
11. Initialization/Termination
12. Service Control
 13. Name Resolution
14. Backup
15. Field Engineering
16. LDAP Interface Events
17. Setup
18. Global Catalog
19. Inter-site Messaging
20. Group Caching
21. Linked-Value Replication
22. DS RPC Client
23. DS RPC Server
24. DS Schema
25. Transformation Engine
26. Claims-Based Access Control
27. PDC Password Update Notifications

Logging levels
Each entry can be assigned a value from 0 through 5, and this value determines the level of detail
of the events that are logged. The logging levels are described as:

0 (None): Only critical events and error events are logged at this level. This is the default
setting for all entries, and it should be modified only if a problem occurs that you want to
investigate.
1 (Minimal): High-level events are recorded in the event log at this setting. Events may
include one message for each major task that is performed by the service. Use this setting to
start an investigation when you do not know the location of the problem.
2 (Basic)
3 (Extensive): This level records more detailed information than the lower levels, such as steps
that are performed to complete a task. Use this setting when you have narrowed the problem
to a service or a group of categories.
4 (Verbose)
5 (Internal): This level logs all events, including debug strings and configuration changes. A
complete log of the service is recorded. Use this setting when you have traced the problem
to a particular category of a small set of categories.

How to configure Active Directory diagnostic event

logging
To configure Active Directory diagnostic event logging, follow these steps.

） Important
 This section, method, or task contains steps that tell you how to modify the registry. However,
serious problems might occur if you modify the registry incorrectly. Therefore, make sure that
you follow these steps carefully. For added protection, back up the registry before you modify
it. Then, you can restore the registry if a problem occurs. For more information, see How to
back up and restore the registry in Windows .

1. Select Start, and then select Run.

2. In the Open box, type regedit, and then select OK.

3. Locate and select the following registry keys.

Domain controller: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

LDS: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance
name>\Diagnostics

Each entry that's displayed in the right pane of the Registry Editor window represents a type
of event that Active Directory can log. All entries are set to the default value of 0 (None).

4. Configure event logging for the appropriate component:

a. In the right pane of Registry Editor, double-click the entry that represents the type of
event for which you want to log. For example, Security Events.
b. Type the logging level that you want (for example, 2) in the Value data box, and then
select OK.

5. Repeat step 4 for each component that you want to log.

6. On the Registry menu, select Exit to quit Registry Editor.

７ Note

Logging levels should be set to the default value of 0 (None) unless you are
investigating an issue.
When you increase the logging level, the detail of each message and the number
of messages that are written to the event log also increase. A diagnostic level of 3
or greater is not recommended, because logging at these levels requires more
system resources and can degrade the performance of your server. Make sure that
you reset the entries to 0 after you finish investigating the problem.

Enable Field Engineering diagnostic event logging

This logging isn't enabled by default and should only be enabled during active troubleshooting.
You can enable the logging by using the following steps:

1. Increase the size of Directory Services event logs to 200 MB.

 2. Enable the Field Engineering diagnostics registry key, and set the value to 5.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field

Engineering

3. Create the following registry keys to configure registry-based filters for expensive, inefficient,
and long-running searches:

ﾉ Expand table

Registry path Data type Default

value

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive REG_DWORD 1
Search Results Threshold

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient REG_DWORD 1
Search Results Threshold

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time REG_DWORD 1

Threshold (msecs)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Anonymous LDAP operations to Active
Directory are disabled on domain
controllers
Article • 02/19/2024

This article provides some information about the issue that anonymous LDAP operations
to Active Directory are disabled on domain controllers.

Applies to: Windows Server 2003

Original KB number: 326690

Summary
By default, anonymous Lightweight Directory Access Protocol (LDAP) operations to
Active Directory, other than rootDSE searches and binds, are not permitted in Microsoft
Windows Server 2003.

More information
Active Directory in earlier versions of Microsoft Windows-based domains accepts
anonymous requests. In these versions, a successful result depends on having correct
user permissions in Active Directory.

With Windows Server 2003, only authenticated users may initiate an LDAP request
against Windows Server 2003-based domain controllers. You can override this new
default behavior by changing the seventh character of the dsHeuristics attribute on the
DN path as follows:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, Root domain in
forest
The DsHeuristics setting applies to all Windows Server 2003-based domain controllers in
the same forest. The value is realized by domain controllers upon Active Directory
replication without restarting Windows. Microsoft Windows 2000-based domain
controllers do not support this setting and do not restrict anonymous operations if they
are present in a Windows Server 2003-based forest.

Valid values for the dsHeuristic attribute are 0 and 0000002. By default, the DsHeuristics
attribute does not exist, but its internal default is 0. If you set the seventh character to 2
(0000002), anonymous clients can perform any operation that is permitted by the access
control list (ACL), as can Windows 2000-based domain controllers.
 ７ Note

If the attribute is already set, do not modify any characters in the DsHeuristics
string other than the seventh character. If the value is not set, make sure that you
provide the leading zeros up to the seventh character. Also, you can use
Adsiedit.msc to make the change to the attribute.

The dsHeuristics string on a domain controller in the Forest_Name.com forest appears

as follows when you view it by using Ldp.exe. Only selected attributes are shown.

>> Dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=

<forest_name>,DC=com
2> objectClass: top; nTDSService;
1> cn: Directory Service;
1> dSHeuristics: 0000002; <-2 in the seventh character = anonymous
access allowed. Note the leading zeros.
1> name: Directory Service;

Feedback
Was this page helpful?  Yes  No

Provide product feedback

LDS service startup fails after you
manually change msDS-Behavior-
Version in Windows Server 2019 and
2016
Article • 02/19/2024

This article provides a solution to an error that LDS service startup fails after you
manually change msDS-Behavior-Version.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4550446

Symptom
In ADSI Edit, you change the msDS-Behavior-Version attribute of the Partitions
container to 7 in order to raise the Active Directory (AD) Lightweight Directory Services
(LDS) instance functional level to WIN2016.

After you restart the server or stop the LDS service, the LDS service cannot be started.
When you try to manually start the service, the following event errors are logged:
 Log Name: ADAM (LDS)
Source: ADAM [LDS] General
Event ID: 1168
Task Category: Internal Processing
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: LDS.CONTOSO.COM
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred.

Additional Data
Error value (decimal):
-1601
Error value (hex):
fffff9bf
Internal ID:
20801a4

Additionally, you receive the following error message:

Windows could not start the <ServiceName> LDS service on Local Computer.
Error 0xc0000025: 0xc0000025

Cause
Manually setting the msDS-Behavior-Version attribute value to 7 on LDS instances is
not supported.

Resolution
If the LDS instance contains only one server, you must restore the server from a backup
to resolve the issue.

If there are multiple replica servers in that instance (for example, LDSServer1 and
LDSServer2), and if one server has not yet been restarted, follow these steps:

1. If the LDS server on which the service that does not start (for example, LDSServer1)
holds the LDS Roles (for example, Schema and Domain Naming FSMO), seize the
roles by running ntdsutil:

C:\Windows\system32> ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server LDSServer2:50000( 50000 is the port
number in that example)
Binding to LDSServer2:50000 ...
Connected to LDSServer2:50000 using credentials of locally logged on user.
server connections: q
fsmo maintenance: seize schema master

2. Connect to the configuration partition of the server that still runs the LDS instance
(for example, LDSServer2), and then roll back the functionality level version by
reverting the msDS-Behavior-Version attribute value.

3. Run a metadata cleanup of the LDS server (LDSServer1) by using dsmgmt:

C:\Windows\system32> dsmgmt
dsmgmt: metadata cleanup
metadata cleanup: connections
server connections: connect to server LDSServer2:50000 ( 50000 is the port
number in that example)
Binding to LDSServer2:50000 ... Connected to LDSServer2:50000 using
credentials of locally logged on user. server connections: q
metadata cleanup: select operation target
select operation target: list naming contexts
Found 3 Naming Context(s) 0 - CN=Configuration,CN={6B7FEBF4-017B-4366-
A8B8-3E5467888DEF} 1 - CN=Schema,CN=Configuration,CN={6B7FEBF4-
017B-4366-A8B8-3E5467888DEF} 2 - DC=LDS,DC=COM select operation
target: select naming context2 ( 2 stands for the domain naming context )
No current site No current domain No current server Naming Context -
DC=LDS,DC=COM select operation target: list sites
Found 4 site(s) 0 - CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} 1 - CN=Site1,CN=Sites,CN=Configuration,CN={6B7FEBF4-
017B-4366-A8B8-3E5467888DEF} 2 -
CN=Site2,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} 3 - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-
017B-4366-A8B8-3E5467888DEF} select operation target: select site3 (where 3
is the number of the site in which the server is located, matching output
from previous step)
Site - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} No current domain No current server Naming Context -
DC=LDS,DC=COM select operation target: list servers in Site
Found 1 server(s) 0 -
CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,CN=
{6B7FEBF4-017B-4366-A8B8-3E5467888DEF} select operation target: select
Server0 (where 0 is the number of the server you wish to remove, matching
output from previous step)
Site - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} No current domain Server -
CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,CN=
{6B7FEBF4-017B-4366-A8B8-3E5467888DEF} DSA object - CN=NTDS
Settings,CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,C
N={6B7FEBF4-017B-4366-A8B8-3E5467888DEF} DNS host name -
LDSServer1.CONTOSO.COM Naming Context - DC=LDS,DC=COM select
operation target: q
metadata cleanup: remove selected server
 4. Log on to LDSServer1, and uninstall the instance:

5. Run the Active Directory Lightweight Directory Services Setup

(C:\Windows\ADAM\adaminstall.exe) on LDSServer1 to install a replica of the
existing instance from LDSServer2.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Numerous "Event ID 1216" Events in
Directory Services Event Log
Article • 02/19/2024

This article provides a resolution for the issue that numerous "Event ID 1216" Events
occur in Directory Services Event Log.

Applies to: Windows Server 2012 R2

Original KB number: 246717

７ Note

This article contains information about modifying the registry. Before you modify
the registry, make sure to back it up and make sure that you understand how to
restore the registry if a problem occurs. For information about how to back up,
restore, and edit the registry, click the following article number to view the article in
the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry

Symptoms
You may find multiple instances of the following entry in the Directory Services event
log:

Event Type:Warning
Event Source:NTDS LDAP
Event Category:LDAP Interface
Event ID:1216
Date:<DateTime>
Time:<DateTime>
User:N/A
Computer:Computer
Description:
The LDAP server closed a socket to a client because of an error condition, 1234.
(Internal ID c01028c::4294967295).

７ Note
The Internal ID value varies with each instance.

Cause
This event log message occurs when a Lightweight Directory Access Protocol (LDAP)
client sends a request to the computer by using User Datagram Protocol (UDP), but
does not keep its socket open to listen for the response from the server. When the
server tries to send the answer back, the error message is logged to the event log. It is a
harmless error that can occur frequently under normal operating conditions. It occurs
only if the diagnostic logging level is increased by modifying the level of LDAP logging
to 2 or more in the registry.

Resolution

２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.

To resolve this issue:

1. Start Registry Editor (Regedt32.exe).

2. Locate the LDAP Interface Events value in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
3. Set the data value of the LDAP Interface Events value to a lower setting, and then
click OK.
4. Quit Registry Editor.

The default value for this registry value is 0.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Problems that can occur with many
Domain Controllers in Active Directory
integrated DNS zones
Article • 02/19/2024

Original KB number: 267855

Applies to: Supported versions of Windows Server

Symptoms
Domain Name System (DNS) registrations of SRV and domain controller (DC) locator A
records (registered by Netlogon) and NS records (added by the authoritative DNS
servers) in an Active Directory-integrated DNS zone for some DCs may not work in a
domain that contains a large number of DCs (usually over 1200). If the Active Directory-
integrated DNS zone has the same name as the Active Directory domain name,
problems with the registration of A records and NS records at the zone root seem to
occur in a domain with more than 400 DCs. Also, one or more of the following error
messages may be logged in the Event log:

Output

Event Type: Error

Event Source: DNS
Event Category: None
Event ID: 4011
Description: The DNS server was unable to add or write an update of domain
name xyz in zone xyz.example.com to the Active Directory. Check that the
Active Directory is functioning properly and add or update this domain name
using the DNS console. The event data contains the error.
Data: 0000: 2a 23 00 00 *#..

Output

Event Type: Error

Event Source: DNS
Event Category: None
Event ID: 4015
Description: The DNS server has encountered a critical error from the Active
Directory. Check that the Active Directory is functioning properly. The
event data contains the error.
Data: 0000: 0b 00 00 00 ....
 The final status code from event 4015, 0x00000b, maps to error
"LDAP_ADMIN_LIMIT_EXCEEDED Administration limit on the server has exceeded."

Output

Event Type: Warning

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1093
Description: The directory replication agent (DRA) could not apply changes
to object
DC=@,DC=xyz.example.com,CN=MicrosoftDNS,CN=System,DC=xyz,DC=example, DC=com
(GUID <GUID>) because the incoming changes cause the object to exceed the
database's record size limit. The incoming change to attribute 9017e
(dnsRecord) will be backed out in an attempt to make the update fit. In
addition to the change to the attribute not being applied locally, the
current value of the attribute on this system will be sent out to all other
systems to make that the definitive version. This has the effect of
nullifying the change to the rest of the enterprise.
The reversal may be recognized as follows: version 5474, time of change
2000-06-28 19:33.24 and USN of 2873104.

Output

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1101
Description: The directory replication agent (DRA) was able to successfully
apply the changes to object
DC=@,DC=xyz.example.com,CN=MicrosoftDNS,CN=System, DC=xyz,DC=example,DC=com
(GUID <GUID>) after backing out one or more of the attribute changes.
Preceding messages will indicate which attributes were reversed. Please note
that this will have the effect of nullifying the change where it was made,
causing the original update not to take effect. The originator should be
notified that their change was not accepted by the system.

Cause
This problem occurs because Active Directory has a limitation of approximately 1200
values that can be associated with a single object. In an Active Directory-integrated DNS
zone, DNS names are represented by dnsNode objects, and DNS records are stored as
values in the multi-valued dnsRecord attribute on dnsNode objects, causing the error
messages listed earlier in this article to occur.

Resolution
You can use one of the following methods to resolve this issue.

Method 1
If you want to specify a list of DNS servers that can add NS records corresponding to
themselves to a specified zone, choose one DNS server and then run Dnscmd.exe with
the /AllowNSRecordsAutoCreation switch:

To set a list of TCP/IP addresses of DNS servers that have permission to

automatically create NS records for a zone, use the dnscmd servername /config
zonename /AllowNSRecordsAutoCreation IPList command. For example:

Console

Dnscmd NS1 /config zonename.com /AllowNSRecordsAutoCreation 10.1.1.1

10.5.4.2

To clear the list of TCP/IP addresses of DNS servers that have permission to
automatically create NS records for a zone and return the zone to the default state
when every primary DNS server automatically adds to a zone an NS record
corresponding to it, use the dnscmd servername /config zonename
/AllowNSRecordsAutoCreation command. For example:

Console

Dnscmd NS1 /config zonename.com /AllowNSRecordsAutoCreation

To query the list of TCP/IP addresses of DNS servers that have permission to
automatically create NS records for a zone, use the dnscmd servername /zoneinfo
zonename /AllowNSRecordsAutoCreation command. For example:

Console

Dnscmd NS1 /zoneinfo zonename.com /AllowNSRecordsAutoCreation

７ Note

Run this command on only one DNS server. Active Directory replication propagates
the changes to all DNS servers that are running on DCs in the same domain.
In an environment in which the majority of the DNS DCs for a domain are located in
branch offices and a few are located in a central location, you may want to use the
Dnscmd command described earlier in this article to set the IPList to include only the

centrally located DNS DCs. By doing so, only the centrally located DNS DCs add their
respective NS records to the Active Directory domain zone.

Method 2

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

If you want to choose which DNS server does not add NS records corresponding to
themselves to any Active Directory-integrated DNS zone, use Registry Editor
(Regedt32.exe) to configure the following registry value on each affected DNS server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Registry value: DisableNSRecordsAutoCreation

Data type: REG_DWORD
Data range: 0x0 | 0x1
Default value: 0x0

This value affects all Active Directory-integrated DNS zones. The values have the
following meanings:

ﾉ Expand table

Value Meaning

0 DNS server automatically creates NS records for all Active Directory-integrated DNS
zones unless any zone, that is hosted by the server, contains the
AllowNSRecordsAutoCreation attribute (described earlier in this article) that does not
include the server. In this situation, the server uses the AllowNSRecordsAutoCreation
configuration.

1 DNS server does not automatically create NS records for all Active Directory-integrated
DNS zones, regardless of the AllowNSRecordsAutoCreation configuration in the Active
 Value Meaning

Directory-integrated DNS zones.

７ Note

To apply the changes to this value, you must restart the DNS Server service.

If you want to prevent certain DNS servers from adding their corresponding NS records
to Active Directory-integrated DNS zones that they host, you can use the
DisableNSRecordsAutoCreation registry value described earlier in this article.

７ Note

If the DisableNSRecordsAutoCreation registry value is set to 0x1, none of the Active

Directory-integrated DNS zones hosted by that DNS server will contain its NS
records. Therefore, if this server must add its own NS record to at least one Active
Directory-integrated DNS zone that it hosts, do not set the registry value to 0x1.

Netlogon Fix

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

The Netlogon portion of this hotfix gives administrators greater control as described
earlier in this article. You should apply the fix to every DC. Also, to prevent a DC from
attempting dynamic updates of certain DNS records that by default are dynamically
updated by Netlogon, use Regedt32.exe to configure the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Registry value: DnsAvoidRegisterRecords

Data type: REG_MULTI_SZ
In this value, specify the list of mnemonics corresponding to the DNS records that
should not be registered by this DC.

７ Note

Set the value to the list of the enter-delimited mnemonics that are specified in the
following table.

The list of mnemonics includes:

ﾉ Expand table

Mnemonic Type DNS Record

LdapIpAddress A <DnsDomainName>

Ldap SRV _ldap._tcp.<DnsDomainName>

LdapAtSite SRV _ldap._tcp.<SiteName>._sites.<DnsDomainName>

Pdc SRV _ldap._tcp.pdc._msdcs.<DnsDomainName>

Gc SRV _ldap._tcp.gc._msdcs.<DnsForestName>

GcAtSite SRV _ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>

DcByGuid SRV _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>

GcIpAddress A gc._msdcs.<DnsForestName>

DsaCname CNAME <DsaGuid>._msdcs.<DnsForestName>

Kdc SRV _kerberos._tcp.dc._msdcs.<DnsDomainName>

KdcAtSite SRV _kerberos._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>

Dc SRV _ldap._tcp.dc._msdcs.<DnsDomainName>

DcAtSite SRV _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>

Rfc1510Kdc SRV _kerberos._tcp.<DnsDomainName>

Rfc1510KdcAtSite SRV _kerberos._tcp.<SiteName>._sites.<DnsDomainName>

GenericGc SRV _gc._tcp.<DnsForestName>

GenericGcAtSite SRV _gc._tcp.<SiteName>._sites.<DnsForestName>

Rfc1510UdpKdc SRV _kerberos._udp.<DnsDomainName>

 Mnemonic Type DNS Record

Rfc1510Kpwd SRV _kpasswd._tcp.<DnsDomainName>

Rfc1510UdpKpwd SRV _kpasswd._udp.<DnsDomainName>

７ Note

It is not necessary to restart the Netlogon service. If the DnsAvoidRegisterRecords

registry value is created or modified while the Netlogon service is stopped or within
the first 15 minutes after Netlogon is started, appropriate DNS updates take place
with a short delay (however, the delay is no later than 15 minutes after Netlogon
starts).

DNS registrations of A records performed by Netlogon can be also be modified by using

the RegisterDnsARecords registry value. For more information, see How to enable or
disable DNS updates in Windows.

Be aware that both the DnsAvoidRegisterRecords and the RegisterDnsARecords registry

values need to allow registering the host (A) record:

RegisterDnsARecords = 0x1
If you list LdapIpAddress and GcIpAddress in the DnsAvoidRegisterRecords registry
value settings, A records are not registered.
RegisterDnsARecords = 0x0
No matter whether you list LdapIpAddress and GcIpAddress in the
DnsAvoidRegisterRecords registry value settings, A records are not registered.

To prevent the problem described earlier in this article from occurring in an environment
in which a set of DCs and/or global catalog (GC) servers are located in a central location
and a large number of the DCs and/or GC servers are located in branch offices, the
administrator can disable registration of some of the DNS records by Netlogon on the
DCs/GCs in the branch offices. In this situation, the list of mnemonics that should not be
registered includes:

DC-specific records:

ﾉ Expand table

Mnemonic Type DNS Record

LdapIpAddress A <DnsDomainName>
 Mnemonic Type DNS Record

Ldap SRV _ldap._tcp.<DnsDomainName>

DcByGuid SRV _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>

Kdc SRV _kerberos._tcp.dc._msdcs.<DnsDomainName>

Dc SRV _ldap._tcp.dc._msdcs.<DnsDomainName>

Rfc1510Kdc SRV _kerberos._tcp.<DnsDomainName>

Rfc1510UdpKdc SRV _kerberos._udp.<DnsDomainName>

Rfc1510Kpwd SRV _kpasswd._tcp.<DnsDomainName>

Rfc1510UdpKpwd SRV _kpasswd._udp.<DnsDomainName>

GC-specific records:

ﾉ Expand table

Mnemonic Type DNS Record

Gc SRV _ldap._tcp.gc._msdcs.<DnsForestName>

GcIpAddress A gc._msdcs.<DnsForestName>

GenericGc SRV _gc._tcp.<DnsForestName>

７ Note

These lists do not include the site-specific records. Therefore, DCs and GC servers in
branch offices are located by site-specific records that are usually used by a DC
locator. If a program searches for a DC/GC by using generic (non-site-specific)
records such as any of the records in the lists that are listed earlier in this article, it
finds a DC/GC in the central location.

An administrator may also choose to limit the number of the DC locator records such as
SRV and A records registered by Netlogon for the same generic DNS name
(_ldap._tcp.dc._msdcs.<DomainName>), even in a scenario with fewer than 1200 DCs in
the same domain, to reduce the size of DNS responses to queries for such records.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More Information
Every DNS server that is authoritative for an Active Directory-integrated DNS zone adds
an NS record. By default, every DC in a domain registers an SRV record for a set of non-
site-specific names such as "_ldap._tcp.<domain_name>" and A record(s) that map(s)
the Active Directory DNS domain name to the TCP/IP address(es) of the DC. When a
DNS server tries to write a record after approximately 1200 records with the same
shared name, Local Security Authority (LSA) runs at 100 percent CPU usage for
approximately 10 seconds and the registration does not succeed. Netlogon retries this
registration every hour; the 100 percent CPU usage spike reappears at least once an
hour and the attempted registrations do not succeed.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot an OBJ_CLASS_VIOLATION
error in Adamsync
Article • 02/19/2024

This article describes how to troubleshoot an OBJ_CLASS_VIOLATION error that occurs

when you use the Adamsync tool in Windows Server.

Applies to: Windows Server 2012 R2

Original KB number: 923835

Summary
This error occurs because of class definition differences between the Active Directory
directory service and the ADAM instance. To troubleshoot this issue, follow the steps
that are described in the following sections:

Determine the attribute and class of the object

Steps to resolve the problem when attributes belong to the TOP class
Steps to resolve the problem when attributes do not belong to the TOP class

Symptoms
You try to use the Active Directory Application Mode (ADAM) Synchronizer
(Adamsync.exe) tool to synchronize the Active Directory objects to an ADAM instance
on a Windows Server. However, an error message that resembles the following is logged
in the Adamsync log file:

Processing Entry: Page X, Frame X, Entry X, Count X, USN X Processing source entry
<guid=f9023a23e3a06d408f07a0d51c301f38> Processing in-scope entry
f9023a23e3a06d408f07a0d51c301f38. Adding target object
CN= TestGroup,OU= Accounts,dc= domain, dc= com. Adding attributes:
sourceobjectguid, objectClass, instanceType, displayName, info, adminDescription,
displayNamePrintable, userAccountControl, codePage, countryCode, logonHours,
primaryGroupID, comment, accountExpires, sAMAccountName, desktopProfile,
legacyExchangeDN, userPrincipalName

Ldap error occurred. ldap_add_sW: Object Class Violation. Extended Info: 0000207D:
UpdErr: DSID-0315119D, problem 6002 (OBJ_CLASS_VIOLATION), data -2054643804
Cause
This problem occurs because of the class definition differences between Active Directory
and ADAM. This difference appears when you try to modify an object to include an
attribute that is invalid for its class. For example, the attribute is not defined in the
ADAM schema at all, or the attribute is defined but the attribute is not present in the list
of Mandatory or Optional attributes for the specific class. Typically, the second situation
is the most frequent cause of this problem.

The class definition for the object that is to be synchronized contains one or more
attributes in Active Directory that are unavailable in ADAM. The "Adding attributes"
section of the error message that is mentioned in the "Symptoms" section displays the
attributes that you try to add. These attributes are defined in the list of Optional or
Mandatory attributes for the class of the object that is being synchronized.

For example, in the error message that is mentioned in the "Symptoms" section, the
reference object is CN=TestGroup. When you view the CN=TestGroup object in Active
Directory, and you check the list of attributes for this class and all parent classes, you see
that one or more attributes in this list are not in the list of Mandatory or Optional
attributes that are enabled for this class in ADAM.

７ Note

This includes attribute lists from all parent classes.

Resolution
To resolve this problem, follow these steps.

Determine the attributes and class of the object

1. Verify the list of attributes that are being added to the object that failed. You can
determine the object that failed by viewing the error message in the sync log. The
failed object is always the last object that is indicated at the end of the sync log
exactly before the error message. For example, the CN=TestGroup object has
failed in the error message that is mentioned in the "Symptoms" section.
2. Determine whether the DisplayNamePrintable, Flags, or ExtensionName attributes
are included in the error message. If one of these attributes is included in the error
message, see the "Steps to resolve the problem when attributes belong to the TOP
 class" section. If no attributes are included in the error message, see the "Steps to
resolve problem when attributes do not belong to the TOP class" section.

Steps to resolve the problem when attributes belong to

the TOP class
You will find that the TOP class in the Active Directory schema contains the
DisplayNamePrintable, Flags, or ExtensionName attribute. However, these attributes are
not contained in the TOP class in ADAM. However, you cannot change the TOP class in
ADAM. Therefore, use one of the following methods, to resolve the issue:

Exclude these attributes by using the <exclude> section in the XML configuration
file.
By using the MMC schema, manually add these attributes to the list of Optional
attributes for the relevant class in the ADAM schema. For example, in the error
message that is mentioned in the "Symptoms" section, the failing object is of the
Group class. Therefore, you must add these attributes to the Optional attributes list
for the Group class in ADAM.

Steps to resolve the problem when attributes do not

belong to the TOP class
1. In ADSchemaAnalyzer, under the Tools\Options menu, click Update with
references to new and present elements on the LDIF generation tab.

2. Use the File menu to load Active Directory as the target schema and ADAM as the
base schema. Wait for the tool to finish comparing the schemas.

3. On the Schema menu, click Mark all elements as included.

4. On the File menu, click Create LDIF file to create an LDF file that contains the
changes.

７ Note

If you import this LDF file directly into ADAM, the necessary attributes will
probably not be added or modified correctly.

5. No error message is displayed. See the "Why you cannot import the LDF file
directly into ADAM" section for an explanation of why this occurs. In this case, go
to step 5 without importing the LDF file.
6. Examine the LDF file that you created in step 4. Specifically, view the class that is
causing the problem. For example, view the Group class. The section for this class
will contain the list of attributes that are present in the list of Mandatory or
Optional attributes for this class in Active Directory but that are missing in ADAM.

7. Find the problem attribute in the LDF file. To do this, examine the "#attributes"
section in the LDF file. Attributes that are not imported remain in this section.
Typically, the problem attribute is the only attribute that you find in the
"#attributes" section. If you find the problem attribute, go to step 8. If you do not
find the problem attribute, go to step 7.

8. If the problem attribute is not obvious from the "#attributes" section in the LDF
file, follow these steps to find the problem attribute:

a. Currently all modifications to a class are under one section in the LDF file. This is
the "#Updating Present Elements" section. Under this section, locate the section
that updates the class that has the problem. For example, if the Group class is
the problem, you will find a section that resembles the following:

# Update element: group

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: adminCount
mayContain: 1.2.840.113556.1.4.150
# mayContain: controlAccessRights
mayContain: 1.2.840.113556.1.4.200
# mayContain: groupAttributes
mayContain: 1.2.840.113556.1.4.152
# mayContain: groupMembershipSAM
mayContain: 1.2.840.113556.1.4.166
-

Note Some more entries that may be located here have been excluded from
this example.

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
 b. Change the entries that you located in step 4a by splitting the entries into a
single attribute per operation. For example, change the entries in the example in
step 7a by using entries that resemble the following:

# Update element: group

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: adminCount
mayContain: 1.2.840.113556.1.4.150
-

# Update element: group

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: controlAccessRights
mayContain: 1.2.840.113556.1.4.200
-

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: groupAttributes
mayContain: 1.2.840.113556.1.4.152
-

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: groupMembershipSAM
mayContain: 1.2.840.113556.1.4.166
-

Note Some more entries that may be located here have been excluded from
this example.

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

9. Save the LDF file.

10. Import the LDF file into the ADAM schema by using the command that is provided
at the beginning of the LDF file.

11. View the report that is displayed by the Ldifde utility. Ldifde will now report the
errors that occur with the attributes that were not imported. The error information
will resemble the following sample information:

Console

ldifde -i -u -f c:\data\problem\KBtest_modified.ldf -s localhost:50010

-j .-c "cn=Configuration,dc=X" #configurationNamingContext
Connecting to "localhost:50010"

Logging in as current user using SSPI

Importing directory from file "c:\data\problem\KBtest_modified.ldf"
Loading entries.
Add error on line 15: Already Exists
The server side error is: 0x2071 An attempt was made to add an object to the
ectory with a name that is already in use.
The extended server error is:
00002071: UpdErr: DSID-0305030D, problem 6005 (ENTRY_EXISTS), data 0

７ Note

Locate the problem attribute in the LDF file by viewing the line number that is
indicated in the error report.

12. Use this error information to find the problem attribute and resolve the problem.
Follow these steps to try to resolve the problem:
a. Locate the problem attribute in the LDF file by viewing the line number that is
indicated in the error report. The failed attribute may have a "DUP-" prefix in the
DisplayName.
b. Note the object identifier (OID) of the attribute and look for this object identifier
in ADAM.
c. Find the attribute in ADAM that has the same object identifier.
d. Compare the attribute in ADAM and in the LDF file to find any differences. For
example, the attributes may have a different DisplayName but the same object
identifier.
e. Decide which attribute to keep, and then correct the other one. For example,
you can remove the entry from the LDF file, or you can correct the ADAM
 attribute entry. Or, you can exclude the problem attribute from the
synchronization by using the <exclude> section in the XML configuration file.

13. After the problem attribute is corrected in Active Directory or in the ADAM schema
or after the attribute is removed from the LDF file, import the modified LDF file
again. Now the import operation should be successful. If the problem is not
resolved, there may be another attribute that is causing the problem. Repeat steps
10 through 12 until all the attributes are imported.

Diagnostics Logging
When you find the problem attribute, it may not be obvious what is wrong with it. For
example, you may not find a duplicate object identifier or a

different DisplayName entry. When a problem attribute is not imported, you can obtain
more information about the failure by turning on debug logging for the LDAP interface.
To do this, follow these steps:

1. To obtain more information about the ldifde failure, turn on LDAP logging in
ADAM. To do this, change the value for the Category 16 LDAP Interface events
registry entry to 5. This registry entry is located under the following registry
subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ADAM_instanceName\Diagnos

tics

2. Import the LDF file again.

3. Look at the event log for errors.

4. After you finish troubleshooting, reset the value for the Category 16 LDAP
Interface events registry entry to 0. Otherwise, the event log will be flooded.

Contact Microsoft Support

If the problem is not resolved after you complete the steps in this article, contact
Microsoft Support .

Status
This behavior is by design.
More information
To synchronize data from Active Directory to ADAM by using the Adamsync tool, follow
these steps:

1. Click Start, point to All Programs, point to ADAM, and then click ADAM Tools
Command Prompt.
2. At the command prompt, type the following command, and then press ENTER:
adamsync /fs Server_Name: port_number configurationName /log
log_file_name.log

Why you cannot import the LDF file directly into ADAM
If you import the LDF file that you created in step 1 under the "Steps to resolve the
problem when attributes do not belong to the TOP class" section into ADAM, these
attributes are still not added to the attribute list in ADAM. You can verify this behavior
by using the ADAM schema MMC or ADSIEDIT to examine the schema. This behavior
occurs because the Ldifde import operation fails silently. Currently, Ldifde does not
report errors. It fails silently because of the way that ADSchemaAnalyzer constructs the
LDF file. ADSchemaAnalyzer uses the ntdsschemaadd and ntdsSchemamodify
commands. These commands turn on permissive LDAP control. This means that any
failure is silent.

Additionally, for each class, all attributes to be added into the Optional attributes list are
added in one add/modify operation. Therefore, if there is a problem adding one of the
attributes, the whole operation fails, and no attributes in the list are added. Therefore,
additional steps must be taken to find the problem attribute.

Usually, the likely reason for failure is a duplicate object identifier of an attribute or
some other difference in the attribute definitions in Active Directory and ADAM. This
means that duplicate OIDs may be missed, and an attribute may be seen as a new
attribute if the LDapDisplayName does not exist in ADAM.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

AD LDS instance logs Event ID 2092 in
Windows Server
Article • 02/19/2024

This article provides a solution to an issue that occurs when you reboot an AD LDS
server that holds FSMO roles or restart an AD LDS instance on that server.

Applies to: Windows Server 2012 R2

Original KB number: 2547569

Symptoms
When you reboot an Active Directory Light-weight Domain Services (AD LDS) server that
holds Flexible Single Master Operations (FSMO) roles or restart an AD LDS instance on
that server, you get a warning message (Event ID 2092) in the ADAM event viewer for
that particular instance. Event ID 2092 shows:

Log Name: ADAM (InstanceName)

Source: ADAM [InstanceName] Replication
Date:
Event ID: 2092
Task Category: Replication
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADAMComputerName
Description:

This server is the owner of the following FSMO role, but does not consider it valid.
For the partition which contains the FSMO, this server has not replicated successfully
with any of its partners since this server has been restarted. Replication errors are
preventing validation of this role.
Operations which require contacting a FSMO operation master will fail until this
condition is corrected.

FSMO Role: CN=Schema,CN=Configuration,CN={95B93FA0-93B9-4E54-A654-

0D55F5CF9E4B}

User Action:
 1. Initial synchronization is the first early replications done by a system as it is
starting. A failure to initially synchronize may explain why a FSMO role cannot
be validated. This process is explained in KB article 305476.
2. This server has one or more replication partners, and replication is failing for all
of these partners. Use the command repadmin /showrepl to display the
replication errors. Correct the error in question. For example there maybe
problems with IP connectivity, DNS name resolution, or security authentication
that is preventing successful replication.
3. In the rare event that all replication partners being down is an expected
occurrence, perhaps because of maintenance or a disaster recovery, you can
force the role to be validated. This can be done by using NTDSUTIL.EXE to
seize the role to the same server. This may be done using the steps provided in
KB articles 255504 and 324801 on https://support.microsoft.com .

The following operations may be impacted:

Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this
forest.
PDC: You will no longer be able to perform primary domain controller operations,
such as Group Policy updates and password resets for non-Active Directory
Lightweight Directory Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts,
computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group
memberships, will not be updated properly if their target object is moved or
renamed.

Log Name: ADAM (InstanceName)

Source: ADAM [InstanceName] Replication
Date:
Event ID: 2092
Task Category: Replication
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADAMComputerName
Description:

This server is the owner of the following FSMO role, but does not consider it valid.
For the partition which contains the FSMO, this server has not replicated successfully
with any of its partners since this server has been restarted. Replication errors are
 preventing validation of this role.
Operations which require contacting a FSMO operation master will fail until this
condition is corrected.

FSMO Role: CN=Partitions,CN=Configuration,CN={95B93FA0-93B9-4E54-A654-

0D55F5CF9E4B}

User Action:

1. Initial synchronization is the first early replications done by a system as it is

starting. A failure to initially synchronize may explain why a FSMO role cannot
be validated. This process is explained in KB article 305476.
2. This server has one or more replication partners, and replication is failing for all
of these partners. Use the command repadmin /showrepl to display the
replication errors. Correct the error in question. For example there maybe
problems with IP connectivity, DNS name resolution, or security authentication
that is preventing successful replication.
3. In the rare event that all replication partners being down is an expected
occurrence, perhaps because of maintenance or a disaster recovery, you can
force the role to be validated. This can be done by using NTDSUTIL.EXE to
seize the role to the same server. This may be done using the steps provided in
KB articles 255504 and 324801 on https://support.microsoft.com .

The following operations may be impacted:

Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this
forest.
PDC: You will no longer be able to perform primary domain controller operations,
such as Group Policy updates and password resets for non-Active Directory
Lightweight Directory Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts,
computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group
memberships, will not be updated properly if their target object is moved or
renamed.

Cause
When there are two or more AD LDS instances in a replica set, FSMO-owning AD LDS
instances are required to in-bound replicate a particular partition on service start-up in
order to satisfy initial synchronization requirements. Event 2092 is logged shortly after
service start-up to indicate this condition. The domain naming FSMO is required to
replicate the Configuration partition, and the Schema FSMO is required to replicate the
Schema partition. Once the respective partition has been replicated successfully updates
will be allowed again. There is no event logged to indicate that initial synchronization
has completed successfully.

Resolution
If AD LDS replication is working between instances, you can ignore this event. This is a
by design behavior that FSMO role holder instance looks for a replica partner to update
the information, when AD LDS service/server is restarted.

More information
To check replication between AD LDS instances, you can use dcdiag.exe or
repadmin.exe. For more information, see the following articles:

Repadmin

Dcdiag

Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADMT 3.1 PES installation fails with
error: The supplied password does not
match this encryption key's password
Article • 02/19/2024

This article helps resolve an issue where an "The supplied password does not match this
encryption key's password" error occurs when you configure the Password Export Server
(PES) service on Active Directory Migration Tool version 3.1.

Applies to: Windows Server 2012 R2

Original KB number: 2004090

Symptoms
Configuring the Password Export Server (PES) service on Active Directory Migration Tool
version 3.1 on the source domain PDC Emulator role holder using the ADMT KEY
command shown below fails with the following on-screen error:

Command-line syntax:

ADMT KEY /OPTION:CREATE /SOURCEDOMAIN:<ADMT source domain> /KEYFILE:x:\

<path>\<filename>.pes /PWD:*

On-screen error:

Dialog Title text: Invalid Password!

Dialog message text:

The supplied password does not match this encryption key's password. ADMT's
Password Migration Filter DLL will not install without a valid encryption key.

Cause
The supplied password was correct, but Windows Installer (msiexec.exe) failed to open a
handle to the policy object on the domain controller for saving the password that will be
used by the PES service. The failure indicates that the user account didn't have the
required permission.

The user who installs the PES service must be a member of the domain's built-in
Administrators group.
In addition, if the user account isn't a member of the built-in Administrators account,
and User Account Control (UAC) is enabled on the domain controller, the user runs with
least user privileges after logon. To access the policy object on the domain controller for
installing the PES service, the user must launch the Pwdmig.msi setup file with full
privileges.

Resolution
Ensure the user account who installs the PES service is a member of the domain's built-
in Administrators group by running the whoami /groups command, and then run the
Pwdmig.msi setup file in an elevated command prompt window launched with the Run
as administrator option.

Alternatively, you can launch an elevated command prompt window, change the
directory to the one where you downloaded the PES installer, and then run the msiexec
/i pwdmig.msi command.

More information
If you see that the output of the command whoami /groups looks like the following, it
means the user logged in with least user privileges. Although they're a member of the
built-in Administrators group, they don't have permissions to perform administrative
tasks with this token.

Whoami /groups output:

ﾉ Expand table

Group Name Type SID Attributes

========== ========== ========== ==========

Everyone Well-known S-1-1-0 Mandatory group, Enabled by

group default, Enabled group

BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only

BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by

default, Enabled group

....
Feedback
Was this page helpful?  Yes  No

Provide product feedback

ADMT 3.2 installation incomplete, MMC
console error "cannot open database
'ADMT' requested by the login"
Article • 02/19/2024

This article provides help to an error (Cannot open database "ADMT" requested by the
login. The logon failed) that occurs when you run Active Directory Migration Tool
(ADMT) console.

Applies to: Windows Server 2012 R2

Original KB number: 2266373

Symptoms
When installing ADMT 3.2 on a Windows Server 2008 R2 domain controller and using
SQL Express 2008 with SP1 and SQL 2008 Cumulative Update 4, the installation
completes without errors. However, the dialog "Active Directory Migration Tool
Installation Wizard" is blank when the install is finished.

When then attempting to run the ADMT console, you receive error:

Active Directory Migration Tool

Unable to check for failed actions.:DBManager.IManageDB.1: Cannot open database
"ADMT" requested by the login. The logon failed.

The MMC console then displays:

MMC could not create the snap-in.

MMC could not create the snap-in. The snap-in might not have been installed
correctly.
Name: Active Directory Migration Tool
CLSID: {E1975D70-3F8E-11D3-99EE-00C04F39BD92}

Cause
There is a code defect in how ADMT interoperates with SQL Express 2008 SP1 on
domain controllers resulting in the
"SQLServerMSSQLUser$ComputerName$InstanceName" group not being created. This
group is required by ADMT to configure specific permissions during the ADMT install
and allows the ADMT database to be created in the SQL instance. ADMT expects the
group to be present, which leads to the blank dialog and an incomplete installation.

Workaround 1
The standard practice is to install ADMT on a member computer in the target domain.
Install SQL Express 2008 SP1 on a Windows 2008 R2 member server in the target
domain and then install ADMT 3.2 on that same member server.

Workaround 2
If you have a requirement to install ADMT 3.2 on a domain controller in order to use
command-line or scripted user migrations with SID History, install SQL 2008 SP1 (non-
Express edition) on a Windows Server 2008 R2 member server in the target domain and
select that remote instance when installing ADMT 3.2 on the domain controller.
Alternatively, you can install SQL Express 2005 SP3 on the domain controller.

Workaround 3
If you have a requirement to install ADMT 3.2 and SQL Express 2008 SP1 on the same
domain controller, use the following steps on the target domain's domain controller:

1. Install the Cumulative Update Package 4 for SQL Server 2008 on the domain
controller.

2. Install SQL Express 2008 SP1 on the domain controller. Note the SQL instance
name created during the install (default is SQLEXPRESS).

3. Create a domain local group with the format of

"SQLServerMSSQLUser$<DCComputerName>$<InstanceName>". For example, if
the domain controller is named "DC1" and the SQL instance was "SQLEXPRESS"
you would run the following command in an elevated command prompt:

Console

NET LOCALGROUP SQLServerMSSQLUser$DC1$SQLEXPRESS /ADD

4. Retrieve the SQL service SID using the SC.EXE command with the name of the SQL
service instance. For example, if the SQL instance was "SQLEXPRESS" you would
 run the following command in an elevated command prompt and note the
returned SERVICE SID value:

Console

SC SHOWSID MSSQL$SQLEXPRESS

5. In the Windows directory, create the "ADMT" subfolder and a subfolder beneath
that named "Data". For example, you would run the following command in an
elevated command prompt:

Console

MD %SystemRoot%\ADMT\Data

6. Using the SID retrieved in Step 4, set FULL CONTROL permissions on the
%SystemRoot%\ADMT\Data folder. For example, if the SID returned in Step 4 was
"S-1-5-80-3880006512-4290199581-3569869737-363123133" you would run the
following command in an elevated command prompt:

Console

ICACLS %systemroot%\ADMT\Data /grant *S-1-5-80-3880006512-4290199581-

3569869737-363123133:F

7. Install ADMT 3.2 on the domain controller while selecting the local SQL Express
2008 instance.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Known issues that may occur when you
use ADMT 3.1 to migrate to a domain
that contains Windows Server 2008 R2
domain controllers
Article • 02/19/2024

This article describes known issues that you may experience when you use Active
Directory Migration Tool 3.1 to migrate Active Directory data to a domain, and provides
help to resolve these issues.

Applies to: Windows Server 2012 R2

Original KB number: 976659

Summary
Although Active Directory Migration Tool (ADMT) 3.1 is not intended to target Windows
Server 2008 R2, Microsoft has verified that this tool can be used to migrate Active
Directory data to a domain hosted by one or more Windows Server 2008 R2 domain
controllers. However, there are known issues with this approach. This article outlines
these issues and provides workarounds.

More information
The following list describes updated supported scenarios for using ADMT 3.1:

ADMT 3.1 must be run from a Windows Server 2008-based computer. The
computer must be a member server or a domain controller.
ADMT can be installed on any computer that is running Windows Server 2008,
unless the computers are Read-Only domain controllers or in a Server Core
configuration.
The target domain must be based on Windows 2000 Server, Windows Server 2003,
Windows Server 2008, or Windows Server 2008 R2.
The source domain must be based on Windows 2000 Server, Windows Server 2003,
or Windows Server 2008.
The ADMT agent, which is installed by ADMT on computers in the source domains,
can operate on computers that are running Windows 2000 Professional, Windows
 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server
2008, Windows 7, or Windows Server 2008 R2.

７ Note

If you do not have Windows Server 2008 because you upgraded from Windows
2000 or Windows Server 2003 to Windows Server 2008 R2, you do have downgrade
rights. To obtain product keys and media for Windows Server 2008 R2, visit this
site .

Known issues
The following known issues may occur when you use ADMT 3.1 to migrate data to a
Windows Server 2008 R2 Active Directory environment:

The Computer Migration Wizard lists Managed Service Accounts as selectable

objects. These objects cannot be migrated by using ADMT 3.1. Although these
objects can be selected, the wizard will fail (non-blocking) migrations of these
objects and exit with an error.

Managed Service Account is a new Windows Server 2008 R2 feature. For more
information, visit the following Microsoft Web page:

What's New in Service Accounts

Security translation on registry keys may fail (nonblocking). When the issue occurs,
the administrator may receive an error message that resembles any of the
following:

ERR3:7330 Failed to open registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009, rc=714 The specified registry key is referenced by a
predefined handle.

ERR3:7330 Failed to open registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows
NT\CurrentVersion\Perflib\009, rc=714 The specified registry key is referenced by a
predefined handle.

ERR3:7331 Failed to enumerate registry key HKEY_DYN_DATA, rc=120 This function

is not supported on this system.
 Multiple user password migration in a batch may fail for the first user password.
When this issue occurs, the administrator may receive an error message that
resembles the following:

Unable to establish a session with the password expert server: The RPC server is
unavailable

To resolve this issue, perform the password migration again.

Scripted migration of users to populate the SID History fails when it is
performed on a member server in the target domain. When you use the
ADMT.EXE command-line tool or script to migrate SID history, you must
perform the migration on a Windows Server 2008-based domain controller in
the target domain.
The Admtdb.exe tool does not validate the version of a remote database
instance. The administrator must make sure that the remote database server is
running Microsoft SQL Server 2000 with Service Pack 4, SQL Server 2005, or a
later version. For more information about migrating user accounts, visit the
following Microsoft Web page: Migrating All User Accounts

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Support policy and known issues for
Active Directory Migration Tool
Article • 02/19/2024

This article discusses information about the current level of support for Active Directory
Migration Tool (ADMT) on current Windows Client and Windows Server operating
systems. This article also lists known issues that administrators might experience when
they try to migrate user profiles, security principals, passwords, or security identifier
history (sIDHistory) data between Active Directory domains and forests.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2
Original KB number: 4089459

Microsoft support by operating system

ADMT was released as a free download to support the migration to Windows
2000/Windows Server 2003-era operating systems.

ADMT hasn't been updated to support the following operating systems:

Windows 11
Windows 10
Windows 8.1
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2

When you run ADMT on operating systems that aren't supported, you might experience
the following known issues:

ADMT can't migrate user profiles from operating systems that are later than
Windows 7 or Windows Server 2008 R2 to other operating systems. ADMT also
can't migrate user profiles to operating systems that are later than Windows 7 or
Windows Server 2008 R2 from older operating systems.
ADMT isn't compatible with the secure defaults that modern operating systems
use.
ADMT hasn't been tested together with later versions of Microsoft SQL Server. If
you use ADMT in such circumstances, you might see incompatibilities or other
 issues.

） Important

Your experience in using ADMT depends on many factors, including the Windows
version that you are migrating from and the Windows version that you are
migrating to. Use the tool at your own risk.

Commercial Windows support case policy

Microsoft handles support cases for ADMT issues completely on a "best effort" basis.
Support cases might not be escalated to the product teams. Microsoft can't guarantee
that issues will be resolved.

Code-level support policy

The ADMT 3.2 code base has been deprecated. Microsoft has officially halted any
development on the ADMT code base. ADMT isn't eligible for security fixes, bug fixes, or
design changes.

Common support scenarios and known issues

This section lists the most common issues that you might experience when you use
ADMT.

） Important

Many of these issues occur because of changes that have improved the
functionality or security of Windows. Some solutions to these issues involve making
temporary changes to Windows that nullify these improvements. Use these
solutions at your own risk.

ADMT won't run on devices that have Windows Defender

Credential Guard enabled
Issue: You see errors that resemble the following:
 Failed to move source object CN=User1. Verify that the caller's account is not
marked sensitive and therefore cannot be delegated. hr=0x8009030e. No
credentials are available in the security package.

Solution: Temporarily disable Credential Guard on the ADMT server.

） Important

Consult your security team before you change the Credential Guard configuration.
Back up the ADMT server before you make any changes.

The Manage Windows Defender Credential Guard topic provides a script that disables
Credential Guard. In addition to running the script, disable the Computer
Configuration\Administrative Templates\System\Device Guard\Secure Launch
Configuration Group Policy Object (GPO). Otherwise, the computer will re-enable
Credential Guard the next time that it starts.

７ Note

On devices that run Windows Server 2022, Credential Guard is enabled if the GPO
that's described here is set to Not Configured.

Domain controllers can't use unconstrained delegation

Issue: During the migration process, ADMT requires that domain controllers use
unconstrained delegation. This practice is no longer allowed or recommended.

Solution: Install and run ADMT apps on the target domain controller. This configuration
removes the need for delegation.

Modern apps don't start for a user who uses a migrated

user profile
Issue: When you use ADMT 3.2 to migrate a user profile to a Windows Client computer,
and then you run the Security Translation wizard to update the profile, modern
applications don't run. These apps include both built-in apps (such as the Windows Start
menu and Search) and apps that are installed from the Windows Store.

Intra-forest migrations are most at risk for this behavior. This is because intra-forest
migrated user accounts can't be restored to the original source domain.
Solution: After you complete the migration, uninstall the modern apps, and then
reinstall them from the Windows Store.

For more information about this issue, see Windows App cannot start after ADMT 3.2
security translation runs in Windows 8, Windows 8.1 and Windows 10.

Security translation resets file associations

Issue: You migrate a user profile, and then you run the security translation wizard in Add
mode. When you sign in to the computer for the first time after the migration, you use
the original (source) user credentials instead of the migrated (target) user credentials.
The file associations reset to their default values, and any custom associations are lost.

In Windows 10, a custom file association is protected from unwanted modifications by

using a hash that's based in part on the user's security identifier (SID). The custom file
association and the hash are stored in the registry. When the user is migrated to a new
domain, the new user account receives a new SID. All file association hashes must be
updated accordingly.

Solution: As soon as the migration finishes, disable the source user account. This action
prevents the issue from occurring.

Objects that have child objects aren't migrated

Issue: When ADMT tries to migrate an object that has a child object, the migration fails,
and ADMT logs the following entry in the migration error log:

Error 7422: Failed to move source object CN=<object name>. hr=0x8007208c The
operation cannot be performed because child objects exist. This operation can only
be performed on a child object.

A few examples of child objects that block migration include, but aren't limited to, the
following:

Exchange Active Sync

Microsoft Dynamic GP
TermSrvLicensing
Citrix SSOSecret and SSOConfig

Solution: You have to delete the child object (also known as a leaf object) in order to
migrate the parent object. For example, you would have to delete the Exchange
ActiveSync object. Otherwise, there's no known workaround.
Computer migration fails on devices that have custom
DNS suffixes
Issue: During an inter-forest migration, you migrate computers that are configured to
retain their primary DNS suffix when their domain membership changes. The ADMT
post-migration check fails when ADMT tries to verify the domain membership of the
migrated computer. The error messages resemble the following examples:

Error 7711: Unable to retrieve the DNS hostname for the migrated computer
'workstation1.contoso.com'. The ADSI property cannot be found in the property
cache. (hr=0x8000500d) Post-check will be retried on the computer 'workstation1'

Error 7709: Post-check failed on the computer 'workstation1.contoso.com'

Error 7675: Unable to verify the migrated computer 'workstation1' belongs to the
domain 'tailspintoys.com'. Access is denied. (hr=0x80070005)

To check this configuration, open the System properties on the computer. To do this,
select Start > Settings > About > Advanced system settings > Computer Name >
Change > More. If Change primary DNS suffix when domain membership changes
isn't selected, the computer is affected by this issue.

Solution: Try one of the following methods:

Manual configuration. After you join the computer to the target domain, remove
the SPNs from the account in the source domain. Alternatively, you can delete the
computer account in the source domain.

Answer file configuration. Use SyncDomainWithMembership. You can set

SyncDomainWithMembership to 1. This is the equivalent of enabling Change primary

DNS suffix when domain membership changes. Then during migration, the
computer registers SPNs that match the new domain and doesn't conflict anymore.

ADMT 3.2 doesn't start if TLS 1.0 is disabled on the SQL

Server database host
Issue: On a device that hosts a SQL Server database, ADMT 3.2 doesn't start, and it
displays SSL Security errors if TLS 1.0 was disabled. This occurs even if ADMT is installed
on the same computer as the SQL Server instance. The error message resembles the
following:
 The system cannot find the file specified.

Solution: On the computer on which ADMT is installed, temporarily enable TLS 1.0.
ADMT works even if TLS 1.0 is disabled on the domain controller.

） Important

Consult your security team before you enable TLS 1.0.

Password Export Server (PES) fails if LSA Protection is

enabled
Issue: Password migration fails and generates an error message that resembles the
following:

Unable to establish a session with the password export server. The RPC server is
unavailable.

Solution: ADMT Password Migration works only if LSA protection is disabled.

） Important

Consult your security team before you change the LSA Protection configuration.
Back up the computer before you make any changes.

Local profiles aren't migrated

Issue: When you run ADMT 3.2 and the Security Translation wizard, ADMT migrates local
user accounts but not local profiles.

Solution: This behavior is by design.

More information
ADMT is available for download at Active Directory Migration Tool version 3.2 .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to Troubleshoot Inter-Forest
Password Migration with ADMTv2
Article • 02/19/2024

This article discusses the dependencies and troubleshooting steps for common
problems associated with the inter -forest password migration operation.

Applies to: Windows Server 2003

Original KB number: 322981

Summary
If you perform intra-forest migrations by using the Active Directory Migration Tool
(ADMT) v2, no special configuration is needed to maintain user passwords, sIDHistory,
and object globally unique identifiers (GUIDs) during the move operation.

However, if you use ADMTv2 to perform inter-forest password migration when you
clone user accounts, this operation relies on dependencies that the administrator must
configure. This article discusses the dependencies and troubleshooting steps for
common problems associated with this operation.

Configuration
Beyond basic configuration, ADMTv2 requires the following dependencies when used to
perform inter-forest password migration:

Service Pack 6a (SP6a) or later must be installed on Microsoft Windows NT 4.0

domain controllers.

All domain controllers must use 128-bit encryption.

The RestrictAnonymous value on the target domain controller should be set to 0

during the migration.

Read permissions on the Pre-Windows 2000 Compatible Access group should be

set to CN=Server,CN=System,DC={targetdom},DC={tld}.

The following registry key should be configured on the Password Export Server:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExp
ort = 1
 The Password Export Server must be restarted after the registry is edited.

The Everyone group should be a member of the Pre-Windows 2000 Compatible

Access group in the target domain during the migration. This action is blocked by
Active Directory Users and Computers. To add the Everyone group, run the
following command: NET LOCALGROUP "PRE-WINDOWS 2000 COMPATIBLE
ACCESS" EVERYONE /ADD

If the target domain is Windows Server 2003-based, run this command to make
the following group a member of the Pre-Windows 2000 Compatible Access
group: NET LOCALGROUP "PRE-WINDOWS 2000 COMPATIBLE ACCESS"
"ANONYMOUS LOGON" /ADD

Troubleshooting
The following are some of the more common error messages and their resolutions:

Unable to establish a session with the password export server. The target server
\SERVER does not have an encryption key for source domain {SRCDOM}. This error
may be caused by one of the following configuration problems:

The Password Export Server has not been configured with the Password Migration
DLL and an encryption key for the target server.

-or-

The encryption key was created and installed, but ADMT is running on a different
computer than the computer that created the encryption key. Password Migration
encryption keys are valid per-computer instead of per-domain.

WRN1:7557 Failed to copy the password for {user}. A strong password has been
generated instead. Unable to copy password. Access is denied. If this error
message appears in the Migration.log file, verify the following:

The following registry key value is set on the target domain controllers:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\RestrictAnonymou
s=0

Pre-Windows 2000 Compatible Access has Read and Enumerate Entire SAM
Domain permissions on the object, as follows: CN=Server,CN=System,DC=
{TargetDomain},DC={tld}

W1:7557 Failed to copy the password for {User}. A strong password has been
generated instead. Unable to copy password. The RPC server is unavailable. This
 error message typically indicates a failure to resolve names. Verify that Domain
Name System (DNS) and NetBIOS (WINS) name resolution is working correctly for
both domains.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot inter-forest
sIDHistory migration with ADMTv2
Article • 02/19/2024

This article describes how to troubleshoot inter-forest sIDHistory migration with Active
Directory Migration Tool version 2 (ADMTv2).

Applies to: Windows Server 2012 R2

Original KB number: 322970

More information
When you are using ADMTv2 to migrate sIDHistory as part of an inter-forest user or
group migration, configuration is required with the base migration requirements.

By default, sIDHistory, password, and objectGUID are all preserved during intra-forest
migrations, but this is not true for inter-forest cloning.

Because there is no built-in security context for inter-forest operations, you must take
steps to protect the security of operations across forest boundaries.

Configuration
The basic requirements for inter-forest migration operations are:

Wizard-based basic user and group account migration without

sIDHistory

The source domain must trust the target domain.

The user account that is running ADMTv2 must have Administrator rights in the
source domain.
The ADMT user account must have delegated permissions to create user or group
objects in the target container.
DNS (hostname) and NetBIOS name resolution between the domains must exist.

sIDHistory migration requires the following additional

dependencies
 Success and failure auditing of account management for both source and target
domains.
Source domains call this user and group management auditing.
An empty local group in the source domain that is named
{SourceNetBIOSDom}$$$.
The
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport

registry key must be set to 1 on the source domain primary domain controller.
You must restart the source domain primary domain controller after the registry
configuration.
Windows security requires user credentials with the delegated MigratesIDHistory
extended right or administrator rights in the target domain. You add these
credentials in the wizard when sIDHistory migration is turned on.

To delegate the MigrateSidHistory extended right on a domain controller or on a

computer that has the Windows Server Administration Tools pack installed, follow these
steps:

1. Click Start, click Administrative Tools, and then click Active Directory Users and
Computers.
2. Right-click the name of the domain that you want to delegate the
MigrateSidHistory extended right from, and then click Delegate Control to open
the Delegation of Control Wizard window.
3. Click Next, click Add, enter the name of the user or group that you wish to add in
the Select Users, Computers, or Groups dialog box, click OK, and then click Next.
4. Click to select the Create a custom task to delegate option, and then click Next.
5. Make sure that the This folder, existing objects in this folder, and creation of new
objects in this folder option is selected, and then click Next.
6. Make sure that the General option is selected, click Migrate SID History in the
Permissions list, and then click Next.
7. Verify that the information is correct, and then click Finish.

No sID to be migrated may exist in the target forest, either as a primary sID
or as an sIDHistory attribute of another object.

Additional requirements for migrating sIDHistory with the

command line or scripting interfaces
When you start a user or group migration with sIDHistory migration from the
command line or from a script, the command or script must be run on the domain
controller in the target domain.
 The user account that is running the migration must have administrator rights in
both the source and the target domains.

Special requirements for group mapping and merging wizard

If sIDHistory is to be migrated during group mapping and merging, the scope of

the source groups must match the scope of the target group.

Troubleshooting
The most basic step you can use to troubleshoot inter-forest sIDHistory migration is to
use the User Account Migration Wizard or the Group Account Migration Wizard to run a
test-mode migration.

During the test-mode migration, ADMTv2 validates the following dependencies:

The {SourceNetBIOSDom}$$$ local group is created.

TcpipClientSupport on the source primary domain controller or primary domain
controller emulator is turned on.
Auditing in both domains is turned on.

Optionally, ADMT can repair any of these dependencies that are not set. To repair or
configure these settings, the account that is used to run ADMT must have enough
permissions in each respective domain to carry out the tasks.

Only the wizard performs these checks and corrections. The command line and scripting
interfaces do not perform these checks, and do not work without correct configuration.

Common error messages with inter-forest sIDHistory

migration
"The handle is invalid (Error code = 6)."

This error indicates an RPC problem where the migration tool cannot bind to an RPC
endpoint on the source primary domain controller. Possible causes include:

TcpipClientSupport on the source primary domain controller or primary domain

controller emulator has not been turned on.
The primary domain controller or primary domain controller emulator was not
restarted after TcpipClientSupport was configured.
DNS or NetBIOS name resolution is not working.
 Could not verify auditing and TcpipClientSupport on domains. Will not be able to
migrate Sid's. The specified local group does not exist.

This error typically indicates that a user or a global or universal group with the
{SourceNetBIOSDom}$$$ name already exists. ADMT typically creates the local group of
that name, but it cannot do so if a security principal already exists with the name.

Could not verify auditing and TcpipClientSupport on domains. Will not be able to
migrate Sid's. Access is Denied.

This error typically indicates that the user account that is used to run ADMT does not
have enough permissions to perform the migration in one or both of the
domains.Domain name lookup failed, rc=1332. No mapping between account names
and security IDs was done. This error in the Migration.log file after a migration with
sIDHistory typically indicates that the source domain has configured trusts that do not
exist on the target domain. To resolve this issue, run the Trust Migration Wizard to map
the trusts in the source domain, and then replicate the relationships in the target
domain.

Additional sIDHistory information

The sIDHistory is a multivalued attribute of security principals in the Active Directory
that may hold up to 850 values. To provide backward-compatibility with domain
controllers that are running earlier versions of Windows, the sIDHistory attribute is only
available in domains that are operating at the functional level of Windows.

Some third-party vendor products make it possible to turn on sIDHistory in mixed mode
domains. These claims do not represent the legitimate use of public APIs. Domain
administrators that use such tools risk putting their Active Directory deployment in an
unsupported state.

During intra-forest migrations, LDAP_Rename is responsible for moving objects. Because

of this, migrated objects retain important identification data, including the objectGUID
and password. This is not the case for inter-forest migrations, which call
DSAddSidHistory to populate the attribute in the target domain. Password migration
may be turned on for inter-forest cloning, but the objectGUID is always lost during this
type of migration.

In both cases, migrated objects are assigned a new sID by the target domain. The
original sID is added to the sIDHistory attribute of the migrated object in the new
domain. After this occurs, the sIDHistory attribute may not be modified or deleted by
using the standard Active Directory administration tools. This is not permitted because
the sIDHistory attribute is owned by the SAM. It is possible to clear the sIDHistory by
using a script or a non-public Microsoft internal tool.

Note that the sIDHistory is a transitional tool and is not meant to exist indefinitely
attached to security principals. Although migrating the sIDHistory can significantly ease
and simplify the domain migration process, there are important security ramifications
that must be considered before you implement the sIDHistory in a production
enterprise.

A Windows security token can hold a maximum of 1,023 sIDs, including sIDHistory and
group sIDs. Kerberos is also limited because Windows Kerberos has a 73-sID buffer. This
size can be doubled by an enterprise-wide registry change. Exceeding these limits
violates the MaxTokenSize restriction and can lead to unpredictable results, including
failure of Kerberos authentication and erratic or nonexistent application of policies. To
prevent these issues, use Security Translation instead of sIDHistory as the long-term
solution to maintaining resource access after a domain migration.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows App cannot start after ADMT
3.2 security translation runs in Windows
8, Windows 8.1 and Windows 10
Article • 02/19/2024

This article provides a solution to an error that occurs when Windows App cannot start
after ADMT 3.2 security translation runs.

Applies to: Windows 10 - all editions

Original KB number: 3145204

Symptoms
Consider the following scenario:

You create a user account in domain A.

You link a Microsoft Account (MSA) to the user account.
You log on to a Windows 8-based, Windows 8.1-based, or Windows 10-based
computer by using the user account, and then you install a Windows app.
You use Active Directory Migration Tool (ADMT) 3.2 to migrate the user account
from domain A to domain B.
You run a security translation to update the permissions settings on the client
computer by using the users new domain SID.
You log off and then log back on by using the migrated user account.

In this scenario, the following issues occur:

Security translation fails and generates error 1314 in the ADMT log on the client on
which the security translation agent ran. The log entry resembles the following.

ﾉ Expand table

Decimal Hex Symbolic Friendly

1314 0x522 ERROR_PRIVELEGE_NOT_HELD A required privilege is not held by the

client.

Built-in and store applications can't start on Windows 8-based, Windows 8.1-
based, or Windows 10-based computers.
 Clicking the Start button does not open the Start menu on Windows 10-based
computers.

If you switch to Tablet mode and then switch back to the previous mode in
Windows 10, the Start menu continues to work but other built-in and store
applications do not start.

Search is unresponsive.

The Settings application does not start on Windows 10-based computers when
you click the Settings icon directly or use the Windows+I keyboard shortcut. This
application works the first time that it is started, and it also works when you use
the Display settings shortcut menu on the desktop.

You cannot view .jpg files because the modern application that is assigned in the
file associations tool does not start. When this occurs, you receive the following
error message:

Invalid value for registry

When you click the Store application in the Windows taskbar of a Windows 10-
based computer, the command fails, and you receive the following error message:

This app can't install.

Workaround
To work around this issue, follow these steps:

1. Migrate user accounts on a pre-Windows 8 operating system to the destination

domain before you upgrade the accounts to Windows 10.
 2. For Windows apps that are installed from the Microsoft Store, uninstall and then
reinstall the app.
3. Protect application data: Back up and restore data as required to avoid data loss.
Data can be copied or restored to a new or different user account that is not yet
subject to security translation.

References
Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active
Directory Domains

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory changes do not
replicate
Article • 02/19/2024

This article provides a solution to an issue where the replication isn't completed when
you replicate Active Directory directory service changes to a domain controller.

Applies to: Windows Server 2012 R2

Original KB number: 830746

Symptoms
When you try to replicate Active Directory directory service changes to a Microsoft
Windows Server 2003-based domain controller, the replication is not completed.

In the event log, you may see events that are similar to the following: In this situation,
you also see error 1818 in the output of the repadmin /showrepl command and in the
output of the repadmin /showreps command.

Cause
This issue may occur when destination domain controllers that are performing remote
procedure call (RPC)-based replication do not receive replication changes from a source
domain controller within the time that the RPC Replication Timeout (mins) registry
setting specifies. You might experience this issue most frequently in one of the following
situations:

You promote a new domain controller into the forest by using the Active Directory
Installation Wizard (Dcpromo.exe).
Existing domain controllers replicate from source domain controllers that are
connected over slow network links.

The default value for the RPC Replication Timeout (mins) registry setting on Windows
2000-based computers is 45 minutes. The default value for the RPC Replication Timeout
(mins) registry setting on Windows Server 2003-based computers is 5 minutes. When
you upgrade the operating system from Windows 2000 to Windows Server 2003, the
value for the RPC Replication Timeout (mins) registry setting is changed from 45
minutes to 5 minutes. If a destination domain controller that is performing RPC-based
replication does not receive the requested replication package within the time that the
RPC Replication Timeout (mins) registry setting specifies, the destination domain
controller ends the RPC connection with the non-responsive source domain controller
and logs a Warning event.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base: 322756 How to back up and restore the registry in Windows

To resolve this issue, increase the bandwidth of your network connection so that the
Active Directory changes replicate in the five-minute timeout period. If you cannot
increase the bandwidth of your network connection, edit the registry on your Windows
Server 2003-based computer to increase the value of the RPC timeout for Active
Directory replication. To increase the RPC timeout value, follow these steps:

1. Start Registry Editor.

2. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

3. Right-click Parameters, point to New, and then click DWORD Value.

4. Type RPC Replication Timeout (mins), and then press ENTER to name the new
value.
5. Right-click RPC Replication Timeout (mins), and then click Modify.
6. In the Value data box, type the number of minutes that you want to use for the
RPC timeout for Active Directory replication, and then click OK. On a Windows
Server 2003-based computer that is part of a Windows 2000 environment or that
was upgraded from Windows 2000 Server, you may want to set this value to 45
minutes.

７ Note

You must restart the computer to activate any changes that are made to RPC
Replication Timeout (mins).
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 1256: The remote system is
not available
Article • 04/08/2024

This article describes the symptoms, cause, and resolution steps for cases when Active Directory replication fails with error 1256: The
remote system is not available.

Applies to: All supported versions of Windows Server

Original KB number: 2200187

Symptoms
1. The DCDIAG reports that the Active Directory Replications test has failed with error 1256: The remote system is not available.

Starting test: Replications

[Replications Check, <Destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (1256):
The remote system is not available. For information about network troubleshooting, see Windows Help.
The failure occurred at <date> <time>
The last success occurred at <date> <time>

2. REPADMIN.EXE reports that a replication attempt has failed with status 1256. REPADMIN commands that commonly cite the
1256 status include but are not limited to:

REPADMIN /REPLSUM

REPADMIN /SHOWREPS
REPADMIN /SHOWREPL

REPADMIN /FAILCACHE

Sample output from REPADMIN /SHOWREPS depicting inbound replication from LonEMEADC to LonContosoDC failing with The
remote system is not available error is shown below:

Repadmin: running command /showrepl against full DC localhost

London\LONCONTOSODC
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: a29bbfda-8425-4cb9-9c66-8e07d505a5c6
DSA invocationID: d58a6322-6a28-4708-82d3-53b7dcc13c1a

==== INBOUND NEIGHBORS ======================================

<snip>
DC=ForestDnsZones,DC=Contoso,DC=com
London\LONEMEADC via RPC
DSA object GUID: cd691606-63d1-4cc8-b77a-055674ba569d
Last attempt @ 2010-06-10 17:35:46 failed, result 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
<#> consecutive failure(s).
Last success @ <date> <time>.

3. NTDS KCC, NTDS Replication, or ActiveDirectory_DomainService events with the 1256 status are logged in the directory service
event log.

ﾉ Expand table
 Event Source Event Event String
ID

NTDS Replication 1085 * Internal event: Active Directory Domain Services could not synchronize the following directory
ActiveDirectory_DomainService partition with the directory service at the following network address.

NTDS KCC 1308 The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate
ActiveDirectory_DomainService with the following domain controller has consistently failed. The Knowledge Consistency
Checker (KCC) has detected that successive attempts to replicate with the following directory
service has consistently failed.

７ Note

Event 1085 is only logged if the NTDS Diagnostics value 5 Replication Events has been set to a value of 1 or higher.

Cause
Replication status 1256 is logged for the following reason:

When the destination DC fails to bind to the source DC using RPC a win32 error code in the Repsfrom status for that partition -
usually Schema or Configuration since these partitions are replicated at a higher priority. After an RPC bind failure has occurred, a
cleanup routine will run to clear the destination DCs queue from that same source DC. This is done to avoid wasting time attempting
to replicate with a DC that it can't connect to. Since it hasn't attempted a sync for the partitions that have been cleared from the
queue, a status 1256 is logged. In a scenario where destination DC replicates Schema, Configuration, and several GC non-writable
partitions from the source DC, the win32 error status for the Schema and Configuration partitions that caused the RPC bind failure is
logged. The destination DC will then cancel the pending replication tasks for the remaining partitions and log win32 error 1256 for
the status.

In summary: 1256 is logged as the replication status per partition as a result of the destination DC cancelling the sync request from
the source DC due to a connectivity failure previously encountered.

Resolution
The win32 error 1256 should not be the focus of troubleshooting efforts, instead find the replication status that led to the RPC bind
failure and then follow the corresponding Troubleshooting Active Directory operations that fail with error... article.

Diagnose Active Directory replication failures.

In order to determine the actual win32 error to troubleshoot, use one of the following methods:

1. View repadmin /showreps or /showrepl output on the destination DC

a. Identify Source DC in the output and list all win32 status messages per partition
b. The win32 status that is listed that is not a 1256 should be the focus of troubleshooting efforts

2. Use repadmin /showrepl * /csv output:

a. Filter column K, Last Failure Status: Deselect 0 and (Blanks)
b. Filter column C, Destination DSA: Deselect (Select All) and select just the DC where the 1256 status is logged.
c. If 1256 is logged on more than one Source DC, Filter column F, Source DSA: Deselect (Select All) and Select just one DC to
narrow the focus.
d. Column K, Last Failure Status will list the 1256's along with the real win32 error that led to the RPC bind failure.

In the following example, win32 error 1722 is logged for the Configuration and Schema partitions and should be the focus of
troubleshooting.

ﾉ Expand table

B C D E F H I J K

Destination Destination DSA Naming Context Source Source DSA Number Last Last Last
DSA Site DSA of Failure Success Failure
Site Failures Time Time Status
 B C D E F H I J K

London LONCONTOSODC CN=Configuration,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1722

17:35 14:50

London LONCONTOSODC CN=Schema,CN=Configuration, London LONEMEADC 11 6/10/2010 6/10/2010 1722

DC=Contoso,DC=com 17:36 14:50

London LONCONTOSODC DC=ForestDnsZones,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:50

London LONCONTOSODC DC=corp,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:50

London LONCONTOSODC DC=EMEA,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:54

London LONCONTOSODC DC=apac,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:50

3. Initiate a manual replication sync between source and destination DCs using repadmin.

Repadmin /replicate DestinationDC SourceDC <DN of partition reporting status 1256> (This will require /readonly switch for

GC partition or /selsecrets switch if destination is an RODC)

repadmin /replicate loncontosodc lonemeadc.emea.contoso.com dc=forestdnszones,dc=contoso,dc=com

DsReplicaSync() failed with status 1722 (0x6ba):

The RPC server is unavailable.

Take note that after manually initiating replication for the partition that the status has changed from 1256 to 1722:

ﾉ Expand table

B C D E F H I J K

Destination Destination DSA Naming Context Source Source DSA Number Last Last Last
DSA Site DSA of Failure Success Failure
Site Failures Time Time Status

London LONCONTOSODC CN=Configuration,DC=Contoso, London LONEMEADC 11 6/10/2010 6/10/2010 1722

DC=com 17:35 14:50

London LONCONTOSODC CN=Schema,CN=Configuration, London LONEMEADC 11 6/10/2010 6/10/2010 1722

DC=Contoso,DC=com 17:36 14:50

London LONCONTOSODC DC=ForestDnsZones, London LONEMEADC 12 6/10/2010 6/10/2010 1722

DC=Contoso,DC=com 17:46 14:50

London LONCONTOSODC DC=corp,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:50

London LONCONTOSODC DC=EMEA,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:54

London LONCONTOSODC DC=apac,DC=Contoso,DC=com London LONEMEADC 11 6/10/2010 6/10/2010 1256

17:35 14:50

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in
Gather information by using TSS for Active Directory replication issues.

More information
The following articles contain the troubleshooting procedures for errors typically logged with win32 error 1256:
 ﾉ Expand table

Win32 error Article

-2146893022 Active Directory replication error -2146893022: The target principal name is incorrect

5 Active Directory replication error 5 - Access is denied

1722 Active Directory replication error 1722: The RPC server is unavailable

1727 Troubleshoot domain controller replication error 1727-The remote procedure call failed and did not execute

1753 Active Directory Replication Error 1753: There are no more endpoints available from the endpoint mapper

1908 Troubleshooting Active Directory operations that fail with error 1908: Could not find the domain controller for this domain

8524 Active Directory Replication Error 8524: The DSA operation is unable to proceed because of a DNS lookup failure

8453 Active Directory replication error 8453: Replication access was denied

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 8304:
"The maximum size on an object has
been exceeded"
Article • 02/19/2024

Original KB number: 4533837

Applies to: Supported versions of Windows Server

Summary
This article discusses the causes and solutions for the Active Directory replication error
8304 (0x2070): "The maximum size on an object has been exceeded".

７ Note

You can get the friendly text of the error code by running the net helpmsg 8304
command.

Symptoms
You may experience one of the following symptoms.

Symptom 1
The dcdiag command reports that the Active Directory replication test failed and
generated error 8304: "The maximum size of an object has been exceeded."

Output

Starting test: Replications

[Replications Check, <DESTINATION DC>] A recent replication attempt
failed:
From <SOURCE DC>to <DESTINATION DC>
Naming Context: <directory partition DN path>
The replication generated an error (8304):
The maximum size of an object has been exceeded.
The failure occurred at <date><time>.
The last success occurred at <date><time>.
......................... <DESTINATION DC> failed test Replications
Symptom 2
When you right-click a connection object from a source domain controller (DC), and
then you select Replicate now, the replication is unsuccessful and generates the
following error message:

Replicate Now

The following error occurred during the attempt to synchronize naming context
<active directory partition name> from domain controller <source DC> to domain
controller <destination DC>:

The maximum size of an object has been exceeded

The operation will not continue

Symptom 3
Various repadmin.exe commands fail and generate error 8304. These commands
include, but are not limited to, the following:

repadmin /add

repadmin /replsum
repadmin /showrepl

repadmin /showrepl

repadmin /syncall

Symptom 4
Event ID 1084 is logged in the Directory Service event log of DCs that are trying to
replicate Active Directory objects inbound.

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1084
Task Category: Replication
Level: Error
User: ANONYMOUS LOGON
Computer: <Destination DC>
Description:
Internal event: Active Directory Domain Services could not update the
following object with changes received from the following source directory
service. This is because an error occurred during the application of the
 changes to Active Directory Domain Services on the directory service.

Object:
CN=john\0ADEL:<GUID>,CN=Deleted Objects,<directory partition DN path>
Object GUID:
<GUID>
Source directory service:
<GUID>._msdcs.contoso.com

Synchronization of the directory service with the source directory service

is blocked until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action
Restart the local computer if this condition appears to be related to low
system resources (for example, low physical or virtual memory).

Additional Data
Error value:
8304 The maximum size of an object has been exceeded.

You may also see an event 1093:

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1093
Task Category: Replication
Level: Warning
Computer: <Destination DC>
Description:
Active Directory Domain Services could not update the following object with
attribute changes because the incoming change caused the object to exceed
the maximum object record size. The incoming change to the following
attribute will be reversed in an attempt to complete the update.

Object:
CN=<MachineName>\0ADEL:<GUID>,CN=Deleted
Objects,DC=xxxx,DC=domainname,DC=com

Object GUID:
<GUID>

Attribute:
9030d (lastKnownParent)
The current value (without changes) of the attribute on the local directory
partition will replicate to all other directory services. This will
counteract the change to the rest of the directory services. The reversal
values may be recognized as follows:

Version:
 2

Time of change:
<DateTime>

Update sequence number:

65064475
Note this event may not quote the attribute that has the most data or
values. It quotes the update for the attribute that made the object size
overflow.

Cause
Error 8304 is logged when the domain controller tries to replicate an object that exceeds
the maximum size.

The most common cause is having a non-linked attribute with a big number of values.
Because of the internal structure of the Active Directory database together with the
Active Directory database record size of 8 KB, this limit of the values is about 1200-1300
values, depending on the population of other non-linked attributes.

On the source server, when you use a tool like LDP or run the repadmin /showattr
/allvalues /extended command on the object, the output resembles the following:

Output

1> distinguishedName:<GUID=<GUID>>;CN=Allowedclients\0ADEL:<GUID>,CN=Deleted
Objects,CN=Configuration,DC=contoso,DC=com

1> instanceType: 0x4 = ( WRITE )

1> whenCreated: 25.4.2018. 13:48:07Central European Daylight Time

1> msDS-LastKnownRDN: Allowed clients

1>msExchSmtpReceiveMaxRecipientsPerMessage: 200

1243> msExchSmtpReceiveRemoteIPRanges:10.142.241.142;…

The following are the attributes that you may encounter issue:

proxyAddresses
servicePrincipalName
userCertificate
msExchSmtpReceiveRemoteIPRanges
 dnsRecord
msiFileList
msTSProperty01, msTSProperty02, …
registeredAddress

７ Note

This issue may happen for any multi-valued non-linked attribute. Attribute with
syntax linked or linked with data are not affected by this problem.

Depending on the available resources and actual local database page population, the
limit may be hit at different number of values. This is why a certain change can be taken
by some Domain Controller or LDS instances, but not on others.

This problem might also occur when a single attribute value exceeds approximately 5
MB. The AD database transaction must hold both the previous and the new value when
the attribute value is updated.

Resolution
This limit is independent of the Microsoft LDAP Server OS version. There is no
workaround for this limitation. You need to potentially revise your application and how it
uses this attribute.

The 1084 event will list the object that has exceeded the maximum size. If the object is
an alive object, identify the attribute that has too many values and remove some of the
values on the source domain controller.

If the object is a deleted object, and the Active Directory recycle bin is enabled, the best
method to correct the issue is to force the object to become a recycled object. When
the object is recycled, Active Directory removes most attributes. This typically reduces
the size of the object enough so that it can be replicated successfully. This process will
truly delete the object and make it unrecoverable from the recycle bin. If the object is a
security principal such as a user account, we recommend that you do not undelete the
object. If a sufficiently large object is undeleted, it may prevent some attributes from
being correctly set. This can cause the object to be damaged and may prevent the
object from being used or even deleted.

The following PowerShell command can be used to force the object into the recycled
state.
 ７ Note

The following command must be run on the DC listed in the 1084 event as the
source domain controller. The event will also list the object distinguished name.

PowerShell

Get-ADObject <dn of object> -IncludeDeletedObjects | Remove-ADObject

For example:

PowerShell

Get-ADObject "CN=john\0ADEL:<GUID>,CN=Deleted Objects,dc=contoso,dc=com" |

Remove-ADObject

After the object is recycled, use Active Directory Sites and Services to try to force
replication.

More information
Here are some suggestions to avoid the limit from past Microsoft issues.

Use of dnsRecord attribute by Microsoft DNS Server

Each IP address or SRV name target is an additional value of the dnsRecord attribute. By
default, each domain controller in Active Directory registers a series of names with DNS,
some are based on the sites the domain controller covers, some are site-less. The limit is
usually reached for site-less names.

When you approach a lot of domain controllers in a domain, like 1200 domain
controllers, there may be issues updating the DNS objects for the names with the
additional values. In such a domain, it is also often not desired to have this many entries
for site-less names. To avoid this limit, you can create a registry value
"DnsAvoidRegisterRecords" on the domain controllers that should not be present in
site-less names.

DFS Volume management in version 1 namespaces

attribute PKT
DFS version 1 namespaces use a single AD object per namespace, and all the DFS link
information is kept in a single attribute "PKT". There are problems with managing the
namespace when this blob exceeds 5 MB (roughly 5000 links).

For more information, see How DFS Works.

In Windows Server 2008, DFS introduces version 2 namespaces where each DFS link is a
separate AD object.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory Replication Error 8451: "The
replication operation encountered a database
error"
Article • 04/09/2024

This article provides a resolution for Active Directory Replication Error 8451: "The replication operation encountered a
database error".

Applies to: All supported versions of Windows Server

Original KB number: 2645996

７ Note

Home users: This article is intended only for technical support agents and IT professionals. If you're looking for help
to resolve a problem, please ask the Microsoft Community .

Symptoms
This article describes the symptoms and causes of situations in which Active Directory Domain Services (AD DS) operations
fail and generate error 8451: "The replication operation encountered a database error." This article also provides a
resolution for this problem.
You might experience one of more of the following symptoms:

You see one or more on-screen error messages, logged events, or diagnostic output that identifies a database error.
Possible formats for that error include the following.

ﾉ Expand table

Decimal Hexadecimal Text code Error message

code code

8451 0x2103 ERROR_DS_DRA_DB_ERROR The replication operation encountered a database error.

-1018 0xfffffc06 JET_errReadVerifyFailure Checksum error on a database page.

-1047 0xfffffbe9 JET_errInvalidBufferSize Data buffer doesn't match column size.

-1075 0xfffffbc JET_errOutOfLongValueID Long-value ID counter has reached maximum value (do an
offline defragmentation to reclaim free and unused
LongValueIDs).

-1206 0xfffffb4a JET_errDatabaseCorrupted Non database file or corrupted db.

-1414 0xfffffa7a JET_errSecondaryIndexCorrupted Secondary index is corrupt. The database must be

defragmented.

-1526 0xfffffa0a JET_errLVCorrupted Corruption encountered in long-value tree.

-1601 0xfffff9bf JET_errRecordNotFound The key was not found.

-1603 0xfffff9b JET_errNoCurrentRecord Currency not on a record.

Dcpromo.exe fails and generates error 8451.

The user interface displays the following message:

The operation failed because:

 Active Directory Domain Services could not replicate the directory partition <DN path of failing partition> from
the remote Active Directory Domain Controller <helper DC>.<dns domain name>.<top level domain>.

The replication operation encountered a database error.

The Dcpromo.log file contains the following information:

<date> <time> [INFO] NstdInstall for contoso.com returned 8451

<date> <time> [INFO] DsRolepInstallDs returned 8451
<date> <time> [ERROR] Failed to install to Directory Service (8451)
<date> <time> [INFO] Starting service NETLOGON

Repadmin.exe reports that the replication attempt has failed with status 8451. Repadmin.exe commands that
commonly cite the 8451 status include but are not limited to:

Repadmin /kcc

Repadmin /rehost

Repadmin /replicate

Repadmin /replsum

Repadmin /showrepl

Repadmin /showreps

Repadmin /showutdvec

Repadmin /syncall

For detailed information about how to use Repadmin to troubleshoot replication problems, see Monitoring and
Troubleshooting Active Directory Replication Using Repadmin .

The following sample shows output from the repadmin /showreps command that indicates that inbound
replication from CONTOSO-DC2 to CONTOSO-DC1 failed and generated the "replication access was denied"
message.

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01
==== INBOUND NEIGHBORS ======================================
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 8451 (0x2103):
The replication operation encountered a database error.
consecutive failure(s).
Last success @ <date> <time>.

Event Viewer lists one or more events that cite the 8451 error. The following table lists the event sources and Event
IDs of common events that cite the 8451 error (in event source + event ID order).

ﾉ Expand table
Event source Event ID Event message

Microsoft-Windows- 1039 with Internal event: Active Directory Domain Services could not process the following object.
ActiveDirectory_DomainService extended
error
8451

Microsoft-Windows- 1084 with Internal event: Active Directory could not update the following object with changes received
ActiveDirectory_DomainService extended from the following source domain controller. It is because an error occurred during the
error application of the changes to Active Directory on the domain controller.
8451

Microsoft-Windows- 1308 with The Knowledge Consistency Checker (KCC) has detected that successive attempt to replicate
ActiveDirectory_DomainService extended with the following directory service failed.
error
8451

Microsoft-Windows- 1699 with The local domain controller failed to retrieve the changes requested for the following
ActiveDirectory_DomainService extended directory partition. As a result, it was unable to send the change requests to the domain
error controller at the following network address.
8451

NTDS Replication 2108 with This event contains REPAIR PROCEDURES for the 1084 event that has previously been
extended logged. This message indicates a specific issue with the consistency of the Active Directory
error database on this replication destination. A database error occurred while applying replicated
8451 with changes to the following object. The database had unexpected contents, preventing the
secondary change from being made. Object:
error CN= [email protected] ,OU=marketing,OU=5thWard,OU=Houston,DC=Contoso,DC=com
value- Object GUID: 2843919c-345c-4f57-bc1a-4ed5acbcf9e2 Source domain controller: 173ee10f-
1075 4c28-4acd-a2d7-61af8d4d3010._msdcs.Contoso.com User Action If none of these actions
succeed and the replication error continues, you should demote this domain controller and
promote it again. Additional Data Primary Error value: 8451 The replication operation
encountered a database error. Secondary Error value: -1075

NTDS Replication 2108 with This event contains REPAIR PROCEDURES for the 1084 event that has previously been
extended logged. This message indicates a specific issue with the consistency of the Active Directory
error database on this replication destination. A database error occurred while applying replicated
8451 with changes to the following object. The database had unexpected contents, preventing the
secondary change from being made. Object:
error CN= [email protected] ,OU=marketing,OU=5thWard,OU=Houston,DC=Contoso,DC=com
value- Object GUID: 2843919c-345c-4f57-bc1a-4ed5acbcf9e2 Source domain controller: 173ee10f-
1526 4c28-4acd-a2d7-61af8d4d3010._msdcs.Contoso.com User Action If none of these actions
succeed and the replication error continues, you should demote this domain controller and
promote it again. Additional Data Primary Error value: 8451 The replication operation
encountered a database error. Secondary Error value: -1526

NTDS Replication 2108 with This event contains REPAIR PROCEDURES for the 1084 event that has previously been
extended logged. This message indicates a specific issue with the consistency of the Active Directory
error database on this replication destination. A database error occurred while applying replicated
8451 with changes to the following object. The database had unexpected contents, preventing the
secondary change from being made. Object:
error CN= [email protected] ,OU=marketing,OU=5thWard,OU=Houston,DC=Contoso,DC=com
value Object GUID: 2843919c-345c-4f57-bc1a-4ed5acbcf9e2 Source domain controller: 173ee10f-
-1414 4c28-4acd-a2d7-61af8d4d3010._msdcs.Contoso.com User Action If none of these actions
succeed and the replication error continues, you should demote this domain controller and
promote it again. Additional Data Primary Error value: 8451 The replication operation
encountered a database error. Secondary Error value: -1414

NTDS General 1039 with Internal event: Active Directory could not process the following object.
extended
error
8451.

NTDS KCC 1925 with The attempt to establish a replication link for the following writable directory partition failed.
extended
error
8451
 Event source Event ID Event message

NTDS Replication 1084 with Internal event: Active Directory could not update the following object with changes received
extended from the following source domain controller. It is because an error occurred during the
error application of the changes to Active Directory on the domain controller.
8451

NTDS Replication 1699 with The local domain controller failed to retrieve the changes requested for the following
extended directory partition. As a result, it was unable to send the change requests to the domain
error controller at the following network address.
8451

When you increase the NTDS diagnosing logging level on the domain controller, Event Viewer lists additional events
that are related to the 8451 error. The following table lists the event sources and Event IDs of events that frequently
accompany other events that contain the 8451 error.

ﾉ Expand table

Event Event Event message

source ID

Internal 1481 Internal error: The operation on the object failed. Additional Data: Error value: 2 000020EF: NameErr:
Processing with DSID-032500E8, problem 2001 (NO_OBJECT), data -1601, best match of: "
error-
1601

Internal 1173 Internal event: Active Directory has encountered the following exception and associated parameters.
Processing with Exception: e0010004 Parameter: 0 Additional Data Error value: -1075 Internal ID: 205086d
error-
1075

Internal 1173 Internal event: Active Directory has encountered the following exception and associated parameters.
Processing with Exception: e0010004 Parameter: 0 Additional Data Error value: -1526 Internal ID: 205036b
error-
1526

Internal 1173 Internal event: Active Directory has encountered the following exception and associated parameters.
Processing with Exception: e0010004 Parameter: 0 Additional Data Error value: -1603 Internal ID: 2050344
error-
1603

NTDS ISAM 474 The database page read from the file 'E:\NTDS\Data\ntds.dit' at offset 3846455296 (0x00000000e5444000)
with for 8192 (0x00002000) bytes failed verification due to a page checksum mismatch. The expected
error- checksum was 323677604 (0x134aeda4) and the actual checksum was 2081515684 (0x7c1168a4). The read
1018 operation will fail with error -1018 (0xfffffc06). If this condition persists, restore the database from a
previous backup. This problem is likely due to faulty hardware. Contact your hardware vendor for further
assistance diagnosing the problem.

NTDS ISAM 488 NTDS (396) NTDSA: Data inconsistency detected in table datatable of database
C:\WINDOWS\NTDS\ntds.dit (4621,7905).

When you run the Dcdiag.exe utility, it produces output that resembles as:

Starting test: Replications

* Replications Check
[Replications Check,<DC Name>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <DN path of failing naming context>
The replication generated an error (8451):
The replication operation encountered a database error

In Active Directory Sites and Services, when you right-click the connection object of a source DC and select Replicate
now, the command fails and generates a message that resembles as:
 The following error occurred during the attempt to synchronize naming context <%directory partition name%>
from Domain Controller <Source DC> to Domain Controller <Destination DC>:
"The replication operation encountered a database error."
The operation will not continue.

How to decode error codes

You can use Microsoft Error Lookup Tool to decode the error codes that are described in this article. Decoding the error
codes that relate to the 8451 error and accompanying errors produces the following information:

C:>err 8451
for decimal 8451 / hex 0x2103 :
ERROR_DS_DRA_DB_ERROR winerror.h
The replication operation encountered a database error.
2 matches found for "8451"

C:>err -1414
for decimal -1414 / hex 0xfffffa7a :
JET_errSecondaryIndexCorrupted esent98.h
/Secondary index is corrupt. The database must be defragmented/
1 matches found for "-1414"

C:>err -1526
for decimal -1526 / hex 0xfffffa0a :
JET_errLVCorrupted esent98.h
/Corruption encountered in long-value tree/
1 matches found for "-1526"

C:>err -1603
for decimal -1603 / hex 0xfffff9bd :
JET_errNoCurrentRecord esent98.h
/Currency not on a record/
1 matches found for "-1603"

C:>err -1075
for decimal -1075 / hex 0xfffffbcd :
JET_errOutOfLongValueIDs esent98.h
/Long-value ID counter has reached maximum value. (perform offline defrag to reclaim free/unused
LongValueIDs)/
1 matches found for "-1075"

C:>err -1601
for decimal -1601 / hex 0xfffff9bf :
JET_errRecordNotFound esent98.h
/The key was not found/
1 matches found for "-1601"

C:>err -1047
for decimal -1047 / hex 0xfffffbe9 :
JET_errInvalidBufferSize esent98.h
/Data buffer doesn't match column size/
1 matches found for "-1047"

C:>err -1018
for decimal -1018 / hex 0xfffffc06 :
JET_errReadVerifyFailure ese.h
/Checksum error on a database page/
 JET_errReadVerifyFailure esent98.h
/* Checksum error on a database page */
2 matches found for "-1018"

C:>err -1206
for decimal -1206 / hex 0xfffffb4a :
JET_errDatabaseCorrupted esent98.h
/Non database file or corrupted db/
1 matches found for "-1206"

Cause
The status 8451: "The replication operation encountered a database error" has multiple root causes, including the
following ones:

The Active Directory database or Active Directory database index might be corrupted. It may be caused by the
following reasons:
Failing hardware:
Disk
Controller
Controller cache
Outdated drivers:
Controller
Outdated firmware:
Computer BIOS
Controller
Disk
Sudden power loss.
Lingering objects.
The long-value ID counter has reached its maximum value:
The ESE column types JET_coltypLongText and JET_coltypLongBinary are called long value column types. These
columns are large string and large binary objects that may be stored in separate B+ trees away from the
primary index. When long values are stored separately from the primary record, they are internally keyed on a
long value ID (LID).
Invalid security descriptor in the msExchSecurityDescriptor attribute.

Resolution
） Important

Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before
you modify it, back up the registry for restoration in case problems occur.

How to resolve a single occurrence of the problem

If the error occurs on only one domain controller and appears to be an isolated problem, the best and quickest resolution
is to do offline defragmentation of the database on the affected server. For information about how to do it, see How to
perform offline defragmentation of the Active Directory database .

If offline defragmentation does not correct the issue, demote and then repromote the affected domain controller. For
information about how to do it, see Demoting Domain Controllers and Domains.

How to resolve a recurring problem

If the problem recurs, collect some diagnostic data.

1. Enable NTDS diagnostic logging for Replication Events and Internal Processing at a level of 5.

To increase NTDS diagnostic logging, change the following REG_DWORD values in the registry of the destination
domain controller under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Set the value of the following entries to 5:

Replication Events
Internal Processing

７ Note

Level-5 logging is extremely verbose. The values of both keys should be restored to the default of 0 after the
problem is resolved. Filtering the Directory Services event log should be done to isolate and identify these
events.

For more information about the standard terminology that is used to describe Microsoft software updates, see the
following Knowledge Base article:

2. Review the event logs for the new events that were generated from the increased logging for error values that will
give a definitive view of the original 8451 error. For example, an Internal Processing Event ID 1173 that has an error
value of -1526 would indicate that we have a corruption in long-value tree.

3. Based on the additional information from the increased logging, refer to the following table for a potential resolution.

ﾉ Expand table

Decimal Hex Text code Error message Potential resolutions

code code

-1018 0xfffffc06 JET_errReadVerifyFailure Checksum error on a Check hardware, firmware, and drivers.
database page Restore from backup.Demote/promote.

-1047 0xfffffbe9 JET_errInvalidBufferSize Data buffer doesn't match 832851 Inbound Replication Fails on
column size Domain Controllers with Event ID: 1699,
Error 8451 or jet error -1601 Note: This
hotfix is no longer available.

-1075 0xfffffbcd JET_errOutOfLongValueIDs Long-value ID counter has Do offline defragmentation.

reached maximum value.
(do offline defragmentation
to reclaim free or
unused LongValueIDs )

-1206 0xfffffb4a JET_errDatabaseCorrupted Non-database file or Check hardware, firmware, and

corrupted db drivers.Run the Esentutl/k command.
Run the Ntdsutil file integrity and
semantic database analysis (SDA)
commands, and then do offline
defragmentation.Otherwise restore from
backup or demote/promote.

-1414 0xfffffa7a JET_errSecondaryIndexCorrupted Secondary index is corrupt. Do offline defragmentation.

The database must be
defragmented.

-1526 0xfffffa0a JET_errLVCorrupted Corruption encountered in Check hardware, firmware, and

long-value tree drivers.Run the Esentutl /k command.
Run the Ntdsutil** file integrity and SDA
commands, and then do offline
 Decimal Hex Text code Error message Potential resolutions
code code

defragmentation. Otherwise, restore

from backup or demote and promote.

-1601 0xfffff9bf JET_errRecordNotFound The key was not found Check hardware, firmware, and
drivers.Run the Esentutl /k command.
Run the Ntdsutil file integrity and SDA
commands, and then do offline
defragmentation​​.​Otherwise restore from
backup or demote and promote.

-1603 0xfffff9bd JET_errNoCurrentRecord Currency not on a record Check hardware, firmware, and
drivers.Run the Esentutl / k command.
Run the Ntdsutil file integrity and SDA
commands, and then do offline
defragmentation​​.​Otherwise restore from
backup or demote and promote.

8451 0x2103 ERROR_DS_DRA_DB_ERROR The replication operation Check hardware, firmware, and
encountered a database drivers.Run the Esentutl /k command.
error Run the Ntdsutil file integrity and SDA
commands, and then do offline
defragmentation. Otherwise restore from
backup or demote/promote.

4. If all these methods fail, restore the domain controller from a backup, or demote it and then repromote.

More information
Verify the vertical jet database stack from the bottom up (proceeding up to the next layer only after the underlying layer is
graded as "good"), the same as you do for TCP.

ﾉ Expand table

Layer Ntdsutil command Esentutl command

(1) Physical consistency no equivalent Esentutl /k

(2) Extensible Storage Engine (ESE) logical Ntdsutil, files, integrity Esentutl /g
consistency

(3) Application logical consistency Ntdsutil, semantic database analysis + Ntdsutil, no equivalent for SDA +
compact Esentutl /d

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following the steps
mentioned in Gather information by using TSS for Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication Event ID
1925: attempt to establish a replication
link failed due to DNS lookup problem
Article • 02/19/2024

This article helps to resolve the issue where you get Event ID 1925 with the error
message that DNS lookup failed, inbound replication of a directory partition has failed
on the destination domain controller.

Applies to: Windows Server 2012 R2

Original KB number: 4469659

This problem typically occurs when an attempt to establish a replication link fails as a
result of a Domain Name System (DNS) lookup problem. If you receive Event ID 1925
with the error message that DNS lookup failed, inbound replication of a directory
partition has failed on the destination domain controller, and you must fix the DNS
problem.

The following is an example of the event text:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 3/12/2008 8:14:13 AM
Event ID: 1925
Task Category: Knowledge Consistency Checker
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: DC3.contoso.com
Description:
The attempt to establish a replication link for the following writable directory
partition failed.

Directory partition:
CN=Configuration,DC=contoso,DC=com
Source directory service: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-
Site-Name, CN=Sites,CN=Configuration,DC=contoso,DC=com
Source domain controller address:
f8786828-ecf5-4b7d-ad12-8ab60178f7cd._msdcs.contoso.com
 Intersite transport (if any): CN=IP,CN=Inter-Site Transports,
CN=Sites,CN=Configuration,DC=constoso,DC=com

This domain controller will be unable to replicate with the source domain controller
until this problem is corrected.

User Action
Verify if the source domain controller is accessible or network connectivity is
available.

Additional Data
Error value:
8524 The DSA operation is unable to proceed because of a DNS lookup failure.

Resolution
Proceed with DNS testing as described in "Active Directory Replication Event ID 2087:
DNS lookup failure caused replication to fail ."

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication Event ID
2042: It has been too long since this
machine replicated
Article • 02/19/2024

This article helps you troubleshoot Active Directory replication Event ID 2042.

Applies to: Windows Server 2012 R2

Original KB number: 4469622

Symptoms
If a domain controller has not replicated with its partner for longer than a tombstone
lifetime, it is possible that a lingering object problem exists on one or both domain
controllers. The tombstone lifetime in an Active Directory forest determines how long a
deleted object (called a "tombstone") is retained in Active Directory Domain Services
(AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime
attribute on the Directory Service object in the configuration directory partition.

When the condition that causes Event ID 2042 to be logged occurs, inbound replication
with the source partner is stopped on the destination domain controller and Event ID
2042 is logged in the Directory Service event log. The event identifies the source domain
controller and the appropriate steps to take to either remove the outdated domain
controller or remove lingering objects and restore replication from the source domain
controller.

The following is an example of the event text:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <Time>
Event ID: 2042
Task Category: Replication
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <domain controller hostname>
Description:
It has been too long since this machine last replicated with the named source
 machine. The time between replications with this source has exceeded the
tombstone lifetime. Replication has been stopped with this source.
The reason that replication is not allowed to continue is that the two machine's
views of deleted objects may now be different. The source machine may still have
copies of objects that have been deleted (and garbage collected) on this machine. If
they were allowed to replicate, the source machine might return objects which have
already been deleted.
Time of last successful replication:
<date> <time>
Invocation ID of source:
<Invocation ID>
Name of source:
<GUID>._msdcs.<domain>
Tombstone lifetime (days): <TSL number in days>

The replication operation has failed.

User Action:

Determine which of the two machines was disconnected from the forest and is now
out of date. You have three options:

1. Demote or reinstall the machine(s) that were disconnected.

2. Use the "repadmin /removelingeringobjects" tool to remove inconsistent
deleted objects and then resume replication.
3. Resume replication. Inconsistent deleted objects may be introduced.

You can continue replication by using the following registry key.

Once the systems replicate once, it is recommended that you remove the key to
reinstate the protection.
Registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Allow

Replication With Divergent and Corrupt Partner

The repadmin /showrepl command also reports error 8416, as shown in the following
example:

Source: Default-First-Site-Name\DC1
******* <number> CONSECUTIVE FAILURES since <date> <time>
Last error: 8614 (0x21a6):
The Active Directory Domain Services cannot replicate with this server because the
time since the last replication with this server has exceeded the tombstone lifetime.
Cause
There are a few potential causes for the logging of Event ID 2042, which include the
following:

Windows Server 2003 pre-Service Pack 1 (SP1) domain controllers having a

software issue that causes replication failures.
Replication failures that have existed longer than the configured tombstone
lifetime value.
System time advance or rollback that causes objects to be deleted on some-but
not all-domain controllers.

Resolution
The resolution of this issue depends on the actual cause or causes of the issue. To
resolve this issue, check for each of the following conditions:

1. Determine whether there are any Windows Server 2003 domain controllers that do
not have at least SP1 applied. If you find any such domain controllers, ensure that
you update them to at least SP1 to resolve this issue.

2. Determine whether there are any replication failures that have been allowed to
exceed the tombstone lifetime of the forest. Typically, the tombstone lifetime of
the forest is 60 to 180 days by default. The event message indicates the tombstone
lifetime of the forest as it is currently configured.

Run the command repadmin /showrepl to determine whether a replication issue

exists. If you suspect that there is a replication issue, see Monitoring and
Troubleshooting Active Directory Replication Using Repadmin for information
about how to resolve the issue.

3. Determine whether there are lingering objects. You can do this by running the
command repadmin /removelingeringobjects in advisory mode, as described in the
following procedure.

You must first identify an authoritative domain controller. If you know that a specific
domain controller has the latest changes, you can use that domain controller as the
authoritative domain controller. Otherwise, you may have to complete the following
procedure on multiple domain controllers until you identify a domain controller that you
believe has the latest changes. Then, you can use that domain controller as your
authoritative domain controller.
Membership in Domain Admins, or equivalent, is the minimum required to complete
this procedure. Review details about default group memberships at Active Directory
Local and Domain Default Groups.

Identify lingering objects

1. On a domain controller that you expect to have the latest changes, open an
elevated Command Prompt window. To open an elevated Command Prompt
window, click Start, point to All Programs, click Accessories, right-click Command
Prompt, and then click Run as administrator.

2. Run the following repadmin command in advisory mode. This makes it possible for
you to assess the lingering objects without actually removing anything.

Console

repadmin /removelingeringobjects <DestDCName> <SourceDCGUID>

<LDAPPartition> /advisory_mode

Substitute the following items for the placeholders in the command syntax:

DestDCName: The host name of the domain controller that you are targeting
for lingering object clean-up. For example, if you want to remove lingering
objects from DC1 in the contoso.com domain, substitute dc1.contoso.com for
<DestDCName>.

SourceDCGUID: Run the following command:

Console

repadmin /showrepl AuthDCname |more

where AuthDCname is the host name of the domain controller that you
selected as authoritative. Substitute the first DSA object GUID that appears
for <SourceDCGUID>.

LDAPPartition: The Lightweight Directory Access Partition (LDAP) name of the

partition that you are targeting. For example, if the lingering objects are in
the domain partition of the contoso.com domain, substitute
dc=contoso,dc=com for <LDAPPartition>.

The following is an example command for identifying lingering objects:

 Console

repadmin /removelingeringobjects dc1.contoso.com 4a8717eb-8e58-456c-995a-

c92e4add7e8e dc=contoso,dc=com /advisory_mode

If necessary, repeat the previous steps on additional domain controllers until you
determine the domain controller that you believe has the latest changes. Use that
domain controller as your authoritative domain controller. Run the repadmin
/removelingeringobjects command without the /advisory_mode switch to actually

remove lingering objects. Repeat the command as necessary to remove lingering

objects from each domain controller that has them.

Restart replication following Event ID 2042

The normal state of replication is one in which changes to objects and their attributes
converge in a way that domain controllers receive the latest information. When a
partner domain controller is discovered to be passing older changes, the changes from
the partner are deemed to be "divergent." The partner is said to be engaged in
"divergent replication." Domain controllers will normally stop replicating with any
partner that is deemed to be engaged in divergent replication.

After you remove all lingering objects, you can restart replication on the domain
controller that logged the event by editing the registry.

７ Note

Restart replication only after you have removed all lingering objects. Incorrectly
editing the registry might severely damage your system. Before making changes to
the registry, you should back up any valued data on the computer.

Membership in Domain Admins, or equivalent, is the minimum required to complete

this procedure. Review details about default group memberships at Active Directory
Local and Domain Default Groups.

Use Repadmin to restart replication following

Event ID 2042
1. Open an elevated Command Prompt. To open an elevated Command Prompt
window, click Start, point to All Programs, click Accessories, right-click Command
Prompt, and then click Run as administrator.
 2. At the command prompt, type the following command, and then press ENTER:

Console

repadmin /regkey <hostname> +allowDivergent

ﾉ Expand table

Parameter Description

/regkey Enables (+) and disables (-) the value for the Strict Replication
Consistency registry entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

<hostname> Substitute the name of a single domain controller, or use an asterisk

character (*) to apply the change to all domain controllers in the forest.
For the domain controller name, you can use the Domain Name System
(DNS) name, the distinguished name of the domain controller computer
object, or the distinguished name of the domain controller server object.

+allowDivergent Enables replication to start again with the replication partner that had
lingering objects. You should run this command only after all the
lingering objects have been removed. After replication is running
properly again, use the -allowDivergent switch to prevent divergent
replication from occurring.

７ Note

If you did not use an asterisk character (*) to apply the change to all domain
controllers, repeat step 2 for every domain controller on which you want to allow
divergent replication.

Reset the registry to protect against outdated

replication
When you are satisfied that lingering objects have been removed and replication has
occurred successfully from the source domain controller, use Repadmin to prevent
divergent replication. To do prevent divergent replication, run the following command:

Console

repadmin /regkey <hostname> -allowDivergent

For example, to restrict divergent replication on a domain controller named DC1 in the
contoso.com domain, run the following command:

Console

repadmin /regkey dc1.contoso.com -allowDivergent

７ Note

If you did not remove all the lingering objects, attempting replication might result
in replication of a lingering object. If strict replication consistency is enabled on the
destination domain controller, replication with the source domain controller will be
blocked again.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication Event ID
2087: DNS lookup failure caused
replication to fail
Article • 02/19/2024

This article provides a solution to the Active Directory replication Event ID 2087 that
occurs when a Domain Name System (DNS) lookup failure causes replication to fail.

Applies to: Windows Server 2012 R2

Original KB number: 4469661

Symptoms
This problem typically occurs when a Domain Name System (DNS) lookup failure causes
replication to fail. When a destination domain controller receives Event ID 2087 in the
Directory Service event log, attempts to resolve the globally unique identifier (GUID) in
the alias (CNAME) resource record, the fully qualified domain name (FQDN), and the
NetBIOS name to the IP address of the source domain controller have all failed. Failure
to locate the source replication partner prevents replication with that source until the
problem is fixed.

The following is an example of the event text:

Log Name: Directory

Service Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 3/9/2008 11:00:21 AM
Event ID: 2087
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: DC3.contoso.com
Description: Active Directory could not resolve the following DNS host name of the
source domain controller to an IP address. This error prevents additions, deletions
and changes in Active Directory Domain Services from replicating between one or
more domain controllers in the forest. Security groups, group policy, users and
computers and their passwords will be inconsistent between domain controllers
until this error is resolved, potentially affecting logon authentication and access to
network resources.
 Source domain controller: DC2
Failing DNS host name:
b0069e56-b19c-438a-8a1f-64866374dd6e._msdcs.contoso.com
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour
period, even if more than 10 failures occur. To log all individual failure events, set
the following diagnostics registry value to 1:

Registry Path: HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC

Client

User Action:

1. If the source domain controller is no longer functioning or its operating system

has been reinstalled with a different computer name or NTDSDSA object GUID,
remove the source domain controller's metadata with ntdsutil.exe, using the
steps outlined in MSKB article 216498.

2. Confirm that the source domain controller is running Active Directory Domain
Services and is accessible on the network by typing "net view \\<source DC
name>" or "ping <source DC name>".

3. Verify that the source domain controller is using a valid DNS server for DNS
services, and that the source domain controller's host record and CNAME
record are correctly registered, using the DNS Enhanced version of
DCDIAG.EXE available on http://www.microsoft.com/dns
dcdiag /test:dns

4. Verify that this destination domain controller is using a valid DNS server for
DNS services, by running the DNS Enhanced version of DCDIAG.EXE command
on the console of the destination domain controller, as follows:
dcdiag /test:dns

5. For further analysis of DNS error failures see KB 824449:

http://support.microsoft.com/?kbid=824449

Additional Data
Error value: 11004
The requested name is valid, but no data of the requested type was found.

Diagnosis
Failure to resolve the current alias (CNAME) resource record of the source domain
controller to an IP address can have the following causes:
 The source domain controller is powered off, is offline, or resides on an isolated
network, and Active Directory and DNS data for the offline domain controller has
not been deleted to indicate that the domain controller is inaccessible.

One of the following conditions exists:

The source domain controller has not registered its resource records in DNS.
The destination domain controller is configured to use an invalid DNS server.
The source domain controller is configured to use an invalid DNS server.
The DNS server that the source domain controller uses does not host the
correct zones, or the zones are not configured to accept dynamic updates.
The direct DNS servers that the destination domain controller queries cannot
resolve the IP address of the source domain controller as a result of nonexistent
or invalid forwarders or delegations.

Active Directory Domain Services (AD DS) has been removed on the source
domain controller and then reinstalled with the same IP address, but knowledge of
the new NTDS Settings GUID has not reached the destination domain controller.

AD DS has been removed on the source domain controller and then reinstalled
with a different IP address, but the current host address (A) resource record for the
IP address of the source domain controller is either not registered or does not exist
on the DNS servers that the destination domain controller queries as a result of
replication latency or replication error.

The operating system of the source domain controller has been reinstalled with a
different computer name, but its metadata either has not been removed or has
been removed and not yet inbound-replicated by the destination domain
controller.

Resolution
First, Determine whether a domain controller is functioning. If the source domain
controller is not functioning, remove its remaining metadata from AD DS.

If the source domain controller is functioning, continue with procedures to diagnose

and solve the DNS problem, as necessary:

Use Dcdiag to diagnose DNS problems.

Register DNS service (SRV) resource records plus host records.
Synchronize replication between the source and destination domain controllers.
Verify consistency of the NTDS Settings GUID.
Determine whether a domain controller is functioning
To determine whether the source domain controller is functioning, use the following
test.

Requirements:

Membership in the Domain Users group in the domain of the domain controller,
or equivalent, is the minimum required to complete this procedure. Review details
about using the appropriate accounts and group memberships at Local and
Domain Default Groups.

Tool: Net view

To confirm that the domain controller is running AD DS and is accessible on the

network, at a command prompt type the following command, and then press ENTER:

Console

net view \\<SourceDomainControllerName>

Where <SourceDomainControllerName> is the NetBIOS name of the domain controller.

This command displays the Netlogon and SYSVOL shares, indicating that the server is
functioning as a domain controller. If this test shows that the domain controller is not
functioning on the network, determine the nature of the disconnection and whether the
domain controller can be recovered or whether its metadata must be removed from AD
DS manually. If the domain controller is not functioning and cannot be restored, use the
procedure in the following section, Clean up domain controller metadata, to delete the
data that is associated with that server from AD DS.

Clean up domain controller metadata

If tests show that the domain controller is no longer functioning but you still see objects
representing the domain controller in the Active Directory Sites and Services snap-in,
replication will continue to be attempted, and you must remove these objects from AD
DS manually. You must use the Ntdsutil tool to clean up (delete) the metadata for the
defunct domain controller.

If the defunct domain controller is the last domain controller in the domain, you should
also remove the metadata for the domain. Allow sufficient time for all global catalog
servers in the forest to inbound-replicate the domain deletion before you promote a
new domain with the same name.
The process for cleaning up metadata is improved in the version of Ntdsutil that is
included with Windows Server 2003 Service Pack 1 (SP1). Instructions for cleaning up
metadata with the Windows Server 2003 version of Ntdsutil and the Windows Server
2003 SP1 version of Ntdsutil are provided in the following procedure.

Requirements:

Membership in Enterprise Admins, or equivalent, is the minimum required to

complete this procedure. Review details about using the appropriate accounts and
group memberships at Local and Domain Default Groups.
Tool: Ntdsutil (System32 command-line tool)

Steps to clean up server metadata

1. Open a Command Prompt.

2. At the Command Prompt, type the ntdsutil command, and then press ENTER.

3. At the ntdsutil command prompt, type the metadata cleanup command, and then
press ENTER.

4. Perform metadata cleanup as follows:

７ Note

If you are removing domain metadata as well as server metadata, skip the
following procedure and use the procedure that begins at step 1.

If you are performing server metadata cleanup only and you are using the
version of Ntdsutil.exe that is included with Windows Server 2003 SP1, at the
metadata cleanup: command prompt, type the following command, and then

press ENTER:

Console

remove selected server <ServerName>

Or

Console

remove selected server <ServerName1> on <ServerName2>

 ﾉ Expand table

Parameter Description

<ServerName>, The distinguished name of the domain controller whose

<ServerName1> metadata you want to remove, in the form cn=
<ServerName>,cn=Servers,cn=<SiteName>,
cn=Sites,cn=Configuration,dc=<ForestRootDomain>

<ServerName2> The DNS name of the domain controller to which you want to
connect and from which you want to remove server metadata.

If you are performing metadata cleanup by using the version of Ntdsutil.exe

that is included with Windows Server 2003 with no service pack, or if you are
performing both domain metadata cleanup and server metadata cleanup,
perform metadata cleanup as follows:
a. At the metadata cleanup: prompt, type the connection command, and
then press ENTER.
b. At the server connections: prompt, type the connect to server <Server>
command, and then press ENTER.
c. At the connection: prompt, type the quit command, and then press
ENTER.
d. At the metadata cleanup: prompt, type the select operation target
command, and then press ENTER.
e. At the select operation target: prompt, type the list sites command,
and then press ENTER.
f. A numbered list of sites appears. Type the select site <SiteNumber>
command, and then press ENTER.
g. At the select operation target: prompt, type the list domains in site
command, and then press ENTER.
h. A numbered list of domains in the selected site appears. Type the select
domain <DomainNumber> command, and then press ENTER.

i. At the select operation target: prompt, type the list servers in site
command, and then press ENTER.
j. A numbered list of servers in a domain and site is displayed. Type the
select server <ServerNumber> command, and then press ENTER.

k. At the select operation target: prompt, type the quit command, and
then press ENTER.
l. At the metadata cleanup: prompt, type the remove selected server
command, and then press ENTER.
m. If the server whose metadata you have removed is the last domain
controller in the domain and you want to remove the domain metadata, at
 the metadata cleanup: prompt, type the remove selected domain
command, and then press ENTER. Metadata for the domain that you
selected in step h is removed.
n. At the metadata cleanup: and ntdsutil: prompts, type quit , and then
press ENTER.

ﾉ Expand table

Parameter Description

<Server> The DNS name of a domain controller that you want to connect
to.

<SiteNumber> The number that is associated with the site of the server that
you want to clean up, which appears in the list.

<DomainNumber> The number that is associated with the domain of the server
that you want to clean up, which appears in the list.

<ServerNumber> The number that is associated with the server that you want to
clean up, which appears in the list.

Use Dcdiag to diagnose DNS problems

If the domain controller is functioning online, continue by using the Dcdiag tool to
diagnose and fix DNS problems that might be interfering with Active Directory
replication.

Use the following procedures to complete this process:

Verify connectivity and basic DNS functionality.

Verify registration of the alias (CNAME) resource record in DNS.
Verify dynamic updates and enable secure dynamic updates.

Before you begin these procedures, gather the following information, which is contained
in the Event ID 2087 message text:

The FQDN of the source domain controller and destination domain controller
The IP address of the source domain controller

The updated version of Dcdiag that is included in Windows Support Tools in Windows
Server 2003 SP1 contains tests that provide consolidated and improved testing of basic
and advanced DNS features. You can use this tool to diagnose basic DNS functionality
and dynamic updates.
When you use the enhanced SP1 version of Dcdiag for DNS testing, there are specific
requirements that do not apply to all Dcdiag tests.

Requirements:

Membership in Enterprise Admins, or equivalent, is the minimum required to

complete the new DNS tests that are available in the SP1 version of Dcdiag. Review
details about using the appropriate accounts and group memberships at Local and
Domain Default Groups.
Tool: Dcdiag.exe
Operating system:

You can run the enhanced version of Dcdiag on computers running the
following operating systems:
Windows XP Professional
Windows Server 2003
Windows Server 2003 with SP1

You can run the new Dcdiag DNS tests against Microsoft DNS servers that are
installed on domain controllers running the following operating systems:
Windows 2000 Server with Service Pack 3 (SP3)
Windows 2000 Server with Service Pack 4 (SP4)
Windows Server 2003
Windows Server 2003 with SP1

７ Note

You can use the /f: switch in Dcdiag commands to save the output to a text file.
Use /f: FileName to generate the file in the location that is indicated in FileName,
for example, /f:c:\Test\DnsTest.txt .

Verify basic DNS functionality

To verify the settings that might interfere with Active Directory replication, you can
begin by running the basic DNS test that ensures that DNS is operating properly on the
domain controller.

The basic DNS test checks the following:

Connectivity: The test determines whether domain controllers are registered in

DNS, can be contacted by PING, and have Lightweight Directory Access
Protocol/remote procedure call (LDAP/RPC) connectivity. If the connectivity test
 fails on a domain controller, no other tests are run against that domain controller.
The connectivity test is performed automatically before any other DNS test is run.

Essential services: The test confirms that the following services are running and
available on the tested domain controller:
DNS Client service
Net Logon service
Key Distribution Center (KDC) service
DNS Server service (if DNS is installed on the domain controller)

DNS client configuration: The test confirms that DNS servers on all adapters are
reachable.

Resource record registrations: The test confirms that the host (A) resource record
of each domain controller is registered on at least one of the DNS servers that is
configured on the client.

Zone and start of authority (SOA): If the domain controller is running the DNS
Server service, the test confirms that the Active Directory domain zone and start of
authority (SOA) resource record for the Active Directory domain zone are present.

Root zone: Checks whether the root (.) zone is present.

Steps to verify basic DNS functionality

1. At a command prompt, type the following command, and then press ENTER:

Console

dcdiag /test:dns /s:<SourceDomainControllerName> /DnsBasic

Where <SourceDomainControllerName> is the distinguished name, NetBIOS

name, or DNS name of the domain controller.

As an alternative, you can test all domain controllers in the forest by typing /e:
instead of /s: .

2. Copy the report into Notepad or an equivalent text editor.

3. Scroll to the Summary table near the bottom of the Dcdiag log file.

4. Note the names of all domain controllers that report "Warn" or "Fail" status in the
Summary table.
 5. Find the detailed breakout section for the problem domain controller by searching
for the string "DC: <DomainControllerName>".

6. Make the required configuration changes on DNS clients and DNS servers.

7. To validate the configuration changes, rerun Dcdiag /test:DNS with the /e: or /s:
switch.

If the basic DNS test shows no errors, continue by verifying that resource records that
are used to locate domain controllers are registered in DNS.

Verify resource record registration

The destination domain controller uses the DNS alias (CNAME) resource record to locate
its source domain controller replication partner. Although domain controllers running
Windows Server 2003 with SP1 can locate source replication partners by using FQDNs-
or, if that fails, NetBIOS names-the presence of the alias (CNAME) resource record is
expected and should be verified for proper DNS functioning.

You can use Dcdiag to verify registration of all resource records that are essential for
domain controller location by using the dcdiag /test:dns /DnsRecordRegistration test.
This test verifies registration of the following resource records in DNS:

The alias (CNAME) (the GUID-based resource record that locates a replication
partner)
The host (A) (the host resource record that contains the IP address of the domain
controller)
LDAP SRV (the service (SRV) resource records that locate LDAP servers)
GC SRV (the service (SRV) resource records that locate global catalog servers)
PDC SRV (the service (SRV) resource records that locate primary domain controller
(PDC) emulator operations masters)

As an alternative, you can use the following procedure to check for only the alias
(CNAME) resource record.

Steps to verify alias (CNAME) resource record registration

1. In the DNS snap-in, locate any domain controller that is running the DNS Server
service, where the server hosts the DNS zone with the same name as the Active
Directory domain of the domain controller.

2. In the console tree, click the zone that is named _msdcs.Dns_Domain_Name.

 ７ Note

In Windows 2000 Server DNS, _msdcs.Dns_Domain_Name is a subdomain of

the DNS zone for the Active Directory domain name. In Windows Server 2003
DNS, _msdcs.Dns_Domain_Name is a separate zone.

3. In the details pane, verify that the following resource records are present:

An alias (CNAME) resource record that is named

Dsa_Guid._msdcs.Dns_Domain_Name
A corresponding host (A) resource record for the name of the DNS server

If the alias (CNAME) resource record is not registered, verify that dynamic updates are
functioning properly. Use the test in the following section.

Verify dynamic updates

If the basic DNS test shows that resource records do not exist in DNS, use the dynamic
update test to diagnose why the Net Logon service did not register the resource records
automatically. To verify that the Active Directory domain zone is configured to accept
secure dynamic updates and to perform registration of a test record
(_dcdiag_test_record), use the following procedure. The test record is deleted
automatically after the test.

To verify dynamic updates, at a command prompt, type the following command, and
then press ENTER:

Console

dcdiag /test:dns /s:<SourceDomainControllerName> /DnsDynamicUpdate

Where <SourceDomainControllerName> is the distinguished name, NetBIOS name, or

DNS name of the domain controller.

As an alternative, you can test all domain controllers by using the /e: switch instead of
the /s: switch.

If secure dynamic update is not configured, use the following procedure to configure it.

Enable secure dynamic updates

1. Open the DNS snap-in.

 2. In the console tree, right-click the applicable zone, and then click Properties.
3. On the General tab, verify that the zone type is Active Directory-integrated.
4. In Dynamic Updates, click Secure only.

Register DNS resource records

If DNS resource records do not appear in DNS for the source domain controller, you
have verified dynamic updates, and you want to register DNS resource records
immediately, you can force the registration manually by using the following procedure.
The Net Logon service on a domain controller registers the DNS resource records that
are required for the domain controller to be located on the network. The DNS Client
service registers the host (A) resource record that the alias (CNAME) record points to.

Requirements:

Membership in the Domain Admins group in the forest root domain or the
Enterprise Admins group, or equivalent, is the minimum required to complete this
procedure.
Tools: net stop / net start , ipconfig

Register DNS resource records manually

To initiate registration of domain controller Locator resource records manually on the

source domain controller, at a command prompt type the following commands, and
then press ENTER after each command:

Console

net stop net logon

net start net logon

To initiate registration of the host A resource record manually, at a command prompt

type the following command, and then press ENTER:

Console

ipconfig /flushdns
ipconfig /registerdns

Wait 15 minutes, and then review events in Event Viewer to ensure proper registration of
the resource records.
Repeat the procedure in the Verify resource record registration section earlier in this
section to verify that the resource records appear in DNS.

Synchronize replication between the source and

destination domain controllers
After you complete DNS testing, use the following procedure to synchronize replication
on the inbound connection from the source domain controller to the destination
domain controller.

Requirements:

Membership in the Domain Admins group in the domain of the destination

domain controller, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.
Tool: Active Directory Sites and Services

Steps to synchronize replication from a source domain controller

1. Open Active Directory Sites and Services.

2. In the console tree, double-click the Sites container, double-click the site of the
domain controller to which you want to synchronize replication, double-click the
Servers container, double-click the server object of the domain controller, and
then click NTDS Settings.
3. In the details pane, in the From Server column, locate the connection object that
shows the name of the source domain controller.
4. Right-click the appropriate connection object, and then click Replicate Now.
5. Click OK.

If replication does not succeed, use the procedure in the following section to verify
consistency of the NTDS Settings GUID.

Verify consistency of the NTDS Settings GUID

If you have performed all DNS tests and other tests and replication does not succeed,
use the following procedure to verify that the GUID of the NTDS Settings object that the
destination domain controller is using to locate its replication partner matches the GUID
that is currently in effect on the source domain controller itself. To perform this test, you
view the object GUID as it appears in the local directories of each domain controller.

Requirements:
 Membership in the Domain Admins group in the domain of the destination
domain controller, or equivalent, is the minimum required to complete this
procedure.
Tool: Ldp.exe (Windows Support Tools)

Steps to verify consistency of the NTDS Settings GUID

1. Click Start, click Run, type Ldp, and then click OK.
2. On the Connection menu, click Connect.
3. In the Connect dialog box, leave the Server box empty.
4. In Port, type 389, and then click OK.
5. On the Connection menu, click Bind.
6. In the Bind dialog box, provide Enterprise Admins credentials. If it is not already
selected, click Domain.
7. In Domain, type the name of the forest root domain, and then click OK.
8. On the View menu, click Tree.
9. In the Tree View dialog box, type CN=Configuration,DC=Forest_Root_Domain and
then click OK.
10. Navigate to the object CN=NTDS
Settings,CN=SourceServerName,CN=Servers,CN=SiteName,
CN=Sites,CN=configuration,DC=ForestRootDomain.
11. Double-click the NTDS Settings object. In the details pane, view the value for the
attribute objectGUID. Right-click that value, and then copy it to Notepad.
12. On the Connection menu, click Disconnect.
13. Repeat steps 2 through 11, but in step 3, type the name of the source domain
controller, for example, DC03.
14. In Notepad, compare the values of the two GUIDs.
15. If the values do not match, the destination domain controller must receive
replication of the valid GUID. Check the GUID value on other domain controllers
and attempt replication on the destination domain controller with a different
domain controller that has the correct GUID.
16. If the values match, verify that the GUID matches the GUID in the
Dsa_Guid._msdcs.Dns_Domain_Nameresource record for the source domain
controller, as follows:
a. Note the primary DNS servers that each domain controller identifies in the
TCP/IP properties in their Network Settings. All the DNS servers that are listed in
the respective TCP/IP properties should be able to indirectly or directly resolve
this alias (CNAME) resource record.
b. From the servers that are listed, identify the authoritative name server or servers
for this domain zone by looking at the server names that are listed for the name
 server (NS) resource records at the root of the zone. (In the DNS snap-in, select
the forward lookup zone for the root domain, and then view the name server
(NS) records in the details pane.)
c. On the name server or servers obtained in step b, open the DNS snap-in, and
double-click the forward lookup zone for the forest root domain name. Double-
click the _msdcs folder, and note the alias (CNAME) resource records that exist
for your server name.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication event IDs
2108 and 1084 occur during inbound
replication of Active Directory Domain
Services
Article • 02/19/2024

This article provides a solution to an issue where you get event IDs 2108 and 1084 when
inbound replication of the Active Directory Domain Services (AD DS) occurs.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 837932

Symptoms
When inbound replication of the Active Directory Domain Services (AD DS) occurs, a
destination domain controller that is running Microsoft Windows Server 2003 Service
Pack 1 (SP1) through Windows Server 2016 logs the following event in the Directory
Service log:

Event ID 1084: Internal event: Active Directory Domain Services could not update
the following object with changes received from the following source directory
service. This is because an error occurred during the application of the changes to
Active Directory Domain Services on the directory service.

Object: CN=<cn path>

Object GUID: <objectguid>

Source directory service: NTDSA._msdcs.<forst root DNS domain name>

Synchronization of the directory service with the source directory service is blocked
until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action:

Restart the local computer if this condition appears to be related to low system
resources (for example, low physical or virtual memory).

Additional Data:
 Error value: <error code> <error string>

７ Note

In the Error value text, <error code> and <error string> represent the actual
values that are shown in the log entry.
Event 1804 has been logged since Windows 2000 Server.

Destination domain controllers that are running Windows Server 2003 SP1 also log the
following event in the Directory Service log:

Event ID 2108: This event contains REPAIR PROCEDURES for the 1084 event which
has previously been logged. This message indicates a specific issue with the
consistency of the Active Directory Domain Services database on this replication
destination. A database error occurred while applying replicated changes to the
following object. The database had unexpected contents, preventing the change
from being made.

７ Note

Event 2108 is logged on Windows Server 2003 after SP1 is installed.

This is a partner event to Event 1084.

Cause
These events occur when the domain controller cannot write a transactional change to
the local copy of the Active Directory database.

Resolution
To resolve this problem, follow these steps. Retry the replication operation after each
step that makes a change.

1. Make sure that sufficient free disk space is available on the volumes that host the
Active Directory database, and then retry the operation. Follow these steps to free
additional disk space:

a. Move unrelated files to another volume.

 b. Perform a system state backup. This process reduces the size of the transaction
log files. For more information, see How to use the backup feature to back up
and restore data in Windows Server 2003 .

c. Perform an offline defragmentation of Active Directory. For more information,

see How to perform offline defragmentation of the Active Directory database .

2. Make sure that the physical drives that host the Ntds.dit file and the transaction
log files do not have NTFS file system compression turned on. To confirm this,
right-click the drive letter in My Computer, and then make sure that the Compress
drive to save disk space check box is not selected.

3. Make sure that the physical drives that host the Ntds.dit file and the transaction
log files are specifically excluded from remote and local antivirus programs. See
your antivirus software documentation for more information.

4. If the destination domain controller contains the global catalog, and the error
occurs in one of the read-only partitions, use one of the following methods to help
resolve the problem:

Method 1: Use the rehost option of the Repadmin.exe tool to rehost the
affected partition.

The Repadmin.exe tool is installed on computers that have the domain

controller role, and is installed together with the RSAT tool on member
workstations and servers. To do this, type the following at a command
prompt, where domain_controller is the name of the destination domain
controller, and good_source_domain_controller_name is the name of
another domain controller:

Console

repadmin /rehost domain_controller naming_context

good_source_domain_controller_name

Method 2: Configure the domain controller so that it is no longer a global

catalog server. Follow these steps:
a. Click Start, point to Administrative Tools, and then click Active Directory
Sites and Services.
b. Locate the Default-First-Site-Name\ Servers\ domain_controller_name\
NTDS Settings subtree.
c. Right-click NTDS Settings, and then click Properties.
d. Click to clear the Global Catalog check box, and then click OK.
 Method 3

If the error occurs in a program partition, use the Ntdsutil.exe tool to change
the replica that hosts the program partition.

5. Use a third-party utility, such as the FileMon utility, to determine whether a

program or a user is accessing the Active Directory database, the transaction log
files, or the Edp.tmp file. If file access activity exists, stop the services that are
responsible for the activity. For more information about the FileMon utility, see
FileMon for Windows v7.04.

6. Determine whether the problem is related to the parent of the Active Directory
object on the destination domain controller. To do this, follow these steps:

a. On the source domain controller, temporarily move the object that is referenced
in Event 1084 to an organizational unit (OU) container. The OU must be
unrelated to the current container. For example, move the object to a new
container off the root of the domain.

b. If replication is completed after you move the object, move the object back to
its original container.

c. Force the security descriptor propagator to rebuild the object container

ancestry in the database that exists on both the source and destination domain
controllers. To do this, follow these steps:

i. Make sure that the Windows Server 2003 Support Tools are installed. The
Support Tools are available on the Windows Server 2003 CD-ROM in the
Support\Tools folder. Double-click the Suptools.msi file to install the tools.

ii. Click Start, click Run, type ldp, and then click OK.

iii. Click Connection, click Connect, and then type the name of the server that
you want to connect to.

７ Note

You will connect over port 389 for Active Directory.

iv. Click Connection, click Bind, and then type your administrative user name,
password, and domain. (You must use domain administrator or enterprise
administrator credentials.) Click OK.
 v. On the Browse menu, click Modify. Leave the DN text box blank. In the
Attribute text box, type FixUpInheritance. Click Yes in the Value text box.

vi. In the Operation area, click Add.

vii. Click Enter to populate the Entry List area.

７ Note

In the Entry List area, [Add]fixupinheritance:yes appears.

viii. Click Run.

７ Note

The right pane now shows a Modified status, and the security descriptor
propagator starts. The runtime for the security descriptor propagator
depends on the size of the Active Directory database. The process is
complete when the DS Security Propagation Events counter in the
NTDS Performance object returns to zero.

ix. Click Close, click Connection, and then click Exit.

7. On the source domain controller, type repadmin /showmeta

distinguished_name_path at a command prompt, and then view the object

metadata for the distinguished name path that is referenced in Event 1084. Repeat
this step on the destination domain controller. Look for inconsistent values that
include, but are not limited to, the following:

Incorrect names and numbers of attributes that appear on the object

Incorrect originating time or date stamps
Incorrect local update sequence numbers (USN)

Incorrect values may indicate a problem with the database page that hosts the
object.

To use the Repadmin.exe tool when the distinguished name path refers to a live
object, type the following at a command prompt:

Console

repadmin /showmeta remote_domain_controller_name

 distinguished_name_path_of_reference _object

If the object is in a deleted objects container or if you cannot use the

Repadmin.exe tool to find the object, use the object's GUID reference to find the
object. This GUID is referenced in Event 1084. To do this, type the following at a
command prompt:

Console

repadmin /showmeta remote_domain_controller_name "GUID_for_the_object

that_is_referenced_in_Event_ID_1084"

For example, if Event 1084 and Event 2108 reference an object where the GUID is
b49cd496-98a2-4500-bb08-58550c2f79ac, type repadmin /showmeta "
<GUID=b49cd496-98a2-4500-bb08-58550c2f79ac>" .

７ Note

The quotation marks and brackets are required.

8. Obtain the most recent Ntdsutil.exe tool by installing the latest service pack for
your operating system. Use the Ntdsutil.exe tool to perform an integrity check of
the Active Directory database on the source domain controller.

Before you start the computer in Directory Services Restore Mode, obtain the
password for the offline administrator account. If you do not know the
administrator account password, reset the Directory Services Restore Mode
password before you start in this mode. On domain controllers that are running
Windows 2000 Service Pack 2 (SP2) and later, use the Setpwd.exe command. The
Setpwd.exe command is located in the %Systemroot%\System32 folder. On
Windows Server 2003-based domain controllers, use the Ntdsutil Set Directory
Services Restore Mode Password command.

For more information about Directory Services Restore Mode, see "Directory
Services cannot start" error message when you start your Windows-based or SBS-
based domain controller .

For more information about how to change the password in Windows Server 2003,
see "Directory Services cannot start" error message when you start your Windows-
based or SBS-based domain controller .
9. Restart the source domain controller, and then press F8 to start Directory Services
Restore Mode. At the command prompt, type ntdsutil files integrity , and then
press Enter.

７ Note

This command confirms the integrity of the database.

If the Ntdsutil tool reports that the database is corrupted, and you have
replicas of the naming contexts on the source domain controller, force a
demotion of the source domain controller, and then re-promote it after you
verify the integrity of the drivers, the firmware, and the physical drives that
host the Active Directory database and the transaction log files.

If the database is corrupted, and no replicas of the naming context on the

source domain controller exist, restore the newest system state. Use the
NTDSutil.exe tool to confirm the integrity of the database again. If you still
receive a corruption message, restore older backups until you can confirm
the integrity of the domain controller.

If the database is still corrupted, restore the most recent system state backup,
and then, at a command prompt, type:

Console

ntdsutil files recover

Use the NTDSutil.exe tool confirm the integrity of the database again. If the
database passes the integrity check, perform an offline defragmentation of
the disk partition. For more information, see How to perform offline
defragmentation of the Active Directory database .

To perform an integrity check of the database, type the following at a

command prompt, and then press Enter, where database_name is the name
of the Active Directory database:

Console

esentutl.exe /g database_name

Finally, use the Start Windows Normally option to restart the computer, and
then retry replication from the source domain controller to the affected
 destination domain controller. If the database fails the integrity check, the
domain controller must be discontinued. You use the Active Directory
Migration Tool (ADMT) to migrate objects. You can also use the Ldifde.exe
and Csvde.exe tools to export objects that you will import to a new
destination domain controller.

For more information about how to use the Ldifde.exe and Csvde.exe tools,
see Step-by-Step Guide to Bulk Import and Export to Active Directory.

10. If these steps do not succeed, and the replication error continues, demote the
domain controller, confirm the integrity of the physical drives and the volumes that
host the Ntds.dit file and the disk subsystem, and then promote the domain
controller again. Use the same computer name.

11. Use the ntdsutil files compact command to perform an offline defragmentation of
the Active Directory database. For more information, see Performing offline
defragmentation of the Active Directory Database .

12. At the command prompt, type the following command, and then press Enter:

Console

ntdsutil "semantic database analysis" "go"

７ Note

The quotation marks in this example are required to run the semantic
database analysis command by using a single command line argument.

If errors are reported, type ntdsutil go fixup , and then press Enter.

７ Note

The semantic database commands do not perform lossy repairs on Active

Directory databases such as the pre-Windows Server 2003 Service Pack 1
Ntdsutil File Repair or Esentutl /p commands.

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies
that are independent of Microsoft. Microsoft makes no warranty, implied or
otherwise, about the performance or reliability of these products.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication Event ID
1388 or 1988: A lingering object is
detected
Article • 02/19/2024

This article helps you troubleshoot Active Directory replication Event ID 1388 and 1988.

Applies to: Windows Server 2012 R2

Original KB number: 4469619

Summary
If a destination domain controller logs Event ID 1388 or Event ID 1988, a lingering object
has been detected and one of two conditions exists on the destination domain
controller:

Event ID 1388: Inbound replication of the lingering object has occurred on the
destination domain controller.
Event ID 1988: Inbound replication of the directory partition of the lingering object
has been blocked on the destination domain controller.

Event ID 1388
This event indicates that a destination domain controller that does not have strict
replication consistency enabled received a request to update an object that does not
reside in the local copy of the Active Directory database. In response, the destination
domain controller requested the full object from the source replication partner. In this
way, a lingering object was replicated to the destination domain controller. Therefore,
the lingering object was reintroduced into the directory.

） Important

When Event ID 1388 occurs, if either the source domain controller (the replication
partner that is outbound-replicating the lingering object) or the destination domain
controller (the inbound replication partner that reports Event ID 1388) is running
Windows 2000 Server, you cannot use the Repadmin tool to remove lingering
objects. For information about how to remove lingering objects in this case, see
Lingering objects may remain after you bring an out-of-date global catalog
 server back online. The procedures and information in this article apply to the
removal of lingering objects from global catalog servers as well as from domain
controllers that are not global catalog servers.

The event text identifies the source domain controller and the outdated (lingering)
object. The following is an example of the event text:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 5/3/2008 3:34:01 PM
Event ID: 1388
Task Category: Replication
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: DC3.contoso.com Description: Another domain controller (DC) has
attempted to replicate into this DC an object which is not present in the local Active
Directory Domain Services database. The object may have been deleted and already
garbage collected (a tombstone lifetime or more has past since the object was
deleted) on this DC. The attribute set included in the update request is not sufficient
to create the object. The object will be re-requested with a full attribute set and re-
created on this DC.

Source DC (Transport-specific network address):

4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com
Object:
CN=InternalApps,CN=Users,DC=contoso,DC=com
Object GUID: a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a
Directory partition:
DC=contoso,DC=com
Destination highest property USN: 20510
User Action:
Verify the continued desire for the existence of this object. To discontinue re-
creation of future similar objects, the following registry key should be created.

Registry Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication
Consistency

Event ID 1988
This event indicates that a destination domain controller that has strict replication
consistency enabled has received a request to update an object that does not exist in its
local copy of the Active Directory database. In response, the destination domain
controller blocked replication of the directory partition containing that object from that
source domain controller. The event text identifies the source domain controller and the
outdated (lingering) object. The following is an example of the event text:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 2/7/2008 8:20:11 AM Event ID: 1988
Task Category: Replication
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: DC5.contoso.com
Description:
Active Directory Domain Services Replication encountered the existence of objects
in the following partition that have been deleted from the local domain controllers
(DCs) Active Directory Domain Services database. Not all direct or transitive
replication partners replicated in the deletion before the tombstone lifetime number
of days passed. Objects that have been deleted and garbage collected from an
Active Directory Domain Services partition but still exist in the writable partitions of
other DCs in the same domain, or read-only partitions of global catalog servers in
other domains in the forest are known as "lingering objects".

This event is being logged because the source DC contains a lingering object which
does not exist on the local DCs Active Directory Domain Services database. This
replication attempt has been blocked.

The best solution to this problem is to identify and remove all lingering objects in
the forest.

Source DC (Transport-specific network address):

4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com
Object: CN=InternalApps,CN=Users,DC=contoso,DC=com
Object GUID:
a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a

Diagnosis
An object that has been permanently deleted from AD DS (that is, its tombstone has
been garbage-collected on all connected domain controllers) remains on a
disconnected domain controller. The domain controller failed to receive direct or
transitive replication of the object deletion because it was disconnected (it is offline or
experiencing an inbound replication failure) from the replication topology for a period
that exceeded a tombstone lifetime. The domain controller is now reconnected to the
topology and that object has been updated on the domain controller, causing a
replication notification to the replication partner that an update is ready for replication.
The replication partner responded according to its replication consistency setting. This
notification applies to attempted replication of a writable object. A copy of the writable
lingering object might also exist on a global catalog server.

Resolution
If replication of a lingering object is detected, you can remove the object from AD DS,
along with any read-only replicas of the object, by identifying the domain controllers
that might store this object (including global catalog servers) and running a repadmin
command to remove lingering objects on these servers ( repadmin
/removelingeringobjects ). This command is available on domain controllers that are

running Windows Server 2008. It is also available on domain controllers that are not
running Windows Server 2008 but are running the version of Repadmin.exe that is
included with Windows Support Tools in Windows Server 2003.

To remove lingering objects, do the following:

1. Use the event text to identify the following:

a. The directory partition of the object
b. The source domain controller that attempted replication of the lingering object
2. Use Repadmin to identify the GUID of an authoritative domain controller.
3. Use Repadmin to remove lingering objects.
4. Enable strict replication consistency, if necessary.
5. Ensure that strict replication consistency is enabled for newly promoted domain
controllers, if necessary.

Use Repadmin to identify the GUID of an authoritative

domain controller
To perform the procedure that removes lingering objects, you must identify the globally
unique identifier (GUID) of an up-to-date domain controller that has a writable replica of
the directory partition that contains the lingering object that has been reported. The
directory partition is identified in the event message. The object GUID of a domain
controller is stored in the objectGUID attribute of the NTDS Settings object.

Requirements:

Membership in Domain Admins in the domain of the domain controller whose

GUID you want to identify is the minimum required to complete this procedure.
Review details about using the appropriate accounts and group memberships at
Local and Domain Default Groups.
Tool: Repadmin.exe

Steps to identify the GUID of a domain controller

1. At a command prompt, type the following command, and then press ENTER:

Console

repadmin /showrepl <ServerName>

ﾉ Expand table

Parameter Description

/showrepl Displays the replication status, including when the domain controller that
is specified by <ServerName> last attempted inbound replication of
Active Directory partitions. Also displays the GUID of the specified domain
controller.

<ServerName> The name of the domain controller whose GUID you want to display.

2. In the first section of the output, locate the objectGuid entry. Select and copy the
GUID value into a text file so that you can use it elsewhere.

Use Repadmin to remove lingering objects

If the destination domain controller and source domain controller are running either
Windows Server 2003 or Windows Server 2008, you can use this procedure to remove
lingering objects with Repadmin. If either domain controller is running Windows 2000
Server, follow the instructions in Lingering objects may remain after you bring an out-
of-date global catalog server back online.

Requirements:
 Membership in Domain Admins in the domain of the domain controller that has
lingering objects, or Enterprise Admins if the directory partition that has lingering
objects is the configuration or schema directory partition, is the minimum required
to complete this procedure. Review details about using the appropriate accounts
and group memberships at Local and Domain Default Groups.
Operating system: Windows Server 2003 or Windows Server 2008 for
<ServerName> and <ServerGUID>
Tool: Repadmin.exe

Steps to use Repadmin to remove lingering objects

1. Open a Command Prompt as an administrator: On the Start menu, right-click
Command Prompt, and then click Run as administrator. If the User Account
Control dialog box appears, provide Domain Admins or Enterprise Admins
credentials, if required, and then click Continue.

2. At the command prompt, type the following command, and then press ENTER:

Console

repadmin /removelingeringobjects <ServerName> <ServerGUID>

<DirectoryPartition> /advisory_mode

ﾉ Expand table

Parameter Description

/removelingeringobjects Removes lingering objects from the domain controller that is

specified by <ServerName> for the directory partition that is
specified by <DirectoryPartition>.

<ServerName> The name of the domain controller that has lingering objects, as
identified in the event message (Event ID 1388 or Event ID
1988). You can use the Domain Name System (DNS) name or
the distinguished name, for example, the distinguished name
CN=DC5,OU=Domain Controllers,DC=contoso,DC=com or the
DNS name DC5.contoso.com .

<ServerGUID> The GUID of a domain controller that has an up-to-date,

writable replica of the directory partition that contains the
lingering object.

<DirectoryPartition> The distinguished name of the directory partition that is

identified in the event message, for example:
For the Sales domain directory partition in the
contoso.com forest: DC=sales,DC=contoso,DC=com
 Parameter Description

For the configuration directory partition in the

contoso.com forest:
CN=configuration,DC=contoso,DC=com
For the schema directory partition in the contoso.com
forest:
CN=schema,CN=configuration,DC=contoso,DC=com

/advisory_mode Logs the lingering objects that will be removed so that you can
review them, but does not remove them.

3. Repeat step 2 without /advisory_mode to delete the identified lingering objects

from the directory partition.

4. Repeat steps 2 and 3 for every domain controller that might have lingering objects.

７ Note

The <ServerName> parameter uses the DC_LIST syntax for repadmin, which allows
the use of * for all domain controllers in the forest and gc: for all global catalog
servers in the forest. To see the DC_LIST syntax, type repadmin /listhelp . For
information about the syntax of the /regkey and /removelingeringobjects
parameters, type repadmin /experthelp .

Enable strict replication consistency

To ensure that lingering objects cannot be replicated if they occur, enable strict
replication consistency on all domain controllers. The setting for replication consistency
is stored in the registry on each domain controller. However, on domain controllers that
are running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with
Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, you can use
Repadmin to enable strict replication consistency on one or all domain controllers.

On domain controllers running Windows Server 2003 without SP1 or running any
version of Windows 2000 Server, you must edit the registry to enable the setting.

Use Repadmin to enable strict replication consistency

Use this procedure to remove lingering objects on a domain controller that is running
Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2003
R2, or Windows Server 2008.
Membership in Domain Admins, or equivalent, is the minimum required to complete
this procedure on a single domain controller. Membership in Enterprise Admins, or
equivalent, is the minimum required to complete this procedure on all domain
controllers in the forest. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.

Steps to use Repadmin to enable strict replication consistency

1. Open a Command Prompt as an administrator: On the Start menu, right-click

Command Prompt, and then click Run as administrator. If the User Account
Control dialog box appears, provide Domain Admins or Enterprise Admins
credentials, if required, and then click Continue.

2. At the command prompt, type the following command, and then press ENTER:

Console

repadmin /regkey <DC_LIST> +strict

ﾉ Expand table

Parameter Description

/regkey Enables (+) and disables (-) the value for the Strict Replication Consistency
registry entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

<DC_LIST> The name of a single domain controller, or * to apply the change to all
domain controllers in the forest. For the domain controller name, you can use
the DNS name, the distinguished name of the domain controller computer
object, or the distinguished name of the domain controller server object, for
example, the distinguished name CN=DC5,OU=Domain
Controllers,DC=contoso,DC=com or the DNS name DC5.contoso.com .

+strict Enables the Strict Replication Consistency registry entry.

3. If you do not use * to apply the change to all domain controllers, repeat step 2 for
every domain controller on which you want to enable strict replication consistency.

７ Note

For more naming options and information about the syntax of the <DC_LIST>
parameter, at the command prompt type repadmin /listhelp . For information
 about the syntax of the /regkey and /removelingeringobjects parameters, type
repadmin /experthelp .

Use Regedit to enable strict replication consistency

As an alternative to using Repadmin, you can enable strict replication consistency by

editing the registry directly. The registry method is required for a domain controller that
is running a version of Windows Server that is earlier than Windows Server 2003 with
SP1. The setting for replication consistency is stored in the Strict Replication
Consistency entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

The values for the Strict Replication Consistency registry entry are as follows:

Value: 1 (0 to disable)
Default: 1 (enabled) in a new Windows Server 2003 or Windows Server 2008 forest;
otherwise 0.
Data type: REG_DWORD

Requirements:

Membership in Domain Admins, or equivalent, is the minimum required to

complete this procedure. Review details about using the appropriate accounts and
group memberships at Local and Domain Default Groups).
Tool: Regedit.exe

７ Note

It is recommended that you do not directly edit the registry unless there is no other
alternative. Modifications to the registry are not validated by the registry editor or
by Windows before they are applied, and as a result, incorrect values can be stored.
This can result in unrecoverable errors in the system. When possible, use Group
Policy or other Windows tools, such as Microsoft Management Console (MMC), to
accomplish tasks rather than editing the registry directly. If you must edit the
registry, use extreme caution.

Steps to use Regedit to enable strict replication consistency

1. Open Regedit as an administrator: Click Start and then, in Start Search, type
regedit. At the top of the Start menu, right-click regedit.exe, and then click Run as
 administrator. In the User Account Control dialog box, provide Domain Admins
credentials, and then click OK.

2. Navigate to the Strict Replication Consistency entry in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

3. Set the value in the Strict Replication Consistency entry to 1.

Ensure that strict replication consistency is enabled for

newly promoted domain controllers
If you are upgrading a forest that was originally created using a computer running
Windows 2000 Server, you should ensure that the forest is configured to enable strict
replication consistency on newly promoted domain controllers to help avoid lingering
objects. After you update the forest as described in (Upgrading Active Directory
Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains), all
new domain controllers that you subsequently add to the forest are created with strict
replication consistency disabled. However, you can implement a forest configuration
change that causes new domain controllers to have strict replication consistency
enabled. To ensure that new domain controllers that you add to the forest have strict
replication consistency enabled, you can use the Ldifde.exe tool to create an object in
the configuration directory partition of the forest. This object is responsible for enabling
strict replication consistency on any Windows Server 2003 or Windows Server 2008
domain controller that is promoted into the forest.

The object that you create is an operational GUID with the following name:

CN=94fdebc6-8eeb-4640-80de-
ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=
<ForestRootDomain>

You can use the following procedure on any domain controller in the forest to add this
object to the configuration directory partition.

Membership in Enterprise Admins, or equivalent, is the minimum required to complete

this procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.

Steps to create the object that ensures strict replication consistency

on new domain controllers

1. In a text editor, such as Notepad, create the following text file:

 dn:
CN=94fdebc6-8eeb-4640-80de-
ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=
<ForestRootDomain>
changetype: add
objectClass: container
showInAdvancedViewOnly: TRUE
name: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=
<ForestRootDomain>

2. Where <ForestRootDomain> contains all domain components (DC=) of the forest

root domain, for example, for the contoso.com forest, DC=contoso,DC=com; for
the fineartschool.net forest, DC=fineartschool,DC=net.

3. Open a Command Prompt as an administrator: On the Start menu, right-click

Command Prompt, and then click Run as administrator. If the User Account
Control dialog box appears, provide Enterprise Admins credentials, if required, and
then click Continue.

4. At the command prompt, type the following command, and then press ENTER:

Console

ldifde -i -f <Path>\<FileName>

ﾉ Expand table

Parameter Description

-i Specifies the import mode. If the import mode is not specified, the
default mode is export.

-f Identifies the import or export file name.

<Path>\ The path and name of the import file that you created in step 1, for
<FileName> example, C:\ldifde.txt.

For information about using Ldifde, see LDIFDE.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory Replication Error 1127:
While accessing the hard disk, a disk
operation failed even after retries
Article • 02/19/2024

This article describes an issue where Active Directory Replications fail with Win32 error
1127: "While accessing the hard disk, a disk operation failed even after retries."

Applies to: Windows Server 2012 R2

Original KB number: 2025726

Symptoms
This article describes symptoms, cause, and resolution steps for cases where AD
operations fail with Win32 error 1127: "While accessing the hard disk, a disk operation
failed even after retries."

1. The DCPROMO promotion of a new domain controller fails with error 1127: While
accessing the hard disk, a disk operation failed even after retries

The on-screen error displayed in DCPROMO is:

Dialog title text: Active Directory Installation Wizard

Message text:

The operation failed because:

Active Directory could not replicate the directory partition <DN path of failing
partition> from the remote domain controller <fully qualified computer name
of helper DC>.
"While accessing the hard disk, a disk operation failed even after retries."
DCPROMO.LOG contains the following text:
[INFO] Replicating the <partition name> directory partition
[INFO] Error - Active Directory could not replicate the directory partition
<partition DN> from the remote domain controller <helper DC>. (1127)
[INFO] NtdsInstall for <DNS domain> returned 1127
[INFO] DsRolepInstallDs returned 1127 [ERROR] Failed to install to Directory
Service (1127)
2. DCDIAG reports that the Active Directory Replications test has failed with error
status (1127): While accessing the hard disk, a disk operation failed even after
retries

Sample error text from DCDIAG is shown below:

Testing server: <site><DC name>

Starting test: Replications
* Replications Check
[Replications Check,<DC name>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: DC=<DN path>
The replication generated an error (1127):
While accessing the hard disk, a disk operation failed even after retries.
The failure occurred at <date> <time>.
The last success occurred at (never)| <date>.

3. REPADMIN.EXE reports that the last replication attempt has failed with status 1127

REPADMIN commands that commonly cite the 1127 status include but aren't
limited to:

REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL

4. The "replicate now" command in Active Directory Sites and Services (DSSITE.MSC)
fails with the on-screen error "While accessing the hard disk, a disk operation failed
even after retries"

Dialog title: Replicate Now

Message text: The following error occurred during the attempt to synchronize
naming context <DNS name of directory partition> from domain controller
<source DC>
to domain controller <destination DC>:
While accessing the hard disk, a disk operation failed even after retries.
This operation will not continue.

5. Events in the Directory Services event log cite the error status 1127

Events that commonly cite the 1127 status include but aren't limited to:
 ﾉ Expand table

Event Source Message String

and Event ID

NTDS KCC The attempt to establish a replication link to a read-only directory partition
1926 with the following parameters failed

NTDS Internal event: Active Directory could not update the following object with
Replication changes received from the following source domain controller. This is
1084 because an error occurred during the application of the changes to Active
Directory on the domain controller.

NTDS The local domain controller failed to retrieve the changes requested for the
Replication following directory partition. As a result, it was unable to send the change
1699 requests to the domain controller at the following network address.

NTDS This event contains REPAIR PROCEDURES for the 1084 event that has
Replication previously been logged. This message indicates a specific issue with the
2108 consistency of the Active Directory database on this replication destination.
A database error occurred while applying replicated changes to the
following object. The database had unexpected contents, preventing the
change from being made.

6. NTDS Replication event 2108 may be logged in the Directory Services Event log
citing the object, source DC, and jet error that is triggering the logging of the 1127
status in on-screen errors, logged events, and diagnostic tool output.

Jet errors known to appear in NTDS Replication event 2108 with status 1127
include but aren't limited to:

ﾉ Expand table

Jet Error Symbolic Error Error string

(decimal)

-510 JET_errLogWriteFail Failure writing to log file

-1018 JET_errReadVerifyFailure Checksum error on a database

page

-1019 JET_errPageNotInitialized Blank database page

-1021 JET_errDiskReadVerificationFailure The OS returned ERROR_CRC from

file IO

-1022 JET_errDiskIO Disk IO error

-1605 JET_errKeyDuplicate Illegal duplicate key

 7. NTDS ISAM events may be logged in the Directory Services event log indicating
the existence of jet errors related to the 1127 status appearing in other on-screen
errors, logged events and diagnostic tool output

ﾉ Expand table

Event Event text

source +
event ID

NTDS The database page read from the file <drive:\path\ntds.dit> at offset <decimal
ISAM offset> (<hex offset>) for <decimal page size> (<hex page size>) bytes failed
474 verification to a page checksum mismatch.... The read operation will fail with
error <decimal jet error> (<hex jet error>). ). If this condition persists then
please restore the database from a previous backup. This problem is likely due
to faulty hardware. Please contact your hardware vendor for further assistance
diagnosing the problem.

NTDS The database page read from the file <drive:\path\ntds.dit> at offset <decimal
ISAM offset> (<hex offset>) for <decimal page size> (<hex page size>) bytes failed
475 verification to a page number mismatch.... The read operation will fail with error
<decimal jet error> (<hex jet error>). ). If this condition persists then please
restore the database from a previous backup. This problem is likely due to faulty
hardware. Please contact your hardware vendor for further assistance
diagnosing the problem.

Cause
Active Directory is unable to write to the Active Directory database or log files. Root
causes include:

1. Software on the local machine is interfering with Active Directory's ability to write
changes to the Active Directory database and/ or log files
2. A defect exists in the disk subsystem including the motherboard/ driver controller,
firmware, driver, physical drives.

Resolution
1. Locate NTDS replication event 1084 events in the Directory Services Event Log

For DCs logging the 1127 status, open the Directory Service Event log and focus
on NTDS Replication event 1084.
 NTDS Replication Event 1084 indicates that Active Directory could not write
updates to an object in its local copy of Active Directory.

Metadata in the Event 1084 identifies (1.) the DN path (and thus the objects host
partition) that could not be updated, (2.) the objectGUID for the object in question
and (3.) the fully qualified CNAME record of the source DC that is sending the
update

2. Locate the NTDS Replication Event 2108 logged immediately following each
NTDS Replication 1084 event and identify the jet error logged in the 2108 event.

NTDS Replication event 2108 is the "User Action" for the NTDS Replication 1084
event.

For every NTDS replication 1084 event logged, there should be a corresponding
NTDS replication 2108 event logged in the Directory Services event log that cites
(1.) the same object DN path and (2.) objectguid and (3.) source DC logged in the
preceding NTDS Replication 1084 event AND a jet error that defines / scopes the
cause and your recovery plan to resolve the error condition.

3. Execute the action plan for the Jet error logged in your NTDS Replication Event
2108:

If the Jet error logged in your NTDS replication events is listed in the table below,
execute the user action, otherwise, skip to step #4:

ﾉ Expand table

Jet Error Symbolic Error + Error String User Action

(decimal)

-510 JET_errLogWriteFail / A log write failure occurred on the

Failure writing to log file destination DC.

Check disk, partition, and file system

health on the destination DC.

Check for software that may be creating

locks on Active Directory log files such as
antivirus software on the destination DC.

See if problem persists following reboot

or try clean boot

Method 1: Stop services that create locks

on files in the file system and focusing
Jet Error Symbolic Error + Error String User Action
(decimal)

specifically on antivirus software.

Method 2: Press F8 during OS boot and

chose "Safe Mode with Networking".

Method 3: Disable non-boot related

third party services. Reboot.

Windows key + R -> MSCONFIG ->

Services tab - > Hide all Microsoft
Services -> Disable checkbox for 3rd-
party services

Windows key + R -> MSCONFIG ->

Startup tab - > Hide all Microsoft
Services -> click "Disable all"

-1018 JET_errReadVerifyFailure / DB is corrupt

Checksum error on a database
page Error caused by a hardware failure.

Evaluate the disk stack including

motherboard / controller, firmware,
connecting cables and physical drives
and contact the relevant vendors for
known issues. Compare current
configuration against vendors reference
configuration.

Evaluate whether problem can be

resolved by latest firmware updates or
was triggered by recent firmware update.

If some DCs are logging -1018s while

other DCs in same environment are not,
look for differences in hardware
configuration.

Databases logging this error can't be

recovered or repaired by integrity checks
or semantic database analysis in
NTDSUTIL or ESENTUTL.

Offline defragsmayresolve the problem

in the unlikely case that problem is
caused by an index consistency problem.
Jet Error Symbolic Error + Error String User Action
(decimal)

Try an offline defrag, otherwise, restore a

system state backup that pre-dates the
corruption, OR force demote, perform a
full metadata cleanup, and re-promote. If
the -1018 error appears, repeat until
hardware root cause is resolved.

One customer reported jet error -1018s

on virtualized DCs running on the same
virtual host only on computers using an
on-board raid controller. Current
thinking is that the UPS lacked sufficient
power for on-board raid controllers to
commit changes to disk following loss of
electrical power. Workaround was to
configure UPS software to shut down
virtualized guests on loss of electrical
power. Servers with dedicated (not on-
board) raid controllers with their own
battery backups didn't experience the
-1018 jet error.

-1019 JET_errPageNotInitialized / Similar to -1018 error but caused by a

Blank database page lost page flush.

A lost flush can represent a critical USN

change. Failure to apply same to local
DC or transitive replication partners
could be harmful where a single
replication path exists.

Deploy OS on server class hardware and

disk subsystem components

Install UPS on host computer.

Install disk controller with on-board

battery backup.

Disable write-back cache on drive

controller.

Avoid placing NTDS.DIT and LOG files on

IDE drives

Databases logging this error can't be

recovered or repaired by integrity checks
Jet Error Symbolic Error + Error String User Action
(decimal)

or semantic database analysis in

NTDSUTIL or ESENTUTL.

Offline defrags may resolve the problem

in the unlikely case that problem is
caused by index consistency problem.

Try an offline defrag, otherwise, restore a

system state backup that pre-dates the
corruption, OR force demote, perform a
full metadata cleanup, and re-promote.
Repeat until hardware root cause is
resolved.

-1021 JET_errDiskReadVerificationFailure / Jet error -1021 is new to Windows Server

The OS returned ERROR_CRC from 2008 R2.
file IO
Pre-Windows Server 2008 R2 operating
systems return -1022 for this case.

-1021 identifies that a -1018 error

occurred at the disk level. Restated,
-1021 indicates that a disk drive returned
a bad check sum error and is the specific
source of the problem in the disk stack.

Problem may be caused by bad blocks

on the hard drive that the hard drive
may keep track of.

Demoting and re-promoting the domain

controller may trigger the storage of
data on healthy blocks.

-1022 JET_errDiskIO / Disk IO error Generic disk error

Disk IO errors mean that the OS

encountered a non-specific error
accessing the disk. This error may be
logged when controllers return generic
errors like "device not working". Some
disks and versions of jet return this error
for CRC problems.

Verify whole driver stack.

 Jet Error Symbolic Error + Error String User Action
(decimal)

-1605 JET_errKeyDuplicate / Illegal Sporadic error.

duplicate key Demote and repromote.
May be caused by index corruption.
Run NTDUSITL semantic database
analysis. If still unresolved, perform an
offline defrag.

4. If the Jet error in the NTDS replication event is NOT in table above, validate the
vertical Jet database stack

If the 2108 event logs a jet error NOT cited in the table, use the Microsoft
Exchange Server Error Code Look-up utility to resolve the jet error to its
symbolic and friendly error string using the syntax "err <jet error>". It is critical
that you add the leading "-" prefix character when resolving jet errors using
ERR.EXE. (for example, "c:\>err -1018").

The event message text in NTDS Replication event 2108 contains a partial user
action for the NTDS Replication 1084 event.

The NTDS Replication 2108 user action is documented in the linked KB article
MSKB 837932 . If the user action for your event isn't cited in the table above,
execute a modified version of the action plan in MSKB 837932 by validating the
vertical jet database stack from the bottom up (proceeding up to the next layer
only when the underlying layer checks out "good"), just like you do with TCP.

ﾉ Expand table

Layer NTDSUTIL command ESENTTUL

command

(1.) Physical consistency no equivalent ESENTUTL /K

(2.) ESE Logical consistency NTDSUTIL FILES INTEGRITY ESENTUTL /G

(3.) Application logical NTDSUTIL ->Semantic database no equivalent for

consistency analysis SDA

+
+
NTDSUTIL -> Offline Defrag
ESENTUTL / D
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8240: There is no such object on the
server
Article • 02/19/2024

This article describes the symptoms, cause, and resolution for AD operations that fail
with Win32 error 8240: "There is no such object on the server."

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2680976

Symptoms

Symptom 1
Output of the Repadmin /ShowReps command:

SiteName\DCName via RPC

objectGuid: <GUID>
Last attempt @ <Time> failed, result 8240:
There is no such object on the server.
Last success @ (never).

Symptom 2
When you try to force replication in the Active Directory Sites and Services console
(dssite.msc) by using the Replicate now option, you receive the following error message:

The following error occurred during the attempt to synchronize naming context
<Naming Context> from Domain Controller <Source-DC-Name> to Domain
 Controller <Destination-DC-Name>:
There is no such object on the server. This operation will not continue.

Symptom 3
When you try to remove Active Directory from a domain controller, you receive the
following error message in the Active Directory installation wizard:

Active Directory could not transfer the remaining data in directory partition
<Naming-Contentxt> to domain controller <Domain-Controller>."There is no such
object on the server."

Symptom 4
You receive NTDS General event 1126 in Directory Service on Domain Controller with
error 8240:

Event Type: Error

Event Source: NTDS General
Event Category: Global Catalog
Event ID: 1126
Date: <DateTime>
Time: <DateTime>
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: ComputerName
Description:
Active Directory was unable to establish a connection with the global catalog.

Additional Data
Error value:
8240 There is no such object on the server.
Internal ID:
3200ba0

Cause
Error 8240 (0x2030) means ERROR_DS_NO_SUCH_OBJECT. This indicates that the
specific object couldn't be found in directory. This error may be encountered in the
following two situations.
Situation 1: During AD replication
When a change occurs to an object in Active Directory on the source domain controller,
the source domain controller propagates this change to other domain controllers by
notifying its replication partners to retrieve this change. Destination domain controllers
pull the change from the source domain controller when they receive the change the
notification. After the change is retrieved, destination domain controllers try to transact
the change into the local database.

The destination domain controller has to look up the changed object in the local
database so that the change can be applied to that object. If the target object can't be
located for some reason, Active Directory reports error 8240.

This error may be observed in the following situations:

When a change occurred to an object on the source domain controller but this
object was cleaned by the garbage-collection process
When AD replication recovers after it fails for a time that exceeds the tombstone
lifetime (TSL), deletion may not be propagated before the tombstone is cleaned
When the change-originating domain controller has Active Directory removed
before the domain controller has an opportunity to propagate the deletion to
other domain controllers that host a writable partition for that domain and the
change is replicated to global catalog

Situation 2: Reported 8240 in 1126 Event (NTDS)

The domain controller tries to locate global catalogs for its functionalities, such as
universal group membership lookup. If the system can't locate an available domain
controller, event 1126 is reported together with error 8240 in the NTDS event log.

Resolution

Situation 1: During AD replication

To troubleshoot this issue, follow these steps:

1. Determine the problematic domain controller that has the inconsistent object. This
error means that the local domain controller finds that an inconsistent object exists
in its incoming partner (for the specific replication connection) but not local AD
database.
2. Determine whether you want to remove the objects or leave those objects as they
are, as follows:

If you want to remove the objects, you can use the Repadmin.exe command
together with the RemoveLingeringObjects switch to remove those
inconsistent objects from the source domain controller. For more
information, go to the following Microsoft TechNet website:

Use Repadmin to remove lingering objects

７ Note

For a read-only partition, you have to use the Repadmin /Rehost

command.

If you want to keep those objects, you can create the following objects on the
destination domain controller:

Sub-Key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Value Name: Strict Replication Consistency

Value Type: REG_DWORD
Value Data: 0

Sub-Key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Value Name: Allow Replication With Divergent and Corrupt Partner

Value Type: REG_DWORD
Value Data: 1

Sub-Key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Value Name: Correct Missing Object

Value Type: REG_DWORD
Value Data: 1

７ Note

You must be careful in a large environment that contains many domain

controllers, because the propagation of those inconsistent objects could
 cause more and more domain controllers to report 8240 errors until the
propagation is complete.

Another option is to forcedly remove Active Directory from the domain

controller that contains the inconsistent objects. To do this, follow these
steps:
a. Forcedly remove Active Directory: Active Directory Installation Wizard
(Dcpromo.exe) /forceremoval.
b. Clean up metadata for the domain controller by following the steps in the
following article in the Microsoft Knowledge Base: 216498 How to
remove data in Active Directory after an unsuccessful domain controller
demotion
c. Repromote the domain controller by using Dcpromo.exe.

Situation 2: Reported 8240 in 1126 Event (NTDS)

For the error that indicates that GC isn't available, we may generally follow the GC
location process to check. To do this, follow these steps:

1. Check whether there's any specified global catalog in the forest. If there's not,
configure a GC.

７ Note

After you mark a domain controller as GC, it may take time for KCC to
calculate a new replication topology, build the global catalog, and GC ready
announcement. How long depends on the replication schedule, the time that
is used to replicate the required read-only NCs, and the interval of KCC actvity.

2. Check whether you can obtain a domain controller from DNS through the
command lTest.exe /DnsGetDC:<DomainName> /GC /Force. If you can't GC record
in DNS, take the following two actions:

GC announcement on existing GCs: use ldp.exe connect to GC to check

whether the value of isGlobalCatalogReady is set to true.
Check DNS registration: netdiag /fix.

3. Check whether you can connect to the GC over TCP 3268 through ldp.exe.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

More information
For more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:

910204 Troubleshooting problems with promoting a domain controller to a global

catalog server

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 8409 and AD replication fails after
you restore or undelete AD objects in
Windows Server 2016
Article • 02/19/2024

This article provides a solution to an error 8409 after you restore or undelete AD objects.

Applies to: Windows Server 2016

Original KB number: 4046675

Symptoms
Assume that you have a Windows Active Directory forest that has Domain Controllers in
Windows Server 2016, and the Recycle Bin optional feature is not enabled. Assume also
that you restore a deleted object through an NTDSUTIL authoritative restore operation,
or you undelete it through an LDAP command or a commercial recovery tool.

After the update replicates, the Active Directory replication fails and returns error 8409.

７ Note

The failure occurs at every replication attempt for the affected naming context for
all inbound partners. However, the failure stops occurring after several hours.

Additionally, the following events are logged in the Windows NT Directory Services
(NTDS) event log on the domain controller in Windows Server 2016:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1481
Task Category: Internal Processing
Description:
Internal error: The operation on the object failed.

Additional Data
Error value:
5 000020D9: SvcErr: DSID-030F2534, problem 5001 (BUSY), data 0
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1084
Task Category: Replication
Description:
Internal event: Active Directory Domain Services could not update the following
object with changes received from the following source directory service. This is
because an error occurred during the application of the changes to Active Directory
Domain Services on the directory service.

Object:
CN=user,OU=users,DC=contoso,DC=com
Object GUID: GUID
Source directory service:
GUID._msdcs.contoso.com

Synchronization of the directory service with the source directory service is blocked
until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action
Restart the local computer if this condition appears to be related to low system
resources (for example, low physical or virtual memory).

Additional Data
Error value:
8409 A database error has occurred.
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2108
Task Category: Replication
Description:
This event contains REPAIR PROCEDURES for the 1084 event which has previously
been logged. This message indicates a specific issue with the consistency of the
Active Directory Domain Services database on this replication destination. A
database error occurred while applying replicated changes to the following object.
The database had unexpected contents, preventing the change from being made.

Object:
CN=user,OU=users,DC=contoso,DC=com
Object GUID: GUID
 Source directory service:
GUID._msdcs.contoso.com

User Action
...
Additional Data
Primary Error value:
8409 A database error has occurred.
Secondary Error value:
0 The operation completed successfully.

Cause
When NTDS is started in Windows Server 2008 R2 or a later version, DS starts an internal
task to check all writable NCs for the need to assign a value of TRUE to the IsRecycled
attribute of the deleted objects.

Until this task is completed, the status of the Recycle Bin optional feature is disabled. In
this state, the replication engine does not allow undeleting or restoring of Active
Directory objects. Therefore, this does not interact with the addition of the isRecycled
attribute.

This task is completed in a few seconds if the objects already have the attribute value of
TRUE. In Windows Server 2016, the task is deferred during a startup to improve the DS
startup time, and it's rescheduled to begin six hours later. Therefore, you can't replicate
any AD object restore process for the first six hours of the DS uptime.

NTDS diagnostics logging for six Garbage Collection at level 2 would enable you to see
the "2406" event that indicates the start of the task and the "2405" event that indicates
the end of the task.

If the AD replication has the top priority, you can delete the objects again and then
restore them again later. Or, you can wait for six hours until the task is completed. If you
restart the domain controller, you start another six-hour interval with this issue.

Resolution
To fix this issue, enable the Recycle Bin optional feature to allow the undelete or restore
operations to finish. After you do this, there is no task started that will disable the
optional feature.
More information
When the directory service starts, it tracks the progress of the task through events that
are logged in the NTDS event log. The events for managing the disabling of the Recycle
Bin optional feature are as follows:

Disabling state:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2406
Task Category: Internal Configuration
Level: Information
Description:
This Active Directory Domain Services server is disabling support for the "Recycle
Bin Feature" optional feature.

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2121
Task Category: Internal Configuration
Level: Information
Description:
This Active Directory Domain Services server is disabling the Recycle Bin. Deleted
objects may not be undeleted at this time.

Disabled state:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2405
Task Category: Internal Configuration
Level: Information
Description:
This Active Directory Domain Services server does not support the "Recycle Bin
Feature" optional feature.

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2120
Task Category: Internal Configuration
Level: Information
Description:
 This Active Directory Domain Services server does not support the Recycle Bin.
Deleted objects may be undeleted, however, when an object is undeleted, some
attributes of that object may be lost. Additionally, attributes of other objects that
refer to the object being undeleted may also be lost.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

AD replication isn't working with event
1865 logged
Article • 02/19/2024

This article helps fix an issue where Active Directory replication doesn't work and event
IDs 1865 and 1311 are logged.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Original KB number: 944351

Symptoms
You have multiple sites in the forest. On some sites, you find that AD replication isn't
working.

On the Inter-Site Topology Generator (ISTG) Domain Controllers, the following events
are logged every 15 minutes.

Event Type: Warning

Event Source: NTDS KCC
Event Category: Knowledge Consistency Checker
Event ID: 1865
Date: <date>
Time: <time>
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: <computername>
Description:
The Knowledge Consistency Checker (KCC) was unable to form a complete spanning
tree network topology. As a result, the following list of sites cannot be reached from
the local site.

Sites: CN=<sitename>,CN=Sites,CN=Configuration,DC=<domain>,DC=com

Event Type: Error

Event Source: NTDS KCC
Event Category: Knowledge Consistency Checker
Event ID: 1311
Date: <date>
Time: <time>
User: NT AUTHORITY\ANONYMOUS LOGON
 Computer: <computername>
Description:
The Knowledge Consistency Checker (KCC) has detected problems with the
following directory partition.

Directory partition:
CN=Configuration,DC=<domain>,DC=com

Cause
This may happen when there are connectivity issues between the ISTG servers. For
example, if a firewall has blocked the ports, the issue would occur.

Resolution
Use the portqry tool to troubleshoot the connectivity issues to the Bridgehead servers of
the sites that are listed in Event 1865. If the ports are blocked by the firewall, configure
the firewall to open the ports.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Community solutions content disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title, and non-infringement. You specifically agree that in no event
shall microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
1818: The remote procedure call was
cancelled
Article • 02/19/2024

This article describes an issue where Active Directory Replications fail with error 1818:
The remote procedure call was cancelled (RPC_S_CALL_CANCELLED).

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2694215

Symptoms
This article describes the symptoms, cause, and resolution steps when Active Directory
replication fails with error 1818: The remote procedure call was cancelled
(RPC_S_CALL_CANCELLED).

1. Possible formats for the error include:

ﾉ Expand table

Decimal Hex Symbolic Error string

1818 0x71a RPC_S_CALL_CANCELLED The remote procedure call was cancelled.

2. The following events get logged

ﾉ Expand table

Event Event ID Event String

Source

NTDS 1232 Active Directory attempted to perform a remote procedure call

Replication (RPC) to the following server. The call timed out and was
 Event Event ID Event String
Source

cancelled.

NTDS 1188 A thread in Active Directory is waiting for the completion of a

Replication RPC made to the following domain controller.
Domain controller:
b8b5a0e4-92d5-4a88-a601-61971d7033af._msdcs.Contoso.com
Operation:
get changes
Thread ID:
448
Timeout period (minutes):
5
Active Directory has attempted to cancel the call and recover
this thread.
User Action
If this condition continues, restart the domain controller.

1173 with Internal event: Active Directory has encountered the following
NTDS error exception and associated parameters. Exception: e0010002
Replication status Parameter: 0 Additional Data Error value: 1818 Internal ID:
1818 5000ede

NTDS 1085 with Internal event: Active Directory could not synchronize the
Replication error following directory partition with the domain controller at the
status following network address.
1818 Directory partition: <NC>
Network address: <GUID-based DC name>
If this error continues, the Knowledge Consistency Checker (KCC)
will reconfigure the replication links and bypass the domain
controller.
User Action
Verify that the network address can be resolved with a DNS
query.
Additional Data Error value: 1818 The remote procedure call was
cancelled.

. Repadmin /showreps displays the following error message

DC=Contoso,DC=com

<Sitename>\<DCname> via RPC DC

DC object GUID: <GUID> Last attempt @ 2009-11-25 10:56:55 failed, result

1818 (0x71a): Can't retrieve message string 1818

(0x71a), error 1815. 823 consecutive failure(s). Last success @ (never).

3. Repadmin /showreps from Domain Controller Name shows that it's failing to pull
Domain NC from <SiteName> but can pull all other NCs

===================

<Sitename>\<DC name>

DC Options: IS_GC

Site Options: IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED

DC object GUID: <GUID>

DC invocationID: <InvocationID>

==== INBOUND NEIGHBORS

=====================================

DC=Contoso,DC=com

<Sitename>\<DCname> via RPC DC

DC object GUID: <GUID>

Last attempt @ <DateTime> failed, result 1818 (0x71a):

Can't retrieve message string 1818 (0x71a), error 1815. 123 consecutive

failure(s). Last success @ (never).

4. DCPromo may fail while promoting a new domain controller and you'll see the
following error on the DCPROMO GUI

Active Directory Installation wizard.

The Operation Failed because: Active Directory could not replicate the
directory partition
CN=Configuration....from the remote domain controller "server name"
" The remote procedure call was cancelled "

The following entries will be logged in the DCPROMO logs

<DateTime> [INFO] EVENTLOG (Informational): NTDS General / Service Control

: 1004

Active Directory Domain Services was shut down successfully.

 <DateTime> [INFO] NtdsInstall for <FQDN fo the domain> returned 1818

<DateTime> [INFO] DsRolepInstallDs returned 1818

<DateTime> [ERROR] Failed to install to Directory Service (1818)

<DateTime> [ERROR] DsRolepFinishSysVolPropagation (Abort Promote) failed

with 8001

<DateTime> [INFO] Starting service NETLOGON

<DateTime> [INFO] Configuring service NETLOGON to 2 returned 0

<DateTime> [INFO] The attempted domain controller operation has completed

<DateTime> [INFO] DsRolepSetOperationDone returned 0

5. While trying to rehost a partition on the Global catalog

repadmin /rehost fail with DsReplicaAdd failed with status

1818 (0x71a)>

DsReplicaAdd fails with status 1818 (0x71a)

Cause
The issue occurs when the destination DC performing inbound replication doesn't
receive replication changes within the number of seconds specified in the "RPC
Replication Timeout" registry key. You might experience this issue most frequently in
one of the following situations:

You promote a new domain controller into the forest by using the Active Directory
Installation Wizard (Dcpromo.exe).
Existing domain controllers replicate from source domain controllers that are
connected over slow network links.

The default value for the RPC Replication Timeout (mins) registry setting on Windows
2000-based computers is 45 minutes. The default value for the RPC Replication Timeout
(mins) registry setting on Windows Server 2003-based computers is 5 minutes. When
you upgrade the operating system from Windows 2000 to Windows Server 2003, the
value for the RPC Replication Timeout (mins) registry setting is changed from 45
minutes to 5 minutes. If a destination domain controller that is performing RPC-based
replication doesn't receive the requested replication package within the time that the
RPC Replication Timeout (mins) registry setting specifies, the destination domain
controller ends the RPC connection with the non-responsive source domain controller
and logs a Warning event.

Some specific root causes for Active Directory logging 1818 \ 0x71a \
RPC_S_CALL_CANCELLED include:

1. An old Network Interface Card driver installed on Domain Controllers could cause
failure of a few network features like Scalable Networking Pack (SNP)
2. Low bandwidth or network packets drops between source and destination domain
controllers.
3. The networking device between source and destination device dropping packets.

７ Note

A speed and duplex mismatch between the NIC and switch on a domain controller
could cause dropped frames, resets, duplicate acknowledgments, and retransmitted
frames.

Resolution
1. Increase replication time-out adding the key RPC Replication Timeout (mins) on
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Start Registry Editor.

Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Right-click Parameters, point to New, and then click DWORD Value.

Type RPC Replication Timeout (mins), and then press ENTER to name the new
value.

Right-click RPC Replication Timeout (mins), and then click Modify.

In the Value data box, type the number of minutes that you want to use for
the RPC timeout for Active Directory replication, and then click OK.

On a Windows Server 2003-based computer that is part of a Windows 2000

environment or that was upgraded from Windows 2000 Server, you may want to
set this value to 45 minutes. This is value may depend on your network
configuration and should be adjusted accordingly.
 ７ Note

You must restart the computer to activate any changes that are made to RPC
Replication Timeout (mins)

2. Update the network adapter drivers

To determine whether an updated network adapter driver is available, contact the

network adapter manufacturer or the original equipment manager (OEM) for the
computer. The driver must meet Network Driver Interface Specification (NDIS) 5.2
or a later version of this specification.

To manually disable RSS and TCP Offload yourself, follow these steps:

Click Start, click Run, type regedit, and then click OK.

Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Right-click EnableTCPChimney, and then click Modify.

In the Value data box, type 0, and then click OK.

Right-click EnableRSS, and then click Modify.

In the Value data box, type 0, and then click OK.

Right-click EnableTCPA, and then click Modify.

In the Value data box, type 0, and then click OK.

Exit Registry Editor,

７ Note

You must restart the computer to activate any changes that are made to
EnableTCPChimney.

3. Enable PMTU Black Hole Detection on the Windows-based hosts that will be
communicating over a WAN connection. Follow these steps:

Start Registry Editor ( Regedit.exe ).

 Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters

On the Edit menu, click Add Value, and then add the following registry value:

Value Name: EnablePMTUBHDetect

Data Type: REG_DWORD
Value: 1
Restart the machine

4. Check the network binding order:

To configure the network binding order:

a. Quit any programs that are running.

b. Right-click Network Neighborhood, and then click Properties.

c. Click the Bindings tab. In the Show Bindings For box, click All Services.

d. Double-click each listed service to expand it.

e. Under each service, double-click each protocol to expand it.

f. Under each protocol, there's a number of network adapter icons. Click the icon
for your network adapter, and then click Move Up until the network adapter is
at the top of the list. Leave the "Remote Access WAN Wrapper" entries in any
order under the network adapter(s).

７ Note

If you have more than one network adapter, place the internal adapter
(with Internet Protocol [IP] address 10.0.0.2 by default on a Small Business
Server network) at the top of the binding order, with the external
adapter(s) directly below the internal adapter.

The final order should appear similar to:

[1] Network adapter one
[2] Network adapter two (if present)
[3] Remote Access WAN Wrapper
.
.
.
[n] Remote Access WAN Wrapper
 g. Repeat step 6 for each service in the dialog box.

h. After you've verified the settings for each service, click All Protocols in the Show
Bindings For box. The entry for "Remote Access WAN Wrapper" doesn't have a
network adapter listed. Skip this item. Repeat steps 4 through 6 for each
remaining protocol.

i. After you've verified that the bindings are set correctly for all services and
protocols, click OK. This initializes the rebinding of the services. When this is
complete, you're prompted to restart the computer. Click Yes.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

More information
Active Directory changes do not replicate

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot Active Directory
replication error 5 in Windows Server: Access is
denied
Article • 02/19/2024

This article describes the symptoms, cause, and resolution of situations in which Active Directory
replication fails with error 5: Access is denied.

Applies to: Windows Server 2012 R2

Original KB number: 3073945

Symptoms
You may encounter one or more of the following symptoms when Active Directory replications fail with
error 5.

Symptom 1
The Dcdiag.exe command-line tool reports that the Active Directory replication test fails with error
status code (5). The report resembles the following:

Testing server: Site_Name\Destination_DC_Name

Starting test: Replications
*Replications Check
[Replications Check,Destination_DC_Name] A recent replication attempt failed:
From Source_DC to Destination_DC
Naming Context: Directory_Partition_DN_Path
The replication generated an error (5):
Access is denied.
The failure occurred at Date Time.
The last success occurred at Date Time.
Number failures have occurred since the last success.

Symptom 2
The Dcdiag.exe command-line tool reports that the DsBindWithSpnEx function fails with error 5 by
running the DCDIAG /test:CHECKSECURITYERROR command.

Symptom 3
The REPADMIN.exe command-line tool reports that the last replication attempt failed with status 5.

The REPADMIN commands that frequently cite the five status include but aren't limited to the
following:
 REPADMIN /KCC
REPADMIN /REPLICATE
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL

Sample output from the REPADMIN /SHOWREPL command follows. This output shows incoming replication
from DC_2_Name to DC_1_Name failing with the "Access is denied" error.

Site_Name\DC_1_Name
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: GUID
DSA invocationID: invocationID

==== INBOUND NEIGHBORS======================================

DC= DomainName,DC=com
Site_Name\DC_2_Name via RPC
DSA object GUID: GUID
Last attempt @ Date Time failed, result 5(0x5):
Access is denied.
<#> consecutive failure(s).
Last success @ Date Time.

Symptom 4
NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService events with the five
status are logged in the Directory Services log in Event Viewer.

The following table summarizes Active Directory events that frequently cite the 8524 status.

ﾉ Expand table

Event Source Event string

ID

1655 NTDS Active Directory tried to communicate with the following global catalog and the attempts
General were unsuccessful.

1925 NTDS KCC The attempt to establish a replication link for the following writable directory partition
failed.

1926 NTDS KCC The attempt to establish a replication link to a read-only directory partition with the
following parameters failed.

Symptom 5
When you right-click the connection object from a source domain controller in Active Directory Sites
and Services and then select Replicate Now, the process fails, and you receive the following error:
 Replicate Now

The following error occurred during the attempt to synchronize naming context %directory
partition name% from Domain Controller Source DC to Domain Controller Destination DC: Access
is denied.

The operation will not continue.

The following screenshot represents a sample of the error:

Workaround
Use the generic DCDIAG command-line tool to run multiple tests. Use the DCDIAG
/TEST:CheckSecurityErrors command-line tool to perform specific tests. (These tests include an SPN
registration check.) Run the tests to troubleshoot Active Directory operations replication failing with
error 5 and error 8453. However, be aware that this tool does not run as part of the default execution of
DCDIAG.

To work around this issue, follow these steps:

1. At command prompt, run DCDIAG on the destination domain controller.

2. Run DCDIAG /TEST:CheckSecurityError .
3. Run NETDIAG.
4. Resolve any faults that were identified by DCDIAG and NETDIAG.
5. Retry the previously failing replication operation.If replications continue to fail, see the "Causes
and solutions" section.

Causes and solutions

The following causes may result in error 5. Some of them have solutions.

Cause 1: The RestrictRemoteClients setting in the registry has a

value of 2
If the Restrictions for Unauthenticated RPC clients policy setting are enabled and is set to Authenticated
without exceptions, the RestrictRemoteClients registry value is set to a value of 0x2 in the
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC registry subkey.
This policy setting enables only authenticated remote procedure call (RPC) clients to connect to RPC
servers that are running on the computer on which the policy setting is applied. It doesn't allow for
exceptions. If you select this option, a system can't receive remote anonymous calls by using RPC. This
setting should never be applied to a domain controller.

Solution

1. Disable the Restrictions for Unauthenticated RPC clients policy setting that restricts the
RestrictRemoteClients registry value to 2.

７ Note

The policy setting is located in the following path: Computer Configuration\Administrative

Templates\System\Remote Procedure Call\Restrictions for Unauthenticated RPC clients

2. Delete the RestrictRemoteClients registry setting, and then restart.

See Restrictions for Unauthenticated RPC Clients: The group policy that punches your domain in the
face .

Cause 2: The CrashOnAuditFail setting in the registry of the

destination domain controller has a value of 2
A CrashOnAduitFail value of 2 is triggered if the Audit: Shut down system immediately if unable to log
security audits policy setting in Group Policy is enabled and the local security event log becomes full.

Active Directory domain controllers are especially prone to maximum-capacity security logs when
auditing is enabled and the size of the security event log is constrained by the Do not overwrite events
(clear log manually) and Overwrite as needed options in Event Viewer or their Group Policy
equivalents.

Solution

） Important

Follow the steps in this section carefully. Serious problems might occur if you modify the registry
incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

1. Clear the security event log, and save it to an alternative location as required.
2. Reevaluate any size constraints on the security event log. This includes policy-based settings.
3. Delete and then re-create a CrashOnAuditFail registry entry as follows:Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
Value Name: CrashOnAuditFail
Value Type: REG_DWORD
Value Data: 1
4. Restart the destination domain controller.
Cause 3: Invalid trust
If Active Directory replication fails between domain controllers in different domains, you should verify
the health of trust relationships along the trust path.

You can try the NetDiag Trust Relationship test to check for broken trusts. The Netdiag.exe utility
identifies broken trusts by displaying the following text:

Trust relationship test. . . . . . : Failed

Test to ensure DomainSid of domain 'domainname' is correct.
[FATAL] Secure channel to domain 'domainname' is broken.
[% variable status code %]

For example, if you have a multi-domain forest that contains a root domain ( Contoso.COM ), a child
domain ( B.Contoso.COM ), a grandchild domain ( C.B.Contoso.COM ), and a tree domain in same forest
( Fabrikam.COM ) and if replication is failing between domain controllers in the grandchild domain
( C.B.Contoso.COM ) and the tree domain ( Fabrikam.COM) , you should verify trust health between
C.B.Contoso.COM and B.Contoso.COM , between B.Contoso.COM and Contoso.COM , and then finally

between Contoso.COM and Fabrikam.COM .

If a shortcut trust exists between the destination domains, you don't have to validate the trust path
chain. Instead, you should validate the shortcut trust between the destination and source domain.

Check for recent password changes to the trust by running the following command:

Console

Repadmin /showobjmeta * <DN path for TDO in question>

Verify that the destination domain controller is transitively inbound replicating the writable domain
directory partition where trust password changes may take effect.

Commands to reset trusts from the root domain PDC are as follows:

Console

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT

/PasswordO:* /Reset /TwoWay

Commands to reset trusts from the child domain PDC are as follows:

Console

netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child

/PasswordO:* /Reset /TwoWay

Cause 4: Excessive time skew

Kerberos policy settings in the default domain policy allow for a five-minute difference in system time
(this is the default value) between KDC domain controllers and Kerberos target servers to prevent
replay attacks. Some documentation states that the system time of the client and that of the Kerberos
target must be within five minutes of one another. Other documentation states that, in the context of
Kerberos authentication, the time that is important is the delta between the KDC that is used by the
caller and the time on the Kerberos target. Also, Kerberos doesn't care whether the system time on the
relevant domain controllers matches current time. It cares only that the relative time difference between
the KDC and target domain controller is within the maximum time skew that Kerberos policy allows.
(The default time is five minutes or less.)

In the context of Active Directory operations, the target server is the source domain controller that is
contacted by the destination domain controller. Every domain controller in an Active Directory forest
that is currently running the KDC service is a potential KDC. Therefore, you have to consider time
accuracy on all other domain controllers against the source domain controller. This includes time on the
destination domain controller itself.

You can use the following two commands to check time accuracy:

DCDIAG /TEST:CheckSecurityError
W32TM /MONITOR

You can find sample output from DCDIAG /TEST:CheckSecurityError in the "More information" section.
This sample shows excessive time skew on Windows Server 2003-based and Windows Server 2008 R2-
based domain controllers.

Look for LSASRV 40960 events on the destination domain controller at the time of the failing
replication request. Look for events that cite a GUID in the CNAME record of the source domain
controller with extended error 0xc000133. Look for events that resemble the following:

The time at the Primary Domain Controller is different than the time at the Backup Domain
Controller or member server by too large an amount

Network traces that capture the destination computer that connects to a shared folder on the source
domain controller (and also other operations) may show the "An extended error has occurred" on-
screen error, but a network trace displays the following:

-> KerberosV5 KerberosV5:TGS Request Realm: <- TGS request from source DC
<- Kerberosvs Kerberosvs:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- TGS response where
"KRB_AP_ERR_TKE_NYV
<- maps to "Ticket not yet valid" <- maps to "Ticket not yet valid"

The TKE_NYV response indicates that the date range on the TGS ticket is newer than the time on the
target. This indicates excessive time skew.

７ Note

W32TM /MONITOR checks time only on domain controllers in the test computers domain, so
you have to run this in each domain and compare time between the domains.
 When the time difference is too great on Windows Server 2008 R2-based destination domain
controllers, the Replicate now command in DSSITE.MSC fails with the "There is a time and / or
date difference between the client and the server" on-screen error. This error string maps to
error 1398 decimal or 0x576 hexadecimal with the ERROR_TIME_SKEW symbolic error name.

For more information, see Setting Clock Synchronization Tolerance to Prevent Replay Attacks .

Cause 5: There's an invalid security channel or password mismatch

on the source or destination domain controller
Validate the security channel by running one of the following commands:

nltest /sc:query
netdom verify

On condition, reset the destination domain controller's password by using NETDOM /RESETPWD.

Solution

1. Disable the Kerberos Key Distribution Center (KDC) service on the domain controller that is
restarted.

2. From the console of the destination domain controller, run NETDOM RESETPWD to reset the password
for the destination domain controller as follows:

Console

c:\>netdom resetpwd /server: server_name /userd: domain_name\administrator

/passwordd: administrator_password

3. Make sure that likely KDCs and the source domain controller (if these are in the same domain)
inbound replicate knowledge of the destination domain controller's new password.

4. Restart the destination domain controller to update Kerberos tickets and retry the replication
operation.

See How to use Netdom.exe to reset machine account passwords of a domain controller .

Cause 6: The "Access this computer from network" user right isn't
granted to a user who triggers replication
In a default installation of Windows, the default domain controller policy is linked to the domain
controller's organization unit (OU). The OU grants the Access this computer from network user right to
the following security groups:

ﾉ Expand table
 Local policy Default domain controller policy

Administrators Administrators

Authenticated Users Authenticated Users

Everyone Everyone

Enterprise Domain Controllers Enterprise Domain Controllers

[Pre-Windows 2000 compatible Access] Pre-Windows 2000 compatible Access

If Active Directory operations fail with error 5, you should verify the following points:

Security groups in the table are granted the Access this computer from network user right in the
default domain controller's policy.
Domain controller computer accounts are located in the domain controller's OU.
The default domain controller's policy is linked to the domain controller's OU or to alternative
OUs that are hosting computer accounts.
Group Policy is applied on the destination domain controller that currently logs error 5.
The Deny access this computer from network user right is enabled or doesn't reference direct or
transitive groups that the security context being used by the domain controller or user account
that triggering replication.
Policy precedence, blocked inheritance, Microsoft Windows Management Instrumentation (WMI)
filtering, or the like, isn't preventing the policy setting from applying to domain controller role
computers.

７ Note

Policy settings can be validated with the RSOP.MSC tool. However, GPRESULT /Z is the
preferred tool because it's more accurate.
Local policy takes precedence over policy that is defined in sites, domains, and the OU.
At one time, it was common for administrators to remove the "Enterprise domain controllers"
and "Everyone" groups from the "Access this computer from network" policy setting in the
default domain controller's policy. However, removing both groups is fatal. There's no reason
to remove "Enterprise domain controllers" from this policy setting, because only domain
controllers are a member of this group.

Cause 7: There's an SMB signing mismatch between the source and

destination domain controllers

ﾉ Expand table

Policy setting Registry path

Microsoft HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
network client:
Digitally sign
 Policy setting Registry path

communications
(if server agrees)

Microsoft HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
network client:
Digitally sign
communications
(always)

Microsoft HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
network server:
Digitally sign
communications
(if server agrees)

Microsoft HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature
network server:
Digitally sign
communications
(always)

You should focus on SMB signing mismatches between the destination and source domain controllers.
The classic cases involve a setting that is enabled or required on one side but disabled on the other.

Cause 8: UDP-formatted Kerberos packet fragmentation

Network routers and switches may fragment or completely drop large User Datagram Protocol (UDP)-
formatted network packets that are used by Kerberos and Extension Mechanisms for DNS (EDNS0).
Computers that are running Windows 2000 Server or Windows Server 2003 operating system families
are especially vulnerable to UDP fragmentation on computers that are running Windows Server 2008 or
Windows Server 2008 R2.

Solution

1. From the console of the destination domain controller, ping the source domain controller by its
fully qualified computer name to identify the largest packet supported by the network route. To
do this, run the following command:

Console

c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472

2. If the largest non-fragmented packet is less than 1,472 bytes, try one of the following methods (in
order of preference):

Change the network infrastructure to appropriately support large UDP frames. This may
require a firmware upgrade or configuration change on routers, switches, or firewalls.
Set maxpacketsize (on the destination domain controller) to the largest packet identified by
the PING -f -l command less 8 bytes to account for the TCP header, and then restart the
changed domain controller.
 Set maxpacketsize (on the destination domain controller) to a value of 1 This triggers
Kerberos authentication to use a TCP. Restart the changed domain controller to make the
change take effect.

3. Retry the failing Active Directory operation.

Cause 9: Network adapters have the Large Send Offload feature

enabled
Solution

1. On the destination domain controller, open network adapter properties.

2. Click the Configure button.
3. Select the Advanced tab.
4. Disable the IPv4 Large Send Offload property.
5. Restart the domain controller.

Cause 10: Invalid Kerberos realm

The Kerberos realm is invalid if one or more of the following conditions are true:

The KDCNames registry entry incorrectly contains the local Active Directory domain name.
The PolAcDmN registry key and the PolPrDmN registry key don't match.

Solutions

） Important

Follow the steps in this section carefully. Serious problems might occur if you modify the registry
incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

Solution for the incorrect KDCNames registry entry

1. On the destination domain controller, run REGEDIT.

2. Locate the following subkey in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains

3. For each <Fully_Qualified_Domain> under the subkey, verify that the value for the KdcNames
registry entry refers to a valid external Kerberos realm and not to the local domain or another
domain in the same Active Directory forest.

Solution for mismatching PolAcDmN and PolPrDmN registry keys

７ Note

This method is valid only for domain controllers that are running Windows 2000 Server.
 1. Start Registry Editor.

2. In the navigation pane, expand Security.

3. On the Security menu, click Permissions to grant the Administrators local group full control of the
SECURITY hive and its child containers and objects.

4. Locate the following subkey in the registry:

HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN

5. In the right-side pane of Registry Editor, click the No Name: REG_NONE registry entry one time.

6. On the View menu, click Display Binary Data.

7. In the Format section of the dialog box, click Byte.

The domain name is displayed as a string on the right side of the Binary Data dialog box. The
domain name is the same as the Kerberos realm.

8. Locate the following subkey in the registry:

HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN

9. In the right-side pane of Registry Editor, double-click the No Name: REG_NONE entry.

10. In the Binary Editor dialog box, paste the value from the PolPrDmN registry subkey. (The value
from the PolPrDmN registry subkey is the NetBIOS domain name).

11. Restart the domain controller.If the domain controller isn't functioning correctly, see other
methods .

Cause 11: There's a LAN Manager Compatibility (LM Compatibility)

mismatch between the source and destination domain controllers

Cause 12: Service principal names are either not registered or not
present because of simple replication latency or a replication failure

Cause 13: Antivirus software uses a mini-firewall network adapter

filter driver on the source or destination domain controller

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies
to" section.

More information
Active Directory errors and events such as those described in the "Symptoms" section can also fail with
error 8453 together with the following, similar error string:
 Replication Access was denied.

The following situations can cause Active Directory operations to fail with error 8453. However, these
situations don't cause failures with error 5.

Naming context (NC) head isn't permitted with the Replicating Directory Changes permission.
The security principal starting replication isn't a member of a group that is granted the Replicating
Directory Changes permission.
Flags are missing in the UserAccountControl attribute. These include the
SERVER_TRUST_ACCOUNT flag and the TRUSTED_FOR_DELEGATION flag.
The read-only domain controller (RODC) is joined in the domain without the ADPREP /RODCPREP
command running first.

Sample output from DCDIAG /TEST:CheckSecurityError

Sample DCDIAG /test:CHECKSECURITYERROR output from a Windows Server 2008 R2 domain
controller follows. This output is caused by excessive time skew.

Doing primary tests Testing server: <Site_Name>\<Destination_DC_Name> Starting test:

CheckSecurityError
Source DC <Source DC> has possible security error (1398).
Diagnosing...
Time skew error between client and 1 DCs! ERROR_ACCESS_DENIED
or down machine received by:
<Source DC> [<Source DC>] DsBindWithSpnEx() failed with error 1398,
There is a time and/or date difference between the client and server..
Ignoring DC <Source DC> in the convergence test of object
CN=<Destination_DC>,OU=Domain Controllers,DC=<DomainName>,DC=com, because we
cannot connect!
......................... <Destination_DC> failed test CheckSecurityError

Sample DCDIAG /CHECKSECURITYERROR output from a Windows Server 2003-based domain controller
follows. This is caused by excessive time skew.

Doing primary tests

Testing server: <Site_Name>\<Destination_DC_Name>
Starting test: CheckSecurityError
Source DC <Source DC>has possible security error (5). Diagnosing...
Time skew error between client and 1 DCs! ERROR_ACCESS_DENIED or down machine recieved by:
<Source DC>
Source DC <Source DC>_has possible security error (5). Diagnosing...
Time skew error: 7205 seconds different between:.
<Source DC>
<Destination_DC>
[<Source DC>] DsBindWithSpnEx() failed with error 5,
Access is denied..
Ignoring DC <Source DC>in the convergence test of object CN=<Destination_DC>,OU=Domain
 Controllers,DC=<DomainName>,DC=com, because we cannot connect!
......................... <Destination_DC>failed test CheckSecurityError

Sample DCDIAG /CHECKSECURITYERROR output follows. It shows missing SPN names. (The output
could vary from environment to environment.)

Doing primary tests

Testing server: <site name>\<dc name>
Test omitted by user request: Advertising
Starting test: CheckSecurityError
* Dr Auth: Beginning security errors check'
Found KDC <KDC DC> for domain <DNS Name of AD domain> in site <site name>
Checking machine account for DC <DC name> on DC <DC Name>
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<DNS domain name>
* Missing SPN :LDAP/<hostname>.<DNS domain name>
* Missing SPN :LDAP/<hostname>
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<NetBIOS domain name>
* Missing SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>
* SPN found :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest
root domain DNS name>
* Missing SPN :HOST/<hostname>.<DNS domain name>/<DNS domain name>
* SPN found :HOST/<hostname>.<DNS domain name>
* SPN found :HOST/<hostname>
* Missing SPN :HOST/<hostname>.<DNS domain name>/<NetBIOS domain name>
* Missing SPN :GC/<hostname>.<DNS domain name>/<DNS domain name> Unable to verify the
machine account (<DN path for Dc machine account>) for <DC Name> on <DC name>.

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following
the steps mentioned in Gather information by using TSS for Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8333: Directory Object Not Found
Article • 02/19/2024

This article describes an issue where Active Directory Replications fail with error 8333:
Directory object not found (ERROR_DS_OBJ_NOT_FOUND).

Applies to: Windows Server 2012 R2

Original KB number: 2703708

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft Community .

Symptoms
This article describes the symptoms, cause, and resolution steps when Active Directory
replication fails with error 8333: Directory object not found
(ERROR_DS_OBJ_NOT_FOUND).

1. Possible formats for the error include:

ﾉ Expand table

Decimal Hex Symbolic Error string

8333 0x208d ERROR_DS_OBJ_NOT_FOUND Directory object not found.

2. The following events could be logged

ﾉ Expand table

Event Event Event String

Source ID

NTDS 2108 This event contains REPAIR PROCEDURES for the 1084 event that has
Replication previously been logged. This message indicates a specific issue with
the consistency of the Active Directory database on this replication
destination. A database error occurred while applying replicated
changes to the following object. The database had unexpected
 Event Event Event String
Source ID

contents, preventing the change from being made. Object:

OU=TestOU,DC=contoso,DC=com Object GUID: <GUID> Source
domain controller: A52b57e3-92b9-4264-822b-
72963eaf1030._msdcs.contoso.com Additional Data Primary Error
value: 8333 Directory object not found. Secondary Error value: -1601
JET_errRecordNotFound, The key was not found

2031 The DS Service Configuration object is not found. It might have been
NTDS accidentally deleted. The Active Directory will be able to operate
General normally, but you will not be able to set certain service parameters,
such as LDAP limits, default query policies, and SPN mappings. DS
Service Configuration object: CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=contoso,DC=com Error: 8333
(Directory object not found.) User Action: Try to restore the DS
Service Configuration object.

3. There may be output from repadmin /replsum

DC-1-03 03h:14m:11s 1 / 52 1 (8333) Directory object not found.

DC-2-01 03h:13m:39s 1 / 26 3 (8333) Directory object not found.
DC-3-09 03h:08m:45s 2 / 103 1 (8333) Directory object not found.
DC-4-03 03h:05m:52s 1 / 13 7 (8333) Directory object not found.

4. DCPromo may fail while promoting a new domain controller and you'll see the
following errors in the DCPROMO log

<DateTime> [INFO] Creating new domain users, groups, and computer objects
<DateTime> [INFO] Error - Active Directory is missing critical information after
installation and cannot continue. If this is a replica domain controller, rejoin
this server to the domain. (8333)
<DateTime> [INFO] NtdsInstall for contoso.com returned 8333
<DateTime> [INFO] DsRolepInstallDs returned 8333
<DateTime> [ERROR] Failed to install to Directory Service (8333)

７ Note

Error 8333 translates to ERROR_DS_OBJ_NOT_FOUND or "Directory object not

found."

5. While trying to rehost a partition on the Global catalog

 repadmin /rehost \<dc-name>\<partition to rehost>\<good source>

repadmin /rehost failed with DsReplicaAdd failed with status 8333 (0x208d)

Cause
The error status 8333 "Directory Object Not Found" has multiple root causes including:

1. Database corruption with additional associated errors logged in the event log of
the source domain controller:

ﾉ Expand table

Source Event Description

ID

NTDS Replication 2108 This event contains REPAIR PROCEDURES for the
1084 event that has previously been logged. This
message indicates a specific issue with the
consistency of the Active Directory Domain Services
database on this replication destination. A database
error occurred while applying replicated changes to
the following object. The database had unexpected
contents, preventing the change from being
made.Object:
CN=chduffey,OU=IT,OU=Corp,DC=contoso,DC=com
Object GUID: <GUID>
Source domain controller: c4efaf4e-d652-4630-
8623-afec5ebc8532._msdcs.contso.comAdditional
Data
Primary Error value: 8333 Directory Object Not
Found.

NTDS General 1168 Error -1073741790(c0000022) has occurred (Internal

ID 3000b3a). Please contact Microsoft Product
Support Services for assistance.

Microsoft-Windows- 1084 Internal event: Active Directory could not update the
ActiveDirectory_DomainService following object with changes received from the
following source domain controller. This is because
an error occurred during the application of the
changes to Active Directory on the domain
controller.

NTDS Replication 1699 The local domain controller failed to retrieve the
changes requested for the following directory
partition. As a result, it was unable to send the
change requests to the domain controller at the
 Source Event Description
ID

following network address. 8446 The replication

operation failed to allocate memory

Additionally you may see replication status code:

ﾉ Expand table

Code Sources Additional Information

8451 Repadmin, DcPromo, as subcode Refer to the troubleshooting guide for 8451 in
in Database Corruption Events the first instance if this error is identified.

2645996

2. Lingering Objects with associated errors logged:

ﾉ Expand table

Source Event Description

ID

NTDS 1988 Active Directory Replication encountered the existence of objects in

Replication the following partition that have been deleted from the local domain
controllers (DCs) Active Directory database. Not all direct or
transitive replication partners replicated in the deletion before the
tombstone lifetime number of days passed. Objects that have been
deleted and garbage collected from an Active Directory partition but
still exist in the writable partitions of other DCs in the same domain,
or read-only partitions of global catalog servers in other domains in
the forest are known as "lingering objects".

NTDS 1388 Another domain controller (DC) has attempted to replicate into this
Replication DC an object that's not present in the local Active Directory
database. The object may have been deleted and already garbage
collected (a tombstone lifetime or more has past since the object
was deleted) on this DC. The attribute set included in the update
request isn't sufficient to create the object. The object will be re-
requested with a full attribute set and re-created on this DC.

Additionally you may see the following replication status codes:

ﾉ Expand table
 Source Sources Description

8606 Repadmin, DCPromo, sub Refer to the troubleshooting guide for 8606 in
code in NTDS Replication the first instance if this error is identified.
events 2028495

1722 Repadmin, DCPromo, sub Refer to the troubleshooting guide for 1722 in
code in NTDS Replication the first instance if this error is identified.
events 2102154

3. Conflict Objects

4. Third-Party process
a. Antivirus
b. Directory synchronization software

Resolution
Investigation of the 8333 "Directory Object Not Found" error message should begin on
the source domain controller in the replication partnership. Referring to each of the
possible causes of the issue from the "cause" section of this document, a support
professional should begin their investigation on the source of the source/destination
replication partnership.

1. Check for indications of Active Directory (JET) Database corruption:

a. Review the Directory Services event log on the source and destination
replication partners for JET database corruption events. Possible events include:

ﾉ Expand table

Source Event Description

ID

NTDS Replication 2108 This event contains REPAIR PROCEDURES for the
1084 event that has previously been logged. This
message indicates a specific issue with the
consistency of the Active Directory Domain Services
database on this replication destination. A database
error occurred while applying replicated changes to
the following object. The database had unexpected
contents, preventing the change from being
made.Object:
CN=chduffey,OU=IT,OU=Corp,DC=contoso,DC=com
Object GUID: <GUID>
Source domain controller: c4efaf4e-d652-4630-
 Source Event Description
ID

8623-afec5ebc8532._msdcs.contso.comAdditional
Data
Primary Error value: 8333 Directory Object Not
Found.

NTDS General 1168 Error -1073741790(c0000022) has occurred (Internal

ID 3000b3a). Please contact Microsoft Product
Support Services for assistance.

Microsoft-Windows- 1084 Internal event: Active Directory could not update the
ActiveDirectory_DomainService following object with changes received from the
following source domain controller. This is because
an error occurred during the application of the
changes to Active Directory on the domain
controller.

NTDS Replication 1699 The local domain controller failed to retrieve the
changes requested for the following directory
partition. As a result, it was unable to send the
change requests to the domain controller at the
following network address. 8446 The replication
operation failed to allocate memory

Additionally you may see replication status code:

ﾉ Expand table

Code Sources Additional Information

8451 Repadmin, DcPromo, as Refer to the troubleshooting guide for 8451

subcode in Database Corruption in the first instance if this error is identified.
Events
2645996

b. Enable advanced directory services replication logging:

） Important

This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
added protection, back up the registry before you modify it. Then, you can
restore the registry if a problem occurs. For more information about how to
back up and restore the registry, click the following article number to view
 the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

To increase NTDS diagnostic logging, change the following REG_DWORD values

in the registry of the destination domain controller under the following registry
key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Set the value of the following subkeys to 5:

5 Replication Events
9 Internal Processing
Note Level 5 logging is extremely verbose and the values of both subkeys
should be set back to the default of 0 after the problem is resolved. Filtering the
Directory Services event log should be performed to isolate and identify these
events.

c. Review the event logs for the new events that were generated from the
increased logging for error values that will give a definitive view of the Database
Corruption.

d. If database corruption has been detected, ensure that recent backups exist of
each domain in the forest.

e. Restart the domain controller reporting the database corruption in directory

services restore mode. (Press F8 while the server is restarting or if this isn't
possible open msconfig.exe and choose "Active Directory Repair" in the "boot"
options.).

f. To perform an inspection of the database in Directory Services Restore Mode:

i. Open a command prompt
ii. Type "ntdsutil"
iii. Type "activate instance ntds"
iv. Type "Semantic database analysis"
v. Type "go"

If errors are detected they'll be displayed to the console and written to a log file
in the current working directory.

g. If database corruption errors are detected, you're advised to contact Microsoft

Support Services.

h. As a last option. You can demote the domain controller, and promote it again to
replace the database and replicate the contents from another server in the
domain.
 ７ Note

If an Active Directory database has been corrupted in your environment,

it's important to consider the source of the corruption to avoid issues in
the future. Some of the known causes of such corruption are:
i. Failing Hardware: Hard Disk or controller
ii. Caching: Hard Disk controller
iii. Out-dated Drivers: Hard Disk controller
iv. Out-dated Firmware: BIOS, Hard Disk controller, Hard Disk
v. Sudden power Loss

2. Check for the existence of and remove Lingering Objects on all domain controllers
in the forest.
There are multiple approaches to check for Lingering Objects including:

a. Check for the existence of the following Directory Services events on domain
controllers in the forest:

ﾉ Expand table

Source Event Description

ID

NTDS 1988 Active Directory Replication encountered the existence of objects

Replication in the following partition that have been deleted from the local
domain controllers (DCs) Active Directory database. Not all direct
or transitive replication partners replicated in the deletion before
the tombstone lifetime number of days passed. Objects that have
been deleted and garbage collected from an Active Directory
partition but still exist in the writable partitions of other DCs in
the same domain, or read-only partitions of global catalog
servers in other domains in the forest are known as "lingering
objects".

NTDS 1388 Another domain controller (DC) has attempted to replicate into
Replication this DC an object that's not present in the local Active Directory
database. The object may have been deleted and already garbage
collected (a tombstone lifetime or more has past since the object
was deleted) on this DC. The attribute set included in the update
request isn't sufficient to create the object. The object will be re-
requested with a full attribute set and re-created on this DC.

Additionally you may see the following replication status codes:

 ﾉ Expand table

Code Sources Additional Information

8451 Repadmin, DcPromo, as Refer to the troubleshooting guide for 8451

subcode in Database Corruption in the first instance if this error is identified.
Events
2645996

b. Use repldiag.exe to examine the forest for lingering objects.

Repldiag may be downloaded from codeplex.com. To perform the lingering

object check-in advisory mode, use the syntax:

repldiag /RemoveLingeringObjects/AdvisoryMode

Directory Service event 1942 will be logged on each domain controller and will
indicate the number of lingering objects that were detected in each directory
partition.

The work being performed by repldiag may also be performed with the built-in
directory services replication tool: Repadmin.exe.

For support professionals preferring to use repadmin.exe, the partial command

will be Repadmin /removelingeringobjects . Repldiag.exe provides an advantage
over Repadmin.exe in that it can be used to search all directory partitions, on all
servers in the forest with a single command.

If Lingering objects are detected:

i. Perform a system state backup of two domain controllers in each domain in
the forest.
ii. Use repldiag.exe to perform clean-up of lingering objects:
repldiag /RemoveLingeringObjects
iii. Each domain controller will log a directory services event 1942 for each
directory services partition to indicate if lingering objects have been
removed.

For an alternate approach to the removal of lingering objects, you can use the
built-in tool Repadmin.exe with the /removelingeringobjects switch. This approach
requires multiple commands, repldiag provides an aggregate of the commands
Repadmin.exe would use.

3. Check for the existence of and remove conflict objects:

a. Search the relevant directory partitions for CNF-managed objects and the object
that the conflict-mangled object conflicted with the following syntax:
 repadmin /showattr localhost "dc=parent,dc=com" /subtree /filter:"((&
(objectClass=*)(cn=*\0acnf:*)))" /atts:objectclass,whencreated,whenchanged

In this example "dc=parent,dc=com" is the distinguished name for the parent.com

domain.

In most circumstances the 8333 error will indicate which directory partition(s)
should be evaluated for conflict objects. It's recommended that the configuration
partition is checked in all instances:

repadmin /showattr localhost "cn=configuration,dc=parent,dc=com" /subtree

/filter:"((&(objectClass=*)(cn=*\0acnf:*)))"

/atts:objectclass,whencreated,whenchanged

b. Review the attributes, attribute values and if present, subordinate objects to

determine which object should remain and which should be deleted

c. Ensure you have an up-to-date backup of the directory

d. Delete the conflict mangled object/container or the object it conflicted with

using LDP.EXE, ADSIEDIT or one of the Active Directory management tools.

4. Perform testing of the replication partners with third-party components removed.

Multiple third-party products have been found to cause this issue including:
a. Anti-Virus software
b. Directory Synchronization

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

More information
Lingering Objects:

Clean that Active Directory forest of lingering objects

Database Corruption:

Event ID 1539—Database integrity

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8477: The replication request has been
posted; waiting for reply
Article • 02/19/2024

This article describes an issue where Active Directory Replications fail with error 8477:
"The replication request has been posted; waiting for reply".

Applies to: Windows Server 2012 R2

Original KB number: 2758780

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Symptoms
This article describes the symptoms, cause, and resolution steps involved in
troubleshooting Active Directory Replication error 8477: "The replication request has
been posted; waiting for reply".

The symptoms discussed in this article are commonly related to the occurrence of event
8477, however may also be observed with other events related to slow or delayed
replication. When troubleshooting such issues, consideration should be given to all
factors that may cause replication delays and be remediated accordingly.

Output from repadmin.exe /showreps /verbose may

report the replication attempt has failed with error 8477 -
"The replication request has been posted; waiting for
reply"
DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
DSA object GUID: <source DCs ntds settings object object guid>
Address: <source DCs ntds settings object object guid>._msdcs.Contoso.Com
 DSA invocationID: <source DCs NTDS DB invocation id>
DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES
NO_CHANGE_NOTIFICATIONS PREEMPTED
USNs: 1158544/OU, 111052/PU
Last attempt @ <Date Time> was delayed for a normal reason, result 8477 (0x211d):
The replication request has been posted; waiting for reply.
Last success @ <Date Time>

Output from repadmin.exe /queue may report a large

number of queued inbound replication requests and an
unprecedentedly long execution time
Repadmin /queue
repadmin running command /queue against server localhost

Queue contains 26 items.

Current task began executing at <Date Time>.
Task has been executing for 86 minutes, 12 seconds.

[6485] Enqueued <Date Time> at priority 590

SYNC FROM SOURCE
NC DC=Contoso,DC=com
DC Default-First-Site-Name\DomainController
DC object GUID <source DCs ntds settings object object guid>
DC transport addr <source DCs ntds settings object object
guid>._msdcs.Contoso.com
ASYNCHRONOUS_OPERATION WRITEABLE PERIODIC NEVER_NOTIFY PREEMPTED

７ Note

The occurrence of event 8477 when inbound replication requests are queuing is
generally observed following a preempted replication task. This event is indicated
by event 8461 - The replication operation was preempted.

When using dcdiag.exe, initialization of a recently

promoted Domain Controller may be delayed, awaiting
the completion of an initial synchronization
Directory Server Diagnosis
 Performing initial setup:
Trying to find home server...
Home Server = DomainController
The directory service on DomainController has not finished initializing.
In order for the directory service to consider itself synchronized, it must
attempt an initial synchronization with at least one replica of this
server's writeable domain. It must also obtain Rid information from the Rid
FSMO holder.
The directory service has not signalled the event which lets other services
know that it is ready to accept requests. Services such as the Key
Distribution Center, Intersite Messaging Service, and NetLogon will not
consider this system as an eligible domain controller.
* Identified AD Forest.
Done gathering initial info.
The directory service on BOULDERDC01 has not finished initializing.
In order for the directory service to consider itself synchronized, it must
attempt an initial synchronization with at least one replica of this
server's writeable domain. It must also obtain Rid information from the Rid
FSMO holder.
The directory service has not signalled the event which lets other services
know that it is ready to accept requests. Services such as the Key
Distribution Center, Intersite Messaging Service, and NetLogon will not
consider this system as an eligible domain controller.
Done gathering initial info.

７ Note

The output from dcdiag.exe described above is normal behavior during the
promotion of a new, replica domain controller into an environment. The occurrence
of 8477 in this case should be given time to clear through normal replication cycles
before remedial activities being considered or conducted.

When using dcdiag.exe, the 'Replications' test case may

issue a 'REPLICATION LATENCY WARNING'
Starting test: Replications
REPLICATION LATENCY WARNING
DomainController: A long-running replication operation is in progress
The job has been executing for 84 minutes and 22 seconds.
 Replication of new changes along this path will be delayed.
This is normal for a new connection, or for a system that has been down a long time.
Enqueued <Date Time> at priority 90
Op: SYNC FROM SOURCE
NC DC=Contoso,DC=com
DSADN <source DCs ntds settings object object guid>

DSA transport addr <source DCs ntds settings object object

guid>._msdcs.Contoso.com
......................... DomainController passed test Replications

'NTDS Replication' event 1580 may be logged in the

directory service event log

ﾉ Expand table

Event Event Event String

Source ID

NTDS 1580 A long-running Active Directory Domain Services inbound replication task
Replication has finished with the following parameters.
Elapsed time (minutes):
84
Operation:
Synchronize Replica
Options:
0x21000051
Parameter 1:
DC=Contoso,DC=com
Parameter 2:
<source DCs ntds settings object object guid>
Parameter 3:

Parameter 4:

A long-running replication task may also occur when a system has been
unavailable or a directory partition has been unavailable for an extended
period of time. A long running replication task may indicate a large
number of updates, or a number of complex updates occurring at the
source directory service. Doing these updates during non-critical times
may prevent replication delays.

A long running replication task is normal in the case of adding a new

directory partition to Active Directory Domain Services. This can occur
because of a new installation, global catalog promotion, or a connection
generated by the Knowledge Consistency Checker (KCC).
 Event Event Event String
Source ID

Additional Data
Error value:
The operation completed successfully.

Cause
The 8477 (The replication request has been posted; waiting for reply) status is
informational and represents normal Active Directory replication operation, indicating
that replication is currently in progress from the source and hasn't yet been applied to
the destination Domain Controllers database replica.

The presence of this event for an extended period may, however, may be indicative of
issues with Active Directory Replication on the Destination Domain Controller. Possible
causes may include:

1. Low Available Physical Memory, High Latency or Low-Bandwidth Network Links,

Excessive CPU Utilization or Disk I/O for the amount of data that the domain
controller is replicating
2. High rate of change for objects in Active Directory Domain Services (AD DS)
3. Third-Party utilities that may hamper or delay normal replication function
4. Large Groups (Greater than 5000 Members) where Linked-value Replication isn't
enabled
5. A recent modification to the Active Directory Schema where a sizeable number of
schema attributes have been modified or indexed

Resolution
Investigation of replication error 8477 should be conducted, at least initially, on the
Destination Domain Controller within the replication partnership. The resolution section
of this article will discuss techniques an Active Directory Administrator should use to
resolve the possible causes for error 8477 as per the "Cause" section.

Low Available Physical Memory, High Latency or Low-

Bandwidth Network Links, Excessive CPU Utilization or
Disk I/O for the amount of data that the domain
controller is replicating
Active Directory Domain Controllers should be configured with as few additional roles
and applications as possible, ideally a Domain Controller should be a single purpose
server used only to service queries and authentication requests. When troubleshooting
Active Directory performance issues, it's often best to first analyze the system for any
additional applications, services, or tasks that are unnecessary or redundant.

As an initial step, an IT Professional should check Task Manager (and Resource Monitor
where appropriate) for overall CPU and Memory usage to determine if it's
uncharacteristically high or deviates from a predefined baseline. If no baseline exists,
Microsoft Best Practice suggests that sustained and repeated CPU usage greater than
80% would be considered high and should be investigated further.

Troubleshooting High CPU Usage on a Domain Controller - Troubleshooting High CPU

Usage on a Domain Controller

Regarding disk usage, on Active Directory Domain Controllers the Ntds.dit and edb.log
files should be the most active files on the system. To determine whether this is the case,
performance logging and analysis (as per the below) should be conducted.

Low Bandwidth, High Latency, or Busy Network Connectivity may also cause error 8477
to occur on Active Directory Domain Controllers. Network Performance data metrics
should be collected from a Domain Controller utilizing Performance Monitor, Network
Monitor, or other such tools. Guidance around monitoring and measuring replication
traffic is detailed in Active Directory Replication Traffic .

For Windows Server 2003 based Domain Controllers:

An IT Professional may choose to use Performance Monitor with Processor, Physical
Disk, Network Interface, and Directory Services counters added to determine and
investigate performance issues on the system. Instead, Server Performance Advisor may
reduce the complexity in analyzing performance metrics obtained from Performance
Monitor. The tool is a free download and will look at CPU, Network, Memory, and Disk
I/O giving detail around overall utilization and a determination as to whether the
performance data is seen as idle, normal, or potentially problematic.

For Windows Server 2008 and above based Domain Controllers:

Performance Monitor in Windows Server 2008 and later includes the key functionality of
Server Performance Advisor straight out of the box. Within the System Data Collector
Sets, the Active Directory Diagnostics set will, similarly to Server Performance Advisor,
produce a report with key metrics for Active Directory Performance investigation and
provide warnings for uncharacteristic behavior on Active Directory Domain Controllers.
Any warnings are included at the top of the report an example of which is below:
 ﾉ Expand table

WARNING

Symptom: The system is experiencing excessive paging

Cause: Available memory on the system is low.

Details: The total physical memory on the system is not capable of handling the load.

Resolution: Upgrade the physical memory or reduce system load

Related: Memory Diagnosis

Symptom: On directory servers, Ntds.dit and Edb.log should be the most active files. In this
case, C:\Windows\NTDS\ntds.dit has the highest I/O rate (84.622 operations/sec).

High rate of change for objects in Active Directory

Domain Services (AD DS)
In a busy Active Directory Environment, a large number of changes may occur to objects
between each scheduled replication. If this is expected within the environment, all
aspects of the organizations infrastructure should be sized appropriately to ease
effective replication.

In the event that an IT Administrator isn't aware or not expecting a large number of
changes and is receiving error 8477, investigation should be conducted to determine
what changes are occurring in the environment and whether these are expected or the
result of an issue with an application or service. An effective means for performing this
task is to determine what objects are changing through the use of the uSNChanged
attribute, the highest uSNChanged value on a specific Domain Controller represents the
High-Watermark USN.

Running repadmin /showreps /verbose against a domain controller with event 8477
being displayed will show the current High-Watermark and is followed by /OU:

DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
DSA object GUID: <source DCs ntds settings object object guid>
Address: <source DCs ntds settings object object guid>._msdcs.Contoso.Com
DSA invocationID: <source DCs NTDS DB invocation id>
DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES
NO_CHANGE_NOTIFICATIONS PREEMPTED
USNs: 1158544/OU, 111052/PU
 Last attempt @ <Date Time> was delayed for a normal reason, result 8477 (0x211d):
The replication request has been posted; waiting for reply.
Last success @ <Date Time>

Depending on the number of changes occurring, the highest USN present on a Domain
Controller may increment quickly, to determine the objects that are being updated, it's
suggested that on the Source Replication Partner, the below command is run for the
relevant Naming Context:

Repadmin /showattrDomainControllerNameDC=Contoso,DC=com /subtree /filter:"

(uSNChanged>=highestcommitedusn)" /atts:objectclass

Specific Applications or Services, such as the Exchange Recipient Update Service may
make regular changes to Active Directory Attributes and may need to be tuned if
resulting replication traffic is unmanageable.

Third-Party utilities that may hamper or delay normal

replication function
Third-Party applications should be configured and tuned around performance and
supportability best practices. Certain applications, if not configured around best
practices for Active Directory Performance, may cause impact to normal Active Directory
Domain Controller function.

Applications of note include (but aren't limited to):

a. Virus Scanning Software

b. Monitoring Agents
c. Identity Synchronization and Management Applications
d. Backup Software and Agents
Virus scanning recommendations for Enterprise computers that are running currently
supported versions of Windows

Large Groups (Greater than 5000 Members) where

Linked-value Replication isn't enabled
Linked-value replication isn't available in Windows 2000 Server forests. Because an
originating update must be written in a single database transaction, and because the
practical limit for a single transaction is 5,000 values, membership of more than 5,000
values isn't supported in Windows 2000 Server Active Directory. A group of this size
represents a limitation both for the database write operation that is required to record a
change to an attribute of that size and the transfer of that much data over the network.
This is different in forests at Windows 2003 or higher functional level where linked-
valued replication (LVR) for group memberships is enabled.

When a Domain is upgraded from a 2000 functional level, the memberships of any
groups carried are considered legacy and can still cause replication issues:

1. Forests before the 2003 functional level should divide the groups into smaller
groups that don't exceed 5,000 members. Group nesting can also be used,
providing the applications and services using the groups can support it.

2. Forests at the 2003 functional level can remove and reinstate group members to
make them LVR-enabled. Over time, as security principals are added and removed
from groups, the members are slowly enabled for LVR Note: Events 1479 and 1519
are also commonly logged in the Directory Service Event Log when large groups
are causing replication issues and delays.

Using repadmin /showobjmeta legacy members in a group can be determined and

converted to LVR enabled members if necessary to resolve the issue, these users are
denoted with 'Type' of value LEGACY:

repadmin /showobjmeta DomainControllerName

"CN=Administrators,CN=Builtin,DC=Contoso,DC=Com"

3 entries.
Type Attribute Last Mod Time Originating DSA Loc.USN Org.USN Ver
======= ============ ============= =================
======= ======= ===
Distinguished Name
=============================
PRESENT member <Date Time> Default-First-Site-Name\DomainController 8203
8203 1
CN=Administrator,CN=Users,DC=Contoso,DC=Com
PRESENT member <Date Time> Default-First-Site-Name\DomainController 12398
12398 1
CN=Enterprise Admins,CN=Users,DC=Contoso,DC=Com
PRESENT member <Date Time> Default-First-Site-Name\DomainController 12378
12378 1
CN=Domain Admins,CN=Users,DC=Contoso,DC=Com
LEGACY member <Date Time> Default-First-Site-Name\DomainController 198458
198458 1 CN=mjordan,CN=Users,DC=Contoso,DC=Com
A recent modification to the Active Directory Schema
where a sizeable number of schema attributes have been
modified or indexed
Attribute definitions are stored in attributeSchema objects in the schema directory
partition. Changes to attributeSchema objects block other replication until the schema
changes are done. During replication of any directory partition other than the schema
directory partition, the replication system first checks to see whether the schema
versions of the source and the destination domain controllers are in agreement. If the
versions aren't the same, the replication of the other directory partition is rescheduled
until the schema directory partition is synchronized.

Modification of the schema through the use of LDIFDE or customized binaries included
with applications (that is, Microsoft Exchange, Operations Manager, and so on) may add
indexed attributes to the schema directory partition. Depending on the size of the
update, replication delays can be caused in large databases.

In cases such as these, the 8477 state may appear as a transient issue and should be
expected to self-resolve once the higher priority schema updates are successfully
replicated and all other replication catches up on backlogged changes within the
directory.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

More information
How the Active Directory Replication Model Works

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot change the replication scope
of an Active Directory integrated DNS
zone in Windows Server 2003
Article • 02/19/2024

This article provides a solution to an error that occurs when you change the replication
scope of an Active Directory integrated domain name system (DNS) zone.

Applies to: Windows Server 2003

Original KB number: 842560

Symptoms
When you try to change the replication scope of an Active Directory integrated DNS
zone, you may receive an error that is similar to the following error message:

The replication scope could not be set.

There was a server failure.

Cause
This issue may occur if the system account does not have the SeSecurityPrivelige
permission that is provided by the built-in administrator account.

Resolution
To resolve this issue, you must add the built-in administrators group account to the
manage auditing and security log user permission. The manage auditing and security
log user permission is located in the default domain controller policy. After you add the
built-in administrators group account, change the replication scope of the required DNS
zone.

To add the built-in administrators group account to the manage auditing and security
log user permission, follow these steps:

1. Start the Active Directory Users and Computers snap-in.

2. Right-click the Domain Controllers container, and then click Properties.
3. Click the Group Policy tab, and then click Edit.
 4. In the left pane, expand Windows Settings, and then expand Security Settings.
5. Expand Local Policies, and then click User Rights Assignment.
6. In the right pane, double-click Manage auditing and security log, and then click
Add User or Group.
7. Click Browse, and then click Advanced.
8. Click Find Now, and then click Administrators in the Search Results box.
9. Click OK, click OK, click OK, and then click OK to quit Group Policy Object Editor.
10. On the File menu, click Exit.
11. Click OK.
12. Quit the Active Directory Users and Computers snap-in.
13. Change the replication scope of the Active Directory integrated DNS zone.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Deleting Active Directory objects that
have many links causes replication
failures
Article • 02/19/2024

This article provides a workaround for an issue that occurs when you delete Active
Directory objects that contain many forward links.

Applies to: Windows Server 2012 R2

Original KB number: 3149779

Summary
This article discusses an issue that occurs when you delete Active Directory objects that
contain many forward links. Here are some common examples:

Group memberships (the member attribute)

Roaming user credentials (the ms-PKI-AccountCredentials attribute)
Read-only domain controller (RODC) exposed user links (the mds-revealedusers
attribute)

The number of links where you start seeing problems may be as low as 50,000. On a
single object, there may be several millions of links.

The registry key that is discussed in this article should be applied only to domain
controllers (DCs) and Lightweight Directory Services (LDS) servers that are experiencing
the issue that is described in the "Symptoms" section. This issue is likely to occur on
Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 DCs. By
following the recommendations that are given here, you may decrease Active Directory
replication performance but increase the reliability of correctly processing the deletion
of such large objects.

Symptoms
When you delete Active Directory objects that contain many forward links, you may
encounter replication failure. For example, you delete groups with large membership
sets, or you demote and then delete RODC computer accounts that have many links to
users accounts that have their password exposed on the RODC.
The following conditions are the key indicators that this solution applies to the issue:

The forest functional level is Windows Server 2003 or later version of Windows
Server, so link value replication is used.

Event 2094 (replication delay) occurs several times, referencing the same deleted
object.

Events 1083 and 1955 (Write conflict) are logged in close time proximity to the
logging of the 2094 event referencing the same deleted object.

The affected domain controller (DC) may also report that the version store is
exhausted (Event ID 623). Exhaustion of version store doesn't always occur in this
scenario. Other factors that increase the likelihood of version store exhaustion
include a high rate of changes to Active Directory objects, both local and
replicated, as well as other long running operations such as deep queries.

Active Directory replication fails with error 8409, error "A database error has
occurred", or other events cite related status codes that are mentioned in the
following table:

ﾉ Expand table

Hex Decimal Symbolic Friendly

000020D9 8409 ERROR_DS_DATABASE_ERROR A database error has occurred

If the Active Directory recycle bin is enabled, the replication errors may not occur
for 60 to 180 days (deleted object lifetime) after the object is deleted. The issues
occur when the object transitions from the deleted status to the recycled status.

Event log entries

When the issue occurs, the following events are logged:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2094
Task Category: Replication
Level: Warning
Keywords: Classic
Description: Performance warning: replication was delayed while applying changes
to the following object. If this message occurs frequently, it indicates that the
replication is occurring slowly and that the server may have difficulty keeping up
with changes.
Object DN: <object name>
Object GUID: <object GUID>
Partition DN: DC=contoso,DC=com
Server: xxxx-xxxx-xxxx-xxxx-xxxxxxx._msdcs.contoso.com
Elapsed Time (secs): 11
User Action
A common reason for seeing this delay is that this object is especially large, either in
the size of its values, or in the number of values. You should first consider whether
the application can be changed to reduce the amount of data stored on the object,
or the number of values. If this is a large group or distribution list, you might
consider raising the forest functional level to Windows Server 2003 or greater, since
this will enable replication to work more efficiently. You should evaluate whether the
server platform provides sufficient performance in terms of memory and processing
power. Finally, you may want to consider tuning the Active Directory Domain
Services database by moving the database and logs to separate disk partitions.
If you wish to change the warning limit, the registry key is included below. A value
of zero will disable the check.
Additional Data
Warning Limit (secs): 10
Limit Registry Key: System\CurrentControlSet\Services\NTDS\Parameters\Replicator
maximum wait for update object (secs)
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1083
Task Category: Replication
Level: Warning
Keywords: Classic
Description:
Active Directory Domain Services could not update the following object with
changes received from the directory service at the following network address
because Active Directory Domain Services was busy processing information.
Object: <object name>
Network address: xxxxx-xxxx-xxxx-xxxx-xxxxxxx._msdcs.contoso.com
This operation will be tried again later.
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1955
Task Category: Replication
 Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Description: Active Directory Domain Services encountered a write conflict when
applying replicated changes to the following object.
Object: <object name>
Time in seconds: 48
Event log entries preceding this entry will indicate whether or not the update was
accepted.
A write conflict can be caused by simultaneous changes to the same object or
simultaneous changes to other objects that have attributes referencing this object.
This commonly occurs when the object represents a large group with many
members, and the functional level of the forest is set to Windows 2000. This conflict
triggered additional retries of the update. If the system appears slow, it could be
because replication of these changes is occurring.
User Action
Use smaller groups for this operation or raise the forest functional level to Windows
Server 2003.

More information
By default, when you delete an Active Directory object that has an exceptionally large
number of forward and backward links, 10,000 links are deleted at a time. During this
time, if other threads update the target objects of these links, the link deletion
transaction is suspended until the objects are available again. This suspension can cause
the whole deletion transaction to take a long time to finish. During this time, other
replication tasks are held up by this long-running task. For example, you may notice that
passwords and group membership updates aren't progressing throughout the forest.

While this update is pending, admins may see write conflicts and transaction failure
events. Also, as additional objects are processed by replication, more and more version
store is allocated because the pending large transaction doesn't release its allocated
versions store until the deletion transaction is finished. This can cause version store
errors and replication warnings events.

７ Note

Garbage collection isn't related to the processing of group membership link

deletions.
Decreasing TSL isn't a valid method of accelerating link deletions.
 The legacy value for Links process batch size is 1,000 in versions before
Windows Server 2008 R2. In later versions, the batch size is increased to
10,000 to improve the performance of undeleting in forests that have the
Recycle Bin enabled.
Check values of the Links process batch size parameter. If it's nondefault, set
the value back to its default or an even smaller value such as 1,000 or 100.

Smaller values decrease version store usage by deleting a smaller number of

objects per deleting thereby reducing the total time to perform a single delete
transaction. This has the positive side effect of reducing version store and time
window for write conflicts while you increase the time that's required to accurately
reflect the group membership in the directory.

Active Directory services check for the following registry key.

For AD DS:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Links process
batch size

For AD LDS:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<adam

instance>\Parameters\Links process batch size

Type: DWORD
Min Value: 100
Max Value: 10000

This value overrides the default value of 10,000 as the number of atomic links to process
at one time. You don't have to restart the NTDS or LDS instance service, or restart the
computer to make the setting effective.

After each atomic operation, the corresponding version store is released. The version
store is reacquired only during the next atomic operation that continues to process the
same object. You may have second thoughts about turning down the link batch size by a
great degree. You can combine it with an increase of the ESE version store. If maybe for
a reason that you have increased version store, you may decide to increase version store
some more or not decrease the Links process batch size value so much.

For more information, see the following articles:

The Version Store Called, and They're All Out of Buckets

 The domain controller runs slower or stops responding when the garbage
collection process runs

Workaround
To work around this issue, set the value of Links process batch size lower than 10,000.
This decreases the potential for an object access collision to occur. By doing this, you
make the replication process of large object deletion more reliable. Also, it now takes a
longer time to complete the whole transaction. This also helps you avoid version store
depletion.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

References
For more information, see the following articles:

Introduction to credential roaming

Introduction to Read-Only DCs

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Changes to security groups or
distribution groups are not replicated to
destination domain controllers when
you use link value replication in a
Windows Server 2003 environment
Article • 02/19/2024

This article provides a solution to an issue where changes that are made to security
groups or distribution groups aren't replicated to destination domain controllers when
you use link value replication.

Applies to: Windows Server 2012 R2

Original KB number: 958838

Symptoms
Consider the following scenario. In a Windows Server 2003 environment, you set the
forest functional level in the forest to Windows Server 2003 or to a later version of
Windows. You do this to apply link value replication (LVR) changes to group
membership on LVR-enabled attributes. In this scenario, you may experience the
following symptoms:

Changes to the security group or distribution group that exists on the source
domain controller aren't replicated to the destination domain controllers. You
experience this symptom when the group membership change is initiated either by
an administrator or by a program.

When you run the repadmin /showreps command, you receive a message that
states that a Windows Server 2008-based or Windows Server 2003-based
destination domain controller can't replicate inbound changes to a directory
partition from one or more source domain controllers. In this situation, you also
receive a Win32 error 8451.

７ Note

Win32 error 8451 corresponds to the ERROR_DS_DRA_DB_ERROR error and to

the following description:
 The replication operation encountered a database error.

The affected Windows Server 2008-based or Windows Server 2003-based

destination domain controller may not replicate inbound changes that are made to
read-only partitions from global catalogs or from domain controllers that are
hosting writable directory partitions.

Windows Server 2008-based and Windows Server 2003-based destination domain

controllers log events in the Directory Service log.

７ Note
NTDS general event 1173 indicates a generic replication failure.
The additional data error value -1603 maps to a Currency not on a record
jet error and to the symbolic name errNoCurrentRecord. The misspelling of
currently in the Currency not on a record error text.
Exception e0010004 corresponds to error DSA_DB_EXCEPTION.
Internal ID 2050344 corresponds to a function in the database layer code
of NTDS. This number depends on the operating system, on the service
pack, and on the patching revisions.

Windows Server 2008-based and Windows Server 2003-based destination domain

controllers log the Directory Service event 1692.

７ Note

This event is logged when you enable diagnostic logging and set the value for
the 5 Replication Events registry entry to 1 or greater.

For more information about NTDS diagnostic logging, see How to configure Active
Directory and LDS diagnostic event logging.

These symptoms may occur when changes are made to any LVR-replicated object class
that has forward links. (These changes to the LVR-replicated object class are also to the
changes that are made to security and distribution groups.)

Cause
This issue occurs if Windows Server 2008-based or Windows Server 2003-based
destination domain controllers stop inbound replication when they receive LVR updates
of objects that don't exist in their local copies of Active Directory.

Specifically, this issue may occur if the following conditions are true:

Membership changes that are made to lingering security or distribution groups on

source domain controllers are outbound-replicated by using link value replication
(LVR) to destination domain controllers that don't have an instance of the group
that is being modified. For example, this issue may occur when an object is
deleted, and the lifetime of the tombstone objects has expired from the local copy
of Active Directory.

The forest functional level is set to Windows Server 2003 Interim mode or a later
version.

The lingering security or distribution groups reside on either read-only or writable

partitions of Windows Server 2003-based or Windows Server 2008-based source
domain controllers, and replication stops between the source and destination
domain controllers.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

To resolve this issue, follow these steps:

1. Run the following repadmin command on the primary domain controller (PDC) to
create a .csv file that contains the list of destination domain controllers:

Console

repadmin /showrepl * /csv >showrepl.csv

 2. Open the .csv file in Excel, and then identify replication failures on destination
domain controllers that have failed the incoming replication process and that
display Win32 error 8451.

3. On the domain controllers that log the "Win32 error 8451" error message, make
sure that diagnostic logging for the 5 Replication Events registry entry is set to a
value of 1. To do this, follow these steps:

a. Click Start, and then click Run.

b. In the Open box, type regedit, and then click OK.

c. Locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

d. In the details pane, double-click 5 Replication Events, type 1 in the Value data
box, and then click OK.

e. Close Registry Editor.

4. On the destination domain controllers, verify that Directory Service event 1692 is
logged in the Directory Service log. The event displays changes to the member
attribute of the security group or to other LVR-replicated attributes and to the
lingering object GUIDs.

5. Remove the lingering objects from the Windows Server 2008-based or Windows
Server 2003-based destination domain controllers by using the repadmin
/removelingeringobjects command.

） Important

Disabling strict replication consistency functionality in the registry of Windows

Server 2008-based or Windows Server 2003-based destination domain controllers
does not resume replication. You must not set the value of the Strict Replication
Consistency registry entry to 0 to unblock replication of directory partitions.

Do not force replication of directory partitions on source domain controllers by

using the repadmin /sync command or an equivalent command together with the
/force switch.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DCDiag VerifyReferences test fails when
you use DFSR to replicate SYSVOL
Article • 02/19/2024

This article provides a solution to an error that occurs when you use the Distributed File
System Replication (DFSR) service to replicate the sysvol folder.

Applies to: Windows Server 2012 R2

Original KB number: 3110032

Symptoms
Consider the following scenario:

You use the Distributed File System Replication (DFSR) service to replicate the
sysvol folder.
All domain controllers (DC) are running Windows Server 2008 R2 or a later version.
You run the Domain Controller Diagnostics Tool (DCDiag) to generate a report
about the replication.

In this scenario, DCDiag returns the following error message:

failed test VerifyReferences

The DCDiag report contains the following entry:

Console

Problem: Missing Expected Value

Base Object: CN=<DCNAME>,OU=Domain Controllers,DC=<DOMAIN>,DC=<COM>
Base Object Description: "DC Account Object"
Value Object Attribute Name: frsComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862

When this problem occurs, DCDiag validates the reference object for DFSR. Also, the NT
File Replication Service (NTFRS) stops.

Cause
This problem occurs because there's no File Replication Service (FRS) reference in the
Active Directory database under the domain controller object when DFSR is used for
sysvol replication. Instead, there's only an object for DFSR.

This logic isn't included in earlier versions of DCDiag, such as DCDiag for Windows
Server 2008 or DCDiag installed together with Windows Server 2003 Support Tools. So
these versions search for the FRS member reference, and it generates a false error in
DCDiag.

Resolution
To resolve this problem, run Dcdiag.exe from %windir%\System32 . This folder contains
the latest version of DCDiag in Windows 2008 and Windows 2008 R2. By running the
latest version of DCDiag, the sysvol replication will pass the VerifyReferences test.

Instead, if the Windows Support Tools suite is installed on Windows Server 2008 R2,
uninstall it. Which resolves the problem and lets you run Dcdiag.exe from any location.

More information
Even if you use the latest DCDiag releases, the error that is mentioned in the Symptoms
section may still occur if the msDFSR-Flags attribute in the CN=
<DCNAME>,OU=Domain Controllers,DC=<DOMAIN>,DC=<COM> line in the DCDiag
entry is missing or doesn't match one of the following flags:

Redirected phase: msDFSR-Flags on CN=dfsr-LocalSettings is 0x20 (32 dez)

Eliminated phase: msDFSR-Flags on CN=dfsr-LocalSettings is 0x30 (48 dez)

In this case, DCDiag assumes falsely that the File Replication Service (FRS) is still
configured for SYSVOL, and it tries to verify FRS objects and attributes in an Active
Directory database that doesn't exist. So you can expect the verification to fail.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Diagnose Active Directory replication
failures
Article • 02/19/2024

This article describes how to diagnose Active Directory replication failures.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2498185

Symptoms
You may notice that Active Directory fails to replicate in the following conditions:

The Repadmin monitoring tool exposes replication failures.

Administrators, users, or applications detect that objects that are created and
changed in Active Directory don't exist on all domain controllers (DCs) in a
common replication scope.

Cause
Active Directory Domain Services (AD DS) replication has the following dependencies:

Network connectivity over the ports and protocols that are used by the ADDS
service
DNS name resolution to resolve the name of a replication partner to its IP address
Authentication and authorization
Time accuracy within 5 minutes to support Kerberos authentication
The directory database
The Active Directory replication topology to build connection objects between
replication partners
The ADDS replication engine

Resolution
Use either of the following methods to view replications errors:

Download and run the Microsoft Support and Recovery Assistant tool .

Read the replication status in the repadmin /showrepl output.

 Repadmin is part of Remote Server Administrator Tools (RSAT). If you're using

Windows 10, version 1803 or an earlier version of Windows, download Remote

Server Administration Tools (RSAT) .

In Windows 10, version 1809 and later version of Windows 10, you can install
the RSAT feature through Settings > Manage optional features.

Use repadmin to identify forest-wide Active Directory

replication errors
You can create a Microsoft Excel spreadsheet for domain controllers by using the
repadmin/showrepl command to view replication errors. To do it, follow these steps:

1. Open a Command Prompt as an administrator:

On the Start menu, right-click Command Prompt, and then select Run as
administrator. If the User Account Control dialog box appears, provide Enterprise
Admins credentials, and then select Continue.

2. At the command prompt, type the following command, and then press Enter:

Console

repadmin /showrepl * /csv >showrepl.csv

3. In Excel, open showrepl.csv.

4. Format the spreadsheet as follows:

a. Hide or delete column A and column G.
b. Select row 1 underneath the column header row. On the View tab, select Freeze
Panes > Freeze Top Row.
c. Select the whole spreadsheet. On the Data tab, select Filter.
d. In the Last Success Time column, select the down arrow, point to Text Filters,
and then select Custom Filter.
e. Sort the table from oldest to newest.
f. In the Source DC or Source DSA column, select the filter down arrow, point to
Text Filters, and then select Custom Filter.
g. In the Custom AutoFilter dialog box, under Show rows where, select does not
contain. In the adjacent text box, type del to eliminate deleted domain
controllers from the view.
h. Repeat step 6 for the Last Failure Time column, but use the value does not
equal, and then type the value 0.
 5. To fix any replication failures that appear under Last Failure Status, see How to
troubleshoot common Active Directory replication errors .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to disable the Knowledge
Consistency Checker from automatically
creating replication topology
Article • 02/19/2024

This article describes how to disable the Knowledge Consistency Checker from
automatically creating replication topology.

Applies to: Windows Server 2012 R2

Original KB number: 242780

Summary
The Knowledge Consistency Checker (KCC) is a Microsoft Windows 2000 and Microsoft
Windows Server 2003 component that automatically generates and maintains the intra-
site and inter-site replication topology. You can disable the KCC's automatic generation
of intra-site or inter-site topology management, or both.

More information
In some situations you may want to manually create replication connections to tailor the
replication topology, but this increases the workload for monitoring for changes in the
network topology described in Active Directory or replication failures occurring on
domain controllers.

The KCC runs at regular intervals to adjust the replication topology for changes that
occur in Active Directory, such as adding new domain controllers and new sites that are
created. At the same time, the KCC reviews the replication status of existing connections
to determine if any connections are not working. If a connection is not working, after a
threshold is reached, KCC automatically builds temporary connections to other
replication partners (if available) to insure that replication is not blocked.

７ Note

When automatic replication topology management is disabled, the failover

detection mentioned above is also disabled.
You can use the Ldp.exe tool that is included in the Windows 2000 or Windows Server
2003 Resource Kit to perform Lightweight Directory Access Protocol (LDAP) searches
against Active Directory for specific information given search criteria. This also lets you
query data that is otherwise not visible using the administrative tools included in
Windows 2000. However, all information that is returned in LDP queries is subject to
security permissions.

How to Modify Active Directory to Disable KCC for a Site

1. Run Setup.exe (if it is not already installed) from the Support\Tools folder of the
Windows 2000 or Windows Server 2003 CD-ROM. This installs the Support Tools
Kit.

2. Run Ldp.exe

3. On the Connection menu, click Connect.

4. Type the server name of a domain controller in the enterprise, verify that the port
setting is 389, click to clear the connectionless check box, and then click OK. After
the connection is complete, server-specific data is displayed in the right pane.

5. On the Connection menu, click Bind. Type the user name, password, and domain
name (in DNS format) in the appropriate boxes (you may need to click to select the
Domain check box), and then click OK. If the binding is successful, you should
receive a message in the right pane that is similar to the following example:
Authenticated as dn: YourUserID

6. On the View menu, click Tree.

7. In the BaseDN box, type the distinguished name of the site object in the
configuration container of the forest. For example, for the Default-First-Site-Name
site in the Mydomain.com forest, the domain name would look like the following
example:
CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM

If this object is located, LDP should display the object in the left pane.

8. Expand the view. One of the child objects should begin with CN=NTDS Site
Settings. Double-click this object. In the right pane, LDP should output the current
settings for the attributes for this object. Each attribute is preceded by a number
and then an angle bracket (>). The number represents the number of values the
attribute contains.
 9. Look for the "options" attribute. If it is not present, this is normal and makes
modifying the value easier.

７ Note

If the "options" attribute is present and the value is not 0, you need to
determine the current flags that are set and use the values below to construct
the new value before continuing to the next step.

10. In the right-hand pane, locate the beginning of the output for the NTDS Site
Settings object. It looks similar to the following example:

Expanding base 'CN=NTDS Site Settings,CN=Default-First-Site-

Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM'...
Result <0>: (null)
Matched DNs:
Getting 1 entry:
>> Dn: CN=NTDS Site Settings,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM

11. Copy the string of data from the ">> Dn" portion of the LDP output.

12. On the Browse menu, click Modify. In the Dn box, paste the string you copied in
the previous step.

13. In the Attribute box, type options.

14. In the Values box, type the appropriate value:

To disable automatic intra-site topology generation, use value 1 (decimal).

To disable automatic inter-site topology generation, use value 16 (decimal).
To disable both intra-site and inter-site topology generation, use value 17
(decimal).

15. In the Operation box, click Replace, click Enter, and then click Run.

16. In the right pane, the output should look similar to the following example if the
operation is successful:

***Call Modify... ldap_modify_s(ld,'CN=NTDS Site Settings,CN=Default-First-

Site-Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM',[1] attrs);
Modified "CN=NTDS Site Settings,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM".
 ７ Note

To re-enable KCC generation, delete the value that you entered in step 14 in this
section.

To determine if these values are set correctly, you can use Active Directory Replication
Monitor (also included with the Support Tools installation) to generate a report on the
site configuration. Included in this information is output similar to the following
example:

Site Name: Default-First-Site-Name

---------------------------------------
Site Options: NTDSSETTINGS_OPT_IS_AUTO_TOPOLOGY_DISABLED
NTDSSETTINGS_OPT_IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED
Site Topology Generator: CN=NTDS Settings,CN=ESTAD-
CESSNA,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=ifr,DC=com
Site Topology Renewal:
Site Topology Failover:

７ Note

NTDSSETTINGS_OPT_IS_AUTO_TOPOLOGY_DISABLED means that intra-site

topology management is disabled, and
NTDSSETTINGS_OPT_IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED means that inter-
site topology management is disabled.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Duplicate Active Directory replication
connections are created
Article • 02/19/2024

This article provides a solution to an issue where duplicate Active Directory replication
connections are created for one or more domain controllers across one or more sites.

Applies to: Windows Server 2012 R2

Original KB number: 3207569

Symptoms
In Active Directory Sites and Services, duplicate Active Directory replication connections
are created for one or more domain controllers across one or more sites.

Cause
This issue is caused by either a lack of network connectivity or by another problem that
disrupts replication on the Intersite Topology Generator (ISTG) in the site. If the ISTG
can't reach other domain controllers, it tries to create new (duplicate) Active Directory
replication connections for domain controllers in the same site.

７ Note

If this is a transient condition, nothing will clean up the duplicate connection

objects. If the connectivity and replication problem is no longer occurring on the
ISTG, you must manually delete the duplicate connection objects and then rerun
repadmin /kcc against the ISTG to make sure that the duplicates are not re-created.

Data collection
To collect the relevant data for this issue, follow these steps.

７ Note

Repadmin /kcc <DCNAME> is the command to force KCC to run. However it

won't create a new connection if the other one is still in place.

 Replace <DCNAME> with the name of the domain controller that serves as the

ISTG for the site.

1. Run repadmin /showconn <DCNAME> >showconn.txt .

2. Run repadmin /failcache <DCNAME> >failcache.txt .
3. Run PortQRYUI on <DCNAME>, and target a remote domain controller that you
have duplicate connections with, as follows:
"Domains and Trusts test" File / Save Result
4. On <DCNAME>, run repadmin /bind RemoteDC (from step 3). For example:
repadmin /bind RemoteDC1

5. If repadmin /bind fails to connect, take a network trace by using netsh on both
domain controllers, as follows:
a. Run netsh trace start capture=yes tracefile=c:\%computername%.etl .
b. Run repadmin /bind <DCNAME> .
c. Connect by using the FQDN instead of the host name, if possible.
d. Run netsh trace stop .
6. Run repadmin /showrepl * /csv >showrepl.csv .
7. Run repadmin /viewlist * >DCs.txt .
8. Run repadmin /istg >istg.txt .

Resolution
To resolve this issue, open ports in the site to allow the ISTG to connect to the domain
controllers. After the connectivity issue is resolved, delete the duplicate connection
objects, and then rerun KCC on the ISTG.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

More information
For more information about this issue, see How Active Directory replication topology
works. Particularly focus on the KCC and topology generation section and the "Excluded
nonresponding servers" subtopic.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to get and use the Active Directory
Replication Status Tool
Article • 02/19/2024

） Important

As of June 2nd, 2023, the Active Directory Replication Status Tool is no longer
available for download. The following article is provided for historical purposes
only.

This article introduces the Active Directory Replication Status Tool (ADREPLSTATUS). This
tool helps administrators identify, prioritize, and fix Active Directory replication errors on
a single domain controller (DC) or any DCs in an Active Directory domain or forest.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4469274

Features
Auto-discovery of the DCs and domains in the Active Directory forest to which the
computer that is running ADREPLSTATUS is joined.
"Errors only" mode lets administrators focus only on DCs that report replication
failures. For more information, see below.
When ADREPLSTATUS detects replication errors, the tool relies on its integration
with resolution content on Microsoft TechNet to display the resolution steps for
the top AD replication errors. For more information, see below.
Rich sorting and grouping of result output by clicking any single column header
(sort) or by dragging one or more column headers to the filter bar. Use one or
both options to arrange output by last replication error, last replication success
date, source DC naming context, replication success date, and so on.
Export replication status data so that it can be imported and viewed by source
domain admins, destination domain admins, or support professionals in Microsoft
Excel or ADREPLSTATUS.
Choose which columns that you want displayed and their display order. These
settings are saved as a preference on the ADREPLSTATUS computer.

７ Note
 ADREPLSTATUS is a read-only tool and makes no changes to the configuration of,
or objects in, an Active Directory forest.

More information
The ADREPLSTATUS user interface consists of a toolbar and Microsoft Office-style ribbon
to expose different features. The Replication Status Viewer tab displays the replication
status for all DCs in the forest. The following screenshot shows ADREPLSTATUS
highlighting a DC that hasn't replicated in Tombstone Lifetime number of days
(identified here by the black color-coding).

Error only
By using the Errors Only button (upper-right of image below), you can filter out healthy
DCs to focus on destination DCs that are reporting replication errors:
Replication error analysis
The Replication Error Guide has a Detected Errors Summary view that records each
unique replication error that occurs on the set of DCs that are targeted by the
administrator.

Selecting any of the replication error codes loads the recommended troubleshooting
content for that error. For example, the following is a screenshot for when the TechNet
Article for Active Directory Replication Error 1256 is displayed:
The goals for this tool are to help administrators identify and fix Active Directory
replication errors before they cause user and application failures or outages, or lingering
objects cause short or long-term replication failures, and to give administrators more
insight into the operation of Active Directory replication in their environments.

The current version of ADREPLSTATUS as of this posting is 2.2.20717.1 (as reported on

ADREPLSTATUS startup splash screen).

Known issues
ADREPLSTATUS won't work when the following security setting is enabled in
Windows - System cryptography: Use FIPS 140 compliant cryptographic algorithms,
including encryption, hashing and signing algorithms.
An additional check mark appears at the bottom of the column chooser when you
right-click a column header.

７ Note

The ADRPLSTATUS tool is supported by the Microsoft ADREPLSTATUS team.

Administrators and support professionals who experience errors installing or
executing ADREPLSTATUS can submit a problem report .
 For known issues, the ADREPLSTATUS team will report the status at the same page.
If your issue requires additional investigation, the ADREPLSTATUS team will contact
you at the email address that you provided in your problem report.

The time that's needed to provide a solution depends on the team's workload as
well as problem complexity and cause. Code defects in the ADREPLSTATUS tool can
typically be resolved relatively quickly. Tool failures due to external causes may take
longer, unless a workaround can be found.

The ADREPLSTATUS team can't fix Active Directory replication errors that are
identified by the ADREPLSTATUS tool. Contact your support provider to fix the
issue. You may also submit and research replication errors at this TechNet
Windows Server forum .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

List of currently available hotfixes for
Distributed File System (DFS) technologies in
Windows Server 2012 and Windows Server 2012
R2
Article • 02/19/2024

This article lists the hotfixes that are currently available for users who have installed Distributed File
System (DFS) technologies on a Windows Server 2012-based computer or a Windows Server 2012 R2-
based computer.

Applies to: Windows Server 2012 R2

Original KB number: 2951262

Summary
This Microsoft Knowledge Base articles that are listed in this article describe the available fixes. If you have
installed DFS technologies on a Windows Server 2012-based computer or a Windows Server 2012 R2-
based computer, we recommend that you review and install the hotfixes that are described in More
information.

Note. The two technologies in DFS are DFS Namespaces (DFS-N) and DFS Replication (DFS-R).

A servicing approach of installing the monthly rollups provides customers with a consistent model for
staying current and secure. You may substitute a more recent monthly rollup for an older monthly rollup.
The remainder of the updates in this list are still required because some components in those updates
were released prior to October 2016 and aren't included in a more recent monthly rollup. For more
information about this servicing approach, see Simplified servicing for Windows 7 and Windows 8.1: the
latest improvements .

Windows Server 2012 R2

You can get the latest fixes for these DFS components by installing the following updates:

KB 4056895: January 8, 2018-KB4056895 (Monthly Rollup) or later

KB 2996883: DFSR stops replication after an unexpected shutdown in a Windows 8.1 or Windows
Server 2012 R2 environment
KB 3000850: November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server
2012 R2
KB 3046481: DFS Namespaces deployment causes slow access or access time-out when you access
DFS share in Windows Server 2012 R2

Windows Server 2012

You can get the latest fixes for these DFS components by installing the following updates:
 KB 4025331: July 11, 2017-KB4025331 (Monthly Rollup) or later
KB 2884176: Large backlogs on Windows -based DFSR servers
KB 2962407: Windows RT, Windows 8, and Windows Server 2012 update rollup: June 2014

More information

７ Note

Some of the following tables contain blank cells to accommodate information that will be supplied
later.

DFS namespaces

Windows Server 2012 R2

ﾉ Expand table

Date Knowledge Title Why we recommend Hotfix type and availability

added Base article this hotfix

April 4056895 January 8, 2018- This monthly rollup Included in January 3, 2018-
15, KB4056895 (Monthly contains the KB4056898 (Security-only
2020 Rollup) 6.3.9600.18895 version update) .Included in January 8,
of Dfsc.sys. (client-side). 2018-KB4056895 (Monthly Rollup)
and later monthly rollups.

Mar 06, 3046481 DFS Namespaces This hotfix contains the To install this update, you must
2015 deployment causes slow most current version of have Windows Server 2012 R2
access or access time-out Dfssvc.exe for Windows installed.
when you access DFS Server 2012 R2.
share in Windows Server
2012 R2.

Windows Server 2012

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and availability
added Base article

April 3192406 October 2016 This monthly rollup contains the Included in October 2016
15, Preview of Monthly 6.2.9200.21968 version of Dfssvc.exe Preview of Monthly Quality
2020 Quality Rollup for and the 6.2.9200.21976 version of Rollup for Windows Server
Windows Server Dfsc.sys for Windows Server 2012. 2012 and later monthly
2012 rollups.

DFS replication
Windows Server 2012 R2

ﾉ Expand table

Date Knowledge Title Why we recommend this Hotfix type and

added Base article hotfix availability

April 15, 4038774 September 19, 2017- This monthly rollup contains Included in September 19,
2020 KB4038774 (Preview of the 6.3.9600.18776 version of 2017-KB4038774 (Preview
Monthly Rollup) Dfsrs.exe for Windows Server of Monthly Rollup) and
2012 R2. later monthly rollups.

Not This hotfix contains the most To install this hotfix, you
applicable current version of Dfsrro.sys must have Windows
for Windows Server 2012 R2. Server 2012 R2 installed.

Not This hotfix contains the most

applicable current version of Dfsrclus.dll
for Windows Server 2012 R2.

August 2996883 DFSR stops replication after This hotfix contains the most To apply this hotfix, you
31, 2014 an unexpected shutdown in current versions of must be running
a Windows 8.1 or Windows Dfsrdiag.exe and Dfsrmig.exe Windows Server 2012 R2
Server 2012 R2 environment for Windows Server 2012 R2. and April 2014 Update
2919355 .

Windows Server 2012

ﾉ Expand table

Date Knowledge Title Why we Hotfix type and

added Base article recommend this availability
hotfix

February 2884176 Large backlogs on Windows-based This hotfix contains To install this hotfix, you
14, 2015 DFSR servers the most current must have Windows Server
version of Dfsrs.exe 2012 installed. This hotfix is
and Dfsrress.dll for available for individual
Windows Server download.
2012.

Jan-10 3121255 0x00000024 Stop error in This hotfix contains To install this hotfix, you
2016 FsRtlNotifyFilterReportChange and an update for must have Windows Server
VSS backup of PI Data server fails in Ntfs.sys for 2012 installed. This hotfix is
Windows Windows Server available for individual
2012. download. This hotfix is also
included in July 11, 2017-
KB4025331 (Monthly Rollup)
and later monthly rollups.

DFS replication - Sysvol migration

ﾉ Expand table
Date Knowledge Title Why we recommend this hotfix Hotfix type and availability
added Base article

Not applicable This hotfix contains the most current versions To install this hotfix, you must
of Dfsrdiag.exe and Dfsrmig.exe for Windows have Windows Server 2012
Server 2012. installed.

Robocopy

Windows Server 2012 R2

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and
added Base article availability

18- 3000850 November 2014 update This hotfix contains the most To install this update rollup,
Nov- rollup for Windows RT current version of Robocopy.exe. you must have Windows
2014 8.1, Windows 8.1, and Server 2012 R2 installed
Windows Server 2012 Robocopy can be used to pre- and April 2014 Update
R2 seed data for new replicated 2919355 .
folders and is also used during
the migration of Sysvol from FRS
to DFSR.

Windows Server 2012

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and
added Base article availability

May 16, 2962407 Windows RT, This hotfix contains the most current To install this hotfix, you
2014 Windows 8, and version of Robocopy.exe. must have Windows 8 or
Windows Server 2012 Windows Server 2012
update rollup: June Robocopy can be used to pre-seed installed.
2014 data for new replicated folders and is
also used during the migration of
Sysvol from FRS to DFSR.

DFS-related registry subkeys that were introduced in hotfixes or security updates

ﾉ Expand table

Date Knowledge Registry subkey

Base
article

January KB 2663685 HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery/strong>

21, 2012
 Date Knowledge Registry subkey
Base
article

November KB 967326 HKLM\System\CurrentControlSet\Services\DFSR\Parameters\Settings\RpcContextHandleTimeoutMs

18. 2009

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following
the steps mentioned in Gather information by using TSS for Active Directory replication issues.

References
KB 968429: List of currently available hotfixes for Distributed File System (DFS) technologies in
Windows Server 2008 and in Windows Server 2008 R2
KB 2473205: List of currently available hotfixes for the File Services technologies in Windows Server
2008 and in Windows Server 2008 R2
KB 2899011: List of currently available hotfixes for the File Services technologies in Windows Server
2012 and in Windows Server 2012 R2

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to restrict Active Directory RPC
traffic to a specific port
Article • 02/19/2024

This article describes how to restrict Active Directory (AD) replication remote procedure
calls (RPC) traffic to a specific port in Windows Server.

Applies to: all supported versions of Windows Server

Original KB number: 224196

Summary
By default, Active Directory replication remote procedure calls (RPC) occur dynamically
over an available port through the RPC Endpoint Mapper (RPCSS) by using port 135. An
administrator can override this functionality and specify the port that all Active Directory
RPC traffic passes through. This procedure locks down the port.

When you specify ports to use by using the registry entries in More information, both
Active Directory server-side replication traffic and client RPC traffic are sent to these
ports by the endpoint mapper. This configuration is possible because all RPC interfaces
supported by Active Directory are running on all ports on which it's listening.

７ Note

This article doesn't describe how to configure AD replication for a firewall.

Additional ports must be opened to make replication work through a firewall. For
example, ports may need to be opened for the Kerberos protocol. To obtain a
complete list of the required ports for services across a firewall, see Service
overview and network port requirements for Windows.

More information

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
 problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

When you connect to an RPC endpoint, the RPC runtime on the client contacts the
RPCSS on the server at a well-known port (135). And it obtains the port to connect to for
the service supporting desired RPC interface. It assumes that the client doesn't know the
complete binding. It's the situation with all AD RPC services.

The service registers one or more endpoints when it starts, and has the choice of a
dynamically assigned port or a specific port.

If you configure Active Directory and Netlogon to run at port x as in the following entry,
it becomes the ports that are registered with the endpoint mapper in addition to the
standard dynamic port.

Use Registry Editor to modify the following values on each domain controller where the
restricted ports are to be used. Member servers aren't considered to be logon servers.
So static port assignment for NTDS has no effect on member servers.

Member servers do have the Netlogon RPC Interface, but it's rarely used. Some
examples may be remote configuration retrieval, such as nltest
/server:member.contoso.com /sc_query:contoso.com .

Registry key 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: (available port)

Restart the computer for the new setting to become effective.

Registry key 2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: DCTcpipPort
Value type: REG_DWORD
Value data: (available port)

Restart the Netlogon service for the new setting to become effective.
 ７ Note

When you use the DCTcpipPort registry entry, and you set it to the same port as the
TCP/IP Port registry entry, you receive Netlogon error event 5809 under
NTDS\Parameters . This indicates that the port configured is in use, and you should

choose a different port.

You'll receive the same event when you have a unique port, and you restart the
Netlogon service on the domain controller. This behavior is by design. It occurs because
of the way the RPC runtime manages its server ports. The port will be used after the
restart, and the event can be ignored.

Administrators should confirm that the communication over the specified port is
enabled if any intermediate network devices or software is used to filter packets
between the domain controllers.

Frequently, you must also manually set the File Replication Service (FRS) RPC port
because AD and FRS replication replicate with the same Domain Controllers. The FRS
RPC port should use a different port.

Don't assume that clients only use the Netlogon RPC services and thus only the setting
DCTcpipPort is required. Clients are also using other RPC services such as SamRPC,

LSARPC, and also the Directory Replication Services (DRS) interface. You should always
configure both registry settings and open both ports on the firewall.

Known issues
After you specify the ports, you may encounter the following issues:

Long logon time after you set a specific static port for NTDS and Netlogon in a
Windows Server 2008 R2-based domain environment
AD replication fails with an RPC issue after you set a static port for NTDS in a
Windows-based domain environment
Logon fails after you restrict client RPC to DC traffic in Windows Server 2012 R2 or
Windows Server 2008 R2

To resolve the issues, install the updates mentioned in the articles.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Information about lingering objects in a
Windows Server Active Directory forest
Article • 02/19/2024

This article provides some information about lingering objects in a Windows Server
Active Directory forest.

Applies to: Windows Server 2012 R2

Original KB number: 910205

Summary
This article contains information about lingering objects in an Active Directory forest.
Specifically, the article describes the events that indicate the presence of lingering
objects, the causes of lingering objects, and the methods that you can use to remove
lingering objects.

INTRODUCTION
Lingering objects can occur if a domain controller does not replicate for an interval of
time that is longer than the tombstone lifetime (TSL). The domain controller then
reconnects to the replication topology. Objects that are deleted from the Active
Directory directory service when the domain controller is offline can remain on the
domain controller as lingering objects. This article contains detailed information about
the events that indicate the presence of lingering objects, the causes of lingering
objects, and the methods that you can use to remove lingering objects.

More information

Tombstone lifetime and replication of deletions

When an object is deleted, Active Directory replicates the deletion as a tombstone
object. A tombstone object consists of a small subset of the attributes of the deleted
object. By inbound-replicating this object, other domain controllers in the domain and
in the forest receive information about the deletion. The tombstone is retained in Active
Directory for a specified period. This specified period is called the TSL. At the end of the
TSL, the tombstone object is permanently deleted.
The default value of the TSL depends on the version of the operating system that is
running on the first domain controller that is installed in a forest. The following table
indicates the default TSL values for different Windows operating systems.

ﾉ Expand table

First domain controller in forest root Default tombstone lifetime

Windows 2000 60 days

Windows Server 2003 60 days

Windows Server 2003 with Service Pack 1 180 days

７ Note

The existing TSL value does not change when a domain controller is upgraded to
Windows Server 2003 with Service Pack 1 (SP1). The existing TSL value is
maintained until you manually change it.

After the tombstone is permanently deleted, the object deletion can no longer be
replicated. The TSL defines how long domain controllers in the forest retain information
about a deleted object. The TSL also defines the time during which all direct and
transitive replication partners of the originating domain controller must receive a unique
deletion.

How lingering objects occur

When a domain controller is disconnected for a period that is longer than the TSL, one
or more objects that are deleted from Active Directory on all other domain controllers
may remain on the disconnected domain controller. Such objects are called lingering
objects. Because the domain controller is offline during the time that the tombstone is
alive, the domain controller never receives replication of the tombstone.

When this domain controller is reconnected to the replication topology, it acts as a

source replication partner that has an object that its destination partner does not have.

Replication problems occur when the object on the source domain controller is updated.
In this case, when the destination partner tries to inbound-replicate the update, the
destination domain controller responds in one of two ways:

If the destination domain controller has Strict Replication Consistency enabled, the
controller recognizes that it cannot update the object. The controller locally stops
 inbound replication of the directory partition from the source domain controller.

If the destination domain controller has Strict Replication Consistency disabled, the
controller requests the full replica of the updated object. In this case, the object is
reintroduced into the directory.

Causes of long disconnections

The following conditions can cause long disconnections:

A domain controller is disconnected from the network and is put in storage.

The shipment of a pre-staged domain controller to its remote location takes

longer than a TSL.

Wide area network (WAN) connections are unavailable for long periods. For
example, a domain controller on board a cruise ship may be unable to replicate
because the ship is at sea for longer than the TSL.

The reported event is a false positive because an administrator shortened the TSL
to force the garbage collection of deleted objects.

The reported event is a false positive because the system clock on the source or on
the destination domain controller is incorrectly advanced or rolled back. Clock
skews are most common following a system restart. Clock skews may occur for the
following reasons:

There is a problem with the system clock battery or with the motherboard.

The time source for a computer is configured incorrectly. It includes a time

source server that is configured by using Windows Time service (W32Time), by
using a third-party time server, or by using network routers.

An administrator advances or rolls back the system clock to extend the useful
life of a system state backup or to accelerate the garbage collection of deleted
objects. Make sure that the system clock reflects the actual time. Also, make
sure that event logs do not contain invalid events from the future or from the
past.

Indications that a domain controller has lingering objects

An outdated domain controller can store lingering objects without any noticeable effect
when the following conditions are true:
 An administrator, an application, or a service does not update the lingering object.
An administrator, an application, or a service does not try to create an object that
has the same name in the domain.
An administrator, an application, or a service does not try to create an object by
using the same user principal name (UPN) in the forest.

Even when there is no noticeable effect, the presence of lingering objects can cause
problems. These problems are most likely to occur if a lingering object is a security
principal.

Events that indicate that lingering objects may be present in the

forest

ﾉ Expand table

Event General description

ID

1862 The local domain controller has not recently received replication information from
several domain controllers (intersite).

1863 The local domain controller has not recently received replication information from
several domain controllers (intersite).

1864 The local domain controller has not recently received replication information from
several domain controllers (summary).

1311 The Knowledge Consistency Checker (KCC) was not able to build a spanning tree
topology.

2042 It has been too long since this server last replicated with the named source server.

Events that indicate that lingering objects are present in the forest

ﾉ Expand table

Event General description

ID

1084 There is no such object on the server.

1388 This destination system received an update for an object that should have been
present locally but was not.

1311 Another domain controller replicated an object not present on this domain controller.
 ７ Note

Lingering objects are not present on domain controllers that log Event ID 1988. The
source domain controller contains the lingering object.

Repadmin errors that indicate that lingering objects are present in

the forest

ﾉ Expand table

Event ID General description

8240 There is no such object on the server.

8606 Insufficient attributes were given to create an object.

Other indications that lingering objects are present in the

forest
A user or group account that was deleted remains in the global address list (GAL)
on servers that are running Microsoft Exchange Server. Therefore, although the
account name appears in the GAL, errors occur when users try to send e-mail
messages.

Multiple copies of an object appear in the object picker or in the GAL for an object
that should be unique in the forest. You sometimes see duplicate objects that have
changed names. These duplicate objects cause confusion on directory searches.
For example, if the relative distinguished name of two objects cannot be resolved,
conflict resolution appends CNF:GUID to the name. In this example, * represents a
reserved character, CNF is a constant that indicates a conflict resolution, and GUID
represents the objectGUID attribute value.

E-mail messages are not delivered to a user whose Active Directory account
appears to be current. After an outdated domain controller or global catalog server
is reconnected, both instances of the user object appear in the global catalog.
Because both objects have the same e-mail address, e-mail messages cannot be
delivered.

A universal group that no longer exists continues to appear in a user's access

token. Although the group no longer exists, if a user account still has the group in
 its security token, the user may have access to a resource that you intended to be
unavailable to that user.

A new object or Exchange mailbox cannot be created. But you do not see the
object in Active Directory. An error message reports that the object already exists.

Searches that use attributes of an existing object may incorrectly find multiple
copies of an object of the same name. One object has been deleted from the
domain. But that object remains in an isolated global catalog server.

If an attempt is made to update a lingering object that resides in a writable directory

partition, events are logged on the destination domain controller. However, if the only
version of a lingering object is in a read-only directory partition on a global catalog
server, the object cannot be updated. Therefore, this kind of event is not triggered.

Removing lingering objects from the forest

Windows 2000-based forests

For more information about how to remove lingering objects in a Windows 2000-based
domain, click the following article number to view the article in the Microsoft
Knowledge Base:

314282 Lingering objects may remain after you bring an out-of-date global catalog
server back online

Windows Server 2003-based forests

For more information, click the following article number to view the article in the
Microsoft Knowledge Base:

892777 Windows Server 2003 Service Pack 1 Support Tools

Preventing lingering objects

The following are methods that you can use to prevent lingering objects.

Method 1: Enable the Strict Replication Consistency registry entry

You can enable the Strict Replication Consistency registry entry so that suspect objects
are quarantined. Then, administrations can remove these objects before they spread
throughout the forest.
If a writable lingering object is located in your environment, and an attempt is made to
update the object, the value in the Strict Replication Consistency registry entry
determines whether replication proceeds or is stopped. The Strict Replication
Consistency registry entry is located in the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

The data type for this entry is REG_DWORD. If you set the value to 1, the entry is
enabled. Inbound replication of the specified directory partition from the source is
stopped on the destination. If you set the value to 0, the entry is disabled. The
destination requests the full object from the source domain controller. The lingering
object is revived in the directory as a new object.

The default value for the Strict Replication Consistency registry entry is determined by
the conditions under which the domain controller was installed in the forest.

７ Note

Raising the functional level of the domain or the forest does not change the
replication consistency setting on any domain controller.

By default, the value of the Strict Replication Consistency registry entry on domain
controllers that are installed in a forest is 1 (enabled) if the following conditions are true:

The Windows Server 2003 version of Winnt32.exe is used to upgrade a Windows

NT 4.0 primary domain controller (PDC) to Windows Server 2003. This computer
creates the forest root domain of a new forest.
Active Directory is installed on a server that is running Windows Server 2003. This
computer creates the forest root domain of a new forest.

By default, the value of the Strict Replication Consistency registry entry on domain
controllers is 0 (disabled) if the following conditions are true:

A Windows 2000-based domain controller is upgraded to Windows Server 2003.

Active Directory is installed on a Windows Server 2003-based member server in a
Windows 2000-based forest.

If you have a domain controller that is running Windows Server 2003 with SP1, you do
not have to modify the registry to set the value of the Strict Replication Consistency
registry entry. Instead, you can use the Repadmin.exe tool to set this value for one
domain controller in the forest or for all the domain controllers in the forest.

For more information about how to use Repadmin.exe to set Strict Replication
Consistency, visit the following Microsoft Web site:
https://technet.microsoft.com/library/cc780362(WS.10).aspx

Method 2: Monitor replication by using a command-line command

To monitor replication by using the repadmin /showrepl command, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. Type repadmin /showrepl * /csv >showrepl.csv , and then press ENTER.

3. In Microsoft Excel, open the Showrepl.csv file.

4. Select the A + RPC column and the SMTP column.

5. On the Edit menu, click Delete.

6. Select the row that is immediately under the column headers.

7. On the Windows menu, click Freeze Pane.

8. Select the complete spreadsheet.

9. On the Data menu, point to Filter, and then click Auto-Filter.

10. On the heading of the Last Success column, click the down arrow, and then click
Sort Ascending.

11. On the heading of the src DC column, click the down arrow, and then click
Custom.

12. In the Custom AutoFilter dialog box, click does not contain.

13. In the box to the right of does not contain, type del.

７ Note

This step prevents deleted domain controllers from appearing in the results.

14. On the heading of the Last Failure column, click the down arrow, and then click
Custom.

15. In the Custom AutoFilter dialog box, click does not equal.

16. In the box to the right of does not equal, type 0.

17. Resolve the replication failures that are displayed.

Method 3: Remove domain controllers
You can remove failing domain controllers from the forest before the TSL expires.

Method 4: Increase the TSL

Windows 2000 Server

Increase the TSL to 180 days by using the Adsiedit tool. To do it, follow these steps:

1. In the Adsiedit tool, expand Configuration DomainControllerName, expand

CN=Configuration, DC=ForestRootDomain, expand CN=Services, expand
CN=Windows NT, right-click CN=Directory Service, and then click Properties.
2. Click the Attribute tab.
3. In the Select which properties to view list, click Optional.
4. In the Select a property to view list, click TombstoneLifetime.
5. In the Edit Attribute box, type 180, click Set, and then click OK. Windows Server
2003

Increase the TSL to 180 days by using the Adsiedit tool. To do it, follow these steps:

1. In the Adsiedit tool, expand Configuration DomainControllerName, expand

CN=Configuration, DC=ForestRootDomain, expand CN=Services, expand
CN=Windows NT, right-click CN=Directory Service, and then click Properties.
2. Click the Attribute Editor tab.
3. In the Attribute list, click TombstoneLifetime, and then click Edit.
4. In the Value box, type 180, and then click OK.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Lingering objects may remain after you
bring an out-of-date global catalog
server back online
Article • 02/19/2024

This article describes procedures for cleaning up objects that are reintroduced to AD
after you bring an offline DC back online.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 314282

Symptoms
You bring a domain controller (DC) or global catalog server online after it has been
offline for a long time. After it comes online, you observer one or more of the following
issues:

E-mail messages are not delivered to a user whose user object was moved
between domains. After you bring the outdated DC or global catalog server back
online, both instances of the user object appear in the global catalog. Both objects
have the same e-mail address, so e-mail messages cannot be delivered.
A user account that no longer exists still appears in the global address list.
A universal group that no longer exists still appears in a user's access token.
Other DCs or global catalog servers log events such as EventID 1084, There is no
such object on the server. Further replication is blocked on the affected DCs or
global catalog servers.

Cause
These problems may occur if the DC or global catalog server has been offline for longer
than the value of the Tombstone-Lifetime attribute of user objects.

For more information about the Tombstone-Lifetime attribute, see Tombstone-Lifetime

attribute.

The Tombstone-Lifetime attribute defines the number of days before a deleted object is
removed from the directory services. This assists in removing objects from replicated
servers and preventing restores from reintroducing a deleted object. The default value is
180 days. After that time, Active Directory no longer needs to remember the change.
If a DC or a global catalog server is offline for longer than the value of the Tombstone-
Lifetime attribute, its copy of Active Directory (or the global catalog) may contain
objects that have been deleted on the other DCs. However, the other DCs no longer
remember that the objects have been deleted. When you bring the offline DC online, it
synchronizes its copy of Active Directory with the rest of the domain. Because the
information about the deletions has been discarded, the DC replicates the affected
objects (referred to as lingering objects) back to the rest of the domain.

In general, AD DS uses a loose-consistency replication model, in which some naming

contexts (also known as directory partitions) are read/write and others are read-only.
When a DC that receives a replicated object that belongs to a read/write naming context
and that object does not already exist in the local copy of the Directory Information Tree
(DIT), the DC creates the object. As the replication process continues, the object
reappears on all DCs in the domain.

DCs and global catalog servers can also use a strict replication consistency model. Under
this model, when the DC receives a replicated object that does not already exist in the
local DIT, the DC stops receiving or sending replicated data and logs events such as
Event ID 1084, "There is no such object on the server." For more information about strict
replication consistency, including the circumstances under which DCs may use this
model by default, see KB 910205, Information about lingering objects in a Windows
Server Active Directory forest . For more information about tombstone issues, see
KB216993 Useful shelf life of a system-state backup of Active Directory .

Resolution 1: Determine whether Active

Directory has lingering objects, and avoid
future lingering objects
KB 910205 , explains several ways in which to determine whether your Active Directory
system has accumulated lingering objects. KB 910205 also describes steps you can take
to prevent lingering objects from accumulating.

Resolution 2: Delete lingering objects

If the object should not exist in Active Directory at all (for example, if the object was
reintroduced by an outdated domain controller), you can delete the objects with the
standard tools (such as ADSIEdit or the Active Directory Users and Computers snap-in).

It is easy to remove lingering objects for read/write naming contexts. In Windows Server
2003 and later versions, you can remove lingering objects by using the command
repadmin /removelingeringobjects . For information about how to use RepAdmin, see

Active Directory Replication Event ID 1388 or 1988: A lingering object is detected .

This article describes how to remove lingering objects that have already appeared in
read-only naming contexts such as directory partitions on global catalog servers or
Read-Only Domain Controllers (RODCs). The functionality discussed in the More
information section still exists in newer operating systems and might still be useful to
troubleshoot unexpected RepAdmin behavior.

More information
This procedure requires the objectGUID of a DC that has a read/write copy of the
object, and the objectGUID of the object itself. If you must remove more than one
object, determine whether any of the objects are in a parent/child relationship (you can
determine this from the objects' distinguished names). If this is the case, order the
deletions so that all of the child objects are deleted before their parent objects.

This procedure has three mains steps, which you have to perform on a computer that
has access to the forest (and you have to use a user account that has administrative
permissions on the forest):

1. Obtain the distinguished name and ObjectGUID of the lingering object.

2. Identify a DC in the object domain.
3. Delete the lingering objects. Select one of the following methods:

Delete a few lingering objects.

Delete a large number of lingering objects.

） Important

Each global catalog server on which you intend to run the delete operations (step
3) must have network connectivity to the domain controller that you identified
(step 2).

For troubleshooting information, see the following sections:

Error message when running Walkservers.cmd to modify many lingering objects in

the environment.
Error message 87 when removing lingering objects in the environment.
Obtain the distinguished name and ObjectGUID of the
lingering object
The best way to identify the domain in which an object is located (and from that to
determine the name of a DC that has a read/write copy of the object) is to retrieve the
distinguished name of the object. You can search for the name (or parts of the name) of
the object by using the Ldp.exe tool. To do this, follow these steps:

1. Start Ldp.exe.

In most versions of Windows, select Start > Run and enter ldp.exe. In older
versions of Windows (such as Windows Server 2003 SP1) this tool is available as
one of the Support Tools.

2. Select Connection > Connect. In the Server box, type the name of a global catalog
server. In the Port box, type 3268, and then select OK.

3. Select Connection > Bind. Type valid credentials if your current credentials are not
sufficient to query all of the global catalog contents. Select OK.

4. Select View > Tree. Enter the distinguished name of the forest root and then select
OK.

5. In the tree list, right-click the forest root and then select Search.

6. In the Filter box, type a filter that uses the <attribute> = <value> format.

In the filter text, <attribute> represents the object attribute to be searched, and
<value> represents the criteria for which you are searching. You can use ***** as a
wildcard character in the value, and you can use an expression.

For information about Lightweight Directory Access Protocol (LDAP) filter syntax,
see Search Filter Syntax.

For example, to find objects for which the sAMAccountName attribute has a value
of testuser, type (sAMAccountName = testuser) in the Filter box. To search for a
user object, the following attributes are most useful:

cn
userPrincipalName
sAMAccountName
name
mail
sn
 To search for a group object, the following attributes are most useful:

cn
sAMAccountName
name

7. Under Scope, select Subtree.

8. Select the Attributes box and then select the end of the attribute string. Type
;objectGUID at the end of the string.

In some versions of Ldp, you have to select Options to see the Attributes box.

9. To run the query, select Run.

The results appear in the main Ldp window.

10. Determine which, if any, of the objects that are listed in the results should be
removed from the global catalog. One indication that you have found a bad object
is that the object does not exist on a read/write copy of the naming context.

11. If the objects that you are looking for are not included in the query results,
rephrase the filter and run the search again.

12. If you have identified a lingering object, note the values of its DN and objectGUID
attributes. You will need those values later.

Identify a DC in the object domain

The value of the object's DN attribute includes the domain of the object. When you
know the domain, you can identify a DC or global catalog server within the domain. To
do this, follow these steps.

1. Check the dc= portions of the DN value. Combine the dc= portions to obtain the
domain name.

For example, if an object has the DN value of cn=FirstName

LastName,cn=Users,dc=name1,dc=name2,dc=com, the object is in the
name1.name2.com domain.

2. To locate a DC (or a global catalog server) in this domain, open Active Directory
Users and Computers, open the domain container, and then open the Domain
Controllers container.

3. Open an elevated Command Prompt window and enter repadmin /showreps dc-
name .

７ Note

In this command, dc-name represents the computer name of the DC that you
identified in step 2.

In older versions of Windows (such as Windows Server 2003 SP1), RepAdmin

is available as one of the Support Tools.

Repadmin produces results that resemble the following:

Default-First-Site-Name\WS2016-DC-01 DSA Options: IS_GC Site Options:

(none) DSA object GUID: <GUID> DSA invocationID: <invocationID>

4. Note the value of the DSA object GUID. This is the objectGUID value of the DC.

Delete lingering objects

Use the following methods to delete lingering objects.

Delete a few lingering objects from a few global catalog servers

If you have only a few objects and global catalogs, follow these steps to delete the
objects by using Ldp.exe:

1. Use Enterprise Administrator credentials to sign in to each global catalog server

that contains a copy of the lingering object.
2. Start Ldp.exe and connect to port 389 on the local domain controller (leave the
Server box empty).

3. Select Connection > Bind. Leave all of the boxes empty (you are already signed in
as an Enterprise Administrator).

4. Select Browse > Modify.

5. Configure the following entries in the Modify dialog box:

a. Leave the Dn box empty.

b. In the Attribute box, type RemoveLingeringObject.

c. In the Values box, type a value that uses the following format:

<GUID=dcGUID>: <GUID=objectGUID>

In this value, dcGUID represents the GUID of the DC that you identified in step 2
of this section, and objectGUID represents the GUID of the lingering object that
 you identified in step 1 of this section.

The value should resemble the following:

<GUID=<GUID>>: <GUID=<GUID>>

） Important

In the value, do not omit the spaces before and after the colon.

d. Select Operation > Replace, and then select Enter.

The Entry List box shows the full command.

e. Select Run.

The results appear in the main Ldp window, and should resemble the following.

***Call Modify... ldap_modify_s(ld, '(null)',[1] attrs); Modified "".

Delete a large number of lingering objects from several global

catalog servers
If you have to delete a large number of lingering objects, you can delete more efficiently
by using scripts than by deleting them manually. To build such scripts, use the following
steps:

1. Create a new folder, and in that folder create new files that have the following
names:

Walkservers.cmd
Walkobjects.cmd
Modifyrootdse.vbs
Server-list.txt
Object-list.txt file

2. Paste the following text into Walkservers.cmd:

Console

for /f %%j in (server-list.txt) do walkobjects %%j

3. Paste the following text into Walkobjects.cmd:

 Console

for /f "delims=@" %%i in (object-list.txt) do cscript //NoLogo

MODIFYROOTDSE.VBS %1 "%%i" >>update-%1.log

4. Paste the following text into Modifyrootdse.vbs:

vbs

'********************************************************************
'*
'* File: MODIFYROOTDSE.VBS
'* Created: January 2002
'* Version: 1.0
'*
'* Main Function: Writes Active Directory information to clean up
'* objects as per: Q314282.
'* Usage: Modifyrootdse.vbs <TargetServer> <GUID PAIR>
'* Parameter are fed into the script using a pair of batch files.
'*
'* Copyright (C) 2002 Microsoft Corporation '*
'********************************************************************
OPTION EXPLICIT
ON ERROR RESUME NEXT

Dim objDomain
Dim ObjValue, strServerName, adsLdapPath
Dim i

'Get the command-line arguments

if Wscript.arguments.count <> 2 Then

Print "Invalid Number of Parameters. Use with WalkServers.CMD and
WalkObjects.CMD"
WScript.quit
End If

strServerName = Wscript.arguments.item(0)
ObjValue = Wscript.arguments.item(1)

adsLdapPath = "LDAP://" & strServerName & "/RootDSE"

Set objDomain = GetObject(adsLdapPath)

If Err.Number <> 0 Then
WScript.Echo "Error opening ROOTDSE. Error number is: " &
Err.Number & ". Error description is: " & Err.Description & "."
Set objDomain = Nothing
WScript.quit
End If

objDomain.Put "RemoveLingeringObject", ObjValue

objDomain.Setinfo
 If Err.Number = 0 Then
WScript.Echo "Object " & ObjValue & " was removed."
Else
WScript.Echo "Object " & ObjValue & " could not be removed. Error
number is: " & Err.Number & ". Error description is: " &
Err.Description & "."
End If

WScript.Quit

７ Note

If you start Modifyrootdse.vbs manually, make sure to enclose in quotation

marks any parameters that contain spaces.

5. Create a list of all of the fully qualified domain names of the global catalog servers
and DCs that contain the lingering objects, and then paste the list into Server-
list.txt. Use the fully qualified domain names to avoid DNS suffix searches.

6. For each lingering object, identify a DC in the object domain that does not have a
copy of the lingering object. Usually this is a DC that has a read/write naming
context in which you manually deleted the lingering object. As described
elsewhere in this article, use RepAdmin to obtain the objectGUID value of each DC.

7. In Object-list.txt, create a list of GUID pairs, using the following format:

<GUID=dcGUID>: <GUID=objectGUID>

７ Note

In this value, dcGUID represents the GUID of the DC that does not have a
copy of the lingering object, and objectGUID represents the GUID of the
lingering object.

Each pair should resemble the following:

<GUID=<GUID>>: <GUID=<GUID>>

） Important

In the value, do not omit the spaces before and after the colon.

8. Run the Walk-servers.cmd file.

For each DC or global catalog server that is listed in Server-list.txt, the scripts generate a
log file that is named Update-server-name.log. Each log file contains a line for each
object that is to be deleted.

Because the lingering objects may not exist on every listed server, errors in the log files
do not necessarily indicate a problem. However, error messages of the form operation
refused or operation error indicate that there is a problem with the GUIDs or with the
syntax of the value. If these errors occur, verify the following:

Make sure that the DC GUIDs are the correct GUIDs for domain controllers that
contain a read/write naming context of the domain that contains the object.

Make sure that the object GUIDs identify lingering objects in read-only naming
contexts (global catalog servers or RODCs).

Error when running Walkservers.cmd to modify many lingering

objects in the environment

Object <GUID=<GUID>> : <GUID=<GUID>> could not be removed. Error number

is: -2147016672. Error description is: .

Cause for this error

This error occurs when the script runs against the GUID of a DC that does not contain a
read/write naming context that corresponds to the naming context that contains the
lingering object. Verify the location of lingering object by the Ldp.exe tool.

Example

In the following example, the lingering object to be removed is located in the

corp.company.local domain. However, the <GUID=<GUID>> entry in the Objects-list.txt
file is associated with a DC that resides in the company.local domain. This DC does not
have a read/write naming context for the corp.company.local domain.

The following search produces multiple objects that represent the same user (Joe), and
lists their objectGUID values.

ldap_search_s(ld, "DC=company,DC=local", 2, "(cn=User*)", attrList, 0, &msg) Result

<0>: (null)
Matched DNs:
Getting 4 entries:
>> Dn: CN=User, Joe,OU=Exec,OU=Corporate
 Users,DC=corp,DC=company,DC=local
1> canonicalName: corp.company.local/Corporate Users/Exec/User, Joe;
1> cn: User, Joe; 1> description: CEO;
1> displayName: User, Joe; 1> distinguishedName: CN=User,
Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local; 4> objectClass:
top; person; organizationalPerson; user;
1> objectGUID: <GUID>; 1> name: User, Joe;
>> Dn: CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local 1>
canonicalName: corp.company.local/Migration/User, Joe;
1> cn: User, Joe;
1> description: Disabled Account; 1> displayName: User, Joe; 1>
distinguishedName: CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local;
4> objectClass: top; person; organizationalPerson; user;
1> objectGUID: <GUID>;
1> name: User, Joe;

In this example, presume that there is a DC in the corp.company.local domain that is

named CORP-DC-01. Running the command repadmin /showreps CORP-DC-01 produces
the objectGUID value <GUID>. This GUID replaces the previous GUID in the Objects-
list.txt file. The entry for this lingering object now appears as follows:

<GUID=<GUID>> : <GUID=<GUID>>

The first GUID is the GUID of the domain controller in the corp.company.local domain.
The second GUID is the GUID of the lingering object. After this change, the Walk-
servers.cmd script runs successfully.

Error message 87 when removing lingering objects in the

environment

This error might occur when you find objects are in fact not appearing on all DCs that
host the naming context, but repadmin /removelingeringobjects does not remove them.
This can be a situation when a hub DC replicates new objects it created with global
catalog servers, but not with read/write replica DCs in its own domain.

This error is returned only in two cases:

The object exists on the reference DC.

The object is too young (compared to the current TSL value) to be lingering.

For an example of the second case, consider a global catalog server that has the
following metadata:
 Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= ===
=========
143543261 d20f71f3-6147-4f80-a0c2-470541ef09e6 104742409 <DateTime>
objectClass
Up-To-Dateness Vector of a RW-replica: d20f71f3-6147-4f80-a0c2-470541ef09e6 @
USN 104583382 @ Time <DateTime>
Up-To-Dateness Vector of a GC: d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN
104762881 @ Time <DateTime>

In this case the DC created the object after replication with the DCs in its own domain
started failing, but it still replicated with global catalog servers in other domains.

To resolve this issue, let these objects become real lingering objects (aged beyond TSL)
and then remove them using the script in this article. To make sure that the data
continues to replicate, set Allow Replication With Divergent and Corrupt Partner on all
DCs in the forest.

If you cannot resolve the errors in the log files by using these methods, you may be
experiencing a different problem. Contact Microsoft Product Support Services for
additional assistance.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error (Target Principal Name is
incorrect) when manually replicating
data between domain controllers
Article • 02/19/2024

This article provides a solution to an error that occurs when you manually replicate data
between domain controllers.

Applies to: Windows 2000

Original KB number: 288167

７ Note

This article applies to Windows 2000. Support for Windows 2000 ends on July 13,
2010. The Windows 2000 End-of-Support Solution Center is a starting point for
planning your migration strategy from Windows 2000. For more information, see
the Microsoft Support Lifecycle Policy.

Symptoms
When you use the Active Directory Sites and Services snap-in to manually replicate data
between Windows 2000 domain controllers, you may receive one of the following error
messages:

The Target Principal Name is incorrect

Or

Access is denied

In addition, the following event ID messages may be logged in the system log:

Output

Event Source: Netlogon

Event Category: None
Event ID: 3210
User: N/A
Event Description:
 Failed to authenticate with \\DOMAINDC, a Windows NT domain controller for
domain DOMAIN.

Output

Event Source: Netlogon

Event ID: 5722
Event Category: None
User: N/A
Event Description:
The session setup from the computer 1 failed to authenticate. The name of
the account referenced in the security database is 2. The following error
occurred: n3

Resolution
To resolve this issue, first determine which domain controller is the current primary
domain controller (PDC) Emulator operations master role holder. To do this, use either
of the following methods:

Install the Netdom.exe utility from Windows 2000 Support Tools, and then run the
following command:

Console

netdom query fsmo

Start the Active Directory Users and Computers snap-in, right-click the domain,
and then click Operations Masters. Click the PDC tab; the current role holder is
displayed in the Operations Master window. On this tab, you can change the
operations master role to the current computer in the second window (if this
computer is not the current holder).

Use the Ntdsutil.exe utility (that is included in Windows 2000), and the Resource Kit
command-line utility. However, these interfaces are recommended for more
advanced users. For additional information, see How to find servers that hold
flexible single master operations roles.

On domain controllers that are experiencing this issue, disable the Kerberos Key
Distribution Center service (KDC):

1. Click Start, point to Programs, click Administrative Tools, and then click Services.
2. Double-click KDC, set the startup type to Disabled, and then restart the computer.
After the computer restarts, use the Netdom utility to reset the secure channels between
these domain controllers and the PDC Emulator operations master role holder. To do so,
run the following command from the domain controllers other than the PDC Emulator
operations master role holder:

Console

netdom resetpwd /server: server_name /userd: domain_name \administrator

/passwordd: administrator_password

Where server_name is the name of the server that is the PDC Emulator operations
master role holder.

After you reset the secure channel, restart the domain controllers. Even if you attempt to
reset the secure channel using the Netdom utility, and the command does not complete
successfully, proceed with the restart process.

If only the PDC Emulator operations master role holder is running, the KDC forces the
other domain controllers to resynchronize with this computer, instead of issuing
themselves a new Kerberos ticket.

After the computers have finished restarting, start the Services program, restart the KDC
service, and then attempt replication again.

More information
If there are multiple domain controllers in the domain, the error message that you
receive when this issue occurs varies depending on which way replication is being
attempted, and if one of the domain controllers that is involved is also the PDC Emulator
operations master role holder.

In some cases, when you use the net view \\computername to attempt to connect to the
domain controller that has the PDC Emulator operations master role from another
domain controller, you may receive an "Access denied" error message. However, if you
use the Internet protocol (IP) address, the command may succeed.

When this problem occurs, numerous errors may be reported in the event logs. These
errors vary depending on any of the following conditions:

The domain controller was not fully functional before the problem occurred.

The domain controller did not successfully completed the Active Directory
Installation Wizard process.
 The Sysvol folder on the domain controller was not shared out.

The domain controller did not have the full file structure under the Domain_name
folder and the Policies folder that is located in
%SystemRoot%\Sysvol\Sysvol\Domain_name\Policies. The following event is an
example of an event that may be reported:

Output

Event ID: 3034

Type: Warning
Source: MRxSmb
Description: The redirector was unable to initialize security context
or query context attributes.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to Modify the Default Intra-Site
Domain Controller Replication Interval
Article • 02/19/2024

This article describes how to modify the default intra-site domain controller replication
interval.

Applies to: Windows Server 2012 R2

Original KB number: 214678

More information
When a domain controller writes a change to its local copy of the Active Directory, a
timer is started that determines when the domain controller's replication partners
should be notified of the change. By default, this interval is 15 seconds in Windows
Server 2003 and later versions. When this interval elapses, the domain controller initiates
a notification to each intra-site replication partner that it has changes that need to be
propagated. Another configurable parameter determines the number of seconds to
pause between notification. This parameter prevents simultaneous replies by the
replication partners. By default, this interval is 3 seconds in Windows Server 2003 and
later versions, when the forest functional level is Windows Server 2003 or a higher
functional level. Both of these intervals can be modified by editing the registry.

２ Warning

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, see Windows registry information for
advanced users.

To change the delay between the change to the Active Directory and first replication
partner notification, use Registry Editor to change the value data for the "Replicator
notify pause after modify (secs)" DWORD value in the following registry key:

Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Key: Replicator notify pause after modify (secs)
Value: REG_DWORD
To change the notification delay between domain controllers, use Registry Editor to
change the value data for the "Replicator notify pause between DSAs (secs)" DWORD
value in the following registry key:

Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Key: Replicator notify pause between DSAs (secs)
Value: REG_DWORD

７ Note

A setting also applies to Active Directory Application Mode (ADAM) and Active
Directory Lightweight Directory Services (AD LDS). For ADAM and for AD LDS, the
registry key is in the ADAM instance "Parameters" registry key.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

NTDS replication warning with Event ID
1093
Article • 02/19/2024

This article provides a solution to an NTDS warning event ID 1093.

Applies to: Windows Server 2012 R2

Original KB number: 2889671

Symptoms
When troubleshooting another issue, we found NTDS warning event ID 1093.

Event Type: Warning

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1093
Date: MM/DD/YYYY
Time: hh:mm:ss
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: DC02
Description:
Active Directory could not update the following object with attribute changes
because the incoming change caused the object to exceed the maximum object
record size. The incoming change to the following attribute will be reversed in an
attempt to complete the update.

Object:
CN=user01,OU=OU1,OU=OU2,OU=Users,DC=contoso,DC=com
Object GUID:
<GUID>
Attribute:
24 (userCertificate)

The current value (without changes) of the attribute on this domain controller will
replicate to all other domain controllers. This will counteract the change to the rest
of the replicated forest. The reversal values may be recognized as follows:
Version:
10277
Time of change:
 <DateTime>
Update sequence number:
614514713
For more information, see Help and Support Center at
https://go.microsoft.com/fwlink/events.asp .

This warning event ID 1093 indicates that the incoming change will not be replicated on
the current domain controller and it will be reversed. That is, the incoming updates on
the related object will be aborted to complete the AD replication. This warning will not
influence the AD replication.

Cause
The userCertificate attribute of the identified user (user01) holds a large number of
certificates, which is exceeding the maximum object record size.

Resolution
To solve the issue, the unwanted certificates need to be removed from userCertificate
attribute of the user object in Active Directory.

To identify which certificates are unwanted, you can refer to the method in the following
section.

More information
You may use this method to export the user data of the user object who reach the
maximum object size. Then identify the related certificates by the scripts and decide
which unwanted certificates can be deleted from this user object.

1. Export the user data by running the command on one of the domain controllers:
(output user_data.txt)

Console

ldifde -f user_data.txt -d "distinguishedname of the problem user

account" -p base

2. Prepare the script LDF2Certs.vbs with following contents:

VB
Option explicit
Const strVBSfile = "LDF2Certs.vbs"
Const ForReading = 1
Const StatusLookingForStart = 0
Const StatusLookingForEnd = 1
Dim strLDFFile
Call CommandParser()
WScript.Echo "!Open the input LDF file " & strLDFFile
Dim oFS
Set oFS = CreateObject("Scripting.FileSystemObject")
Dim objLDFFile
Set objLDFFile = oFS.OpenTextFile(strLDFFile, ForReading, False)
Dim strReadLine, lngStatus, objCertFile, lngCertNumber, strCertFile
lngStatus = StatusLookingForStart
lngCertNumber = 0
Do While objLDFFile.AtEndOfStream <> True
strReadLine = objLDFFile.ReadLine
If lngStatus = StatusLookingForEnd Then
If Not IsNull(strReadLine) Then
If InStr(strReadLine,":") > 0 Then
objCertFile.Close
Set objCertFile = Nothing
lngCertNumber = lngCertNumber + 1
lngStatus = StatusLookingForStart
Else
objCertFile.Write strReadLine
End If
End If
End If
If lngStatus = StatusLookingForStart Then
If Not IsNull(strReadLine) Then
If InStr(strReadLine,"userCertificate::") > 0 Then
WScript.Echo "!Found " & (lngCertNumber + 1) & " certificate"
strCertFile = "Cert" & Right("0000" & CStr(lngCertNumber), 4) &
".cer"
Set objCertFile = oFS.CreateTextFile(strCertFile, True, False)
lngStatus = StatusLookingForEnd
End If
End If
End If
Loop
objLDFFile.Close
Set objLDFFile = Nothing

Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
Sub CommandParser()'Glable variables: strLDFFile
If WScript.Arguments.Named.Exists("LDFFile") = True Then
strLDFFile = WScript.Arguments.Named.Item("LDFFile")
WScript.Echo "CommandParser: the LDF file name: " & strLDFFile
Else
Call ShowUsage()
End If
End Sub
 Sub ShowUsage()
WScript.Echo " "
WScript.Echo "Usage: CScript " & strVBSfile & " /LDFFile:<Input LDF
file name, such as input.txt>"
WScript.Quit
End Sub

3. Prepare the script doit.bat with following commands:

Console

cscript LDF2Certs.vbs /LDFFile:user_data.txt

dir /B Cert*.* > listofcerts.txt
FOR /F %%i IN (listofcerts.txt) DO echo %%i >> allcerts.txt && certutil
-dump %%i >> allcerts.txt

4. Put two scripts (LDF2Certs.vbs and doit.bat) and the user data (user_data.txt) in the
same folder and run script doit.bat. After running the script, text file allcerts.txt will
be generated, which contains all the certificates in the user data with detailed
information. Meanwhile, all the certificates will be dumped as .cer files in the same
folder as well.

７ Note

It may take some time as there are lots of certificates need to be dumped.

5. You can identify the certificates with their text or UI format and decide with
certificates can be removed from this user object.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of NTDS replication warning
IDs 1083 and 1061, and SAM error ID
12294 because of an Active Directory
collision
Article • 02/19/2024

This article provides help to fix an issue that occurs if a change that is made on the local
domain controller is also made on the domain controller that holds the PDC operations
master role.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 306091

Summary
Simultaneous changes against Active Directory object attributes on different domain
controllers may cause an Active Directory collision for the update. When this occurs,
NTDS replication warnings 1083 or 1061, or SAM error ID 12294 may be logged.

More information
The following events may be logged if immediate replication is triggered (for example,
by an urgent replication for a user lockout condition) and collides with the local Active
Directory update:

Event Type: Warning

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1083
Description:
Replication warning: The directory is busy. It couldn't update object CN=... with
changes made by directory GUID._msdcs.domain. Will try again later.

This indicates that the unsuccessful attempt of the remotely triggered update that will
be retried later:
 Event Type: Warning
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1061
Description:
Internal error: The directory replication agent (DRA) call returned error 8438.
(decimal 8438 / hex 0x20f6: ERROR_DS_DRA_BUSY, winerror.h)

If advanced NTDS logging is enabled, the following error ID may also be logged:

Event Type: Warning

Event Source: NTDS General
Event Category: Internal Processing
Event ID: 1173
Description:
Internal event: Exception e0010004 has occurred with parameters -1102 and 0
(Internal ID 2030537).
(JetDataBase ID -1102: JET_errWriteConflict -1102, Write lock failed due to
outstanding write lock)

If NTDS logging is set to 4 (Verbose) or higher in the Replication Events entry of the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics\ subkey, the
following error ID may also be logged:

Event Type: Warning

Event Source: NTDS Replication Event
Category: Replication
Event ID: 1413
Description:
The following object changes were not applied to the local Active Directory
database because the local metadata for the object indicates that the change is
redundant.

If the remotely triggered update wins against the local update, the following system
event may be logged for a user account lockout:

Event Type: Error

Event Source: SAM
Event Category: None
Event ID: 12294
 User: user-SID
Description:
The SAM database was unable to lock out the account of user due to a resource
error, such as a hard disk write failure (the specific error code is in the error data).
Accounts are locked after a certain number of bad passwords are provided so
consider resetting the password of the account mentioned above.
Data: 0000: c00002a5

You must analyze the error data to receive the correct error condition. DWord data
hexadecimal 0xc00002a5 = decimal -1073741147: STATUS_DS_BUSY, ntstatus.h).

After the warnings, an NTDS information event is logged that reports that the queued
update has already been made (with the same version ID) and is be ignored as
redundant:

Event Type: Information

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1413
Description:
Property 90296 (lockoutTime) of object CN=username,OU=... is not being applied to
the local database because its local metadata implies the change is redundant. The
local version is (version-ID).

When this condition exists, no replication error has occurred. Active Directory is
consistent and you can safely ignore the resulting event logs.

On a computer that is running Microsoft Windows Server, you can also determine
whether a replication error has occurred by exporting the replication meta-data of the
object. To do this, run the following command at a command prompt:

Console

repadmin /showobjmeta <domainController> <objectDN>

７ Note

In this command, make the following replacements for the placeholders:

Replace the domainController placeholder with the host name of a domain

controller.
 Replace the objectDN placeholder with the distinguished name of the
affected object.

In the output that this command generates, match the last update times of the attribute
to the times that the events were logged. From this information, you can determine
which attribute caused the replication error.

Generally, you experience this problem with the lockoutTime attribute or with one of the
password attributes. In these cases, you can safely ignore the events. The events occur
because the change that occurs on the primary domain controller (PDC) is also written
to the local domain controller. At the same time, the change is replicated among the
domain controllers. For lockoutTime, the change is replicated urgently in the site of the
PDC.

Because of the short replication notification intervals that you can have in Microsoft
Windows Server, you may experience a replication collision in the same site of the PDC.
Password changes are one example of a scenario in which you may experience a
replication collision. This behavior occurs because a domain controller forwards new
passwords to the PDC. Both the PDC and the local domain controller then replicate the
changed password information. Therefore, a replication collision may occur on another
domain controller in the same site. For more information about replication notification,
click the following article number to view the article in the Microsoft Knowledge Base:
214678 How to modify the default intra-site domain controller replication interval

To help reduce the generation of replication collision events, configure the PDC in a site
that does not have other domain controllers or client computers. In this scenario, the
PDC does not urgently replicate updates that it receives. Therefore, you may reduce the
risk of replication collisions. In a large domain, you can use this method to help reduce
the load on the PDC.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
NTFRS deprecation intentionally blocks
the installation of Windows Server
version 1709 replica DCs
Article • 02/19/2024

Applies to: Windows Server 2016

Original KB number: 4023141

Symptom
When you use the Install-ADDSDomainController cmdlet to install a replica-domain
controller that's running Windows Server version 1709 to a NTFRS-enabled domain, the
installation fails, and you receive the following error message:

The specified domain %1 is still using the File Replication Service (FRS) which is
deprecated. This server does not support FRS and cannot be promoted as a replica
into the specified domain. You should migrate the specified domain to use DFS
Replication by using the DFSRMIG command before continuing.

For more information, see https://go.microsoft.com/fwlink/?linkid=849270 .

If the Windows Server version is earlier than Windows Server version 1709, you receive
the following message:

The File Replication Service (FRS) is deprecated. To continue replicating the SYSVOL
folder, you should migrate to DFS Replication by using the DFSRMIG command. If
you continue to use FRS for SYSVOL replication in this domain, you might not be
able to add domain controllers running a future version of Windows Server.

Servers that indirectly run the Install-ADDSDomainController cmdlet in Server Manager

are also affected.

Cause
This behavior is intended and by design and consistent with previous announcements
about the deprecation of NTFRS in future versions of Windows. Windows Server 2016 is
the initial release that ends support of NTFRS.
Resolution
Use the steps in the following article to migrate sysvol replication from FRS to DFSR:

Sysvol replication Migration Guide: FRS to DFS replication

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory Replication Error 1753:
There are no more endpoints available
from the endpoint mapper
Article • 02/19/2024

This article describes an issue where Active Directory Replications fail with Win32 error
1753: "There are no more endpoints available from the endpoint mapper."

Applies to: Windows Server 2012 R2

Original KB number: 2089874

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft Community .

Symptoms
This article describes symptoms, cause, and resolution steps for AD operations that fail
with Win32 error 1753: "There are no more endpoints available from the endpoint
mapper."

1. DCDIAG reports that the Connectivity test, Active Directory Replications test, or
KnowsOfRoleHolders test has failed with error 1753: "There are no more endpoints
available from the endpoint mapper."

Testing server: <site><DC Name>

Starting test: Connectivity
*Active Directory LDAP Services Check * Active Directory RPC Services Check
[<DC Name>] DsBindWithSpnEx() failed with error 1753,
There are no more endpoints available from the endpoint mapper..
Printing RPC Extended Error Info:
Error Record 1, ProcessID is <process ID> (DcDiag)
System Time is: <date> <time>
Generating component is 2 (RPC runtime) Status is 1753: There are no more
endpoints available from the endpoint mapper. Detection location is 500
NumberOfParameters is 4
Unicode string: ncacn_ip_tcp
Unicode string: <source DC object GUID>._msdcs.contoso.com
Long val: -481213899
Long val: 65537
 Error Record 2, ProcessID is 700 (DcDiag)
System Time is: <date> <time>
Generating component is 2 (RPC runtime)
Status is 1753: There are no more endpoints available from the endpoint
mapper.
NumberOfParameters is 1
Unicode string: 1025

[Replications Check,<DC Name>] A recent replication attempt failed:

From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The replication generated an error (1753):
There are no more endpoints available from the endpoint mapper.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
3 failures have occurred since the last success.
The directory on <DC name> is in the process.
of starting up or shutting down, and is not available.
Verify machine is not hung during boot.

2. REPADMIN.EXE reports that replication attempt has failed with status 1753.

REPADMIN commands that commonly cite the 1753 status include but aren't
limited to:

REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL

The following sample output from REPADMIN /SHOWREPS shows that inbound
replication from CONTOSO-DC2 to CONTOSO-DC1 fails with the "replication
access was denied" error:

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID:
DSA invocationID:

DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
 DSA object GUID:
Last attempt @ <date> <time> failed, result 1753 (0x6d9):
There are no more endpoints available from the endpoint mapper.
<#> consecutive failure(s).
Last success @ <date> <time>.

3. The "Check Replication Topology" command in Active Directory Sites and Services
returns "there are no more endpoints available from the endpoint mapper."

Right-clicking on the connection object from a source DC and choosing "Check

Replication Topology" fails with "There are no more endpoints available from the
endpoint mapper. The on-screen error message is shown below:

Dialog Title Text: Check Replication Topology

Dialog Message text:

The following error occurred during the attempt to contact the domain
controller: There are no more endpoints available from the endpoint mapper.

OK

4. The "replicate now" command in Active Directory Sites and Services returns "there
are no more endpoints available from the endpoint mapper."

Right-clicking on the connection object from a source DC and choosing "replicate

now" fails with "There are no more endpoints available from the endpoint mapper.
The on-screen error message is shown below:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to
synchronize naming context <directory partition name> from Domain
Controller <Source DC> to Domain Controller <Destination DC>: There are no
more endpoints available from the endpoint mapper

The operation will not continue

Buttons in Dialog: OK

5. NTDS Knowledge Consistency Checker (KCC), NTDS General, or Microsoft-

Windows-ActiveDirectory_DomainService events with the 1753 status are logged in
the directory service event log.
 Active Directory events that commonly cite the 1753 status include but aren't
limited to:

ﾉ Expand table

Event Event Event String

Source ID

NTDS 1655 Active Directory attempted to communicate with the following global
General catalog and the attempts were unsuccessful.

NTDS 1925 The attempt to establish a replication link for the following writable
KCC directory partition failed.

NTDS 1265 An attempt by the Knowledge Consistency Checker (KCC) to add a

KCC replication agreement for the following directory partition and source
domain controller failed.

Cause
The diagram below shows the Remote Procedure Call (RPC) workflow. The workflow
starts with the registration of the server application with the RPC Endpoint Mapper
(EPM) in step 1. It ends with the passing of data from the RPC client to the client
application in step 7.
Steps 1 through 7 map to the following operations:

1. Server app registers its endpoints with the RPC Endpoint Mapper (EPM).
2. Client makes an RPC call on behalf of a user, OS, or application-initiated operation.
3. Client-side RPC contacts the target computers EPM and asks for the endpoint to
complete the client call.
4. Server Machine's EPM responds with an endpoint.
5. Client-side RPC contacts the server app.
6. Server app executes the call, returns the result to the client RPC.
7. Client-side RPC passes the result back to the client app.

Failure 1753 is generated by a failure between steps 3 and 4. Specifically, error 1753
means that the RPC client (destination DC) could contact the RPC Server (source DC)
over port 135, but the EPM on the RPC Server (source DC) couldn't locate the RPC
application of interest and returned server-side error 1753. The error indicates that the
RPC client (destination DC) received the server-side error response from the RPC Server
(AD replication source DC) over the network.

Specific root causes for the 1753 error include:

 1. The server app never started. That is, step 1 in the "more information" diagram was
never attempted.
2. The server app started, but there was some failure during initialization. The failure
prevented it from registering with the RPC Endpoint Mapper. That is, step 1 in the
"more information" diagram was attempted but failed.
3. The server app started, but later died. That is, step 1 in the "more information"
diagram was completed successfully. It was undone later because the server died.
4. The server app manually unregistered its endpoints (similar to 3 but intentional.
Not likely but included for completeness.)
5. The RPC client (destination DC) contacted a different RPC server than the intended
one. It's because of a Name to IP-mapping error in DNS, WINS, or host / lmhosts
file.

Error 1753 is NOT caused by:

a lack of network connectivity between the RPC client (destination DC) and RPC
Server (source DC) over port 135.
a lack of network connectivity between the RPC server (source DC) using port 135
and the RPC client (destination DC) over the ephemeral port.
a password mismatch or the inability by the source DC to decrypt a Kerberos
encrypted packet.

Resolution

Verify that the service registering its service with the

endpoint mapper has started
For Windows 2000 and Windows Server 2003 DCs: ensure that the source DC is
booted into normal mode.
For Windows Server 2008 or Windows Server 2008 R2: from the console of the
source DC, start Services Manager (services.msc). Verify that the Active Directory
service is running. Active Directory appears as "Active Directory Domain Services"

Verify that RPC client (destination DC) connected to the

intended RPC Server (source DC)
All DCs in a common Active Directory forest register a GUIDED DC CNAME record in the
_msdcs.<forest root domain> DNS zone, regardless of what domain they reside in
within the forest. The guided DC CNAME record is derived from the objectGUID of each
DCs NTDS Settings object.
When doing replication-based operations, a destination DC queries DNS for the source
DCs GUIDED CNAME record. The CNAME record contains the source DC's fully qualified
computer name. This name is used to derive the source DCs IP address via:

DNS client cache lookup

Host / LMHost file lookup
host A / AAAA record in DNS or WINS

Stale NTDS Settings objects and bad name to IP mappings in DNS, WINS, Host, and
LMHOST files may cause the RPC client (destination DC) to connect to the wrong RPC
Server (Source DC). Furthermore, the bad name to IP mapping may cause the RPC client
(destination DC) to connect to a computer that doesn't even have the RPC Server
Application of interest (the Active Directory role in this case) installed. For example, a
stale host record for DC2 contains the IP address of DC3 or a member computer.

Verify that the following GUIDs match:

the object GUID for the source DC that exists in the destination DCs' copy of Active
Directory
the source DC object GUID stored in the source DCs' copy of Active Directory.

If there's a discrepancy, use repadmin /showobjmeta on the NTDS settings object to see
which one corresponds to last promotion of the source DC. Compare the following date
stamps:

The NTDS Settings object create date from /showobjmeta .

The last promotion date in the source DCs dcpromo.log file.

You may have to use the last modify / create date of the DCPROMO.LOG file itself. If the
object GUIDs aren't identical, the destination DC may have a stale NTDS Settings object
for the source DC whose CNAME record refers to a host record with a bad name to IP
mapping.

On the destination DC, run IPCONFIG /ALL to determine which DNS Servers the
destination DC is using for name resolution:

Console

c:\>ipconfig /all

On the destination DC, run NSLOOKUP against the source DCs fully qualified DC CNAME
record:

Console
 c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination
DCs primary DNS Server IP >
c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination
DCs secondary DNS Server IP>

Verify that the IP address returned by NSLOOKUP "owns" the host name / security identity
of the source DC.

a) C:\\>NBTSTAT -A \\<IP address _returned_ by NSLOOKUP in the step above>

OR

b) Sign in to the console of the source DC, run IPCONFIG from the CMD prompt and
verify that the source DC owns the IP address returned by the NSLOOKUP command
above.

Check for stale / duplicate host to IP mappings in DNS.

Console

NSLOOKUP -type=hostname \<single label hostname of source DC> \<primary DNS

Server IP on destination DC>
NSLOOKUP -type=hostname \<single label hostname of source DC> \<secondary
DNS Server IP on destination DC>

NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \

<primary DNS Server IP on destination DC>
NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \
<secondary DNS Server IP on dest. DC>

If invalid IP addresses exist in host records, investigate whether DNS scavenging is

enabled and properly configured.

If the tests above or a network trace doesn't show a name query returning an invalid IP
address, consider stale entries in HOST files, LMHOSTS files, and WINS Servers. DNS
Servers can also be configured to perform WINS fallback name resolution.

Verify that the server application (Active Directory, and so

on) has registered with the endpoint mapper on the RPC
server (source DC)
Active Directory uses a mix of well-known and dynamically registered ports. Well-known
ports and protocols used by Active Directory domain controllers include:
 ﾉ Expand table

RPC Server Application Port TCP UDP Comments

DNS Server 53 √ √

Kerberos 88 √ √

LDAP Server 389 √ √

Microsoft-DS 445 √ √

LDAP SSL 636 √ √

Global Catalog Server 3268 √

Global Catalog Server 3269 √

Well-known ports are NOT registered with the endpoint mapper.

Active Directory and other applications also register services that receive dynamically
assigned ports in the RPC ephemeral port range. Such RPC server applications are
dynamically assigned TCP ports between 1024 and 5000 on Windows 2000 and
Windows Server 2003 computers. They are dynamically assigned TCP ports between
49152 and 65535 range on Windows Server 2008 and Windows Server 2008 R2
computers. The RPC port used by replication can be hard-coded in the registry using the
steps documented in MSKB 224196 . Active Directory continues to register with the
EPM when configured to use a hard-coded port.

Verify that the RPC Server application of interest has registered itself with the RPC
endpoint mapper on the RPC Server (the source DC in the case of AD replication).

There are many ways to accomplish this task. One is to install and run PORTQRY from
an admin privileged command prompt on the console of the source DC:

Console

c:\>portquery -n \<source DC> -e 135 >file.txt

In the portqry output, note the port numbers dynamically registered by the "MS NT
Directory DRS Interface" (UUID = 351...) for the ncacn_ip_tcp protocol. The snippet
below shows a sample output from a Windows Server 2008 R2 DC and the UUID /
protocol pair used by Active Directory highlighted in bold:

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface

ncacn_np:CONTOSO-DC01[\pipe\lsass]
 UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_np:CONTOSO-DC01[\PIPE\protected_storage]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_ip_tcp:CONTOSO-DC01[49156]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_http:CONTOSO-DC01[49157]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_http:CONTOSO-DC01[6004]

Other causes
1. Verify that the source DC is booted in normal mode. And verify that the OS and DC
role on the source DC have fully started.

2. Verify that the Active Directory Domain Service is running. If the service is currently
stopped or wasn't configured with default startup values, reset the default startup
values. Reboot the modified DC, and then retry the operation.

3. Verify that the startup value and service status for RPC service and RPC Locator is
correct for OS version of the RPC Client (destination DC) and RPC Server (source
DC). If the service is currently stopped or wasn't configured with default startup
values, reset the default startup values. Reboot the modified DC, and then retry the
operation.

Also ensure that the service context matches default settings.

ﾉ Expand table

Windows 2000 Startup Value Service Status

Remote Procedure Call (RPC) Automatic Started

Remote Procedure Call (RPC) Locator Automatic Started

Windows Server 2003, Server 2008, Server 2008 R2 Startup Value Service Status

Remote Procedure Call (RPC) Automatic Started

Remote Procedure Call (RPC) Locator Manual Null or Stopped

4. Verify that the size of the dynamic port range hasn't been constrained. The
Windows Server 2008 and Windows Server 2008 R2 NETSH syntax to enumerate
the RPC port range is shown below:
 Console

>netsh int ipv4 show dynamicport tcp

>netsh int ipv4 show dynamicport udp
>netsh int ipv6 show dynamicport tcp
>netsh int ipv6 show dynamicport udp

5. Review KB 224196 . Ensure that the hard-coded port falls within the ephemeral
port range for the source DC's OS version.

6. Verify that the ClientProtocols key exists under HKLM\Software\Microsoft\Rpc and

contains the following five default values:

Console

ncacn_http REG_SZ rpcrt4.dll

ncacn_ip_tcp REG_SZ rpcrt4.dll
ncacn_nb_tcp REG_SZ rpcrt4.dll
ncacn_np REG_SZ rpcrt4.dll
ncacn_ip_udp REG_SZ rpcrt4.dll

More information

Example of a bad name to IP mapping causing RPC error

1753 vs. -2146893022: the target principal name is
incorrect
The contoso.com domain consists of \\DC1 and \\DC2 with IP addresses x.x.1.1 and
x.x.1.2. The host "A" / "AAAA" records for \\DC2 are correctly registered on all of the
DNS Servers configured for \\DC1. In addition, the HOSTS file on \\DC1 contains an
entry-mapping DC2's fully qualified hostname to IP address x.x.1.2. Later, DC2's IP
address changes from X.X.1.2 to X.X.1.3 and a new member computer is joined to the
domain with IP address x.x.1.2. AD Replication attempts triggered by the "replicate now"
command in Active Directory Sites and Services snap-in fails with error 1753. The trace is
shown below:

F# SRC DEST Operation

1 x.x.1.1 x.x.1.2 ARP:Request, x.x.1.1 asks for x.x.1.2
2 x.x.1.2 x.x.1.1 ARP:Response, x.x.1.2 at 00-13-72-28-C8-5E
3 x.x.1.1 x.x.1.2 TCP:Flags=......S., SrcPort=50206, DstPort=DCE endpoint
resolution(135)
4 x.x.1.2 x.x.1.1 ARP:Request, x.x.1.2 asks for x.x.1.1
 5 x.x.1.1 x.x.1.2 ARP:Response, x.x.1.1 at 00-15-5D-42-2E-00
6 x.x.1.2 x.x.1.1 TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135)
7 x.x.1.1 x.x.1.2 TCP:Flags=...A...., SrcPort=50206, DstPort=DCE endpoint
resolution(135)
8 x.x.1.1 x.x.1.2 MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA}
EPT(EPMP)
9 x.x.1.2 x.x.1.1 MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0x5E68 Xmit=0x16D0
Recv=0x16D0
10 x.x.1.1 x.x.1.2 EPM:Request: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-
AB04-00C04FC2DCD2} [DCE endpoint resolution(135)]
11 x.x.1.2 x.x.1.1 EPM:Response: ept_map: 0x16C9A0D6 - EP_S_NOT_REGISTERED

At frame 10, the destination DC queries the source DCs' end-point mapper over port 135
for the Active Directory replication service class UUID {E351...}

In frame 11, the source DC, in this case a member computer, doesn't yet host the DC
role. So it hasn't registered the {E351...} UUID for the Replication service with its local
EPM. The source DC responds with symbolic error EP_S_NOT_REGISTERED. This error
maps to decimal error 1753, hex error 0x6d9, and friendly error "there are no more
endpoints available from the endpoint mapper".

Later, the member computer with IP address x.x.1.2 gets promoted as a replica
"MayberryDC" in the contoso.com domain. Again, the "replicate now" command is used
to trigger replication, but this time fails with the on-screen error "the target principal
name is incorrect". The computer whose NIC owns the IP address x.x.1.2 is a domain
controller. It's currently booted into normal mode, and has registered the {E351...}
replication service UUID with its local EPM. But it doesn't own the name / security
identity of DC2, and can't decrypt the Kerberos request from DC1. So the request fails
with error "The target principal name is incorrect.". This error maps to decimal error
-2146893022, hex error 0x80090322.

Such invalid host-to IP mappings could be caused by stale entries in host / lmhost files,
host A / AAAA registrations in DNS or WINS.

Summary:

Example 1 failed because of an invalid host to IP mapping (in the HOST file in this
case). It caused the destination DC to resolve to a "source" DC that didn't have the
AD service running (or even installed for that matter). So the replication SPN wasn't
yet registered, and the source DC returned error 1753.
In the second case, an invalid host to IP mapping (again in the HOST file) caused
the destination DC to connect to a DC that had registered the {E351...} replication
 SPN. But that source had a different hostname and security identity than the
intended source DC, so the attempts failed with error -2146893022: The target
principal name is incorrect.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Related Content
Service overview and network port requirements for the Windows Server system
Restricting Active Directory replication traffic and client RPC traffic to a specific
port
How to configure RPC dynamic port allocation to work with firewall
How RPC works
How to server prepares for a connection
How the client establishes a connection
Registering the interface
Making the Server available on the network
Registering endpoints
Listening for client calls
How the client establishes a connection
224196 Restricting Active Directory replication traffic and client RPC traffic to a
specific port
SPN for a target DC in AD DS

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory Replication Error 8524:
The DSA operation is unable to proceed
because of a DNS lookup failure
Article • 02/19/2024

This article describes symptoms, cause, and resolution steps for AD operations that fail
with Win32 error 8524:

The DSA operation is unable to proceed because of a DNS lookup failure.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2021446

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft Community .

Symptoms
1. DCDIAG reports that Active Directory Replications test has failed with status 8524:

Testing server: <sitename><destination DC>

Starting test: Replications
[Replications Check,<destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context:
CN=<DN path for failing directory partition>,DC=Contoso,DC=Com
The replication generated an error (8524):
The DSA operation is unable to proceed because of a DNS lookup failure.

2. REPADMIN reports that a replication attempt has failed with status 8524.

REPADMIN commands that commonly cite the 8524 status include, but aren't
limited to:

REPADMIN /REPLSUM
REPADMIN /SHOWREPS

REPADMIN /SHOWREPL

A sample of 8524 failures from REPADMIN /SHOWREPL is shown below:

 Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: DSA invocationID:
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID:
Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8524 (0x214c):
The DSA operation is unable to proceed because of a DNS lookup failure.
1 consecutive failure(s).
Last success @ YYYY-MM-DD HH:MM:SS.

Rest of /showrepl output truncated

3. One of the following events with the 8524 status are logged in the directory
service event log:

NTDS Knowledge Consistency Checker (KCC)

NTDS General
Microsoft-Windows-ActiveDirectory_DomainService

Active Directory events that commonly cite the 8524 status include but aren't
limited to:

ﾉ Expand table

Event Source Event String

Microsoft-Windows- 2023 This directory server was unable to

ActiveDirectory_DomainService replicate changes to the following remote
directory server for the following directory
partition

NTDS General 1655 Active Directory attempted to

communicate with the following global
catalog and the attempts were
unsuccessful.

NTDS KCC 1308 The KCC has detected that successive

attempts to replicate with the following
directory service has consistently failed.
 Event Source Event String

NTDS KCC 1865 The KCC was unable to form a complete

spanning tree network topology. As a
result, the following list of sites can't be
reached from the local site

NTDS KCC 1925 The attempt to establish a replication link

for the following writable directory
partition failed.

NTDS KCC 1926 The attempt to establish a replication link

to a read-only directory partition with the
following parameters failed

4. Domain controllers log NTDS Replication event 2087 and NTDS Replication event
2088 in their Directory Service event log:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <date> <time>
Event ID: 2087
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <dc name>.<domain name>
Description:

Active Directory Domain Services couldn't resolve the following DNS host
name of the source domain controller to an IP address. This error prevents
additions, deletions, and changes in Active Directory Domain Services from
replicating between one or more domain controllers in the forest. Security
groups, group policy, users, and computers and their passwords will be
inconsistent between domain controllers until this error is resolved. It
potentially affects logon authentication and access to network resources.

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <date> <time>
Event ID: 2088
 Task Category: DS RPC Client
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <dc name>.<domain name>
Description:
Active Directory Domain Services couldn't use DNS to resolve the IP address of
the source domain controller listed below. To maintain the consistency of
Security groups, group policy, users, and computers and their passwords,
Active Directory Domain Services successfully replicated using the NetBIOS or
fully qualified computer name of the source domain controller.

Invalid DNS configuration may be affecting other essential operations on

member computers, domain controllers, or application servers in this Active
Directory Domain Services forest, including logon authentication or access to
network resources.

You should immediately resolve this DNS configuration error so that this
domain controller can resolve the IP address of the source domain controller
using DNS.

Cause
Error Status 8524 maps to the following error string:

The DSA operation is unable to proceed because of a DNS lookup failure.

It's a catch-all error for all possible DNS failures affecting Active Directory on post
Windows Server 2003 SP1 domain controllers.

Microsoft-Windows-ActiveDirectory_DomainService event 2087 is a partner event to

other Active Directory events that cite the 8524 status if an Active Directory domain
controller is unable to resolve a remote DC by its fully qualified CNAME record (<object
guid for source DCs NTDS Settings object>._msdcs.<forest root domain>) using DNS.

Microsoft-Windows-ActiveDirectory_DomainService event 2088 is logged when a source

domain controller is successfully resolved by its NetBIOS name but such name
resolution fallback only occurs when DNS name resolution fails.

The presence of the 8524 status and the Microsoft-Windows-

ActiveDirectory_DomainService event 2088 or 2087 events all indicate that DNS name
resolution is failing Active Directory.
In summary, the 8524 replication status is logged when a destination DC can't resolve
the source DC by its CNAME and Host "A" or Host "AAAA" records using DNS. Specific
root causes include:

1. The source DC is offline, or no longer exists, but its NTDS Settings object still exist
in the destination DCs' copy of Active Directory.

2. The source DC failed to register the CNAME or host records on one or more DNS
Servers because of the following reasons:

The registration attempts failed.

DNS client settings on the source don't point to DNS Servers that either host,
forwarded or delegate its _msdcs.<forest root domain zone and (or) primary
DNS suffix domain zones>.

3. DNS client settings on the destination DC don't point to DNS Servers that either
host, forward or delegate the DNS zones containing the CNAME or host records
for the source DC

4. CNAME and host records registered by the source DC don't exist on DNS servers
queried by the destination DC because of the following reasons:

Simple replication latency

A replication failure
A zone transfer failure

5. Invalid forwarders or delegations. They prevent the destination DC from resolving

CNAME or Host records for DCs in other domains in the forest.

6. DNS Servers used by destination DC, source DC, or intermediate DNS Servers
aren't functioning properly.

Resolution

Verify whether the 8524 is caused by an offline DC or

stale DC metadata
If the 8524 error/event refers to a DC that's currently offline but still valid in the forest,
make it operational.

If the 8524 error/event refers to an inactive DC, remove the stale metadata for that DC
from the destination DCs' copy of Active Directory. An inactive DC is a DC install that no
longer exists on the network, but its NTDS Settings object still exists in the destination
DCs' copy of Active Directory -

Microsoft support regularly finds stale metadata for nonexistent DCs, or stale metadata
from previous promotions of a DC with the same computer name that hasn't been
removed from Active Directory.

Remove stale DC metadata if present

GUI Metadata Cleanup using Active Directory Sites and Services

(DSSITE.MSC)

1. Start the Windows Server 2008 or Windows Server 2008 R2 Active Directory Sites
and Services snap-in (DSSITE.MSC).

It can also be done by starting the Active Directory Sites and Services on a
Windows Vista or Windows 7 computer that has been installed as part of the
Remote Server Administration Tools (RSAT) package.

2. Focus the DSSITE.MSC snap-in on the destination DCs' copy of Active Directory.

After starting DSSITE.MSC, right-click the "Active Directory Sites and Services [<DC
Name>]

Select the destination DC that's logging the 8524 error/event from the list of DCs
visible in the "Change Domain Controller..." list

3. Delete the source DCs NTDS Settings object referenced in the 8524 errors and
events. Active Directory Users and Computers (DSA.MSC) snap-in and delete either
the source DCs NTDS Settings object.

A DCs NTDS Settings object appears

Below the Sites, Site Name, Servers container, and %server name% container
Above the inbound connection object displayed in the right pane of Active
Directory Sites and Services.

The red highlight in the screenshot below shows the NTDS Settings object for
CONTOSO-DC2 located below the Default-First-Site-Name site.
 Right-click the stale NTDS Settings object you want to remove, then select
"Delete."

Metadata cleanup can also be done from the W2K8 / W2K8 R2 Active Directory
Users and Computers snap-in as documented in TECHNET .

Command-line Metadata Cleanup using NTDSUTIL

The legacy or command-line method of deleting stale NTDS Settings objects using the
NTDSUTIL metadata cleanup command is documented in MSKB 216498 .

Run DCDIAG /TEST:DNS on the source DC + destination DC

DCDIAG /TEST:DNS does seven different tests to quickly vet the DNS health of a domain

controller. This test isn't run as part of the default execution of DCDIAG.

1. Sign in with Enterprise Admin credentials to the console of the destination domain
controllers that log the 8524 events.

2. Open an administrative privileged CMD prompt, and then run DCDIAG /TEST:DNS
/F on the DC logging the 8424 status and the source DC that the destination DC is

replicating from.

To run DCDIAG against all DCs in a forest, type DCDIAG /TEST:DNS /V /E /F:<File
name.txt> .

To run DCDIAG TEST:DNS against a specific DC, type DCDIAG /TEST:DNS /V /S:<DC
NAME> /F:<File name.txt> .

3. Locate the summary table at the end of the DCDIAG /TEST:DNS output. Identify and
reconcile warning or failure conditions on the relevant DCs of the report.

4. If DCDIAG doesn't identify the root cause, take "the long way around" using the
steps below.
Check Active Directory Name Resolution using PING
Destination DCs resolve source DCs in DNS by their fully qualified CNAME records that
are derived from the object GUID of the remote DCs NTDS Settings object (the parent
object to connection objects visible in the Active Directory Sites and Services snap-in).
You can test a given DCs' ability to resolve a source DC fully qualified CNAME record
using the PING command.

1. Locate the objectGUID of the source DCs NTDS Settings object in the source DCs'
copy of Active Directory.

From the console of the source DC logging the 8524 error/event, type:

repadmin /showrepl <fully qualified hostname of source DC cited in the 8524

error (event)>

For example, if the DC referenced in the 8524 error/event is contoso-DC2 in the

contoso.com domain, type:

repadmin /showrepl contoso-dc2.contoso.com

The "DSA Object GUID" field in the header of the repadmin /SHOWREPl command
contains the objectGUID of the source DCs current NTDS settings object. Use the
source DCs' view of its NTDS Settings Object in case replication is slow or failing.
The header of the repadmin output will look something like:

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- right click +
copy this string to the Windows
<- clipboard & paste into it the PING command in
<- step 4

2. Locate the ObjectGUID of the source DC in the destination DCs' copy of Active
Directory.

From the console of the destination DC logging the 8524 error/event, type:

repadmin /showrepl <fully qualified hostname of destination DC>

For example, if the DC logging 8524 error/event is contoso-DC1 in the

contoso.com domain, type:
 repadmin /showrepl contoso-dc1.contoso.com

REPADMIN /SHOWREPL output is shown below. The "DSA Object GUID" field is listed

for each source DC the destination DC inbound replicates from.

Console

c:\>repadmin /showreps `contoso-dc1.contoso.com`

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID:
DSA invocationID:
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016 <-
Object GUID for source DC derived from
Last attempt @ 2010-03-24 15:45:15 failed, result 8524
(0x214c): \ destination DCs copy of Active Directory
The DSA operation is unable to proceed because of a DNS
lookup failure.
23 consecutive failure(s).
Last success @ YYYY-MM-DD HH:MM:SS.

3. Compare the object GUID from #2 and #3.

If the object GUIDS are the same, then the source DC and destination DC know
about the same instantiation (the same promotion) of the source DC. If they're
different, then figure which one was created later. The NTDS setting object with
the earlier create date is likely stale and should be removed.

4. PING the source DC by its fully qualified CNAME.

From the console of the destination DC, test Active Directory's name resolution
with a PING of the source DCs fully qualified CNAME record:

c:\>ping <ObjectGUID> from source DCs NTDS Settings object._msdcs.<DNS name

for Active Directory forest root domain>

Using our example of the 8a7baee5... objectGUID from the repadmin /showreps
output above from the contoso-dc1 DC in the contoso.com domain, the PING
syntax would be:

c:\>ping 8a7baee5-cd81-4c8c-9c0f-b10030574016. _msdcs.contoso.com

If ping works, retry the failing operation in Active Directory. If PING fails, proceed
to the "Resolve the 8524 DNS lookup failure" but retrying the PING test after each
 step until it resolves.

Resolve the 8524 DNS lookup failure: The long way

around
If the 8524 error/events aren't caused by stale DC metadata, and the CNAME PING test
fails, vet the DNS health of:

The source DC
The destination DC
The DNS Servers used by the source and destination DCs

In summary, verify that:

The source DC has registered the CNAME and host records with a valid DNS.
The destination DC points to valid DNS Servers.
The records of interest registered by source DCs are resolvable by destination DCs.

The error message text in DS RPC Client event 2087 documents a user action for
resolving the 8524 error. A more detailed action plan follows:

1. Verify that the source DC points to valid DNS Servers

On the source DC, verify that DNS Client settings point exclusively to operational
DNS Severs that either host, forward or delegate the_msdcs.<forest root domain>
zone (that is, All DCs in the contoso.com forest register CNAME records in
the_msdcs.contoso.com zone)

AND

The DNS zone for the Active Directory domain (that is, a computer in the
contoso.com domain would register host records in contoso.com zone).

AND

The computers primary DNS suffix domain if different from the Active Directory
domain name (see Technet article Disjoint Namespace ).

Options to validate that a DNS Server hosts, forwards, or delegates (that is, "can
resolve") such zones include.

Start the DNS management tool for your DNS and verify the DNS Servers to
which the source DC points for name resolution host the zones in question.
 Use NSLOOKUP to verify that all of the DNS Servers that the source DC points
to can resolve queries for the DNS zones in question.

Run IPCONFIG /ALL on the console of the source DC

Console

c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.99 <- Primary DNS
Server IP>
10.45.42.101<-
Secondary DNS Server IP>

Run the following NSLOOKUP queries:

Console

c:\>nslookup -type=soa <Source DC DNS domain name> <source DCs

primary DNS Server IP >
c:\>nslookup -type=soa < Source DC DNS domain name > <source DCs
secondary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source
DCs primary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source
DCs secondary DNS Server IP >

For example, if a DC in the CHILD.CONTOSO.COM domain of the contoso.com

forest is configured with the primary and secondary DNS Server IPs
"10.45.42.99" and "10.45.42.101", the NSLOOKUP syntax would be:

Console

c:\>nslookup -type=soa child.contoso.com 10.45.42.99

c:\>nslookup -type=soa child.contoso.com 10.45.42.101
c:\>nslookup -type=soa _msdcs.contoso.com 10.45.42.99
c:\>nslookup -type=soa _msdcs.contoso.com 10.45.42.101

Notes:

The SOA query for the _mscs.contoso.com zone will resolve correctly if the
targeted DNS has a good forwarder or delegation or for the_msdcs.<forest
root zone>. It won't resolve correctly if the _msdcs.<forest root zone> on the
DNS Server being queried is a non-delegated subdomain of <forest root
zone> that is the zone relationship created by Windows 2000 domains.
 CNAME records are always registered in the _msdcs.<forest root zone>, even
for DC in non-root domains.
Configuring the DNS client of a DC or member computer to point to an ISP
DNS Server for name resolution is invalid. The only exception is that ISP has
been contracted (that is, paid), and is currently hosting, forwarding, or
delegating DNS queries for your Active Directory forest.
ISP DNS Servers typically don't accept dynamic DNS updates so CNAME,
Host, and SRV records may have to be manually registered.

2. Verify that the source DC has registered its CNAME record

Use step 1 from "Check Active Directory Name Resolution using PING" to locate
the current CNAME of the source DC.

Run ipconfig /all on the console of the source DC to determine to which DNS
Servers the source DC points for name resolution.

Console

c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.99
<primary DNS Server IP
10.45.41.101
<secondary DNS Server IP

Use NSLOOKUP to query the current DNS Servers for the source DCs' CNAME
record (found via the procedure in "Check Active Directory Name Resolution using
PING").

Console

c:\>nslookup -type=cname <fully qualified cname of source DC> <source

DCs primary DNS Server IP >
c:\>nslookup -type=cname <fully qualified cname of source DC> <source
DCs secondary DNS Server IP>

In the example, the NTDS Settings objectGUID for contoso-dc2 in the contoso.com
domain is 8a7baee5-cd81-4c8c-9c0f-b10030574016. It points to "10.45.42.99" as
primary for DNS name resolution. The NSLOOKUP syntax would be:

Console

c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-

b10030574016._msdcs.contoso.com 10.45.42.99
 c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-
b10030574016._msdcs.contoso.com 10.45.42.101

If the source DC hasn't registered its CNAME record on the DNS Servers it points
to for name resolution, run the following command from the source DC. Then
recheck the registration of the CNAME record:

Console

c:\>net stop netlogon & net start netlogon

Notes:

CNAME records are always registered in the _msdcs.<forest root zone>, even
for DC in non-root domains.
CNAME records are registered by the NETLOGON Service during OS startup,
NETLOGON service startup, and recurring intervals later.
Each promotion of a DC with the same name may create a new NTDS
Settings object with a different objectGUID that therefore registers a different
CNAME record. Verify registration of the CNAME record based the last
promotion of the source DC vs. the objectGUID for the NTDS Settings object
on the destination DC if the source has been promoted more than 1x.
Timing issues during OS startup can delay successful Dynamic DNS
registration.
If a DC's CNAME record was successfully registered, but later disappears,
check KB953317 . Duplicate DNS zones in different replication scopes or
overly aggressive DNS scavenging by the DNS Server.
If the CNAME record registration is failing on the DNS servers to which the
source DC points for name resolution, review NETLOGN events in the SYSTEM
event log for DNS registration failures.

3. Verify that the source DC has registered its host records

From the console of the source DC, run ipconfig /all to determine to which DNS
Servers the source DC points for name resolution.

Console

c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.99 <- Primary DNS Server
IP>
 10.45.42.101<- Secondary DNS
Server IP>

Use NSLOOKUP to query the current DNS Servers for the host record.

Console

c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC>

<source DCs primary DNS Server IP >
c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC>
<source DCs secondary DNS Server IP>

Continuing the example for the hostname for contoso-dc2 in the contoso.com
domain is 8a7baee5-cd81-4c8c-9c0f-b10030574016 and points to self (127.0.0.1)
as primary for DNS name resolution, the NSLOOKUP syntax would be:

Console

c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.99

c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.101

Repeat the NSLOOKUP command against the source DCs secondary DNS Server IP
address.

To dynamically register host "A" records, type the following command from the
console of the computer:

Console

c:\>ipconfig /registerdns

Notes:

Windows 2000 through Windows Server 2008 R2 computers all register IPv4
host "A" records.
Windows Server 2008 and Windows Server 2008 R2 computers all register
IPv6 host "AAAA" records.
Host "A" and "AAAA" records are registered in the computers primary DNS
suffix zone.
Disable NICs that don't have network cables attached.
Disable host record registration on NICs that aren't accessible to DCs and
member computers on the network.
It isn't supported to disable the IPv6 protocol by unchecking the IPv6
checkbox in the network card properties.
4. Verify that the destination DC points to valid DNS Servers

On the destination DC, verify that DNS Client settings point exclusively to currently
online DNS Severs that either host, forward and delegate the _msdcs.<forest root
domain> zone (that is, all DCs in the contoso.com forest register CNAME records
in the_msdcs.contoso.com zone).

AND

The DNS zone for the Active Directory domain (that is, a computer in the
contoso.com domain would register host records in contoso.com zone).

AND

The computers primary DNS suffix domain if different from the Active Directory
domain name (see Technet article Disjoint Namespace ).

Options to validate that a DNS Server hosts, forwards, or delegates (that is, "can
resolve") such zones include:

Start the DNS management tool for your DNS and verify the DNS Servers to
which the source DC points for name resolution host the zones in question.

OR

Use NSLOOKUP to verify that all of the DNS Servers that the source DC points
to can resolve queries for the DNS zones in question.

Run IPCONFIG /ALL on the console of the destination DC:

Console

c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.102 <- Primary DNS
Server IP>

10.45.42.103<- Secondary DNS Server IP>

Run the following NSLOOKUP queries from the console of the destination DC:

Console

c:\>nslookup -type=soa <Source DC DNS domain name> <destinatin

DCs primary DNS Server IP >
c:\>nslookup -type=soa < Source DC DNS domain name > <destination
DCs secondary DNS Server IP >
c:\>nslookup -type=soa _msdcs.<forest root DNS domain>
 <destination DCs primary DNS Server IP >
c:\>nslookup -type=soa _msdcs.<forest root DNS name> <destination
DCs secondary DNS Server IP>

For example, if a DC in the CHILD.CONTOSO.COM domain of the contoso.com

forest is configured with the primary and secondary DNS Server IPs "10.45.42.102"
and "10.45.42.103", the NSLOOKUP syntax would be

Console

c:\>nslookup -type=soa child.contoso.com 10.45.42.102

c:\>nslookup -type=soa child.contoso.com 10.45.42.103
c:\>nslookup -type=soa _msdcs.contoso.com 10.45.42.102
c:\>nslookup -type=soa _msdcs.contoso.com 10.45.42.103

Notes:

The SOA query for the _mscs.contoso.com zone will resolve correctly if the
targeted DNS has a good forwarder or delegation or for the_msdcs.<forest
root zone>. It won't resolve correctly if the_msdcs.<forest root zone> on the
DNS Server being queried is a non-delegated subdomain of <forest root
zone> that is the zone relationship created by Windows 2000 domains.
CNAME records are always registered in the _msdcs.<forest root zone>, even
for DC in non-root domains.
Configuring the DNS client of a DC or member computer to point to an ISP
DNS Server for name resolution is invalid. The only exception is that ISP has
been contracted (that is, paid) and is currently hosting, forwarding, or
delegating DNS queries for your Active Directory forest.
ISP DNS Servers typically don't accept dynamic DNS updates, so CNAME,
Host, and SRV records may have to be manually registered.
The DNS resolver on the Windows computers is by-design "sticky". It uses
DNS servers that are responsive to queries, regardless of whether such DNS
Servers host, forward, or delegate the required zones. Restated, the DNS
resolver won't fail over and query another DNS server as long as the active
DNS is responsive, even if the response from the DNS Server is "I either don't
host the record you're looking for or even host a copy of the zone for that
record".

5. Verify that the DNS Server used by the destination DC can resolve the source
DCs CNAME and HOST records

From the console of the destination DC, run ipconfig /all to determine the DNS
Servers to which destination DC points for name resolution:
 Console

DNS Servers that destination DC points to for name resolution:

c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.102 <- Primary DNS
Server IP>
10.45.42.103<- Secondary
DNS Server IP>

From the console of the destination DC, use NSLOOKUP to query the DNS Servers
configured on the destination DC for the source DCs CNAME and host records:

Console

c:\>nslookup -type=cname <fully qualified CNAME of source DC>

<destination DCs primary DNS Server IP >
c:\>nslookup -type=cname <fully qualified CNAME of source DC>
<destination DCs secondary DNS Server IP>
c:\>nslookup -type=host <fully qualified hostname of source DC>
<destination DCs primary DNS Server IP >
c:\>nslookup -type=host <fully qualified hostname of source DC>
<destination DCs secondary DNS Server IP>

In the example, contoso-dc2 in the contoso.com domain with GUID 8a7baee5-

cd81-4c8c-9c0f-b10030574016 in the Contoso.com forest root domain points to
DNS Servers "10.45.42.102" and "10.45.42.103". The NSLOOKUP syntax would be:

Console

c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-

b10030574016._msdcs.contoso.com 10.45.42.102
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-
b10030574016._msdcs.contoso.com 10.45.42.103
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.102
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.102

6. Review the relationship between the DNS Servers used by the source and
destination DCs

If the DNS Servers used by the source and destination host AD-integrated copies
of the _msdcs.<forest root> and <primary DNS suffix> zones, check for:

Replication latency between the DNS where the record was registered and
the DNS where the record is being queried.
 A replication failure between the DNS where the record is registered and the
DNS being queried.
The DNS zone hosting the record of interest stays in different replication
scopes and therefore different contents, or is CNF / conflict-mangled on one
or more DCs.

If the DNS zones used by the source and destination DC are stored in primary and
secondary copies of DNS zones, check for:

The "allow zone transfers" checkbox isn't enabled on the DNS that hosts the
primary copy of the zone.
The "Only the following servers" checkbox is enabled, but the IP address of
the secondary DNS hasn't been added to the allowlist on the primary DNS.
The DNS zone on the Windows Server 2008 DNS hosting the secondary copy
of the zone is empty because of KB953317 .

If the DNS servers used by the source and destination DC have parent / child
relationships, check for:

Invalid delegations on the DNS that owns the parent zone that is delegating
to the subordinate zone.
Invalid forwarder IP addresses on the DNS server trying to resolve the
superior DNS zone (example: a DC in child.contoso.com trying to resolve host
records in conto.com zone staying on DNS Servers in the root domain).

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Orphaned child domain controller
information is not replicated to other
domain controllers
Article • 02/19/2024

This article provides a solution to an issue where an orphaned child domain controller
can't be replicated to other domain controllers.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 887430

Symptoms
A Microsoft Windows Server-based child domain is orphaned from the rest of the forest.
This child domain can receive changes that are replicated by domain controllers in the
parent (root) domain, but no domain controllers in the root domain or any other child
domains have knowledge of the domain controllers in the affected child domain.

When an administrator tries to view the domain controllers in the orphaned child
domain from another domain, no domain controllers are displayed. For example, no
domain controllers are displayed in the following configuration naming context:
CN=Servers,CN= Site_Name,CN=Sites,CN=Configuration,DC= Domain_Name,DC=com

In this case, Site_Name and Domain_Name are attributes of the orphaned domain.

Cause
This issue may occur if the child domain is orphaned from the parent domain.

Resolution

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.
To resolve this issue, you must create a replication link and then enable one-way
authentication instead of two-way authentication. To do this, follow these steps:

1. On a domain controller in the root domain, add the Replicator Allow SPN Fallback
registry value. To do this, follow these steps on the domain controller.
a. Select Start > Run, and then enter regedt32.
b. Select the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

c. Select Edit > New > DWORD Value.

d. Enter Replicator Allow SPN Fallback.
e. In the right pane, double-click Replicator Allow SPN Fallback, type 1 in the
Value data box, and then select OK.
f. Restart the domain controller.

2. Open a Command Prompt window, and run the following commands:

Console

repadmin /options
fully_qualified_domain_name_(FQDN)_of_the_root_domain_controller
+DISABLE_NTDSCONN_XLATE
repadmin /add CN=Configuration,DC=Domain_Name,DC=Domain_Name
FQDN_of_the_root_domain_controller FQDN_of_the_child_domain_controller
repadmin /showreps

A successful incoming connection should be displayed for the configuration

naming context from the child domain controller.

７ Note

For information about the Repadmin.exe tool, see Monitoring and

Troubleshooting Active Directory Replication Using Repadmin.

3. At the command prompt, run the command: repadmin /options

FQDN_of_the_root_domain_controller -DISABLE_NTDSCONN_XLATE .

4. Remove the Replicator Allow SPN Fallback registry entry. To do this, follow these
steps:

a. Start Registry Editor, and select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

b. Right-click Replicator Allow SPN Fallback, select Delete, and then select OK.
 5. Force replication between all domain controllers in the root domain. To do this,
follow these steps:

a. On a domain controller in the root domain, select Start > Programs >
Administrative Tools > Active Directory Sites and Services.

b. Expand Sites > Servers, expand your Server_Name folder, and then select NTDS
Settings.

c. If there are other domain controllers in your environment to replicate, they will
be listed in the right pane. Right-click the first domain controller in the list,
select All Tasks, and then select Check Replication Topology to start the
Knowledge Consistency Checker (KCC).

An incoming connection object from one or more of the child domain

controllers is displayed. You may have to update the display by pressing F5.

d. Repeat step 3 for each domain controller in the root domain.

6. Allow replication to occur throughout the forest. Then, run the repadmin /showreps
command on the root domain controller and on the child domain controllers. This
step makes sure that Active Directory Directory Service (AD DS) replication is
successful.

The Replication Allow SPN Fallback registry entry enables the domain controller to use
one-way authentication if two-way authentication cannot be performed because of a
failure to resolve a Service Principal Name (SPN) to a computer account.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 1722:
The RPC server is unavailable
Article • 04/10/2024

This article helps fix the error 1722 of Active Directory replication.

Applies to: Windows Server (All supported versions)

Original KB number: 2102154

Symptoms
This article describes the symptoms, cause, and resolution for resolving Active Directory
replication failing with Win32 error 1722: The RPC server is unavailable.

1. DCPROMO Promotion of a replica DC fails to create an NTDS Settings object on

the helper DC with error 1722。

Dialog Title text: Active Directory Domain Services Installation Wizard

Dialog Message text:

Output

The operation failed because: Active Directory Domain Services could

not create the NTDS Settings object for this Active Directory Domain
Controller CN=NTDS Settings,CN=<Name of DC being
promoted),CN=Servers,CN=<site name>,CN=Sites,CN=Configuration,DC=
<forest root domain> on the remote AD DC <helper DC>.<domain name>.<top
level domain>. Ensure the provided network credentials have sufficient
permissions. "The RPC server is unavailable."

2. DCDIAG reports that the Active Directory Replications test has failed with error
1722: The RPC Server is unavailable.

Output

[Replications Check,<DC Name>] A recent replication attempt failed:

From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The replication generated an error (1722):
The RPC server is unavailable.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
<X> failures have occurred since the last success.
[<dc name>] DsBindWithSpnEx() failed with error 1722,
 The RPC server is unavailable..
Printing RPC Extended Error Info:
<snip>

3. REPADMIN.EXE reports that replication attempt has failed with status 1722 (0x6ba).

REPADMIN commands that commonly cite the -1722 (0x6ba) status include but are
not limited to:

REPADMIN /REPLSUM

REPADMIN /SHOWREPL

REPADMIN /SHOWREPS
REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS and REPADMIN /SYNCALL depicting The
RPC server is unavailable error is shown below:

Console

c:\> repadmin /showreps

<site name><destination DC>
DC Options: <list of flags>
Site Options: (none)
DC object GUID: <NTDS settings object object GUID>
DC invocationID: <invocation ID string>
==== INBOUND NEIGHBORS ======================================
DC=<DN path for directory partition>
<site name><source DC via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <date> <time> failed, result **1722 (0x6ba):
The RPC server is unavailable.
<X #> consecutive failure(s).
Last success @ <date> <time>

Sample output of REPADMIN /SYNCALL depicting The RPC server is unavailable error
is shown below:

Console

C:\>repadmin /syncall
CALLBACK MESSAGE: Error contacting server \<object guid of NTDS
Settings object>._msdcs.\<forest root domain>.\<top level domain>
(network error): 1722 (0x6ba):
The RPC server is unavailable.

4. The replicate now command in Active Directory Sites and Services returns The RPC
server is unavailable.
 Right-clicking on the connection object from a source DC and choosing replicate
now fails with The RPC server is unavailable. The on-screen error message is
shown below:

Dialog title text: Replicate Now

Dialog message text:

The following error occurred during the attempt to synchronize naming

context <DNS name of directory partition> from domain controller <source
Dc host name> to domain controller <destination DC hostname>:The RPC
server is unavailable. This operation will not continue. This condition may be
caused by a DNS lookup problem. For information about troubleshooting
common DNS lookup problems, see the following Microsoft Web site: DNS
Lookup Problem

5. NTDS Knowledge Consistency Checker (KCC), NTDS General, or Microsoft-

Windows-ActiveDirectory_DomainService events with the 1722 status are logged in
the directory service event log.

Active Directory events that commonly cite the 1722 status include but are not
limited to:

ﾉ Expand table

Event Source Event Event String

ID

Microsoft-Windows- 1125 The Active Directory Domain Services

ActiveDirectory_DomainService Installation Wizard (Dcpromo) was unable to
establish connection with the following
domain controller.

NTDS KCC 1311 The Knowledge Consistency Checker (KCC)

has detected problems with the following
directory partition.

NTDS KCC 1865 The Knowledge Consistency Checker (KCC)

was unable to form a complete spanning
tree network topology. As a result, the
following list of sites cannot be reached from
the local site.

NTDS KCC 1925 The attempt to establish a replication link for

the following writable directory partition
failed.
 Event Source Event Event String
ID

NTDS Replication 1960 Internal event: The following domain

controller received an exception from a
remote procedure call (RPC) connection. The
operation may have failed.

Cause
RPC is an intermediate layer between the network transport and the application
protocol. RPC itself has no special insight into failures but attempts to map lower layer
protocol failures into an error at the RPC layer.

RPC error 1722 / 0x6ba / RPC_S_SERVER_UNAVAILABLE is logged when a lower layer

protocol reports a connectivity failure. The common case is that the abstract TCP
CONNECT operation failed. In the context of AD replication, the RPC client on the
destination DC was not able to successfully connect to the RPC server on the source DC.
Common causes for this are:

1. Link local failure

2. DHCP failure
3. DNS failure
4. WINS failure
5. Routing failure (including blocked ports on firewalls)
6. IPSec / Network authentication failures
7. Resource limitations
8. Higher layer protocol not running
9. Higher layer protocol is returning this error

Resolution
Basic troubleshooting steps to identify the problem.

Verify the startup value and service status are correct for
RPC, RPC Locator, and Kerberos Key Distribution Center
Verify the startup value and service status are correct for the Remote Procedure Call
(RPC), Remote Procedure Call (RPC) Locator and Kerberos Key Distribution Center.
The OS version will determine the correct values for the source and destination system
that is logging the replication error. Use the following table to help validate the settings.

ﾉ Expand table

Service Windows 2000 Windows 2003 Windows 2008 Windows 2008

Name /R2 R2

Remote Started / Started / Started / Started /

Procedure Automatic Automatic Automatic Automatic
Call (RPC)

Remote Started / Not started / Not started / Not started /

Procedure Automatic Manual Manual Manual
Call (RPC) (Domain
Locator Controllers)

Not started /
Manual(Member
Servers)

Kerberos Started / Started / Started / Started /

Key Automatic Automatic Automatic Automatic
Distribution (Domain (Domain (Domain (Domain
Center Controllers) Controllers) Controllers) Controllers)
(KDC)
Not started / Not started / Not started / Not started /
Disabled(Member Disabled(Member Disabled(Member Disabled(Member
Servers) Servers) Servers) Servers)

If you make any changes to match the settings above, restart the machine. Verify both
the startup value and service status match the values documented in the table above.

Verify the ClientProtocols key exists under

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc, and
that it contains the correct default protocols

ﾉ Expand table

Protocol Name Type Data Value

ncacn_http REG_SZ rpcrt4.dll

ncacn_ip_tcp REG_SZ rpcrt4.dll

ncacn_np REG_SZ rpcrt4.dll

 Protocol Name Type Data Value

ncacn_ip_udp REG_SZ rpcrt4.dll

If the ClientProtocols key or any of the four default values are missing, import the key
from a known good server.

Verify DNS is working

DNS lookup failures are the cause of a large number of 1722 RPC errors when it comes
to replication.

There are a few tools to use to help identify DNS errors:

DCDIAG /TEST:DNS /V /E /F:<filename.log>

The DCDIAG /TEST:DNS command can validate DNS health of Windows 2000 Server
(SP3 or later), Windows Server 2003, and Windows Server 2008 family domain
controllers. This test was first introduced with Windows Server 2003 Service Pack 1.

There are seven test groups for this command.

Authentication (Auth)

Basic ( Basc )

Records registration (RReg)

Dynamic update ( Dyn )

Delegations (Del)

Forwarders/Root hints (Forw)

Sample output:

Output

TEST: Authentication (Auth)

Authentication test: Successfully completed

TEST: Basic (Basc)

Microsoft(R) Windows(R) Server 2003, Enterprise Edition (Service
Pack level: 2.0) is supported
NETLOGON service is running
kdc service is running
DNSCACHE service is running
DNS service is running
 DC is a DNS server
Network adapters information:
Adapter [00000009] Microsoft Virtual Machine Bus Network Adapter:
MAC address is 00:15:5D:40:CF:92
IP address is static
IP address: <IP Address>
DNS servers:
<DNS IP Address> (DC.domain.com.) [Valid]
The A record for this DC was found
The SOA record for the Active Directory zone was found
The Active Directory zone on this DC/DNS server was found (primary)
Root zone on this DC/DNS server was not found
<omitted other tests for readability>

Summary of DNS test results:

Output

Auth Basc Forw Del Dyn RReg Ext

Domain: fragale.contoso.com
DC1 PASS PASS FAIL PASS PASS PASS n/a
Domain: child.fragale.contoso.com
DC2 PASS PASS n/a n/a n/a PASS n/a

Enterprise DNS infrastructure test results:

For parent domain domain.com and subordinate domain child:
Forwarders or root hints are not misconfigured from parent domain to
subordinate domain
Error: Forwarders are configured from subordinate to parent domain
but some of them failed DNS server tests

(See DNS servers section for error details)

Delegation is configured properly from parent to subordinate domain
......................... domain.com failed test DNS

The summary provides remediation steps for the more common failures from
this test.

Explanation and additional options for this test can be found at Domain
Controller Diagnostics Tool (dcdiag.exe).

NLTEST /DSGETDC:<netbios or DNS domain name>

Nltest /dsgetdc is used to exercise the dc locator process. Thus /dsgetdc:<domain

name> tries to find the domain controller for the domain. Using the force flag forces

domain controller location rather than using the cache. You can also specify
options such as /gc or /pdc to locate a Global Catalog or a primary domain
controller emulator. For finding the Global Catalog, you must specify a tree name,
which is the DNS domain name of the root domain.

Sample output:

Output

DC: [\DC.fabrikam.com]
Address: \\<IP Address>
Dom Guid: 5499c0e6-2d33-429d-aab3-f45f6a06922b
Dom Name: fabrikam.com
Forest Name: fabrikam.com
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully

Netdiag -v

Can be used with Windows 2003 and earlier versions to gather specific information
for networking configuration and error. This tool takes some time to run when
executing the -v switch.

Sample output for the DNS test:

Output

DNS test . . . . . . . . . . . . . : Passed

Interface {34FDC272-55DC-4103-B4B7-89234BC30C4A}
DNS Domain:
DNS Servers: <DNS Server Ip address>
IP Address: Expected registration with PDN (primary DNS domain
name):
Hostname: DC.fabrikam.com.
Authoritative zone: fabrikam.com.
Primary DNS server: DC.fabrikam.com <Ip Address>
Authoritative NS:<Ip Address>
Check the DNS registration for DCs entries on DNS server <DNS Server Ip
address>
The Record is correct on DNS server '<DNS Server Ip address>'.
(You will see this line repeated several times for every entry for this
DC. Including srv records.)
The Record is correct on DNS server '<DNS Server Ip address>'.
PASS - All the DNS entries for DC are registered on DNS server '<DNS
Server Ip address>'.

ping -a <IP_of_problem_server>
 It's a simple quick test to validate the host record for a domain controller is
resolving to the correct machine.

dnslint /s IP /ad IP

DNSLint is a Windows utility that helps you to diagnose common DNS name
resolution issues. The output is an htm file with much information including:

DNS server: localhost

Output

IP Address: 127.0.0.1
UDP port 53 responding to queries: YES
TCP port 53 responding to queries: Not tested
Answering authoritatively for domain: NO

SOA record data from server:

Output

Authoritative name server: DC.domain.com

Hostmaster: hostmaster
Zone serial number: 14
Zone expires in: 1.00 day(s)
Refresh period: 900 seconds
Retry delay: 600 seconds
Default (minimum) TTL: 3600 seconds

Additional authoritative (NS) records from server: DC2.fabrikam.com <IP Address>

Alias (CNAME) and glue (A) records for forest GUIDs from server:

CNAME: 98d4aa0c-d8e2-499a-8f90-9730b0440d9b._msdcs.fabrikam.com
Alias: DC.fabrikam.com
Glue: <IP Adress>

CNAME: a2c5007f-7082-4adb-ba7d-a9c47db1efc3._msdcs.fabrikam.com
Alias: dc2.child.fabrikam.com
Glue: <IP Address>

For more information, see Description of the DNSLint utility .

Verify network ports are not blocked by a firewall or

third-party application listening on the required ports
The endpoint mapper (listening on port 135) tells the client which randomly assigned
port a service (FRS, AD replication, MAPI, and so on) is listening on.

ﾉ Expand table

Application protocol Protocol Ports

Global Catalog Server TCP 3269

Global Catalog Server TCP 3268

LDAP Server TCP 389

LDAP Server UDP 389

LDAP SSL TCP 636

LDAP SSL UDP 636

IPsec ISAKMP UDP 500

NAT-T UDP 4500

RPC TCP 135

RPC randomly allocated high TCP ports¹ TCP 1024 - 5000

49152 - 65535*

* This is the range in Windows Server 2008, Windows Vista, Windows 7, and Windows

2008 R2.

Portqry can be used to identify if a port is blocked from a Dc when targeting another
DC. It can be downloaded at PortQry Command Line Port Scanner Version 2.0 .

Example syntax:

portqry -n <problem_server> -e 135

portqry -n <problem_server> -r 1024-5000

A graphical version of portqry, called Portqryui can be found at PortQryUI - User

Interface for the PortQry Command Line Port Scanner .

If the Dynamic Port range has ports being blocked, use the below links to configure a
port range that is manageable for the customer.

Additional important links for configuration and working with Firewalls and Domain
Controllers:

HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall

 Restricting Active Directory Replication Traffic to a Specific Port
How to Configure a Firewall for Domains and Trusts
A List of the Windows Server Domain Controller Default Ports
Port Requirements for the Microsoft Windows Server System

Bad NIC drivers

See network card vendors or OEMs for the latest drivers.

UDP fragmentation can cause replication errors that

appear to have a source of RPC server is unavailable
Event ID 40960 & 40961 errors with a source of LSASRV are common for this particular
cause.

For more information, see How to force Kerberos to use TCP instead of UDP in
Windows .

SMB signing mismatches between DCs

Using Default Domain Controllers Policy to configure consistent settings for SMB
Signing under the following section will help address this cause:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security

Options

Microsoft network client: Digitally sign communications (always) Disabled.

Microsoft network client: Digitally sign communications (if server agrees) Enabled.
Microsoft network server: Digitally sign communications (always) Disabled.
Microsoft network server: Digitally sign communications (if client agrees) Enabled.

The settings can be found under the following registry keys:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Paramet
ers and

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

RequireSecuritySignature = always (0,disable, 1 enable).

EnableSecuritySignature = is server agrees (0,disable, 1 enable).

Additional Troubleshooting:
If the above don't provide a solution to the 1722, use the following Diagnostic logging
to gather more information:

Output

Windows Server 2003 SP2 computers logs extended RPC Server info in NTDS
Replication events 1960, 1961, 1962 and 1963.
Crank up NTDS Diagnostic logging

1 = basic, 2 and 3 add continually verbose info and 5 logs extended info.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

References
RPC Return Values
Understanding Extended Error Information
Extended error information detection locations
Enabling Extended error information
Network Connectivity

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error
-2146893022 (0x80090322): The target
principal name is incorrect
Article • 04/11/2024

This article describes how to troubleshoot a problem in which Active Directory

replication fails and generates an error (-2146893022: The target principal name is
incorrect).

Applies to: Windows Server (All supported versions)

Original KB number: 2090913

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, please ask the Microsoft
Community .

Summary
This error occurs when the source domain controller doesn't decrypt the service ticket
provided by the destination (target) domain controller.

Top cause
The destination domain controller receives a service ticket from a Kerberos Key
Distribution Center (KDC). And the KDC has an old version of the password for the
source domain controller.

Top resolution
1. Stop the KDC service on the destination domain controller. To do it, run the
following command at a command prompt:

Console

net stop KDC

 2. Start replication on the destination domain controller from the source domain
controller. Use AD Sites and Services or Repadmin .

Using repadmin :

Console

Repadmin /replicate destinationDC sourceDC DN_of_Domain_NC

For example, if replication is failing on ContosoDC2.contoso.com , run the following

command on ContosoDC1.contoso.com :

Console

Repadmin /replicate ContosoDC2.contoso.com ContosoDC1.contoso.com

"DC=contoso,DC=com"

3. Start the Kerberos KDC service on the destination domain controller by running the
following command:

Console

net start KDC

If it doesn't resolve the issue, see the Resolution section for an alternative solution in
which you use the netdom resetpwd command to reset the computer account password
of the source domain controller. If these steps don't resolve the problem, review the rest
of this article.

Symptoms
When this problem occurs, you experience one or more of the following symptoms:

DCDIAG reports that the Active Directory replications test has failed and returned
error -2146893022: The target principal name is incorrect.

[Replications Check,<DC Name>] A recent replication attempt failed:

From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The replication generated an error (-2146893022):
The target principal name is incorrect.
The failure occurred at <date> <time>.
 The last success occurred at <date> <time>.
<X> failures have occurred since the last success.

Repadmin.exe reports that a replication attempt failed, and reports a status of

-2146893022 (0x80090322).

Repadmin commands that commonly indicate the -2146893022 (0x80090322)

status include but aren't limited to the following ones:

REPADMIN /REPLSUM

REPADMIN /SHOWREPL

REPADMIN /SHOWREPS

REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS and REPADMIN /SYNCALL that indicate
the target principal name is incorrect error is as follows:

Console

c:\> repadmin /showreps

<site name>\<destination DC>
DC Options: IS_GC
Site Options: (none)
DC object GUID: <NTDS settings object object GUID>
DChttp://bemis/13/Pages/2090913_en-US.aspx invocationID: <invocation
ID string>

==== INBOUND NEIGHBORS ======================================

DC=<DN path for directory partition>

<site name>\<source DC via RPC
DC object GUID: <source DCs ntds settings object object
guid>
Last attempt @ <date> <time> failed, result -2146893022
(0x80090322):
The target principal name is incorrect.
<X #> consecutive failure(s).
Last success @ <date> <time>.

c:\> repadmin /syncall /Ade

Syncing all NC's held on localhost.
Syncing partition: DC=<Directory DN path>
CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=
<server name>,CN=Servers,CN=<site
name>,CN=Sites,CN=Configuration,DC=<forest root domain> (network
error): -2146893022 (0x80090322):
The replicate now command in Active Directory Sites and Services returns the
following error message:
The target principal name is incorrect

Right-clicking on the connection object from a source DC and then selecting

replicate now fails. The on-screen error message is as follows:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to
contact the domain controller <source DC name>:
The target principal name is incorrect
Buttons in Dialog: OK

NTDS Knowledge Consistency Checker (KCC), NTDS General, or Microsoft-

Windows-ActiveDirectory_DomainService events that have the -2146893022
status are logged in the directory service event log.

Active Directory events that commonly cite the -2146893022 status include but
aren't limited to the following ones:

ﾉ Expand table

Event Source Event Event String

ID

NTDS Replication 1586 The Windows NT 4.0 or earlier replication

checkpoint with the PDC emulator master
was unsuccessful.

A full synchronization of the security

accounts manager (SAM) database to
domain controllers running Windows NT 4.0
and earlier might take place if the PDC
emulator master role is transferred to the
local domain controller before the next
successful checkpoint.

NTDS KCC 1925 The attempt to establish a replication link

for the following writable directory partition
failed.

NTDS KCC 1308 The Knowledge Consistency Checker (KCC)

has detected that successive attempts to
replicate with the following domain
controller has consistently failed.
 Event Source Event Event String
ID

Microsoft-Windows- 1926 The attempt to establish a replication link to

ActiveDirectory_DomainService a read-only directory partition with the
following parameters failed

NTDS Inter-site Messaging 1373 The Intersite Messaging service could not
receive any messages for the following
service through the following transport. The
query for messages failed.

Cause
The -2146893022\0x80090322\SEC_E_WRONG_PRINCIPAL error code isn't an Active
Directory error. It may be returned by the following lower layer components for different
root causes:

RPC
Kerberos
SSL
LSA
NTLM

Kerberos errors that are mapped by Windows code to

-2146893022\0x80090322\SEC_E_WRONG_PRINCIPAL include:

KRB_AP_ERR_MODIFIED (0x29/41 decimal/KRB_APP_ERR_MODIFIED)

KRB_AP_ERR_BADMATCH (0x24h/36 decimal/"Ticket and authenticator don't
match")
KRB_AP_ERR_NOT_US (0x23h/35 decimal/"The ticket isn't for us")

Some specific root causes for -2146893022\0x80090322\SEC_E_WRONG_PRINCIPAL

include:

A bad name-to-IP mapping in DNS, WINS, HOST, or LMHOST file. It caused the
destination domain controller to connect to the wrong source domain controller in
a different Kerberos realm.

The KDC and source domain controller have different versions of the source
domain controller's computer account password. So the Kerberos target computer
(source domain controller) couldn't decrypt Kerberos authentication data sent by
the Kerberos client (destination domain controller).
 The KDC couldn't find a domain to look for the source domain controller's SPN.

Authentication data in Kerberos encrypted frames were modified by hardware

(including network devices), software, or an attacker.

Resolution
Run dcdiag /test:checksecurityerror on the source DC

SPNs may be missing, invalid, or duplicated due to simple replication latency,

especially following promotion, or replication failures.

Duplicate SPNs may cause bad SPN to name mappings.

DCDIAG /TEST:CheckSecurityError can check for missing or duplicate SPNs and

other errors.

Run this command on the console of all source domain controllers that fail
outbound replication with the SEC_E_WRONG_PRINCIPAL error.

You can check SPN registration against a specific location by using the following
syntax:

Console

dcdiag /test:checksecurityerror replsource:<remote dc>

Verify that Kerberos encrypted network traffic reached the intended Kerberos
target (name-to-IP mapping)

Consider the following scenario:

Inbound replicating Active Directory destination domain controllers search their

local copy of the directory for the objectGUID of the source domain controllers
NTDS Settings objects.

The domain controllers query the active DNS server for a matching DC GUIDED
CNAME record. Then it's mapped to a host A/AAAA record that contains the
source domain controller's IP address.

In this scenario, Active Directory runs a name resolution fallback. It includes

queries for fully qualified computer names in DNS or single-label host names in
WINS.
 ７ Note

DNS Servers can also perform WINS lookups in fallback scenarios.

The following situations can all cause a destination domain controller to submit
Kerberos-encrypted traffic to the wrong Kerberos target:

Stale NTDS Settings objects

Bad name-to-IP mappings in DNS and WINS host records
Stale entries in HOST files

To check for this condition, either take a network trace or manually verify that name
DNS/NetBIOS name queries resolve to the intended target computer.

Method 1: Network trace method (as parsed by Network

Monitor 3.3.1641 by having full default parsers enabled)
The following table shows a synopsis of network traffic that occurs when destination
DC1 inbound replicates the Active Directory directory from source DC2.

ﾉ Expand table

F# SRC DEST Protocol Frame Comment

1 DC1 DC2 MSRPC MSRPC:c/o Request: unknown Call=0x5 Dest DC RPC call to
Opnum=0x3 Context=0x1 Hint=0x90 EPM on source DC
over 135

2 DC2 DC1 MSRPC MSRPC:c/o Response: unknown EPM response to

Call=0x5 Context=0x1 Hint=0xF4 RPC caller
Cancels=0x0

3 DC1 DC2 MSRPC MSRPC:c/o Bind: UUID{E3514235-4B06- RPC bind request to

11D1-AB04-00C04FC2DCD2} E351... service UUID
DRSR(DRSR) Call=0x2 Assoc Grp=0x0
Xmit=0x16D0 Recv=0x16D0

4 DC2 DC1 MSRPC MSRPC:c/o Bind Ack: Call=0x2 Assoc RPC Bind response
Grp=0x9E62 Xmit=0x16D0
Recv=0x16D0
F# SRC DEST Protocol Frame Comment

5 DC1 KDC KerberosV5 KerberosV5:TGS Request Realm: TGS request for

CONTOSO.COM Sname : E3514235-4B06- replication SPN of
11D1-AB04-00C04FC2DCD2/6f3f96d3- source DC. This
dfbf-4daf-9236- operation will not
4d6da6909dd2/contoso.com appear on the wire
of destination DC
uses self as KDC.

6 KDC DC1 KerberosV5 KerberosV5:TGS Response Cname: TGS response to

CONTOSO-DC1$ destination DC
contoso-dc1. This
operation will not
appear on the wire
of destination DC
uses self as KDC.

7 DC1 DC2 MSRPC MSRPC:c/o Alter Cont: UUID{E3514235- AP request

4B06-11D1-AB04-00C04FC2DCD2}
DRSR(DRSR) Call=0x2

8 DC2 DC1 MSRPC MSRPC:c/o Alter Cont Resp: Call=0x2 AP response.

Assoc Grp=0x9E62 Xmit=0x16D0
Recv=0x16D0

ﾉ Expand table

Drilldown on Frame 7 Drilldown on Frame 8 Comments

MSRPC MSRPC:c/o Alter Cont: MSRPC:c/o Alter Cont DC1 connects to AD Replication
UUID{E3514235-4B06-11D1- Resp: Call=0x2 Assoc Service on DC2 over the port
AB04-00C04FC2DCD2} Grp=0xC3EA43 Xmit=0x16D0 returned by the EPM on DC2.
DRSR(DRSR) Call=0x2 Recv=0x16D0

Ipv4: Src = x.x.x.245, Dest = Ipv4: Src = x.x.x.35, Dest Verify that AD replication source DC
x.x.x.35, Next Protocol = TCP, = x.x.x.245, Next Protocol (referred to as the Dest computer in
Packet ID =, Total IP Length = = TCP, Packet ID = 31546, the first column and Src computer in
0 Total IP Length = 278 column 2 owns the IP address cited
in the trace. It's x.x.x.35 in this
example.

Ticket: Realm: CONTOSO.COM , ErrorCode: In column 1, note the realm of the

Sname : E3514235-4B06-11D1- KRB_AP_ERR_MODIFIED target Kerberos realm as
AB04- (41) contoso.com followed by the source
00C04FC2DCD2/6f3f96d3- domain controllers Replication SPN
dfbf-4daf-9236- Realm: <verify that realm ( Sname ) which consists of the Active
4d6da6909dd2/contoso.com returned by the source Directory replication service UUID
DC matches the Kerberos (E351...) concatenated with object
Drilldown on Frame 7 Drilldown on Frame 8 Comments

realm intended by the GUID of the source domain

destination DC>. controllers NTDS Settings object.

Sname : <verify that the The GUIDED value 6f3f96d3-dfbf-

sName in the AP response 4daf-9236-4d6da6909dd2 to the
matches contains the right of the E351... replication service
hostname of the UUID is the Object GUID for the
intended source DC and source domain controllers NTDS
NOT another DC that the settings object. It's currently defined
destination incorrectly in the destination domain controllers
resolved to due to a bad copy of Active Directory. Verify that
name-to-ip mapping this object GUID matches the value
problem>. in the DSA Object GUID field when
repadmin /showreps is run from the
console of the source DC.

A ping or nslookup of the source

domain controllers fully qualified
CNAME concatenated with_msdcs.
<forest root DNS name> from the
console of the destination DC must
return the source domain controllers
current IP address:

ping 6f3f96d3-dfbf-4daf-9236-
4d6da6909dd2._msdcs.contoso.com

nslookup -type=cname 6f3f96d3-

dfbf-4daf-9236-4d6da6909dd2._msdcs.
<forest root domain> <DNS Server
IP>

In the reply shown in column 2,

focus on the Sname field and verify
that it contains the hostname of the
AD replication source DC.

Bad name-to-IP mappings could

cause the destination DC to connect
to a DC in an invalid target realm
causing the Realm value to be invalid
as shown in this case. Bad host-to-IP
mappings could cause DC1 to
connect to DC3 in the same domain.
It would still generate
KRB_AP_ERR_MODIFIED, but the
 Drilldown on Frame 7 Drilldown on Frame 8 Comments

realm name in frame 8 would match

the realm in frame 7.

Method 2: Name-to-IP mapping verification (without

using a network trace)
From the console of the Source domain controller:

ﾉ Expand table

Command Comment

IPCONFIG /ALL Note IP address of NIC used by destination domain controllers

|MORE

REPADMIN Note value of DSA Object GUID. It denotes the object GUID for the source
/SHOWREPS |MORE domain controllers NTDS Settings Object in the source domain controllers
copy of active Directory.

From the Console of the destination DC:

ﾉ Expand table

Command Comment

IPCONFIG /ALL |MORE Note the primary, secondary and any

tertiary DNS Servers configured that
the destination DC could query during
DNS lookups.

REPADMIN /SHOWREPS |MORE In the Inbound Neighbors section of

the repadmin output, locate the
replication status where the destination
DC replicates a common partition from
the source DC in question.

The DSA object GUID listed for the

source DC in the replication status
section of the report should match the
object GUID listed in the /showreps
header when run on the console of the
source DC.

IPCONFIG /FLUSHDNS Clear the DNS Client cache

 Command Comment

Start > Run > Notepad Check for host-to-IP mappings

%systemroot%\system32\drivers\etc\hosts referencing the source domain
controllers single label or fully qualified
DNS name. Remove if present. Save
changes to HOST file.

Run Nbtstat -R (upper case R) to

refresh the NetBIOS name cache.

NSLOOKUP -type=CNAME <object guid of source DCs NTDS Verify that IP returned matches the IP
Settings object>._msdcs.<forest root DNS name> address of target DC listed above
<primary DNS Server IP> recorded from the console of the
source DC.
Repeat for each additional DNS Server IP configured on
the destination DC. Repeat for all DNS Servers IPs
configured on destination DC.
example: c:\>nslookup -type=cname 8a7baee5-cd81-
4c8c-9c0f-b10030574016._msdcs.contoso.com
152.45.42.103

nslookup -type=A+AAAA <FQDN of source DC> <DNS Check for duplicate host A records on
Server IP> all DNS Server IPs configured on the
destination DC.

nbtstat -A <IP address of DNS Server IP returned by Should return name of the source DC.
nslookup>

７ Note

A replication request that's directed to a non-domain controller (because of a bad

name-to-IP mapping) or a domain controller that doesn't currently have the E351...
service UUID registered with the endpoint mapper returns error 1753: There are no
more endpoints available with the endpoint mapper.

The Kerberos target can't decrypt Kerberos authenticated data because of a password
mismatch.

This issue can occur if the password for the source domain controller differs between
the KDC and source domain controller's copy of the Active Directory directory. The
destination domain controller's copy of the source domain controller computer account
password may be stale if it's not using itself as the KDC.

Replication failures can prevent domain controllers from having a current password
value for domain controllers in a given domain.
Every domain controller runs the KDC service for their domain realm. For same realm
transactions, a destination domain controller favors getting Kerberos tickets from itself.
However, it may get a ticket from a remote domain controller. Referrals are used to get
Kerberos tickets from other realms.

The NLTEST /DSGETDC:<DNS domain of target domain> /kdc command that's run at an
elevated command prompt in close time proximity to a SEC_E_WRONG_PRINCIPAL
error can be used to quickly identify which KDC a Kerberos client is targeting.

The definitive way to determine which domain controller a Kerberos client got a ticket
from is to take a network trace. The lack of Kerberos traffic in a network trace may
indicate:

The Kerberos client has already acquired tickets.

It's getting tickets off-the-wire from itself.
Your network trace application isn't correctly parsing Kerberos traffic.

Kerberos tickets for the logged-on user account can be purged at an elevated command
prompt by using the KLIST purge command.

Kerberos tickets for the system account that are used by Active Directory replication can
be purged without a restart by using KLIST -li 0x3e7 purge .

Domain controllers can be made to use other domain controllers by stopping the KDC
service on a local or remote domain controller.

Use REPADMIN /SHOWOBJMETA to check for obvious version number differences in

password-related attributes (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet,
lmPwdHistory) for the source domain controller in the source domain controller's and
destination domain controller's copy of the Active Directory directory.

Console

C:\>repadmin /showobjmeta <source DC> <DN path of source DC computer

account>

Console

C:\>repadmin /showobjmeta <KDC selected by destination DC> <DN path of

source DC computer account>

The netdom resetpwd /server:<DC to direct password change to> /userd:<user name>
/passwordd:<password> command that's run at an elevated command prompt on the
console of the domain controller that requires a password reset can be used to reset
domain controller machine account passwords.

Troubleshoot specific scenarios

Repro steps for bad host-to-IP mapping that causes the destination domain
controller to pull from wrong source.

1. Promote \\dc1 + \\DC2 + \\DC3 in the contoso.com domain. End-to-end

replication occurs without errors.

2. Stop the KDC on \\DC1 and \\DC2 to force off-box Kerberos traffic that can
be observed in a network trace. End-to-end replication occurs without errors.

3. Create a Host file entry for \\DC2 that points to the IP address of a DC in a
remote forest. It's to simulate a bad host-to-IP mapping in a host A/AAAA
record, or perhaps a stale NTDS Settings object in the destination domain
controller's copy of the Active Directory directory.

4. Start Active Directory Sites and Services on the console of \\DC1. Right-click
\\DC1's inbound connection object from \\DC2 and note the target account
name is incorrect replication error.

Repro steps for a source domain controller password mismatch between KDC and
the source domain controller.

1. Promote \\dc1 + \\DC2 + \\DC3 in the contoso.com domain. End-to-end

replication occurs without error.

2. Stop the KDC on \\DC1 and \\DC2 to force off-box Kerberos traffic that can
be observed in network trace. End-to-end replication occurs without error.

3. Disabling inbound replication on KDC \\DC3 to simulate a replication failure

on the KDC.

4. Reset the computer account password on \\DC2 three or more times so that
\\DC1 and \\DC2 both have the current password for \\DC2.

5. Start Active Directory Sites and Services on the console of \\DC1. Right-click
on \\DC1's inbound connection object from \\DC2 and note the target
account name is incorrect replication error.

DS RPC client logging

 Set NTDS\Diagnostics Loggings\DS RPC Client = 3. Trigger replication. Look for
Task Category Event 1962 + 1963. Note the fully qualified cname that's listed in the
directory service field. The destination domain controller should be able to ping
this record and have the returned address map to the current IP address of the
source DC.

Kerberos workflow

The Kerberos workflow includes the following actions:

Client Computer calls IntializeSecurityContext function and specifies the

Negotiate security support provider (SSP).

The client contacts the KDC with its TGT and requests a TGS Ticket for the target
domain controller.

The KDC searches the Global Catalog for a source (either e351 or hostname) in
the destination domain controller's realm.

If the target domain controller is in the destination domain controller's realm,

the KDC provides the client a service ticket.

If the target domain controller is in a different realm, the KDC provides the
client a referral ticket.

The client contacts a KDC in the target domain controller's domain and requests
a service ticket.

If the source domain controller's SPN doesn't exist in the realm, you receive a
KDC_ERR_S_PRINCIPAL_UNKNOWN error.

The destination domain controller contacts the target and presents its ticket.

If the target domain controller owns the name in the ticket and can decrypt it,
the authentication works.

If the target domain controller hosts the RPC server service UUID, the on-wire
Kerberos KRB_AP_ERR_NOT_US or KRB_AP_ERR_MODIFIED error is remapped
to the following one:

-2146893022 decimal / 0x80090322 / SEC_E_WRONG_PRINCIPAL / "The

target principal name is incorrect"

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The naming context is in the process of
being removed or is not replicated from
the specified server
Article • 02/19/2024

This article provides a resolution to solve the Active Directory replication error (8452).
This article is only intended for technical support agents and IT professionals. If you're a
home user and looking for help with a problem, visit ask the Microsoft Community .

Applies to: Windows Server 2012 R2

Original KB number: 2023704

Symptoms
1. DCDIAG reports that Active Directory Replications test has failed with error status
code (8452): The naming context is in the process of being removed or is not
replicated from the specified server.

Testing server: <site name><destination dc name>

Starting test: Replications
Replications Check
[Replications Check,<destination DC name>] A recent replication attempt
failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (8452):
The naming context is in the process of being removed or is not replicated
from the specified server.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
3 failures have occurred since the last success.

2. REPADMIN.EXE reports that the last replication attempt has failed with status 8452.

REPADMIN commands that commonly cite the five statuses include but aren't

limited to:

REPADMIN /SHOWREPS
REPADMIN /REPLSUM
 REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS depicting inbound replication from

CONTOSO-DC2 to CONTOSO-DC1 failing with the replication access was denied
error is shown below:

Console

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 8452 (0x2104):
The naming context is in the process of being removed or is not
replicated from the specified server.
<#> consecutive failure(s).
Last success @ <date> <time>.

3. The replicate now command in Active Directory Sites and Services returns the
following error:

The naming context is in the process of being removed or is not replicated

from the specified server.

Right-clicking on the connection object from a source DC and choosing replicate

now fails with the above error. The on-screen error message text is shown below:

Dialog title text: Replicate Now Dialog message text: The following error
occurred during the attempt to synchronize naming context <%directory
partition name%> from Domain Controller <Source DC> to Domain Controller
<Destination DC>: The naming context is in the process of being removed or
is not replicated from the specified server.

The operation will not continue

Buttons in Dialog: OK

4. NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService

events with the five statuses are logged in the directory service event log.
 Active Directory events that commonly cite the 8524 status include but aren't
limited to:

ﾉ Expand table

Event Source Event String

NTDS 1586 The checkpoint with the PDC was unsuccessful. The checkpointing
General process will be retried again in four hours. A full synchronization of the
security database to downlevel domain controllers may take place if
this machine is promoted to be the PDC before the next successful
checkpoint. The error returned was: The naming context is in the
process of being removed or is not replicated from the specified
server.

Cause
This error most commonly occurs when the following replication topologies are
different:

The replication topology in a DC that's starting replication.

The replication topology that's defined in the destination DC's copy of Active
Directory.

The error naturally occurs when the replication topology in an Active Directory forest is
being modified by:

New partitions being added or removed from the forest. For example, the
promotion or demotion of the first/last DC in a domain. Or the addition/removal of
an application partition including default DNS application partitions.

The addition or removal of directory partitions on existing DCs (that is, the
promotion/demotion of global catalog or addition/removal of an application
partition).

Changes in replication topology or settings:

The promotion of new DCs
The demotion of existing DCs
Changes to preferred/nominated bridgeheads
The building of alternate replication paths in response to replication failures or
offline DCs
Site and site link changes.
The error can be transient in a forest undergoing the above changes. It remains
transient until the set of source DCs and partitions which each destination DC replicates
from has inbound replicated by triggering replication operations.

The error can be persistent when replication failures prevent the end-to-end replication
of topology changes in the forest.

The error is most commonly seen in replication scenarios triggered by REPADMIN.EXE

remotely (especially /SYNCALL ) or the replicate now command in DSSITE.MSC where the
copy of Active Directory on the DC triggering replication has a different list of source
DCs that a destination DC replicates from partitions than what the destination DC has
defined in its copy of Active Directory.

Windows 2000 domain controllers are particularly prone to this error during GC
demotion as they're slow to remove objects from read-only partitions. Object removal
during GC demotion improved dramatically on Windows Server 2003 and later OS
versions.

The NTDS Replication event 1586 occurs in the following situation:

The primary domain controller (PDC) Flexible Single Master Operation (FSMO) role for
the domain has been seized or transferred to a domain controller that wasn't a direct
replication partner of the previous role holder.

In rare conditions, the error can be caused by corruption in attributes like hasMasterNCs
or msds-hasMasterNCs .

The More information section of this article contains explanations as to why the
diagnostic and administrative tools listed in the Symptoms section of this article
generate the 8452 error.

In summary, Error 8452 happens if any of the following conditions is true:

1. When DC1 <- DC2 replication is started for a Naming Context (NC), on DC1 there's
no replica link for the NC from DC2.
2. When DC1 <- DC2 replication in started for an NC, the NC is in the process of
being removed on DC2.
3. In mixed domain environment, the PDC FSMO role is transferred from DC2 to DC1,
but on DC1 there's no replica link from DC2.

Resolution
 1. Wait. As mentioned, this condition is transient and doesn't normally warrant
troubleshooting.

Assume that replication topology changes of the type listed in the Cause section
are taking place in your Active Directory forest. In this situation, wait for the error
condition to correct itself with time.

2. Avoid the use of the repadmin /syncall command and equivalents until domain
controllers starting replication and the destination DCs being replicated to agree
source DCs and directory partitions being replicated.

3. Make originating changes in the right places.

4. Push and Pull changes connection object and partition changes around as
required.

5. Go Direct.

If the replicate now command from \DC3 to \DC2 when the DSSITE.MSC snap-in is
run from the console of \DC1 but focused on \DC4, cut out the middle men.

If the error is caused by root cause no. 3, then after the user gives the correct
input, the error won't happen. For example, in case no. 1 of scenario no. 3, if the
user input a correct <src DC> such that on <dest DC> there's a replica link from
<src DC> for <the NC>, the repadmin /replicate command will be executed
successfully.

6. Resolve replication failures blocking end-to-end replication.

7. REPADMIN /REPLICATE.

8. NTDS Replication event 1586.

For NTDS Replication event 1586, transfer the DPC role to an Active Directory
domain controller that currently a direct replication partner of the previous domain
PDC.

More information

repadmin /syncall

The repadmin /syncall operation will cause a DC to start replication from all of its
source replication partners and make the source replication partners start replication
from all of their source replication partners, and so on.
For example, suppose we have a replication topology DC1 <- DC2 <- DC3. repadmin
/syncall on DC1 will start the following replication: DC2 <- DC3, and DC1 <- DC2.

There are two cases where error 8452 might be observed in this scenario:

Case 1: Change the replication topology to make DC2 inbound replicate from DC4 so
that the current topology becomes DC1 <- DC2 <- DC4.

If we call repadmin /syncall on DC1 before knowledge of the DC2 <- DC4 topology
change inbound replicates to DC1, the syncall operation will start DC2 <- DC3
replications because DC1 still has the old replication topology stored locally. On DC2 at
this moment, KCC has created a replica link from DC4 and has deleted the replica link
from DC3. So the replication from DC2 <- DC3 can't be executed and the operation logs
error 8452.

Case 2: Suppose an NC on DC3 is being removing while we call repadmin /syncall <the
NC> on DC1. DC2 <- DC3 replication will be started as before. Because the NC on DC3 is

in the process of being removed, it isn't a valid replication source, the error 8452 will be
observed.

Active Directory sites and services (DSSITE.MSC) ->

replicate now
The Active Directory Sites and Services snap-in, DSSITE.MSC uses the topology
information stored in its local copy of AD.

Given the replication topology DC1 <- DC2 <- DC3, a connection object exists under
DC2's NTDS Settings object. This connection object represents the route for DC2 to
inbound replicate an NC (or multiple NCs) from DC3. If we right-click on this connection
object and select replicate now, we will start a DC2 <- DC3 replication on DC2.

As in the REPAMIN /SYNCALL example, there are also two cases where we might observe
error 8452.

Case 1: Suppose we change the replication topology on DC2 to make it inbound

replicate from DC4. The new replication topology is DC1 <- DC2 <- DC4. Until
knowledge of this topology change outbound replicates to DC1, the topology on DC1 is
still the old topology of DC1 <- DC2 <- DC3.

Starting the Active Directory Sites and Services UI focused on DC1s copy of Active
Directory still shows that DC2 has an inbound connection object from source DC3.
Right-clicking on DCs inbound connection object from DC2 and choosing replicate now
will start a DC2 <- DC3 replication on DC2. However, the KCC on DC2 already removed
the replica link inbound replicating to DC2 from DC3 and created a replica link to DC2.
Because the replication attempt DC2 <-> DC2 can't be executed, the request fails error
8452.

Case 2: Suppose we're removing an NC on DC3 when we right-click the connection

object, and select replicate now on DC1 to start DC2 <- DC3 replication for this NC.
Because the NC on DC3 is in the process of being removed, DC3 isn't a valid replication
source. So we'll see error 8452.

repadmin /replicate or repadmin /sync

The replicate (or sync ) command of repadmin triggers immediate replication of a

naming context (directory partition) to a destination DC from a source DC. Its
(simplified) syntax is: repadmin /replicate <dest DC> <src DC> <replicated NC> .

There are two cases that we'll trigger error 8452 when the repadmin /replicate (or
sync ) command is used to start a replication:

Case 1: the <src DC> parameter isn't a replication partner of <dest DC> for <replicated
NC>. For example, we have to replication topology DC1 <- DC2 <- DC3 in which DC2
syncs an NC from DC3. If we call repadmin /replicate DC2 DC1 the NC, a replication
DC2 <- DC1 will be started. Because on DC2 we don't have a replica link from DC1 for
the NC, this replication can't be executed, and we'll get error 8452.

Case 2: the NC is being removed on src DC when we call repadmin /replicate <dest DC>
<src DC> <the NC> , so <src DC> isn't a valid replication source. So we'll see error 8452.

DCDIAG
The showrepl (or showreps ) command of repadmin reports the replication status for
each source DC from which the destination DC has an inbound connection object. The
replications test of dcdiag checks for timely replication between DCs. If error 8452 is in
repadmin /showrepl or dcdiag /test:replications report, the reason is that the

replicated NC is being removed on the source DC when the last replication happened.

NTDS replication event 1586

NTDS replication event 1586 is generated in a mixed domain environment that contains
both Windows NT 4.0 and Active Directory DCs. In this mixed domain environment,
Active Directory domain controllers replicate among themselves using the DS replication
protocol, while the Active Directory PDC replicates to NT4 BDCs using the legacy
netlogon replication protocol. In this case, the Active Directory PDC FSMO role holder is

the single point for replication to NT4 BDCs in a common domain. The PDC maintains a
checkpoint for each BDC representing the most recent replicated change. If the PDC
FSMO role is transferred to another Active Directory DC in the domain, the information
about each individual BDC's checkpoint must be replicated to the new PDC FSMO role.
So, the new PDC FSMO role holder must have a direct replication relationship with the
old PDC FSMO role holder. If the new PDC doesn't replicate directly with the old PDC
(that is, on the new PDC there's no replica link from old PDC), then we'll see error 8452
in event 1586.

Demotion
There's another scenario that DRAERR_NoReplica error will be returned. When we
demote a DC, it will use DC locator to find a DC to replicate local changes to. If the
found DC doesn't replicate directly with the being-deleted DC, DRAERR_NoReplica will
be returned and DC locator will be called to find a destination DC. In this scenario, the
error isn't logged so it isn't observed.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Related Links
How the Active Directory Replication Model Works
RepsFrom

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 8453:
Replication access was denied
Article • 02/19/2024

This article describes how to troubleshoot a problem where Active Directory replication
fails and generates error 8453: Replication access was denied.

Applies to: Windows Server 2012 R2

Original KB number: 2022387

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Summary
This error 8453 has the following primary causes:

The destination domain controller doesn't have the required permissions to

replicate the naming context/partition.

The administrator who manually started replication doesn't have permissions to do

so.

７ Note

This condition doesn't affect periodic or scheduled replication.

Top cause
For period or scheduled replication, if the destination domain controller is a Read-only
Domain Controller (RODC):

The Enterprise Read-Only Domain Controllers security group doesn't have Replicating
Directory Changes permissions on the root of the naming context (NC) for the partition
that doesn't replicate and returns error 8453.
Top solution
On each NC that RODCs don't replicate and that returns error 8453, grant Replicating
Directory Changes permissions to the forest-root domain's Enterprise Read-only
Domain Controllers security group.

Example:

A RODC childdc2.child.contoso.com doesn't replicate the contoso.com partition and

returns error 8453. To troubleshoot this situation, follow these steps:

1. Open ADSIEDIT.msc on a contoso.com domain controller.

2. Open a connection to the contoso.com domain NC (default naming context).

3. Open the properties of the dc=contoso,dc=com NC, and select the Security tab.

4. Select Add, and enter the following entry in the text box:
Contoso\Enterprise Read-Only Domain Controllers

７ Note

This group exists only in the forest-root domain.

5. Select Check Names, and then select OK.

6. In the Permissions for Enterprise Read-Only Domain Controllers dialog box, clear
the Allow check boxes that are automatically selected:

Read
Read domain password & lockout policies
Read Other domain parameters

7. Select the Allow box next to Replicating Directory Changes, and then select OK.

If these steps don't resolve the problem, see the rest of this article.

Symptoms
When this problem occurs, you experience one or more of the following symptoms:

The DCDIAG Replication test ( DCDIAG /TEST:NCSecDesc ) reports that the tested
domain controller failed test replications and has a status of 8453: Replication
access was denied:
 Output

Starting test: Replications

[Replications Check,<destination domain controller] A recent
replication attempt failed:
From <source DC> to <Destination DC
Naming Context: <DN path of failing directory partition>
The replication generated an error (8453):
Replication access was denied.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
%#% failures have occurred since the last success.
The machine account for the destination <destination DC>.
is not configured properly.
Check the userAccountControl field.
Kerberos Error.
The machine account is not present, or does not match on the.
destination, source or KDC servers.
Verify domain partition of KDC is in sync with rest of enterprise.
The tool repadmin/syncall can be used for this purpose.
......................... <DC tested by DCDIAG> failed test
Replications

The DCDIAG NCSecDesc test ( DCDIAG /TEST:NCSecDesc ) reports that the domain
controller that was tested by DCDIAG failed test NCSecDec and that one or more
permissions are missing on the NC head of one or more directory partitions on the
tested domain controller that was tested by DCDIAG:

Output

Starting test: NCSecDesc

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
Replicating Directory Changes <- List of
missing access
Replication Synchronization <- rights
required for each Manage Replication Topology
<- security group could vary
Replicating Directory Changes In Filtered Set <-
depending in missing
access rights for the naming context: <- right
in your environment
DC=contoso,DC=com
Error CONTOSO\Domain Controllers doesn't have
Replicating Directory Changes All
access rights for the naming context:
DC=contoso,DC=com
Error CONTOSO\Enterprise Read-Only Domain Controllers doesn't have
Replicating Directory Changes
access rights for the naming context:
DC=contoso,DC=com
......................... CONTOSO-DC2 failed test NCSecDesc
The DCDIAG MachineAccount test ( DCDIAG /TEST:MachineAccount ) reports that the
domain controller that was tested by DCDIAG failed test MachineAccount because
the UserAccountControl attribute on the domain controllers computer account is
missing the SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION flags:

Output

Starting test: MachineAccount

The account CONTOSO-DC2 is not trusted for delegation . It cannot
replicate.
The account CONTOSO-DC2 is not a DC account. It cannot replicate.
Warning: Attribute userAccountControl of CONTOSO-DC2 is:
0x288 = ( HOMEDIR_REQUIRED | ENCRYPTED_TEXT_PASSWORD_ALLOWED |
NORMAL_ACCOUNT )
Typical setting for a DC is
0x82000 = ( SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION )
This may be affecting replication?
......................... CONTOSO-DC2 failed test MachineAccount

The DCDIAG KCC event log test indicates the hexadecimal equivalent of Microsoft-
Windows-ActiveDirectory_DomainService event 2896:

B50 hex = 2896 decimal. This error may be logged every 60 seconds on the
infrastructure master domain controller.

Output

Starting test: KccEvent

The KCC Event log test
An error event occurred. EventID: 0xC0000B50
Time Generated: 06/25/2010 07:45:07

Event String:
A client made a DirSync LDAP request for a directory partition. Access
was denied due to the following error.

Directory partition:
<DN path of directory partition>

Error value:
8453 Replication access was denied.

User Action
The client may not have access for this request. If the client requires
it, they should be assigned the control access right "Replicating
Directory Changes" on the directory partition in question.

REPADMIN.EXE reports that a replication attempt failed and returned an 8453

status.
REPADMIN commands that commonly indicate the 8453 status include but aren't
limited to the following.

REPADMIN /KCC

REPADMIN /REHOST

REPADMIN /REPLICATE

REPADMIN /REPLSUM

REPADMIN /SHOWREPL

REPADMIN /SHOWREPS

REPADMIN /SHOWUTDVEC

REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS showing inbound replication from

CONTOSO-DC2 to CONTOSO-DC1 that fail and return the replication access
was denied error is as follows:

Output

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID:
DSA invocationID:
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 8453 (0x2105):
Replication access was denied.
<#> consecutive failure(s).
Last success @ <date> <time>.

The replicate now command in Active Directory Sites and Services (DSSITE.MSC)
returns a replication access was denied error.

Right-clicking the connection object from a source domain controller and then
selecting replicate now fails. And a replication access was denied error is returned.
The following error message is displayed:

Output
 Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to
synchronize naming context <%directory partition name%> from Domain
Controller <Source DC> to Domain Controller <Destination DC>:
Replication access was denied

The operation will not continue

Buttons in Dialog: OK

NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService

events that have the 8453 status are logged in the Active Directory Directive
Services (AD DS) event log.

Active Directory events that commonly indicate the 8453 status include but aren't
limited to the following events:

ﾉ Expand table

Event Source Event Event String

ID

Microsoft-Windows- 1699 This directory service failed to retrieve the changes

ActiveDirectory_DomainService requested for the following directory partition. As a
result, it was unable to send change requests to
the directory service at the following network
address.

Microsoft-Windows- 2896 A client made a DirSync LDAP request for a

ActiveDirectory_DomainService directory partition. Access was denied due to the
following error.

NTDS General 1655 Active Directory attempted to communicate with

the following global catalog and the attempts were
unsuccessful.

NTDS KCC 1265 The attempt to establish a replication link with

parameters
Partition: <partition DN path>
 Event Source Event Event String
ID

Source DSA DN: <DN of source DC NTDS Settings

object>
Source DSA Address: <source DCs fully qualified
CNAME>
Inter-site Transport (if any): <dn path>
failed with the following status:

NTDS KCC 1925 The attempt to establish a replication link for the
following writable directory partition failed.

Cause
Error 8453 (Replication Access was denied) has multiple root causes, including:

The UserAccountControl attribute on the destination domain controller computer

account is missing either of the following flags:
SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION

The default permissions don't exist on one or more directory partitions to allow
scheduled replication to occur in the operating system's security context.

The default or custom permissions don't exist on one or more directory partitions
to allow users to trigger ad-hoc or immediate replication by using DSSITE.MSC
replicate now, repadmin /replicate , repadmin /syncall , or similar commands.

The permissions that are required to trigger ad-hoc replication are correctly
defined on the relevant directory partitions. However, the user isn't a member of
any security groups that have been granted the replication directory changes
permission.

The user who triggers ad-hoc replication is a member of the required security
groups, and those security groups have been granted the Replicate Directory
Changes permission. However, membership in the group that's granting the
replicating directory changes permission is removed from the user's security token
by the User Account Control split user access token feature. This feature was
introduced in Windows Vista and Windows Server 2008.

７ Note

Don't confuse the User Account Control split token security feature that was
introduced in Vista and Windows Server 2008 with the UserAccountControl
 attribute that's defined on domain controller role computer accounts that are
stored by the Active Directory service.

If the destination domain controller is an RODC, RODCPREP hasn't been run in

domains that are currently hosting read-only domain controllers, or the Enterprise
Read-Only Domain Controllers group doesn't have Replicate Directory Changes
permissions for the partition that is not replicating.

DCs that are running new operating system versions were added to an existing
forest where Office Communication Server has been installed.

You have Lightweight Directory Services (LDS) instances. And the NTDS Settings
object for the affected instances is missing from the LDS configuration container.
For example, you see the following entry:

CN=NtDs Settings,CN=Server1$ADAMINST1,CN=Server,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,CN={A560B9B8-6B05-4000-9A1F-
9A853DB6615A}

Active Directory errors and events, such as those mentioned in the Symptoms section,
may also occur and generate an error 5 message (Access is denied).

The steps for error 5 or error 8453 mentioned in the Resolution section won't resolve
replication failures on computers that are currently failing replication and generating the
other error message.

Common root causes for Active Directory operations failing that are generating error 5
messages include:

Excessive Time Skew

The fragmentation of UDP-formatted Kerberos packets by intermediate devices on
the network
Missing access this computer from network rights.
Broken secure channels or intra-domain trusts
CrashOnAuditFail = 2 entry in the registry

Resolution
To resolve this problem, use the following methods.

Run a health-check by using DCDIAG + DCDIAG

/test:CheckSecurityError
 1. Run DCDIAG on the destination DC that's reporting the 8453 error or event.
2. Run DCDIAG on the source domain controller on which the destination domain
controller is reporting the 8453 error or event.
3. Run DCDIAG /test:CheckSecurityError on the destination domain controller.
4. Run DCDIAG /test:CheckSecurityError on the source DC.

Fix invalid UserAccountControl

The UserAccountControl attribute includes a bitmask that defines the capabilities and
state of a user or computer account. For more information about UserAccountControl
flags, see User-Account-Control attribute.

The typical UserAccountControl attribute value for a writeable (full) DC computer

account is 532480 decimal or 82000 hex. UserAccountControl values for a DC computer
account can vary, but must contain the SERVER_TRUST_ACCOUNT and
TRUSTED_FOR_DELEGATION flags, as shown in the following table.

ﾉ Expand table

Property flag Hex value Decimal value

SERVER_TRUST_ACCOUNT 0x2000 8192

TRUSTED_FOR_DELEGATION 0x80000 524288

UserAccountControl Value 0x82000 532480

The typical UserAccountControl attribute value for a read-only domain controller

computer account is 83890176 decimal or 5001000 hex.

ﾉ Expand table

Property flag Hex value Decimal value

WORKSTATION_TRUST_ACCOUNT 0x1000 4096

TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION 0x1000000 16777216

PARTIAL_SECRETS_ACCOUNT 0X4000000 67108864

Typical UserAccountControl Value for RODC 0x5001000 83890176

The UserAccountControl attribute on the destination domain controller is

missing the SERVER_TRUST_ACCOUNT flag
If the DCDIAG MachineAccount test fails and returns a failed test
MachineAcccount error message, and the UserAccountControl attribute on the
tested domain controller is missing the SERVER_TRUST_ACCOUNT flag, add the
missing flag in the tested domain controller's copy of Active Directory.

1. Start ADSIEDIT.MSC on the console of the domain controller that's missing

the SERVER_TRUST_ACCOUNT as reported by DCDIAG.
2. Right-click ADSIEDIT in the top-left pane of ADSIEDIT.MSC, and then select
connect to.
3. In the Connection Settings dialog box, click Select a well known naming
context, and then select Default naming context (the computer account
domain partition).
4. Click Select or type a domain or server. And select the name of the domain
controller that's failing in DCDIAG.
5. Select OK.
6. In the domain naming context, locate and right-click the domain controller
computer account, and select Properties.
7. Double-click the UserAccountControl attribute, and then record its decimal
value.
8. Start Windows Calculator in programmer mode (Windows Server 2008 and
later versions).
9. Enter the decimal value for UserAccountControl. Convert the decimal value
to its hexadecimal equivalent, add 0x80000 to the existing value, and then
press the equals sign (=).
10. Convert the newly calculated UserAccountContorl value to its decimal
equivalent.
11. Enter the new decimal value from Windows Calculator to the
UserAccountControl attribute in ADSIEDIT.MSC.
12. Select OK twice to save.

The UserAccountControl attribute on the destination domain controller is

missing the TRUSTED_FOR_DELEGATION flag

If the DCDIAG MachineAccount test returns a failed test MachineAcccount error

message, and the UserAccountControl attribute on the tested domain controller is
missing the TRUSTED _FOR_DELEGATION flag, add the missing flag in the tested
domain controller's copy of Active Directory.

1. Start Active Directory Users and Computers (DSA.MSC) on the console of the
domain controller that was tested by DCDIAG.

2. Right-click the domain controller computer account.

 3. Select the Delegation tab.

4. On the domain controller machine account, select the Trusted this computer
for delegation to any service (Kerberos only) option.

Fix invalid default security descriptors

Active Directory operations take place in the security context of the account that started
the operation. Default permissions on Active Directory partitions allow the following
operations:

Members of the Enterprise Administrators group can start ad-hoc replication

between any domain controller in any domain in the same forest.
Members of the Built-in Administrators group can start ad-hoc replication between
domain controllers in the same domain.
Domain Controllers in the same forest can start replication by using either change
notification or replication schedule.

Default permissions on Active Directory partitions don't allow the following operations
by default:

Members of the Built-in Administrators group in one domain can't start ad-hoc
replication to domain controllers in that domain from domain controllers in
different domains.
Users that aren't members of the Built-in Administrators group can't start ad-hoc
replication from any other domain controller in the same domain or forest.

By design, these operations fail until default permissions or group memberships are
modified.

Permissions are defined at the top of each directory partition (NC head), and are
inherited throughout the partition tree. Verify that explicit groups (groups that the user
is directly a member of) and implicit groups (groups that explicit groups have nested
membership of) have the required permissions. Also verify that Deny permissions
assigned to implicit or explicit groups don't take precedence over the required
permissions. For more information about default directory partitions, see Default
Security of the Configuration Directory Partition.

Verify that default permissions exist in the top of each directory partition that is
failing and returning replication access was denied

If ad-hoc replication is failing between domain controllers in different domains, or

between domain controllers in the same domain for non-domain administrators,
see the Grant non-domain admins permissions section.

If ad-hoc replication is failing for members of the Enterprise Administrators group,

focus on NC head permissions that are granted to the Enterprise Administrators
group.

If ad-hoc replication is failing for members of a Domain Administrators group,

focus on the permissions that are granted to the built-in Administrators Security
group.

If a scheduled replication that's started by domain controllers in a forest is failing

and returning error 8453, focus on permissions for the following security groups:

Enterprise Domain Controllers

Enterprise Read-Only Domain Controllers

If a scheduled replication is started by domain controllers on a read-only

domain controller (RODC) is failing and returning error 8453, verify that the
Enterprise Read-Only Domain Controllers security group is granted the required
access on the NC head of each directory partition.

The following table shows the default permission that's defined on the schema,
configuration, domain, and DNS applications by various Windows versions.

ﾉ Expand table

DACL required on each directory partition Windows Server 2008 and later

Manage Replication Topology X

Replicating Directory Changes X

Replication Synchronization X

Replicating Directory Changes All X

Replicating Changes in Filter Set X

 ７ Note

The DCDIAG NcSecDesc test may report false positive errors when it's run
in environments that have mixed system versions.

The DSACLS command can be used to dump the permissions on a given

directory partition by using the following syntax:
DSACLS <DN path of directory partition>

For example, use the following command:

Console

C:\>dsacls dc=contoso,dc=com

The command can be targeted to a remote domain controller by using the

syntax:

Console

c:\>dsacls \\contoso-dc2\dc=contoso,dc=com

Be wary of DENY permission on NC heads removing the permissions for groups

that the failing user is a direct or nested member of.

Add required permissions that are missing

Use the Active Directory ACL editor in ADSIEDIT.MSC to add the missing DACLS.

Grant non-domain admins permissions

Grant non-domain admins the following permissions:

To replicate between domain controllers in the same domain for non-enterprise

administrators
To replicate between domain controllers in different domains

Default permissions on Active Directory partitions don't allow the following operations:

Members of the Built-in Administrators group in one domain can't initiate ad-hoc
replication from domain controllers in different domains.
 Users that aren't members of the built-in domain admins group to initiate ad-hoc
replication between domain controllers in the same domain or different domain.

These operations fail until permissions on directory partitions are modified.

To resolve this problem, use either of the following methods:

Add users to existing groups that have already been the granted the required
permissions to replicate directory partitions. (Add the Domain administrators for
replication in the same domain, or the Enterprise Administrators group to trigger
ad-hoc replication between different domains.)

Create your own group, grant that group the required permissions on directory
partitions throughout the forest, and then add users to those groups.

For more information, see KB303972 . Grant the security group in question the same
permissions listed in the table in the Fix invalid default security descriptors section.

Verify group membership in the required security groups

After the correct security groups have been granted the required permissions on
directory partitions, verify that users who start replication have effective membership in
direct or nested security groups that are granted replication permissions. To do it, follow
these steps:

1. Log on by using the user account in which ad-hoc replication is failing and
returning replication access was denied.

2. At a command prompt, run the following command:

Console

WHOAMI /ALL

3. Verify membership in the security groups that have been granted the replicating
directory changes permissions on the relevant directory partitions.

If the user was added to the permitted group that was changed after the last user
logon, log on a second time, and then run the WHOAMI /ALL command again.

If this command still does not show membership in the expected security groups,
open an elevated Command Prompt window, on the local computer, and run
WHOAMI /ALL at the command prompt.
 If the group membership differs between the WHOAMI /ALL output that is generated
by elevated and non-elevated command prompts, see When you run an LDAP
query against a Windows Server 2008-based domain controller, you obtain a
partial attribute list .

4. Verify that the expected nested group memberships exist.

If a user is getting permissions to run ad-hoc replication as a member of nested

group, which is a member of group that has been directly granted replication
permissions, verify the nested group membership chain. We've seen ad-hoc Active
Directory replication failures because the Domain Administrators and Enterprise
Administrators groups were removed from the built-in Administrators groups.

RODC replication
If computer-initiated replication is failing on RODCs, verify that you have run ADPREP
/RODCPREP and that the Enterprise Read-Only Domain Controller group is granted the

Replicate Directory Changes right on each NC head.

Missing NTDS Settings object for LDS server

In Active Directory Lightweight Directory Services (LDS), it's possible to delete the object
without a metadata cleanup in DBDSUTIL. It may cause this problem. To restore the
instance to the configuration set, you must uninstall the LDS instance on the affected
servers, and then run the ADAM configuration wizard.

７ Note

If you have added LDAPS support for the instance, you must configure the
certificate in the service store again, because uninstalling the instance also removes
the service instance.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Active Directory
replication error 8614
Article • 02/19/2024

This article provides the steps to troubleshoot Active Directory replication error 8614.

Applies to: Windows Server 2012 R2

Original KB number: 2020053

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, please ask the Microsoft
Community .

Symptoms
1. DCDIAG reports that Active Directory Replications test failed with error status code
8614: Active Directory can't replicate with this server because the time since the
last replication with this server has exceeded the tombstone lifetime.

Output

Testing server: <site name><destination dc name>

Starting test: Replications
* Replications Check
[Replications Check,<destination DC name] A recent replication attempt
failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (8614):
Active Directory cannot replicate with this server because the time
since the last replication with this server has exceeded the tombstone
lifetime.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
3 failures have occurred since the last success.

2. REPADMIN.EXE reports that the last replication attempt failed with status 8614.
REPADMIN commands that commonly cite the 8614 status include but aren't
limited to:
 REPADMIN /REPLSUM
REPADMIN /SHOWREPL

REPADMIN /SHOWREPS
REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS depicting inbound replication from

CONTOSO-DC2 to CONTOSO-DC1 failing with the replication access was denied
error is shown below:

Output

efault-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID:
DSA invocationID:

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID:
Last attempt @ <date> <time> failed, result 8614(0x21a6):
The Active Directory cannot replicate with this server because the time
since the last replication with this server has exceeded the tombstone
lifetime.
<#> consecutive failure(s).
Last success @ <date> <time>.

3. NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService

events with the five statuses are logged in the Directory Service event log.

Active Directory events that commonly cite the 8524 status include but aren't
limited to:

ﾉ Expand table

Event ID Event string

source

NTDS KCC 1925 The attempt to establish a replication link for the following writable
directory partition failed.

4. NTDS Replication Event 2042 may be logged in the Directory Service event log:

Output
 Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2042
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: <name of DC that logged event>

Description:
It has been too long since this machine last replicated with the named
source
machine. The time between replications with this source has exceeded
the tombstone
lifetime. Replication has been stopped with this source.

The reason that replication is not allowed to continue is that the two
machine's views of deleted objects may now be different. The source
machine may still have copies of objects that have been deleted (and
garbage collected) on this machine. If they were allowed to replicate,
the source machine might return objects which have already been
deleted.

Time of last successful replication: YYYY-MM-DD HH:MM:SS

Invocation ID of source: <32 character GUID for source DC>
Name of source: <fully qualified cname record of source DC>
Tombstone lifetime (days): <current TSL value. Default = 60 or 180
days>

The replication operation has failed.

User Action:

Determine which of the two machines was disconnected from the forest
and is now out of date. You have three options:

1. Demote or reinstall the machine(s) that were disconnected.

2. Use the repadmin /removelingeringobjects tool to remove inconsistent
deleted objects and then resume replication.
3. Resume replication. Inconsistent deleted objects may be introduced.
You can continue replication by using the following registry key. Once
the systems replicate once, it's recommended that you remove the key to
reinstate the protection.

5. The replicate now command in Active Directory Sites and Services returns the
following message:

Active Directory cannot replicate with this server because the time since the
last replication with this server has exceeded the tombstone lifetime.

Right-clicking on the connection object from a source DC and choosing replicate

now in Active Directory Sites and Services (DSSITE.MSC) is unsuccessful. You
 receive the following message:

Active Directory cannot replicate with this server because the time since the
last replication with this server has exceeded the tombstone lifetime.

The on-screen error message text is as follows:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to
synchronize naming context <%directory partition name%> from Domain
Controller <Source DC> to Domain Controller <Destination DC>:

The Active Directory cannot replicate with this server because the time since
the last replication with this server has exceeded the tombstone lifetime.
The operation will not continue

Buttons in the dialog: OK

Cause
Active Directory domain controllers support multi-master replication. Any domain
controller that holds a writable partition can originate a create, modify, or delete of an
object or attribute (value). Knowledge of object/attribute deletion persists for
tombstone lifetime number of days. (See Information about lingering objects in a
Windows Server Active Directory forest .

Active Directory requires end-to-end replication from all partition holders to transitively
replicate all originating deletes for directory partitions to all partition holders. Failure to
inbound-replicate a directory partition in a rolling TSL number of days results in
lingering objects. A lingering object is an object that has been intentionally deleted by
at least one DC, but incorrectly exists on destination DCs which failed to inbound-
replicate the transient knowledge of all unique deletions.

Error 8614 is an example of logic added in domain controllers that are running Windows
Server 2003 or a later version. It quarantines the spread of lingering objects and
identifies long-term replication failures that cause inconsistent directory partitions.

Root causes for error 8614 and NTDS Replication Event 2042 include:

1. The destination DC that logs the 8614 error failed to inbound-replicate a directory
partition from one or more source DCs for tombstone lifetime number of days.
 2. System time on the destination DC moved, or jumped, tombstone lifetime one or
more numbers of days in the future since the last successful replication. It gives the
appearance to the replication engine that the destination DC failed to inbound-
replicate a directory partition for tombstone lifetime elapsed number of days.

Time jumps can occur when the following conditions are true:

A destination DC successfully inbound-replicates, adopts bad system time TSL

or more number of days in the future.
The destination DC then tries to inbound-replicate from a source that was
last replicated from TSL or more number of days in the past.

Or

Time jumps from current time to a date/time tombstone lifetime or more days in
the past, successfully inbound-replicates. Then it tries to inbound-replicate after it
adopts time TSL or more number of days in the future.

Basically, the cause and resolution for replication error 8614 apply equally to the cause
and resolution for NTDS replication event 2042.

Resolution

７ Note

There are two action plans to recover Active Directory domain controllers that log
error status 8614 or NTDS Replication event 2042. You can either force-demote the
domain controller, or use the action plan below that says, Check for required fixes,
look for time jumps, check for lingering objects, and remove them if present,
remove any replication quarantines, resolve replication failures, then put the DC
back into service. Force-demoting such DCs may be easier and faster, but can
result in the loss of originating updates (that is, data loss) on the domain controller
that's being force-demoted. Active Directory recovers gracefully from this condition
by following the steps below. Select the best solution for your scenario. Don't
assume that a force demotion is the only workable solution, especially when
replication failure is easy to resolve or is external to Active Directory.

1. Check for nondefault values of tombstone lifetime.

By default, tombstone lifetime uses either 60 or 180 days, depending on the

version of Windows deployed in your forest. Microsoft Support regularly sees DCs
that have failed inbound replication for those periods of time. It's also possible that
 the tombstone lifetime has been configured to a short period, such as two days. If
so, DCs that didn't inbound-replicate for, say, five days will fail the following test:

All DCs must replicate with a rolling TSL number of days

Use repadmin /showattr to see whether a nondefault value for the

TombstoneLifetime attribute has been configured.

Console

repadmin /showattr "CN=Directory Service,CN=Windows

NT,CN=Services,CN=Configuration,DC=<forest root domain>,DC=<top level
domain>"

If the attribute isn't present in the showattr output, an internal default value is
being used.

2. Check for DCs that failed inbound replication for TSL number of days.

Run repadmin /showrepl * /csv parsed by using Excel as specified in the Verify
successful replication to a domain controller section. Sort the replsum output in
Excel on the last replication success column in the order from least current to the
most current date and time.

3. Check for Windows Server 2003 RTM domain controllers.

If the 8614 error occurred on a Windows Server 2003 RTM domain controller,
install the latest Windows Server 2003 service pack.

4. Check for time jumps.

To determine whether a time jump occurred, check event and diagnostic logs
( repadmin /showreps , dcdiag logs) on destination DCs that are logging 8614 errors
for the following timestamps:

Date stamps that predate the release of an operating system. For example,
date stamps from Windows Server 2003 for an OS released in Windows
Server 2008.
Date stamps that predate the installation of the operating system in your
forest.
Date stamps in the future.
No events being logged in a given date range.

Microsoft Support teams have seen system time on production domain controllers
incorrectly jump hours, days, weeks, years, and even tens of years in the past and
 future.

If system time was found to be inaccurate, correct it. Then try to determine why
time jumped, and what can be done to prevent inaccurate time going forward vs.
just correcting the bad time. Possible areas to investigate include:

Was the forest root PDC configured by using an external time source?
Are reference time sources online, available on the network, and resolvable in
DNS?
Was the Microsoft or third-party time service running and in an error-free
state?
Are DC-role computers configured to use NT5DS hierarchy to source time?
Was the time rollback protection described in How to configure the Windows
Time service against a large time offset in place?
Do system clocks have good batteries and accurate time in the BIOS?
Are virtual host and guest computers configured to source time according to
the hosting manufacturers recommendations?

This article How to configure the Windows Time service against a large time
offset documents steps to help protect domain controllers from listening to
invalid time samples. More information on MaxPosPhaseCorrection and
MaxNegPhaseCorrection is available in Windows Time Service.

5. Check for and remove lingering objects if they're present.

The point of the 8614 error replication quarantine is to check for lingering objects
and remove them, if present, in each locally held partition before setting Allow
Replication with divergent and corrupt partner to 1 in the registry of the
destination DC, even if you think that all destination DCs in the forest are running
in strict replication consistency.

Removing lingering objects is beyond the scope of this article. For more
information, see the following articles:

Information about lingering objects in a Windows Server Active Directory

forest .

Event ID 1388 or 1988: A lingering object is detected

Repadmin syntax is shown here:

ﾉ Expand table
 Syntax Online help (Windows Server
2008 and later)

c:\>repadmin /removelingeringobjects c:\>repadmin

<Dest_DSA_LIST> <Source DSA GUID> <NC> /help:removelingeringobject
[/advisory_mode]

6. Evaluate setting strict replication on destination DCs.

Strict mode replication prevents lingering objects from being reanimated on

destination DCs that have used garbage collection to create, delete, and reclaim
intentionally deleted objects.

The registry key for strict replication:

Path: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
Setting: Strict Replication Consistency <- not case sensitive>
Type: reg_dword
Value: 0 | 1

Repadmin syntax for enabling and disabling strict replication on a single or multiple

DCs is as follows:

ﾉ Expand table

Syntax Online help Enable on a Enable on Enable on

(Windows Server single DC all DCs in all GCs in
2008 and later) forest forest

repadmin /regkey Repadmin repadmin /regkey repadmin repadmin

<DSA_LIST> /help:regkey <fully qualified /regkey * /regkey gc:
<{+|-}key> [value computer name> +strict +strict
[/reg_sz] ] +strict

7. Set Allow replication with divergent and corrupt partner to 1 on the 8614 DC.

After any lingering objects are removed, disable the time-based replication
quarantine:

Registry method：

Registry path: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters

Registry setting: Allow replication with divergent and corrupt partner <- Not
case sensitive》
Registry value: 0 = disallow, 1 = allow
 Repadmin method：

ﾉ Expand table

Syntax Online help Enable on a Enable on all Enable on all

(Windows single DC DCs in forest GCs in forest
Server 2008
and later)

repadmin Repadmin repadmin /regkey repadmin repadmin /regkey

/regkey /help:regkey dc01.contoso.com /regkey * GC:
<DSA_LIST> +allowDivergent +allowDivergent +allowDivergent
<{+|-}key>
[value
[/reg_sz] ]

8. Resolve AD replication failures if they're present.

When the 8614 error status is logged on a destination DC, prior replication errors
that were logged in the previous TSL number of days are masked.

The fact that the 8614 error was reported by the destination DC doesn't mean that
the replication fault resides on the destination DC. Instead, the source of the
replication failure could lie with the network or DNS name resolution. Or, there
could be a problem with one of the following items:

authentication
jet database
topology
the replication engine on either the source DC or the destination DC

Review past Directory Service events and diagnostic output (dcdiag, repadmin logs)
that was generated by the source DC, by the destination DC, and by alternative
replication partners in the past to identify the scope and failure status that is
preventing replication between the destination DC and the source DC.

9. Delete Allow replication with divergent and corrupt partner or set Allow
replication with divergent and corrupt partner to 0 in the registry.

10. Monitor Active Directory replication daily going forward.

Monitor end-to-end replication in your Active Directory forest daily by using an

Active Directory monitoring application. One inexpensive but effective option is to
run repadmin /showrepl * /csv and then parse the results in Excel. For more
information, see Method 2: Monitor replication by using a command line.
 Identify DCs that are approaching replication failures for 50 percent and for 90
percent of tombstone lifetime. Put them on a watch list. At 50 percent of TSL, make
a strong push to resolve replication errors. At 90 percent, consider demoting DCs
that cause replication errors forcibly if it's necessary. To do so, use the dcpromo
/forceremoval command.

Again, replication errors that are logged on a destination DC may be caused by a

problem on:

The source DC
The destination DC
The underlying network

Therefore, try to determine the cause and where the fault is before you take
preventive action.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

References
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 5 -
Access is denied
Article • 02/19/2024

This article describes the symptoms, cause, and resolution steps for situations where AD
operations fail with error 5: Access is denied.

Applies to: Windows Server 2012 R2

Original KB number: 2002013

Symptoms
1. DCDIAG reports that Active Directory Replications test has failed with error status code
(5): access is denied.

Output

Testing server: <site name><destination dc name>

Starting test: Replications
Replications Check
[Replications Check,<destination DC name] A recent replication attempt
failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (5):
Access is denied.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
3 failures have occurred since the last success.

2. DCDIAG reports that DsBindWithSpnEx() failed with error 5.

3. REPADMIN.EXE reports that the last replication attempt has failed with status 5.

REPADMIN commands that commonly cite the status 5 include but aren't limited to:

REPADMIN /KCC

REPADMIN /REPLICATE
REPADMIN /REPLSUM

REPADMIN /SHOWREPL

REPADMIN /SHOWREPS
REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS showing inbound replication from CONTOSO-
DC2 to CONTOSO-DC1 failing with the replication access was denied error is shown
 below:

Output

Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01

==== INBOUND NEIGHBORS ======================================

DC=contoso, DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 5 (0x5):
Access is denied.
<#> consecutive failure(s).
Last success @ <date> <time>.

4. NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService events

with the status 5 are logged in the directory service event log.

Active Directory events that commonly cite the 8524 status include but aren't limited to:

ﾉ Expand table

Event Source Event String

NTDS 1655 Active Directory attempted to communicate with the following global
General catalog and the attempts were unsuccessful.

NTDS KCC 1925 The attempt to establish a replication link for the following writable
directory partition failed.

NTDS KCC 1926 The attempt to establish a replication link to a read-only directory
partition with the following parameters failed.

5. The replicate now command in Active Directory Sites and Services returns Access is
denied.

Right-clicking on the connection object from a source DC and choosing replicate now
fails with Access is denied. The on-screen error message text and screenshot is shown
below:

6. Dialog title text: Replicate Now

Dialog message text:

The following error occurred during the attempt to synchronize naming context
<%directory partition name%> from Domain Controller <Source DC> to Domain
 Controller <Destination DC>: Access is denied

The operation will not continue

Buttons in Dialog: OK

Cause
Valid root causes for error 5: access is denied include:

1. The RestrictRemoteClients setting in the registry has a value of 2.

2. The Access this computer from network user right isn't granted to the Enterprise
Domain Controllers group or the administrator triggering immediate replication.
3. The CrashOnAuditFail setting in the registry of the destination DC has a value of 2.
4. There's a time difference between the Key Distribution Center (KDC) used by the
destination DC and the source DC. The time difference exceeds the maximum time skew
that's allowed by Kerberos defined in Default Domain policy.
5. There's an SMB signing mismatch between the source and destination DCs.
6. There's an LMCompatiblity mismatch between the source and destination DCs.
7. Service principal names are either not registered or not present because of simple
replication latency or a replication failure.
8. UDP formatted Kerberos packets are being fragmented by network infrastructure
devices like routers and switches.
9. The secure channel on the source or destination DC is invalid.
10. Trust relationships in the trust chain are broken or invalid.
11. The KDCNames setting in the
HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains section of the registry

incorrectly contains the local Active Directory domain name.

12. Some network adapters have a Large Send Offload feature.
13. Antivirus software that uses a mini-firewall network adapter filter driver on the source or
destination DC.

Active Directory errors and events like those cited in the symptoms section of this KB can also
fail with error 8453 with similar error string Replication Access was denied. The following
root cause reasons can cause AD operations to fail with 8453: replication access was denied
but don't cause failures with error 5: replication is denied:

1. NC head not permitted with the replicating directory changes permission.

2. The security principal starting replication not a member of a group that has been
granted replicating directory changes.
3. Missing flags in the UserAccountControl attribute including SERVER_TRUST_ACCOUNT and
TRUSTED_FOR_DELEGATION .

4. RODC promoted into domain without having first run ADPREP /RODCPREP .

Resolution
AD Replication failing with error 5 has multiple root causes. Solve the problem initially using
tools like:

DCDIAG
DCDIAG /TEST: CheckSecurityError
NETDIAG that exposes common problems

If still unresolved, walk the known causes list in most common, least complex, least disruptive
order to least common, most complex, most disruptive order.

Run DCDIAG, DCDIAG /TEST:CheckSecurityError, and

NETDIAG
The generic DCDIAG runs multiple tests.

DCDIAG /TEST:CheckSecurityErrors was written to do specific tests (including an SPN

registration check) to troubleshoot Active Directory operations replication failing with:

error 5: access is denied

error 8453: replication access was denied

DCDIAG /TEST:CheckSecurityErrors isn't run as part of the default execution of DCDIAG.

1. Run DCDIAG on the destination DC

2. Run DCDIAG /TEST:CheckSecurityError
3. Run NETDIAG
4. Resolve any faults identified by DCDIAG and NETDIAG. Retry the previously failing
replication operation. If still failing, continue to the long way around.

The long way around

1. RestrictRemoteClients value is set to 2
 This registry value RestrictRemoteClients is set to a value of 0x2 in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC .

To resolve this issue:

a. Disable the policy that enforces this setting.

b. Delete the RestrictRemoteClients registry setting and reboot.

For more information on this setting, see RestrictRemoteClients registry key is

enabled.

The RestrictRemoteClients registry value is set by the following group policy setting:

Computer Configuration > Administrative Templates > System > Remote

Procedure Call - Restrictions for Unauthenticated RPC clients

A registry value of 0x2 is applied if the policy setting is enabled and set to
Authenticated without exceptions.

This option allows only authenticated RPC clients to connect to RPC servers running
on the computer on which the policy setting is applied. It doesn't permit exceptions.
If you select this option, a system can't receive remote anonymous calls using RPC.
This setting should never be applied to a domain controller.

2. Check Access this computer from network rights.

In a default installation of Windows, the default domain controllers policy is linked to

the domain controllers OU container. It grants the access this computer from network
user right to the following security groups:

ﾉ Expand table

Local Policy Default Domain controllers policy

Administrators Administrators

Authenticated Users Authenticated Users

Everyone Everyone

Enterprise Domain Controllers Enterprise Domain Controllers

[Pre-Windows 2000 compatible Access] [Pre-Windows 2000 compatible Access]

If Active Directory operations are failing with error 5: access is denied, verify that:

Security groups in the list above have been granted the access this computer
from network right in default domain controllers policy.
 Domain controller computer accounts are located in the domain controllers OU.
Default domain controllers policy is linked to the domain controllers OU or
alternate OUs hosting computer accounts.
Group policy is applying on the destination domain controller currently logging
error 5.
Deny Access this computer from network user right hasn't been enabled or
doesn't reference failing direct or nested groups.
Policy precedence, blocked inheritance, WMI filtering, or the like, is NOT
preventing the policy setting from applying to DC role computers.

Policy settings can be validated with RSOP.MSC but GPRESULT /Z is the preferred tool
because it's more accurate.

７ Note

Local policy takes precedence over policy defined in Sites, Domains, and OU.

７ Note

At one time it was common for administrators to remove the enterprise domain
controllers and everyone groups from the access this computer from network
right in default domain controllers policy. Removing both is fatal. There is no
reason to remove enterprise domain controllers from this right as only DCs are a
member of this group.

3. CrashOnAuditFail = 2

AD Replication fails when HKLM\System\CurrentControlSet\Control\LSA\CrashOnAuditFail

= has a value of 2,

A CrashOnAduitFail value of 2 is triggered when the Audit: Shut down system

immediately if unable to log security audits setting in Group Policy has been enabled,
and the local security event log becomes full.

Active Directory domain controllers are especially prone to maximum capacity security
logs when auditing has been enabled, and the size of the security event log has been
constrained by the Do not overwrite events (clear log manually) or Overwrite as
needed options in Event Viewer or group policy equivalents.

User Action:

If HKLM\System\CCS\Control\LSA\CrashOnAuditFail = 2:

Clear the security event log (save to alternate location as required)

 Re-evalaute any size constraints on the security event log, including policy-based
settings.
Recreate CrashOnAuditFail (REG_DWORD) = 1
Reboot

On seeing a CrashOnAuditFail value of 0 or 1, some CSS engineers have resolved access

is denied errors by again clearing the security event log, deleting the CrashOnAuditFail
registry value, and rebooting the destination DC.

Related Content: Manage auditing and security log.

4. Excessive time skew

Kerberos policy settings in the default domain policy allow for a 5-minutes difference
(default value) in system time between KDC domain controllers and a Kerberos target
server to prevent replay attacks. Some documentation states that time between the
client and the Kerberos target must have time within five minutes of each other. Others
state that in the context of Kerberos authentication, the time that matters is the delta
between the KDC used by the caller and the time on the Kerberos target. Also, Kerberos
doesn't care that system time on the relevant DCs matches current time. It only cares
that relative time difference between the KDC and target DC is inside the maximum
time skew (default five minutes or less) allowed by Kerberos policy.

In the context of Active Directory operations, the target server is the source DC being
contacted by the destination DC. Every domain controller in an Active Directory forest
(currently running the KDC service) is a potential KDC. So you'll need to consider time
accuracy on all other DCs against the source DC including time on the destination DC
itself.

Two methods to check time accuracy include:

Console

C:\> DCDIAG /TEST: CheckSecurityError

AND

Console

C:\> W32TM /MONITOR

Look for LSASRV 40960 events on the destination DC at the time of the failing
replication request that cites a GUIDed CNAME record of the source DC with extended
error:
 0xc000133: the time at the Primary Domain Controller is different than the time at
the Backup Domain Controller or member server by too large an amount.

Network traces capturing the destination computer connecting to a shared folder on

the source DC (and other operations) may show the on-screen error an extended error
has occurred. But a network trace shows:

KerberosV5:TGS Request Realm > TGS request from source DC

KerberosV5:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) > TGS response where
KRB_AP_ERR_TKE_NYV > maps to Ticket not yet valid

The TKE_NYV response indicates that the date range on the TGS ticket is newer than
time on the target, indicating excessive time skew.

７ Note

W32TM /MONITOR only checks time on DCs in the test computers domain so you'll

need to run this in each domain and compare time between the domains.

７ Note

If system time was found to be inaccurate, make an effort to figure out why and
what can be done to prevent inaccurate time going forward. Was the forest root
PDC configured with an external time source? Are reference time sources online
and available on the network? Was the time service running? Are DC role
computers configured to use NT5DS hierarchy to source time?

７ Note

When the time difference is too great on Windows Server 2008 R2 destination DCs,
the replicate now command in DSSITE.MSC fails with the on-screen error There is a
time and / or date difference between the client and the server. This error string
maps to error 1398 decimal / 0x576 hex with symbolic error name
ERROR_TIME_SKEW.

Related Content: Setting Clock Synchronization Tolerance to Prevent Replay Attacks.

5. SMB signing mismatch

The best compatibility matrix for SMB signing is defined by four policy settings and
their registry-based equivalents:
 ﾉ Expand table

Policy setting Registry Path

Microsoft HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
network client:
Digitally sign
communications
(if server agrees)

Microsoft HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
network client:
Digitally sign
communications
(always)

Microsoft HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
network server:
Digitally sign
communications
(if server agrees)

Microsoft HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature
network server:
Digitally sign
communications
(always)

Focus on SMB signing mismatches between the destination and source domain
controllers with the classic cases being the setting enabled or required on one side but
disabled on the other.

７ Note

Internal testing showed SMB signing mismatches causing replication to fail with
error 1722: The RPC Server is unavailable.

6. UDP formatted Kerberos packet fragmentation

Network routers and switches may fragment or completely drop large UDP formatted
network packets used by Kerberos and EDNS0 (DNS). Computers running Windows
2000 and Windows 2003 operating system families are vulnerable to UDP
fragmentation comparing to computers running Windows Server 2008 and 2008 R2.

User Action:

From the console of the destination DC, ping the source DC by its fully qualified
computer name to identify the largest packet supported by the network route.
 Console

c:\> Ping <source DC hostname.>. <fully qualified computer name> -f -l

1472

If the largest non-fragmented packet is less than 1,472 bytes, either (in order of
preference)

Modify your network infrastructure to properly support large UDP frames. It

may require a firmware upgrade or config change on routers, switches, or
firewalls.

OR

Set maxpacketsize (on the destination DC) to the largest packet identified by
the PING -f -l command less 8 bytes to account for the TCP header and reboot
the modified DC.

OR

Set maxpacketsize (on the destination DC) to a value of "1" which triggers
Kerberos to use a TCP. Reboot the modified DC to make the change take effect.

Retry the failing Active Directory operation

1. Invalid Secure channel / Password Mismatch

Validate the secure channel with nltest /sc: query or netdom verify .

For more information about reset the destination DC's password with NETDOM /
RESETPWD , see How to use Netdom.exe to reset machine account passwords of a

Windows Server domain controller .

User Action:

Disable the KDC service on the DC being rebooted.

From the console of the destination DC, run NETDOM RESETPWD to reset the
password for the destination DC:

Console

c:\>netdom resetpwd /server: server_name /userd: domain_name

\administrator /passwordd: administrator_password

Ensure that likely KDCs AND the source DC (if in the same domain) inbound
replicate knowledge of the destination DCs new password.
 Reboot the destination DC to flush Kerberos tickets and retry the replication
operation.

2. Invalid trust

If AD replication is failing between DCs in different domains, verify trust relationships

health along the trust path

When able, use the NETDIAG Trust Relationship test to check for broken trusts.
NETDIAG identifies broken trusts with the following text:

Trust relationship test. . . . . . : Failed Test to ensure DomainSid of domain

<domainname> is correct. [FATAL] Secure channel to domain <domainname> is
broken. [<%variable status code%>]

For example, you have a multi-domain forest containing:

root domain Contoso.COM

child domain B.Contoso.COM
grandchild domain C.B.Contoso.COM
tree domain in same forest Fabrikam.COM

If replication is failing between DCs in grandchild domain C.B.Contoso.COM and tree

domain Fabrikam.COM , verify trust health in the following order:

between C.B.Contoso.COM and B.Contoso.COM

between B.Contoso.COM and Contoso.COM
between Contoso.COM and Fabrikam.COM

If a short cut trust exists between the destination domains, the trust path chain doesn't
have to be validated. Instead validate the short cut trust between the destination and
source domain.

Check for recent password changes to the trust with Repadmin /showobjmeta * \<DN path
for TDO in question> Trusted Domain Object (TDO) verify that the destination DC is

transitively inbound replicating the writable domain directory partition where trust
password changes may take place.

Commands to reset trusts:

From root domain PDC:

Console

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD

/PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay
 From Child domain PDC:

Console

netdom trust <Child Domain> /Domain:<Root Domain>

/UserD:Root/PasswordD:*/UserO:Child /PasswordO:* /Reset /TwoWay

3. Invalid Kerberos realm - PolAcDmN / PolPrDmN (no repro when article written)

Copied from Domain controller is not functioning correctly .

a. Start Registry Editor.
b. In the left pane, expand Security.
c. On the Security menu, select Permissions to grant the Administrators local group
Full Control of the SECURITY hive and its child containers and objects.
d. Locate the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN key.
e. In the right pane of Registry Editor, select the <No Name>: REG_NONE entry one
time.
f. On the View menu, select Display Binary Data. In the Format section of the dialog
box, select Byte.
g. The domain name appears as a string in the right side of the Binary Data dialog box.
The domain name is the same as the Kerberos realm.
h. Locate the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN registry key.
i. In the right pane of Registry Editor, double-click the <No Name>: REG_NONE entry.
j. In the Binary Editor dialog box, paste the value from PolPrDmN. (The value from
PolPrDmN will be the NetBIOS domain name).
k. Restart the domain controller.

4. Invalid Kerberos realm - KdcNames

User Action:

On the console of the destination DC, run REGEDIT.

Locate the following path in the registry:
HKLM\system\ccs\control\lsa\kerberos\domains .

For each <fully qualified domain> under

HKLM\system\ccs\control\lsa\kerberos\domains , verify that the value for KdcNames

refers to a valid external Kerberos realm and NOT the local domain or another
domain in the same Active Directory forest.

5. Network Adapters with IPv4 Large Send Offload enabled:

User Action:

Open Network Adapter card properties.

Select Configure button.
 Select Advanced tab.
Disable IPv4 Large Send Offload.
Reboot.

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by
following the steps mentioned in Gather information by using TSS for Active Directory
replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 1396: Logon
Failure: The target account name is incorrect
Article • 02/19/2024

This article describes the symptoms, cause, and resolution for resolving Active Directory replication failing with
Win32 error 1396.

Applies to: Windows Server 2012 R2

Original KB number: 2183411

Symptoms
This article describes the symptoms, cause, and resolution for resolving Active Directory replication failing with
Win32 error 1396:

Logon failure: The target account name is incorrect.

1. DCDIAG reports that the Active Directory Replications has failed with error 1396:

Logon failure: The target account name is incorrect.

Testing server: <Site name><DC Name>

Starting test: Replications
[Replications Check,<DC Name>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: CN=<DN path of naming context>
The replication generated an error (1396):
Logon Failure: The target account name is incorrect.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
XX failures have occurred since the last success

2. REPADMIN.EXE reports that replication attempt has failed with status 1396.

REPADMIN commands that commonly cite the 1396 status include but are not limited to:

REPADMIN /ADD
REPADMIN /REPLSUM*

REPADMIN /REHOST

REPADMIN /SHOWVECTOR /LATENCY

REPADMIN /SHOWREPS

REPADMIN /SHOWREPL
REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS depicting inbound replication from CONTOSO-DC2 to
CONTOSO-DC1 failing with the Logon Failure: The target account name is incorrect error is shown
below:
 Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: <GUID>
DSA invocationID: <invocationID>

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
DSA object GUID: <GUID>
Last attempt @ <date> <time> failed, result 1396 (0x574):
Logon Failure: The target account name is incorrect.
<#> consecutive failure(s).
Last success @ <date> <time>.

3. The replicate now command in Active Directory Sites and Services returns Logon Failure: The target
account name is incorrect.

Right-clicking on the connection object from a source DC and choosing replicate now fails with Logon
Failure: The target account name is incorrect. The on-screen error message is shown below:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to synchronize naming context
<partition DNS path> from domain controller <source DC> to domain controller <destination DC>:

Logon Failure: The target account name is incorrect.

This operation will not continue.

Buttons in Dialog: OK

4. NTDS KCC, NTDS General or Microsoft-Windows-ActiveDirectory_DomainService events with the 1396

status are logged in the directory service event log.

Active Directory events that commonly cite the 1396 status include but are not limited to:

ﾉ Expand table

Event Source Event Event String

ID

Microsoft-Windows- 1125 The Active Directory Domain Services Installation Wizard (Dcpromo)
ActiveDirectory_DomainService was unable to establish connection with the following domain
controller.

NTDS Replication (This event lists 1645 Active Directory did not perform an authenticated remote procedure
the 3-part SPN) call (RPC) to another domain controller because the desired service
principal name (SPN) for the destination domain controller is not
registered on the Key Distribution Center (KDC) domain controller that
resolves the SPN.

Microsoft-Windows- 1655 Active Directory Domain Services attempted to communicate with the
ActiveDirectory_DomainService following global catalog and the attempts were unsuccessful.

Microsoft-Windows- 2847 The Knowledge Consistency Checker located a replication connection

ActiveDirectory_DomainService for the local read-only directory service and attempted to update it
 Event Source Event Event String
ID

remotely on the following directory service instance. The operation

failed. It will be retried.

NTDS KCC 1925 The attempt to establish a replication link for the following writable
directory partition failed.

NTDS KCC 1926 The attempt to establish a replication link to a read-only directory
partition with the following parameters failed.

NETLOGON 5781 Server cannot register its name in DNS

5. Dcpromo fails with an onscreen error:

Active Directory Installation Failed

The operation failed because:

The Directory Service failed to create the server object for CN=NTDS
Settings,CN=ServerBeingPromoted,CN=Servers,CN=Site,CN=Sites,CN=Configuration,DC=contoso,DC
=com on server ReplicationSourceDC.contoso.com. Please ensure the network credentials provided
have sufficient access to add a replica.
"Logon Failure: The target account name is incorrect."

OK

In this case, Event ID 1645, 1168, and 1125 are logged on the server that is being promoted.

6. Map a drive using net use

Console

C:\>net use z: \\<server_name>\c$

System error 1396 has occurred.

Logon Failure: The target account name is incorrect.

In this case, the server was also logging Event ID 333 in the system event log and using SQL Server was
using a high amount of virtual memory.

7. The DC time is incorrect.

8. The KDC will not start on an RODC after a restore of the krbtgt account for the RODC, which had been
deleted. After the restore using third-party restore tools, error 1396 appears.

Event ID 1645 is logged on the RODC.

Dcdiag also reports an error that it cannot update the RODC krbtgt account.

Cause
Multiple root causes exist. Known root causes include:

1. The SPN does not exist on the global catalog searched by the KDC on behalf of the client attempting to
authenticate using Kerberos.
 In the context of Active Directory replication, the Kerberos client is the destination DC, the KDC
performing the SPN lookup is likely the destination DC itself but could be a remote DC.

2. The user or service account that should contain the service principal name being looked up does not exist
on the global catalog searched by the KDC on behalf of destination DC attempting to replicate.

In the context of Active Directory replication, the source DC computer account does not exist on the
global catalog searched by the DC on behalf of the destination DC performing inbound replication.

3. The destination DC lacks an LSA secret for the source DCs domain.

4. The SPN being looked up exists on a different computer account than the source DC.

5. For issues where replication is failing to an RODC, the RODC-specific KRBTGT account may have been
deleted.

Resolution
1. Check the Directory Service event log on the destination DC for NTDS Replication event 1645 and note
the following:

The name of the destination DC

The SPN being looked up (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<object guid for source DCs
NTDS Settings object>/<target domain>.<tld>@<target domain>.<tld>
The KDC being used by the destination DC

2. From the console of the KDC identified in step 1, type nltest /dsgetdc:<forest root DNS domain name >
/gc .

Run the NLTEST locator test immediately following a replication attempt that fails with the 1396 error on
the destination DC.

This should identify that GC that the KDC is performing SPN lookups against.

The GC being searched by the KDC may also be captued in Microsoft-Windows-

ActiveDirectory_DomainService event 1655.

3. Search for the SPN discovered in step 1 on the the global catalog discovered in step 2.

Console

C:\>repadmin /showattrServer_NameDC=corp,DC=contoso,dc=com <GC used by KDC> <DN path of

forest root domain> /filter:"(serviceprincipalname=<SPN cited in the NTDS Replication event
1645>)" /gc /subtree /atts:cn,serviceprincipalname

Or

Console

C:\>dsquery * forestroot -scope subtree -filter "(serviceprincipalname=E3514235-4B06-11D1-

AB04-00C04FC2DCD2/65cead9f-4949-46a3-a49a-f1fbfe13d2b3*)" -attr * -
sServer_Name.europe.corp.microsoft.com

Verify that the host object for the SPN exists.

 Verify the DN path for the host object including whether the object is CNF/conflict mangled or resides in
the lost and found container.

Verify that the source DCs AD Replication SPN is registered only on the source DCs computer account.

If the replication SPN is missing, determine if the source DC has registered its SPN with itself, and whether
the SPN is missing on the GC used by the KDC due to simple replication latency or a replication failure

4. Check the secure channel health and trust health.

This table lists other symptoms, causes, and resolutions:

ﾉ Expand table

Symptom Cause Resolution

The DC is not functioning and logs Event These problems In this case, you might need to apply the hotfix in KB939820.
ID 1925 and 1411 on Windows Server occur because
2008 domain controllers and Windows the version
Server 2003 domain controllers in the number of the
same domain that have been KRBTGT account
authoritatively restored. increases when
you perform an
authoritative
restoration. The
KRBTGT account
is a service
account that is
used by the
Kerberos Key
Distribution
Center (KDC)
service.

Map a drive using net use If the error To prevent the system logging the event 333 continually in future,
C:\Documents and Settings\wschong>net appears while please apply the hotfix 970054 on the server and set the following
use z: \<server_name>\c$ System error mapping a drive registry value to 1:
1396 has occurred. using net use, Location:
Logon Failure: The target account name is the cause could HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
incorrect. be that the Non Manager
In this case, the server was logging Event Paged Memory Name: RegistryFlushErrorSubside
ID 333 and using high memory, with SQL or the Paged Type: REG_DWORD
Server using highest. Pool Memory is Value: 1 or 2
temporarily
insufficient. The
system keeps
recording such
events until the
computer is
restarted, or the
related hive is
unloaded, even
though the
temporary
memory
insufficiency
stops. For more
information
about SQL
Server
 Symptom Cause Resolution

performance
problems, see
Troubleshooting
Performance
Problems in
SQL Server
2005.

The DC time is incorrect. The DC is a unchecked the option to sync time for virtual DC from VMWare host,
virtual machine so that it can sync time with the PDC.
that was set to
sync time with
the VMware
host, caused
events 1925,
1645.

Dcpromo fails with an onscreen error: During For dcpromo error where helper DC SPN is not valid, use SetSPN to
Active Directory Installation Failed. The dcpromo, the create new SPN on helper DC, in format
operation failed because: SPN on the GC/serverName.contoso.com
The Directory Service failed to create the helper DC (the
server object for CN=NTDS replication
Settings,CN=ServerBeingPromoted, source DC) is
CN=Servers,CN=Site, not valid.
CN=Sites,CN=Configuration,DC=contoso,
DC=com on server
ReplicationSourceDC.contoso.com.
Ensure the network credentials provided
have sufficient access to add a replica.
Logon Failure: The target account name is
incorrect.

In this case, Event ID 1645, 1168, and

1125 are logged on the server that is
being promoted.

More information
Other causes include:

1. Event ID 1925 can occur on Windows Server 2008 domain controllers and Windows Server 2003 domain
controllers in the same domain that have been authoritatively restored. In this case, you might need to
apply the hotfix 939820.

2. During dcpromo, the SPN on the helper DC (the replication source DC) is not valid.

3. If the error appears while mapping a drive using net use, the cause could be that the Non Paged Memory
or the Paged Pool Memory is temporarily insufficient. The system keeps recording such events until the
computer is restarted, or the related hive is unloaded, even though the temporary memory insufficiency
stops. For more information about SQL Server performance problems, see Troubleshooting Performance
Problems in SQL Server 2005.

4. The DC is a virtual machine that was set to sync time with the VMware host, caused events 1925, 1645.

5. For the RODC specific scenario where the KRBTGT account is deleted: authoritatively restore the
KRBTGT_##### account using NTDSUTIL and then import the LDIFDE file to correct backlinks. At
 minimum, the msDS-KrbTgtLink attribute on the RODC's computer object will need to be updated to
point to the DN of the restored account.

Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following the
steps mentioned in Gather information by using TSS for Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8446: The replication operation failed to
allocate memory
Article • 02/19/2024

This article describes the symptoms, cause, and resolution steps for issues when Active
Directory replication fails with error 8446.

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Applies to: Windows Server 2012 R2

Original KB number: 2693500

Symptoms
This article describes the symptoms, cause, and resolution steps for issues when Active
Directory replication fails with error 8446: "The replication operation failed to allocate
memory".

1. REPADMIN.exe reports that replication attempt has failed with error "8446" - The
Replication operation failed to allocate memory

DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <Date Time> failed, result 8446 (0x20fe):
The replication operation failed to allocate memory.
1359 consecutive failure(s).
Last success @ <Date & Time>.

CN=Configuration,DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <Date Time> failed, result 8446 (0x20fe):
The replication operation failed to allocate memory.
 1358 consecutive failure(s).
Last success @ <Date & Time>.

Source: Default-First-Site-Name\DomainController
******* 1359 CONSECUTIVE FAILURES since <Date Time>

Last error: 8446 (0x20fe):

The replication operation failed to allocate memory.

2. DCPROMO fails with error 1130

06/05 09:55:33 [INFO] Error - Active Directory could not replicate the directory
partition CN=Configuration,DC=contoso,DC=com from the remote domain
controller 5thWardDC1.contoso.com. (1130)
06/05 09:55:33 [INFO] NtdsInstall for domain.net returned 1130
06/05 09:55:33 [INFO] DsRolepInstallDs returned 1130
06/05 09:55:33 [ERROR] Failed to install to Directory Service (1130)
Non critical replication returned 1130
err.exe 1130
ERROR_NOT_ENOUGH_SERVER_MEMORY / Not enough server storage is
available to process this command.

3. NTDS Replication, NTDS General Events with the 8466 status are logged in the
directory service event log.

ﾉ Expand table

Event Event Event String

Source ID

NTDS 1699 The local domain controller failed to retrieve the changes requested
Replication for the following directory partition. As a result, it was unable to
send the change requests to the domain controller at the following
network address. 8446 The replication operation failed to allocate
memory

NTDS 1079 Active Directory could not allocate enough memory to process
General replication tasks. Replication might be affected until more memory
is available Increase the amount of physical memory or virtual
memory and restart this domain controller

4. When you try to manually initiate replication using Repadmin or Active Directory
Sites and Services, you get the following error message:
 The following error occurred during the attempt to synchronize naming
context Contoso.com from domain controller <Source DC > to domain
controller <Destination DC>:
The replication Operation failed to allocate memory. This operation will not
continue.

5. The domain controller may become unresponsive and a reboot will provide a
temporary workaround.

Cause
The 8446 (operation failed to allocate memory. This operation will not continue) status
can occur when the Active Directory replication engine cannot allocate memory to
perform Active directory replication.

These events can occur due to the following conditions

Low available physical memory
Low available paging file size versus physical memory (Wrong configuration of
paging file): Paging file should be 1.5 times the size of physical memory
Paged Pool or Non-Paged pool exhaustion in the kernel
LSASS Virtual memory depletion on 32-bit domain controllers. This is where the
Virtual Memory of LSASS reaches the 2-GB limit of virtual memory available for a
process running in user mode.
The Virtual Memory depletion could be a leak inside the LSASS User mode Process,
or the Database Cache (ESE Cache) may be consuming all the available memory.

The following information is important to understand

Lsass.exe memory usage on domain controllers has two major components: one fixed
and one variable.

The fixed component is made up of the code, the stacks, the heaps, and various fixed
size data structures (for example, the schema cache). The amount of memory that LSASS
uses may vary, depending on the load on the computer. As the number of running
threads increases, so does the number of memory stacks. Lsass.exe usually uses 100 MB
to 300 MB of memory. Lsass.exe uses the same amount of memory no matter how much
RAM is installed in the computer.

The variable component is the database buffer cache. The size of the cache can range
from less than 1 MB to the size of the entire database. Because a larger cache improves
performance, the database engine for AD (ESENT) attempts to keep the cache as large
as possible. While the size of the cache varies with memory pressure in the computer,
the maximum size of the cache is limited by both the amount of physical RAM installed
in the computer and by the amount of available virtual address space (VA). AD uses only
a portion of total VA space for the cache.

Resolution
Determine if there is depletion of following resources and fix the underlying cause:

Physical RAM
Paging File
Paged Pool or Non-Paged Pool Depletion

LSASS Virtual memory fragmentation

If the root cause is not memory, then the problem may be caused by a lack of available
continuous address space for memory allocation. Due to memory fragmentation, the
available address segments are too small to satisfy request.

The fragmentation problem is not apparent on 64-bit systems since it has much larger
virtual address space 16 TB. Therefore, a solution is replacing 32-bit domain controllers
with DC's running 64-bit hardware and a 64-bit version of operation system.

Domain Controller Scalability

If there is no apparent memory leak or resource depletion:

Check the size of the NTDS.DIT file on the domain controller; if the size is beyond 2 GB
on a 32- bit domain controller, then a likely solution is to move to a 64-bit operating
system and hardware.

There are many cases where administrators have moved onto to x64 Bit hardware and
not faced a repeat of the 8446 (Replication failed to allocate memory) error.

For 32-bit operating systems, depending on the size of the NTDS.DIT, the /USERVA
boot.ini switch that increases the virtual mode address space on domain controllers may
provide relief, but this might cause kernel mode depletion as this reduces the size of the
kernel mode address space. Prior to implementing the /UserVA switch, it is best to
consult with a Windows memory performance tuning expert for an analysis of kernel
mode and user mode memory usage. Database cache consumes all available virtual
memory for the LSASS process.
Run Performance Monitor with database counters, review the following counters:

LSASS - Working Set

LSASS - Virtual Bytes
Database - "Database Cache Size"

７ Note

By default you will not be able to view the database counters on a Windows 2003
Domain controller. Use the following steps to add the database counters on
Windows Server 2003.

These steps are not needed for Window Server 2008 and later.

1. Import the following registry settings: (copy the following text to notepad and save
as a .reg file, and then import the settings on the DC)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performa
nce]
"Open"="OpenPerformanceData"
"Collect"="CollectPerformanceData"
"Close"="ClosePerformanceData"
"Library"="C:\\Windows\\System32\\esentprf.dll"
"Show Advanced Counters"=dword:00000001

2. Run the following command from a command prompt to back up your existing
performance counters: Lodctr /s: backup.ini

3. Run the following command from a command prompt to register the database
counters: Lodctr c:\windows\system32\esentprf.ini

Open Perfmon or restart performance monitor if already open.

You should by now be able to view a new performance object in Perfmon called
Database.

Add the "Database Cache Size" counter. In the following example, the database
cache size grows at an increasing trend of Virtual Bytes and Working Set of the
LSASS Process eventually consuming all 2 GB of available virtual memory allocated
 to the LSASS process. You will encounter the 8446 replication failure once this
virtual address space is consumed. Refer to the " LSASS ESE Database cache is not
limited by default" section of the article for detailed instructions on how to avoid
this condition.

LSASS ESE Database cache is not limited by default

If you determine it is the database cache that is consuming memory using performance
monitor, you can add the following registry value to limit the database cache.

You can use the "EDB max buffers" registry value for limiting ESE cache allocation
(number of pages is 8912 bytes) to prevent the conditions.

Value Name: EDB max buffers

Type: reg_dword
Setting: <refer to the values below>
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Ｕ Caution

Ensure that you set an optimal value to the registry value (EDB max buffers), if the
cache limit is too low then it might cause performance degradation. You may apply
the following values as start for an optimization, depending is the /3GB boot.ini
switch is use or not:

Without /3GB switch: "EDB max buffers", Reg_DWord: 157286 (1.2 GB); expected
LSASS consumption ~1.5 GB With /3GB switch: "EDB max buffers", Reg_DWord:
235929 (1.8 GB); expected LSASS consumption ~2.1 GB

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 8464:
Synchronization attempt failed
Article • 02/19/2024

This article helps you troubleshoot the Active Directory replication error 8464.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 3001248

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Symptoms
This article describes the symptoms, cause, and resolution for resolving issues in which
Active Directory replication fails and returns error 8464:

Hex error code: 0x00002110

Dec error code: 8464
Symbolic Name: ERROR_DS_DRA_INCOMPATIBLE_PARTIAL_SET
Error Description: Synchronization attempt failed because the destination DC is
currently waiting to synchronize new partial attributes from source. This condition is
normal if a recent schema change modified the partial attribute set. The destination
partial attribute set is not a subset of source partial attribute set.
Header: winerror.h

Additionally, an ActiveDirectory_DomainService or NTDS Replication event 1704 entry

that resembles the following is logged:

Log Name: Directory Service

Event ID :1704
Event Source: ActiveDirectory_DomainService / NTDS Replication
Task Category: Global Catalog
Event Text: The global catalog initiated replication of a member of the partial
 attribute set for the following directory partition from the following domain
controller.

Directory partition:
DC=<name>,DC=<domain>,DC=com

Domain controller:
<fqdn>

This is a special replication cycle due to the addition of one or more attributes to the
partial attribute set.

７ Note

It is typical to see Active Directory replication status 8464 after you extend the
schema or after you add new attributes to the partial attribute set (PAS). This
message states that replication is delayed temporarily. Active Directory replication
status 8464 goes away after the PAS finishes the update process.

Cause
This issue occurs because PAS synchronization is triggered when an attribute is added to
the PAS.

For the details, see the More Information section.

Resolution
Because this is a standard part of PAS synchronization, resolution steps are not needed.
See the More Information section for troubleshooting steps if this replication status
persists in the environment for more than a week.

More information

The details of the cause for status 8464

The Schema definition for an attribute is stored in the Schema partition as an
attributeSchema object. Checking the Replicate this attribute to the Global Catalog
check box sets the isMemberOfPartialAttributeSet attribute to TRUE on the
attributeSchema object. Any attributeSchema object that has this attribute set to TRUE
will cause the corresponding attribute to be included in the Partial Attribute Set.

When PAS synchronization occurs (that results from PAS extension), there is a
specialized task in the replication task queue. The DRS_SYNC_PAS flag identifies this
specialized task.

An unoptimized Active Directory topology or Active Directory replication failures may

result in a significant delay in the PAS update process. It's typical to see Active Directory
replication status 8464 during the PAS update process.

How to check Active Directory replication status 8464

The Repadmin commands provide an Active Directory replication status report state that
a replication attempt is delayed with status 8464.

The following Repadmin commands typically cite the 8464 status. The commands include
but are not limited to:

REPADMIN /SHOWREPL
REPADMIN /REPLSUM

REPADMIN /REPLICATE

The following is a sample output from Repadmin /showrepl that shows incoming
replication from DC2 to DC1 being delayed:

Domain\DC2 DSA Options: IS_GC Site Options: (none) DSA object GUID: <GUID>
DSA invocationID: <ID>
DC=child,DC=root,DC=contoso,DC=com
Domain\DC1 via RPC DSA object GUID: <GUID> Last attempt @ 2014-08-28
04:50:44 was delayed for a normal reason, result 8464 (0x2110)

The following is the verbose output of the Repadmin /showrepl command:

Domain\TRDC1 via RPC

DSA object GUID: <GUID> Address: xxxxxxxxxx._msdcs.root.contoso.com DSA
invocationID: <ID> SYNC_ON_STARTUP DO_SCHEDULED_SYNCS
PARTIAL_ATTRIBUTE_SET USNs: 0/OU, 234943/PU
Last attempt @ <Date & Time> was delayed for a normal reason, result 8464
(0x2110):
Synchronization attempt failed because the destination DC is currently waiting to
synchronize new partial attributes from source. This condition is normal if a recent
 schema change modified the partial attribute set.
The destination partial attribute set is not a subset of source partial attribute set.
Last success @ <Date & Time>.

How to determine the destination domain controller

７ Note

These steps require an understanding of the environment's Active Directory

replication topology, correlation of replication status data and temporary
modification of Active Directory replication interval or connections.

1. Identify one destination domain controller for one partition logged Active
Directory replication status 8464. Use this domain controller and partition for these
steps (don't jump around between partitions and domain controllers).

７ Note

This step makes you to focus on updating the bridgehead servers and hub-
site domain controller first.

2. Collect the following data. Check replication status results for the destination
domain controller and source domain controller. Run the following commands to
export the results:

a. Compare the current PAS synchronization state among all global catalog
servers. Run the following command to export the result to a pas_domain.txt
file:

Console

repadmin /showattr gc: <Partition_DN> /gc /atts:partialattributeset

>pas_domain.txt

b. Check replication status results for the destination and source domain
controllers. Run the following commands to export the results:

Console

Repadmin /showrepl <DestinationDC> /verbose >repl_destDC.txt

Repadmin /showrepl <SourceDC> /verbose >repl_sourceDC.txt
 Repadmin /showrepl * /csv >showrepl.csv

c. List of all attributes in the PAS. This is useful for determining the current count.
Run the following command to export the result to a pas.txt file:

Console

repadmin /showattr fsmo_schema: ncobj:schema: /filter:"

(ismemberofpartialattributeset=TRUE)" /subtree /atts:dn >pas.txt

d. Check event ID 1704 and 1702 as they indicate the PAS synchronization is
complete in the Directory Service event log. Here's an example of event ID 1702:

Log Name: Directory Service

Event ID: 1702
Event Source: ActiveDirectory_DomainService / NTDS Replication
Task Category: Global Catalog
Event Text: The global catalog completed synchronization of the partial
attribute set for the following directory partition from the following domain
controller.

Directory partition:
DC=<name>,DC=<domain>,DC=com

Domain controller:
<fqdn>

This is a special replication cycle due to the addition of one or more

attributes to the partial attribute set.

3. Analyse the data based on the destination domain controller with outdated PAS or
source domain controller with outdated PAS.

If the destination domain controller doesn't have the updated PAS, do the
following:
a. Determine whether any source partners have the updated value.
b. Update destination and any source domain controllers that are out of date
to clear the status 8464.
c. Manually start replication with source domain controllers that are up to
date. Or, create and replicate source domain controllers if connections
don't exist.
d. When the destination domain controller is updated, status 8464 will be
logged for any source domain controllers that aren't updated.
 If the destination domain controller has the updated PAS, but the source
domain controller doesn't, the status 8464 won't clear until the source is
updated. Or, you can update the source domain controller by manually
starting replication with a domain controller that is up to date.

Pas_domain.txt instructions
The value of interest in the output is listed after the v1.cAttrs = text. This numeric value
displays how many attributes are included in the PAS. Compare these values among
each global catalog (GC) for each partition. If all GCs display the same value, all GCs are
in-sync (they either all have the updated PAS, or they all don't). If all values are the same,
compare them with the values from output in other partitions or the dump schema, and
count the list of attributes in the PAS.

The following is a sample log, where DC1 hasn't updated the partial attribute set for the
CHILD partition. Also DC2 has completed the PAS update process. No data is logged for
ChildDC1, because the partialattributeset attribute has no data due to ChildDC1
containing a full copy of the Child domain partition.

Repadmin: running command /showattr against full DC DC1.root.contoso.com

DN: DC=child,DC=root,DC=contoso,DC=com
1> partialAttributeSet: { dwVersion = 1; dwFlag = 0; V1.cAttrs = 196, V1.rgPartialAttr
= 0, 3, 4, 6, 7, 8, 9
Repadmin: running command /showattr against full DC
ChildDC1.child.root.contoso.com
DN: DC=child,DC=root,DC=contoso,DC=com
Repadmin: running command /showattr against full DC DC2.root.contoso.com
DN: DC=child,DC=root,DC=contoso,DC=com
1> partialAttributeSet: { dwVersion = 1; dwFlag = 0; V1.cAttrs = 203, V1.rgPartialAttr
= 0, 3, 4, 6, 7, 8, 9

Pas.txt Instructions

Identify the list of attributes in the PAS

To see a list of the attributes in the PAS, use repadmin or another tool to query the
Schema partition for all attributes where the ismemberofpartialattributeset value is set
to TRUE:

Console
 repadmin /showattr fsmo_schema: ncobj:schema: /filter:"
(ismemberofpartialattributeset=TRUE)" /subtree /atts:dn >pas.txt

Make sure that the word TRUE is in all uppercase text.

You can also use LDIFDE to achieve this data together with the count:

Console

Ldifde -f pas.txt -d "cn=schema,cn=configuration,dc=forestRootDN" -r "

(ismemberofpartialattributeset=TRUE)" 196 entries exported

Identify the count of attributes in the PAS

To achieve a count of the attributes from the repadmin output, follow these steps:

1. Open the text file in Notepad.

2. Delete any blank lines at the beginning and end of the file.
3. Delete the line at the top of the file that begins with "Repadmin: running command
/showatt."
4. Put your pointer on the last line of text in the file, then press the Ctrl + G keyboard
shortcut to open up the Go To Line dialog box. The line number in this window
represents the count for attributes in the partial attribute set.

Directory Service event log

Enable diagnostic logging for global catalog events in order to view additional detail
about the partial attribute set update cycle. After enabling replication event verbosity,
view the Directory Services event log.

To enable diagnostic logging for global catalog events, follow these steps:

1. Open Regedit.
2. Locate and then select the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

3. Configure event logging for global catalog:

a. On the right side of Registry Editor, double-click the 18 Global Catalog entry.
b. Type 3 in the Value data box, and then select OK.
4. Close Regedit.
Replication status cycle in partial attribute
synchronization
The Active Directory replication status 8464 message is logged when the destination
domain controller is waiting to synchronize the updated PAS from the source domain
controller.

７ Note

The domain controller that is selected for the PAS_Sync task can move to a different
source domain controller on the next replication interval (from the existing set of
replica partners).

New attempts to synchronize the PAS are based on the replication schedule. When a
different source is selected for the PAS_Sync task, replication will proceed usually with
the prior source domain controller. After the PAS is successfully updated, replication for
the same partition to the domain controller that is updated will fail from domain
controllers without the updated PAS. The same replication status is logged for this
scenario.

When the destination domain controller hasn't updated the PAS, one of the following
processes occurs:

Selects one replica source to update PAS. Then, event 1704 is logged when the
sync begins.
If source does not have the updated PAS itself, Active Directory replication status
8464 is logged, and event ID 1705 is logged if diagnostic logging is enabled.
If the PAS update task failed, and then a new source is selected, event ID 1706 is
logged if diagnostic logging is enabled.
Replication from other domain controllers for the same partition proceeds as usual
(status 0 is logged if there are no failures).

Example of the PAS synchronization cycle

This section is a sample of the PAS synchronization cycle. The following table is the
domain controllers in the forest:

ﾉ Expand table

Domain Controllers Domain

DC1 Root.contoso.com
 Domain Controllers Domain
DC2 Root.contoso.com

ChildDC1 Child.root.contoso.com

ChildDC2 Child.root.contoso.com

TRDC1 Treeroot.fabrikam.com

The following is the structure of the forest:

Consider the following scenario:

Seven new attributes are added to the PAS by using Schema extension. Therefore,
the count for attributes in the PAS increases from 196 to 203.
This starts PAS synchronization. All GCs must now source the data for these seven
attributes in each GC partition.
This diagram shows the update of just one partition.
The replication interval in this environment is 15 minutes.
A pre-existing condition exists that blocks replication from a DC hosting a writable
copy of the partition.
In this scenario, the following processes occur:

1. When destination domain controller hasn't updated the PAS:

a. DC1 selects DC2 for PAS_SYNC. Because DC2 also has the old PAS, Active
Directory replication status 8464 is logged.

b. TRDC1 wasn't selected for PAS_SYNC and it also has the old PAS, Active
Directory replication status 0 (Successful) is logged.

c. ChildDC1 holds a writable copy of the CHILD partition so that it has all
attributes for this partition. However, there's a pre-existing issue that causes
Active Directory replication to fail with error 8606.

2. The destination domain controller selects a new source (TRDC1) for the PAS_SYNC
task.

a. TRDC1 also has the old PAS so replication is delayed, and status 8464 is logged.

b. DC2 also has the old PAS. However, it isn't selected for PAS_Sync on this interval,
and replication is completed correctly. Therefore, status 0 is logged.

c. Active Directory replication still fails with ChildDC1 because of an unrelated

lingering objects issue exists (abandoned objects).
3. PAS_SYNC toggles back to the other outdated replica (DC2).

a. Meanwhile we correct the replication issue on ChildDC1.

b. Replication is delayed from DC2, and status 8464 is logged.

c. Replication proceeds successfully from TRDC1.

d. Replication proceeds successfully from ChildDC1 (but it isn't selected for

PAS_Sync on this cycle).

4. A suitable domain controller is finally selected for PAS_SYNC (ChildDC1).

a. Replication proceeds as usual from DC2 and TRDC1 (these attempts are
completed before PAS_Sync).

b. Replication proceeds as usual from ChildDC1and PAS_SYNC is complete.

5. The destination domain controller finally has the updated PAS (from the last
interval).

a. Replication from DC2 and TRDC1 is now both delayed because the source
domain controllers are outdated. The same Active Directory replication status is
logged for this issue.

b. Replication is complete successfully from ChildDC1.

6. In between the previous replication interval and the next one, DC2's copy of the
partial attribute set for the CHILD domain is also updated (not pictured though).

a. Because both the destination domain controller (DC1) and source domain
controllers (DC2 and ChildDC1*) have the updated PAS, replication is completed
correctly.

*ChildDC1 has a full set of attributes for the partition (not just the PAS).

b. Replication is delayed from TRDC1 because it still has the old PAS.
 7. In between the previous replication interval and the next one, TRDC1's copy of the
partial attribute set for the CHILD domain is also updated (not pictured though).

a. Replication is completed correctly from all partners, because the destination

domain controller and sources all have the same attributes for the PAS.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 8545:
"Replication update could not be
applied"
Article • 02/19/2024

This article provides a solution to an issue where Active Directory replication fails for one
or more partitions with the error 8545.

Applies to: Windows Server 2012 R2

Original KB number: 3110029

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Symptoms
In Windows Server 2012 and Windows Server 2008, Active Directory replication fails for
one or more partitions and returns error 8545: "The replication update could not be
applied because either the source or the destination has not yet received information
regarding a recent cross-domain move operation."

Additionally, the following error is logged in the Directory Service log on the destination
domain controller:

Microsoft-Windows-ActiveDirectory_DomainService Event ID 1084Internal event:

Active Directory Domain Services could not update the following object with
changes received from the following source directory service. This is because an
error occurred during the application of the changes to Active Directory Domain
Services on the directory service.

Object:

CN=<User>,OU=Users,OU=Boulder,DC=na,DC=contoso,DC=com
Object GUID:
33555323-8e42-42dd-ab95-51693b54281f
 Source directory service:
1126750c-e8ac-4355-8412-ccb287e48c23._msdcs.contoso.com

Synchronization of the directory service with the source directory service is blocked
until this update problem is corrected.
This operation will be tried again at the next scheduled replication.

User Action
Restart the local computer if this condition appears to be related to low system
resources (for example, low physical or virtual memory).

Additional Data
Error value:
8545 The replication update could not be applied because either the source or the
destination has not yet received information regarding a recent cross-domain move
operation.

７ Note

For more information about how to apply the values that are referenced in event ID
1084, see the tables in the "More Information" section.

Cause
This issue occurs if the object that's listed in event 1084 was migrated from one domain
to another domain in the same forest. The destination domain controller doesn't learn
of the object's new location (its partition). Therefore, the object is still present in the old
partition on the destination domain controller.

The source domain controller knows of the object's migration and locates it in the
object's new location.

Active Directory replication error 8545 is logged when the source domain controller tries
to send changes for this recently migrated object when the destination domain
controller finds the object present in a different partition.

Resolution
As a preventive measure, consider installing Microsoft Knowledge Base article
2682997 on all domain controllers that are still running Windows Server 2008 or
Windows Server 2008 R2. To do this, follow these steps:

1. Determine the distinguished name (DN) of the naming context (NC) / partition
where the object was migrated from. For more information about this, see the
"More Information" section.

2. On the destination domain controller, follow these steps to unhost this partition:

a. Run the following command line: Repadmin /unhost DestinationDC

<DNofObject'sOldLocation>

For example, if the destination domain controller is DC1, and the DN for the
partition where the object was migrated from is dc=corp,dc=contoso,dc=com,
the command would be Repadmin /unhost DC1 dc=corp,dc=contoso,dc=com.

７ Note

Monitor the Directory Service log on the domain controller for event ID
1660. Review the event text to make sure that it says the domain controller
no longer hosts the CORP NC.

b. Event ID 1659 indicates the status of the unhost operation. Do not readd the
partition until after you successfully sync the other partition.

3. On the destination domain controller, trigger replication with the source domain
controller (the one that was failing).

4. Rehost the partition from a domain controller that has a valid read/write copy of
the partition. To do this, run the following command line:

Repadmin /add DNobObject'sOldLocation DestinationDC GoodSourceDC

/readonly

For example, assume that the destination domain controller is DC1, the partition
that you unhosted is dc=corp,dc=contoso,dc=com, and a domain controller that
has a read/write copy of the Corp partition is CorpDC1.corp.contoso.com . In this
situation, the command will be Repadmin /add dc=corp,dc=contoso,dc=com dc1
CorpDC1.corp.contoso.com /readonly . For more information about this specific

scenario, see the "More Information" section.

More information
The scenario that's described in the preceding sections can be confusing. Use the
following table style to document all the points of data that you need to resolve this
issue.

First, determine whether it's the source or destination domain controller that has a copy
of the object in the old location (the location from where the object was migrated).

ﾉ Expand table

Name Details

Object DN CN=JUSTINTU,OU=Users,OU=BOULDER,DC=na,DC=contoso,DC=com

ObjectGUID 33555323-8e42-42dd-ab95-51693b54281f

Parent Object DN OU=Users,OU=BOULDER,DC=na,DC=contoso,DC=com

Old Source Which domain was the object in?

Domain (DN)
Dc=corp,dc=contoso,dc=com

Target domain Which domain was the object migrated to?

(DN)
Dc=na,dc=contoso,dc=com

Identify all DCs Repadmin /showobjmeta *"<GUID=33555323-8e42-42dd-ab95-

with object(s) 51693b54281f>" >JUSTINTUObjmeta.txt
(replication
metadata) Important:

For any DCs that you fail to obtain data from:

1. Connect to each DC that you didn't obtain data from.
2. Rerun the command, and substitute the DC name for the asterisk.

Example: repadmin /showobjmeta DC004 "<GUID=33555323-8e42-42dd-

ab95-51693b54281f>" >LCTXDC004_JUSTINTUObjmeta.txt

Identify all DCs Repadmin /showattr *"<GUID=33555323-8e42-42dd-ab95-51693b54281f>"

with object(s) /gc >JUSTINTUattr.txt
(attribute values)
Important:

For any DCs that you fail to obtain data from:

1. Connect to each DC in question.
2. Rerun the command, and substitute the DC name for the asterisk.

Example: repadmin /showobjattr LCTXDC004 "<GUID=33555323-8e42-42dd-

ab95-51693b54281f>" /gc >LCTXDC004_JUSTINTUAttr.txt
 Name Details

Identify all DCs in Repadmin /viewlist * >allDCs.txt

forest

Identify the Repadmin /showattr DCNAME NCOBJ: Config: /filter:"

DSA_GUID for all (Objectclass=NTDSDSA)" /atts:objectGUID /subtree >ntdsa.txt
DCs
The preceding two commands.

DC in source
domain without
object in NA
partition- name

DC in source
domain without
object in NA
partition
DSA_GUID

Replication status Repadmin /showrepl * /csv >showrepl.csv

for forest

To identify the current location of the object in the database:

1. Dump the database of one of the destination DCs.

2. Open the database dump file, and then search for the objectGUID that's reported
in event 1084.
3. Grab the DNT and PDNT, and build the object hierarchy by copying the
pertinent values into a table, as follows:

ﾉ Expand table

DNT PDNT RDN ObjectGUID

61001 45020 Justintu 33555323-8e42-42dd-ab95-51693b54281f

45020 20005 LostAndFound

6931 1752 Corp

1751 20003 Contoso

1750 2 com

By using the database dump file, you can see this object's current location in the
database on this domain controller:
CN=LostAndFound,DC=Corp,DC=Contoso,DC=com

You can see that the object was present in the LostAndFound container on the
corp.contoso.com NC. However, replication is blocked on this object except for the
NA.contoso.com NC. Because this object is already present in the database (but in the

old, incorrect NC), you must remove this partition from this domain controller in order
to dispose of the old object.

Example scenario action plan

The Configuration object was migrated from the Corp partition to the NA partition.
However, the NA partition fails to replicate from NADC1.na.contoso.com to
DC1.la.contoso.com , and the attempt returns error 8545.

Destination DC: DC1.la.contoso.com

Source DC: NADC1.na.contoso.com

1. As a preventive measure, consider installing KB article 2682997 on all domain

controllers that are still running Windows Server 2008 or Windows Server 2008 R2.
To do this, you will have to unhost the Corp partition on the domain controller,
replicate the NA partition, and then readd the CORP partition from a known good
source. To do this, follow these steps:

a. Unhost the partition from the GC by running the following commands:

Repadmin /options the DC +disable_ntdsconn_xlate

Repadmin /unhost the DC dc=corp,dc=contoso,dc=com

b. Monitor the Directory Service log on the domain controller for event ID 1660.
Review the event text to verify that the domain controller no longer hosts the
CORP NC.
2. Event ID 1659 indicates the status of the unhost operation. Do not readd the
partition until after you sync the NA partition, as follows:

a. Replicate the NA partition. After the partition is successfully removed from the
database: Initiate replication from CORPDC.na.contoso.com by running the
following command:

Console

Repadmin /replicate the DC1.la.contoso.com NADC1.na.contoso.com

DC=na,DC=bayer,DC=cnb
 b. Readd the CORP NC back to this domain controller by running the following
repadmin /add commands:

Console

Repadmin /add dc=corp,dc=contoso,dc=com DC1.la.contoso.com

CorpDC1.corp.contoso.com /readonly

Repadmin /options the DC -disable_ntdsconn_xlate

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot common Active Directory
replication errors
Article • 04/10/2024

This article contains information and links to help you troubleshoot Active Directory
Replication errors. It is intended to provide Active Directory administrators with a
method to diagnose replication failures and to determine where those failures are
occurring.

Applies to: Windows Server (All supported versions)

Original KB number: 3108513

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Error codes
To troubleshoot specific errors, refer to the following table.

ﾉ Expand table

Replication Cause Related Knowledge Base

error code article

8464 This issue occurs because partial attribute set Active Directory replication
(PAS) synchronization is triggered when an error 8464: Synchronization
attribute is added to the PAS. attempt failed

8477 This code is informational and represents a Troubleshooting AD

regular Active Directory replication operation. It Replication error 8477: The
indicates that replication is currently in progress replication request has been
from the source and has not yet been applied to posted; waiting for reply
the destination domain controller's database
replica.

8418 Attempts to replicate Active Directory when Troubleshooting AD

schema information is not consistent between the Replication error 8418: The
domain controller partners that are involved replication operation failed
result in a Schema Mismatch error status. This because of a schema
Replication Cause Related Knowledge Base
error code article

symptom manifests itself in several ways. The mismatch between the

underlying cause of the error may vary. servers involved

1908 This error has two primary causes: Troubleshooting AD

The destination domain controller can't Replication error 1908:
contact a key distribution center (KDC). Could not find the domain
The computer is experiencing Kerberos- controller for this domain
related errors.

8333 This error has multiple causes. They include the Troubleshooting AD
following: Replication error 8333:
Database corruption, with additional Directory Object Not Found
associated errors that are logged in the
event log of the source domain controller
Lingering objects that have associated
errors logged
Conflict objects
A third-party process

8589 This error most commonly occurs on a domain Troubleshooting AD

controller after a replication partner has Active Replication error 8589: The
Directory forcibly removed and then is re- DS cannot derive a service
promoted before end-to-end replication can principal name (SPN)
complete. This error can also occur when you
rename a domain controller and the
serverReference attribute is not updated.

1818 The issue occurs when the destination domain Troubleshooting AD

controller that is performing incoming replication Replication error 1818: The
does not receive replication changes within the remote procedure call was
number of seconds that is specified in the RPC cancelled
Replication Timeout registry key.

8446 This error can occur when the Active Directory Troubleshooting AD
replication engine cannot allocate memory to run Replication error 8446: The
Active Directory replication. replication operation failed
to allocate memory

8240 This error indicates that the specific object could Troubleshooting AD
not be found in the directory. This error may be Replication error 8240:
encountered in the following situations: There is no such object on
During AD replication the server
Reported 8240 in 1126 Event (NTDS)

8451 Status 8451: The replication operation Active Directory Replication

encountered a database error has multiple Error 8451: The replication
Replication Cause Related Knowledge Base
error code article

causes. Refer to the related Knowledge Base operation encountered a

article in the third column. database error

1256 This error is logged because of a connectivity Active Directory Replication

failure. Error 1256: The remote
system is not available.

1396 Known causes of this error include the following: Active Directory Replication
The service principal name (SPN) does not Error 1396: Logon Failure:
exist on the global catalog that is searched The target account name is
by the Kerberos Key Distribution Center incorrect.
(KDC) on behalf of the client that is trying
to authenticate by using the Kerberos
protocol.
The user or service account that should
contain the SPN that is being looked up
does not exist on the global catalog that is
searched by the KDC on behalf of the
destination domain controller that is trying
to replicate.
The destination domain controller lacks a
Local Security Authority (LSA) secret for the
source domain controller's domain.
The SPN that is being looked up exists on
the account of a different computer than
the source domain controller.

1722 Remote Procedure Call (RPC) is an intermediate Active Directory replication

layer between the network transport and the error 1722: The RPC server is
application protocol. RPC itself has no special unavailable
insight into failures. However, it tries to map
lower-layer protocol failures into an error at the
RPC layer.

-2146893022 This error code is not returned by Active Active Directory replication
Directory. However, it may be returned by lower- error -2146893022: The
layer components. These include RPC, the target principal name is
Kerberos protocol, Secure Sockets Layer (SSL), incorrect
LSA, and NT LAN Manager (NTLM). The code is
returned for various reasons.

1753 Specific causes of this error include the following: Active Directory Replication
The server app never started. Error 1753: There are no
The server app started. However, there was more endpoints available
a failure during initialization that prevented from the endpoint mapper
the server app from registering with the
RPC Endpoint Mapper.
Replication Cause Related Knowledge Base
error code article

The server app started but later died.

The server app manually unregistered its
endpoints. (This resembled the previous
cause, but its occurrence was intentional.
You are unlikely to receive this error for this
reason. However, we include it for
completeness.)
The RPC client (that is, the destination
domain controller) contacted a different
RPC server than the intended one because
of a name-to-IP mapping error in DNS,
WINS, or the host / lmhosts file.

8606 Error 8606 is logged when the following Active Directory Replication
conditions are true: Error 8606: Insufficient
A source domain controller sends an attributes were given to
update to an object (instead of sending an create an object
originating object create request) that was
already created, deleted, and then
reclaimed by garbage collection from a
destination domain controller's copy of
Active Directory.
The destination domain controller was
configured to run in strict replication
consistency.

1127 Error 8606 is logged when the following Active Directory Replication
conditions are true: Error 1127: While accessing
A source domain controller sends an the hard disk, a disk
update to an object (instead of sending an operation failed even after
originating object create request) that was retries
already created, deleted, and then
reclaimed by garbage collection from a
destination domain controller's copy of
Active Directory.
The destination domain controller was
configured to run in strict replication
consistency. duplication of above?

8452 This error most frequently occurs when the The naming context is in the
replication topology in a domain controller that is process of being removed
starting replication differs from the replication or is not replicated from the
topology that is defined in the destination specified server
domain controller's copy of Active Directory.
 Replication Cause Related Knowledge Base
error code article

8456 or 8457 Incoming or outgoing replication was 2023007

automatically disabled by the operating system
because of multiple root causes.

8453 This Replication Access was denied error has Active Directory replication
multiple causes. error 8453: Replication
access was denied

8524 This is a catch-all error for all possible DNS Active Directory Replication
failures that affect Active Directory on post- Error 8524: The DSA
Windows Server 2003 SP1-based domain operation is unable to
controllers. proceed because of a DNS
lookup failure

8614 Causes of this error (and for NTDS Replication Troubleshoot Active
Event 2042) include the following: Directory replication error
The destination domain controller that is 8614
logging the 8614 error did not inbound-
replicate a directory partition from one or
more source domain controllers for
Tombstone lifetime number of days.
System time on the destination domain
controller moved, or jumped, Tombstone
lifetime one or more days into the future
after the last successful replication.

8545 This Active Directory replication error is logged Active Directory replication
when the source domain controller tries to send error 8545: Replication
changes for a recently migrated object when the update could not be applied
destination domain controller has the object
present in a different partition.

5 This Active Directory replication error has multiple Active Directory replication
causes. error 5 - Access is denied

Event IDs
To troubleshoot specific event IDs, refer to the following table:

ﾉ Expand table
 Event ID Cause Related article

Event ID Fixing Replication Topology Problems How to troubleshoot Event ID 1311

1311 messages on a Windows domain

Event ID A lingering object is detected 4469619

1388 or 1988

Event ID It has been too long since this machine 4469622

2042 replicated

Event ID Attempt to establish a replication link 4469659

1925 failed due to DNS lookup problem

Event ID DNS lookup failure caused replication 4469661

2087 to fail

Event ID DNS lookup failure occurred with Event ID 2088: DNS lookup failure
2088 replication success occurred with replication success

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

References
Troubleshooting Active Directory Replication Problems

Troubleshooting Active Directory Replication Problems

Diagnose Active Directory replication failures

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot domain controller
replication error 1727-The remote
procedure call failed and did not
execute
Article • 04/10/2024

This article solves the error message "The remote procedure call failed and did not
execute". This error occurs during domain controller (DC) replication on Windows
Server.

Applies to: Windows Server (All supported versions)

Original KB number: 4019721

Symptoms
This Active Directory (AD) replication error appears in one or more of the following
forms:

Decimal: 1727
Hex: 0x6bf
Symbolic: RPC_S_CALL_FAILED_DNE
Error message: The remote procedure call failed and did not execute.

Cause
This problem occurs because of one of the following reasons:

A network connectivity issue between the two domain controllers (DCs). See the
following sections for details.
A load-induced performance issue on the replication partner. This issue is less
common and is often transient in nature. See the following sections for details.

About the network connectivity issue

This problem occurs when the DC's replication partner can't complete the RPC
connection to AD Replication's RPC Service (DRSR UUID E3514235-4B06-11D1-AB04-
00C04FC2DCD2). More specifically, the replication partner can bind to the RPC endpoint
mapper, but can't complete the DRSR RPC bind.
Possible root causes include:

firewalls
routers
WAN optimizers
other intermediate network devices
network filter drivers

About the performance issue

This problem occurs when one of the following conditions is true:

The server is backlogged and doesn't respond to the TCP ACK or the response
message. So, the sender abandons the TCP session.
The network is too slow or unreliable. It can't deliver the TCP ACK or the response
message.

Resolution
To resolve this problem, determine any recent changes that would affect the network
between the two DCs and undo those changes if possible. If there are no recent
changes, you must fully examine the RPC network connectivity between the two DCs. To
do so, follow either the high-level troubleshooting steps or the detailed troubleshooting
steps.

High-level troubleshooting steps

1. Take a double-sided network capture while you reproduce the problem. To do so,
follow these steps:
a. Start a network capture on both DCs.
b. Manually start replication between the two DCs.
c. Stop both sides of the trace when you receive the error.

2. Examine the RPC conversation between the two DCs. Determine whether there's
ever a case in which the message that's sent from the requestor DC doesn't incur a
response from the replication partner.

７ Note

Occasionally, there is a partial response that includes the piggy-back TCP ACK for
the request message. But the traffic has been modified or the response doesn't
 actually arrive at the requester DC. Therefore, the TCP stack doesn't receive an ACK.

Detailed troubleshooting steps

Start a network capture on both DCs before you take the following steps to test DC
connectivity.

Test the source DC connectivity from the destination DC

Follow these steps on the destination DC:

1. Verify whether the source DC is listening on TCP port 135. To do so, run the
PortQry.exe -n -e 135 command.

If the port status is FILTERED, the AD replication failure is likely to fail and return
error 1722 instead. Try resolving error 1722, and then check whether the AD
replication succeeds. If the problem persists, restart the detailed troubleshooting
steps.

If the status isn't FILTERED, the commands return the RPC endpoint mapper
database. Search for MS NT Directory DRS Interface to find the upper-range port
in the endpoint mapper database that the source DC is listening on for AD
replication. You may get one or more entries. Make a note of the ports for
ncacn_ip_tcp.

For example, you get something that resembles the following example, which
presents two upper-range ports 49159 and 49160:

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface

ncacn_ip_tcp:2012dc[49159] UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS
NT Directory DRS Interface ncacn_ip_tcp:2012dc[49160]

７ Note

The upper-range ports are DC specific and are dynamically assigned.

However, an administrator can hard-code the port that is used for AD
replication by using the following registry value.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameter
s
Registry value: TCP/IP Port
 Value type: REG_DWORD
Value data: (available port)

2. Test TCP port connectivity to the upper-range ports that you note. To do so, run
the following command:

Console

PortQry.exe -n <SourceDC> -e <Upper_Range_Port_Number>

For example, you run the following commands:

Console

PortQry.exe -n 2012dc -e 49159

PortQry.exe -n 2012dc -e 49160

If port status is FILTERED, review the network trace that you've captured to
determine where the packet is blocked.

3. Test DNS. Verify that the destination DC can resolve the CNAME and HOST records
of the source DC. And verify that the resolved IP address is the actual IP address of
the source DC. If DNS points to an old or invalid IP address, then RPC connection
attempt is made to an incorrect source DC.

Test the destination DC connectivity from the source DC

Repeat step 1 through 3 on the source DC.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot Event ID 1311
messages on a Windows domain
Article • 02/19/2024

This article describes how to troubleshoot event ID 1311 messages in the Directory
Service event log on a Windows domain.

Applies to: Windows Server 2016, Windows Server 2019, Windows Server 2012 R2
Original KB number: 307593

Symptoms
The Knowledge Consistency Checker (KCC) constructs and maintains the replication
topology for Active Directory. To do this, the KCC examines the sum of all naming
contexts that reside in the forest and all administrator-defined constraints for site, site
link, and link cost.

If an Active Directory domain, a schema, a configuration, an application partition, or the

global catalog naming contexts can't be replicated between domain controllers or sites,
an event ID 1311 message similar to the following is logged in the Directory Service
event log:

Event Type: Error

Event Source: NTDS KCC
Event Category: Knowledge Consistency Checker
Event ID: 1311
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User: N/A
Computer: <domain_controller_name>
Description:
The Directory Service consistency checker has determined that either (a) there is not
enough physical connectivity published via the Active Directory Sites and Services
Manager to create a spanning tree connecting all the sites containing the Partition
CN=<partition name>,DC=<root domain of forest>,DC=com, or (b) replication
cannot be performed with one or more critical servers in order for changes to
propagate across all sites (most often because of the servers being unreachable).

Cause
This behavior occurs if one or more of the following conditions are true:

Site link bridging is enabled on a network that doesn't support physical network
connectivity between two domain controllers in different sites that are connected
by a KCC link.

One or more sites aren't contained in site links.

Site links contain all sites, but the site links aren't interconnected. This condition is
known as disjoint site links.

One or more domain controllers are offline.

Bridgehead domain controllers are online, but errors occur when they try to
replicate a required naming context between Active Directory sites.

Administrator-defined preferred bridgeheads are online, but they don't host the
required naming contexts.

Preferred bridgeheads are defined correctly by the administrator, but they're

currently offline.

The bridgehead server is overloaded either because the server is undersized, too
many branch sites are trying to replicate changes from the same hub domain
controller, or the site link schedules are too frequent.

KCC has built a different path around a site-to-site connection failure, but it retries
the failing connection every 15 minutes because it is in connection keeping mode.

The common causes of event ID 1311 messages fall into two categories: improper
logical configuration and infrastructure failure. Event ID 1311 messages are logged
when an improper logical configuration or a replication error occurs.

Improper logical configuration

A logical configuration is improperly configured when information in the

Configuration naming context (NC) (visible in the Sites and Services snap-in)
doesn't match the physical topology of the network that hosts the Active Directory
forest. For example, a site may not be properly defined, sites that are missing from
site links may be included, site links may not be interconnected, or incorrect
bridgeheads may be selected by the administrator.

Infrastructure failure

An infrastructure failure occurs because of one of more of the following events:

A wide area network (WAN) link fails.
 A domain controller that hosts a necessary naming context is offline.
A replication failure occurs for one or more naming contexts.
The inbound partner for the replication has disabled outbound replication.

Resolution
To troubleshoot event ID 1311 messages, use the following methods.

Determine if the event ID 1311 messages are site-specific or forest-wide.

Determine if site link bridging is turned on and if the network is fully routed.

Verify that all sites are defined in site links.

Detect and remove preferred bridgeheads.

Resolve Active Directory replication failures in the forest.

Determine if source servers are overloaded.

Determine if site links are disjointed.

Delete connections if KCC is in "Connection Keeping" mode.

Determine if the Event ID 1311 messages are site-specific

or forest-wide
Determine if event ID 1311 messages are logged on all inter-site topology generator
(ISTG) domain controllers in the forest or only on site-specific ISTG domain controllers.
To locate ISTG domain controllers, use the Ldp.exe tool to search for the following
attributes:

Base DN: CN=Sites,CN=Configuration,DC=RootDomainName,DC=Com

Filter: (cn=NTDS Site Settings)
Scope: Subtree
Attributes: interSiteTopologyGenerator

To determine the scope of the event, use one of the following methods:

Examine the Directory Service event logs of an appropriate number of ISTG domain
controllers in the forest.

Use the Eventcombmt.exe tool (available from Microsoft Product Support Services)
to search for event ID 1311 messages on an appropriate number of ISTG domain
 controllers in the forest.

Determine if site link bridging is turned on and if the

network is fully routed
When you enable site link bridging in the Active Directory Sites and Services snap-in,
you must make sure that any site defined in Active Directory has a fully routed network
connection to any other site that is defined by the administrator. If KCC builds a
connection link between two unconnected sites in which site link bridging is enabled,
event ID 1311 messages may be logged.

Site link bridging is enabled in Active Directory if the following conditions are true:

The Bridge all site links check box is selected for the IP protocol and the SMTP
protocol in the Active Directory Sites and Services snap-in.

The Options attribute for the IP protocol and the SMTP protocol is NULL or set to 0
(zero) for the following Domain Name (DN) paths:
CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC= root domain
of forest
CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC= root
domain of forest

To determine if a fully routed network connection exists between two sites, contact your
NOS administrator, network administrator, or Active Directory architect.

If site link bridging is enabled in a non-routed environment, either make the network
fully routed, or disable site link bridging and then create the site links and site link
bridges that you must use. Wait for two times the longest replication interval in the
forest. If event ID 1311 messages continue to be logged or if site link bridging is
enabled in a fully routed network, continue to the "Verify That All Sites Are Defined in
Site Links" method.

By default, site link bridging is turned on. Additionally, the best practice guidelines
recommend that you keep site link bridging turned on.

The following diagram uses plus signs (+) and minus signs (-) to illustrate physical
network connections between Active Directory sites. Site AZ is listed in site link WEST
and site GA is listed in site link EAST, but sites AZ and GA don't have fully routed
network connections to sites WA and NY in an Active Directory configuration where site
link bridging is enabled.

Output
 WA <-- Site Link WANY --> NY
+- +-
+ - + -
+ - + -
+ - + -
CA + + + AZ IL + + + GA

Site Link WEST Site Link EAST

Verify that all sites are defined in site links

Every site defined in Active Directory must be hosted or reside in a site link. For example
if sites WA, CA, AZ, NY, IL, and GA are defined, and site links WEST, EAST and WANY are
defined, event ID 1311 messages are logged if any one site (for example, AZ or GA) isn't
listed in a site link where the sites are physically connected. Sites are orphaned when
sites in a deleted site link aren't added to an appropriate existing site link.

Output

WA -- Site Link WANY -- NY

/ /
/ /
/ /
CA (AZ) IL (GA)

Site Link WEST Site Link EAST

Because sites AZ and GA are not listed in any site links, they are orphaned and the KCC
does not consider them when it constructs the replication topology for Active Directory.

The repadmin /showism command is useful for locating improperly configured sites.
Output from the repadmin /showism command appears similar to the following example
from a forest named corp:

==== TRANSPORT CN=IP,CN=Inter-Site

Transports,CN=Sites,CN=Configuration,DC=corp,DC=com CONNECTIVITY
INFORMATION FOR 3 SITES: ====
0, 1, 2
( 0) CN=US-NC,CN=Sites,CN=Configuration,DC=corp,DC=com 0:0:0, 100:15:0,
200:15:0
( 1) CN=US-TX,CN=Sites,CN=Configuration,DC=corp,DC=com 100:15:0, 0:0:0,
100:15:0
 ( 2) CN=US-WA,CN=Sites,CN=Configuration,DC=corp,DC=com 200:15:0, 100:15:0,
0:0:0

７ Note

Unlike other arguments for the repadmin command, you cannot run the repadmin
/showism command from a remote computer. You must run the repadmin /showism

command from the console of the domain controller that you want to examine (in
most cases, this is the ISTG domain controller).

For each site that is configured for IP-based replication or for SMTP-based replication
(not shown), the repadmin /showism command returns a site matrix that represents the
connections to all the sites in the forest. Each entry in the site matrix contains three
numbers delimited by colons (:) that represent the cost, replication interval, and options
for each replication link to another site in the Active Directory forest. The numbers in an
entry appear in the following order:
Cost : Replication interval : Options

The Cost value indicates the preference for a network link for replicating directory
information between sites. The administrator uses the Active Directory Sites and
Services snap-in to define the Cost value for each site link.

The Replication interval value indicates the replication frequency of the link in
minutes.

The Options value indicates the options for the site link, including site link
notification.

７ Note

When you troubleshoot event ID 1311 messages, you can ignore the Options
value.

In the example from the corp.com forest, site link bridging is enabled, and the forest
contains three Active Directory sites:

Site 0: US-NC, an uncovered site that uses the TX<->NC link to connect to Site 1
(US-TX).
Site 1: US-TX, which hosts two domain controllers.
Site 2: US-WA, a covered site that uses the TX<->WA link to connect to Site 1 (US-
TX).
Each site matrix contains one 0:0:0 entry that refers to itself. An entry that contains
positive numbers for the cost value and replication interval value (for example, 200:15:0
or 100:15:0) indicates that the site connection is good. A -1:0:0 entry indicates that the
site connection isn't working. Which occurs if one or more of the following conditions is
true:

The replication protocol isn't used. For example, if SMTP replication isn't
configured, the entries in the SMTP portion of the /SHOWISM matrix all appear as
-1:0:0.
The site doesn't host any domain controllers (this is known as an uncovered site).
The site isn't included in a site link.

If site link bridging is enabled and the repadmin /showism command returns -1:0:0
entries for one or more covered Active Directory sites, make sure that the affected sites
are listed in a site link.

A site with a full complement of -1:0:0 entries and one 0:0:0 entry is orphaned unless the
site is uncovered (no domain controllers reside in that site). When you troubleshoot
event ID 1311 messages, record the names of all orphaned sites, but don't record the
names of uncovered sites.

If site link bridging is disabled, -1:0:0 entries are less meaningful. If it's the case, you
must manually determine if each site is included in a site link. To do so, write down the
list of sites and site links, and manually map each site to a site link.

７ Note

The repadmin /showism command always returns -1:0:0 entries for an uncovered
site.

In the following repadmin /showism example, site link bridging is enabled in the
corp.com forest, and site link TX<->WA was deleted. Site 2 (US-WA) is orphaned from

all other sites in the forest and must be added to an appropriate site link.

==== TRANSPORT CN=IP,CN=Inter-Site

Transports,CN=Sites,CN=Configuration,DC=corp,DC=com CONNECTIVITY
INFORMATION FOR 3 SITES: ====
0, 1, 2 ( 0) CN=US-NC,CN=Sites,CN=Configuration,DC=corp,DC=com 0:0:0,
100:15:0, -1:0:0
( 1) CN=US-TX,CN=Sites,CN=Configuration,DC=corp,DC=com 100:15:0, 0:0:0, -1:0:0
( 2) CN=US-WA,CN=Sites,CN=Configuration,DC=corp,DC=com -1:0:0, -1:0:0, 0:0:0
Detect and remove preferred bridgeheads
Because correct bridgehead selection is difficult in multi-domain forests, and because
Windows 2000 has good fail-over logic in case a KCC-selected bridgehead goes offline,
Microsoft strongly recommends that you don't define preferred bridgehead servers.

To search for preferred bridgehead servers:

1. Use the Ldp.exe command-line tool to do an LDAP search for the following criteria:
DN Path: cn=sites,cn=configuration,dc=<root domain of forest>
ObjectClass: server
Attributes: bridgeheadTransportList

2. Use the FINDSTR command against an LDIFDE export file from the
CN=Sites,CN=Configuration container:
LDIFDE CN=SITES,CN=CONFIGURATION,DC=<Root domain in forest>
SITEDUMP.LDF
FINDSTR /i "bridgeheadTransportList" SITEDUMP.LDF

If the search returns any results, note the name of server in the Domain Name path
in which the bridgeheadTransportList attribute is populated.

If you find any preferred bridgehead servers, use the Site and Services snap-in to
remove them, and then wait two times the maximum replication interval in the
forest. If event ID 1311 messages continue to be logged, continue to the next
method.

Resolve Active Directory replication failures in the forest

Active Directory replication requires the transitive replication of all naming contexts in
the forest to all domain controllers that replicate a common partition.

Resolve replication failures for online domain controllers as quickly as possible,

especially those that host one-of-a-kind naming contexts in a forest (for example, the
only domain controller for a particular domain in the forest). As a last resort, if you can't
make a domain controller replicate, remove it from the forest.

If a domain controller is offline for fewer days than the tombstone lifetime number (by
default 60), bring the domain controller online and force it to replicate, or as a last
resort, remove it from the forest.

If a domain controller is offline or does not replicate inbound changes for more days
than the tombstone lifetime number, do not resuscitate it. Instead, immediately remove
it from the forest.

For more information about the TombstoneLifetime value, click the following article
numbers to view the articles in the Microsoft Knowledge Base:

216993 Useful shelf life of a system-state backup of Active Directory

314282 Lingering objects may remain after you bring an out-of-date Global
Catalog server back online

When you want to discover and troubleshoot replication failures, the following tools can
be useful:

repadmin /failcache : Run this command from the console of each ISTG domain

controller in the forest to discover replication failures for bridgeheads in the site
for that ISTG.

７ Note

You can also run this command remotely against other ISTG domain
controllers in the forest.

repadmin /showreps : Run this command from the console of each ISTG domain

controller in the forest to analyze replication of specific domain controllers that are
exposed by the repadmin /failcache command.

dcdiag /test:intersite /e /q : This command tests inter-site connectivity for

bridgehead domain controllers in the forest. The result set is limited to domain
controllers that experience errors with the /q switch.

dcdiag /test:connectivity /e /q : This command tests name resolution and ldap /

rpc connectivity to all domain controllers in the forest. The result set is limited to
domain controllers that experience errors with the /q switch.

Examine the Directory Service Event log on ISTG domain controllers and
Bridgehead servers, using the following settings for the NTDS Diagnostic levels:
One Knowledge Consistency Checker: 3
Five Replication Events: 3
Internal Processing: 1

The repadmin /failcache command lists replication failures that KCC knows about. The
output from the repadmin /failcache command is divided into two sections:
The KCC Link Failures cache lists errors for existing connection links. The ISTG domain
controller imports showreps (repsfroms) data for every bridgehead server in its site.
However, the ISTG domain controller does not list errors. The link failure cache is
emptied at the beginning of every KCC run and refilled during the course of the current
run.

The KCC Connection Failures cache lists unsuccessful attempts to build connection
objects between domain controllers (reps from or reps to). When you run the repadmin
/failcache command from the ISTG domain controller, it lists entries that are imported

from bridgeheads in the site. At the beginning of each KCC run, the KCC examines each
entry in the connection failure cache and tries to DsBind to the failing server. If the bind
succeeds, the entry is removed.

The repadmin /failcache command differs from the repadmin /showreps command in
two ways:

The repadmin /showreps command shows the naming context that is failing. The
repadmin /failcache command doesn't.

Data from the repadmin /failcache command isn't replicated between domain
controllers.

The following example shows sample output from the repadmin /failcache command.

Z:>repadmin /failcache ==== KCC CONNECTION FAILURES >

============================
(none)

==== KCC LINK FAILURES > ==================================

USA-WA-24\C-24-DC03 DC object GUID: 134244cd-26be-4944-82a7-ac3eb74fc02f
No Failures. USA-WA-24\B-24-DC02 DC object GUID: 21b050d6-33b5-424d-aa9b-
060fe209233d No Failures. USA-WA-24\Z-24-DC-05 DC object GUID: bfb3b008-
3849-4e5d-81d8-53dbb76d587a No Failures.

Determine if source servers are overloaded

A domain controller that is overloaded with a large number of direct replication partners
or a replication schedule that is overly aggressive can create a backlog in which some
partners never receive changes from a hub domain controller. In the output from the
repadmin /showreps command, partner domain controllers of overloaded source domain

controllers appear with the at never status.

To resolve this issue, resize hardware, reconfigure site links and reconfigure site link or
connection schedules as necessary to reduce the load on overloaded domain
controllers.

Determine if site links are disjointed

Disjoint site links is an Active Directory configuration in which the topology is broken
into two parts or in which some sites don't replicate because site definitions and site link
definitions are incorrect. For example, the following diagram shows a configuration in
which Sitelink_ABC contains sites A, B, and C and Sitelink_DEF contains sites D, E, and F,
but no site link connects any of the sites in Sitelink_ABC to any of the sites in
Sitelink_DEF. To resolve the disjoint site links condition, a new site link must connect at
least one site in Sitelink_ABC with at least one site in Sitelink_DEF (for example, a new
site link between site A and site D).

Output

A D
/ \ / \
/ \ / \
/ \ / \
B C E F

Sitelink_ABC Sitelink_DEF

The following diagram shows another possible a disjoint site links configuration. In this
case, a new site link must join any site in Sitelink_ABDC with at least one site in
Sitelink_FG (for example, a new site link between site A and site F) to resolve the disjoint
site links condition.

Output

A F
/ \ \
/ \ \
/ \ \
B C \
\ / \
\ / \
\ / \
D G

Sitelink_ABDC Sitelink_FG
Disjoint site links are the most difficult improper configuration to troubleshoot. Look for
disjoint site links only after you rule out all other known causes. Use a pencil and paper
to graph site topology and locate orphaned sites.

Delete connections if KCC is in Keep Connection mode

If KCC builds a different path around a site-to-site connection failure, but it retries the
failing connection every 15 minutes because it is in connection keeping mode, delete all
broken connections and let KCC rebuild them. Wait two times the longest replication
schedule in the forest.

Terminology and concepts

Bridgehead server: Any domain controller in an Active Directory site that replicates
an Active Directory partition (for example, schema, configuration, domain,
application partition, or global catalog) to a domain controller in another Active
Directory site.

A bridgehead is selected for each unique directory partition, domain, or

application partition in an Active Directory site, so a site that hosts three different
domains has three in-site bridgehead servers.

Domain controllers replicate all naming contexts that are held in common with
their direct replication partners, so a domain controller in the "corp.com" domain
replicates CN=SCHEMA and CN=CONFIGURATION in addition to the "corp.com"
domain naming context with its inter-site bridgehead partner.

Inter-site topology generator (ISTG): For each Active Directory site, a single server,
known as the ISTG, is nominated to build the inter-site replication topology.

Uncovered Site: An Active Directory site defined in the Sites and Services snap-in
that does not currently contain any Windows 2000 domain controllers. An
uncovered site may be waiting for its domain controller to arrive from a staging
site. Additionally, a site may be defined as uncovered to provide site preference for
client operations.

Truncated output from the REPADMIN

/SHOWISM command
In some environments, the repadmin /showism command from build 2195 of Windows
quits prematurely during execution and its output is truncated because of an internal
error. For example, the top portion of this successful /SHOWISM output from a domain
controller in the corp.com domain indicates that 128 sites are defined (0-127).

==== TRANSPORT CN=IP,CN=Inter-Site

Transports,CN=Sites,CN=Configuration,DC=corp,DC=com

CONNECTIVITY INFORMATION FOR 128 SITES: ====

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,

14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,

29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43,

44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58,

59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,

74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,

89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103,

104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118,

119, 120, 121, 122, 123, 124, 125, 126, 127

In the following example, the repadmin /showism output stops in the middle of the line
for site 115, CN=HeadQuarters.

All DCs in site CN=Headquarters,CN=Sites,CN=Configuration,DC=corp,DC=com

(with trans & hosting NC) are bridgehead candidates. (115)
CN=headquarters,CN=Sites,CN=Configuration,DC=corp,DC=com -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,

-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,

-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,

-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,

-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,

-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, 100:0:0, 150:0:0, 150:0:0, 100:0:0,

To resolve this truncation problem, obtain an updated version of the Repadmin.exe file
from Microsoft Product Support Services (PSS).
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Jet database errors and
recovery steps
Article • 02/19/2024

This article introduces Jet database error messages and troubleshooting steps.

Applies to: Windows Server 2012 R2

Original KB number: 4042791

Summary
During operating system startup, domain controller installation/uninstallation, or Active
Directory Replication, you may encounter Jet error messages. This article introduces Jet
error messages and their solutions.

Error messages

-501 JET_errLogFileCorrupt

Cause

Hardware corrupted the I/O at writing, or the hardware lost flush caused the log to
become unusable. Typically the database (DB) is left in a corrupted state.

Resolution
Restore the database from a known good backup, or reinstall the domain controller
(DC).

-510 JET_errLogWriteFail / Failure writing to log file

Cause
A log write failure occurred. This issue can be caused by any of the following:

A controller, hard drive, or other hardware stopped responding to disk commands.

Software, such as antivirus software, created locks on Active Directory log files.
Resolution
1. A restart of the server will restore access if this is a hardware issue. If the problem
happens frequently, you can upgrade firmware, replace the controller, or replace
the disk, in that order.

2. For an issue that is due to software, stop services that create locks on the files in
the file system. For example, determine whether antivirus software is causing locks
on Active Directory log files. Make sure that the proper files have been added to
the antivirus exclusion list. Windows Server 2016 automatically excludes certain
files and folders from antivirus scanning, see List of automatic exclusions. For
Windows Server 2012 R2, see:

Virus scanning recommendations for Enterprise computers that are running

currently supported versions of Windows
Event ID 2108 and Event ID 1084 occur during inbound replication of Active
Directory in Windows 2000 Server and in Windows Server 2003
Recommended file and folder exclusions for Microsoft Forefront Client
Security, Forefront Endpoint Protection 2010, and Microsoft System Center
2012 Endpoint Protection

If steps 1 and 2 don't fix the issue, determine whether a non-Microsoft application or
service is causing the issue by disabling these. To do this, follow these steps:

1. Press Windows key + R. Enter MSCONFIG and then click OK. On the Services tab,
select Hide all Microsoft Services. Clear the check box for third-party services.
2. Disable all enabled startup items.
3. Restart the server.

-528 JET_errMissingLogFile

Cause

This can be due to an unexpected shutdown that was caused by a power outage or
another unexpected shutdown. Other causes include administrator changes to log files
(such as copying an old copy) or corrupted backup/restore software (if immediately
after a restore).

Resolution

Restore the database from a known-good backup, or reinstall the DC.

-543 JET_errRequiredLogFilesMissing
See -528 / JET_errMissingLogFile (above).

Cause

Administrator modified logs or lost I/O flush on shutdown.

-550 JET_errDatabaseDirtyShutdown

Cause

Administrator modified logs or lost I/O flush on shutdown.

-551 JET_errConsistentTimeMismatch

Cause

Administrator modified logs or lost I/O flush on shutdown.

-567 JET_errDbTimeTooNew

Cause

Disk subsystem lost an I/O, probably on a hang or unscheduled shutdown.

Resolution

Verify battery backup for disk cache.

-1018 JET_errReadVerifyFailure / Checksum error on a

database page

Cause

The DB is corrupted due to a hardware failure.

Resolution
 Evaluate the disk stack, including the motherboard/controller, firmware,
connecting cables, and physical drives, and contact the relevant vendors for known
issues. Compare your current configuration against the vendors' reference
configurations.
Evaluate whether the problem can be resolved by the latest firmware updates or
was triggered by a recent firmware update.
If some DCs are logging -1018s while other DCs in the same environment aren't,
look for differences in hardware configurations.
Databases that log this error can't be recovered or repaired by integrity checks or
semantic database analysis in NTDSUTIL or ESENTUTL.
Offline defrags may fix the problem in the unlikely case that the problem is due to
an index consistency problem.
Try an offline defrag. Or, restore a system state backup that predates the
corruption. Or force-demote, perform a full metadata cleanup, and repromote. If
the -1018 error appears, repeat until the hardware root cause is resolved.

When Jet error -1018s occurs on virtualized DCs that are running on the same virtual
host only on computers that are using an on-board raid controller, the error can occur
because the uninterruptible power supply (UPS) lacked sufficient power for on-board
raid controllers to commit changes to disk following loss of electrical power. The
workaround is to configure UPS software to shut down virtualized guests upon loss of
electrical power. Servers that have dedicated (not on-board) raid controllers with their
own battery backups don't experience the -1018 JET error.

-1019 JET_errPageNotInitialized / Blank database page

Cause
This is like the -1018 error but is due to a lost page flush.

A lost flush can represent a critical USN change. Failure to apply the same change to
local DCs or to transitive replication partners could be harmful where a single replication
path exists.

Resolution
Deploy the OS on server-class hardware and disk subsystem components.

Install UPS on the host computer.

Install a disk controller with on-board battery backup.
Disable the write-back cache on the drive controller.
 Avoid placing NTDS.DIT and LOG files on IDE drives.

Databases that log this error can't be recovered or repaired by integrity checks or
semantic database analysis in NTDSUTIL or ESENTUTL.

Offline defrags may resolve the problem in the unlikely case that the problem is due to
an index consistency problem.

Try an offline defrag. Or, restore a system state backup that predates the corruption. Or,
force demote, perform a full metadata cleanup, and then repromote. Repeat until the
hardware root cause is resolved.

-1021 JET_errDiskReadVerificationFailure / The OS

returned ERROR_CRC from file IO
Jet error -1021 was new as of Windows Server 2008 R2. Windows versions that are
earlier than Windows Server 2008 R2 return -1022 instead.

-1021 identifies a -1018 error that occurred at the disk level. In other words, -1021
indicates that a disk drive returned a bad check sum error and is the specific source of
the problem in the disk stack.

Cause
The problem may be due to bad blocks on the hard disk that the hard drive may keep
track of.

Resolution

Removing and reinstalling Active Directory on the domain controller may trigger the
storage of data on healthy blocks.

-1022 JET_errDiskIO / Disk IO error

Cause
Generic disk error. Disk IO errors mean that the OS encountered a non-specific error in
accessing the disk. This error may be logged when controllers return generic errors like
"device not working." Some disks and versions of Jet return this error for CRC problems.

Resolution
Verify the whole driver stack.

-1206 JET_errDatabaseCorrupted

Cause

This error is the same as missing/corrupt log file. This error indicates that a lost flush
occurred.

-1216 JET_errAttachedDatabaseMismatch

Cause

Administrator modified logs or lost I/O flush on shutdown.

-1605 JET_errKeyDuplicate / Illegal duplicate key

Cause

Sporadic error. This error can be due to index corruption.

Resolution

Remove and reinstall Active Directory on the DC. Run NTDUSITL semantic database
analysis. If the issue persists, perform an offline defrag.

-1811

Cause
Administrator modified logs or lost I/O flush on shutdown.

Troubleshoot
You can use these methods to troubleshoot Jet database errors:

1. Verify that all Active Directory databases and log files are deployed on suitable
hardware.
 Many but not all SATA and IDE drives don't support the write flush command. SAS
drives do support it.

Active Directory databases and log files should use SAS drives on SAS controllers
DCs that have a battery backup on any write caching element.

2. If 0xc00002e1 (c00002e1) and 0xc00002e2 (c00002e2) are virtual guest domain

controllers that are running on Windows Server 2012 Hyper-V hosts, install
corrective fixes from Loss of consistency with IDE-attached virtual hard disks when
a Hyper-V host server experiences an unplanned restart on hosts and guest DCs
as required.

3. Check whether the event that preceded the LSASS 0xc00002e1 (c00002e1) and
0xc00002e2 (c00002e2) boot errors indicates one of the following issues:

Unscheduled power outage.

System hang.
Installation of Windows updates or service pack installs.
Addition or removal of disks, volumes, or partitions to the local system.
Hard drive failure.
NTDS.DIT or one or more log files were copied from another computer or
even from a previous point in this DCs life.
Unknown

4. Start the computer into Directory Services Restore mode.

5. Best practice: Make a System State backup so that you can roll back any changes
that are made during your recovery session.

6. Best practice: Ask the administrator up front to locate the most recent system state
backup so that you can factor the existence or nonexistence of System State
backups into your recovery plans. Have the admin delegate the location of any
backups, if possible.

7. Run NTDSUTIL -> Files -> Info.

７ Note

the path to the NTDS.DIT and log files.

8. Verify that the drive that hosts the NTDS.DIT or log files is available on OS startup.

9. Open Windows Explorer and verify that the NTDS.DIT and log files are present at
the log file path reported by step 7.
 If the files are present, proceed to step 10.

If the files are not present, search all available drives and volumes for the NTDS.DIT
and log files that belong to this instance of Active Directory.

２ Warning

There may be multiple NTDS.DIT and log files present on local drives. Use
date and time stamps to locate the correct instance.

Correct the paths for the database and log file paths as required.

10. Verify file permissions for the OS version in question.

７ Note

The OS needs sufficient permissions on Windows Server 2003.

ﾉ Expand table

Account Permissions Inheritance

System Full Control This folder, subfolders and files

Administrators Full Control This folder, subfolders and files

Creator Owner Full Control Subfolders and Files only

Local Service Create Folders / Append Data This folder and subfolders

The root of the volume that is hosting the NTDS.DIT and NTDS log files
(system requires fully control)
The %windir% folder (i.e., c:\windows or c:\winnnt) (system requires fully
control)
The folder that hosts the NTDS.DIT and NTDS log files (see permissions table
below)
The NTDS Log files themselves (see perms table below)

11. Verify that the correct log files reside in the log file directory:

NTDSUTIL /FILES will identify the database directory and log file directory if
different. NTDSUTIL /MH will identify which log files are required in the log file
directory.
 Under no circumstances should the database or log files from one DC be copied to
another DC to make the second DC functional.

12. Confirm that disk or file compression is not enabled on any volume that is hosting
the NTDS.DIT or log file volume.

13. Validate the health of the database in NTDS.DIT from the bottom up.

Validate Jet database health from the bottom up. Proceed up to the next layer only
when the underlying layer completes without error.

Troubleshooting any error reported by ESE logical or application logical

consistency when physical consistency is still failing will lead you down an
improper troubleshooting path.

Equivalent NTDSUTIL and ESENTUTL commands for each later are shown below:

ﾉ Expand table

Layer NTDSUTIL command ESENTUTL equivalent

command

1. Physical consistency no equivalent ESENTUTL /K

2. ESE logical consistency NTDSUTIL FILES INTEGRITY ESENTUTL /G

3. Application logical NTDSUTIL ->Semantic No equivalent. Run

consistency database analysis NTDSUTIL -> SDA

+ +

NTDSUTIL -> Offline Defrag ESENTUTL / D

14. Look up the user action for the first failing Jet error encountered during step 13.
Perform remediation if possible.

15. Repair the Jet database:

Some Jet database errors can be repaired by using NTDSUTIL and ESENTUTL.
Some Jet database errors cannot be repaired, and any attempt to repair them
will fail. In such cases, your only recourse may be to restore a system state
backup that predates the corruption, or build a new server. If replica DCs are
up-to-date, lead with promoting additional replicas into the domain after
attempting to mitigate the root cause for any hardware or software-related
errors.
 ７ Note

The Jet error that is returned in NTDS General event 1168 is an application
layer error. Don't act on this Jet error unless the Jet Physical consistency and
Application logical consistency checks, (tested in that order) pass without
error.

More Information
For more information, see the following Microsoft article:

Domain controller does not start, c00002e2 error occurs, or "Choose an option" is
displayed

What is a lost IO / Lost Flush

When an application writes data to a disk, the disk indicates the written operation
success. However, when the application tries to read the data that it just wrote, the data
does not exist. This issue is called as lost I/O, or lost flush.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8418: The replication operation failed
because of a schema mismatch between
the servers involved
Article • 02/19/2024

This article describes the symptoms, cause, and resolution for resolving Active Directory
replication failing with Win32 error 8418.

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2734946

Symptoms
This article describes the symptoms, cause, and resolution for resolving Active Directory
replication failing with Win32 error 8418: The replication operation failed because of a
schema mismatch between the servers involved.

This article is part of a series on troubleshooting AD replication errors and events

documented on Technet. To find this and related articles, use your favorite Internet
search engine to query on: Troubleshooting AD replication error <error number>:
<error string> site:support.microsoft.com

For example: Troubleshooting AD replication error 5: Access is denied

site:support.microsoft.com

Replication of any Active Directory data between domain controllers in a forest relies on
all DC's having a consistent view of the definitions of objects and attributes. These
definitions are stored in the Schema partition of the Active Directory database. The
directory replication engine prioritizes replication of data this in this partition above all
others - when any change to a schema definition is detected between partners it must
be replicated before data in other partitions can be synchronized.
1. One or more on-screen errors, logged events or diagnostic output identifies the
existence of a schema mismatch.

Possible formats for that error include:

ﾉ Expand table

Decimal Hex Symbolic Error String

8418 0x20e2 ERROR_DS_DRA_SCHEMA_MISMATCH The replication operation

failed because of a schema
mismatch between the servers
involved.

2. DCPromo Promotion

On-Screen error

---------------------------
Active Directory Domain Services Installation Wizard
---------------------------
The operation failed because: Active Directory Domain Services could not
replicate the directory partition <DN path of partition> from the remote Active
Directory Domain Controller <helper DC FQDN>.
"The replication operation failed because of a schema mismatch between the
servers involved."
---------------------------
OK
---------------------------

DCPROMO.LOG where error is encountered prior to non-critical replication phase:

MM/DD/YYYY HH:MM:SS [INFO] NtdsInstall for <hostname.dns domain name.

<top level domain> returned 8418
MM/DD/YYYY HH:MM:SS [INFO] DsRolepInstallDs returned 8418
MM/DD/YYYY HH:MM:SS [ERROR] Failed to install to Directory Service (8418)
MM/DD/YYYY HH:MM:SS [INFO] Starting service NETLOGON

If the error is encountered during the non-critical replication phase of DCPROMO,

the replica DC reboots and logs the following in the DCPROMO.LOG file.

MM/DD HH:MM:SS [WARNING] Non critical replication returned 8418 MM/DD

HH:MM:SS [INFO] Cleaning up old Netlogon information MM/DD HH:MM:SS
 [INFO] Stopped the DS MM/DD HH:MM:SS [INFO] The attempted domain
controller operation has completed

3. The following events may be logged in the Directory Service Event Log

ﾉ Expand table

Event Source Event Event String

ID

Microsoft-Windows- 1203 The directory service could not replicate the

ActiveDirectory_DomainService following object from the source directory
service at the following network address
because of an Active Directory Domain
Services schema mismatch.

Microsoft-Windows- 1309 The Knowledge Consistency Checker (KCC) has

ActiveDirectory_DomainService with detected that successive attempts to replicate
error with the following directory service has
status consistently failed.
8418

Microsoft-Windows- 1791 Replication of application directory partition

ActiveDirectory_DomainService with <DN path> from source <NTDS Settings
error object GUID> from source DC (<source DC
status FQDN>) has been aborted. Replication
8418 requires consistent schema but last attempt to
synchronize the schema had failed. It is crucial
that schema replication functions properly. See
previous errors for more diagnostics. If this
issue persists, contact Microsoft Product
Support Services for assistance. Error 8418:
The replication operation failed because of a
schema mismatch between the servers
involved.

NTDS KCC 1925 The attempt to establish a replication link for

with the following writable directory partition failed.
error
status
8418

NTDS Replication 1203 The local domain controller could not replicate
the following object from the source domain
controller at the following network address
because of an Active Directory schema
mismatch

NTDS Replication 1791 Replication of Naming Context <DN path>

with from source <NTDS Settings object guid> has
 Event Source Event Event String
ID

error been aborted. Replication requires consistent

status schema but last attempt to sync the schema
8418 had failed. It is crucial that schema replication
functions properly. See previous errors for
more diagnostics. If this issue persists, contact
Microsoft Product Support Services for
assistance. Error 8418: The replication
operation failed because of a schema
mismatch between the servers involved.

4. Active Directory Sites and Services fail with the following error:

--------------------------- Replicate Now --------------------------- The following

error occurred during the attempt to synchronize naming context <Naming
context> from Domain Controller <source DC> to Domain Controller
<destination DC>: The replication operation failed because of a schema
mismatch between the servers involved. This operation will not continue. ------
--------------------- OK ---------------------------

5. REPADMIN.EXE shows the following errors:

REPADMIN /SHOWREPS

Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8418 (0x20e2): The

replication operation failed because of a schema mismatch between the
servers involved.

REPADMIN /SYNCALL

repadmin /syncall /AePdq Syncing all NC's held on <DC Name>. Syncing
partition: DC=contoso,DC=com SyncAll reported the following errors: Error
issuing replication: 8418 (0x20e2): The replication operation failed because of a
schema mismatch between the servers involved.

REPADMIN /REPLSUM

repadmin /replsummary Replication Summary Start Time: YYYY-MM-DD

HH:MM:SS Beginning data collection for replication summary, this may take a
while: ..... Source DSA largest delta fails/total %% error <Source DC>
xxh:yym:zzs 4 / 5 80 (8418) The replication operation failed because of a
 schema mismatch between the servers involved. Destination DSA largest delta
fails/total %% error <dest DC> 04h:02m:16s 4 / 5 80 (8418) The replication
operation failed because of a schema mismatch between the servers involved.

Cause
Attempts to replicate AD when schema information is not consistent between the DC
partners involved will result in a "Schema Mismatch" error status. This symptom can be
manifested in a number of different ways as outlined above. However the underlying
cause of the error being raised can vary.

There are also scenarios where this error will be raised but there is not a mismatch in the
schema information in the strictest sense. In these cases, it may be that the Active
Directory data being replicated does not conform to the current schema definition for
the relevant object or attribute whose value is being synchronized and applied at the
destination DC.

The duration of schema mismatch errors typically fall into one of two categories,
transient or persistent. Within the persistent category, there are some failures that can
be investigated AND resolved safely.

For issues where schema replication fails due to improper attribute schema definitions
please engage Microsoft Customer Service and Support to work through the issue.

Note: Lab testing of schema modification is critical prior to implementing any proposed
action plan into your production schema.

Schema Update - after an administrative schema update is likely that a schema

mismatch will occur on various DC's throughout the forest. This will typically happen in a
pattern that matches the AD replication topology and schedule. This behavior is normal
so long as the error state is transient*. This class of failure is most likely to be

reported by monitoring software and requires no administrative intervention.

The duration for which schema mismatch may be logged by a given destination DC
should last no more than one replication cycle for any given partner. DC's with only one
partner should only see the error once while bridge head dc's may see the error multiple
times, once for each partner.

A reasonable estimate of the acceptable time limit transient failure is forest convergence
period* x 1.5.

*The largest amount of time taken for an object update to replicate from one DC to all
other DCs in the forest.
Transient Symptom Triggers

Schema Update - after an administrative schema update is likely that a schema

mismatch will occur on various DC's throughout the forest. This will typically happen in a
pattern that matches the AD replication topology and schedule. This behavior is normal
so long as the error state is transient*. This class of failure is most likely to be reported
by monitoring software and requires no administrative intervention.

The duration for which schema mismatch may be logged by a given destination DC
should last no more than one replication cycle for any given partner. DC's with only one
partner should only see the error once while bridge head dc's may see the error multiple
times, once for each partner.

*A reasonable estimate of the acceptable time limit transient failure is twice the amount
of time taken for an object update to replicate from one DC to all other DCs in the
forest.

Persistent Symptom Triggers

In some scenarios the schema mismatch error will persist indefinitely and intervention is
required to investigate, identify the underlying trigger and resolve. Some scenarios
present as known issues while in other the Schema Mismatch is purely a side effect of
other blocking issues that prevent it from self-resolving through normal replication.

Known Issues

ﾉ Expand table

KB Article Title Key Data

No.

982438 You cannot install AD DS in Windows Server 2008 in a Event ID 1791

Windows Server 2003-based domain if another computer
that is in the same domain has MSCS installed

947020 Event IDs 1481, 1173, and 1203 are logged in the Directory Event ID 1481 Error
Services log on a Windows Server 2003-based domain 2083; DSID 31510B7
controller
Event ID 1173 Param
2083 DSID 31010B7

Event ID 1203
"Schema Mismatch"

824873 Event 1791 is logged when information is replicated from Event ID 1791 Error
Windows 2000 to Windows Server 2003 8418
 KB Article Title Key Data
No.

Event ID 1481 DSID

3151030

2001769 Error While Propagating Permissions: "Unable to save Event ID 1450 DSID
permission ... 3150dbe

Other Blocking Issues

ﾉ Expand table

Topic KB Key Data

Replication Quarantine 2020053 Event ID 2042

Error status 8614

Replication failure caused by Lingering objects when Strict 2028495 Event ID 1988 with
Replication Consistency is enabled status 8606

Replication Topology

Disabled Replication 2028495 Status 8457

DNS (Name Resolution) 2021446 Event ID 2023 with

Status code 8524

RPC 1722: Status Code 1722

2102154 Status Code 1753

1753:

2089874

Resolution
In order to resolve an issue where schema mismatch is cited, it is critical to understand
the scenario in which the is error is being raised as it may influence the data collected.
The common scenarios are:

Recent Schema Update

DC Promotion
Normal Replication
As stated previously, in the case of a recent schema update it is common for some DC's
to report the schema mismatch as a normal part of processing the update. This state
should only be investigated if it persists for an extended period Schema Mismatch
during promotion of a DC is almost always a persistent issue that cannot be overcome
without investigation and remedial steps being taken.

Initial Data Collection

The aim of the initial data collection is to try to capture information sufficient to identify
if a known issue is being experienced or if other issues are contributing to the failure.

Collecting replication data for all DC's in the forest is advised particularly in the case
where a schema mismatch has been noted after a recent Schema Update or during
normal replication monitoring. Collecting this data helps identify any pockets of
replication failure on which to focus.

Repadmin showrepl * /csv > allrepl.csv

Once all the DC's experiencing replication failures, of ANY form, have been identified
from the repadmin /showrepl data focus cam move to specific DC's.

In the case where DCpromo fails with a schema mismatch the following data should be
collected:

DCpromo and DCpromoUI logs

NTDS Diagnostic Event Logging on both the source and destination DC as
described below in "Data Collection Phase 2"
Ldifde Export of the Schema partition as described below in the "Schema Review"

Verify the Schema Versions

The current schema version can be read from two places on any given DC - the registry
and in the Active Directory itself. In normal operation the two values should be in sync
and should correctly reflect the Schema Version of the forest as defined by the schema
FSMO.

Note: Only Microsoft provided updates of the Active Directory Schema will update the
SchemaVersion number.

Reference Schema Version Values

ﾉ Expand table
 Operating System Schema Version

Windows 2000 13

Windows Server 2003 30

Windows Server 2003 R2 31

Windows Server 2008 43

Windows Server 2008R2 47

Windows Server 2012 56

Windows Server 2012R2 69

Windows Server 2016 87

In the Registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\SystemSchemaVe

rsion

In Active Directory:

Object: Cn=Schema,cn=configuration,dc=contoso,dc=com
Attribute: ObjectVersion

The schema version in AD can be exported using one of the following commands

Ldifde -f schemaver.ldf -d Cn=Schema,cn=configuration,dc=contoso,dc=com -l

ObjectVersion dsquery * cn=schema,cn=configuration,dc=contoso,dc=com -scope base -

attr objectVersion

Possible Resolution 1

In the scenario where the following conditions apply:

The AD schema has been recently updated

One or more partners of a DC is reporting a schema mismatch for an extended period

The registry and AD schema versions on the source DC are in sync and match the
expected forest-wide version

It's possible that a reboot of the source DC will resolve the replication failures. The
underlying cause is thought to be failure to correctly reload the in memory version of
schema after the schema update has been received.

Data Collection Phase 2

In the event that the resolution above is not applicable or is unsuccessful increase
"NTDS Diagnostic" Event Logging on both Source AND Destination DCs under the
following registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics

ﾉ Expand table

Name Type Value

5 Replication DWORD 5

9 Internal Processing DWORD 5

24 Schema DWORD 5

7 Internal Configuration DWORD 5

This will log additional information to the Directory Services event log that will assist in
diagnosing the issue

Trigger the scenario that raises the Schema Mismatch err and review the event log data
collected to try to identify:

The object on which replication is failing either by its Distinguished Name or

ObjectGUID
The attribute being applied either by its ldapdisplayname or its internal ID
Any internal or extended error data.

Event ID's of interest from the Directory Service Event log include:

Replication event 1173

Replication Event 1791

Replication Event 1203

The following example events show both an internal ID and extended error data

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 1173
 Task Category: Internal Processing
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: Dc12.Contoso.com
Description:
Internal event: Active Directory Domain Services has encountered the following
exception and associated parameters.
Exception:
e0010004
Parameter: 0
Additional Data
Error value:
8364
Internal ID:
2050078

The following example event identifies a specific object on which replication blocked.

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 1203
Task Category: Replication
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: GB-JDT-DMV-N55.contoso.com
Description:
The directory service could not replicate the following object from the source
directory service at the following network address because of an Active Directory
Domain Services schema mismatch.
Object: CN=Machine,CN={54EFB8A2-33F1-4E04-B4AD-
229ABA513555},CN=Policies,CN=System,DC=contoso,DC=com
Network address: <GUID>._msdcs.contoso.com
Active Directory Domain Services will attempt to synchronize the schema before
attempting to synchronize the following directory partition. Directory partition:
DC=contoso,DC=comiption:
The directory service could not replicate the following object from the source
directory service at the following network address because of an Active Directory
 Domain Services schema mismatch. Object:
CN=Machine,CN={54EFB8A2-33F1-4E04-B4AD-
229ABA513555},CN=Policies,CN=System,DC=contoso,DC=com Network address:
<GUID>._msdcs.contoso.com
Active Directory Domain Services will attempt to synchronize the schema before
attempting to synchronize the following directory partition. Directory partition:
DC=contoso,DC=com

Review the data collected

Look for correlating events including the ones noted above which point to known
trigger scenarios.

Look for events that might indicate other underlying issues on the source or destination
that might be blocking replication and so causing what might be a transient mismatch
failure to persist.

Examples of other causes include but are not limited to:

Database CorruptionMemory Constraints Replication Quarantine Strict Replication

Consistency Disabled Replication Objects with Security Descriptors in excess of 64 Kb
DNS (Name Resolution) etc. RPC Communication Failures Local firewalls

See Causes Section for details of events and related status codes for some of these
issues.

Supplementary Actions

If the object triggering failure can be identified, then first use repadmin /showobjmeta to
dump the object replication metadata and on both source and destination DC. This
method can be used to identify "candidate" attributes that could be the cause of failure

Repadmin /showobjmeta Target_DC "DN_of Trigger_Object"

If only the GUID of the object is known use the syntax:

Repadmin /showobjmeta Target_DC "\<GUID=ObjectGuid_of Trigger_Object>"

Review the replication metadata for correctness by ensuring that all the replicated
attributes display a correctly formed attribute name

Example

The two entries fro replication metadata for a problem object as displayed by
Repadmin.exe shows no ldapdisplayname:
 USN DSA Org USN Org. Time/Date Version Attribute
24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18085395 <DateTime> 2
24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18086114 <DateTime> 3

If any of the metadata fields has no associated name try using ldp.exe to expose the
internal attributeid

The metadata for the same object above as displayed in LDP.exe shows the AttributeID
associated with the data

AttID Ver Loc.USN Originating DSA Org.USN Org.Time/Date

250000 2 24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18085395 <DateTime>
250004 3 24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18086114 <DateTime>

The attribute ID can be used to help identify the problem attribute but requires the
engagement of Microsoft Support.

Version comparison - attributes to be replicated will have higher version numbers on the
source.

７ Note

In the DCpromo scenario, the destination object will most likely not yet exist.

If ONLY the object can be identified from the event data, dump the attribute values of
the trigger object.

Console

Ldifde -f results.txt> -d "DN_of Trigger_Object" -s Target_DC Ldifde -f \

<results.txt> -d "<GUID=ObjectGuid_of Trigger_Object>" -s Target_DC Repadmin
/showattr Target_DC "DN_of Trigger_Object" Repadmin /showattr Target_DC
"DN_of Trigger_Object"

If the replication events citing 8418 yielded any Extended or Internal errors use those
values to try to match against known issues.

If the attribute triggering failure cannot be identified by the event log data or replication
metadata, then it will be necessary to engage Microsoft Product Support to assist with
the investigation.

Schema Review
Once a potential trigger attribute has been identified and other known causes
eliminated then the next action is to review the schema definition for the attribute. This
analysis is best performed with the assistance Microsoft Product Support.

Export of entire schema partition from both source and destination domain controllers:

Console

Ldifde -f schema _TargetDC.ldf -d

cn=schema,cn=configuration,dc=contoso,dc=com -s Target_DC

Data to provide to Microsoft Support

Be prepared to provide the following information to Microsoft Support staff to assist in

diagnosing the causes of the schema mismatch

Export of schema partition from the source domain controller

DCpromo logs from destination DC (if appropriate for the scenario)
Repadmin /showrepl output from the source and destination domain controller

Directory Services Event logs with extended logging from the source and
destination domain controller
Replication metadata of any problem object identified from the event logs
LDIFDE Export of any problem object identified from the event logs

More information
Possible schema definition issues that can trigger mismatch include:

OID Clash Invalid OM Syntax values Invalid MayContain values Objects with attributes
that contain data but the schema definition for the attribute type(s) has been marked as
defunct

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8461
Article • 02/19/2024

This article describes symptoms, cause, and resolution steps for cases in which AD
Replication is delayed and generates Win32 error 8461:

The replication operation was preempted.

Applies to: Windows Server 2012 R2

Original KB number: 2981628

Symptoms
The specific symptoms are as follows:

Symptom 1:

DCDIAG reports that the Active Directory Replications test has failed with error
status (8461): The replication operation was preempted.

Sample error text from DCDIAG resembles the following:

Testing server: <site><DC name>

Starting test: Replications
* Replications Check

REPLICATION LATENCY WARNING

[Replications Check,<DC name>] This replication path was preempted by
higher priority work.
From <source DC> to <destination DC>
Naming Context: DC=<DN path>
The replication generated an error (8461):
The replication operation was preempted.
Replication of new changes along this path will be delayed.
Progress is occurring normally on this path.

Symptom 2:
REPADMIN.EXE reports that the last replication attempt was delayed for a normal
reason, result 8461 (0x210d).

REPADMIN commands that commonly cite the 8461 status include but aren't limited

to:
REPADMIN /REPLSUM

REPADMIN /SHOWREPL
REPADMIN /SHOWREPS

REPADMIN /SYNCALL

Symptom 3:

Repadmin /rehost fails and generates status code 8461.

Symptom 4:

Repadmin /queue output reveals one or more tasks that have the status of

"PREEMPTED."

[12142] Enqueued 2011-11-26 06:05:55 at priority 40

SYNC FROM SOURCE
NC dc=west,dc=contoso,dc=com
DSA Boulder\BoulderDC DC DSA object GUID <GUID>
DSA transport addr <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY
PREEMPTED

Symptom 5:

The "replicate now" command in Active Directory Sites and Services (DSSITE.MSC)
fails and generates the following error message:

The replication operation was preempted.

Dialog title: Replicate Now

Message text: The following error occurred during the attempt to synchronize
naming context <DNS name of directory partition> from domain controller
<source DC>
to domain controller <destination DC>:
The replication operation was preempted.

Symptom 6:
Events in the Directory Services event log cite the error status 8461.

ﾉ Expand table

Event Source Message

and Event ID

NTDS The following number of operations is waiting in the replication queue.

Replication The oldest operation has been waiting since the following time. Time:
1839 <date> <time> Number of waiting operations: <value> This condition can
occur if the overall replication workload on this domain controller is too
large or the replication interval is too small.

NTDS Performance warning: replication was delayed while applying changes to

Replication the following object. If this message occurs frequently, it indicates that the
2094 replication is occurring slowly and that the server may have difficulty
keeping up with changes.

Source: NTDS Replication

Event ID 1839
Type: Warning
Description:
The following number of operations is waiting
in the replication queue. The oldest operation has
been waiting since the following time.
Time:
Number of waiting operations:
This condition can occur if the overall
replication workload on this domain controller is
too large or the replication interval is too small.

７ Note

Event 1580 is also logged when long-running replication tasks complete if

verbose replication diagnostics logging has been set to a value of 0x1 or
greater.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics]
"5 Replication Events"=dword:00000001

ﾉ Expand table
 Event Event String
Source and
Event ID

NTDS A long-running Active Directory Domain Services inbound replication task

Replication has finished with the following parameters.
1580
Elapsed time (minutes):
84

Operation:
Synchronize Replica

Options:
0x21000051

Parameter 1:
DC=Contoso,DC=com

Parameter 2:
<source DCs ntds settings object object guid>

Parameter 3:

Parameter 4:

A long-running replication task may also occur when a system has been
unavailable or a directory partition has been unavailable for an extended
period of time. A long-running replication task may indicate a large number
of updates, or a number of complex updates occurring at the source
directory service. Performing these updates during non-critical times may
prevent replication delays.

A long running replication task is normal in the case of adding a new

directory partition to Active Directory Domain Services. This can occur
because of a new installation, global catalog promotion, or a connection
generated by the Knowledge Consistency Checker (KCC).

Additional Data

Error value:

The operation completed successfully.

Cause
This replication status is returned when there are higher priority replication tasks in the
destination DCs inbound queue. It doesn't indicate a failure condition; the replication
task isn't cancelled, instead, the task is put into a holding pattern until the higher
priority work is completed. It's normal to see this message returned periodically in larger
environments, and it's important to note that the condition is transient.

While this issue is common and transient, some other AD replication problems can
cause a backlog in the queue. If this occurs, you might start seeing replication tasks
being preempted frequently. Frequent logging of event 2094 "Performance warning"
(sample event are shown in the "Symptoms" and "Resolution" sections) is another
indication that troubleshooting may be needed.

Investigate those problems

Explanation of repadmin /queue and replication priority

Analyze queue output over time to determine whether tasks are being processed
Explanation of repadmin /showrepl /verbose

ﾉ Expand table

Active Directory The progress of inbound replication was Wait for replication to
replication has interrupted by a higher priority complete. This
been preempted. replication request, such as a request informational message
generated manually with the repadmin indicates normal operation.
/sync command.

Replication Load
Too many partners
Too frequent of object and attribute updates
Frequent updates combined with inter-site change notification that results in a
high rate of redundant change notifications
Small replication schedule window

Performance-based issue

Disk and or memory performance

Network performance

Resolution
This status does not indicate a failure condition. This is a temporary issue in many cases
and there are no resolution steps required.

If the status 8461 never clears, there is a lot of work to do to determine the correct path
to take. This issue requires advanced knowledge of multiple troubleshooting tools. It
may be necessary to seek the help of Microsoft Support to assist with the data analysis
process.

You will have to determine the cause before you implement any steps to resolve an
underlying problem. The cause of the replication status 8461 can occur in any of the
following scenarios:

Transient condition

Replication load
Consistent Load
Temporary Load

Performance issue
OS Performance
Disk Performance
Network Performance

Determine whether this is only a transient condition. Document the time that manual
replication is initiated, and find the corresponding tasks in the repadmin /queue output.
Sometime later, run repadmin /queue , and determine whether the manually initiated
tasks are still present.

If replication tasks are queued. Look at the currently running task, and investigate.

Use event log data, repadmin output, and performance monitor to help isolate the
cause of the problem. Determine how quickly updates are being processed and what
rate of change.

Replication Load

Consistent
The domain controller has too many replication partners or under too great a replication
load. Symptoms of an overloaded DC would be:

A replication queue that never clears even though replication tasks are processed
in a timely fashion
 ７ Note

You can use repadmin /queue over time and correlate this with performance
data to identify this scenario.

Frequent occurrence of replication status 8461

Resolution: Reduce inbound connections (balance connections amongst hub-site

DCs (ADLB.exe is useful here), add new DCs and rebalance the connections, deploy
RODC in spoke sites, and decrease excessive replication of changes.

Excessive replication
Attributes that are frequently updated. Identify attribute updates using verbose
replication event log events (or using repadmin /showchanges ) and then correlate with
repadmin /showobjmeta for several objects on the destination DC. Look at the attribute

identified in the event and look for a high version number, or get multiple logs for the
same object throughout the day and see if the version number increases frequently.

Temporary
Bulk changes infrequently
After hosting a partition for the first time or during a rehost

Performance-based issue
Common symptoms for performance induced queue buildup include

Event ID 2094

Event Type: Warning

Event Source: NTDS Replication
Event Category: Replication
Event ID: 2094
Description:
Performance warning: replication was delayed
while applying changes to the following object. If this
message occurs frequently, it indicates that the
replication is occurring slowly and that the server may
have difficulty keeping up with changes.
 Object DN: CN=JUSTINTU,OU=Workstations,DC=contoso,DC=com
Object GUID: <GUID>
Partition DN: DC=contoso,DC=com
Server: <GUID>._msdcs.contoso.com
Elapsed Time (secs): 13
User Action:
A common reason for seeing this delay is that this object is especially large, either in
the size of its values, or in the number of values. You should first consider whether
the application can be changed to reduce the amount of data stored on the object,
or the number of values.If this is a large group or distribution list, you might
consider raising the forest version to Windows Server 2003, since this will enable
replication to work more efficiently. You should evaluate whether the server
platform provides sufficient performance in terms of memory and processing power.
Finally, you may want to consider tuning the Active Directory database by moving
the database and logs to separate disk partitions.

If you wish to change the warning limit, the registry key is included below. A value
of zero will disable the check.

Additional Data Warning Limit (secs): 10 Limit Registry Key:

System\CurrentControlSet\Services\NTDS\Parameters\Replicator maximum wait for
update object (secs)

Determine whether changes that are applied to the database are occurring slowly by
using performance monitoring and repadmin /queue output. Correlate AD Replication
counters with base OS performance counters (Disk, Memory, Network, and CPU).

DC

Disk

Network

Queue contains 55 items.

Current task began executing at <DateTime>.
Task has been executing for 508 minutes, 53 seconds.
[6485] Enqueued 2011-11-26 01:55:33 at priority 590
SYNC FROM SOURCE NC DC=corp,DC=contoso,DC=com
DC Houston\5thWardDC
DC object GUID <GUID>
DC transport addr <GUID>._msdcs.contoso.com
FORCE
 [12142] Enqueued <DateTime> at priority 40
SYNC FROM SOURCE NC dc=west,dc=contoso,dc=com
DC Boulder\BoulderDC
DC object GUID <GUID>
DC transport addr <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY PREEMPTED

More information

Slow AD Replication troubleshooting

This issue requires advanced knowledge of multiple troubleshooting tools. It may be
necessary to seek the help of Microsoft Support to assist with the data analysis process.

Terminology: Slow vs. latent

In slow AD replication, changes are committed to the Active Directory database slowly
or replication tasks take a long time to process.

Common causes include:

DC / OS performance problems
Resource depletion
Disk bottleneck

AD database problems
Logical or physical corruption
Object or attribute issues

DC load issues

Handling too many clients

Replication storm
High rate of change to objects and attributes
Full partition syncs

In latent AD replication, the DC is not notified about changes for a long time:

Common causes include:

AD Topology Configuration (schedule, site links, replication schedule, disconnected

topology)
This document and data collection strategy is meant to be used for troubleshooting
Slow AD Replication.

Symptoms of slow AD Replication

Data collection

Repadmin Data

Use Repadmin /queue to document the queued replication tasks. Monitor the queue to
see if there is a delay in processing replication tasks. Log all repadmin /queue output to
the same text file so you have good historical data.

Console

Repadmin /queue DCName >DCNameReplQueue.txt

Choice /d y /t 300
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 300
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 900
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 900
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 1800
Repadmin /queue DCName >>DCNameReplQueue.txt

Review the output to see whether replication tasks are processed in a timely manner.
The top of the file contains the currently running task and the length of time it has been
running. If the same task is always at the top of the output, you can use verbose output
of repadmin /showrepl to monitor the progress.

Repadmin changes

Repadmin /showrepl

Use Repadmin /showrepl and the /verbose option to monitor the last replication status
and the number of changes that remain to be replicated.

Console

Repadmin /showrepl /verbose DCNameDomainDN

Repadmin /showrepl /verbose 5thwardCorpDC dc=corp,dc=contoso,dc=com

To limit the output so that only the desired Source DC is displayed, use the following:
 Console

Repadmin /showrepl /verbose DCNameDomainDN SourceDcDSAObjectGUID

Repadmin /showrepl /verbose 5thwardCorpDC <GUID> dc=corp,dc=contoso,dc=com

Repadmin /showutdvec

Use Repadmin /showutdvec on the source and destination DC to determine replication

delta.

Console

repadmin /showutdvec DCName DomainDN

repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com

Obtain Repadmin /showutdvec /latency from the source and destination DC for the
partition in question.

In the output, document the following:

1. From source DCs showutdvec: USN # next to Source DCName

2. From destination DCs showutdvec USN# next to SOURCE DCNanme

Source DC

Dallas\2008DC1 @ USN 451265 @ Time <DateTime>

Dallas\SourceDC @ USN 1126541 @ Time <DateTime>
Houston\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\2012DC2 @ USN 460219 @ Time <DateTime>
Dallas\DestinationDC @ USN 1353465 @ Time <DateTime>
Dallas\2003DC1 @ USN 15556 @ Time <DateTime>

Destination DC

Dallas\2008DC1 @ USN 451265 @ Time <DateTime>

Dallas\SourceDC @ USN 801224 @ Time <DateTime>
Houston\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\2012DC2 @ USN 460219 @ Time <DateTime>
 Dallas\DestinationDC @ USN 1359087 @ Time <DateTime>
Dallas\2003DC1 @ USN 15556 @ Time <DateTime>

Source DC

SourceDC @ USN 1126541

Destination DC

SourceDC @ USN 801224

1126541-801224 = 325317

The destination DC is 325,317 USNs behind.

７ Note

You can also get the Source DCs highestcommitedUSN from the Source DC by
using this command:

Console

repadmin /showattr SourceDC . /atts:highestcommittedusn DN: 1>

highestCommittedUSN: 1126541

Performance Data

Create a new User Defined Data Collector set in Performance Monitor that uses the AD
Diagnostics template.

The steps here detail how to set up a good set of baseline DC performance counters.
You will need to modify some of the settings, such as duration and sample interval to fit
your specific scenario.

How to Create a User Defined Data Collection Set

1. Open Server Manager on a Full version of Windows Server 2008 or a later version.
2. Expand Diagnostics > Performance > Data Collector Sets.
3. Right-click User Defined and select New > Data Collector Set.
4. Type in a name such as AD DS Diagnostics, and leave the default selection of
Create from a template (Recommended) selected. Then, select Next.
5. Select Active Directory Diagnostics from the list of templates and then select Next
and follow the Wizard prompts (making any changes you think are necessary).
6. Right-click the new User Defined data collector set and view the Properties.
 7. To change the run time, modify the Overall Duration settings in the Stop Condition
tab, and then click OK to apply the changes.

Options to consider:

Overall Duration -you can have the data collector stop after collecting for a set
amount of time

Limits -you can have the data collect stop after a time or size threshold is reached
(with the option to have it automatically restart)

Setting limits is advantageous when you want to limit the log size.

Restart the data collector set at limits

Duration

Maximum Size

View Performance Counter Properties for the User Defined Data Collector Set

1. Select your new User Defined data collector set.

2. Right-click Performance Counter, and then select Properties.
Here you have the options of changing the Sample interval and adding or removing
additional counters.

For this scenario, the default-sampling interval of 3 seconds should be sufficient.

However, for much longer sampling times, 3 seconds is too frequent an interval.

All recommended counters are included in the default AD Diagnostic's collector set with
three exceptions:

Database ==>Instances(lsass/NTDSA)\ *

LogicalDisk(*)\*

For LogicalDisk: all instances are not required - System drive and drives where
database and logs are stored should be included at minimumSecurity System-
Wide Statistics\*

Security System-Wide Statistics\*

To add the AD DS database counters to the User Defined Data Collection Set

1. In Performance Counter Properties, select Add.

2. Expand Database ==>Instances (all counters should be highlighted).

3. Under Instances of selected object, select lsass/NTDSA

 4. Select Add, and then click OK.

5. Add the LogicalDisk and Security System-Wide Statistics objects also.

After the settings are configured to your liking, you can run the new data collector set
directly from Server Manager or export it and deploy it to specific servers.

When you are ready to begin collecting performance data, start your newly defined
Collection Set:

To start your newly defined Data Collection Set from the MMC:
 1. In the Performance Monitor mmc, navigate to Performance / Data Collector Sets /
User Defined
2. Right-click the new collection set AD DS Diagnostics and select Start.
3. You can verify that it has started by selecting User Defined AD DS Diagnostics
should have a status of Running

After testing is complete, stop the AD DS Diagnostics Collection Set:

1. In the Performance Monitor mmc, navigate to Performance / Data Collector Sets /

User Defined.
2. Right-click the new collection set AD DS Diagnostics, and select Stop. You can
verify that it has stopped by selecting User Defined.

AD DS Diagnostics should go from a status of Running to Compiling and finally Stopped

Please note that the MMC is not great about refreshing its view. So, if it seems to be stuck
in Running or Compiling after you clickStop, try refreshing the screen.

The compiled report is viewable under Performance / Reports / User Defined / AD DS

Diagnostics

The default path in Windows Explorer is here: %systemdrive%\PerfLogs\Admin\AD DS

Diagnostics

Command-Line instructions: Gather AD Diagnostics from the command line:

To START a collection of data from the command-line issue this command from an
elevated command prompt: logman start "user defined\AD DS Diagnostics" -ets
To STOP the collection of data before the default 5 minutes, issue this command: (get at
least one full five-minute sample for this issue) logman stop "user defined\AD DS
Diagnostics" -ets

Diagnostic data is logged here: C:\PerfLogs\Admin\AD DS Diagnostics\DateStamp

Sample Data Collection Script

Console

logman start "system\Active Directory Diagnostics" -ets time /t >slow.txt

repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com
>slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
:start
ping 127.0.0.1 -n 60 >NUL
time /t >>slow.txt time /t >>slowrepl.txt
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com
>>slowrepl.txt
 repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
goto start

Event log data

The default logging enabled in the directory services event log is useful to monitor for
events that indicate slow application of changes. (EVENT X) Verbose diagnostic logging
can be enabled to see what changes are currently being applied. Enabling diagnostic
logging at the level mentioned in this article will cause the log to fill up rather quickly,
so only enable it while actively troubleshooting this condition. To give an idea of rate of
events logged with this level of verbosity:

A Directory Services event log configured to 100 MB wrapped in less than two minutes
(1 minute 27 seconds). The log contained 195,728 events. Of all events, 189,340 were
event ID 1412 (attribute addition).

Increase the size of the Directory Services event log

Size the event log so that the enhanced logging doesn't cause the log to wrap in
too short of a period

Enable AD Replication Diagnostic logging to 0x5:

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics 5 Replication Events =

Export the Directory Services event log shortly after you receive the status 8461, and
reduce the diagnostic logging to a suitable level.

Review the event log for the following:

How quickly are attribute values are written to the database? ->Directory Services event
log Event ID 1412 or even better, use performance counter: DirectoryServices / DRA
Inbound Properties Applied/sec

At diagnostic level 5 for Replication Events, for user object creation, around 25 or so
event 1412's (depending on what was written at time of user creation) are written (one
per attribute value). When all attributes have been added, the object creation event is
logged (Event ID 1365).

The description section of the event contains the following data:

Internal event:
The following object changes were applied to the local Active Directory Domain
 Services database.
Property: 900dd (sAMAccountName)
Object: CN=xtestingusers14167,CN=Users,DC=north,DC=fabrikam,DC=com Object
GUID: <GUID>
Remote version: 1
Remote timestamp: <DateTime>
Remote Originating USN: 540828

The Property section contains both the attributeID and the lDAPDisplayName of the
attribute.

One event is written per value at this debug log level. Filter on the events and determine
how many entries occur in a given period. Review the event details in order to
determine if we are writing values for multiple attributes in order to instantiate an object
or if we are writing to the same attribute across multiple objects. While this level of
analysis can seem cumbersome, it can be useful in determining root cause. As an
example, if you see that we are only writing a few events per second then that could
indicate that transactions are being written to the database slowly or perhaps we have
too many partners that are sending redundant changes (event ID 1239).

Notice that it is perfectly normal to see event ID 1239 when replication diagnostics is set
to 0x5. If you filter out event 1239 and you see nothing else and you have a fairly long
event log history, then that may indicate a problem. This issue was observed by a
customer with a large Active Directory environment that had inter-site change
notification enabled. If you determine that there is a large number of events per second,
replication is probably not affected by a performance problem.

Object Metadata

If an event is logged that indicates a change is taking a long time to process Event ID,
record the objectGUID, and then get the following output:

Replication metadata:

Console

Repadmin /showobjmeta "<GUID=ObjectGUID>" >objectmeta.txt

Review the output for recently modified attributes. Pay particular attention to attributes
with frequently modified version numbers. An attribute that has a high version count
could indicate that frequent changes are being made to the attribute. If you suspect this,
you can either view the attribute value to get some context as to why the attribute was
changed, or you can let some time pass, and then get addition repadmin /showobjmeta
output in order to check whether the version of the same attribute on the same object
has increased further.

Object and attribute data:

Use a utility to output the object and attribute values. Then, review the attribute data for
the attributes that have recently modified data. The following examples present two
methods to do this.

Object attribute values from repadmin:

Console

Repadmin /showattr DCName "<GUID=ObjectGUID>" /allvalues /long

>objectByGuid.txt

Object attribute values from LDP

Connect and bind to the server in LDP and copy all the output for the object to a text
file

ldpoutput.txt

Network-related data

Console

Tasklist /svc >nets.txt Netstat -anob >>nets.txt

Data AnalysisKey AD Replication specific Performance Counters

DRA Inbound Full Sync Objects Remaining

DRA Inbound Objects Applied/Sec
DRA Inbound Objects / Second (Inbound Replication)
DRA Inbound Objects Filtered / Sec (Suggests all New Attributes)
DRA Outbound Bytes Total Since Boot Replication Queue:

ﾉ Expand table
 DirectoryServices\DRA Indicates the number of directory This counter should be
Pending Replication synchronizations that are queued as low as possible. If it
Synchronizations for this server. This counter helps is not, the server
identify replication backlogs-the hardware is probably
higher the number, the larger the slowing replication.
backlog.

Use this counter to determine the replication queue. Repadmin /queue DCName also
reports this information.

Gauging Current Performance:

ﾉ Expand table

DRA Inbound Objects Shows the number of objects received from neighbors through
Applied/sec inbound replication and applied.

DRA Inbound Properties Shows the total number of object properties (attributes) applied
Applied/sec from inbound replication partners.

You can use the two counters to monitor how quickly changes are being applied to the
database.

Database:

Server Performance:

ﾉ Expand table

DirectoryServices\DRA Indicates the number of This counter indicates that the

Inbound Object Updates object updates received monitored server is receiving
Remaining in Packet in the most recent changes, but it is taking a long
directory replication time to apply them to the
update packet that have database. This counter should be
not yet been applied to as low as possible. If it is not, it
the local server. usually indicates that server
hardware is slowing replication.

Network:

ﾉ Expand table

Object\counter Description Guidelines

DirectoryServices\DRA Indicates the total number of bytes received per

Inbound Bytes Total/sec second through inbound replication. This number is
 Object\counter Description Guidelines

the sum of the bytes of uncompressed and

compressed data received during inbound

Testing
Scenario Two DCs were isolated (no client or other server activity) 15,000 users were
created from script with the minimal attributes populated on one DC Enabled the
connection between the two DCs.

To give an idea of rate of events logged with this level of verbosity:

A Directory Services event log configured to 100 MB in size wrapped in less than two
minutes (1 minute 27 seconds). The log contained 195,728 events. Of all events, 189,340
were event ID 1412 (attribute addition). The number of event 1412s per second:

01: 2400
02: 3570
03: 3540
04: 2160
05: 1170
06: 1890
07: 2225
08: 1435
09: 4233
10: 2817

Event ID 1365 (Object creation) was logged 6,312 times in 1 minute 27 seconds. In one
minute, 4,630 user objects were created, consisting of 138,900 attributes) or about 77
objects per second.

An understanding of NTDS performance counters is needed in order to troubleshoot

this issue effectively.

Object creations per second is obtained via the following performance counters:

NTDS / DRA Inbound Objects Applied/sec

Database adds/sec

NTDS / DRA Inbound Values (DNs only)/sec This number includes objects that
reference other objects. Values for distinguished names, such as group or
distribution list memberships, are more expensive to apply than other kinds of
 values because a group or distribution list object can include hundreds or
thousands of members. In contrast, a simple object might have only one or two
attributes. A high number from this counter might explain why inbound changes
are slow to be applied to the database. Attribute creations per second is:

NTDS / DRA Inbound Properties Applied/sec

Special Condition Frequently Encountered

Repadmin /rehost results in status 8461:

This issue occurs when the GC being rehosted is busy accepting updates for other
partitions. The sourcing of writable domain partitions including schema, configuration,
and domain partition are by nature higher priority work-items than the rehosting of a
read-only domain partition.

Repadmin /queue output should show that the request to add the partition has been
queued and will eventually be processed. However, sometimes it is necessary to use an
alternative method of partition rehost:

1. Repadmin /unhost
2. Wait for event ID 1660
3. Disable KCC connection translation
4. Repadmin /addIf the process is preempted before /add is complete, you can
disable inbound replication and use repadmin /replicate and the /readonly and
/force options to get the partition re-hosted before you re-enable inbound

replication.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory Replication Error 8606:
Insufficient attributes were given to
create an object
Article • 02/19/2024

This article provides help to troubleshoot Active Directory replication error 8606:
Insufficient attributes were given to create an object.

Applies to: Windows Server 2012 R2

Original KB number: 2028495

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Summary
This article describes the symptoms and causes of an issue in which Active Directory
replication is unsuccessful and generates error 8606: "Insufficient attributes were given
to create an object. This object may not exist because it may have been deleted." This
article also describes a resolution for this issue.

Symptoms

Symptom 1
The DCDIAG reports that the Active Directory Replications test failed with error 8606:
"Insufficient attributes were given to create an object."

Starting test: Replications

[Replications Check, <Destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (8606):
Insufficient attributes were given to create an object. This object may not exist
 because it may have been deleted and already garbage collected
The failure occurred at <date> <time>
The last success occurred at <date> <time>

Symptom 2
Incoming replication that is triggered by the Replicate Now command in the Active
Directory Sites and Services snap-in DSSITE.MSC is unsuccessful and generates the error
"Insufficient attributes were given to create an object." When you right-click a
connection object from a source DC and then select Replicate now, the replication is
unsuccessful and generates the following error: "Access is denied." Additionally, you
receive the following error message:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to
synchronize naming context <%active directory partition name%> from domain
controller <source DC> to domain controller <destination DC>:

Insufficient attributes were given to create an object. This object may not exist
because it may have been deleted and already garbage collected.

The operation will not continue

Symptom 3
Various repadmin.exe commands fail with error 8606. These commands include but are
not limited to the following:

repadmin /add repadmin /replsum

repadmin /showrepl repadmin /showrepl

repadmin /syncall

Symptom 4
Event 1988 is logged shortly after one of the following events occurs:

The first domain controller in the forest is deployed.

Any update to the partial attribute set is made.

Symptom 5
NTDS replication event 1988 may be logged in the Directory Service event log of
domain controllers that are trying to inbound-replicate Active Directory.

Type: Error
Source: NTDS Replication
Category: Replication
Event ID: 1988
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: <hostname of DC that logged event, aka the "destination" DC in the
replication attempt>
Description: The local domain controller has attempted to replicate the following
object from the following source domain controller. This object is not present on the
local domain controller because it may have been deleted and already garbage
collected.
Source domain controller:
<fully qualified GUIDED CNAME of source DC>
Object:
<DN path of live object on source DC>
Object GUID:
<object GUID of object on source DCs copy of Active Directory>

Cause
Error 8606 is logged when the following conditions are true:

A source domain controller sends an update to an object (instead of an originating

object create) that has already been created, deleted, and then reclaimed by
garbage collection from a destination domain controller's copy of Active Directory.
The destination domain controller was configured to run in strict replication
consistency.

If the destination domain controller was configured to use loose replication consistency,
the object would have been "reanimated" on the destination domain controller's copy of
the directory. Specific variations that can cause error are 8606 documented in the "More
Information" section. However, the error is caused by one of the following:

A permanently lingering object whose removal will require admin intervention

A transient lingering object that will correct itself when the source domain
controller performs its next garbage-collection cleanup. The introduction of the
first domain controller in an existing forest and updates to the partial attribute set
are known causes of this condition.
 An object that was undeleted or restored at the cusp of tombstone lifetime
expiration

When you troubleshoot 8606 errors, think about the following points:

Although error 8606 is logged on the destination domain controller, the problem
object that is blocking replication resides on the source domain controller.
Additionally, the source domain controller or a transitive replication partner of the
source domain controller potentially did not inbound-replicate knowledge of a
deleted tombstone lifetime number of days in the past.

Lingering objects may exist under the following circumstances:

As "live" objects, as CNF or conflict mangled objects "live" objects, or as CNF or
conflict mangled objects in the deleted objects container of the source domain
controller
In any directory partition except the schema partition. Lingering objects are
most frequently found in read-only domain partitions on GCs. Lingering objects
may also exist in writable domain partitions as well as the configuration
partition. The schema partition does not support deletes.
In any object class (users, computers, groups, and DNS records are most
common).

Remember to search for potentially lingering objects by object GUID versus DN

path so that objects can be found regardless of their host partition and parent
container. Searching by objectguid will also locate objects that are in the deleted
objects container without using the deleted objects LDAP control.

The NTDS Replication 1988 event identifies only the current object on the source
domain controller that is blocking incoming replication by a strict mode
destination domain controller. There are likely additional objects "behind" the
object that is referenced in the 1988 event that is also lingering.

The presence of lingering objects on a source domain controller prevents or blocks

strict mode destination domain controllers from inbound-replicating "good"
changes that exist behind the lingering object in the replication queue.

Because of the way that domain controllers individually delete objects from their
deleted object containers (the garbage-collection daemon runs every 12 hours
from the last time each domain controller last started), the objects that are causing
8606 errors on destination domain controllers could be subject to removal in the
next garbage-collection cleanup execution. Lingering objects in this class are
transient and should remove themselves in no more than 12 hours from problem
start.
 The lingering object in question is likely one that was intentionally deleted by an
administrator or application. Factor this into your resolution plan, and beware of
reanimating objects, especially security principals that were intentionally deleted.
Resolution

Resolution
1. Identify the current value for the forest-wide TombStoneLifeTime setting.

Console

repadmin /showattr "CN=Directory Service,CN=Windows

NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD"
/atts:tombstonelifetime

See the "Tombstone lifetime and replication of deletions" section in the following
article in the Microsoft Knowledge Base:
910205 Information about lingering objects in a Windows Server Active
Directory forest.

2. For each destination domain controller that is logging the 8606 error, filter the
Directory Service event log on NTDS Replication event 1988.

3. Collect metadata for each unique object that is cited in the NTDS Replication event
1988. From each 1988 event that is logged on the destination domain controller
that cites a new object, populate the following table:

ﾉ Expand table

Object Object Source Host Live or LastKnownParent IsDeleted

DN path GUID DC partition deleted? value

Columns 1 through 5 of this table can be populated by reading values directly

from fields in the NTDS Replication 1988 events that are logged in the Directory
Service event logs of the destination domain controllers that are logging either the
1988 event or the 8606 replication status.

The date stamps for LastKnownParent and IsDeleted columns can be determined
by running repadmin /showobjmeta and referencing the objectguid of the object
 that is cited in the NTDS replication 1988 event. To do this, use the following
syntax:

Console

repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID

of object cited in the 1988 event>"

The date stamp for LastKnownParent identifies the date on which the object was
deleted. The date stamp for IsDeleted tells you when the object was last deleted or
reanimated. The version number tells you whether the last modification deleted or
reanimated the object. An IsDeleteted value of 1 represents an initial delete. Odd-
numbered values greater than 1 indicate a reanimation following at least one
deletion. For example, an isDeleted value of 2 represents an object that was
deleted (version 1) and then later undeleted or reanimated (version 2). Later even-
numbered values for IsDeleted represent later reanimations or undeletes of the
object.

4. Select the appropriate action based on the object metadata cited in the 1988
event.

Error 8606 / NTDS Replication event 1988 event is most frequently caused by long-
term replication failures that are preventing domain controllers from inbound-
replicating knowledge of all originating deletes in the forest. This results in
lingering objects on one or more source domain controllers.

Review the metadata for object that is listed in the table that was created in step 4
of the "Resolution" section.

If the object in the 1988 event is either ((live on the source domain controller) but
(deleted on the destination domain controller for longer than tombstone lifetime
expiration)), see "Removing Lingering Objects" and "." Objects in this condition
must be manually removed by an administrator.

Deleted objects may have been prematurely purged from the deleted objects
container if system time jumped forward in time on the destination domain
controller. Review the "Check for Time Jumps" section.

If the object that is cited in the 1988 event exists in the deleted objects container
of the source domain controller and its delete date is right at the cusp of
tombstone lifetime expiration in such a way that the object was reclaimed by
garbage collection by one or more destination domain controllers and will be
reclaimed by garbage collection at the next garbage-collection interval on source
 domain controllers (that is, the lingering objects are transient), you have a choice.
Either wait for the next garbage collection execution to delete the object, or
manually trigger garbage collection on the source domain controller. See
"Manually starting garbage collection." The introduction of the first domain
controller, or any change in the partial attribute set, can cause this condition.

If repadmin /showobjmeta output for the object that is cited in the 1988 event has a
LastKnownParent value of 1, this indicates that the object was deleted, and an
IsDeleted value that of 2 or some other even-numbered value, and that date
stamp for IsDeleted is at the cusp of the tombstone lifetime number of days
different from the date stamp for LastKnownParent, then the object was deleted
and then undeleted / auth-restored while it was still live on the source domain
controller but already reclaimed by garbage collection by destination domain
controllers logging error 8606 / Event 1988. See Reanimations at the cusp of TSL
expiration

How to remove lingering objects

While many methods exist to remove lingering objects, there are three primary tools
commonly used: repadmin.exe, Lingering Object Liquidator (LoL) and repldiag.

Lingering Object Liquidator (LoL)

The easiest method to clean up Lingering Objects is to use the LoL. The LoL tool was
developed to help automate the cleanup process against an Active Directory Forest. The
tool is GUI-based and can scan the current Active Directory Forest and detect and
cleanup lingering objects. The tool is available on Microsoft Download Center .

Repadmin

The following two commands in repadmin.exe can remove lingering objects from
directory partitions:

repadmin /removelingeringobjects
repadmin /rehost

The repadmin /removelingeringobjects command can be used to remove lingering

objects from writable and read-only directory partitions on source domain controllers.
The syntax is as follows:

Console
 repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC>
[/ADVISORY_MODE]

Where:
<Dest_DSA_LIST> is the name of a domain controller that contains lingering objects
(such as the source domain controller that is cited in the NTDS Replication 1988 event).

<Source DSA GUID> is the name of a domain controller that hosts a writable copy of
the directory partition that contains lingering objects to which the domain controller in
<Dest_DSA_LIST> has network connectivity. The DC to be cleaned up (first DC specified
in the command) must be able to connect directly to port 389 on the DC that hosts a
writable copy of the directory partition (specified second in the command).

<NC> is the DN path of the directory partition that is suspected of containing lingering
objects, such as the partition that is specified in a 1988 event.

The repadmin /rehost command can be used to remove lingering-objects domain

controllers that host a read-only copy of a domain directory partition from domain
controllers. The syntax is as follows:

Console

repadmin /rehost DSA <Naming Context> <Good Source DSA Address>

Where:
DSA is the name of a domain controller that hosts a read-only domain directory
partition for a nonlocal domain. For example, a GC in root.contoso.com can rehost its
read-only copy of child.contoso.com but cannot rehost root.contoso.com.

<Naming Context> is the DN path of a read-only domain directory partition that is

residing in a global catalog.

<Good Source DSA Address> is the name of a domain controller that hosts a writable
copy of <Naming Context>. The domain controller must be network-available to the
DSA computer.

If the lingering object that is reported in the 1988 event is not removed by repadmin,
evaluate whether the object on the source domain controller was created in USN gap, or
whether the objects originating domain controller does not exist in the source domain
controller's up-to-dateness vector.

Repldiag
 ７ Note

Lingering objects can also be removed by using repldiag.exe. This tool automates
the repadmin /removelingeringobjects process. Removing lingering objects from a
forest with repldiag is as simple as running repldiag /removelingeringobjects .
However, it is usually best to exercise some control over the process in larger
environments. The option /OverRideReferenceDC allows you to select which DC is
used for cleanup. The option /outputrepadmincommandlinesyntax allows you to see
what a forest-wide cleanup looks like using repadmin.

Launch the following TechNet on-demand lab for guided troubleshooting practice of
this and other AD replication errors:

In the lab, you use both repadmin and repldiag.exe to remove lingering objects
Troubleshooting Active Directory Replication Errors
In this lab, you'll walk through the troubleshooting, analysis and implementation phases
of commonly encountered Active Directory replication errors. You'll use a combination
of ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five DC, three-
domain environment. AD replication errors encountered in the lab include -2146893022,
1256, 1908, 8453 and 8606."

Monitoring Active Directory replication health daily

If error 8606 / Event 1988 was caused by the domain controller's failing to replicate
Active Directory changes in the last tombstone lifetime number of days, make sure that
Active Directory replication health is being monitored on a day-to-day basis going
forward. Replication health may be monitored by using a dedicated monitoring
application or by viewing the output from the one inexpensive but effective option to
run repadmin /showrepl * /csv command in a spreadsheet application such as
Microsoft Excel. (See "Method 2: Monitor replication by using a command line" in
Microsoft Knowledge Base article 910205).

Domain controllers that have not inbound-replicated in 50 percent of tombstone

lifetime number of days should be put in a watch list that receive priority admin
attention to make replication operational. Domain controllers that cannot be made to
successfully replicate should be force-demoted if they have not replicated within 90
percent of TSL.

Replication failures that appear on a destination domain controller may be caused by

the destination domain controller, by the source domain controller, or by the underlying
network and DNS infrastructure.
Check for time jumps
To determine whether a time jump occurred, check date stamps in Event and diagnostic
logs (Event Viewer, repadmin /showreps , netlogon logs, dcdiag reports) on destination
domain controllers that are logging error 8606 / NTDS Replication 1988 events for the
following:

Date stamps that predate the release of an operating system (for example, date
stamps from CY 2003 for an OS released in CY 2008)
Date stamps that predate the installation of the operating system in your forest
Date stamps in the future
Having no events that are logged in a given date range

Microsoft Support teams have seen system time on production domain controllers
incorrectly jump hours, days, weeks, years, and even tens of years in the past and future.
If system time was found to be inaccurate, you should correct it and then try to
determine why time jumped and what can be done to prevent inaccurate time going
forward vs. just correcting the bad time. Possible questions include the following:

Was the forest root PDC configured by using an external time source?
Are reference online time sources available on the network and resolvable in DNS?
Was the Microsoft or third-party time service running and in an error-free state?
Are domain controller role computers configured to use NT5DS hierarchy to
source time?
Was time rollback protection that is described in Microsoft Knowledge Base article
884776 in place?
Do system clocks have good batteries and accurate time in the BIOS on domain
controllers on virtual host computers?
Are virtual host and guest computers configured to source time according to the
hosting manufacturer's recommendations?
Microsoft Knowledge Base article 884776 documents steps to help protect
domain controllers from "listening" to invalid time samples. More information
about MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in the
W32Time Blog post Windows Time Service .

Check for lingering objects by using repadmin /removelingeringobjects /advisorymode ,

and then remove them as required.

Relax "Allow replication with Divergent and corrupt partner" as required.

How to manually start garbage collection

Several options exist to manually trigger garbage collection on a specific domain
controller:

Run "repadmin /setattr "" "" doGarbageCollection add 1"

Run LDIFDE /s <server> /i /f dogarbage.ldif where dobarbage.ldif contains the text:

dn:
changetype: modify
replace: DoGarbageCollection
dogarbagecollection: 1
-

７ Note

The final "-" character is a required element of the .ldif file.

Reanimations at the cusp of TSL expiration

For this condition to exist, repadmin /showobject "<GUID=object guid for object in 1988
event>" should report that the object is "not found" on the destination domain

controller but is live on the source domain controller and is either a deleted or a
nondeleted object.

A review of key fields from repadmin /showobjmeta on the source domain controller
should report that the following are true: LastKnownParent has a value of 1, and its date
stamp is at the cusp of TSL days in the past. Its date stamp indicates the delete date of
the object.

IsDeleted has a version number of 2 (or another even-numbered value), where version 1
defined the original deletion and version 2 is the restore / reanimation. The date stamp
for "isDeleted=2" should be ~ TSL number of days later than the last change date for
LastKnownParent.

Evaluate whether the object in question should remain a live object or a deleted object.
If LastKnownParent has a value of 1, something or someone deleted the object. If this
was not an accidental deletion, chances are good that the object should be deleted from
any source domain controllers that have a live copy of the object.

If the object should exist on all replicas, the options are as follows:
 Enable loose replication on strict mode destination domain controllers that do not
have the object.
Force-demote the domain controllers that have already garbage collected the
object.
Delete the object and then re-create it.

More information
Launch the following TechNet on-demand lab for guided troubleshooting practice of
this and other AD replication errors:

Troubleshooting Active Directory Replication Errors

In this lab, you will walk through the troubleshooting, analysis, and implementation
phases of commonly encountered Active Directory replication errors. You will use a
combination of ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five
DC, three-domain environment. AD replication errors encountered in the lab include
-2146893022, 1256, 1908, 8453 and 8606."

Causes of lingering objects

Cause 1: The source domain controller sends updates to objects

that have already been reclaimed by garbage collection on the
destination domain controller because the source domain
controller either was offline or failed replication for TSL elapsed
number of days

The CONTOSO.COM domain contains two domain controllers in the same domain.
Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers.
DC2 experiences a motherboard failure. Meanwhile, DC1 makes originating deletes for
stale security groups daily over the next 90 days. After it is offline for 90 days, DC2
receives a replacement motherboard, powers up, and then originates a DACL or SACL
change on all user accounts before it inbound-replicates knowledge of originating
deletes from DC1. DC1 logs 8606 errors for updates security groups that are purged on
DC1 for the first 30 days that DC2 was offline.

Cause 2: The source DC sends updates to objects at the cusp of TSL

expiration that have already been reclaimed by garbage collection
by a strict mode destination DC
The CONTOSO.COM domain contains two domain controllers in the same domain.
Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers.
DC1 and DC2 replicate every 24 hours. DC1 originates-deletes daily. DC1 is in-place
upgraded. This stamps new attribute on all objects in the configuration and writable
domain partitions. This includes objects that are currently in the deleted objects
container. Some of them were deleted 60 days ago and are now at the cusp of
tombstone expiration. DC2 reclaims some objects by garbage collection that were
deleted TSL days ago before the replication schedule opens with DC2. Error 8606 is
logged until DC1 reclaims the blocking objects by garbage collection.

Any updates to the partial attribute set can cause temporary lingering objects that will
clear themselves up after source domain controllers garbage-collect deleted objects at
the cusp of TSL expiration (for example, the addition of the first W2K8 R2 domain
controller to an existing forest).

Cause 3: A time jump on a destination domain controller

prematurely speeds up the garbage collection of deleted objects
on a destination domain controller
The CONTOSO.COM domain contains two domain controllers in the same domain.
Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers.
DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. The reference time
source that is used by DC1 (but not DC2) rolls forward to calendar year 2039. This
causes DC2 to also use a system time in CY2039. This causes DC1 to prematurely delete
objects that are deleted today from its deleted objects container. Meanwhile, DC2
originates changes to attributes on users, computers, and groups that are live on DC2
but deleted and now prematurely garbage collected on DC1. DC1 will log error 8606
when it next inbound-replicates changes for the premature deleted objects.

Cause 4: An object is reanimated at the cusp of TSL expiration

The CONTOSO.COM domain contains two domain controllers in the same domain.
Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers.
DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. An OU that contains
users, computers, and groups are accidentally deleted. A system state backup that is
made at the cusp of TSL in the past is auth-restored on DC2. The backup contains
objects that are live on DC2 but already deleted and reclaimed by garbage collection on
DC1.

Cause 5: A USN bubble is triggered the logging of the 8606

Say that you create an object in a USN bubble in such a way that it does not outbound-
replicate because the destination domain controller "thinks" it has the object because of
the bubble. Now, after the bubble closes, and after changes start to replicate again, a
change is created for that object on the source domain controller and is displayed as a
lingering object to the destination domain controller. The destination controller logs
event 8606.

Requirements for end-to-end replicate knowledge of

originating deletes
Active Directory domain controllers support multi-master replication where any domain
controller (that holds a writable partition) can originate a create, change, or delete of an
object or attribute (value). Knowledge of object / attribute deletes are persisted by the
originating domain controller and any domain controller that has incoming replicated
knowledge of an originating delete for TSL number of days. (See Microsoft Knowledge
Base articles 216996 and 910205 )

Active Directory requires end-to-end replication from all partition holders to transitively
replicate all originating deletes for all directory partitions to all partition holders. Failure
to inbound-replicate a directory partition in a rolling TSL number of days results in
lingering objects. A lingering object is an object that was intentionally deleted by at
least one domain controller but that incorrectly exists on destination domain controllers
that did not inbound-replicate the transient knowledge of all unique deletions.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication error 8456
or 8457: The source | destination server
is currently rejecting replication
requests
Article • 04/10/2024

This article describes the symptoms, cause, and resolution steps for situations where
Active Directory operations fail with error 8456 or 8457.

Applies to: Windows Server (All supported versions)

Original KB number: 2023007

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Symptoms
Active Directory operations fail with error 8456 or 8457: The source | destination server
is currently rejecting replication requests.

1. The DCPROMO promotion of a new domain controller in an existing forest fails

with the error: The source server is currently rejecting replication requests.

Dialog title text: Active Directory Installation Wizard Dialog message text:

The operation failed because: Active Directory could not transfer the remaining
data in directory partition <directory partition DN path> to domain controller
<destination DC>. "The source server is currently rejecting replication
requests."

2. DCDIAG reports the error: The source server is currently rejecting replication
requests or The destination server is currently rejecting replication requests.

Testing server: Default-First-Site-Name<DC NAME>

Starting test: Replications
 * Replications Check
[Replications Check,<DC NAME>] A recent replication attempt failed:
From IADOMINO to <DC NAME>
Naming Context: DC=<DN path of partition>
The replication generated an error (8456):
The source server is currently rejecting replication requests.
The failure occurred at <Date> <Time>.
The last success occurred at <Date> <time>.
957 failures have occurred since the last success.
Replication has been explicitly disabled through the server options

Testing server: Default-First-Site-Name<DC NAME>

Starting test: Replications
* Replications Check
[Replications Check,<DC NAME>] A recent replication attempt failed:
From IADOMINO to <DC NAME>
Naming Context: DC=<DN path of partition>
The replication generated an error (8457):
The destination server is currently rejecting replication requests.
The failure occurred at <Date> <Time>.
The last success occurred at <Date> <time>.
957 failures have occurred since the last success.
Replication has been explicitly disabled through the server options

3. REPADMIN indicates that incoming and outgoing Active Directory replication may
be failing with the error: The source | destination server is currently rejecting
replication.

DC=Contoso,DC=COM
<site name><dc name> via RPC
DC object GUID: <objectguid of source DCs NTDS settings object>
Last attempt @ <date> <time> failed, result 8457 (0x2109):
The destination server is currently rejecting replication requests.

DC=Contoso,DC=COM
<site name><dc name> via RPC
DC object GUID: <objectguid of source DCs NTDS settings object>
Last attempt @ <date> <time> failed, result 8456 (0x2108):
The source server is currently rejecting replication requests.

７ Note
 REPADMIN commands may display both the hexadecimal and the decimal
equivalent for the currently rejecting replication error.

4. Event sources and event IDs that indicate that a USN rollback has occurred include
but are not limited to the following.

ﾉ Expand table

Event source Event Event string

ID

NTDS KCC 1308 The Knowledge Consistency Checker (KCC) has

detected that successive attempts to replicate
with the following domain controller has
consistently failed.

NTDS KCC 1925 The attempt to establish a replication link for

the following writable directory partition failed.

NTDS KCC 1926 The attempt to establish a replication link to a

read-only directory partition with the following
parameters failed

NTDS Replication 1586 The Windows NT 4.0 or earlier replication

checkpoint with the PDC emulator master was
unsuccessful. A full synchronization of the
security accounts manager (SAM) database to
domain controllers running Windows NT 4.0
and earlier might occur if the PDC emulator
master role is transferred to the local domain
controller before the next successful
checkpoint. The checkpoint process will be tried
again in four hours.

NTDS Replication 2023 The local domain controller was unable to

replicate changes to the following remote
domain controller for the following directory
partition.

Microsoft-Windows- 2095 During an Active Directory Domain Services

ActiveDirectory_DomainService replication request, the local domain controller
(DC) identified a remote DC which has received
replication data from the local DC by using
already acknowledged USN tracking numbers.

Microsoft-Windows- 2103 The Active Directory Domain Services database

ActiveDirectory_DomainService was restored by using an unsupported
restoration procedure. Active Directory Domain
Services will be unable to log on users while
 Event source Event Event string
ID

this condition persists. Therefore, the Net

Logon service has paused.

Where embedded status codes 8456 and 8457 map to the following.

ﾉ Expand table

Decimal Hexadecimal Error string

error error

8456 2108 The source server is currently rejecting replication

8457 2109 The destination server is currently rejecting

replication

5. NTDS General Event 2013 may be logged in the Directory Services event log. This
indicates that a USN rollback occurred because of an unsupported rollback or
restore of the Active Directory Database.

Event Type: Error

Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: <date>
Time: <time>
User: <user name>
Computer: <computer name>
Description: The Active Directory database has been restored by using an
unsupported restoration procedure. Active Directory will be unable to log on
users while this condition persists. As a result, the Net Logon service has
paused. User Action See previous event logs for details. For more information,
visit the Help and Support Center at https://support.microsoft.com .

6. NTDS General Event 1393 may be logged in the Directory Services event log. This
indicates that the physical or virtual drive that is hosting the Active Directory
database or log files lacks sufficient free disk space:

Event Type: Error

Event Source: NTDS General
Event Category: Service Control
Event ID: 1393
 Date: <date>
Time: <time>
User: <user name>
Computer: <computer name> Description:
Attempts to update the Directory Service database are failing with error 112.
Since Windows will be unable to log on users while this condition persists, the
NetLogon service is being paused. M ake sure that sufficient free disk space is
available on the drives where the directory database and log files reside.

Cause
Incoming or outgoing replication was automatically disabled by the operating system
because of multiple root causes.

Three events that disable inbound or outbound replication include:

A USN rollback occurred (NTDS General Event 2103).

The hard disk is full (NTDS General Event 1393).
A corrupt UTD vector is present (Event 2881).

The operating system automatically makes four configuration changes when one of
three conditions occurs. The four configuration changes are as follows:

1. Incoming Active Directory replication is disabled.

2. Outgoing Active Directory replication is disabled.
3. DSA not writable is set to a nonzero value in the registry.
4. The NETLOGON service status is changed from running to paused.

The dominant root cause for this error condition is a USN rollback discussed in A
Windows Server domain controller logs Directory Services event 2095 when it
encounters a USN rollback .

Do not assume that any nonzero value for DSA not writable or that a source or
destination server is currently rejecting replication requests during DCPROMO / AD
Replication definitively means that a USN rollback has occurred and that such domain
controllers implicitly have to be force-demoted or force-repromoted. Demotionmaybe
the correct option. However, it may be excessive when the error is caused by insufficient
free disk space.

Resolution
1. Check the value for DSA not writable.
For each domain controller that is logging the 8456 or 8457 error, determine
whether one of the three triggering events automatically disabled incoming or
outgoing Active Directory Replication by reading the value for " DSA not writable"
from the local registry.

When replication is automatically disabled, the operating system writes one of four
possible values to DSA not writable:

Path:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Setting: DSA not writable

Type: Reg_dword
Values:
#define DSA_WRITABLE_GEN 1
#define DSA_WRITABLE_NO_SPACE 2
#define DSA_WRITABLE_USNROLLBCK 4
#define DSA_WRITABLE_CORRUPT_UTDV 8

A value of 1 can be written only when the forest version is incompatible with the
OS (for example, the W2K DC is promoted into a Windows Server 2003 forest
functional level forest or the like).

A value of 2 means that the physical or virtual drive that is hosting the Active
Directory database or log files lacks sufficient free disk space.

A value of 4 means that a USN rollback occurred because the Active Directory
database was incorrectly rolled back in time. Operations that are known to cause a
USN rollback include the following:

The booting from previously saved virtual machine snapshots of domain

controller role computers on Hyper-V or VMWARE hosts.
Incorrect physical-to-virtual (P2V) conversions in forests that contain more
than one domain controller.
Restoring DC role computers by using imaging products such as Ghost.
Rolling the contents of a partition that is hosting the active directory
database back in time by using an advanced disk subsystem.

A value of 8 indicates that the up-to-dateness-vector is corrupted on the local DC.

Technically, DSA not writable could consist of multiple values. For example, a
registry value of 10 would indicate insufficient disk space and a corrupted UTD.
Typically, a single value is written to DSA not writable.
 ７ Note

It is common for support professionals and administrators to partly disable

the replication quarantine by enabling outgoing replication, by enabling
incoming replication, by changing the startup value for the NETLOGON
service from disabled to automatic, and by starting the NETLOGON service.
Therefore, the full quarantine configuration may not be in place when it is
examined.

2. Check the Directory Service event log for quarantine events.

Assuming the Directory Service event log has not wrapped, you may find one or
more related events logged in the Directory Service event log of a domain
controller that is logging the 8456 or 8457 error.

ﾉ Expand table

Event Details

NTDS The Active Directory database was restored by using an unsupported

General restoration procedure. Active Directory will be unable to log on users while
2103 this condition persists. Therefore, the Net Logon service has paused. User
Action See previous event logs for more information.

NTDS There is insufficient space on the disk.

General
Event 1393

Event 2881 Not applicable

3. Perform the recovery based on the value of DSA not writable or on events that are
logged on the system:

If DSA not writable equals 4 or if NTDS General Event 2103 is logged,

perform the recovery steps for a USN Rollback. For more information, see A
Windows Server domain controller logs Directory Services event 2095 when it
encounters a USN rollback .

If DSA not writable equals 2 or if NTDS General event 1393 is logged, check
for sufficient free disk space on the physical and virtual partitions that are
hosting the Active Directory database and log files. Free up space as required.

If DSA not writable equals 8, demote and then repromote the domain
controller before it can replicate its bad value to other domain controllers in
 the forest.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Ntdsutil to find and clean up
duplicate security identifiers
Article • 02/19/2024

This article discusses how to use Ntdsutil to find and clean up duplicate security
identifiers.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 816099

Summary
This article describes how to check for and clean up or remove duplicate security
identifiers (SIDs) in the SAM database. Every security account, such as a user, group, or
computer, has a unique SID. Access permissions are granted or denied to SIDs for
resources, such as files, folders, printers, Microsoft Exchange mailboxes, Microsoft SQL
Server databases, objects that are stored in Active Directory, and any data that is
protected by the Windows Server security model.

A SID contains header information and a set of relative identifiers that identify the
domain and the security account. In a domain, each domain controller can create
accounts and issue a unique SID to every account. Every domain controller maintains a
pool of relative IDs that is used to create SIDs. After 80 percent of the relative ID pool is
consumed, the domain controller requests a new pool of relative identifiers from the
relative ID operations master. Make sure the same pool of relative IDs is never allocated
to different domain controllers, and prevents the allocation of duplicate SIDs. However,
because it is possible (but rare) for a duplicate relative ID pool to be allocated, you have
to identify those accounts that have been issued duplicate SIDs to prevent incorrect
security from being applied.

Duplicate relative ID pools may occur if the administrator seizes the relative ID master
role (RID master), while the original RID master is operational but temporarily
disconnected from the network. In typical practice, the RID master role is assumed by
just one domain controller after one replication cycle. However, before the role
ownership is resolved, two different domain controllers might each request a new
relative ID pool and be allocated the same relative ID pool.

Start Ntdsutil
To start Ntdsutil, follow these steps:

1. Select Start > Run.

2. In the Open box, type ntdsutil, and then press Enter. To access Help at any time,
type ? at the command prompt, and then press Enter.

Look for a duplicate SID

To look for a duplicate SID, follow these steps:

1. At the Ntdsutil command prompt, type security account management, and then
press Enter.

2. To connect to the server that stores your Security Account Maintenance (SAM)
database, type connect to serverDNSNameOfServer at the SAM command prompt,
and then press Enter.

3. At the SAM command prompt, type check duplicate sid, and then press Enter.

７ Note

A display of duplicates appears.

Clean up a duplicate SID

1. At the Ntdsutil command prompt, type security account management, and then
press Enter.

2. Connect to the server that stores your Security Account Maintenance (SAM)
database. At the SAM command prompt, type 'connect to
serverDNSNameOfServer' and then press Enter.

3. At the SAM command prompt, type cleanup duplicate sid, and then press Enter.

７ Note

Ntdsutil confirms the removal of the duplicate.

4. At the SAM command prompt, type q, and then press Enter.

5. After finished using Ntdsutil, type q, and then press Enter.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 84 occurs in Active Directory
Rights Management Services (AD RMS)
in Windows Server
Article • 02/19/2024

This article provides help to fix an issue in which event ID 84 is logged in Active
Directory Rights Management Services (AD RMS) in Windows Server.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 4038927

Symptoms
On a Windows Server-based computer that has Active Directory Rights Management
Services (AD RMS) installed, you receive the following event:

Log Name: Application

Source: Active Directory Rights Management Services
Date: Date/Time
Event ID: 84
Task Category: Certification
Level: Error
Keywords: Classic
User: N/A
Computer: ipc01.treyresearch.net
Description:
This Active Directory Rights Management Services (AD RMS) cluster cannot perform
an operation on one of the AD RMS databases. Ensure that all AD RMS databases
are operating correctly on the network and that the AD RMS service account has
read and write permissions to the databases.

Parameter Reference
Context: Pipeline[ComponentBase.LogResults]
RequestId:RequestID
HelpLink.ProdName: Microsoft SQL Server
HelpLink.ProdVer: 10.50.4000
HelpLink.EvtSrc: MSSQLServer
HelpLink.EvtID: 8115
HelpLink.BaseHelpUrl: https://go.microsoft.com/fwlink
HelpLink.LinkId: 20476
SqlError-1.Class: 0
SqlError-0.State: 1
SqlError-1.Server: sql01.treyresearch.net ,1441
SqlError-0.Message: Arithmetic overflow error converting IDENTITY to data type
smallint.
SqlError-1.Number: 3606
SqlError-0.Number: 8115
SqlError-1.Message: Arithmetic overflow occurred.
SqlError-1.State: 0
SqlError-0.Server: sql01.treyresearch.net ,1441
SqlError-0.Class: 16

Microsoft.RightsManagementServices.LowSeveritySqlException
Message: The Database Engine threw this exception in response to an error that can
be corrected by the user, such as a missing database object or entity, possible data
inconsistency, transaction deadlock, security setting problems, or SQL command
syntax error. Please examine the SqlError details for more information.
HelpLink.ProdName: Microsoft SQL Server
HelpLink.ProdVer: 10.50.4000
HelpLink.EvtSrc: MSSQLServer
HelpLink.EvtID: 8115
HelpLink.BaseHelpUrl: https://go.microsoft.com/fwlink
HelpLink.LinkId: 20476
Context: ComponentBase.LogResults
SqlError-1.Class: 0
SqlError-0.State: 1
SqlError-1.Server: sql01.treyresearch.net ,1441
SqlError-0.Message: Arithmetic overflow error converting IDENTITY to data type
smallint.
SqlError-1.Number: 3606
SqlError-0.Number: 8115
SqlError-1.Message: Arithmetic overflow occurred.
SqlError-1.State: 0
SqlError-0.Server: sql01.treyresearch.net ,1441
SqlError-0.Class: 16
+ System.Data.SqlClient.SqlException
+ Message: Arithmetic overflow error converting IDENTITY to data type smallint.
Arithmetic overflow occurred.
+ HelpLink.ProdName: Microsoft SQL Server
 + HelpLink.ProdVer: 10.50.4000
+ HelpLink.EvtSrc: MSSQLServer
+ HelpLink.EvtID: 8115
+ HelpLink.BaseHelpUrl: https://go.microsoft.com/fwlink
+ HelpLink.LinkId: 20476
+ Context: ComponentBase.LogResults

Cause
This issue occurs because the AD RMS logging process does not log an event to the
logging database.

There are two tables in the logging database that refer to a UserAgentId value. Both the
dbo.UserAgent and the dbo.ServiceRequest tables have a UserAgentId column. These
columns are both of data type smallint. As soon as the UserAgentId value exceeds the
maximum value (~32,767), the logging database cannot update. When a transaction
does not log, RMS will roll back the request and throw an error.

More information
When requesting a license from AD RMS, clients are passing agent strings with the basic
information about the requesting application. The dbo.UserAgent table only stores
unique agent strings.

Originally, the MSIPC clients just passed in versions of OS, application, MSIPC, and
architecture. The table in which the strings are stored only keeps unique entries. There
should not be lots of unique strings across the user base.

SQL

MSIPC;version=1.0.2191.0;AppName=EXCEL.EXE;AppVersion=16.0.7369.2127;AppArch
=x86;OSName=Windows;OSVersion=10.0.10586;OSArch=amd64

At some point, the MSIPC client started including the process ID (PID) to that user agent
string. This makes every string unique.

SQL

MSIPC;version=1.0.2456.0;AppName=EXCEL.EXE;AppVersion=15.0.4919.1000;AppArch
=x86;PID=13660;OSName=Windows;OSVersion=6.1.7601;OSA
Therefore, the table that should not have terribly many unique strings to store now has
many thousands.

Workaround
To work around this issue, disable logging on the AD RMS cluster:

Resolution
To resolve this issue, change the data type of the columns from smallint to int (integer).
To do this, follow these steps:

７ Note

A large logging database (DB) may take a long time to alter and may cause SQL
performance issues. Therefore, we recommend that you back up the SQL DB from
the production SQL instance and restore it on a nonproduction SQL location. After
that, you can perform the database alteration on the nonproduction SQL location,
and then replace the production DB.
 1. Back up the AD RMS logging database.

2. Collect the SQL information.

The AD RMS logging database name

The Dbo.UserAgent key name

3. Generate the script (see the following sample).

Sample script

７ Note

Edit the database name and the UserAgent table key value to reflect the target
environment.

SQL

/***************************************************************************
****
THIS TOOL AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
****************************************************************************
***/
use [DRMS_Logging_ipc_treyresearch_net_443]
go

ALTER TABLE [dbo].[ServiceRequest] drop CONSTRAINT

 [FK_CLIENTINFOID_ServiceRequest_UserAgent]
GO

Alter table [dbo].[ServiceRequest] alter COLUMN [UserAgentId] int

GO

ALTER TABLE [dbo].[UserAgent] DROP CONSTRAINT [PK__UserAgen__UserAgentId]

GO

Alter table [dbo].[UserAgent] alter COLUMN [UserAgentId] int

GO

Alter table [dbo].[UserAgent] ADD PRIMARY KEY (UserAgentId)

GO

ALTER TABLE [dbo].[ServiceRequest] WITH CHECK ADD CONSTRAINT

[FK_CLIENTINFOID_ServiceRequest_UserAgent] FOREIGN KEY([UserAgentId])
REFERENCES [dbo].[UserAgent] ([UserAgentId])
GO

ALTER TABLE [dbo].[ServiceRequest] CHECK CONSTRAINT

[FK_CLIENTINFOID_ServiceRequest_UserAgent]
GO

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot promote a Windows Server
domain controller to be a global catalog
server
Article • 02/19/2024

This article provides solutions to an issue where you can't promote a Windows Server
domain controller to be a global catalog server.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 889711

Symptoms
You cannot promote a Microsoft Windows Server domain controller to be a global
catalog server. After you try to assign the role of global catalog server to the Windows
Server domain controller by clicking the Global Catalog check box, the domain
controller is not promoted to be a global catalog server. Information events that are
similar to the following may be logged repeatedly in the Directory Services log.

Event 1559

Event 1578

Event 1801

If you enable diagnostic logging for the Knowledge Consistency Checker (KCC) to level
1, the following event is logged.

Additional symptoms
When you type repadmin /showrepl at the command line of the Windows Server domain
controller, one or more of the domains may not appear.

When you try to add a connection by using the naming context of the missing domain,
you may receive the following error message:

Error number: 8440.

The naming context specified for this replication operation is invalid.

Cause
This problem occurs when the domain-naming update for the domain has not reached
the domain controller that is experiencing the problem. Or, the domain-naming update
for a domain that is newly promoted may not have reached any domain controllers
outside that domain.

You can verify whether the domain-naming update has reached all the domain
controllers by modifying the dumpDatabase attribute on the domain controller that is
experiencing the problem. For more information, click the following article number to
view the article in the Microsoft Knowledge Base:

315098 How to use the online dbdump feature in Ldp.exe

In the dump file that you create, look for the cross-reference record for the domain. This
cross-reference record has an object class 196619. Locate the record that the object
class 196619 points to. Then, make sure that the object class that is contained in the
record has an assigned GUID.

In the following example, object 5070 references object 5072. However, object 5072 is
not assigned a GUID:

5070 4111 1 1459 true 3 DOMAIN DOMAIN 5072 196619 - 6f73dba6-33e1-41e5-

9330-c09a60a37942 4
objectclass: 196619, 65536
5071 2 2 - false <DateTime> - 1376281 com com - - - - -
5072 5071 5 - false <DateTime> - 1376281 domain domain

Resolution
To resolve this problem, use one of the following methods.

Method 1
If one or two domain controllers experience the problem, and other domain controllers
in the same domain do not experience the problem, you must demote and then
promote the domain controllers that are experiencing the problem. To do this, follow
these steps:

1. Log on to the Windows Server domain controller by using an account that has
domain administrator permissions.
2. Click Start, click Run, type dcpromo, and then click OK.
 3. Follow the instructions in the wizard to demote the domain controller.
4. After you demote the domain controller, restart the Windows Server computer.
5. Click Start, click Run, type dcpromo, and then click OK.
6. Follow the instructions in the wizard to promote the Windows Server domain
controller.

Method 2
You must rebuild the domain that is mentioned in the event descriptions if one of the
following conditions is true:

No domain controllers in the domain received the update.

The domain controllers that reside outside the domain that was reported in the
event messages did not receive the update.

More information
Event 1119 may be logged in the Directory Services log on the domain controller. This
event may be logged after you assign the role of global catalog server to the domain
controller, and after the account and the schema information is replicated to the new
global catalog server.

The event description states that the computer is identified as a global catalog server. To
confirm that the domain-naming master is a global catalog server, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. Type nltest /dsgetdc : domain_name /server: server_name, and then press ENTER.

3. Verify that the GC flag is present on the server.

For example, when you type the command, you receive a message that is similar to the
following if the GC flag is present:

DC: \\Server_Name

Address: \\IP Address

Dom Guid: <GUID>

Dom Name: Domain_name

Forest Name: Domain_name.com

 Dc Site Name: Default-First-Site-Name

Our Site Name: Default-First-Site-Name

Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE

The command completed successfully

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you attempt to create a DFS
namespace: The namespace cannot be
queried. The RPC server is unavailable
Article • 02/19/2024

This article provides a solution to an error that occurs when you create a DFS
namespace.

Applies to: Windows Server 2012 R2

Original KB number: 2021914

Symptoms
You may receive the following error when attempting to create a DFS namespace on a
Windows Server 2008 computer:

The namespace cannot be queried. The RPC server is unavailable.

This issue is typically seen in an environment using a third-party DNS server.

Cause
This error can occur when no DomainDNSName records are registered for the domain.
These records are updated by the Netlogon service on domain controllers. These are the
same as parent A records in domain's forward lookup zone.

The following documentation indicates these records are not a requirement and are only
used for DNS clients that do not understand SRV records:
How DNS Support for Active Directory Works.

DnsDomainName:

Enables a non-SRV-aware client to locate any domain controller in the domain by

looking up an A record. A name in this form is returned to the LDAP client through an
LDAP referral. A non-SRV-aware client looks up the name; an SRV-aware client looks up
the appropriate SRV resource record.

In a network trace, you will see a DNS lookup for the DomainDNSname A record and the
DNS server will respond with the SOA record if these A records do not exist.
DNS lookup query:

Dns: QueryId = 0x887C, QUERY (Standard query), Query for adatum.com of type
Host Addr on class Internet
QRecord: adatum.com of type Host Addr on class Internet

Response with the SOA record:

Dns: QueryId = 0x887C, QUERY (Standard query), Response - Success

QRecord: adatum.com of type Host Addr on class Internet
AuthorityRecord: adatum.com of type SOA on class Internet: PrimaryNameServer:
adadc1.adatum.com, AuthoritativeMailbox: hostmaster.adatum.com

Resolution
Update the A records on the DNS server, or create a HOSTS file on the Windows Server
2008 computer that includes the fully qualified name and the IP addresses of the
domain controller.

Sample HOSTS file:

adatum.com 192.168.2.10
adatum.com 192.168.3.10
adatum.com 192.168.4.10

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You may experience problems when you
rename sites in the Active Directory
forest
Article • 02/19/2024

This article describes the problems that you may experience when you rename sites in
the Active Directory forest.

Applies to: Windows Server 2012 R2

Original KB number: 920718

More information
When you rename a site in the Active Directory forest, the following events occur in the
background:

1. The site name change is replicated in the configuration naming context (NC)
throughout the forest.
2. When the site name change is replicated on a local domain controller, the Net
Logon service looks up its subnet-to-site mapping table. Thereafter, the Net Logon
service informs the client computers about the new site name.
3. The Net Logon service on the domain controller then registers its new site-specific
domain controller Service location (SRV) records with its authoritative Domain
Name System (DNS) server.
4. The DNS server writes the new domain controller records to the zone. This new
information is then replicated to other DNS servers based on the DNS or Active
Directory replication schedule.
5. The client computers receive the new site name from the domain controller. The
client computers then use this new site name in the DNS queries to look for
domain controllers.
6. The Distributed File System (DFS) server service keeps caches of client-to-site and
server-to-site mappings. These caches are named "client site cache" and "target
site cache." These caches are refreshed every 12 hours, but the caches are only
reliably present after 24 hours.

Because of the different time intervals that are used to update site-related information,
you may experience the following problems:
When the client computers are informed about the new site name in step 2, their
DNS server may not yet have the new record registrations and will therefore return
an error. The client computers will then query for records that aren't site-specific.
The domain controllers that are returned from this query may only have a weak
network link to the client computer. Therefore, the client computer experiences
poor performance. The effect of this problem depends on the following:

The replication delay of the site information in the Configuration NC

The delay that you experience in obtaining the new DNS records that are
propagated to all DNS servers

To force the Net Logon service to immediately register its DNS records, you can
run the nltest /dsregdns command at the command prompt.

７ Note

The Nltest tool can be obtained from the Microsoft Windows Server 2003
support tools.

To speed up adoption of new sites especially for System Volume (SYSVOL)

access, you can use the logon server as the preferred DFS server.

When client computers search for domain-based DFS volumes, the DFS namespace
servers or domain controllers examine the IP address of the client computers and
their local site information. When the DFS namespace servers or domain
controllers examine the IP address, they can determine the site that the client
computers are in. You can also perform this mapping from the client site cache.
DFS may run a query for the best alternative site by using the Windows Server
2003 closest site selection mode. The DFS server then examines the target site
cache to find the servers for the site that the client computer is in, and the next
best sites. Because of the delay to update the caches, the DFS server may not find
the new site names in the target site cache. The DFS server then returns an
incorrectly ordered list of servers to the client computer. Therefore, the client
computer may contact slow servers for files. This causes poor performance.

If the site information is completely replicated in Active Directory and DNS, you
may restart all DFS namespace servers or domain controllers so that they obtain
the latest server-to-site mapping.

For more information about DFS, visit the following Microsoft Web site:

Distributed File System

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Kerberos Forest Search Order may not
work in an external trust and event ID 17
is returned
Article • 02/19/2024

This article discusses a situation where Kerberos Forest Search Order (KFSO) doesn't
work in an external trust.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1
Original KB number: 2977475

Symptoms
In Windows Server 2008 R2 and later versions of Windows Server, the following Group
Policy settings can be used to configure KFSO:

Computer Configuration \ Administrative Templates \ System \ Kerberos \ Use Forest

Search Order

Computer Configuration \ Administrative Templates \ System \ KDC \ Use Forest

Search Order

With these settings configured, Kerberos authentication may work in external trusts in a
single-domain forest environment. However, it may fail when the specified forest
contains multiple domains.

In this situation, InitializeSecurityContext may return "SEC_E_TARGET_UNKNOWN."

Additionally, the following event may be logged.

Cause
The KFSO feature offers the convenience of allowing for short name (host name) service
principal name (SPN) resolution in a forest trust environment instead of offering the
support of Kerberos authentication over external trusts.

If Kerberos authentication is required, then a forest trust is necessary. On an external

trust, you have to change the application to use FQDN server names and three-part
SPNs. For more information, see Technologies for Federating Multiple Forests .
When FQDN names are used, the forest trust object can offer SPN routing according to
the UPN/SPN suffix provided in the request so that the Key Distribution Center (KDC)
knows the next hop in the Kerberos referral procedure.

More information
In an external trust environment that has KFSO configured, the KDC, or the Kerberos
client tries to append the specified suffix to search, and then it issues a DsCrackNames
request against the target forest in order to resolve the requested SPN. However, the
DsCrackNames request may try to connect to any global catalog in the target forest. If
the request contacts the domain controller in the directly trusted domain, Kerberos
authentication may be successful. If the request contacts a domain controller in another
domain, Kerberos authentication may be unsuccessful.

This behavior is expected, because KFSO is not designed to offer Kerberos

authentication support over external trusts. To use a Kerberos trust between forests,
create a forest trust instead.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to optimize the location of a
domain controller or global catalog that
resides outside of a client's site
Article • 02/19/2024

This article provides the steps to optimize the location of a domain controller or global
catalog that resides outside of a client's site.

Applies to: Windows Server 2012 R2

Original KB number: 306602

Summary
The domain controller locator mechanism in Windows 2000 always prefers a domain
controller that resides in the site of the client that is searching for a domain controller.
This is achieved by a domain controller that registers site-specific domain controller
locator DNS SRV resource records for the site in which the domain controller resides.

Additionally, a domain controller may register site-specific domain controller locator

DNS SRV resource records for any other sites that do not contain a domain controller in
the same role to which the site of the domain controller is the closest. Such roles include
a role that hosts the same domain, or that is a global catalog). This mechanism ensures
that clients will locate the nearest domain controller in cases in which no domain
controller is located in the client's site.

For more information about this mechanism, refer to the Windows 2000 Server Resource
Kit, "Distributed Systems Guide" book, Chapter 3: "Name Resolution in Active Directory."

In a case in which all the domain controllers in the same role (that is, that are hosting
the same domain or are being global catalogs) in a particular site become unavailable,
clients that are located in the same site will fail over to any other domain controller in
any other site without optimization.

More information
The following information describes the recommended configuration that you should
use to optimize the location of the domain controllers or global catalogs when all of the
domain controllers/global catalogs that are serving a particular site become unavailable.
"Section I" describes the configuration for hub-and-spoke topologies. "Section II"
describes the configuration for other topologies.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

Section I: Hub-and-spoke topology

The recommendations in this section are based upon the following assumption in the
hub-and-spoke topology:

It is preferable that if all domain controllers and global catalogs in a satellite site
become unavailable, a client that's searching for a domain controller or global catalog in
that site fails over to a domain controller or global catalog that's in a central hub and
not in another satellite site. This solution is suitable for topologies that have a single hub
site or multiple central hubs to accommodate cases in which it's irrelevant to which
central site a satellite client fails over.

To achieve this behavior, the domain controllers and global catalogs in the satellite
offices should not register generic (non-site-specific) domain controller locator DNS
records. These records are registered only by the domain controllers and global catalogs
in the central hub. When clients cannot locate the domain controllers and global
catalogs that serve their site, they try to locate any domain controllers or global catalogs
by using these generic (non-site-specific) domain controller locator DNS records.

The following records should not be registered by the domain controllers or global
catalogs in the satellite sites:

Windows Server 2003-based domain controllers

Windows 2000-based domain controllers with Service Pack 2 (SP2) or later
installed, or with the hotfix that is specified in Knowledge Base article 267855
To configure domain controllers or global catalogs not to
register generic records

Windows 2000
1. Start Registry Editor (Regedt32.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: DnsAvoidRegisterRecords

Data type: REG_MULTI_SZ

Set the value to the list of the enter-delimited mnemonics that are specified in the
"Reference tables" section.

4. Exit Registry Editor.

Windows Server 2003

To configure Windows Server 2003-based domain controllers, use the "DC locator DNS
records not registered by the DCs" Net Logon service group policy. To do this, specify
the list of the space-delimited mnemonics that are specified in the "Reference tables"
section.

Reference tables

The following tables contain mnemonics, types, and owner names of the domain
controller locator DNS records that should not be registered by the satellite domain
controllers and global catalogs to optimize the domain controller location.

Domain controller-specific records

ﾉ Expand table

Mnemonic Type DNS Record

LdapIpAddress A <DnsDomainName>

Ldap SRV _ldap._tcp.<DnsDomainName>

DcByGuid SRV _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>

 Mnemonic Type DNS Record

Kdc SRV _kerberos._tcp.dc._msdcs.<DnsDomainName>

Dc SRV _ldap._tcp.dc._msdcs.<DnsDomainName>

Rfc1510Kdc SRV _kerberos._tcp.<DnsDomainName>

Rfc1510UdpKdc SRV _kerberos._udp.<DnsDomainName>

Rfc1510Kpwd SRV _kpasswd._tcp.<DnsDomainName>

Rfc1510UdpKpwd SRV _kpasswd._udp.<DnsDomainName>

Global catalog-specific records

ﾉ Expand table

Mnemonic Type DNS Record

Gc SRV _ldap._tcp.gc._msdcs.<DnsForestName>

GcIpAddress A gc._msdcs.<DnsForestName>

GenericGc SRV _gc._tcp.<DnsForestName>

For the complete list of the domain controller locator DNS records, see the Windows
2000 Server Resource Kit, "Distributed Systems Guide" book, Chapter 3: "Name
Resolution in Active Directory." For the complete list of the domain controller locator
DNS records, refer to KB article Q267855 that is referenced in this article.

Section II: Other topologies

If the failover to the central hubs when local domain controllers and global catalogs
become unavailable does not satisfy your requirements, you can use the following
configuration.

If the clients (such as servers that run Microsoft Exchange Servers) in site A fail over to
the domain controllers and global catalogs in site B, an administrator can configure
some or all the domain controllers and global catalogs in site B to register site-specific
records for site A when domain controllers and global catalogs in site A become
unavailable. To make sure that domain controllers and global catalogs from site B are
chosen by the clients in site A only if the domain controllers and global catalogs from
site A are not available, the domain controllers and global catalogs in site B that are
covering site A should register SRV records that containing lower (higher in absolute
value) priority.
 ７ Note

The priority setting is applied to all SRV records that are registered by a domain
controller. Therefore, the administrator should be cautious when setting a lower
priority to be used by a domain controller because the domain controller will
register a lower priority for the site-specific-records, including for its own site.

To configure a domain controller to register site-specific

records for a different site

Windows 2000
1. Start Registry Editor (Regedt32.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: SiteCoverage

Data type: REG_MULTI_SZ

Set the value to the list of the space-delimited site names for which the domain
controller should register.

4. Exit Registry Editor.

Windows Server 2003

To configure Windows Server 2003-based domain controllers, use the "Sites Covered by
the domain controller locator DNS SRV Records" Net Logon service group policy. To do
this, specify the list of the space-delimited site names for which the domain controller
should register.

To configure a Global Catalog to register site-specific

records for a different site

Windows 2000

1. Start Registry Editor (Regedt32.exe).

 2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: GcSiteCoverage

Data type: REG_MULTI_SZ

Set the value to the list of the space-delimited site names for which the global
catalog should register.

4. Exit Registry Editor.

Windows Server 2003

Use the "Sites Covered by the global catalog locator DNS SRV Records" Net Logon
service Group Policy by specifying the list of the carriage return-delineated site names
for which the global catalog should register.

To Configure a domain controller to Register SRV Records

with Particular Priority

Windows 2000
1. Start Registry Editor (Regedt32.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: LdapSrvPriority

Data type: REG_DWORD

Set the value to the desired value of the priority. Exit

4. Exit Registry Editor.

Windows Server 2003

To configure Windows Server 2003-based domain controllers, use the "Priority Set in the
domain controller locator DNS SRV Records" Net Logon service Group Policy.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot problems with promoting
a domain controller to a global catalog
server
Article • 02/19/2024

This article discusses a problem with promoting a domain controller to a global catalog
server.

Applies to: Windows Server 2003

Original KB number: 910204

Summary
This article discusses the following topics:

The event messages that are logged in the Directory Services log for Windows
Server
The possible causes of the global catalog promotion failure
Ways to determine the cause of the global catalog promotion failure
Ways to resolve the global catalog promotion failure

Symptoms
When you try to promote a domain controller to a global catalog server, the domain
controller may not advertise itself as a global catalog. This is true if you promote the
domain controller programmatically or by clicking to select the Global Catalog option.
When this problem occurs, event messages are logged in the Directory Services log.

Additionally, the output may show that the domain controller did not pass the
advertising test and is not advertising the global catalog. This output occurs when a
domain controller logs event ID 1578 and when you run a domain controller diagnostic
check (Dcdiag.exe) on that domain controller.

７ Note

To run a domain controller diagnostic check, do the following:

1. Click Start, click Run, type cmd, and then click OK.
 2. At the command prompt, type dcdiag /v /f: logfile.txt , and then press
ENTER.

The following event messages are logged in the Directory Services log when this
problem occurs.

Event ID 1559

Event ID 1578

If you enable diagnostic logging for the Knowledge Consistency Checker (KCC) at
level 1, the following event is logged.

Event ID 1801

Cause
A global catalog must replicate inbound copies of all objects from all domain partitions
in the forest before the global catalog can advertise the global catalog role.

When a domain controller is selected to host the global catalog, the KCC on the domain
controller that is being promoted uses its discretion to build connection objects from
source domain controllers that host the required partitions. These source domain
controllers may consist of existing global catalogs in the forest or domain controllers
that host writable copies of every domain partition that resides in its forest. The
contents of each domain partition are then inbound replicated from source domain
controllers that are designated by the KCC. The contents are replicated to the newly
promoted global catalog over existing or newly created connection links.

Global catalog promotion may fail if one of the following conditions is true:

1. The configuration partition on one or more domain controllers contains a cross-

reference object to a stale or orphaned domain, but no domain controllers for that
domain are located in the forest.

2. Metadata for a source domain controller that is designated by the KCC is located in
the configuration partition of one or more domain controllers but does not
represent a domain controller currently present in the forest.

3. The source domain controller that is selected by the KCC on the global catalog that
is being promoted is offline.
 4. The source domain controller that was selected by the KCC on the global catalog
that is being promoted is inaccessible over the network. This domain controller is
inaccessible because there is no network connectivity or partial network
connectivity. The following are examples of network connectivity issues:

Ports that are blocked

IP addresses that are filtered
Networks that are not fully routed but that have the bridge-all-site-links
option enabled

5. Source domain global catalogs are constrained from acting as bridgeheads

because non-global catalog domain controllers have incorrectly been selected as
preferred bridgeheads by administrators.

6. The global catalog that is being promoted cannot build a connection link from the
selected source domain controller because of the error status that is logged in one
of the events that are listed in the Summary section.

An orphaned domain will prevent the domain controller from finishing the replication.
The domain controller cannot advertise itself as a global catalog server until replication
is completed. There are several issues that could lead to an orphaned domain:

1. Active Directory was removed from all the domain controllers of a domain, but the
domain partition cross-reference object still remains.

2. Active Directory was removed from a domain controller, and the directory partition
of the domain controller was removed. The domain controller was then re-created
before replication was completed. These events caused lingering phantoms that a
cross-reference object incorrectly references.

3. The domain-naming update for the domain has not reached the domain controller
that is experiencing the problem. Or, the domain-naming update for a domain that
is newly promoted may not have reached any domain controllers outside that
domain. This issue would be a temporary problem.

Resolution

２ Warning

You should not enable a reduced occupancy level to artificially accelerate global
catalog promotion. We strongly recommend that you first resolve the Directory
Service replication issue so that the global catalog is automatically advertised.
To resolve this problem, first identify the root cause of the replication issue, and resolve
that problem. Determine whether the replication issue is caused by one of the following
conditions:

A replication delay
An orphaned domain that is located in the forest environment
An inability to build the connection link
An inability to replicate over the connection agreement

If there is an NTDS KCC event ID 1265 that is logged in the Directory Service log, use
that event to determine the cause of the replication failure for the same domain
partition. Make sure that network connectivity is good and that no required network
ports are blocked. Required network ports are, for example, TCP 135 and ephemeral
ports that are used by RPC. View the DNS records to make sure that the registered Host
and SRV records are all correctly registered. If there are incorrect records, you must clear
them out and register such records.

Remove all stale metadata for any domain controllers and domains in the forest that are
listed in the relevant event IDs. You must do this to make sure that replication is not
failing because of a non-existent domain controller or domain. For more information
about how to remove Active Directory metadata, see the following article:

Clean up Active Directory Domain Controller server metadata

After you have verified that the replication between domain controllers is working
correctly, determine whether there is an orphaned domain object. You can use the
Ntdsutil.exe utility to clear the orphaned domain object. If there is any orphaned domain
controller object for that domain, you must also delete the domain controller object. For
more information about how to remove an orphaned domain, see the following article:

How to remove orphaned domains from Active Directory

For more information about how to remove orphaned domain controller objects, see
the following article:

Clean up Active Directory Domain Controller server metadata

More information
After you promote the domain controller to a global catalog server, domain partitions in
the forest will be replicated to the new global catalog server. When all partitions have
successfully replicated to the new global catalog server, event ID 1119 will be logged in
the Directory Services log on the domain controller. The event description states that
the computer is now advertising itself as a global catalog server.

To confirm that the domain controller is a global catalog server, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. Type nltest /dsgetdc: Domain_name /server: Server_Name , and then press ENTER.

3. Verify that the server is advertising the "GC" (global catalog) flag. For example,
when you type the command in step 2, you will receive a message that is similar to
the following if the GC flag is present:

DC: \\<ServerName>
Address: \\<IPAddress>
Dom Guid: <GUID>

Dom Name: <DomainName>

Forest Name: <DomainName>.com
Dc Site Name: Default-First-Site-Name

Our Site Name: Default-First-Site-Name

Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE

The command completed successfully

７ Note

Nltest is a command-line tool that is built into Windows Server. For more
information, see Nltest.

For more information, see the following articles:

You cannot promote a Windows Server domain controller to be a global catalog

server

How to remove orphaned domains from Active Directory

Feedback
Was this page helpful?  Yes  No
Provide product feedback
DCPROMO fails with error "Access is
denied" if the user does the promotion
isn't granted the "trusted for
delegation" user right
Article • 02/19/2024

This article provides a solution to an Access is denied error that occurs with DCPROMO
(Domain Controller Promoter).

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Original KB number: 2002413

Symptoms
DCPROMO promotion of a Windows Server 2008 or later version member computer to a
replica domain controller (DC) fails with the following error:

Title: Windows Security

Message Text: Network Credentials
The operation failed because: The Active Directory Domain Services Installation
Wizard was unable to convert the computer account <hostname>$ to an Active
Directory Domain Controller account. "Access is denied"

DCPROMO Demotion can fail with the same error:

Title: Windows Security

Message Text: Network Credentials
The operation failed because: Active Directory Domain Services could not configure
the computer account <hostname>$ to the remote Active Directory Domain
Controller account <fully qualified name of helper DC>. "Access is denied"

Cause
The user account used to execute DCPROMO hasn't been granted the "Enable computer
and user accounts to be trusted for delegation" user right.

Resolution
1. Verify that the default domain controllers policy exists in Active Directory.

If the domain controller policy doesn't exist, evaluate whether that condition is
because of simple replication latency, an Active Directory replication failure or
whether the policy has been deleted from Active Directory. If the policy has been
deleted, contact Microsoft Support to recreate the missing policy with the default
policy GUID (Globally Unique Identifier). Don't manually recreate the policy with
the same name and settings as the default.

If the default domain controllers policy exists in Active Directory on some domain
controllers but not others, evaluate whether that inconsistency is due simple
replication latency or a replication failure. Resolve as required.

2. Verify that the server account is not protected from accidental deletion.

To do this, go to the Active Directory Administrative Center, find your server

under the Computers listing within your domain, open the properties. In the first
section, right under the operating system information, make sure the Protect from
accidental deletion checkbox is unchecked.

In the process of elevation to Domain Controller, the computer account for the
server is deleted, and re-added as a Domain Controller. If this checkbox is clicked,
this can't happen.

3. Verify that the user account does the DCPROMO operation has been granted the
"Enable computer and user accounts to be trusted for delegation" user right in the
default domain controllers policy.

Run whoami /all to verify that the "Enable computer and user accounts to be
trusted for delegation" user right exists in the users security token.

７ Note

By default, this right is granted to members of the Administrators security

group in the target domain. The built-in Administrator account is a member
of this security group but may have been removed.

If a user other than the built-in administrators group is doing DCPROMO

promotions, either add that user account to the Administrators security
group OR add the user account the "Enable computer and user accounts to
be trusted for delegation" user right in the default domain controllers policy.
"Enable computer and user accounts to be trusted for delegation" was
recently modified, or the policy granting the DCPROMO user account exists
 on some domain controllers in the domain but not others, check for simple
replication latency or a replication failure in both Active Directory and File
System Replication (FSR) / Distributed File System Replication (DFSR).
If the policy was recently modified, have the DCPROMO user account sign out
and sign in.

4. Verify that the default domain controllers policy is linked to the domain controllers
OU and that all DC machine accounts stay in that OU.

If DC machine accounts stay in an alternate OU container, either move all DC

machine accounts to the domain controllers OU or link the default domain
controllers policy to the alternate OU container.

5. Verify that the file system portion of default domain controllers policy exists in the
SYSVOL share of the DC being used to apply policy on the computer being
promoted or demoted.

If not present, it can be because of one or more of the following reasons:

Replication latency in FRS / DFSR

A replication failure in FRS / DFSR
The policy has been deleted from the SYSVOL. If the policy has been deleted,
contact Microsoft Support to recreate the missing policy with the default
policy GUID. Don't manually recreate the policy with the same name and
settings as the default.

6. The default domain policy or policy in general isn't applying to the logged on user

To check for policy inheritance, Windows Management Instrumentation (WMI)

filtering or security descriptor problem that may be preventing policy from
applying, run the following command:

Console

gpresult /h result.html

More information
Table1. Logs from Promotion (example)

ﾉ Expand table
DCPROMO.LOG DCPROMOUI.LOG

[INFO] Creating the NTDS Settings Calling DsRoleGetDcOperationResults

object for this Active Directory Domain Error 0x0 (!0 => error)
Controller on the remote AD DC Operation results:
<helperDC>.contoso.com... OperationStatus: 0x5 !0 => error
[INFO] Replicating the schema directory DisplayString: The Active Directory Domain
partition Services Installation Wizard was unable to
... convert the computer account <DC being
[INFO] Replicated the schema promoted>$ to an Active Directory Domain
container. Controller account.
[INFO] Active Directory Domain ServerInstalledSite: (null)
Services updated the schema cache. OperationResultsFlags: 0x0
[INFO] Replicating the configuration Enter ProgressDialog::UpdateText The Active
directory partition Directory Domain Services Installation Wizard
... was unable to convert the computer account <dc
[INFO] Replicated the configuration being promoted>$ to an Active Directory
container. Domain Controller account.
[INFO] Error - The Active Directory Enter State::SetOperationResultsMessage The
Domain Services Installation Wizard Active Directory Domain Services Installation
was unable to convert the computer Wizard was unable to convert the computer
account <DC being promoted>$ to an account <dc being promoted>$ to an Active
Active Directory Domain Controller Directory Domain Controller account.
account. (5) Enter State::SetOperationResultsFlags 0x0
[INFO] EVENTLOG (Error): NTDS Exception caught
General / Internal Processing: 1168 catch completed
Internal error: An Active Directory handling exception
Domain Services error has occurred. Enter State::ClearHiddenWhileUnattended
Enter EnableConsoleLocking
Additional Data Enter RegistryKey::Create
SOFTWARE\Microsoft\Windows
Error value (decimal): NT\CurrentVersion\Winlogon
-1073741823 Enter RegistryKey::SetValue-DWORD
DisableLockWorkstation
Error value (hex): Enter State::SetOperationResults result FAILURE
c0000001 Enter ProgressDialog::UpdateText
Enter State::IsOperationRetryAllowed
Internal ID: true
300162a credentials were invalid, hr=0x80070005
Enter GetErrorMessage 80070005
[INFO] EVENTLOG (Informational): Enter State::GetOperationResultsMessage The
NTDS General / Service Control: 1004 Active Directory Domain Services Installation
Active Directory Domain Services was Wizard was unable to convert the computer
shut down successfully. account <dc being promoted>$ to an Active
Directory Domain Controller account.
[INFO] NtdsInstall for a.com returned 5 Enter State::GetOperation REPLICA
[INFO] DsRolepInstallDs returned 5 Enter State::GetReplicaDomainDNSName <target
[ERROR] Failed to install to Directory dns domain name>
Service (5)
 DCPROMO.LOG DCPROMOUI.LOG

[INFO] Starting service NETLOGON

[INFO] Configuring service NETLOGON
to 2 returned 0
[INFO] The attempted domain
controller operation has completed
[INFO] DsRolepSetOperationDone
returned 0

Table 2. Logs from Demotion (example)

ﾉ Expand table

DCPROMO.LOG DCPROMOUI.LOG

[INFO] Uninstalling the Directory ....

Service OperationStatus: 0x5 !0 => error
[INFO] Invoking NtdsDemote DisplayString: Active Directory Domain Services
... couldn't configure the computer account <dc
[INFO] Removing Active Directory name>$ on the remote Active Directory Domain
Domain Services objects that refer Controller <helper DC>.<dns domain>.
to the local Active Directory Domain ServerInstalledSite: (null)
Controller from the remote Active OperationResultsFlags: 0x0
Directory Domain Controller <DNS Enter ProgressDialog::UpdateText Active Directory
domain>... Domain Services couldn't configure the computer
[INFO] Error - Active Directory account <dc name>$ on the remote Active Directory
Domain Services couldn't configure Domain Controller VM1-W7.a.com.
the computer account <dc being Enter State::SetOperationResultsMessage Active
demoted>$ on the remote Active Directory Domain Services couldn't configure the
Directory Domain Controller computer account <dc name>$ on the remote
<helper DC>.<DNS domain>. (5) Active Directory Domain Controller <helper DC>.
[INFO] NtdsDemote returned 5 <DNS domain>.
[INFO] DsRolepDemoteDs returned Enter State::SetOperationResultsFlags 0x0
5 ...
[ERROR] Failed to demote the credentials were invalid, hr=0x80070005
directory service (5) Enter GetErrorMessage 80070005
.... Enter State::GetOperationResultsMessage Active
Directory Domain Services couldn't configure the
computer account <dc name>$ on the remote
Active Directory Domain Controller <helper DC>.
<DNS domain>.
Enter State::GetOperation DEMOTE
Enter State::GetParentDomainDnsName

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Access is denied" error when you try to
create NTDS Settings object
Article • 02/19/2024

This article provides a solution to fix an error (Access is denied) that occurs when you
promote new Windows Server 2012 R2 domain controllers in an existing domain.

Applies to: Windows Server 2012 R2

Original KB number: 3207962

Symptoms
When you try to promote new Windows Server 2012 R2 domain controllers in an
existing domain, the operation fails with an "Access is denied" error. This issue occurs
even when the user is a member of the Domain Admins or Enterprise Admins group.

In this situation, the administrator sees the following error message:

Title: Windows Security

Message Text: Network Credentials

The operation failed because: Active Directory Domain Services could not configure
the computer account <hostname>$ to the remote Active Directory Domain
Controller account <fully qualified name of helper DC>. "Access is denied"

The failure occurs when adding the NTDS Settings object for the new Domain
Controller, returning the following error message:

The operation failed because:

Active Directory Domain Services could not create the NTDS Settings object for this
Active Directory Domain Controller CN=NTDS Settings,CN=TEST-
DC,CN=Servers,CN=mysite,CN=Sites,CN=Configuration,DC=domain,DC=com on the
remote AD DC DCName.ChildDomain.domain.com. Ensure the provided network
credentials have sufficient permissions.

"Access is denied."

Additionally, the DCPromo.log file shows the following errors:

2705DateTime[INFO]
 Error - Active Directory Domain Services could not create the NTDS Settings object
for this Active Directory Domain Controller CN=NTDS Settings,CN=TEST-
DC,CN=Servers,CN=mysite,CN=Sites,CN=Configuration,DC=domain,DC=com on
the remote AD DC DCName.ChildDomain.domain.com. Ensure the provided
network credentials have sufficient permissions. (5)

DateTime[INFO] EVENTLOG (Error): NTDS General / Internal Processing: 1168 Internal

error: An Active Directory Domain Services error has occurred.

Additional Data

Error value (decimal):

-1073741823

Error value (hex):

c0000001

Internal ID: 30017c6

...
DateTime[INFO] NtdsInstall for ChildDomain.domain.com returned 5
DateTime [INFO] DsRolepInstallDs returned 5
DateTime [ERROR] Failed to install to Directory Service (5)
DateTime[ERROR] DsRolepFinishSysVolPropagation (Abort Promote) failed with 8001
DateTime[WARNING] Failed to abort system volume installation (8001)
DateTime[INFO] Starting service NETLOGON
DateTime[INFO] Configuring service NETLOGON to 2 returned 0
DateTime[INFO] The attempted domain controller operation has completed

Where the errors map to the following:

Cause
This issue occurs because the Add/Remove Replica In Domain permission is missing for
the Domain Admins and Enterprise Admins groups on the domain partition of the
domain.
Resolution
To resolve this issue, follow these steps:

1. Verify that all the steps and conditions in the "Resolution" section of Knowledge
Base article 2002413 are true for your environment.

2. If domain controller promotion still fails even after you make sure that the user
also has the SeEnableDelegationPrivilege permission, check ADSIEdit.msc to verify
the user's effective permissions for the domain partition:

a. Click Start, click Run, and then type adsiedit.msc.

b. Expand Default naming context, right-click DC=domain,DC=com, and then click

Properties.

c. On the Security tab, click the Advanced button.

d. On the Effective Access tab, enter the user or group name of the user who is
performing the operation that's failing in DCPromo.

e. Confirm whether the Add/remove replica in domain control access permission

has been granted.

3. If the Add/Remove Replica In Domain permission is missing for the user or group,
add it by using ADSIEdit.msc:

a. Click Start, click Run, and then type adsiedit.msc.

 b. Expand Default naming context, right-click DC=domain,DC=com, and then click
Properties.

c. On the Security tab, click the Advanced button.

d. On the Permissions tab, add the Add/remove replica in domain control access
permission for the desired user or group as follows:

Type: Allow
Applies to: This object only

More information

７ Note

there could be additional reasons why a domain controller promotion or demotion

fails with an "Access is denied" error. For more information, see KB 2002413 .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"The service cannot be started" error
during AD DS configuration
Article • 02/19/2024

This article provides help to an error (The service cannot be started) that occurs when
Active Directory Domain Services (AD DS) configuration fails.

Applies to: Windows Server 2012 R2

Original KB number: 2737880

Symptoms
In Windows Server 2012, one of the following AD DS configuration operations fails:

Configuring a new domain controller by using Server Manager or the

AddsDeployment Windows PowerShell module
Removing AD DS from an existing domain controller by using Server Manager or
the AddsDeployment Windows PowerShell module
Cloning a virtualized domain controller by using dccloneconfig.xml

When the configuration fails, you receive the following error message:

The service cannot be started, either because it is disabled or it has no enabled

devices associated with it.

Additionally, you see that the Dcpromoui.log file contains the following line of text:

Enter GetErrorMessage 80070422

Cause
This issue occurs because an administrator configured the "startup type" for the DS Role
Server service (DsRoleSvc) to disabled. You can confirm this by using the Services.msc
snap-in to examine the Startup type list on the General tab.

By default, the DS Role Server service is installed during AD DS role installation and is
set to the Manual startup type.

Resolution
To resolve this issue, make sure that the DS Role Server service is not disabled. To do
this, use Services.msc or Sc.exe to set the startup type to Manual and to let the DS Role
Server operations start and stop the service on demand. For example, run the following
command from an Administrator elevated command prompt:

Console

sc.exe config dsrolesvc start= demand

７ Note

The space after the "start=" argument is intentional.

More information
This behavior is by design.

The DS Role Server service is new to Windows Server 2012 and is used to install or
remove Active Directory or to clone domain controllers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot add a domain controller as a
node in a failover cluster environment
Article • 02/19/2024

This article provides some information about how to add a domain controller as a node
in a failover cluster environment.

Applies to: Windows Server 2012 R2

Original KB number: 2795523

Symptoms
When you build a Windows Server 2012 failover cluster environment, you cannot add a
server that has the Active Directory Domain Services (AD DS) role as a node.

Cause
We do not support combining the AD DS role and the failover cluster feature in
Windows Server 2012.

Status
This behavior is by design.

More information
Although we do not recommend this, you can enable domain controllers as a cluster
node in Windows Server versions earlier than Windows Server 2012. However, starting
with Windows Server 2012, we no longer support this configuration.

For more information about how to use domain controllers as nodes in failover clusters,
click the following article number to view the article in the Microsoft Knowledge Base:

281662 How to use Windows Server cluster nodes as domain controllers

For more information about Microsoft support policy for Windows Server 2012 failover
clusters, click the following article number to view the article in the Microsoft Knowledge
Base:
2775067 The Microsoft support policy for Windows Server 2012 failover clusters

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unable to select DNS Server role when
adding a domain controller into an
existing Active Directory domain
Article • 02/19/2024

This article helps fix an issue where the option to auto-install the DNS Server role is
disabled or grayed out in the Active Directory Installation Wizard (DCPROMO) when
promoting a Windows Server 2008 or Windows Server 2008 R2 replica domain
controller.

Applies to: Windows Server 2012 R2

Original KB number: 2002584

Symptoms
When promoting a Windows Server 2008 or Windows Server 2008 R2 replica domain
controller, the option to auto-install the DNS Server role is disabled or grayed out in the
Active Directory Installation Wizard (DCPROMO).

Text in the Additional information field states:

DNS cannot be installed on this domain controller because this domain does not
host DNS.

A screenshot of this condition is shown below:

The %windir%\debug\dcpromoui.log file on the replica domain controller being
promoted shows the following:

Enter DoesDomainHostDns SLD

dcpromoui A74.A78 046C <DateTime> Dns_DoesDomainHostDns testing domain
name SLD
dcpromoui A74.A78 046D <DateTime> SOA query returned 9003 so the domain
does not host DNS
dcpromoui A74.A78 046E <DateTime> Dns_DoesDomainHostDns returning false
dcpromoui A74.A78 046F <DateTime> HRESULT = 0x00000000
dcpromoui A74.A78 0470 <DateTime> The domain does not host DNS.

Cause
1. A code defect prevents the DNS Server checkbox from being enabled when
promoting replica domain controllers into existing domains with single-label DNS
names like "contoso" instead of best-practice fully qualified DNS name like
" contoso.com " or " corp.contoso.com ". This condition exists even when Microsoft
DNS is installed on a domain controller and hosts Active Directory-integrated
forward lookup zones for the target domain.
 For more information about single label domains, visit the following Microsoft web
site:

Microsoft DNS Namespace Planning Solution Center

OR

2. DCPromo checks to see if the DNS zone for the target Active Directory forest is
hosted in Active Directory. If the DNS zone for the target domain isn't hosted on
an existing domain controller in the target forest, DCPROMO doesn't allow the
user to install DNS during the replica promotion.

The goal of this behavior is to prevent administrators from creating duplicate

copies of DNS zones with different replication scopes (that is, file-based zones on
Microsoft or third-party DNS Servers and Active Directory integrated DNS zones
on domain controllers on the newly promoted domain controller).

Resolution
For the first root cause, continue the promotion and install the DNS Server role after it's
promoted.

For the second root cause, the DNS client and server configuration on the replica
domain controller being promoted was sufficient to discover a helper domain controller
in the target domain but DCPROMO has determined that the DNS zone for the domain
wasn't Active Directory integrated.

Determine which DNS servers are going to host the zone for your Active Directory
domain and what replication scopes those zones will use (Microsoft DNS versus third-
party DNS, forest-wide application partition, domain-wide application partition, file-
based primary, and so on.)

Don't let the inability to auto-install the DNS Server role during DCPROMO block the
promotion of Windows Server 2008 replica domain controllers in the domain. Server
Manager can be used to install the Microsoft DNS Server role on existing domain
controllers, as well as computers functioning as member or workgroup computers. DNS
zones and their records can be replicated or copied between DNS servers.

Specific workarounds include:

1. If the DNS zones exist on DNS servers outside the domain, consider moving the
zones to an existing domain controller in the domain that hosts the DNS Server
role.
 2. If zone data needs to be moved, configure the Microsoft DNS server to host a
secondary copy of the zone, then convert that zone to be a file-based primary,
then transition the zone to be Active Directory integrated as required. You can
ignore this step if you have no interest in saving the DNS zone data.

3. Configure the new replica domain controller being promoted to point exclusively
to DNS servers hosting Active Directory integrated copies of the zone.

4. Use the following command to force Windows 2000, Windows XP, Windows Server
2003, Windows Vista, and Windows Server 2008 computers to dynamically register
Host A or AAAA records:

Console

ipconfig /registerdns

5. Use the following command to force Windows 2000, Windows Server 2003, and
Windows Server 2008 domain controllers to dynamically register SRV records

Console

net stop netlogon & net start netlogon

6. Restart DCPROMO on the replica domain controller.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to create an Active Directory server
in Windows Server 2003
Article • 02/19/2024

This article describes how to install and configure a new Active Directory installation in a
laboratory environment that includes Windows Server 2003 and Active Directory.

Applies to: Windows Server 2003

Original KB number: 324753

７ Note

You will need two networked servers that are running Windows Server 2003 for this
purpose in a laboratory environment.

Create the Active Directory

After you have installed Windows Server 2003 on a stand-alone server, run the Active
Directory Wizard to create the new Active Directory forest or domain, and then convert
the Windows Server 2003 computer into the first domain controller in the forest. To
convert a Windows Server 2003 computer into the first domain controller in the forest,
follow these steps:

1. Insert the Windows Server 2003 CD-ROM into your computer's CD-ROM or DVD-
ROM drive.

2. Click Start, click Run, and then type dcpromo.

3. Click OK to start the Active Directory Installation Wizard, and then click Next.

4. Click Domain controller for a new domain, and then click Next.

5. Click Domain in a new forest, and then click Next.

6. Specify the full DNS name for the new domain. Note that because this procedure is
for a laboratory environment and you are not integrating this environment into
your existing DNS infrastructure, you can use something generic, such as
mycompany.local, for this setting. Click Next.

7. Accept the default domain NetBIOS name (this is "mycompany" if you used the
suggestion in step 6). Click Next.
 8. Set the database and log file location to the default setting of the c:\winnt\ntds
folder, and then click Next.

9. Set the Sysvol folder location to the default setting of the c:\winnt\sysvol folder,
and then click Next.

10. Click Install and configure the DNS server on this computer, and then click Next.

11. Click Permissions compatible only with Windows 2000 or Windows Server 2003
servers or operating systems, and then click Next.

12. Because this is a laboratory environment, leave the password for the Directory
Services Restore Mode Administrator blank. Note that in a full production
environment, this password is set by using a secure password format. Click Next.

13. Review and confirm the options that you selected, and then click Next.

14. The installation of Active Directory proceeds. Note that this operation may take
several minutes.

15. When you are prompted, restart the computer. After the computer restarts,
confirm that the Domain Name System (DNS) service location records for the new
domain controller have been created. To confirm that the DNS service location
records have been created, follow these steps:
a. Click Start, point to Administrative Tools, and then click DNS to start the DNS
Administrator Console.
b. Expand the server name, expand Forward Lookup Zones, and then expand the
domain.
c. Verify that the _msdcs, _sites, _tcp, and _udp folders are present. These folders
and the service location records they contain are critical to Active Directory and
Windows Server 2003 operations.

Add Users and Computers to the Active

Directory domain
After the new Active Directory domain is established, create a user account in that
domain to use as an administrative account. When that user is added to the appropriate
security groups, use that account to add computers to the domain.

1. To create a new user, follow these steps:

a. Click Start, point to Administrative Tools, and then click Active Directory Users
and Computers to start the Active Directory Users and Computers console.
 b. Click the domain name that you created, and then expand the contents.

c. Right-click Users, point to New, and then click User.

d. Type the first name, last name, and user logon name of the new user, and then
click Next.

e. Type a new password, confirm the password, and then click to select one of the
following check boxes:

Users must change password at next logon (recommended for most users)
User cannot change password
Password never expires
Account is disabled

Click Next.

f. Review the information that you provided, and if everything is correct, click
Finish.

2. After you create the new user, give this user account membership in a group that
permits that user to perform administrative tasks. Because this is a laboratory
environment that you are in control of, you can give this user account full
administrative access by making it a member of the Schema, Enterprise, and
Domain administrators groups. To add the account to the Schema, Enterprise, and
Domain administrators groups, follow these steps:
a. On the Active Directory Users and Computers console, right-click the new
account that you created, and then click Properties.
b. Click the Member Of tab, and then click Add.
c. In the Select Groups dialog box, specify a group, and then click OK to add the
groups that you want to the list.
d. Repeat the selection process for each group in which the user needs account
membership.
e. Click OK to finish.

3. The final step in this process is to add a member server to the domain. This
process also applies to workstations. To add a computer to the domain, follow
these steps:

a. Log on to the computer that you want to add to the domain.

b. Right-click My Computer, and then click Properties.

c. Click the Computer Name tab, and then click Change.

 d. In the Computer Name Changes dialog box, click Domain under Member Of,
and then type the domain name. Click OK.

e. When you are prompted, type the user name and password of the account that
you previously created, and then click OK.

A message that welcomes you to the domain is generated.

f. Click OK to return to the Computer Name tab, and then click OK to finish.

g. Restart the computer if you are prompted to do so.

Troubleshooting: You cannot open the Active

Directory snap-ins
After you have completed the installation of Active Directory, you may not be able to
start the Active Directory Users and Computers snap-in, and you may receive an error
message that indicates that no authority can be contacted for authentication. This can
occur if DNS is not correctly configured. To resolve this issue, verify that the zones on
your DNS server are configured correctly and that your DNS server has authority for the
zone that contains the Active Directory domain name. If the zones appear to be correct
and the server has authority for the domain, try to start the Active Directory Users and
Computers snap-in again. If you receive the same error message, use the DCPROMO
utility to remove Active Directory, restart the computer, and then reinstall Active
Directory.

For more information about configuring DNS on Windows Server 2003, see How to
configure DNS for Internet access in Windows Server 2003 .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DCPROMO demotion fails if it's unable
to contact the DNS infrastructure
master
Article • 02/19/2024

This article solves an issue where the demotion of a Windows Server computer that
hosts the Active Directory Domain Services (AD DS) or domain controller server role
fails.

Applies to: Windows Server 2012 R2

Original KB number: 2694933

Symptoms
The graceful demotion of a Windows Server computer hosting the AD DS or domain
controller server role fails. You see the following on-screen error:

Title bar text: Active Directory Domain Services Installation Wizard

Message Text:
The operation failed because:
Active Directory Domain Services could not transfer the remaining data in directory
partition
DC=DomainDNSZones,DC=<DNS domjain name> to Active Directory Domain
Controller
\\<DNS name of helper DC used to service demotion>
"The directory service is missing mandatory configuration information, and is unable
to determine the ownership of floating single-master operation roles."

The relevant part of the DCPROMO.LOG file contains the following text:

Output

<date> <time> [INFO] Transferring operations master roles owned by this

Active Directory Domain Controller in directory partition
DC=DomainDnsZones,DC=contoso,DC=com to Active Directory Domain Controller \\
<DNS name of helper DC...
<date> <time> [INFO] EVENTLOG (Warning): NTDS Replication / Replication :
2091
A review of the infrastructure object and attributes for the DNS application partition
referenced in the on-screen DCPROMO error and DCPROMO.LOG:

Output

Expanding base 'CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com'...

Getting 1 entries:
Dn: CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com
cn: Infrastructure;
distinguishedName:
CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = ( );
fSMORoleOwner: CN=NTDS Settings\0ADEL:<NTDS Settings objet GUID>,CN=\
<hostname of last DC to host the partition infrastructure
role>,CN=Servers,CN=<active directory site
name>,CN=Sites,CN=Configuration,DC=contoso,DC=com;
instanceType: 0x4 = ( WRITE );
isCriticalSystemObject: TRUE;
name: Infrastructure;
objectCategory: CN=Infrastructure-
Update,CN=Schema,CN=Configuration,DC=contoso,DC=com;
objectClass (2): top; infrastructureUpdate;
objectGUID: <object guid>;
showInAdvancedViewOnly: TRUE;
systemFlags: 0x8C000000 = ( DISALLOW_DELETE | DOMAIN_DISALLOW_RENAME |
DOMAIN_DISALLOW_MOVE );
uSNChanged: <some USN #>;
uSNCreated: <some USN #>;
whenChanged: <date> <time>;
whenCreated: <date> <time>;

Where distinguishing elements in the LDAP output taken from the sample domain
CONTOSO.COM include:

1. The fSMORoleOwner attribute contains the string 0ADEL indicating that the role
owning DC's NTDS Settings object has been deleted.

2. The fSMORoleOwner attribute contains a 32-character alpha-numeric GUID of the

owning DCs NTDS Settings object in the format of xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx.

3. The name of the default DNS application partition for which the fSMORoleOwner
attribute is assigned to a DC with a deleted NTDS Settings object. In this case, the
error referenced the DomainDNSZones. This same error may also occur for the
ForestDNSZones application partition.

Cause
The error occurs when the domain controller that's being demoted can't outbound
replicate changes to the DC that owns the infrastructure FSMO or operational role for
the partition referenced in the DCPROMO [log] error.

Specifically, the demotion attempt is aborted to safeguard against data loss. In the case
of DNS application partitions, the demotion is blocked to ensure that the following data
is replicated:

live and deleted DNS records

ACLS of the DNS records
metadata, such as registration and deletion dates

DN paths for partitions where the error in the Symptoms section may occur include:

CN=Infrastructures,DC=DomainDNSZones....
CN=Infrastructures,DC=ForestDNSZones....

Resolution

７ Note

When the infrastructure master is assigned to a deleted NTDSA on a DNS

application partition, like DomainDNSZones, it may also be missing for
ForestDNSZones partition or vice versa. We recommend that you verify that the for
both the DomainDNSZones and ForestDNSZones partitions assigned to live
Windows Server 2003 or later domain controllers hosting the DNS Server role and
partition in question.

To resolve this issue, use one of the following methods:

1. Use ADSIEDIT.MSC to assign the DN path for the fsMORoleOwner attribute to a live
DC that was a direct replication partner of the original FSMO role owner. Then wait
for that change to inbound-replicate to the DC that's being demoted.

2. Run the script in the Resolution section of KB949257 for the partition in
question.

3. If the DC that's being demoted can't inbound-replicate changes for the directory
partition in question, run the DCPROMO /FORCEREMOVAL command to forcefully
demote the domain controller.
More information
DCPromo attempts to outbound-replicate changes on every locally held NC so that
unique changes aren't lost. If data is stored in DNS zones, DCPROMO attempts to
outbound replicate the contents of DNS zones to the infrastructure master for the DNS
partition in question.

Related problem:

KB949257 describes a problem where the ADPREP /RODCPREP command fails when
infrastructure master for one or more DNS application partitions is assigned to a deleted
NTDSA.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain controller promotion stops
responding when NetBIOS over TCPIP is
disabled in Windows Server 2012 R2
Article • 02/19/2024

This article provides a solution to an issue where domain controller promotion stops
responding when short credentials are used in an environment that has NetBIOS over
TCPIP disabled.

Applies to: Windows Server 2012 R2

Original KB number: 2948052

Symptoms
When you use Active Directory Domain Services Configuration Wizard to promote a
computer to domain controller in Windows Server 2012 R2, the wizard stops
responding. When the issue occurs, Active Directory Domain Services Configuration
Wizard indicates the promotion is in process and displays the following text:

Windows Server 2012 R2 domain controllers have a default for the security setting
named "Allow cryptography algorithms compatible with Windows NT 4.0" that
prevents weaker cryptography algorithms when establishing security channel
sessions.

When the issue occurs, the Dcpromo.log file correctly indicates that the promotion
operation has stopped:

[INFO] DnsDomainName chilld contoso.local

[INFO] FlatDomainName child
[INFO] SiteName Default-First-Site-Name
[INFO] SystemVolumeRootPath C:\Windows\SYSVOL
INFO] DsDatabasePath C:\Windows\NTDS, DsLogPath C:\Windows\NTDS
[INFO] ParentDnsDomainName contoso.local
[INFO] ParentServer <helper DC>.contoso.local
[INFO] Account contoso\administrator
[INFO] Options 5243072
[INFO] Validate supplied paths
....
 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963
Internal event: The following local directory service received an exception from a
remote procedure call (RPC) connection. Extensive RPC information was requested.
This is intermediate information and might not contain a possible cause

[INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1962

Internal event: The local directory service received an exception from a remote
procedure call (RPC) connection. Extended error information is not available.
.... Error value:
A security package specific error occurred. 1825directory service:
<hostname> Additional Data

Error value:
Could not find the domain controller for this domain. (1908)

[INFO] EVENTLOG (Error): NTDS Replication / Setup : 1125

The Active Directory Domain Services Installation Wizard (Dcpromo) was unable to
establish connection with the following domain controller.
Domain controller: <DC name>.<DNS domain name>.<top level domain name>
Additional Data
Error value:
1908 Could not find the domain controller for this domain.

This issue occurs when the following conditions are true:

NetBIOS over TCP/IP is disabled. This occurs in the following situations:

Disable NetBIOS over TCP/IP option is not selected in Networks panel, the WINS
tab in the Advanced TCP/IP Settings of IPv4 properties.
NetBIOS over TCP/IP is disabled on the DHCP Server.
The computers are using IPv6 configuration only.

"Short" credential names are used in the Credential UI or in the domain controller
promotion answer file.
The Dcpromo.log earlier in this section indicates an
ERROR_DOMAIN_CONTROLLER_NOT_FOUND error is returned from the DRS bind
call when the promotion process is setting up to replicate the first naming context.

In this case, Kerberos cannot locate a domain controller to authenticate with by

using the specified credentials. For example, the specified credentials are
"wolf\administrator" instead of a "long" DNS credentials like
wolf.com\administrator. In the credential, "wolf" is the NetBIOS name of the
domain hosting the administrator account.
 ７ Note

If the issue occurs when you promote a new domain controller in a new child
domain. The following issues also occurs:

The computer consider it is joined to the domain.

You will have the option to log on to the child domain but the logon will fails.
If you log on to the computer locally, the ADDS and AWDS services is
disabled. The Netlogon.exe process is not started and the startup value is set
to manual identical, such as the default setting for a member workstation.

Cause
When you run Active Directory Domain Services Configuration Wizard in a NetBIOS-
less\WINS-less environment, it introduces some DC-locator limitations to be aware of
short domain names. This is especially true on a non-domain-joined computer. DC-
locator tries to map short domain names to fully qualified domain names (FQDNs) by
using the trusted-domain-list, which involves DNS to be used most of the time. If DNS
cannot be used, locator has to use WINS\NetBIOS. However, WINS\NetBIOS is not
available when NetBIOS over TCP/IP is disabled. This issue can be partly worked around
by the DNS-suffix feature that is added to DC-locator in Windows Server 2012 R2 and
Windows 8.1 but that is not always a 100% reliable solution.

Resolution
To resolve the issue, follow these steps:

1. End the Server Manager process in Task Manager.

７ Note

This step closes the Active Directory Domain Services Configuration Wizard.
When the issue occurs, the cancel button in the UI does not work.
Additionally, ending the Active Directory Domain Services Configuration
Wizard in Task Manager also does not work.

2. When you promote the computer as a domain controller again, use one of the
following workarounds:
 Specific "long" credentials, for example, <domain>\administrator, in the
promotion wizard or the promotion answer files.

On Windows 8.1 and Windows Server 2012 R2 computers, configure the DNS
search suffixes, so that when the DNS search suffixes are concatenated with
the provided NetBIOS domain name, they can be resolved to the fully
qualified DNS name of the Active Directory domain that hosts the user
account being used to perform the authenticated operation.

７ Note

This assumes that the NetBIOS name that is specified in credential "UI"
matches the left-most part of the target accounts DNS domain name.

Join the computer being prompted as a member computer in the target

domain, and then retry the promotion.

Temporarily enable NetBIOS over TCP/IP in order to complete the promotion.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Deployment and operation of Active
Directory domains that are configured
by using single-label DNS names
Article • 02/19/2024

This article contains information about the deployment and operation of Active
Directory (AD) domains that are configured by using single-label DNS names.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2, Windows
Server 2016, Windows Server 2019, Windows 10, version 1809
Original KB number: 300684

Summary
The wish to remove the single label domain configuration is a frequent reason to
rename a domain. The application compatibility information in this article applies to all
scenarios in which you might consider renaming a domain.

For the following reasons, the best practice is to create new Active Directory domains
that have fully qualified DNS names:

Single-label DNS names cannot be registered by using an Internet registrar.

Client computers and domain controllers that are joined to single-label domains
require additional configuration to dynamically register DNS records in single-label
DNS zones.

Client computers and domain controllers may require additional configuration to

resolve DNS queries in single-label DNS zones.

Some server-based applications are incompatible with single-label domain names.

Application support may not exist in the initial release of an application, or support
may be dropped in a future release.

Transitioning from a single-label DNS domain name to a fully qualified DNS name
is non-trivial and consists of two options. Either migrate users, computers,
groups, and other states to a new forest. Or, do a domain rename of the existing
domain. Some server-based applications are incompatible with the domain rename
feature that is supported in Windows Server 2003 and newer domain controllers.
These incompatibilities either block the domain rename feature or make the use of
 the domain rename feature more difficult when you try to rename a single-label
DNS name to a fully qualified domain name.

The Active Directory Installation Wizard (Dcpromo.exe) in Windows Server 2008

warns against creating new domains that have single-label DNS names. Because
there's no business or technical reason to create new domains that have single-
label DNS names, the Active Directory Installation Wizard in Windows Server 2008
R2 explicitly blocks creating such domains.

Examples of applications that are incompatible with domain renaming include, but
aren't limited to, the following products:

Microsoft Exchange 2000 Server

Microsoft Exchange Server 2007
Microsoft Exchange Server 2010
Microsoft Exchange Server 2013
Microsoft Internet Security and Acceleration (ISA) Server 2004
Microsoft Live Communications Server 2005
Microsoft Operations Manager 2005
Microsoft SharePoint Portal Server 2003
Microsoft Systems Management Server (SMS) 2003
Microsoft Office Communications Server 2007
Microsoft Office Communications Server 2007 R2
Microsoft System Center Operations Manager 2007 SP1
Microsoft System Center Operations Manager 2007 R2
Microsoft Lync Server 2010
Microsoft Lync Server 2013

More information
Best-practice Active Directory domain names consist of one or more subdomains that
are combined with a top-level domain that is separated by a dot character ("."). The
following ones are some examples:

contoso.com
corp.contoso.com

Single-label names consist of a single word like "contoso."

The top-level domain occupies the rightmost label in a domain name. Common top-
level domains include the following:

.com
 .net
.org
Two-letter country code top-level domains (ccTLD) such as .nz

Active Directory domain names should consist of two or more labels for the current and
the future operating system and for application experience and reliability.

Invalid Top Level domain queries reported by the ICANN Security and Stability Advisory
Committee can be found at Invalid Top Level Domain Queries at the Root Level of the
Domain Name System .

DNS name registration with an Internet

registrar
We recommend that you register DNS names for the top-most internal and external
DNS namespaces with an Internet registrar. Which includes the forest root domain of
any Active Directory forests unless such names are subdomains of DNS names that are
registered by your organization name (For example, the forest root domain
"corp.example.com" is a subdomain of an internal "example.com." namespace.) When
you register your DNS names with an Internet registrar, this lets Internet DNS servers
resolve your domain now or at some point over the life of your Active Directory forest.
And, this registration helps prevent possible name collisions by other organizations.

Possible symptoms when clients can't

dynamically register DNS records in a single-
label forward lookup zone
If you use a single-label DNS name in your environment, clients may be unable to
dynamically register DNS records in a single-label forward lookup zone. Specific
symptoms vary according to the version of Microsoft Windows that is installed.

The following list describes the symptoms that may occur:

After you configure Microsoft Windows for a single label domain name, all servers
that have the domain controller role may be unable to register DNS records. The
System log of the domain controller may consistently log NETLOGON 5781
warnings that resemble the following example:

７ Note
 Status code 0000232a maps to the following error code:

DNS_ERROR_RCODE_SERVER_FAILURE

The following additional status codes and error codes may appear in log files such
as Netdiag.log:

DNS Error Code: 0x0000251D = DNS_INFO_NO_RECORDS

DNS_ERROR_RCODE_ERROR
RCODE_SERVER_FAILURE

Windows-based computers that are configured for DNS dynamic updates won't
register in a single-label domain. Warning events that resemble the following
examples are recorded in the System log of the computer:

How to enable Windows-based clients to do

queries and dynamic updates with single-label
DNS zones
By default, Windows doesn't send updates to top-level domains. However, you can
change this behavior by using one of the methods that are described in this section. Use
one of the following methods to enable Windows-based clients to do dynamic updates
to single-label DNS zones.

Also without modification, an Active Directory domain member in a forest that contains
no domains that have single-label DNS names doesn't use the DNS Server service to
locate domain controllers in domains that have single-label DNS names that are in other
forests. Client access to the domains that have single-label DNS names fails if NetBIOS
name resolution isn't configured correctly.

Method 1: Use Registry Editor

Domain controller locator configuration for Windows XP Professional and later
versions of Windows

） Important

This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
 added protection, back up the registry before you modify it. Then, you can
restore the registry if a problem occurs. For more information, see How to
back up and restore the registry in Windows .

On a Windows-based computer, an Active Directory domain member requires

additional configuration to support single-label DNS names for domains.
Specifically, the domain controller locator on the Active Directory domain member
doesn't use the DNS server service to locate domain controllers in a domain that
has a single-label DNS name unless that Active Directory domain member is joined
to a forest that contains at least one domain, and this domain has a single-label
DNS name.

To enable an Active Directory domain member to use DNS to locate domain

controllers in domains that have single-label DNS names that are in other forests,
follow these steps:

1. Select Start, select Run, type regedit, and then select OK.

2. Locate and then select the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. In the details pane, locate the AllowSingleLabelDnsDomain entry. If the

AllowSingleLabelDnsDomain entry doesn't exist, follow these steps:
a. On the Edit menu, point to New, and then select DWORD Value.
b. Type AllowSingleLabelDnsDomain as the entry name, and then press
ENTER.

4. Double-click the AllowSingleLabelDnsDomain entry.

5. In the Value data box, type 1, and then select OK.

6. Exit Registry Editor.

DNS client configuration

） Important

This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
added protection, back up the registry before you modify it. Then, you can
restore the registry if a problem occurs. For more information, see How to
back up and restore the registry in Windows .
Active Directory domain members and domain controllers that are in a domain
that has a single-label DNS name typically must dynamically register DNS records
in a single-label DNS zone that matches the DNS name of that domain. If an Active
Directory forest root domain has a single-label DNS name, all domain controllers
in that forest typically must dynamically register DNS records in a single-label DNS
zone that matches the DNS name of the forest root.

By default, Windows-based DNS client computers don't attempt dynamic updates

of the root zone "." or of single-label DNS zones. To enable Windows-based DNS
client computers to try dynamic updates of a single-label DNS zone, follow these
steps:

1. Select Start, select Run, type regedit, and then select OK.

2. Locate and then select the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters

3. In the details pane, locate the UpdateTopLevelDomainZones entry. If the

UpdateTopLevelDomainZones entry doesn't exist, follow these steps:
a. On the Edit menu, point to New, and then select DWORD Value.
b. Type UpdateTopLevelDomainZones as the entry name, and then press
ENTER.

4. Double-click the UpdateTopLevelDomainZones entry.

5. In the Value data box, type 1, and then select OK.

6. Exit Registry Editor.

These configuration changes should be applied to all domain controllers and

members of a domain that have single-label DNS names. If a domain that has a
single-label domain name is a forest root, these configuration changes should be
applied to all the domain controllers in the forest, unless the separate zones
_msdcs. ForestName, _sites. ForestName, _tcp. ForestName, and_udp. ForestName
are delegated from the ForestName zone.

For the changes to take effect, restart the computers where you changed the
registry entries.

７ Note
For Windows Server 2003 and later versions, the
UpdateTopLevelDomainZones entry has moved to the following registry
 subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient

On a Microsoft Windows 2000 SP4-based domain controller, the computer

will report the following name registration error in the System event log if
the UpdateTopLevelDomainZones setting is not enabled:
On a Windows 2000 SP4-based domain controller, you must restart your
computer after you add the UpdateTopLevelDomainZones setting.

Method 2: Use Group Policy

Use Group Policy to enable the Update Top Level Domain Zones policy and the Location
of the DCs hosting a domain with single label DNS name policy as specified in the
following table under the folder location on the root domain container in Users and
Computers, or on all organizational units (OUs) that host computer accounts for
member computers, and for domain controllers in the domain.

ﾉ Expand table

Policy Folder location

Update Top Level Domain Zones Computer Configuration\Administrative

Templates\Network\DNS Client

Location of the DCs hosting a Computer Configuration\Administrative

domain with single label DNS Templates\System\Net Logon\DC Locator DNS Records
name

７ Note

These policies are supported only on Windows Server 2003-based computers and
on Windows XP-based computers.

To enable these policies, follow these steps on the root domain container:

1. Select Start, select Run, type gpedit.msc, and then select OK.
2. Under Local Computer Policy, expand Computer Configuration.
3. Expand Administrative Templates.
4. Enable the Update Top Level Domain Zones policy. To do it, follow these steps:
a. Expand Network.
b. Select DNS Client.
c. In the details pane, double-click Update Top Level Domain Zones.
 d. Select Enabled.
e. Select Apply, and then select OK.
5. Enable the Location of the DCs hosting a domain with single label DNS name
policy. To do this, follow these steps:
a. Expand System.
b. Expand Net Logon.
c. Select DC Locator DNS Records.
d. In the details pane, double-click Location of the DCs hosting a domain with
single label DNS name.
e. Select Enabled.
f. Select Apply, and then select OK.
6. Exit Group Policy.

On Windows Server 2003-based and later versions DNS servers, make sure that root
servers aren't created unintentionally.

On Windows 2000-based DNS servers, you may have to delete the root zone "." to have
the DNS records correctly declared. The root zone is automatically created when the
DNS server service is installed because the DNS server service can't reach the root hints.
This issue was corrected in later versions of Windows.

Root servers may be created by the DCpromo Wizard. If the "." zone exists, a root server
has been created. For name resolution to work correctly, you may have to remove this
zone.

New and modified DNS policy settings for

Windows Server 2003 and later versions
The Update Top Level Domain Zones policy

If this policy is specified, it creates a REG_DWORD UpdateTopLevelDomainZones entry

under the following registry subkey: HKLM\Software\Policies\Microsoft\Windows
NT\DNSClient

The following are the entry values for UpdateTopLevelDomainZones : - Enabled (0x1).
A 0x1 setting means that computers may try to update the TopLevelDomain zones.
That is, if the UpdateTopLevelDomainZones setting is enabled, computers to which
this policy is applied send dynamic updates to any zone that is authoritative for the
resource records that the computer must update, except for the root zone. -
Disabled (0x0). A 0x0 setting means that computers aren't permitted to try to
update the TopLevelDomain zones. That is, if this setting is disabled, computers to
which this policy is applied don't send dynamic updates to the root zone or to the
 top-level domain zones that are authoritative for the resource records that the
computer must update. If this setting isn't configured, the policy isn't applied to
any computers, and computers use their local configuration.

The Register PTR Records policy

A new possible value, 0x2, of the REG_DWORD RegisterReverseLookup entry was

added under the following registry subkey:
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient

The following are the entry values for RegisterReverseLookup : - 0x2. Register only if
"A" record registration succeeds. Computers try to implement PTR resource
records registration only if they successfully registered the corresponding "A"
resource records. - 0x1. Register. Computers try to implement PTR resource
records registration whatever the success of the "A" records registration. - 0x0.
Don't register. Computers never try to implement PTR resource records
registration.

References
DNS namespace planning

Unable to select DNS Server role when adding a domain controller into an existing
Active Directory domain

ADMT Guide: Migrating and Restructuring Active Directory Domains

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active
Directory Domains

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain Controller rename doesn't
rename all AD DFSR SYSVOL objects
Article • 02/19/2024

This article provides resolutions to fix the issue where the domain controller rename
doesn't rename all AD DFSR SYSVOL objects.

Applies to: Windows Server 2003

Original KB number: 2001271

Symptoms
The SYSVOL msDFSR-Member container used by DFS Replication (DFSR) isn't updated
when a domain controller is renamed. For example, when renaming a DC named
"OldName" to a DC named "NewName", the following object doesn't get renamed:

CN=OLDNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-

Globalsettings,CN=System,DC=contoso,DC=com

File replication will continue to work correctly and normally, and sysvol folder won't be
affected for group policy processing or scripts.

However, the CN won't be updated or removed during later demotions or via Metadata
Cleanup. This will leave orphaned DFSR topology objects in the Active Directory domain
indefinitely. In addition, if a new domain controller - with the previously renamed DC's
old name - were to be promoted in the domain, it would take over the old object and
temporarily stop replication on the renamed domain controller until an administrator
manually recreated a new object for the renamed domain controller using
ADSIEDIT.MSC.

Cause
A code defect in the domain controller rename process.

Resolution
Workaround 1:

Before running DCPROMO.EXE, rename computers to the final intended name using the
System control panel applet or NETDOM.EXE.
Workaround 2:

When renaming an existing DC, first demote it gracefully with DCPROMO.EXE, rename it,
then promote it back to being a DC.

Workaround 3:

Use ADSIEDIT.MSC to correct the AD objects manually, using the following steps:

1. Sign in as a Domain Administrator on a DC in the affected domain.

2. Start ADSIEDIT.MSC.

3. Connect to the default naming context.

4. Navigate to the DFSR Topology container. For example, in a domain called

contoso.com , it will be:

CN=Topology,CN=Domain System Volume,CN=DFSR-

Globalsettings,CN=System,DC=contoso,DC=com

5. Rename the msDFSR-Member CN object that has the old computer name and give
it the new computer name.

Was: CN=OLDNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-

Globalsettings,CN=System,DC=contoso,DC=com

Change to: CN=NEWNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-

Globalsettings,CN=System,DC=contoso,DC=com

More information
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain controllers do not demote
gracefully when you use the Active
Directory Installation Wizard to force
demotion
Article • 02/19/2024

This article provides a workaround for an issue where domain controllers don't demote
when you use the Active Directory Installation Wizard (Dcpromo.exe) to force demotion.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 332199

Symptoms
Microsoft Windows 2000 or Microsoft Windows Server 2003 domain controllers may not
gracefully demote by using the Active Directory Installation Wizard (Dcpromo.exe).

Cause
This behavior may occur if a required dependency or operation fails. These include
network connectivity, name resolution, authentication, Active Directory directory service
replication, or the location of a critical object in Active Directory.

Resolution
To resolve this behavior, determine what is preventing the graceful demotion of the
Windows 2000 or the Windows Server 2003 domain controller, and then try to demote
the domain controller by using the Active Directory Installation Wizard again.

７ Note

For Windows Server 2008, the Directory Services Restore Mode (DSRM) is
unchanged from Windows Server 2003 with one exception. In Windows Server
2008, you can run the dcpromo/forceremoval command to forcibly remove AD DS
from a domain controller that is started in DSRM, just as you can in the AD DS
stopped state. A domain controller must still be started in DSRM to restore system
 state data from a backup. For more information about how to do this, see
Restartable AD DS Step-by-Step Guide.

Workaround
If you cannot resolve the behavior, you can use the following workarounds to perform a
forced demotion of the domain controller to preserve the installation of the operating
system and of any applications on it.

２ Warning

Before you use either of the following workarounds, make sure that the you can
successfully start in Directory Services Restore mode. Otherwise, you will not be
able to log on after you forcefully demote the computer. If you do not remember
the Directory Services Restore mode password, you can reset the password by
using the Setpwd.exe utility that is located in the Winnt\System32 folder. In
Windows Server 2003, the functionality of the Setpwd.exe utility has been
integrated into the Set DSRM Password command of the NTDSUTIL tool.

Windows 2000 domain controllers

1. Install the Q332199 hotfix on a Windows 2000 domain controller that is running
Service Pack 2 (SP2) or a later version, or install Windows 2000 Service Pack 4 (SP4).
SP2 and later versions support forced demotion. Then, restart your computer.

2. Click Start, click Run, and then type the command: dcpromo /forceremoval .

3. Click OK.

4. At the Welcome to the Active Directory Installation Wizard page, click Next.

5. If the computer that you are removing is a global catalog server, click OK in the
message window.

７ Note

Promote additional global catalogs in the forest or in the site if the domain
controller that you are demoting is a global catalog server, as needed.
 6. At the Remove Active Directory page, make sure that the This server is the last
domain controller in the domain check box is cleared, and then click Next.

7. At the Network Credentials page, type the name, password, and domain name for
a user account with enterprise administrator credentials in the forest, and then
click Next.

8. In Administrator Password, type the password and confirmed password that you
want to assign to the Administrator account of the local SAM database, and then
click Next.

9. On the Summary page, click Next.

10. Perform a metadata cleanup for the demoted domain controller on a surviving
domain controller in the forest.

If you removed a domain from the forest by using the remove selected domain
command in Ntdsutil, verify that all the domain controllers and the global catalog
servers in the forest have removed all the objects and the references to the domain that
you just removed before you promote a new domain into the same forest with the same
domain name. Tools such as Replmon.exe or Repadmin.exe from Windows 2000 Support
Tools may help you determine whether end-to-end replication has occurred. Windows
2000 SP3 and earlier global catalog servers are noticeably slower to remove objects and
naming contexts than Windows Server 2003 is.

Windows Server 2003 domain controllers

1. By default, Windows Server 2003 domain controllers support forced demotion.
Click Start, click Run, and then type the command: dcpromo /forceremoval .

2. Click OK.

3. At the Welcome to the Active Directory Installation Wizard page, click Next.

4. At the Force the Removal of Active Directory page, click Next.

5. In Administrator Password, type the password and confirmed password that you
want to assign to the Administrator account of the local SAM database, and then
click Next.

6. In Summary, click Next.

7. Perform a metadata cleanup for the demoted domain controller on a surviving

domain controller in the forest.
If you removed a domain from the forest by using the remove selected domain
command in Ntdsutil, verify that all the domain controllers and the global catalog
servers in the forest have removed all the objects and the references to the domain that
you just removed before you promote a new domain into the same forest with the same
domain name. Windows 2000 Service Pack 3 (SP3) and earlier global catalog servers are
noticeably slower to remove objects and naming contexts than Windows Server 2003 is.

If resource access control entries (ACEs) on the computer that you removed Active
Directory from were based on domain local groups, these permissions may have to be
reconfigured, because these groups will not be available to member or stand-alone
servers. If you plan to install Active Directory on the computer to make it a domain
controller in the original domain, you do not have to configure access control lists
(ACLs) any more. If you prefer to leave the computer as a member or stand-alone server,
any permissions that are based on domain local groups must be translated or replaced.

Windows Server 2003 Service Pack 1 enhancements

Windows Server 2003 SP1 enhances the dcpromo /forceremoval process. When dcpromo
/forceremoval is executed, a check is made to determine whether the domain controller

hosts an operations master role, is a Domain Name System (DNS) server, or is a global
catalog server. For each of these roles, the administrator receives a popup warning that
advises the administrator to take appropriate action.

If the domain controller can't start in normal mode

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

） Important

Follow these steps only as a last resort if the domain controller cannot start in
normal mode.
To remove Active Directory from a domain controller, follow these steps:

1. Restart the computer, and then press F8 to display the Windows 2000 Advanced
Options menu.

2. Choose Directory Services Restore Mode, press ENTER, and then press ENTER
again to continue restarting.

3. Modify the ProductType entry in the registry. To do this, follow these steps:

a. Click Start, click Run, type regedit, and then click OK.

b. Locate the registry subkey

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions .

c. In the right-pane, double-click ProductType.

d. Type ServerNT in the Value data box, and then click OK.

７ Note

If this value is not set correctly or is misspelled, you may receive the
following error message:System Process - License Violation: The system has
detected tampering with your registered product type. This is a violation of
your software license. Tampering with product type is not permitted.

e. Quit Registry Editor.

4. Restart the computer.

5. Log on with the administrator account and password that is used for Directory
Service Repair mode.

The computer will behave as a member server. However, there are still some
remaining files and registry entries on the computer that are associated with the
domain controller.

6. Start Registry Editor and locate the registry entry

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

If there is an entry for Src Root Domain Srv, right-click the value and then click
Delete. This value must be deleted so that the domain controller sees itself as the
only domain controller in the domain after promotion.
 ） Important

The above step is critical. Without it the re-promotion into the temporary AD
forest will not complete and you will not be able to log on to the domain
controller.

7. Remove the remaining files and registry entries. To do this, follow these steps:

a. Start the Active Directory Installation Wizard.

b. Install Active Directory to make the computer a domain controller for a new,
temporary domain, such as psstemp.deleteme.

７ Note

Make sure that you make the computer a domain controller in a different
forest.

c. After you install Active Directory, start the Active Directory Installation Wizard
again, and then remove Active Directory from the domain controller.

8. After you remove Active Directory from a domain controller, remove metadata that
is left in the domain. For more information about how to remove this metadata,
see How to remove data in Active Directory after an unsuccessful domain
controller demotion.

Status
Microsoft has tested and supports the forced demotion of domain controllers that are
running Windows 2000 or Windows Server 2003.

More information
The Active Directory Installation Wizard creates Active Directory domain controllers on
Windows 2000-based and Windows Server 2003-based computers. Operations that are
performed by the Active Directory Installation Wizard include the installation of new
services, changes to the startup values of existing services, and the transition to Active
Directory as a security and authentication realm.

With forced demotion, a domain administrator can forcibly remove Active Directory and
roll back locally held system changes without having to contact or replicate any locally
held changes to another domain controller in the forest.

Because forced demotion causes the loss of any locally held changes, use it only as a
last resort in production or test domains. You can forcibly demote domain controllers
when connectivity, name resolution, authentication, or replication engine dependencies
cannot be resolved so that graceful demotion can be performed. Valid scenarios for
forced demotions include the following:

There are no domain controllers currently available in the parent domain when you
try to demote the last domain controller in an immediate child domain.

The Active Directory Installation Wizard cannot complete because there is a name
resolution, authentication, replication engine, or Active Directory object
dependency that you cannot resolve after you perform detailed troubleshooting.

A domain controller has not replicated incoming Active Directory changes in

Tombstone Lifetime (Default Tombstone Lifetime is 60 days) number of days for
one or more naming contexts.

） Important

Do not recover such domain controllers unless they are the only chance of
recovery for a particular domain.

Time does not permit more detailed troubleshooting because you must
immediately bring into service the domain controller. Forced demotions may be
useful in lab and classroom environments where you can remove domain
controllers out of existing domains, yet you do not have to demote each domain
controller serially.

If you force the demotion of a domain controller, you will lose any unique changes that
reside in the Active Directory of the domain controller that you are forcibly demoting.
This includes the addition, deletion, or modification of users, computers, groups, trust
relationships, and Group Policy or Active Directory configuration that did not replicate
off before you ran the dcpromo /forceremoval command. Additionally, you will lose
changes to any one of the attributes on these objects, such as passwords for users,
computers, and trust relationships and group membership.

However, if you force the demotion of a domain controller, you return the operating
system to a state that is the same as the successful demotion of the last domain
controller in a domain (service start values, installed services, use of a registry based
SAM for the account database, computer is a member of a workgroup). Programs that
are installed on the demoted domain controller remain installed.

The System event log identifies forcibly demoted Windows 2000 domain controllers and
instances of the dcpromo /forceremoval operation by event ID 29234. For example: The
System event log identifies forcibly demoted Windows Server 2003 domain controllers
by event ID 29239. For example: After you use the dcpromo /forceremoval command,
metadata for the demoted computer is not deleted on surviving domain controllers. For
more information, see Clean up Active Directory Domain Controller server metadata.

The following are items that you must address, if applicable, after forcibly demoting a
domain controller:

1. Remove the computer account from the domain.

2. Verify that DNS records, such as A, CNAME, and SRV Records, are removed, and
remove them if they are present.
3. Verify that FRS member objects (FRS and DFS) are removed, and remove them if
they are present.
4. If the demoted computer is a member of any security groups, remove it from those
groups.
5. Remove any DFS references to the demoted server, such as links or root replicas.
6. A surviving domain controller must seize any operations master roles, also known
as flexible single master operations or FSMO, that were previously held by the
forcibly demoted domain controller. For more information, see Transfer or seize
Operation Master roles in Active Directory Domain Services.
7. If the domain controller that you are demoting is a DNS server or global catalog
server, you must create a new GC or DNS server to satisfy load balancing, fault
tolerance, and configuration settings in the forest.
8. When you use the remove selected server command in NTDSUTIL, the NTDSDSA
object, the parent object for incoming connections to the domain controller that
you forcibly demoted is removed. The command does not remove the parent
server objects that appear in the Sites and Services snap-in. Use the Active
Directory Sites and Services MMC snap-in to remove the server object if the
domain controller will not be promoted into the forest with the same computer
name.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
DCDIAG.EXE /E or /A or /C expected
errors
Article • 02/19/2024

This article helps fix errors that occur when you run DCDIAG.EXE /E or /A or /C
commands.

Applies to: Windows Server 2012 R2

Original KB number: 2512643

Symptoms
Consider the following scenario:

You administer an AD environment. There may be a mixture of Windows Server 2003,

Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 DCs.

When running DCDIAG.EXE /E (or /A or /C ) on Windows Server 2008 or Windows Server

2008 R2 (included with the operating systems), you see the following errors against all
Windows Server 2003 DCs:

Starting test: Services

Invalid service type: RpcSs on DCDIAG-2003, current value
WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS
......................... DCDIAG-2003 failed test Services

When running DCDIAG.EXE /E (or /A or /C ) on Windows Server 2008 or Windows Server

2008 R2 (included with the operating systems), you see the following errors against all
Win2008 and Win2008 R2 DCs:

Starting test: FrsEvent

The event log File Replication Service on server
dcdiag-2008.margiestravel.com could not be queried, error 0x6ba
"The RPC server is unavailable."
......................... dcdiag-2008 failed test FrsEvent

Starting test: DFSREvent

The event log DFS Replication on server
dcdiag-2008r2.margiestravel.com could not be queried, error 0x6ba
 "The RPC server is unavailable."
......................... dcdiag-2008r2 failed test DFSREvent

Starting test: KccEvent

The event log Directory Service on server
dcdiag-2008.margiestravel.com could not be queried, error 0x6ba
"The RPC server is unavailable."
......................... dcdiag-2008 failed test KccEvent

Starting test: SystemLog

The event log System on server
dcdiag-2008.margiestravel.com could not be queried, error 0x6ba
"The RPC server is unavailable."
......................... dcdiag-2008 failed test SystemLog

When running DCDIAG.EXE /E (or /A or /C) on Windows Server 2003 (included with the
Support Tools out-of-band install):

No errors are logged for any of the DCs, regardless of OS.

When running DCDIAG.EXE /C (which includes /test:verifyenterprisereferences ) on

Windows Server 2008 or Windows Server 2008 R2, and the Domain Functional Mode is
Windows Server 2008 or higher, and FRS is still being used to replicate SYSVOL, you see
the following errors:

Starting test: VerifyEnterpriseReferences

The following problems were found while verifying various important DN references.
Note, that these problems
can be reported because of latency in replication. So follow up to resolve the
following problems, only if
the same problem is reported on all DCs for a given domain or if the problem
persists after replication has
had reasonable time to replicate changes.
[1] Problem: Missing Expected Value
Base Object: CN=SRV-01,OU=Domain Controllers,DC=margiestravel,DC=com
Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862
[2] Problem: Missing Expected Value
Base Object: CN=SRV-02,OU=Domain Controllers,DC=margiestravel,DC=com
 Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862
LDAP Error 0x20 (32) - No Such Object.
......................... SRV-01 failed test VerifyEnterpriseReferences

When running DCDIAG.EXE /C (which includes /test:outboundsecurechannels ) and you

specify /testdomain:<your trusted domain> on Windows Server 2008, or on Windows
Server 2008 R2 you see the following errors:

Testing server: Default-First-Site-Name\SRV-01

Starting test: OutboundSecureChannels
[SRV-01] Does not have downlevel trust object for [contoso.com]
[SRV-01] Does not have uplevel trust object for [contoso.com]
[SRV-02] Does not have downlevel trust object for [contoso.com]
[SRV-02] Does not have uplevel trust object for [contoso.com]
......................... SRV-01 failed test OutboundSecureChannels

Cause
All of these behaviors are expected.

The Windows Server 2008/200R2 versions of DCDIAG are designed to test RPCSS
for the Windows Server 2008 shared process setting -not the previous isolated
process setting used in Windows Server 2003 and older operating systems. The
tool doesn't distinguish between OSs for this service.

The Windows Server 2008/200R2 versions of DCDIAG assume that a Windows

Server 2008 domain functional level means the DCs are replicating SYSVOL with
DFSR.

The Windows Server 2008/200R2 versions of DCDIAG don't correctly test trust
health

Windows Server 2008/2008 R2 doesn't allow remote connectivity to the event log
based on default firewall rules.

The Windows Server 2003 version of DCDIAG doesn't report back an error if it can't
connect to the event log; it only reports if it connects and finds errors.
 The Windows Server 2003 version of DCDIAG doesn't test the RPCSS service
configuration.

Resolution
There are multiple workarounds to these issues:

Ignore all these errors when running DCDIAG.

To stop the event log-related errors, enable the built-in incoming firewall rules on
DCs so that the event logs can be accessed remotely:

Remote Event Log Management (NP-In)

Remote Event Log Management (RPC)
Remote Event Log Management (RPC-EPMAP)

This can be done through the "Windows Firewall with Advanced Security"
snap-in (WF.MSC), using the firewall group policy (Computer Configuration\
Policies\ Windows Settings\ Security Settings\ Windows Firewall with
Advanced Security), or by using NETSH.EXE ADVFIREWALL .

To stop the RPCSS service error, you can opt out of the test with /SKIP:SERVICES .
There are caveats to this, see More Information. It's better to ignore this specific
error altogether when it's returned from Win2003 DCs.

It's expected and normal for this service's behavior type to be 0x10 (isolated) on
Windows Server 2003 and 0x20 (shared) on Windows Server 2008 and later. Don't
change it based on what DCDIAG says unless you're running the version of
DCDIAG that goes with that OS. Between Windows Server 2003 and Windows
Server 2008, the behavior changed for the RPC service, but there was nothing yet
to share in that svchost.exe process. In Windows Server 2008 R2, the new
RPCEptMapper service was added to that shared svchost process. You can see who
would launch in that same process by looking for this value in the service registry
keys:
%systemroot%\system32\svchost.exe -k RPCSS.

Do not change the service type on Windows Server 2003 to stop the error. There
may be unexpected issues long-term as this isn't a tested configuration. These
issues would be difficult to identify or trace back to this root cause. Long-term
solution to the RPCSS service issue: replace the remaining Windows Server 2003
servers with a later operating system.
 To stop the OutboundSecureChannels errors, use /skip:outboundsecurechannels .
The tests aren't valid and can be instead tested with NETDOM.EXE and NLTEST.EXE .

To stop the VerifyEnterpriseReferences errors, migrate your SYSVOL from FRS to

DFSR. Since you are using a native Windows Server 2008 or later domain, FRS is no
longer recommended for SYSVOL replication and nothing is preventing you from
replacing the deprecated FRS system. See
https://technet.microsoft.com/library/dd640019.aspx .

More information
The Windows Server 2008/2008 R2 DCDIAG Services test checks for the following
services to be running, configured with default start options, and configured with
default process types:

７ Note

These are the true service names in the registry under

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

RPCSS - Start Automatically - Shared Process

EVENTSYSTEM - Start Automatically - Shared Process
DNSCACHE - Start Automatically - Shared Process
NTFRS - Start Automatically - Own Process
ISMSERV - Start Automatically - Shared Process
KDC - Start Automatically - Shared Process
SAMSS - Start Automatically - Shared Process
SERVER - Start Automatically - Shared Process
WORKSTATION - Start Automatically - Shared Process
W32TIME - Start Manually or Automatically - Shared Process
NETLOGON - Start Automatically - Shared Process
(If domain functional level is Windows Server 2008 or later)
DFSR - Start Automatically - Own Process
(If target is Windows Server 2008 or later)
NTDS - Start Automatically - Shared Process
(If using SMTP-based AD replication)
IISADMIN - Start Automatically - Shared Process
SMTPSVC - Start Automatically - Shared Process
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message occurs when you demote
a domain controller
Article • 02/19/2024

This article provides a solution to an issue where demoting a domain controller by using
the Active Directory Installation wizard (Dcpromo.exe) fails.

Applies to: Windows Server 2012 R2

Original KB number: 282272

Symptoms
When you demote a Windows domain controller by using the Dcpromo.exe, you may
receive the following error message:

This domain controller holds the last replica of the following application directory
partitions:
DC=MSTAPI,DC= yourdomain,DC=com

Cause
This behavior can occur if you installed the domain controller by using the Configure
Your Server wizard. When you use this wizard, it automatically creates a program
partition or a non-domain naming context called DC=MSTAPI,DC=
yourdomain,DC=com.

Resolution
If you created the partition by using the Configure Your Server wizard, and you used
the default name of Mstapi, if this name is not in use, use the Tapicfg.exe tool to remove
this name. To do so, run the following command, where <your_domain.com> is your
domain DNS name:

Console

tapicfg remove /directory:mstapi.<your_domain.com>

If the partition was created manually, or if it was created by using another program, you
can remove it by using the Ntdsutil utility:
 1. Open a command prompt, and then type ntdsutil.

2. From the Ntdsutil prompt, type partition management .

3. In the Domain Management window, type connections .

4. Type connect to server <yourservername> .

After the binding message appears, you will have a successful connection to your
server.

5. In the Server Connections window, type quit .

6. In the Domain Management window, type list . A list of the naming contexts on
this server appears.

7. To remove the application directory partition replica, type remove nc replica

<ApplicationDirectoryPartition> <DomainController> .

8. At the Ntdsutil prompt, type Q , and then press ENTER until you are returned to the
CMD command prompt. You can now successfully demote this domain controller.
You may have to restart this domain controller before you start the Active
Directory Installation wizard again.

More information
Windows supports program naming contexts, also referred to as non-domain naming
contexts. This feature allows the Microsoft Active Directory directory service to host
dynamic data without impacting network performance by enabling you to control the
scope of replication and placement of replicas. With Active Directory services, you can
create a new type of naming context or partition, referred to as the application partition.
This naming context can contain a hierarchy of any type of object except security
principals (users, groups, and computers), and it can be configured to replicate to any
set of domain controllers in the forest that are not necessarily all in the same domain.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

FSMO placement and optimization on
Active Directory domain controllers
Article • 02/19/2024

Certain operations are best done on a single domain controller. This article describes the
placement of Active Directory Flexible Single-Master Operation (FSMO) roles in the
domain and forest for these operations.

Applies to: Windows Server 2012 R2

Original KB number: 223346

More information
Certain domain and enterprise-wide operations aren't well suited to multi-master
updates. In these situations, the operations must be done on a single domain controller
in the domain or in the forest. Having a single-master owner defines a well-known
target for critical operations, and prevents possible conflicts or latency created by multi-
master updates. It means that the relevant FSMO role owner must be online,
discoverable, and available on the network by computers that must perform FSMO-
dependent operations.

When the Active Directory Installation Wizard (Dcpromo.exe) creates the first domain in
a new forest, the wizard adds five FSMO roles. A forest with one domain has five roles.
The Active Directory Installation Wizard adds three domain-wide roles on the first
domain controller in each additional domain in the forest. Additionally, infrastructure
master roles exist for each application partition. It includes the default domain and the
forest-wide DNS application partitions that are created on Windows Server 2003 and
later domain controllers. The operations masters and their scope are shown in the
following table.

ﾉ Expand table

FSMO Role Scope Function and availability requirements

Schema Enterprise - Used to introduce manual and programmatic schema updates. It

Master includes those updates that are added by Windows ADPREP
/FORESTPREP , by Microsoft Exchange, and by other applications
that use Active Directory Domain Services (AD DS).
- Must be online when schema updates are performed.
FSMO Role Scope Function and availability requirements

Domain Enterprise - Used to add and to remove domains and application partitions
Naming to and from the forest.
Master - Must be online when domains and application partitions in a
forest are added or removed.

Primary Domain - Receives password updates when passwords are changed for the
Domain computer and for user accounts that are on replica domain
Controller controllers.
- Consulted by replica domain controllers that service
authentication requests that have mismatched passwords.
- Default target domain controller for Group Policy updates.
- Target domain controller for legacy applications that perform
writable operations and for some admin tools.
- Must be online and accessible 24 hours a day, seven days a
week.

RID Domain - Allocates active and standby RID pools to replica domain
controllers in the same domain.
- Must be online in the following situations:

when newly promoted domain controllers must obtain a

local RID pool that's required to advertise
when existing domain controllers must update their current
or standby RID pool allocation.

Infrastructure Domain - Updates cross-domain references and phantoms from the global
Master catalog. For more information, see Phantoms, tombstones, and
Application the infrastructure master
partition - A separate infrastructure master is created for each application
partition, including the default forest-wide and domain-wide
application partitions created by Windows Server 2003 and later
domain controllers.

The Windows Server 2008 R2 ADPREP /RODCPREP command targets

the infrastructure master role for default DNS application in the
forest root domain. The DN path for this role holder is:

CN=Infrastructure,DC=DomainDnsZones,DC=<forest root
domain>,DC=<top level domain>
CN=Infrastructure,DC=ForestDnsZones,DC=<forest root
domain>,DC=<top level domain>

FSMO availability and placement

The Active Directory Installation Wizard does the initial placement of roles on domain
controllers. This placement is frequently correct for directories that have just a few
domain controllers. In a directory that has many domain controllers, the default
placement may not be the best match for your network.

Consider the following factors in your selection criteria:

It's easier to keep track of FSMO roles if you host them on fewer computers.

Place roles on domain controllers that can be accessed by the computers, which
need access to a given role, especially on networks that aren't fully routed. For
example, to obtain a current or standby RID pool, or perform pass-through
authentication, all DCs need network access to the RID and PDC role holders in
their respective domains.

You should transfer (not seize) the role to the new domain controller under the
following conditions:
a role must be moved to a different domain controller
the current role holder is online and available

FSMO roles should only be seized if the current role holder isn't available. For
more information, see Managing Operations Master Roles.

FSMO roles assigned to domain controllers that are offline or in an error state only
have to be transferred or seized if role-dependent operations are being done. If
the role holder can be made operational before the role is needed, you may delay
seizing the role. If role availability is critical, transfer or seize the role as required.
The PDC role in each domain should always be online.

Select a direct intrasite replication partner for existing role holders to act as a
standby role holder. If the primary owner goes offline or fails, transfer or seize the
role to the designated standby FSMO domain controller as required.

General recommendations for FSMO placement

Place the schema master on the PDC of the forest root domain.

Place the domain naming master on the forest root PDC.

The addition or removal of domains should be a tightly controlled operation. Place

this role on the forest root PDC. Certain operations that use the domain naming
master fail if the domain naming master isn't available. These operations include
creating or removing domains and application partitions. On a domain controller
that runs Microsoft Windows 2000, the domain naming master must also be
hosted on a global catalog server. On domain controllers that run Windows Server
2003 or later versions, the domain naming master doesn't have to be a global
catalog server.

Place the PDC on your best hardware in a reliable hub site that contains replica
domain controllers in the same Active Directory site and domain.

In large or busy environments, the PDC frequently has the highest CPU usage,
because it handles pass-through authentication and password updates. If high CPU
usage becomes a problem, identify the source. The source includes applications or
computers that may be performing too many operations (transitively) targeting the
PDC. Techniques to reduce CPU include:
Adding more or faster CPUs
Adding more replicas
Adding more memory to cache Active Directory objects
Removing the global catalog to avoid global catalog lookups
Reducing the number of incoming and outgoing replication partners
Increasing the replication schedule
Reducing authentication visibility by using LDAPSRVWEIGHT and
LDAPPRIORITY, and by using the Randomize1CList feature.

All domain controllers in a particular domain, and computers that run applications
and admin tools that target the PDC, must have network connectivity to the
domain PDC.

Place the RID master on the domain PDC in the same domain.

RID master overhead is light, especially in mature domains that have already
created the bulk of their users, computers, and groups. The domain PDC typically
receives the most attention from administrators. Co-locating this role on the PDC
helps ensure reliable availability. Make sure that existing domain controllers and
newly promoted domain controllers have network connectivity to obtain active
and standby RID pools from the RID master, especially the domain controllers
promoted in remote or staging sites.

Legacy guidance suggests placing the infrastructure master on a non-global

catalog server. There are two rules to consider:

Single domain forest:

In a forest that contains a single Active Directory domain, there are no

phantoms. So, the infrastructure master has no work to do. The infrastructure
 master may be placed on any domain controller in the domain, whether that
domain controller hosts the global catalog or not.

Multidomain forest:

If every domain controller in a domain that's part of a multi-domain forest also

hosts the global catalog, there are no phantoms or work for the infrastructure
master to do. The infrastructure master may be put on any domain controller in
that domain. Practically, most administrators host the global catalog on every
domain controller in the forest.

If every domain controller in a given domain that's located in a multi-domain

forest doesn't host the global catalog, the infrastructure master must be placed
on a domain controller that doesn't host the global catalog.

References
For more information, see How to use Windows Server cluster nodes as domain
controllers .

Articles about Operations Master roles:

Phantoms, tombstones, and the infrastructure master

Error when you run the Adprep /rodcprep command in Windows Server 2008

The NTDS Replication event 1586 occurs in one of the following situations:

the PDC FSMO role for a particular domain has been seized.
the PDC FSMO role for a particular domain has been transferred to a new domain
controller that wasn't a direct replication partner of the previous role holder.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy application rules for
domain controllers
Article • 02/19/2024

This article describes group policy application rules for domain controllers.

Applies to: Windows Server 2012 R2

Original KB number: 259576

Summary
Domain controllers pull some security settings only from group policy objects linked to
the root of the domain. Because domain controllers share the same account database
for the domain, certain security settings must be set uniformly on all domain controllers.
This ensures the members of the domain have a consistent experience regardless of
which domain controller they use to log on. Windows 2000 accomplishes this task by
allowing only certain setting in the group policy to be applied to domain controllers at
the domain level. This group policy behavior is different for member server and
workstations.

The following settings are applied to domain controllers in Windows 2000 only when
the group policy is linked to the Domain container:

All settings in Computer Configuration/Windows Settings/Security

Settings/Account Policies (This includes all of the Account Lockout, Password, and
Kerberos policies.)

The following three settings in Computer Configuration/Windows

Settings/Security Settings/Local Policies/Security Options:
Automatically log off users when logon time expires
Rename administrator account
Rename guest account

The following settings are applied to Windows Server 2003-based domain controllers
only when the group policy is linked to the domain container. (The settings are located
in Computer Configuration/Windows Settings/Security Settings/Local
Policies/Security Options.)

Accounts: Administrator account status

Accounts: Guest account status
Accounts: Rename administrator account
 Accounts: Rename guest account
Network security: Force logoff when logon hours expire

More information
These settings from group policy objects aren't applied on the Domain Controllers
organizational unit because a domain controller can be moved out of the Domain
Controllers organizational unit and into a different organizational unit. Using the
Domain container allows these setting to be applied regardless of in which
organizational unit the domain container resides.

The process for applying these settings on a domain controller includes:

The domain controller gathers the list of group policy objects by searching the
parent containers of the domain controller's Computer object.
The domain controller applies the settings listed earlier only if the group policy
object is linked to the Domain container.
If there are multiple group policy objects linked to the Domain container,
application of the group policy objects starts with the group policy object at the
bottom of the list and ends with the group policy object at the top. This results in
the group policy object at the top taking precedence over the others.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy preparation isn't
performed when you automatically
prepare an existing domain for
Windows Server 2012 R2
Article • 02/19/2024

This article describes an issue that Group Policy preparation isn't performed when you
automatically prepare an existing domain.

Applies to: Windows Server 2012 R2

Original KB number: 2737129

Symptoms
When you automatically prepare an existing domain for Windows Server 2012 R2 by
using Server Manager or the Install-AddsDomainController Windows PowerShell
cmdlet, Group Policy preparation isn't performed. Additionally, the following output is
displayed briefly when you use Install-AddsDomainController :

Adprep successfully updated the forest-wide information.

Adprep successfully updated the domain-wide information.

The new cross domain planning functionality for Group Policy, RSOP Planning Mode,
requires file system and Active Directory Domain Services permissions to be updated for
existing Group Policy Objects (GPOs).

７ Note

This output is not visible when you install Active Directory Domain Services (AD DS)
by using Server Manager, and the output is not logged.

Cause
This behavior is by design. The automated remote domain preparation capabilities that
are added in Windows Server 2012 don't alter the Group Policy preparation (Gpprep)
behavior that occurred in earlier operating systems.
Gpprep adds cross-domain planning functionality for Group Policy and Resultant Set of
Policy (RSoP) planning mode. This requires updating the file system in SYSVOL and
Active Directory permissions for existing group policies. If the environment already
contains custom or delegated permissions that were put in place manually by
administrators, Gpprep triggers replication of all Group Policy files in SYSVOL and may
deny RSOP functionality to delegated users until their permissions are re-created by
administrators.

Resolution
Domain administrators must run adprep.exe /domainprep /gpprep manually, just as they
had to do in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

More information
Administrators should run Gpprep only one time in the history of a domain. They
shouldn't run Gpprep every time that an upgrade occurs. Gpprep was introduced in
Windows Server 2003.

The Adprep.exe tool is included on the Windows Server 2012 media at \support\adprep.
This version of Adprep.exe supports remote preparation and doesn't have to run on the
infrastructure master operations master (also known as flexible single master operations
or FSMO) role, as it did in previous server operating systems.

For more information about legacy Adprep.exe commands, see Prepare Your
Infrastructure for Upgrade.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to upgrade Windows 2000 domain
controllers to Windows Server 2003
Article • 02/19/2024

This article discusses how to upgrade Microsoft Windows 2000 domain controllers to
Windows Server 2003 and how to add new Windows Server 2003 domain controllers to
Windows 2000 domains.

Applies to: Windows Server 2012 R2

Original KB number: 325379

Summary
This article discusses how to upgrade Microsoft Windows 2000 domain controllers to
Windows Server 2003 and how to add new Windows Server 2003 domain controllers to
Windows 2000 domains. For more information about how to upgrade domain
controllers to Windows Server 2008 or Windows Server 2008 R2, visit the following
Microsoft Web site:

Upgrade Domain Controllers: Microsoft Support Quick Start for Adding Windows Server
2008 or Windows Server 2008 R2 Domain Controllers to Existing Domains

Domain and forest inventory

Before you upgrade Windows 2000 domain controllers to Windows Server 2003 or
before you add new Windows Server 2003 domain controllers to a Windows 2000
domain, follow these steps:

1. Inventory the clients that access resources in the domain that host Windows Server
2003 domain controllers for compatibility with SMB signing:

Each Windows Server 2003 domain controller enables SMB signing in its local
security policy. Make sure that all network clients that use the SMB/CIFS protocol
to access shared files and printers in domains that host Windows Server 2003
domain controllers can be configured or upgraded to support SMB signing. If they
can't, temporarily disable SMB signing until updates can be installed or until the
clients can be upgraded to newer operating systems that support SMB signing. For
information about how to disable SMB signing, see the To disable SMB signing
section at the end of this step.
Action plans

The following list shows the action plans for popular SMB clients:

Microsoft Windows Server 2003, Microsoft Windows XP Professional,

Microsoft Windows 2000 Server, Microsoft Windows 2000 Professional, and
Microsoft Windows 98

No action is required.

Microsoft Windows NT 4.0 Install Service Pack 3 or later (Service Pack 6A is

recommended) on all Windows NT 4.0-based computers that access domains
that contain Windows Server 2003-based computers. Instead, temporarily
disable SMB signing on Windows Server 2003 domain controllers. For
information about how to disable SMB signing, see the To disable SMB
signing section at the end of this step.

Microsoft Windows 95

Install the Windows 9 x directory service client on the Windows 95-based

computers or temporarily disable SMB signing on Windows Server 2003
domain controllers. The original Win9 x directory service client is available on
the Windows 2000 Server CD-ROM. However, that client add-on has been
replaced by an improved Win9 x directory service client. For information
about how to disable SMB signing, see the To disable SMB signing section at
the end of this step.

Microsoft Network Client for MS-DOS and Microsoft LAN Manager clients

The Microsoft Network Client for MS-DOS and the Microsoft LAN Manager
2.x network client may be used to provide access to network resources, or
they may be combined with a bootable floppy disk to copy operating system
files and other files from a shared directory on a file server as part of a
software installation routine. These clients don't support SMB signing. Use an
alternative installation method, or disable SMB signing. For information about
how to disable SMB signing, see the To disable SMB signing section at the
end of this step.

Macintosh clients

Some Macintosh clients aren't SMB signing compatible and will receive the
following error message when they try to connect to a network resource:

- Error -36 I/O

 Install updated software if it's available. Otherwise, disable SMB signing on
Windows Server 2003 domain controllers. For information about how to
disable SMB signing, see the To disable SMB signing section at the end of
this step.

Other third-party SMB clients

Some third-party SMB clients don't support SMB signing. Consult your SMB
provider to see if an updated version exists. Otherwise, disable SMB signing
on Windows Server 2003 domain controllers.

To disable SMB signing

If software updates can't be installed on affected domain controllers that are

running Windows 95, Windows NT 4.0, or other clients that were installed before
the introduction of Windows Server 2003, temporarily disable the SMB service
signing requirements in Group Policy until you can deploy updated client software.

You can disable SMB service signing in the following node of Default Domain
Controllers policy on the domain controllers organizational unit: Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft Network Server:

Digitally sign communications (always)

If domain controllers aren't located in the domain controller's organizational unit,

you must link the default domain controller's Group Policy object (GPO) to all
organizational units that host Windows 2000 or Windows Server 2003 domain
controllers. Or, you can configure SMB service signing in a GPO that is linked to
those organizational units.

2. Inventory the domain controllers that are in the domain and in the forest:

a. Make sure that all the Windows 2000 domain controllers in the forest have
installed all the appropriate hotfixes and service packs.

Microsoft recommends that all the Windows 2000 domain controllers run the
Windows 2000 Service Pack 4 (SP4) or later operating systems. If you can't fully
deploy Windows 2000 SP4 or later, all the Windows 2000 domain controllers
must have an Ntdsa.dll file whose date stamp and version are later than June 4,
2001 and 5.0.2195.3673.

By default, Active Directory administrative tools on Windows 2000 SP4,

Windows XP, and Windows Server 2003 client computers use Lightweight
Directory Access Protocol (LDAP) signing. If such computers use (or fall back to)
 NTLM authentication when they remotely administer Windows 2000 domain
controllers, the connection won't work. To resolve this behavior, remotely
administered domain controllers should have a minimum of Windows 2000 SP3
installed. Otherwise you should turn off LDAP signing on the clients that run the
administration tools.

The following scenarios use NTLM authentication:

You administer Windows 2000 domain controllers that are located in an

external forest connected by an NTLM (non-Kerberos) trust.
You focus Microsoft Management Console (MMC) snap-ins against a
specific domain controller that is referenced by its IP address. For example,
you click Start, click Run, and then type the following command: dsa.msc
/server=ipaddress

To determine the operating system and the service pack revision level of Active
Directory domain controllers in an Active Directory domain, install the Windows
Server 2003 version of Repadmin.exe on a Windows XP Professional or Windows
Server 2003 member computer in the forest, and then run the following
repadmin command against a domain controller in each domain in the forest:

Console

>repadmin /showattr <name of the domain controller that is in the

target domain> ncobj:domain: /filter:"(&(objectCategory=computer)
(primaryGroupID=516))" /subtree
/atts:operatingSystem,operatingSystemVersion,operatingSystemServiceP
ack

DN: CN=NA-DC-01,organizational unit=Domain

Controllers,DC=company,DC=com
1> operatingSystem: Windows Server 2003
1> operatingSystemVersion: 5.2 (3718)
DN: CN=NA-DC-02,organizational unit=Domain
Controllers,DC=company,DC=com
1> operatingSystem: Windows 2000 Server
1> operatingSystemVersion: 5.0 (2195)
1> operatingSystemServicePack: Service Pack 1

７ Note

The domain controller's attributes do not track the installation of individual

hotfixes.

b. Verify the end-to-end Active Directory replication throughout the forest.

Verify that each domain controller in the upgraded forest replicates all its locally
held naming contexts with its partners consistently with the schedule that site
links or connection objects define. Use the Windows Server 2003 version of
Repadmin.exe on a Windows XP- or Windows Server 2003-based member
computer in the forest with the following arguments: All the domain controllers
in the forest must replicate Active Directory without error, and the values in the
"Largest Delta" column of the repadmin output shouldn't be significantly
greater than the replication frequency on the corresponding site links or
connection objects that are used by a given destination domain controller.

Resolve all replication errors between domain controllers that have failed to
inbound replicate in less than Tombstone Lifetime (TSL) number of days (by
default, 60 days). If replication can't be made to function, you may have to
forcibly demote the domain controllers and remove them from the forest by
using the Ntdsutil metadata cleanup command, and then promote them back
into the forest. You can use a forceful demotion to save both the operating
system installation and the programs that are on an orphaned domain
controller. For more information about how to remove orphaned Windows 2000
domain controllers from their domain, click the following article number to view
the article in the Microsoft Knowledge Base:

216498 How to remove data in Active Directory after an unsuccessful domain

controller demotion

Take this action only as a last resort to recover the installation of the operating
system and the installed programs. You'll lose unreplicated objects and
attributes on orphaned domain controllers including users, computers, trust
relationships, their passwords, groups, and group memberships.

Be careful when you try to resolve replication errors on domain controllers that
haven't replicated inbound changes for a particular Active Directory partition for
greater than tombstonelifetime number of days. When you do so, you may
reanimate objects that were deleted on one domain controller but for which
direct or transitive replication partners never received the deletion in the
previous 60 days.

Consider removing any lingering objects that reside on domain controllers that
haven't performed inbound replication in the last 60 days. Alternatively, you can
forcefully demote domain controllers that have not performed any inbound
replication on a given partition in tombstone lifetime number of days and
remove their remaining metadata from the Active Directory forest by using
 Ntdsutil and other utilities. Contact your support provider or Microsoft PSS for
additional help.

c. Verify that the contents of the Sysvol share are consistent.

Verify that the file system portion of group policy is consistent. You can use
Gpotool.exe from the Resource Kit to determine whether there are
inconsistencies in policies across a domain. Use Healthcheck from the Windows
Server 2003 support tools to determine whether the Sysvol share replica sets
function correctly in each domain.

If the contents of the Sysvol share are inconsistent, resolve all the
inconsistencies.

d. Use Dcdiag.exe from the support tools to verify that all the domain controllers
have shared Netlogon and Sysvol shares. To do so, type the following command
at a command prompt:

Console

DCDIAG.EXE /e /test:frssysvol

e. Inventory the operations roles.

The schema and infrastructure operations masters are used to introduce forest
and domain-wide schema changes to the forest and its domains that are made
by the Windows Server 2003 adprep utility. Verify that the domain controller
that hosts the schema role and infrastructure role for each domain in the forest
reside on live domain controllers and that each role owner has performed
inbound replication over all partitions since they were last restarted.

The DCDIAG /test:FSMOCHECK command can be used to view forest-wide and

domain-wide operational roles. Operations master roles that reside on non-
existent domain controllers should be seized to a healthy domain controller by
using NTDSUTIL. Roles that reside on unhealthy domain controllers should be
transferred if possible. Otherwise, they should be seized. The NETDOM QUERY FSMO
command doesn't identify FSMO roles that reside on deleted domain
controllers.

Verify that the have performed inbound replication of Active Directory since last
booted. Inbound replication can be verified by using the REPADMIN /SHOWREPS
DCNAME command, where DCNAME is the NetBIOS computer name or the fully

qualified computer name of a domain controller. For more information about

 operations masters and their placement, click the following article numbers to
view the articles in the Microsoft Knowledge Base:

197132 Windows 2000 Active Directory FSMO roles

223346 FSMO placement and optimization on Active Directory domain

controllers

f. EventLog Review

Examine the event logs on all the domain controllers for problematic events.
The event logs must not contain serious event messages that indicate a
problem with any of the following processes and components:

physical connectivity
network connectivity
name registration
name resolution
authentication
Group Policy
security policy
disk subsystem
schema
topology
replication engine

g. Disk Space Inventory

The volume that hosts the Active Directory database file, Ntds.dit, must have
free space equal to at least 15-20% of the Ntds.dit file size. The volume that
hosts the Active Directory log file must also have free space equal to at least 15-
20% of the Ntds.dit file size. For more information about how to free up
additional disk space, see the "Domain Controllers Without Sufficient Disk
Space" section of this article.

h. DNS Scavenging (Optional)

Enable DNS Scavenging at 7-day intervals for all DNS servers in the forest. For
best results, perform this operation 61 or more days before you upgrade the
operating system. This provides the DNS scavenging daemon sufficient time to
garbage-collect the aged DNS objects when an offline defragmentation is
performed on the Ntds.dit file.

i. Disable the DLT Server Service (Optional)

 The DLT Server service is disabled on new and upgraded installations of
Windows Server 2003 domain controllers. If distributed link tracking isn't used,
you can disable the DLT Server service on your Windows 2000 domain
controllers and begin deleting DLT objects from each domain in the forest. For
more information, see the "Microsoft Recommendations for distributed link
tracking" section of the following article in the Microsoft Knowledge Base:
312403 Distributed Link Tracking on Windows-based domain controllers

j. System State Backup

Make a system state backup of at least two domain controllers in every domain
in the forest. You can use the backup to recover all the domains in the forest if
the upgrade doesn't work.

Microsoft Exchange 2000 in Windows 2000

forests

７ Note

If Exchange 2000 Server is installed, or will be installed, in a Windows 2000

forest, read this section before you run the Windows Server 2003 adprep
/forestprep command.

If Microsoft Exchange Server 2003 schema changes will be installed, go to the

"Overview: Upgrading Windows 2000 domain controllers to Windows
Server 2003" section before you run the Windows Server 2003 adprep
commands.

The Exchange 2000 schema defines three inetOrgPerson attributes with non-Request for
Comment (RFC)-compliant LDAPDisplayNames: houseIdentifier, secretary, and
labeledURI.

The Windows 2000 inetOrgPerson Kit and the Windows Server 2003 adprep command
define RFC-complaint versions of the same three attributes with identical
LDAPDisplayNames as the non-RFC-compliant versions.

When the Windows Server 2003 adprep /forestprep command is run without corrective
scripts in a forest that contains Windows 2000 and Exchange 2000 schema changes, the
LDAPDisplayNames for the houseIdentifier, labeledURI, and secretary attributes become
mangled. An attribute becomes "mangled" if "Dup" or other unique characters are
added to the beginning of the conflicted attribute name so that objects and attributes in
the directory have unique names.

Active Directory forests aren't vulnerable to mangled LDAPDisplayNames for these

attributes in the following cases:

If you run the Windows Server 2003 adprep /forestprep command in a forest that
contains the Windows 2000 schema before you add the Exchange 2000 schema.
If you install the Exchange 2000 schema in forest that was created where a
Windows Server 2003 domain controller was the first domain controller in the
forest.
If you add Windows 2000 inetOrgPerson Kit to a forest that contains the Windows
2000 schema, and then you install Exchange 2000 schema changes, and then you
run the Windows Server 2003 adprep /forestprep command.
If you add Exchange 2000 schema to an existing Windows 2000 forest, then run
Exchange 2003 /forestprep before you run the Windows Server 2003 adprep
/forestprep command.

Mangled attributes will occur in Windows 2000 in the following cases:

If you add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and
the secretary attributes to a Windows 2000 forest before you install the Windows
2000 inetOrgPerson Kit.
You add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the
secretary attributes to a Windows 2000 forest before you run the Windows Server
2003 adprep /forestprep command without first running the cleanup scripts.
Action plans for each scenario follow:

Scenario 1: Exchange 2000 schema changes are added

after you run the Windows Server 2003 adprep
/forestprep command
If Exchange 2000 schema changes will be introduced to your Windows 2000 forest after
the Windows Server 2003 adprep /forestprep command is run, no cleanup is required.
Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server
2003" section.

Scenario 2: Exchange 2000 schema changes will be

installed before the Windows Server 2003 adprep
/forestprep command
If Exchange 2000 schema changes have already been installed but you have NOT run the
Windows Server 2003 adprep /forestprep command, consider the following action plan:

1. Log on to the console of the schema operations master by using an account that is
a member of the Schema Admins security group.

2. Click Start, click Run, type notepad.exe in the Open box, and then click OK.

3. Copy the following text including the trailing hyphen after "schemaUpdateNow: 1"
to Notepad.

dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName: msExchAssistantName
-

dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI
-

dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchHouseIdentifier
-

dn:
changetype: Modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

4. Confirm that there is no space at the end of each line.

5. On the File menu, click Save. In the Save As dialog box, follow these steps:
a. In the File name box, type the following:
\%userprofile%\InetOrgPersonPrevent.ldf
b. In the Save as type box, click All Files.
c. In the Encoding box, click Unicode.
d. Click Save.
 e. Quit Notepad.

6. Run the InetOrgPersonPrevent.ldf script.

a. Click Start, click Run, type cmd in the Open box, and then click OK.

b. At a command prompt, type the following, and then press ENTER: cd

%userprofile%

c. Type the following command

Console

c:\documents and settings\%username%>ldifde -i -f

inetorgpersonprevent.ldf -v -c DC=X "domain name path for forest root
domain"

Syntax notes:

DC=X is a case-sensitive constant.

The domain name path for the root domain must be enclosed in quotation
marks.

For example, the command syntax for an Active Directory forest whose forest root
domain is TAILSPINTOYS.COM would be:

c:\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c

DC=X "dc=tailspintoys,dc=com"

７ Note

You may need to change the Schema Update Allowed registry subkey if you
receive the following error message: Schema update is not allowed on this DC
because the registry key is not set or the DC is not the schema FSMO Role
Owner.

7. Verify that the LDAPDisplayNames for the CN=ms-Exch-Assistant-Name, CN=ms-

Exch-LabeledURI, and CN=ms-Exch-House-Identifier attributes in the schema
naming context now appear as msExchAssistantName, msExchLabeledURI, and
msExchHouseIdentifier before you run the Windows Server 2003 adprep
/forestprep commands.

8. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows

Server 2003" section to run the adprep /forestprep and /domainprep commands.
Scenario 3: The Windows Server 2003 forestprep
command was run without first running inetOrgPersonFix
If you run the Windows Server 2003 adprep /forestprep command in a Windows 2000
forest that contains the Exchange 2000 schema changes, the LDAPDisplayName
attributes for houseIdentifier, secretary, and labeledURI will become mangled. To
identify mangled names, use Ldp.exe to locate the affected attributes:

1. Install Ldp.exe from the Support\Tools folder of the Microsoft Windows 2000 or
Windows Server 2003 media.

2. Start Ldp.exe from a domain controller or member computer in the forest.

a. On the Connection menu, click Connect, leave the Server box empty, type 389
in the Port box, and then click OK.
b. On the Connection menu, click Bind, leave all the boxes empty, and then click
OK.

3. Record the distinguished name path for the SchemaNamingContext attribute. For
example, for a domain controller in the CORP.ADATUM.COM forest, the
distinguished name path might be
CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.

4. On the Browse menu, click Search.

5. Use the following settings to configure the Search dialog box:

Base DN: The distinguished name path for the schema naming context that is
identified in step 3.
Filter: (ldapdisplayname=dup*)
Scope: Subtree

6. Mangled houseIdentifier, secretary, and labeledURI attributes have

LDAPDisplayName attributes that are similar to the following format:

LDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
LDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
LDAPDisplayName: DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef

7. If the LDAPDisplayNames for labeledURI, secretary, and houseIdentifier were

mangled in step 6, run the Windows Server 2003 InetOrgPersonFix.ldf script to
recover, and then go to the "Upgrading Windows 2000 domain controllers with
Winnt32.exe" section.
 a. Create a folder named %Systemdrive%\IOP, and then extract the
InetOrgPersonFix.ldf file to this folder.

b. At a command prompt, type cd %systemdrive%\iop .

c. Extract the InetOrgPersonFix.ldf file from the Support.cab file that is located in
the Support\Tools folder of the Windows Server 2003 installation media.

d. From the console of the schema operations master, load the

InetOrgPersonFix.ldf file by using Ldifde.exe to correct the LdapDisplayName
attribute of the houseIdentifier, secretary, and labeledURI attributes. To do so,
type the following command, where <X> is a case-sensitive constant and <dn
path for forest root domain> is the domain name path for the root domain of
the forest:

Console

C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name

path for forest root domain"

Syntax notes:

DC=X is a case-sensitive constant.

The domain name path for the forest root domain must be enclosed in
quotation marks.

8. Verify that the houseIdentifier, secretary, and labeledURI attributes in the schema
naming context are not "mangled" before you install Exchange 2000.

Overview: Upgrading Windows 2000 domain

controllers to Windows Server 2003
The Windows Server 2003 adprep command that you run from the \I386 folder of the
Windows Server 2003 media prepares a Windows 2000 forest and its domains for the
addition of Windows Server 2003 domain controllers. The Windows Server 2003 adprep
/forestprep command adds the following features:

Improved default security descriptors for object classes

New user and group attributes

New Schema objects and attributes like inetOrgPersonThe adprep utility supports
two command-line arguments:
 adprep /forestprep : Runs forest upgrade operations.
dprep /domainprep : Runs domain upgrade operations.

The adprep /forestprep command is a one-time operation performed on the schema

operation master (FSMO) of the forest. The forestprep operation must complete and
replicate to the infrastructure master of each domain before you can run adprep
/domainprep in that domain.

The adprep /domainprep command is a one-time operation that you run on the
infrastructure operations master domain controller of each domain in the forest that will
host new or upgraded Windows Server 2003 domain controllers. The adprep
/domainprep command verifies that the changes from forestprep have replicated in the

domain partition and then makes its own changes to the domain partition and group
policies in the Sysvol share.

You can't perform either of the following actions unless the /forestprep and the
/domainprep operations have completed and replicated to all the domain controllers in
that domain:

Upgrade the Windows 2000 domain controllers to Windows Server 2003 domain
controllers by using Winnt32.exe.

７ Note

You can upgrade the Windows 2000 member servers and computers to Windows
Server 2003 member computers whenever you want. Promote new Windows Server
2003 domain controllers into the domain by using Dcpromo.exe.The domain that
hosts the schema operations master is the only domain where you must run both
adprep /forestprep and adprep /domainprep . In all other domains, you only have to

run adprep /domainprep .

The adprep /forestprep and the adprep /domainprep commands don't add attributes to
the global catalog partial attribute set or cause a full synchronization of the global
catalog. The RTM version of adprep /domainprep does cause a full sync of the \Policies
folder in the Sysvol tree. Even if you run forestprep and domainprep several times,
completed operations are performed only one time.

After the changes from adprep /forestprep and adprep /domainprep completely
replicate, you can upgrade the Windows 2000 domain controllers to Windows Server
2003 by running Winnt32.exe from the \I386 folder of the Windows Server 2003 media.
Also, you can add new Windows Server 2003 domain controllers to the domain by using
Dcpromo.exe.

Upgrading the forest with the adprep /forestprep

command
To prepare a Windows 2000 forest and domains to accept Windows Server 2003 domain
controllers, follow these steps first in a lab environment, then in a production
environment:

1. Make sure that you've completed all the operations in the "Forest Inventory" phase
with special attention to the following items:
a. You have created system state backups.
b. All the Windows 2000 domain controllers in the forest have installed all the
appropriate hotfixes and service packs.
c. End-to-end replication of Active Directory is occurring throughout the forest
d. FRS replicates the file system policy correctly throughout each domain.

2. Log on to the console of the schema operations master with an account that is a
member of the Schema Admins security group.

3. Verify that the schema FSMO has performed inbound replication of the schema
partition by typing the following at a Windows NT command prompt: repadmin
/showreps

( repadmin is installed by the Support\Tools folder of Active Directory.)

4. Early Microsoft documentation recommends that you isolate the schema

operations master on a private network before you run adprep /forestprep . Real-
world experience suggests that this step isn't necessary and may cause a schema
operations master to reject schema changes when it's restarted on a private
network.

5. Run adprep on the schema operations master. To do so, click Start, click Run, type
cmd, and then click OK. On the schema operations master, type the following
command:

Console

X:\I386\adprep /forestprep

where X:\I386\ is the path of the Windows Server 2003 installation media. This
command runs the forest-wide schema upgrade.
 ７ Note

Events with event ID 1153 that are logged in the Directory Service event log,
such as the sample that follows, can be ignored:

6. Verify that the adprep /forestprep command successfully ran on the schema
operations master. To do so, from the console of the schema operations master,
verify the following items: - The adprep /forestprep command completed without
error. - The CN=Windows2003Update object is written under
CN=ForestUpdates,CN=Configuration,DC= forest_root_domain. Record the value
of the Revision attribute. - (Optional) The schema version incremented to version
30. To do so, see the ObjectVersion attribute under
CN=Schema,CN=Configuration,DC= forest_root_domain.If adprep /forestprep
doesn't run, verify the following items:

The fully qualified path for Adprep.exe located in the \I386 folder of the
installation media was specified when adprep ran. To do so, type the
following command:

Console

x:\i386\adprep /forestprep

where x is the drive that hosts the installation media.

The logged on user who runs adprep has membership to the Schema Admins
security group. To verify this, use the whoami /all command.

If adprep still doesn't work, view the Adprep.log file in the

%systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.

7. If you disabled outbound replication on the schema operations master in step 4,

enable replication so that the schema changes that were made by adprep
/forestprep can propagate. To do this, following these steps:

a. Click Start, click Run, type cmd, and then click OK.
b. Type the following, and then press ENTER: repadmin /options -
DISABLE_OUTBOUND_REPL

8. Verify that the adprep /forestprep changes have replicated on all the domain
controllers in the forest. It's useful to monitor the following attributes:
a. Incrementing the schema version
 b. The CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC=
forest_root_domain or CN=Operations,CN=DomainUpdates,CN=System,DC=
forest_root_domain and the operations GUIDs under it have replicated in.
c. Search for new schema classes, objects, attributes, or other changes that adprep
/forestprep adds, such as inetOrgPerson. View the Sch XX.ldf files (where XX is

a number between 14 and 30) in the %systemroot%\System32 folder to

determine what objects and attributes there should be. For example,
inetOrgPerson is defined in Sch18.ldf.

9. Look for mangled LDAPDisplayNames. If you find mangled names, go to Scenario

3 of the same article.

10. Log on to the console of the schema operations master with an account that is a
member of the Schema Admins group security group of the forest that hosts the
schema operations master.

Upgrading the domain with the adprep /domainprep

command
Run adprep /domainprep after the /forestprep changes fully replicate to the
infrastructure master domain controller in each domain that will host Windows Server
2003 domain controllers. To do so, follow these steps:

1. Identify the infrastructure master domain controller in the domain you're

upgrading, and then log on with an account that is a member of the Domain
Admins security group in the domain you're upgrading.

７ Note

The enterprise administrator may not be a member of the Domain Admins

security group in child domains of the forest.

2. Run adprep /domainprep on the Infrastructure master. To do so, click Start, click
Run, type cmd, and then on the Infrastructure master type the following command:
X:\I386\adprep /domainprep where X:\I386\ is the path of the Windows Server

2003 installation media. This command runs domain-wide changes in the target
domain.

７ Note
 The adprep /domainprep command modifies files permissions in the Sysvol
share. These modifications cause a full synchronization of files in that
directory tree.

3. Verify that domainprep completed successfully. To do so, verify the following items:

The adprep /domainprep command completed without error.

The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn path
of domain you are upgrading existsIf adprep /domainprep doesn't run, verify
the following items:
The logged on user who runs adprep has membership to the Domain Admins
security group in the domain being you're upgrading. To do so, use the
whoami /all command.

The fully qualified path for Adprep.exe located in the \I386 directory of the
installation media was specified when you ran adprep . To do so, at a
command prompt type the following command: x :\i386\adprep
/forestprep where x is the drive that hosts the installation media.

If adprep still doesn't work, view the Adprep.log file in the

%systemroot%\System32\Debug\Adprep\Logs\ Latest_log folder.

4. Verify that the adprep /domainprep changes have replicated. To do so, for the
remaining domain controllers in the domain, verify the following items: - The
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn path of
domain you are upgrading object exists and the value for the Revision attribute
matches the value of the same attribute on the infrastructure master of the
domain. - (Optional) Look for objects, attributes, or access control list (ACL)
changes that adprep /domainprep added. Repeat steps 1-4 on the infrastructure
master of the remaining domains in bulk or as you add or upgrade DCs in those
domains to Windows Server 2003. Now you can promote new Windows Server
2003 computers into the forest by using DCPROMO. Or, you can upgrade existing
Windows 2000 domain controllers to Windows Server 2003 by using
WINNT32.EXE.

Upgrading Windows 2000 domain controllers

by using Winnt32.exe
After the changes from /forestprep and /domainprep completely replicate and you have
made a decision about security interoperability with earlier-version clients, you can
upgrade Windows 2000 domain controllers to Windows Server 2003 and add new
Windows Server 2003 domain controllers to the domain.

The following computers must be among the first domain controllers that run Windows
Server 2003 in the forest in each domain:

The domain naming master in the forest so that you can create default DNS
program partitions.
The primary domain controller of the forest root domain so that the enterprise-
wide security principals that Windows Server 2003's forestprep adds become
visible in the ACL editor.
The primary domain controller in each non-root domain so that you can create
new domain-specific Windows 2003 security principals. To do so, use WINNT32 to
upgrade existing domain controllers that host the operational role you want. Or,
transfer the role to a newly promoted Windows Server 2003 domain controller.
Perform the following steps for each Windows 2000 domain controller that you
upgrade to Windows Server 2003 with WINNT32 and for each Windows Server
2003 workgroup or member computer that you promote:

1. Before you use WINNT32 to upgrade Windows 2000 member computers and
domain controllers, remove Windows 2000 Administration Tools. To do so, use the
Add/Remove Programs tool in Control Panel. (Windows 2000 upgrades only.)

2. Install any hotfix files or other fixes that either Microsoft or the administrator
determines is important.

3. Check each domain controller for possible upgrade issues. To do so, run the
following command from the \I386 folder of the installation media: winnt32.exe
/checkupgradeonly Resolve any issues that the compatibility check identifies.

4. Run WINNT32.EXE from the \I386 folder of the installation media, and the restart
the upgraded 2003 domain controller.

5. Lower the security settings for earlier-version clients as required.

If Windows NT 4.0 clients don't have NT 4.0 SP6 or Windows 95 clients don't have
the directory service client installed, disable SMB Service signing on the Default
Domain Controllers policy on the Domain Controllers organizational unit, and then
link this policy to all organizational units that host domain controllers. Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft Network Server: Digitally sign communications (always)

6. Verify the health of the upgrade using the following data points:
 The upgrade completed successfully.
The hotfixes that you added to the installation successfully replaced the
original binaries.
Inbound and outbound replication of Active Directory is occurring for all
naming contexts held by the domain controller.
The Netlogon and Sysvol shares exist.
The event log indicates that the domain controller and its services are
healthy.

７ Note

You may receive the following event message after you upgrade: You can
safely ignore this event message.

7. Install the Windows Server 2003 Administration Tools (Windows 2000 upgrades
and Windows Server 2003 non-domain controllers only). Adminpak.msi is in the
\I386 folder of the Windows Server 2003 CD-ROM. Windows Server 2003 media
contains updated support tools in the Support\Tools\Suptools.msi file. Make sure
that you reinstall this file.

8. Make new backups of at least the first two Windows 2000 domain controllers that
you upgraded to Windows Server 2003 in each domain in the forest. Locate the
backups of the Windows 2000 computers that you upgraded to Windows Server
2003 in locked storage so you don't accidentally use them to restore a domain
controller that now runs Windows Server 2003.

9. (Optional) Perform an offline defragmentation of the Active Directory database on

the domain controllers that you upgraded to Windows Server 2003 after the single
instance store (SIS) has completed (Windows 2000 upgrades only).

The SIS reviews existing permissions on objects stored in Active Directory, and
then applies a more efficient security descriptor on those objects. The SIS starts
automatically (identified by event 1953 in the directory service event log) when
upgraded domain controllers first start the Windows Server 2003 operating
system. You benefit from the improved security descriptor store only when you log
an event ID 1966 event message in the directory service event log: This event
message indicates that the single instance store operation has completed and
serves as a queue the administrator to perform of offline defragmentation of the
Ntds.dit using NTDSUTIL.EXE.

The offline defragmentation can reduce the size of a Windows 2000 Ntds.dit file by
up to 40%, improves Active Directory performance, and updates the pages in the
 database for more efficient storage of Link Valued attributes. For more information
about how to defragment the Active Directory database, click the following article
number to view the article in the Microsoft Knowledge Base:

232122 Performing offline defragmentation of the Active Directory database

10. Investigate the DLT Server Service. Windows Server 2003 domain controllers
disable the DLT Server service on fresh and upgrade installs. If Windows 2000 or
Windows XP clients in your organization use the DLT Server service, use Group
Policy to enable the DLT Server service on new or upgraded Windows Server 2003
domain controllers. Otherwise, incrementally delete distributed link tracking
objects from Active Directory. For more information, click the following article
number to view the article in the Microsoft Knowledge Base:

312403 Distributed Link Tracking on Windows-based domain controllers

If you bulk delete thousands of DLT objects or other objects, you may block
replication because of a lack of version store. Wait tombstonelifetime number of
days (by default, 60 days) after you delete the last DLT object and for garbage
collection to complete, then use NTDSUTIL.EXE to perform an offline
defragmentation of the Ntds.dit file.

11. Configure the best practice organizational unit structure. Microsoft recommends
that administrators actively deploy the best practice organizational unit structure in
all the Active Directory domains, and after they upgrade or deploy Windows Server
2003 domain controllers in Windows Domain mode, redirect the default containers
that earlier-version APIs use to create users, computers, and groups to an
organizational unit container that the administrator specifies.

For additional information about the best practice organizational unit structure,
view the "Creating an Organizational Unit Design" section of the "Best Practice
Active Directory Design for Managing Windows Networks" white paper. To view
the white paper, visit the following Microsoft Web site:
https://technet.microsoft.com/library/bb727085.aspx For more information
about changing the default container where users, computers, and groups that
earlier-version APIs create are located, click the following article number to view
the article in the Microsoft Knowledge Base:

324949 Redirecting the users and computers containers in Windows Server 2003
domains

12. Repeat steps 1 through 10 as required for each new or upgraded Windows Server
2003 domain controller in the forest and step 11 (Best Practice organizational unit
 structure) for each Active Directory domain.

In Summary:

Upgrade Windows 2000 Domain controllers with WINNT32 (from the

slipstreamed installation media if used)
Verify the hotfixes files have been installed on the upgraded computers
Install any required hotfixes not contained on installation media
Verify the health on new or upgraded servers (AD, FRS, Policy, and so on)
Wait 24 hours after OS upgrade then offline defrag (optional)
Start the DLT Service if you must, otherwise delete DLT objects using q312403
/ q315229 post forest-wide domainpreps
Perform offline defrag 60+ days (tombstone lifetime and garbage collection #
of days) after deleting DLT objects

Dry-run upgrades in a lab environment

Before you upgrade Windows domain controllers to a production Windows 2000
domain, validate and refine your upgrade process in the lab. If the upgrade of a lab
environment that accurately mirrors the production forest performs smoothly, you can
expect similar results in production environments. For complex environments, the lab
environment must mirror the production environment in the following areas:

Hardware: computer type, memory size, page file placement, disk size,
performance and raid configuration, BIOS and firmware revision levels
Software: client and server operating system versions, client and server
applications, service pack versions, hotfixes, schema changes, security groups,
group memberships, permissions, policy settings, object count type, and location,
version interoperability
Network infrastructure: WINS, DHCP, link speeds, available bandwidth
Load: Load simulators can simulate password changes, object creation, Active
Directory replication, logon authentication and other events. The goal isn't to
reproduce the scale of the production environment. Instead, the goals are to
discover the costs and frequency of common operations and to interpolate their
effects (name queries, replication traffic, network bandwidth, and processor
consumption) on the production environment based on your current and future
requirements.
Administration: tasks performed, tools used, operating systems used
Operation: capacity, interoperability
Disk Space: Note the starting, peak, and ending size of the operating system,
Ntds.dit, and Active Directory log files on global catalog and non-global catalog
 domain controllers in each domain after each of the following operations:

1. adprep /forestprep
2. adprep /domainprep
3. Upgrading Windows 2000 domain controllers to Windows Server 2003
4. Performing offline defragmentation after version upgrades

An understanding of the upgrade process and complexity of the environment combined

with detailed observation determines the pace and degree of care that you apply to
upgrading production environments. Environments with a small number of domain
controllers and Active Directory objects connected over high availability wide area
network (WAN) links might upgrade in only a few hours. You may have to take more
care with enterprise deployments that have hundreds of domain controllers or hundreds
of thousands of Active Directory objects. In such cases, you may want to perform the
upgrade over the course of several weeks or months.

Use "Dry-run" upgrades in the lab to perform the following tasks:

Understand the inner workings of the upgrade process and the associated risks.
Expose potential problem areas for the deployment process in your environment.
Test and develop fall-back plans in case the upgrade doesn't succeed.
Define the appropriate level of detail to apply to the upgrade process for the
production domain.

Domain controllers without sufficient disk

space
On domain controllers with insufficient disk space, use the following steps to free up
additional disk space on the volume that hosts the Ntds.dit and Log files:

1. Delete the unused files including *.tmp files or cached files that internet browsers
use. To do so, type the following commands (press ENTER after each command):

Console

cd /d drive\
del *.tmp /s

2. Delete any user or memory dump files. To do so, type the following commands
(press ENTER after each command):

Console
 cd /d drive\
del *.dmp /s

3. Temporarily remove or relocate files that you can access from other servers or
easily reinstall. Files that you can remove and easily replace include ADMINPAK,
Support Tools, and all the files in the %systemroot%\System32\Dllcache folder.

4. Delete old or unused user profiles. To do so, click Start, right-click My Computer,
click Properties, click the User Profiles tab, and then delete all the profiles that are
for old and unused accounts. Don't delete any profiles that may be for service
accounts.

5. Delete the symbols at %systemroot%\Symbols. To do so, type the following

command: rd /s %systemroot%\symbols Depending on whether the servers have a
full or small symbol set, this may gain approximately 70 MB to 600 MB.

6. Perform an offline defragmentation. An offline defragmentation of the Ntds.dit file

may free up space but temporarily requires double the space of the current DIT
file. Perform the offline defrag by using other local volumes if one is available. Or,
use space on a best connected network server to perform the offline
defragmentation. If the disk space is still not sufficient, incrementally delete
unnecessary user accounts, computer accounts, DNS records, and DLT objects from
Active Directory.

７ Note

Active Directory does not delete objects from the database until tombstonelifetime
number of days (by default, 60 days) have passed and the garbage collection
completes. If you reduce tombstonelifetime to a value lower than end-to-end
replication in the forest, you may cause inconsistencies in Active Directory.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DCPROMO answer file syntax for
unattended promotion and demotion of
domain controllers
Article • 02/19/2024

This article describes the parameters and options that are used in the DCPROMO answer
file to install and remove Active Directory Domain Services (AD DS) on domain
controllers.

Applies to: Windows Server 2012 R2

Original KB number: 947034

Summary
This article describes the syntax that you use to build answer files to perform
unattended installations of AD DS on domain controllers. You can also use the answer
files to remove AD DS in unattended mode.

Introduction
The Dcpromo.exe program (DCPROMO) was introduced in Microsoft Windows 2000
Server to provide a GUI method of promoting and demoting Active Directory domain
controllers. Administrators can use DCPROMO answer files to do the following
unattended tasks:

Promote workgroup and member servers to Active Directory domain controllers.

Upgrade Microsoft Windows NT 4.0 domain controllers to Active Directory domain
controllers.
Demote domain controllers.

Windows Server 2003 updated the syntax for DCPROMO answer files.

Windows Server 2012 replaced DCPROMO with PowerShell cmdlets. However, the
Windows Server 2003 version of the DCPROMO answer file syntax remains fully
supported on the following Windows versions:

Windows Server 2019

Windows Server 2016
Windows Server 2012 R2
 Windows Server 2012
Windows Server 2008 R2
Windows Server 2008

More information
The DCPROMO answer file is an ASCII text file that provides automated user input for
each page of the DCPROMO wizard.

Subtle differences exist between the DCPROMO answer file syntax in Windows 2000
Server and in Windows Server 2003. Despite these differences, Windows Server 2003 can
read the Windows 2000 Server answer file syntax and interpret equivalent settings.
However, the Windows Server 2003 answer file syntax may not work correctly on a
Windows 2000 Server domain controller. For example, Windows 2000 Server cannot use
the RemoveApplicationPartitions and ConfirmGc options.

If you have to use the same answer files on both Windows 2000 Server and Windows
Server 2003 domain controllers, use the answer file syntax that is described in this
article.

To start DCPROMO in unattended mode, open an administrative Command Prompt

window, and run the following command:

Console

dcpromo /answer:<answer.txt>

７ Note

In this command, <answer.txt> is the path and file name of the answer file that will
be used for demotion or promotion. You can use this command whether you use
the Start > Run command or an unattended Setup file.

Each DCPROMO operation requires answers to specific fields in the [DCInstall] section of
the answer file. The following list provides the required fields for each operation. The
default values are used if the option is not specified. The default values for these fields
are described in Field Definitions.

For new forest installations, the following options apply:

[DCINSTALL]
InstallDNS=yes
NewDomain=forest
NewDomainDNSName=<The fully qualified Domain Name System (DNS) name>
DomainNetBiosName=<By default, the first label of the fully qualified DNS name>
SiteName=<Default-First-Site-Name>
ReplicaOrNewDomain=domain
ForestLevel=<The forest functional level number>
DomainLevel=<The domain functional level number>
DatabasePath="<The path of a folder on a local volume>"
LogPath="<The path of a folder on a local volume>"
RebootOnCompletion=yes
SYSVOLPath="<The path of a folder on a local volume>"
SafeModeAdminPassword=<The password for an offline administrator account>

For child domain installations, the following options apply:

[DCINSTALL]
ParentDomainDNSName=<Fully qualified DNS name of parent domain>
UserName=<The administrative account in the parent domain>
UserDomain=<The name of the domain of the user account>
Password=<The password for the user account> Specify * to prompt the user for
credentials during the installation.
NewDomain=child

ChildName=<The single-label DNS name of the new domain>

SiteName=<The name of the AD DS site in which this domain controller will
reside> This site must be created in advance in the Dssites.msc snap-in.
DomainNetBiosName=<The first label of the fully qualified DNS name>
ReplicaOrNewDomain=domain
DomainLevel=<The domain functional level number> This value can't be less than
the current value of the forest functional level.

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"
SYSVOLPath="<The path of a folder on a local volume>"
InstallDNS=yes

CreateDNSDelegation=yes
DNSDelegationUserName= <The account that has permissions to create a DNS
delegation> The account that is being used to install AD DS may differ from the
account in the parent domain that has the permissions that are required to create
a DNS delegation. In this case, specify the account that can create the DNS
delegation for this parameter. Specify * to prompt the user for credentials during
the installation.
DNSDelegationPassword= <The password for the account that is specified for
DNSDelegationUserName> Specify * to prompt the user for a password during the
installation.
SafeModeAdminPassword=<The password for an offline administrator account>
RebootOnCompletion=yes

For a new tree in existing forest installations, the following options apply:

[DCINSTALL]
UserName=<An administrative account in the parent domain>
UserDomain=<The name of the domain of the user account>
Password=<The password for the adminstrative account> Specify * to prompt the
user for credentials during the installation.
NewDomain=tree
NewDomainDNSName=<The fully qualified DNS name of the new domain>
SiteName=<The name of the AD DS site in which this domain controller will
reside> This site must be created in advance in the Dssites.msc snap-in.
DomainNetBiosName=<The first label of the fully qualified DNS name>
ReplicaOrNewDomain=domain
DomainLevel=<The domain functional level number>
DatabasePath="<The path of a folder on a local volume>"
LogPath="<The path of a folder on a local volume>"
SYSVOLPath="<The path of a folder on a local volume>"
InstallDNS=yes
CreateDNSDelegation=yes
DNSDelegationUserName= <The account that has permissions to create a DNS
delegation> The account that is being used to install AD DS may differ from the
account in the parent domain that has the permissions that are required to create
a DNS delegation. In this case, specify the account that can create the DNS
delegation for this parameter. Specify * to prompt the user for credentials during
the installation.
DNSDelegationPassword=<The password for the account that is specified for
DNSDelegationUserName> Specify * to prompt the user for a password during the
installation.
SafeModeAdminPassword=<The password for an offline administrator account>
RebootOnCompletion=yes

For additional domain controller installations, the following options apply:

[DCINSTALL]
UserName=<The administrative account in the domain of the new domain
controller>

UserDomain=<The name of the domain of the new domain controller>

Password=<The password for the UserName account>

SiteName=<The name of the AD DS site in which this domain controller will

reside> This site must be created in advance in the Dssites.msc snap-in.

ReplicaOrNewDomain=replica

ReplicaDomainDNSName=<The fully qualified domain name (FQDN) of the

domain in which you want to add an additional domain controller>

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

InstallDNS=yes

ConfirmGC=yes

SafeModeAdminPassword=<The password for an offline administrator account>

RebootOnCompletion=yes

For additional domain controller installations that use the Install From Media (IFM)
method, the following options apply:

[DCINSTALL]
UserName=<The administrative account in the domain of the new domain
controller>
Password=<The password for the UserName account>
UserDomain=<The name of the domain of the UserName account>
DatabasePath="<The path of a folder on a local volume>"
LogPath="<The path of a folder on a local volume>"
SYSVOLPath="<The path of a folder on a local volume>"
SafeModeAdminPassword=<The password of an offline administrator account>

CriticalReplicationOnly=no
SiteName=<The name of the AD DS site in which this domain controller will
reside>
This site must be created in advance in the Dssites.msc snap-in.

ReplicaOrNewDomain=replica
ReplicaDomainDNSName=<The fully qualified domain name (FQDN) of the
domain in which you want to add an additional domain controller>
ReplicationSourceDC=<An existing domain controller in the domain>

ReplicationSourcePath=<The local drive and the path of the backup>

RebootOnCompletion=yes

For read-only domain controller (RODC) installations, the following options apply:

[DCINSTALL]
UserName=<The administrative account in the domain of the new domain
controller>
UserDomain=<The name of the domain of the user account>
PasswordReplicationDenied=<The names of the user, group, and computer
accounts whose passwords are not to be replicated to this RODC>
PasswordReplicationAllowed =<The names of the user, group, and computer
accounts whose passwords can be replicated to this RODC>
DelegatedAdmin=<The user or group account name that will install and
administer the RODC>
SiteName=Default-First-Site-Name
CreateDNSDelegation=no
CriticalReplicationOnly=yes

Password=<The password for the UserName account>

ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=<The FQDN of the domain in which you want to add an
additional domain controller>
DatabasePath= "<The path of a folder on a local volume>"
LogPath="<The path of a folder on a local volume>"
SYSVOLPath="<The path of a folder on a local volume>"
InstallDNS=yes
ConfirmGC=yes
SafeModeAdminPassword=<The password for an offline administrator account>
RebootOnCompletion=yes

For removal of AD DS, the following options apply:

[DCINSTALL]
UserName=<An administrative account in the domain>
UserDomain=<The domain name of the administrative account>
Password=<The password for the UserName account>
AdministratorPassword=<The local administrator password for the server>
RemoveApplicationPartitions=yes
RemoveDNSDelegation=yes
DNSDelegationUserName=<The DNS server administrative account for the DNS
zone that contains the DNS delegation>
DNSDelegationPassword=<The password for the DNSDelegationUserName
account>
RebootOnCompletion=yes

For removal of AD DS from the last domain controller in a domain, the following
options apply:

[DCINSTALL]
UserName=<An administrative account in the parent domain>
UserDomain=<The domain name of the UserName account>
Password=<The password for the UserName account> Specify * to prompt the
user for credentials during the installation.
IsLastDCInDomain=yes
AdministratorPassword=<The local administrator password for the server>
RemoveApplicationPartitions=If you want to remove the partitions, specify "yes"
(no quotation marks) for this entry. If you want to keep the partitions, this entry is
optional.
RemoveDNSDelegation=yes
DNSDelegationUserName=<The DNS server administrative account for the DNS
zone that contains the DNS delegation>
DNSDelegationPassword=<The password for the DNS server administrative
account>
RebootOnCompletion=yes

For removal of the last domain controller in a forest, the following options apply:

[DCINSTALL]
UserName=<An administrative account in the parent domain>
UserDomain=<The domain name of the UserName account>
Password=<The password for the UserName account> Specify * to prompt the
user for credentials during the installation.
IsLastDCInDomain=yes
AdministratorPassword=<The local administrator password for the server>
 RemoveApplicationPartitions=If you want to remove the partitions, specify "yes"
(no quotation marks) for this entry. If you want to keep the partitions, this entry is
optional.
RemoveDNSDelegation=yes
DNSDelegationUserName=<The DNS server administrative account for the DNS
zone that contains the DNS delegation>
DNSDelegationPassword=<The password for the DNS server administrative
account>
RebootOnCompletion=yes

Field definitions
This section describes the fields and the entries that you can use in the answer file. The
default value for each entry appears in bold text.

Installation operation parameters

AllowDomainReinstall

Yes | No
This entry specifies whether an existing domain is re-created.

AllowDomainControllerReinstall

Yes | No
This entry specifies whether to continue to install this domain controller even
though an active domain controller account that uses the same name is detected.
Specify "Yes" (no quotation marks) only if you're sure that the account is no longer
being used.

ApplicationPartitionsToReplicate

No default
This entry specifies the application partitions that have to be replicated in the
format ""partition1" "partition2"". If * is specified, all application partitions will be
replicated. Use space-separated or comma-and-space-separated distinguished
names. Enclose the whole string in quotation marks.

ChildName
 No default
This is the name of the subordinate domain that is appended to the
ParentDomainDNSName entry. If the parent domain is "A.COM," and the
subordinate domain is "B," enter "B.A.COM and B" (no quotation marks) for
ChildName.

ConfirmGc

Yes | No
This entry specifies whether the replica is also a global catalog. "Yes" makes the
replica a global catalog if the backup was a global catalog. "No" doesn't make the
replica a global catalog. (These entries don't require quotation marks.)

CreateDNSDelegation

Yes | No
No default
This entry indicates whether to create a DNS delegation that references this new
DNS server. This entry is valid for AD DS-integrated DNS only.

CriticalReplicationOnly

Yes | No
This entry specifies whether the installation operation performs only important
replication before a restart and then skips the noncritical and potentially lengthy
part of replication. The noncritical replication occurs after the role installation is
complete, and the computer restarts.

DatabasePath

%systemroot%\NTDS
This entry is the path of the fully qualified, non-Universal Naming Convention
(UNC) directory on a hard disk of the local computer. This directory will host the
AD DS database (NTDS.DIT). If the directory exists, it must be empty. If it doesn't
exist, it will be created. Free disk space on the logical drive that is selected must be
200 megabytes (MB). To accommodate rounding errors or all objects in the
domain, free disk space may have to be larger. For best performance, locate the
directory on a dedicated hard disk.

DelegatedAdmin
 No default
This entry specifies the name of the user or the group who will install and
administer the RODC. If no value is specified, only members of the Domain Admins
group or the Enterprise Admins group can install and administer the RODC.

DNSDelegationPassword

<Password> | *

No default

This entry specifies the password for the user account that is used to create or
remove the DNS delegation. Specify * to prompt the user to enter credentials.

DNSDelegationUserName

No default
This entry specifies the user name to be used when the DNS delegation is created
or removed. If you don't specify a value, the account credentials that you specify
for the installation or removal of AD DS are used for the DNS delegation.

DNSOnNetwork

Yes | No
This entry specifies whether the DNS service is available on the network. This entry
is used only when the network adapter for this computer isn't configured to use
the name of a DNS server for name resolution. Specify "No" (no quotation marks)
to indicate that DNS will be installed on this computer for name resolution.
Otherwise, the network adapter must be configured to use a DNS server name
first.

DomainLevel

0|2|3
No default
This entry specifies the domain functional level. This entry is based on the levels
that exist in the forest when a new domain is created in an existing forest. Value
descriptions are as follows:
0 = Windows 2000 Server native mode
2 = Windows Server 2003
3 = Windows Server 2008
DomainNetbiosName

No default
This entry is the NetBIOS name that is used by pre-AD DS clients to access the
domain. The DomainNetbiosName must be unique on the network.

ForestLevel

0|2|3

This entry specifies the forest functional level when a new domain is created in a
new forest as follows:

0 = Windows 2000 Server

2 = Windows Server 2003
3 = Windows Server 2008 You must not use this entry when you install a new
domain controller in an existing forest. The ForestLevel entry replaces the
SetForestVersion entry that is available in Windows Server 2003.

InstallDNS

Yes | No
The default value changes depending on the operation. For a new forest, the DNS
server role is installed by default. For a new tree, a new child domain, or a replica, a
DNS server is installed by default if an existing DNS infrastructure is detected by
the Active Directory Domain Services Installation Wizard. If no existing DNS
infrastructure is detected by the wizard, a DNS server isn't installed by default.
This entry specifies whether DNS is configured for a new domain if the Active
Directory Domain Services Installation Wizard detects that the DNS dynamic
update protocol isn't available. This entry also applies if the wizard detects an
insufficient number of DNS servers for an existing domain.

LogPath

%systemroot%\NTDS
This is the path of the fully qualified, non-UNC directory on a hard disk on the local
computer that will host the AD DS log files. If the directory exists, it must be empty.
If it doesn't exist, it will be created.

NewDomain

Tree | Child | Forest

 "Tree" means the new domain is the root of a new tree in an existing forest. "Child"
means the new domain is a child of an existing domain. "Forest" means the new
domain is the first domain in a new forest of domain trees.

NewDomainDNSName

No default
This entry is used in "new tree in existing forest" or "new forest" installations. The
value is a DNS domain name that is currently not being used.

ParentDomainDNSName

No default
This entry specifies the name of an existing parent DNS domain for a child domain
installation.

Password

<Password> | *
No default
This entry specifies the password that corresponds to the user account that is used
to configure the domain controller. Specify * to prompt the user to enter
credentials. For protection, passwords are removed from the answer file following
an installation. Passwords must be redefined every time that an answer file is used.

PasswordReplicationAllowed

<Security_Principal> | NONE

No default

This entry specifies the names of computer accounts and user accounts whose
passwords can be replicated to this RODC. Specify "NONE" (no quotation marks) if
you want to keep the value empty. By default, no user credentials will be cached
on this RODC. To specify more than one security principal, add the entry multiple
times.

PasswordReplicationDenied

<Security_Principal> | NONE
 This entry specifies the names of the user, group, and computer accounts whose
passwords aren't to be replicated to the RODC. Specify "NONE" (no quotation
marks) if you don't want to deny the replication of credentials for any users or
computers. To specify more than one security principal, add the entry multiple
times.

RebootOnCompletion

Yes | No
This entry specifies whether to restart the computer after you install or remove AD
DS regardless of whether the operation was successful.

RebootOnSuccess

Yes | No | NoAndNoPromptEither

This entry specifies whether the computer must be restarted after AD DS has been
installed or removed successfully. A restart is always required to complete a
change in an AD DS role.

ReplicaDomainDNSName

No default
This entry specifies the FQDN of the domain in which you want to configure an
additional domain controller.

ReplicaOrNewDomain

Replica | ReadOnlyReplica | Domain

This entry is used only for new installations. "Domain" (no quotation marks)
converts the server into the first domain controller of a new domain.
"ReadOnlyReplica" (no quotation marks) converts the server into a RODC. "Replica"
(no quotation marks) converts the server into an additional domain controller.

ReplicationSourceDC

No default
This entry specifies the FQDN of the partner domain controller from which AD DS
data is replicated to create the new domain controller.
ReplicationSourcePath

No default
This entry specifies the location of the installation files that are used to create a
new domain controller.

SafeModeAdminPassword

<Password> | NONE
No default
This entry is used to supply the password for the offline administrator account that
is used in Directory Service Restore Mode. You can't specify an empty password.

SiteName

Default-First-Site-Name
This entry specifies the site name when you install a new forest. For a new forest,
the default is Default-First-Site-Name. For all other scenarios, a site will be selected
by using the current site and the subnet configuration of the forest.

SkipAutoConfigDNS

No default
This entry is for expert users who want to skip automatic configuration of client
settings, forwarders, and root hints. The entry is only in effect if the DNS Server
service is already installed on the server. In this case, you'll receive an informational
message that confirms that the automatic configuration of DNS was skipped.
Otherwise, this entry is ignored. If you specify this switch, make sure that zones are
created and configured correctly before you install AD DS, or the domain
controller won't operate correctly. This entry doesn't skip automatic creation of the
DNS delegation in the parent DNS zone. To control DNS delegation creation, use
the DNSDelegation entry.

Syskey

<system_key> | NONE
This entry specifies the system key for the media from which you replicate the
data.

SYSVOLPath
 %systemroot%\SYSVOL
This entry specifies a fully qualified, non-UNC directory on the hard disk of the
local computer. This directory will host the AD DS log files. If the directory already
exists, it must be empty. If it doesn't exist it will be created. The directory must be
located on a partition that was formatted by using the NTFS 5.0 file system. Locate
the directory on a different physical hard disk than the operating system for best
performance.

TransferIMRoleIfNeeded

Yes | No
This entry specifies whether to transfer the infrastructure master role to this
domain controller. This entry is useful if the domain controller is currently hosted
on a global catalog server, and you don't plan to make the domain controller a
global catalog server. Specify "Yes" (no quotation marks) to transfer the
infrastructure master role to this domain controller. If you specify "Yes," make sure
that you specify the ConfirmGC=No entry.

UserDomain

No default
This entry specifies the domain name for the user account that is used for install
AD DS on a server.

UserName

No default
This entry specifies the user account name that is used for installing AD DS on a
server. We recommend that you specify the account credentials in the <domain>\
<user_name> format.

Removal operation parameters

AdministratorPassword

No default
This entry is used to specify the local administrator password when you remove AD
DS from a domain controller.

DemoteFSMO
 Yes | No
This entry indicates whether a forced removal happens even if an operations
master role is held by the domain controller.

DNSDelegationPassword

<Password> | *

No default

This entry specifies the password for the user account that is used to create or to
remove the DNS delegation. Specify * to prompt the user to enter credentials.

DNSDelegationUserName

No default
This entry specifies the user name to be used when the DNS delegation is created
or removed. If you don't specify a value, the account credentials that you specify
for the AD DS installation or for the AD DS removal are used for the DNS
delegation.

IgnoreIsLastDcInDomainMismatch

Yes | No
This entry specifies whether to continue the removal of AD DS from the domain
controller when either the IsLastDCInDomain=Yes entry is specified or the Active
Directory Domain Services Installation Wizard detects that there's actually another
active domain controller in the domain. This entry also applies to a scenario in
which the IsLastDCInDomain=No entry is specified, and the wizard can't contact
any other domain controller in the domain.

IgnoreIsLastDNSServerForZone

Yes | No
This entry specifies whether to continue removing AD DS even though the domain
controller is the last DNS server for one or more AD DS-integrated DNS zones that
the domain controller hosts.

IsLastDCInDomain

Yes | No
 This entry specifies whether the domain controller from which you remove AD DS
is the last domain controller in the domain.

Password

<Password> | *
No default
This entry specifies the password that corresponds to the user account that is used
to configure the domain controller. Specify * to prompt the user to enter
credentials. For protection, passwords are removed from the answer file after you
install AD DS. Passwords must be redefined every time that an answer file is used.

RebootOnCompletion

Yes | No
This entry specifies whether to restart the computer after you install or remove AD
DS regardless of whether the operation was successful.

RebootOnSuccess

Yes | No | NoAndNoPromptEither

Determines whether the computer must be restarted after AD DS has been

successfully installed or removed. A restart is always required to complete a
change in an AD DS role.

RemoveApplicationPartitions

Yes | No
This entry specifies whether to remove application partitions when you remove AD
DS from a domain controller. "Yes" (no quotation marks) removes application
partitions on the domain controller. "No" (no quotation marks) doesn't remove
application partitions on the domain controller. If the domain controller hosts the
last replica of any application directory partition, you must manually confirm that
you must remove these partitions.

RemoveDNSDelegation

Yes | No
 This entry specifies whether to remove DNS delegations that point to this DNS
server from the parent DNS zone.

RetainDCMetadata

Yes | No
This entry specifies whether domain controller metadata is retained in the domain
after AD DS removal so that a delegated administrator can remove AD DS from an
RODC.

UserDomain

No default
This entry specifies the domain name for the user account that is used to install AD
DS.

UserName

No default
This entry specifies the user account name that is used to install AD DS on a server.
We recommend that you specify the account credentials in the <domain>\
<user_name> format.

Unattended installation return codes

The Active Directory Domain Services Installation Wizard returns a success code or a
failure code after you complete the unattended installation of a Windows Server 2008-
based domain controller. For more information about the unattended installation return
codes, visit the following Microsoft Web site:

Unattended Installation Return Codes

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Installing Active Directory Domain
Services Fails with Error "The specified
user already exists."
Article • 02/19/2024

This article provides a solution to an issue where installing Active Directory Domain
Services fails with the error: The specified user already exists.

Applies to: Windows Server 2012 R2

Original KB number: 2000622

Symptoms
When you attempt to install Active Directory Domain Services on a Windows Server
computer, you may receive the following error:

Error Joining Domain

The operation failed because: The attempt to join this computer to the <target DNS
domain> failed. The specified user already exists.

The %systemroot%\debug\DCPROMOUI.LOG contains the following text:

dcpromoui Enter ComposeFailureMessage

dcpromoui Enter GetErrorMessage 80070524
dcpromoui Enter State::GetOperationResultsMessage The attempt to join this
computer to the <target DNS domain> domain failed.
dcpromoui Enter State::GetOperationResultsFlags 0x0
dcpromoui Enter State::SetFailureMessage The operation failed because:
The attempt to join this computer to the <target DNS domain> domain failed.
"The specified user already exists."

Cause
There is a computer account with the same name as the computer on which you are
attempting to install Active Directory Domain Services.

Resolution
1. If you are installing Active Directory Domain Services on a computer with the same
name as a domain controller that previously existed in the domain, it is possible
that metadata still remains.

You can use one of the following methods to remove the metadata:

Clean up server metadata

216498 How to remove data in Active Directory after an unsuccessful
domain controller demotion

For best results, remove the stale domain controller metadata on a domain
controller in the same domain and site that the new domain controller is joining, or
the helper domain controller specified in the Active Directory Installation Wizard or
answer file.

2. If the Active Directory Installation Wizard continues to fail with error "The specified
user already exists", review the %systemroot%\debug\DCPROMOUI.LOG to identify
the name of the helper domain controller that the new domain controller is
attempting to use.

Sample output from DCPROMOUI.LOG:

dcpromoui Enter DS::JoinDomain ← Search for this section of the

%systemroot%\debug\dcpromoui.log
dcpromoui Enter MassageUserName administrator
dcpromoui contoso.com\administrator
dcpromoui Enter MyNetJoinDomain contoso.com<helper DCs
hostname>.contoso.com ← name of helper domain controller
dcpromoui Calling NetJoinDomain
dcpromoui lpServer : (null)
dcpromoui lpDomain : contoso.com<helper DCs hostname>.contoso.com
dcpromoui lpAccountOU : (null)
dcpromoui lpAccount : contoso.com\administrator
dcpromoui fJoinOptions : 0x27
dcpromoui HRESULT = 0x80070524Error ← 0x80070524 = 0x524 hex / 1316
decimal with symbolic error ERROR_USER_EXISTS
dcpromoui HRESULT = 0x80070524

3. Verify that the helper domain controller identified in Step 2 has inbound replicated
the removal of the conflicting domain controller machine account and NTDS
Settings objects (metadata cleanup) performed in Step 1. If the domain controller
machine account still exists, evaluate the possible reasons:
 Replication latency such as a domain controller being several hops away from
the domain controller originating the metadata cleanup.
Inbound replication failure on the helper domain controller.
The helper domain controller resides in a lag site that has been intentionally
configured to inbound replicate changes in a delayed fashion.

4. For more information about other root causes for this error, click the following
article number to view the articles in the Microsoft Knowledge Base:

938447 You cannot add a user name or an object name that only differs by a
character with a diacritic mark

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot an Internal error message
during the replication phase of dcpromo
Article • 02/19/2024

This article describes how to troubleshoot an internal error that you receive during the
replication phase of the Active Directory Installation Wizard (Dcpromo).

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 265090

７ Note

Home users: This article is only intended for use by technical support agents and IT
professionals. If you're looking for help with a problem, ask the Microsoft
Community .

Summary
During promotion, directory service objects are replicated in the order of the Update
Sequence Number (USN) (low to high) for the schema, configuration, and domain.
Internal errors can occur when a parent container for replicated child objects doesn't
exist in the local directory service.

This issue can occur in either of the following scenarios:

There is a live object whose parent was deleted in the past, and the parent has
expired and been converted to a phantom. Therefore, the child object can no
longer be replicated out. The call to FillGuidAndSid for the parent object in
ReplPrepareDataToShip doesn't succeed, and an error is reported (8352 =
ERROR_DS_NOT_AN_OBJECT). This error causes the outbound replication of the
child object to quit, and you receive a replication internal error message.

If there is a live (or deleted) object that has a phantom parent, Active Directory
temporarily accepts the live object because of out-of-order replication
requirements. Disk cleanup procedures, such as garbage collection, shouldn't be
able to convert a deleted object into a phantom if the parent has child objects. The
Ntdsa.dll file as of Windows 2000 Service Pack 2 (SP2) prevents this situation in the
directory service. However, this file doesn't fix the issue after it has already
occurred.
 You use the authoritative restore command when you use Windows Server 2003
or a later version of the Ntdsutil tool. Ntdsutil.exe increases the USN of specified
containers and child objects in Active Directory. Beta versions of Ntdsutil.exe may
incorrectly increase the USN for the Lost and Found container. When objects that
are destined for the Lost and Found container are replicated before the container
is created in the local directory service, the following event is reported:

Event 1084: Replication failed with an internal error

To avoid this scenario, the Lost and Found container is normally one of the first
containers that is replicated.

Internal errors can also occur on existing Active Directory domain controllers during
normal or administrator-initiated Active Directory replication.

Steps to troubleshoot this error message

1. Use Network Monitor, event logs, or Dcpromo.log to locate the source server that
is being used during Active Directory replication (when you are using the Active
Directory Installation Wizard).

2. If this error occurs when you are using Active Directory Installation Wizard and
more than one potential replication partner exists, use the Active Directory
Installation Wizard answer file to find the source server. Possible source domain
controllers include domain controllers in the parent domain for new child domains,
or domain controllers in the same domain for replicated domain controllers.
Alternatively, if a specific source server is suspect, stop the Net Logon service on
the suspect computer, and search from a different domain controller.

3. On the source server, locate and click the following registry sub key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics

Edit the following values:

9 Internal Processing: Set the diagnostic level to 1.

7 Internal Configuration: Set the diagnostic level to 3.
5 Replication Events: Set the diagnostic level to 3.

4. Use Registry Editor to export the \NTDS key from the source server to the
computer that is being promoted (for example, Ntds.reg). Copy the file to the
computer that is encountering the internal error when replication occurs. If the
internal error occurs when the Active Directory Installation Wizard is running, copy
 the .reg file to the desktop on the problem domain controller so that the file can
be easily started.

Alternatively, press Windows key+R, and then drag the .reg file from the staged
Explorer window that is focused on that file. Select OK to add the contents of the
.reg file to the registry.

5. When the computer that is being promoted starts replicating the schema naming
context, run the Ntds.reg file to build the \NTDS\Diagnostics registry key and
settings.

２ Warning

The NTDS\Diagnostics registry key does not exist at this phase of promotion
and must be manually created on the destination domain controller. If the
NTDS\Diagnostics registry key is loaded too early when the Active Directory

Installation Wizard is running, the key is overwritten with default values and
no events are logged. For existing domain controllers, the registry settings can
be enabled any time.

6. Examine the directory service events logs on the source and destination servers.
Internal events are displayed on the source server as event ID 1173. Review NTDS
replication events that occur before the internal error to locate the global universal
identification (GUID) of the object that's being replicated. (There may be back-to-
back attempts to replicate the same object). Record the GUID for the problematic
object or container.

7. Start Ldp.exe, initiate a connection, and bind against the source server. From the
Browse menu, select Delete. For the distinguished name path, type
<GUID=GUID#>, for example, <GUID=b2d605a4-b9e6-4505-ba59-
895e91a9a7b5>. Set the search scope to Base, and then delete the specified GUID.

8. Using Ldp.exe, set the value for the TombstoneLifetime attribute to 2 (the value in
days before tombstoned objects are removed). TombstoneLifetime is located in the
following distinguished name path:

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,,DC= root

domain ,DC=COM

Verify that the TombstoneLifetime attribute is present and its value is 2. If the value
is less than 2, the value is invalid, and the server uses the default value of 60 days.
(You can also use ADSIEDIT to change this attribute.)
 ７ Note

After you wait two days for the tombstoned objects to be removed, you may
have to wait an additional 60 minutes or longer before you restart the domain
controller and continue the garbage collection process.

9. Initiate garbage collection on the source domain controller. Locate and click the
following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics key

Edit the following values:

6 Garbage Collection: Set diagnostic level to 3.

9 Internal Processing: Set diagnostic level to 1.

To force a garbage collection, restart the domain controller. Garbage collection

should run 15 minutes after you restart the domain controller. The diagnostic
levels now record garbage collection events in the directory service event log.

10. To verify that the object has been deleted, run the following command:

Console

repadmin /showmeta "<"GUID for deleted object">"

If you receive a message: no such object, the object has already been successfully
deleted, and you can now successfully run the Active Directory Installation Wizard.
If the object has not yet undergone the garbage collection process, there should
be metadata for the isDeleted attribute. The time stamp that's associated with the
isDeleted attribute is the deletion time. Verify that the deletion time is set for at
least two days ago, for example:

Console

repadmin /showmeta "<GUID=b2d605a4-b9e6-4505-ba59-895e91a9a7b>"

11. When this issue is resolved, reset the diagnostics logging levels to 0 and set the
tombstone lifetime back to what it was previously, or remove the value altogether
to prompt the computer to use the default values. The TombstoneLifetime setting
is critical in defining the useful life of system state and Active Directory backups.
When TombstoneLifetime is set to 2, backup tapes that are older than two days are
 unusable. Any domain controller that has been down for two or more days must
be either restored from backup or reinstalled.

The following text is an example of the events that are reported in the directory service
event log on the source and destination server:

Event Type: Information Event Source: NTDS Replication Event Category: Replication
Event ID: 1240 Date: MM/DD/YY Time: HH:MM:SS AM|PM User: S-1-5-21-
1151542997-2719369742-1698538726-500 Computer: computer_source
Description: Property 0 (objectClass) of object CN="NTDS Settings DEL:51c6913c-
9221-4ac4-8513-9155dd7e15ad",CN="ZA9902000 DEL:37eabd48-bc98-483f-b2fd-
9c8869e9c3ce",CN=Servers,CN=Bull,CN=Sites,CN=Configuration,DC=mma,DC=fr
(GUID 51c6913c-9221-4ac4-8513-9155dd7e15ad) is being sent to DSA 6abec3d1-
3054-41c8-a362-5a0c5b7d5d71.

Event Type: Warning Event Source: NTDS General Event Category: Internal
Processing Event ID: 1173 Date: MM/DD/YY Time: HH:MM:SS AM|PM User: S-1-5-
21-1151542997-2719369742-1698538726-500 Computer: computer_source
Description: Internal event: Exception e0010002 has occurred with parameters 8442
and 20a0 (Internal ID 11003a1).

The following text is reported in the Active Directory Installation Wizard log on the
computer that is being promoted. In this sample Dcpromo.log file, the computer that is
being promoted, \\computer_promoted, is encountering the "internal error" in the
Active Directory Installation Wizard when it's sourcing from \\computer_source. Note
the error 8442 that occurs while one of three naming contexts is being replicated ("The
replication system encountered an internal error"). This example shows that the error
occurs on the configuration naming context:

MM/DD HH:MM:SS [INFO] Replicating

CN=Configuration,DC=win2ktest,DC=A,DC=com: received 917 out of 1783 objects.
MM/DD HH:MM:SS [INFO] Replicating
CN=Configuration,DC=win2ktest,DC=A,DC=com: received 1049 out of 1783 objects.
MM/DD HH:MM:SS [INFO] Replicating
CN=Configuration,DC=win2ktest,DC=A,DC=com: received 1181 out of 1783 objects.
MM/DD HH:MM:SS [INFO] Replicating
CN=Configuration,DC=win2ktest,DC=A,DC=com: received 1200 out of 1783 objects.
MM/DD HH:MM:SS [INFO] Error - The Directory Service failed to replicate the
partition CN=Configuration,DC=test,DC=A,DC=com from remote server
computer_source.test.a.com. (8442)
MM/DD HH:MM:SS [INFO] NtdsInstall for test.a.com returned 8442
 MM/DD HH:MM:SS [INFO] DsRolepInstallDs returned 8442
MM/DD HH:MM:SS [ERROR] Failed to install to Directory Service (8442)
MM/DD HH:MM:SS [INFO] Starting service NETLOGON
MM/DD HH:MM:SS [INFO] Configuring service NETLOGON to 2 returned 0
MM/DD HH:MM:SS [INFO] Searching for the machine account
forcomputer_promotedon \computer_source.test.a.com...
MM/DD HH:MM:SS [INFO] Configuring the server account
MM/DD HH:MM:SS [INFO] NtdsSetReplicaMachineAccount returned 0
MM/DD HH:MM:SS [INFO] Attempted to move accountcomputer_sourceto
CN=GAXGPTS01,CN=Computers,DC=test,DC=A,DC=com

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message: The wizard cannot gain
access to the list of domains in the
forest
Article • 02/19/2024

This article helps fix the error (The wizard cannot gain access to the list of domains in
the forest) that occurs when you use Dcpromo.exe to move a Windows Server into an
existing domain.

Applies to: Windows Server 2012 R2

Original KB number: 259374

Symptoms
When you attempt to use Dcpromo.exe to move a Windows 2000-based, or a Windows
Server 2003-based server into an existing domain, the following error message may be
displayed:

Active Directory Installation Wizard

The wizard cannot gain access to the list of domains in the forest. The error is:

The specified domain either does not exist or could not be contacted. If you are using
Windows Server 2008, the error message may resemble the following: Active Directory
Installation Wizard

The wizard cannot access the list of domains in the forest. The error is:

The network path was not found.

Cause
This problem can occur if the server that is running the Domain Name System (DNS)
service has not registered an "A" record for itself in DNS.

The SRV records for the domain controllers must be in the DNS database. If the "A"
record for the DNS server is missing, the process does not succeed.

Resolution
You can add the "A" record to DNS by issuing the following command at the DNS
server:

ipconfig /registerdns After verifying that an "A" record is present for the DNS server, you
may receive the following error message when you attempt to continue the
Dcpromo.exe process:

Active Directory Installation Wizard

The wizard cannot gain access to the list of domain in the forest. The error is:

The RPC server is unavailable.

To resolve this problem, type the following command on the server on which you try to
use Dcpromo.exe. This command clears the DNS resolver cache on the computer that is
running Dcpromo.exe so that it re-creates the query after the "A" record for the DNS
server is registered in the DNS database.ipconfig /flushdns

This problem can also occur during the Dcpromo.exe process if the existing domain
controller that is authenticating this process does not have file and printer sharing
enabled on its network adapter. To resolve this issue, enable file and printer sharing on
the existing domain controller until the Dcpromo.exe process is complete.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The NETLOGON share is not present
after you install Active Directory
Domain Services on a new full or read-
only Windows Server 2008-based
domain controller
Article • 02/19/2024

This article provides a workaround for an issue that occurs after you install Active
Directory Domain Services on a new full or read-only Windows Server 2008-based
domain controller.

） Important

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, see How to back up and restore the registry
in Windows .

Applies to: Windows Server 2012 R2

Original KB number: 947022

Symptoms
After you install Active Directory Domain Services on a new full or read-only Windows
Server 2008-based domain controller in an existing domain, the SYSVOL share is
present. However, the NETLOGON share is not present on the new domain controller.

７ Note

This article does not apply if both NETLOGON and SYSVOL shares are missing.

Cause
This problem occurs when the Netlogon service reads the SysvolReady Flag in the
registry very quickly. Then, the Netlogon service tries to share out the
\Windows\SYSVOL\domain\scripts folder before the NT File Replication Service (NTFRS)
creates this folder.

Workaround

７ Note

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft cannot guarantee that these problems can
be solved. Modify the registry at your own risk.

To work around this issue, set the SysvolReady Flag registry value to 0 and then back to
1 in the registry. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate the following subkey in Registry Editor:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. In the details pane, right-click the SysvolReady flag, and then click Modify.

4. In the Value data box, type 0, and then click OK.

5. Again in the details pane, right-click the SysvolReady flag, and then click Modify.

6. In the Value data box, type 1, and then click OK.

７ Note

This will cause Netlogon to share out SYSVOL, and the scripts folder will be present.

More information
The problem that is described in the Symptoms section occurs in the following scenario:

1. NTFRS first puts changes in the following location:

\Windows\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
 Then, NTFRS notifies Netlogon to share out SYSVOL by setting the SysvolReady
Flag registry entry to 1.

2. NTFRS then moves and renames files from the location that is mentioned in step 1
to the following folder:
\Windows\SYSVOL\domain

3. However, if the Netlogon service reads the SysvolReady Flag entry in the registry
very quickly, the Netlogon service tries to share out the
\Windows\SYSVOL\domain\scripts folder before NTFRS creates this folder.
Therefore, the NETLOGON share is not created.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A newly promoted domain controller
may fail to advertise after completion of
DCpromo
Article • 02/19/2024

This article describes an issue where a newly promoted domain controller fails to
advertise after completion of DCpromo.

Applies to: Windows Server 2012 R2

Original KB number: 967336

Symptoms
A newly promoted domain controller may fail to advertise after completion of DCpromo
and reboot. This issue is specific to domain controllers participating in domains at
functional level where Sysvol is replicated by Distributed Files System Replication (DFSR).

Cause
There's a name resolution or network connectivity issue.

Resolution
To resolve this problem, choose one of the following options:

1. Resolve any possible name resolution or network connectivity issue that would
prevent communication with the defined "Parent Computer"

2. Modify the following registry to point to an available source domain controller:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\S

eeding SysVols\contoso.com

"Parent Computer"=" DC1.contoso.com "

More information
DFSR is a Multi master replication engine used to replicate files and folders for
Distributed files system (DFS) structures and optionally the Domain System Volume in
functional level domains. Domain controllers using DFSR for sysvol will initially
synchronize their Sysvol content after the DCpromo wizard has synchronized Active
Directory and the computer is rebooted.

A replica domain controller will attempt to source its sysvol content from the same
server that it used to source it domain-naming context from during the Active Directory
promotion by reading the "Parent Computer" registry key under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seedin

g SysVols\domain.com

７ Note

"Parent Computer" may be set automatically or defined by an administrator during

DCpromo.

If the Server defined by the "Parent Computer" becomes unavailable after the reboot,
initial synchronization of the sysvol content will be delayed until action to correct the
server's availability on the network has been restored.

Errors reported in the DFSR event log:

Source: DFSR

Event ID: 1202

Level: Error

Description:

The DFS Replication service failed to contact domain controller to access

configuration information. Replication is stopped. The service will try again during
the next configuration polling cycle, which will occur in 60 minutes. This event can
be caused by TCP/IP connectivity, firewall, Active Directory Domain Services, or DNS
issues.

Source: DFSR

Event ID: 4612

Level: Error

Description:
The DFS Replication service initialized SYSVOL at local path
C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The
replicated folder will remain in the initial synchronization state until it has replicated
with its partner WIN-C0T0SC8MCEF.contoso.com . If the server was in the process of
being promoted to a domain controller, the domain controller will not advertise and
function as a domain controller until this issue is resolved. This can occur if the
specified partner is also in the initial synchronization state, or if sharing violations
are encountered on this server or the sync partner. If this event occurred during the
migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes
will not replicate out until this issue is resolved. This can cause the SYSVOL folder on
this server to become out of sync with other domain controllers.

Source: DFSR

Event ID: 4612

Level: Error

Description:

The DFS Replication service initialized SYSVOL at local path

C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The
replicated folder will remain in the initial synchronization state until it has replicated
with its partner DC1.contoso.com. If the server was in the process of being
promoted to a domain controller, the domain controller will not advertise and
function as a domain controller until this issue is resolved. This can occur if the
specified partner is also in the initial synchronization state, or if sharing violations
are encountered on this server or the sync partner. If this event occurred during the
migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes
will not replicate out until this issue is resolved. This can cause the SYSVOL folder on
this server to become out of sync with other domain controllers.

Source: DFSR

Event ID: 5008

Level: Error

Description:

The DFS Replication service failed to communicate with partner DC1 for replication
group Domain System Volume. This error can occur if the host is unreachable, or if
 the DFS Replication service is not running on the server. The service will retry the
connection periodically.

Additional Information:

Error: 1722 (The RPC server is unavailable.)

Source: DFSR

Event ID: 4614

Level: Warning

Description:

The DFS Replication service initialized SYSVOL at local path

C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The
replicated folder will remain in the initial synchronization state until it has replicated
with its partner DC1.contoso.com. If the server was in the process of being
promoted to a domain controller, the domain controller will not advertize and
function as a domain controller until this issue is resolved. This can occur if the
specified partner is also in the initial synchronization state, or if sharing violations
are encountered on this server or the synchronization partner. If this event occurred
during the migration of SYSVOL from File Replication service (FRS) to DFS
Replication, changes will not replicate out until this issue is resolved. This can cause
the SYSVOL folder on this server to become out of sync with other domain
controllers.

Additional Information:

Replicated Folder Name: SYSVOL Share

Errors reported in the DFSR debug logs:

ERROR: DownstreamTransport: SetupBinding Failed

Error: The RPC server is unavailable.

References:

Distributed File System Replication FAQ

Additional information on DFSR debug Logging

DCpromo
How to back up and restore the registry in Windows

DNS Server Operations Guide

Disclaimer
Microsoft and/or its suppliers make no representations or warranties about the
suitability, reliability, or accuracy of the information contained in the documents and
related graphics published on this website (the "materials") for any purpose. The
materials may include technical inaccuracies or typographical errors and may be revised
at any time without notice.

To the maximum extent permitted by applicable law, Microsoft and/or its suppliers
disclaim and exclude all representations, warranties, and conditions whether express,
implied, or statutory, including but not limited to representations, warranties, or
conditions of title, non-infringement, satisfactory condition or quality, merchantability
and fitness for a particular purpose, with respect to the materials.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Requirements for domain controller
certificates from a third-party CA
Article • 03/19/2024

This article describes the requirements that you need to fulfill to issue a domain
controller certificate from a third-party certification authority (CA).

Applies to: Windows Server 2012 R2

Original KB number: 291010

Summary
For more information about the requirements for a Windows Server 2008 R2 domain
controller certificate from a third-party CA, see Updated requirements for a Windows
Server 2008 R2 domain controller certificate from a 3rd party CA .

Support
Currently, Microsoft supports the use of third-party domain controller certificates
with smart card sign-in only.
Currently, Microsoft doesn't support the use of certificates from third-party CAs to
support SMTP (Simple Mail Transfer Protocol) replication between domain
controllers.
Third-party CAs don't support the automatic enrollment and renewal of domain
controller or computer certificates.

Requirements
You can manually issue a certificate to a domain controller. The certificate for the
domain controller must meet the following specific format requirements:

The certificate must have a CRL distribution-point extension that points to a

valid certificate revocation list (CRL).

Optionally, the certificate Subject section should contain the directory path of
the server object (the distinguished name), for example:
CN=server1.northwindtraders.com OU=Domain Controllers
DC=northwwindtraders DC=com
 The certificate Key Usage section must contain:
Digital Signature, Key Encipherment

Optionally, the certificate Basic Constraints section should contain:

[Subject Type=End Entity, Path Length Constraint=None]

The certificate Enhanced Key Usage section must contain:

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

The certificate Subject Alternative Name section must contain the Domain
Name System (DNS) name. If SMTP replication is used, the certificate Subject
Alternative Name section must also contain the globally unique identifier (GUID)
of the domain controller object in the directory. For example:
Other Name: 1.3.6.1.4.1.311.25.1 = ac 4b 29 06 aa d6 5d 4f a9 9c 4c bc b0 6a 65
d9 DNS Name=server1.northwindtraders.com

The certificate template must have an extension that has the basic metabolic
panel (BMP) data value DomainController.

７ Note

The dsstore.exe -dcmon command does not recognize the certificate

without one of these extensions.

You must use the Schannel cryptographic service provider (CSP) to generate
the key.
The domain controller certificate must be installed in the local computer's
certificate store.

Sample certificate
Console

X509 Certificate:
Version: 3
Serial Number: 61497f5e000000000006
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00 ..
Issuer:
CN=TestCA
DC=northwindtraders
 DC=com

NotBefore: 2/12/2001 3:57 PM

NotAfter: 7/10/2001 10:24 AM

Subject:
CN=TEST-DC1
OU=Domain Controllers
DC=northwindtraders
DC=com

Public Key Algorithm:

Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
Algorithm Parameters:
05 00 ..
Public Key Length: 1024 bits
Public Key: UnusedBits = 0
0000 30 81 89 02 81 81 00 b1 c8 84 ce ea 5c da 96 23
0010 4b d5 07 d7 27 f3 76 1f d3 0f 23 3f 8b fa 8b 68
0020 34 09 47 4a f5 33 41 77 86 d2 d3 a7 34 19 5c 49
0030 43 bf 5a 3c 25 a3 77 69 54 ad 84 af 20 b2 c2 f6
0040 40 f7 82 7f b9 b0 db cb db 76 7c 13 54 8e 3b 5e
0050 9e 92 a2 42 8d 97 db 07 06 cc 5d 7a 95 9f 7f 8b
0060 c1 69 7b 0a 6a e7 8f fa 6b c4 60 23 d4 03 88 45
0070 83 61 2e b2 af a2 f9 69 e2 84 d9 95 01 c4 88 eb
0080 89 16 5a 4d a4 34 27 02 03 01 00 01
Certificate Extensions: 9
1.2.840.113549.1.9.15: Flags = 0, Length = 37
SMIME Capabilities
[1]SMIME Capability
Object ID=1.2.840.113549.3.2
Parameters=02 02 00 80
[2]SMIME Capability
Object ID=1.2.840.113549.3.4
Parameters=02 02 00 80
[3]SMIME Capability
Object ID=1.3.14.3.2.7
[4]SMIME Capability
Object ID=1.2.840.113549.3.7

2.5.29.15: Flags = 0, Length = 4

Key Usage
Digital Signature, Key Encipherment (a0)

2.5.29.37: Flags = 0, Length = 16

Enhanced Key Usage
Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

1.3.6.1.4.1.311.20.2: Flags = 0, Length = 22

Certificate Template Name
DomainController

2.5.29.14: Flags = 0, Length = 16

Subject Key Identifier
 a8 20 ce 65 63 3e cd a1 c8 77 97 44 fa 28 43 71 17 e3 6e 84

2.5.29.35: Flags = 0, Length = 18

Authority Key Identifier
KeyID=44 b8 25 f8 d9 53 c5 96 e1 8c 14 d5 e4 5e 33 3a fc 22 7b e7

2.5.29.31: Flags = 0, Length = f8

CRL Distribution Points
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://test-
dc1.northwindtraders.com/CertEnroll/TestCA.crl
URL=ldap:///CN=TestCA,CN=test-
dc1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=northw
indtraders,DC=com?certificateRevocationList?base?
objectClass=cRLDistributionPoint

1.3.6.1.5.5.7.1.1: Flags = 0, Length = 10a

Authority Information Access
[1]Authority Info Access
Access Method=Certification Authority Issuer
(1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://test-dc1.northwindtraders.com/CertEnroll/test-
dc1.northwindtraders.com_TestCA.crt
[2]Authority Info Access
Access Method=Certification Authority Issuer
(1.3.6.1.5.5.7.48.2)
Alternative Name:

URL=ldap:///CN=TestCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Confi
guration,DC=northwindtraders,DC=com?cACertificate?base?
objectClass=certificationAuthority

2.5.29.17: Flags = 0, Length = 3d

Subject Alternative Name
Other Name:
1.3.6.1.4.1.311.25.1=04 10 96 8e ea d7 ee ba bc 42 81 db 4f 92
f5 88 db 4a
DNS Name=test-dc1.northwindtraders.com

Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00

How to determine the domain controller GUID

Start Ldp.exe and locate the domain-naming context. Double-click the name of the
domain controller that you want to view. The list of attributes for that object contains
"Object GUID" followed by a long number. The number is the GUID for that object.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Schema mismatch" error message
occurs when you try to run the Active
Directory Installation Wizard
(Dcpromo.exe)
Article • 02/19/2024

This article provides the resolution of fixing the error "schema mismatch", when you try
to run the Active Directory Installation Wizard (Dcpromo.exe).

Applies to: Windows Servers 2012 R2

Original KB number: 838179

Symptoms
When you run the Active Directory Installation Wizard (Dcpromo.exe) on a computer
that is running one of the editions of Microsoft Windows that is listed in the "Applies to"
section, you may receive a "schema mismatch" error message.

If you are running Microsoft Windows Server 2003, you may receive the following error
message:

Active Directory could not replicate the directory partition DN path for partition
from the remote domain controller fully qualified computer name of the source
domain controller. The replication operation failed because of a schema mismatch
between the servers involved.

If you are running Microsoft Windows 2000, you may receive the following error
message:

The Directory Service failed to replicate the partition partition name from remote
server remote server name. The replication operation failed because of a schema
mismatch between the servers involved.

Cause
This problem may occur if one of the following conditions is true:
 Condition 1: The source domain controller's copy of the Active Directory directory
service contains duplicate multi-valued attributes.
Condition 2: One or more attributes or pages in the database of the source domain
controller are corrupted.
Condition 3: The source domain controller has attributes in its database that are
not covered by the current schema because of schema deletion.

Resolution
To resolve this problem, use one of the following two methods. Method 1 addresses
Condition 1 and Condition 2. Method 2 addresses Condition 3.

Method 1: Resolution for Condition 1 and Condition 2

The "schema mismatch" error message is misleading. The root cause of the error may
not have anything to do with the schema partition (CN) or with any objects that are in it.
The actual problem may be a database constraint violation, such as a multi-valued
attribute with duplicate values.

To troubleshoot and to resolve this problem, follow the steps in this six-part procedure.

Part 1: Turn on diagnostic logging

Turn on diagnostic logging on the source domain controller. To do this, follow these
steps.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:

322756 How to back up and restore the registry in Windows

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

3. In the Name column in the right pane, right-click the 5 Replication Events registry
entry, and then click Modify.

4. Type 5, and then click OK.

5. Repeat steps 3 and 4 for the following registry entries:

7 Internal Configuration
8 Directory Access
9 Internal Processing
24 DS Schema

6. In the left pane, click the following registry subkey again:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

7. On the File menu, click Export.

8. In the Save in box, open the administrator's Desktop folder on the computer
where you are receiving the "schema mismatch" error message. In the File name
box, type Ntds_logging, and then click OK.

７ Note

Typically, the administrator's Desktop folder is C:\Documents and

Settings\Administrator\Desktop. However the system drive letter can vary. To
find the system drive that your computer uses, follow these steps:

a. Log on to the computer where you are receiving the "schema mismatch" error
message.

b. Click Start, click Run, type command, and then click OK.

c. Type set, and then press ENTER.

The output line that begins with "SystemDrive=" shows you the drive letter that
your system uses.

d. Type exit, and the press ENTER.

Part 2: Force inbound replication of Active Directory

Force the destination computer to perform inbound replication of Active Directory from
a domain controller where NTDS diagnostic logging has been enabled. If there are
multiple source domain controllers, make sure that replication occurs from a source
domain controller where diagnostic logging has been enabled. To do this, use one of
the following methods:

Increase HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics
logging on all possible source domain controllers by using steps 1 through 5 in the
"Part 1: Turn on diagnostic logging" section.

Stop the Net Logon service on all possible source domain controllers except the
source domain controller that is referenced in the "schema mismatch" error where
logging was increased. To do this, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click
Services.
2. Right-click Net Logon, and then click Stop.
3. Create an unattended Active Directory Installation Wizard answer file.

Run the Active Directory Installation Wizard on the destination computer that is
reporting the "schema mismatch" error with NTDS diagnostic logging enabled. The
exact time that NTDS diagnostic logging occurs depends on whether the computer
that is being promoted is running Windows 2000 or Windows Server 2003.

The Active Directory Installation Wizard affects the following Windows registry
keys:
Helper domain controllers that are running Windows 2000 or Windows Server
2003 preserve log settings in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

registry subkey until the Active Directory Installation Wizard demotes these
domain controllers.
Windows 2000-based computers that are being promoted overwrite the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

registry subkey at the beginning of each promotion attempt. Double-click

Ntds_logging.reg as soon as inbound replication of the schema partition from
the helper domain controller has started to pre-populate the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

registry subkey for each attempt to promote the Windows 2000-based domain
controller.
Windows Server 2003-based computers do not overwrite pre-existing values in
the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics
 registry subkey. However, existing settings are deleted after each failed
promotion attempt.

Part 3: Pre-populate the registry on destination domain controllers

Pre-populate the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics subkey on

destination domain controllers that are running Windows 2000 or Windows Server 2003.
To do this, follow these steps:

1. On the source domain controller, follow steps 1 through 5 in the "Part 1: Turn on
diagnostic logging" section.

2. Right-click the following registry subkey, and then click Export:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics

3. In the Save in box, open the administrator's Desktop folder on the computer that
is being promoted. In the File name box, type Ntds_logging, and then click OK.

７ Note

To locate the Desktop folder, see the note in Part 1, step 8.

4. On the destination domain controller, double-click the Ntds_logging.reg file that

you saved in the administrator's Desktop folder at the appropriate time, depending
on whether the computer that is being promoted is running Windows Server 2003
or Windows 2000.

Part 4: Locate any duplicate multi-valued attributes

1. Examine the directory service event logs on both the source domain controller and
the destination domain controller to find the problem object.

2. On the source domain controller, review the directory service event log and note
the last object and attribute that were outbound replicated to the domain
controller that is being promoted. The problem object is either the last object or
attribute that is referenced in the directory service event log or the object in the
same partition with the next highest Update Sequence Number (USN). Record the
domain name path of the object that is referenced and the last attribute that was
replicated. On the source domain controller, look for the last event 1240. On the
destination domain controller, look for event 1203.
3. Use the ldifde command to export the object that is referenced. To do this:
a. Click Start, click Run, type command, and then click OK.
b. Type the following, and then press ENTER: LDIFDE -f MISMATCH -d <domain name
path of object referenced in event log of the source domain controller>

4. Examine the ldifde output in Notepad or another text editor. Pay particular
attention to attributes that have duplicate values. For example, the following
truncated example contains attributes with duplicate values:

msExchMonitoringResponses:: <Start of Duplicate #1>

W19fQ0xBU1M6c3RyKDE3KV1TTVRQRXZlbnRDb25zdW1lcltOb3RpZnlPbkVyc
m9yOnN0cigyKV0tMV
tSZXNwb25kVG9XaGljaE9iamVjdHM6c3RyKDEpXTBbT2JqZWN0c1RvUmVzcG9
uZFRvOnN0cigwKV1b
U01UUFNlcnZlcjpzdHIoNCldQUxFWFtUb0xpbmU6c3RyKDI1KV1yamtlbnZpbkB
tZXRib2UuazEyLm
5qLnVzW01lc3NhZ2U6c3RyKDMxNyldJVRhcmdldEluc3RhbmNlLk5hbWUlIGhhc
yByZXBvcnRlZCBh
ICVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUuICBSZXBvcnRlZCB
zdGF0dXMgaXM6DQ pRdWV1ZXMgLSAlVGFy
Z2V0SW5zdGFuY2UuUXVldWVzU3RhdGVTdHJpbmclDQpEcml2ZXMgLSAlVGFy
Z2V0SW5zdGFuY2UuRGlza3NTdGF0ZVN0cmluZyUNClNlcnZpY2VzIC0gJVRhcm
dldEluc3RhbmNlLl
NlcnZpY2VzU3RhdGVTdHJpbmclDQpNZW1vcnkgLSAlVGFyZ2V0SW5zdGFuY2
UuTWVtb3J5U3RhdGVT
dHJpbmclDQpDUFUgLSAlVGFyZ2V0SW5zdGFuY2UuQ1BVU3RhdGVTdHJpbmcl
DQpbU3ViamVjdDpzdH
IoNTkpXSVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUgb24gJVRh
cmdldEluc3RhbmNl Lk5hbWUl msExchMonitoringResponses:: <Start of
Duplicate#2>
W19fQ0xBU1M6c3RyKDE3KV1TTVRQRXZlbnRDb25zdW1lcltOb3RpZnlPbkVyc
m9yOnN0cigyKV0tMV
tSZXNwb25kVG9XaGljaE9iamVjdHM6c3RyKDEpXTBbT2JqZWN0c1RvUmVzcG9
uZFRvOnN0cigwKV1b
U01UUFNlcnZlcjpzdHIoNCldQUxFWFtUb0xpbmU6c3RyKDI1KV1yamtlbnZpbkB
tZXRib2UuazEyLm
5qLnVzW01lc3NhZ2U6c3RyKDMxNyldJVRhcmdldEluc3RhbmNlLk5hbWUlIGhhc
yByZXBvcnRlZCBh
ICVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUuICBSZXBvcnRlZCB
zdGF0dXMgaXM6DQ pRdWV1ZXMgLSAlVGFy
Z2V0SW5zdGFuY2UuUXVldWVzU3RhdGVTdHJpbmclDQpEcml2ZXMgLSAlVGFy
 Z2V0SW5zdGFuY2UuRGlza3NTdGF0ZVN0cmluZyUNClNlcnZpY2VzIC0gJVRhcm
dldEluc3RhbmNlLl
NlcnZpY2VzU3RhdGVTdHJpbmclDQpNZW1vcnkgLSAlVGFyZ2V0SW5zdGFuY2
UuTWVtb3J5U3RhdGVT
dHJpbmclDQpDUFUgLSAlVGFyZ2V0SW5zdGFuY2UuQ1BVU3RhdGVTdHJpbmcl
DQpbU3ViamVjdDpzdH
IoNTkpXSVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUgb24gJVRh
cmdldEluc3RhbmNl Lk5hbWUl

5. If duplicate values appear, use Adsiedit.msc or ldifde to remove one of the

duplicates. After you have removed the duplicates, retry the promotion by running
the Active Directory Installation Wizard again.

Part 5: Look for database corruption

The root cause may be database corruption on the source domain controller. To locate
database corruption and repair it, follow these steps:

1. Examine the source domain controller's directory services event log for the last
1240 event that was logged. This event may be logged just before Internal
Processing Event 1173. Note the DN path of the object that is referenced in the
last 1240 event, and then run the Repadmin.exe tool on the console of the source
domain controller. To do this, follow these steps:
a. Click Start, click Run, type command, and then click OK.
b. Type the following command, and then press ENTER:

Console

REPADMIN /SHOWMETA CN=Secret,CN=Schema,CN=Configuration,DC=CORP,DC=COM

2. View the metadata of the last outbound-replicated object that was replicated from
the source domain controller. If no duplicate values are found, examine the source
domain controller's directory services event log for the last 1240 event that was
logged before a 1173 event. The following is a sample 1240 event.

3. Run the repadmin /showmeta command against the domain name path of the
object that is referenced in the last 1240 event that was logged on the source
domain controller. For example, using the sample event in step 2 for a domain
controller in the CORP.COM domain, the syntax would be the following:

Console
 REPADMIN /SHOWMETA CN=Secret,CN=Schema,CN=Configuration,DC=CORP,DC=COM

Look for inconsistent or suspicious values in the output, especially in the Local USN
and the Originating time columns. For example, in the following truncated output
example, two attributes, defaultObjectCategory and ObjectClass, have what
appears to be USN numbers and 0 date and time stamps that are not valid.

Truncated output from the repadmin /showmeta command:

CN=Secret,=Schema,CN=Configuration,DC=CORP,DC=COM object Loc.

USNOriginating Time: Attribute 21962002-01-29 05:52.47 instanceType
18295873486194836 4446-09-07 21:51.13defaultObjectCategory
182958734861948362002-01-29 05:52.47 objectClass

4. If the problem object that is referenced in the output is not a critical object, make a
ldifde backup of the object, and then delete the object. Do not delete problem
objects that reside in the schema partition of Active Directory.

5. Run an NTDSUTIL files integrity check against the Active Directory database. To do
this:

a. Windows 2000 uses setpwd to change the DSRM passwords. Windows Server
2003 uses ntdsutil to change the DSRM passwords.

The following option works in Windows Server 2003:

322672 How to reset the Directory Services Restore Mode administrator

account password in Windows Server

b. Start the source domain controller in DSREPAIR mode.

７ Note

Clients that try to access the DFS Root information or the DFS Link
information may receive an "access denied" error message during an
attempt to connect while the domain controller is in DSREPAIR mode. This
behavior is by design.

c. Run NTDSUTIL files integrity check from the Windows command prompt.

d. Look for errors in the NTDSUTIL output.

6. If the NTDSUTIL integrity check logged jet error -1206, investigate the following
options. Do not under any circumstances repair corrupted Active Directory
databases by using NTDSUTIL or by using ESENTUTL equivalents.

a. If other candidate domain controllers exist to source the new domain controller
in the forest, run the Active Directory Installation Wizard with the problem
source domain controller offline.

b. If other domain controllers in the domain exist and if there is no significant

system state unique to the helper domain controller, try to gracefully demote
the original source domain controller. Otherwise, force-demote it, and then
remove its metadata from the forest. Run the Active Directory Installation
Wizard to add the original domain controller back to the forest after end-to-end
replication of the removal on all domain controllers in the forest has occurred.

c. Restore the system state for that domain controller if the all following
conditions are true:

The original source domain controller is the only domain controller in its
domain.
It contains critical system state (that is, it contains the forest root domain,
or there is a significant investment in objects in its copy of Active
Directory).
A valid system state backup exists (that is, the backup is less than
tombstonelifetime days old and it contains no corrupted objects).

７ Note

A system state restore of a partition that contains a single replica is

effectively an authoritative restore of that partition.

d. If the original source domain controller is the only domain controller in its
domain and if it contains critical system state but no valid system state backups
exist, consider doing the following:

Add a Microsoft Windows NT 4.0-based backup domain controller (BDC) to

the domain. This option assumes a mixed mode or a switch that allows the
Windows NT 4.0-based BDC to replicate with Windows 2000-based domain
controllers in native mode domains.
Put the Windows NT 4.0-based BDC on a private network.
Promote the Windows NT 4.0-based BDC to a primary domain controller
(PDC).
 Upgrade the Windows NT 4.0-based PDC to Windows 2000 or to Windows
Server 2003.
Add replica domain controllers for fault-tolerance and load balancing.
Add the required schema changes for Active Directory programs.

Part 6: Turn off diagnostic logging

After you have finished troubleshooting and resolving the problem, turn off diagnostic
logging. To do this, go to "Part 1: Turn on diagnostic logging," and follow steps 1
through 5. Set the following registry entries to 0 (zero).

5 Replication Events
7 Internal Configuration
8 Directory Access
9 Internal Processing
24 DS Schema

Method 2: Resolution for Condition 3

The third cause for the "schema mismatch" error occurs when the helper domain
controller has attributes in its database that are not covered by the current schema. This
problem may occur if a schema object was deleted on a Windows 2000 domain
controller before Service Pack 3 (SP3) for Windows 2000 was installed.

To resolve this problem, follow these steps:

1. Identify the object that has the attributes that are not in the schema. To do this,
consider the following:

If you are running Windows 2000, the 1039 event is logged on the source
domain controller with the DN of the object that was affected.
If you are running any other operating system, enable replication events at
level five (5) on the source. During outbound replication, the object and the
attribute that are being shipped will be logged. When the error occurs, look
for the next object that would be shipped to the destination computer.

2. After you identify the object that has the extra attributes, do any one or more of
the following:

Delete the object. The offending attributes will be stripped, and the
tombstone will be shipped for replication.
Edit the object to remove the attributes in question.
Re-add the schema entries that were removed.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server 2008 and newer
domain controller returns only 5000
values in an LDAP response
Article • 02/19/2024

This article provides a solution to an issue where the Windows Server 2008 R2 or newer
domain controller only returns 5000 values for an LDAP response.

Applies to: Windows Server 2012 R2

Original KB number: 2009267

Symptoms
An LDAP application may return less information when a query is sent to a Windows
Server 2008 or Windows Server 2008 R2 domain controller than when sent to a
Windows Server 2003 domain controller. The query results may appear truncated or
incomplete. In some occasions, you may not get any results. For example, if an LDAP
application queries the members of a group, the Windows Server 2008 R2 or Windows
Server 2008 domain controller only returns 5000 members, while the Windows Server
2003 domain controllers return many more members. In both cases, you may realize the
same extended LDAP policy setting in NTDSUTIL required for the LDAP application. For
more information about viewing the LDAP policy settings, click the following article
number to view the article in the Microsoft Knowledge Base:

315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

Sample output:

ldap policy: show values

Policy Current(New)

MaxPoolThreads 4
MaxDatagramRecv 4096
MaxReceiveBuffer 10485760
InitRecvTimeout 120
MaxConnections 5000
MaxConnIdleTime 900
MaxPageSize 50000
MaxQueryDuration 120
 MaxTempTableSize 10000
MaxResultSetSize 262144
MinResultSets 0
MaxResultSetsPerConn 0
MaxNotificationPerConn 5
MaxValRange 25000

７ Note

On both domain controllers, the setting MaxPageSize is set to 50000 (default 1000)
and MaxValRange to 25000 (default 1500).

Cause
Internal LDAP limitations have been introduced in Windows Server 2008 R2 and
Windows Server 2008 to prevent overloading the domain controller. These limits
overwrite the LDAP policy setting when the policy value should be higher.

ﾉ Expand table

LDAP setting maximum value (hardcoded)

MaxReceiveBuffer 20971520

MaxPageSize 20000

MaxQueryDuration 1200

MaxTempTableSize 100000

MaxValRange 5000

Therefore the effective setting for the above LDAP policy is MaxPageSize=50000 and
MaxValRange=25000 on a Windows Server 2003 domain controller as configured in the
LDAP policy but on a Windows Server 2008 R2 or Windows Server 2008 domain
controller the hardcoded limits dictate MaxPageSize=20000 and MaxValRange=5000.
MaxValRange affects the number of attributes returned for a query. If you perform an
LDAP query for the multi-valued attribute Member for a group object with more than
5000 members the Windows Server 2008 R2 or Windows Server 2008 domain controller
will only return 5000 of them.
Resolution
The new maximum limits introduced with Windows Server 2008 R2 and Windows Server
2008 try to enforce the message that applications should adopt to the policies AD wants
to enforce. You should adapt your LDAP application accordingly. For the MaxValRange
limitation you may consider the following MSDN information and samples for using
ranged queries: Range Retrieval of Attribute Values
https://msdn.microsoft.com/library/cc223242(PROT.10).aspx
The following code example uses ranging to retrieve the members of a group using the
IDirectoryObject interface: Example Code for Ranging with IDirectoryObject
https://msdn.microsoft.com/library/aa705923(VS.85).aspx
The following code example uses ranging to retrieve the members of a group using the
IDirectorySearch interface: Example Code for Ranging with IDirectorySearch
https://msdn.microsoft.com/library/aa705924(VS.85).aspx
For MaxPageSize it is recommended to used paged queries, outlined on MSDN as
follows: Paging Search Results
https://msdn.microsoft.com/library/aa367011(VS.85).aspx
ldap_create_page_control Function
https://msdn.microsoft.com/library/aa366547(VS.85).aspx
There is a way to override these limitations, but we encourage to discuss the
requirements with Microsoft customer technical support to decide if modifying the
policies is the correct approach.

More information
For more information about LDAP policies, visit LDAP Policies
https://msdn.microsoft.com/library/cc223376(PROT.10).aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain controller is not functioning
correctly
Article • 02/19/2024

This article provides common resolutions to the issue where domain controller is not
functioning correctly.

Applies to: Windows Server 2012 R2

Original KB number: 837513

Symptoms
When you run the Dcdiag tool on a Microsoft Windows 2000-Server based domain
controller or on a Windows Server 2003-based domain controller, you may receive the
following error message:

DC Diagnosis
Performing initial setup:
[DC1] LDAP bind failed with error 31

When you run the REPADMIN /SHOWREPS utility locally on a domain controller, you may
receive one of the following error messages:

[D:\nt\private\ds\src\util\repadmin\repinfo.c, 389] LDAP error 82 (Local Error).

Last attempt @ yyyy-mm-dd hh:mm.ss failed, result 1753: There are no more
endpoints available from the endpoint mapper.

Last attempt @ yyyy-mm-dd hh:mm.ss failed, result 5: Access is denied.

If you use Active Directory Sites and Services to trigger replication, you may receive a
message that indicates that access is denied.

When you try to use network resources from the console of an affected domain
controller, including Universal Naming Convention (UNC) resources or mapped network
drives, you may receive the following error message:

No logon servers available (c000005e = "STATUS_NO_LOGON_SERVERS")

If you start any Active Directory administrative tools from the console of an affected
domain controller, including Active Directory Sites and Services and Active Directory
Users and Computers, you may receive one of the following error messages:

Naming information cannot be located because: No authority could be contacted

for authentication. Contact your system administrator to verify that your domain is
properly configured and is currently online.

Naming information cannot be located because: Target account name is incorrect.

Contact your system administrator to verify that your domain is properly configured
and is currently online.

Microsoft Outlook clients that are connected to Microsoft Exchange Server computers
that are using affected domain controllers for authentication may be prompted for
logon credentials, even though there is successful logon authentication from other
domain controllers.

The Netdiag tool may display the following error messages:

DC list test . . . . . . . . . . . : Failed

[WARNING] Cannot call DsBind to <servername>.<fqdn> (<ip address>).
[ERROR_DOMAIN_CONTROLLER_NOT_FOUND]
Kerberos test. . . . . . . . . . . : Failed
[FATAL] Kerberos does not have a ticket for krbtgt/<fqdn>.

[FATAL] Kerberos does not have a ticket for <hostname>.

LDAP test. . . . . . . . . . . . . : Passed
[WARNING] Failed to query SPN registration on DC <hostname><fqdn>

The following event may be logged in the system event log of the affected domain
controller:

Output

Event Type: Error

Event Source: Service Control Manager
Event ID: 7023
Description: The Kerberos Key Distribution Center service terminated with
the following error: The security account manager (SAM) or local security
authority (LSA) server was in the wrong state to perform the security
operation.
Resolution
There are several resolutions for these symptoms. The following is a list of methods to
try. The list is followed by steps to perform each method. Try each method until the
problem is resolved. Microsoft Knowledge Base articles that describe less common fixes
for these symptoms are listed later.

1. Method 1: Fix Domain Name System (DNS) errors.

2. Method 2: Synchronize the time between computers.
3. Method 3: Check the Access this computer from the network user rights.
4. Method 4: Verify that the domain controller's userAccountControl attribute is
532480.
5. Method 5: Fix the Kerberos realm (confirm that the PolAcDmN registry key and the
PolPrDmN registry key match).
6. Method 6: Reset the machine account password, and then obtain a new Kerberos
ticket.

Method 1: Fix DNS errors

1. At a command prompt, run the netdiag -v command. This command creates a
Netdiag.log file in the folder where the command was run.
2. Resolve any DNS errors in the Netdiag.log file before you continue. The Netdiag
tool is in the Windows 2000 Server Support Tools on the Windows 2000 Server CD-
ROM or as a download.
3. Make sure that DNS is configured correctly. One of the most common DNS
mistakes is to point the domain controller to an Internet Service Provider (ISP) for
DNS instead of pointing DNS to itself or to another DNS server that supports
dynamic updates and SRV records. We recommend that you point the domain
controller to itself or to another DNS server that supports dynamic updates and
SRV records. We recommend that you set up forwarders to the ISP for name
resolution on the Internet.

For more information about configuring DNS for Active Directory directory service, click
the following article numbers to view the articles in the Microsoft Knowledge Base:
254680 DNS namespace planning

Method 2: Synchronize the time between computers

Verify that the time is correctly synchronized between domain controllers. Additionally,
verify that the time is correctly synchronized between client computers and domain
controllers.
Method 3: Check the "Access this computer from the
network" user rights
Modify the Gpttmpl.inf file to confirm that the appropriate users have the Access this
computer from the network user right on the domain controller. To do this, follow these
steps:

1. Modify the Gpttmpl.inf file for the Default Domain Controllers Policy. By default,
the Default Domain Controllers Policy is where user rights are defined for a domain
controller. By default, the Gpttmpl.inf file for the Default Domain Controllers Policy
is located in the following folder.

７ Note

Sysvol may be in a different location, but the path for the Gpttmpl.inf file will
be the same.

For Windows Server 2003 domain controllers:

C:\WINDOWS\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-
945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

For Windows 2000 Server domain controllers:

C:\WINNT\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-945F-
00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

2. To the right of the SeNetworkLogonRight entry, add the security identifiers for
Administrators, for Authenticated Users, and for Everyone. See the following
examples.

For Windows Server 2003 domain controllers:

SeNetworkLogonRight = *S-1-5-32-554,*S-1-5-9,*S-1-5-32-544,*S-1-1-0

For Windows 2000 Server domain controllers:

SeNetworkLogonRight = *S-1-5-11,*S-1-5-32-544,*S-1-1-0

７ Note
 Administrators (S-1-5-32-544), Authenticated Users (S-1-5-11), Everyone (S-1-
1-0), and Enterprise Controllers (S-1-5-9) use well-known security identifiers
that are the same in every domain.

3. Remove any entries to the right of the SeDenyNetworkLogonRight entry (Deny

access to this computer from the network) to match the following example.

SeDenyNetworkLogonRight =

７ Note

The example is the same for Windows 2000 Server and for Windows Server
2003.

By default, Windows 2000 Server has no entries in the SeDenyNetworkLogonRight

entry. By default, Windows Server 2003 has only the Support_random string
account in the SeDenyNetworkLogonRight entry. (The Support_random string
account is used by Remote Assistance.) Because the Support_random string
account uses a different security identifier (SID) in every domain, the account is not
easily distinguishable from a typical user account just by looking at the SID. You
may want to copy the SID to another text file, and then remove the SID from the
SeDenyNetworkLogonRight entry. That way, you can put it back when you are
finished troubleshooting the problem.

SeNetworkLogonRight and SeDenyNetworkLogonRight can be defined in any

policy. If the previous steps do not resolve the issue, check the Gpttmpl.inf file in
other policies in Sysvol to confirm that the user rights are not also being defined
there. If a Gpttmpl.inf file contains no reference to SeNetworkLogonRight or to
SeDenyNetworkLogonRight, those settings are not defined in the policy and that
policy is not causing this issue. If those entries do exist, make sure that they match
the settings listed earlier for the Default Domain Controller policy.

Method 4: Verify that the domain controller's

userAccountControl attribute is 532480
1. Click Start, click Run, and then type adsiedit.msc.
2. Expand Domain NC, expand DC=domain, and then expand OU=Domain
Controllers.
3. Right-click the affected domain controller, and then click Properties.
 4. In Windows Server 2003, click to select the Show mandatory attributes check box
and the Show optional attributes check box on the Attribute Editor tab. In
Windows 2000 Server, click Both in the Select which properties to view box.
5. In Windows Server 2003, click userAccountControl in the Attributes box. In
Windows 2000 Server, click userAccountControl in the Select a property to view
box.
6. If the value is not 532480, type 532480 in the Edit Attribute box, click Set, click
Apply, and then click OK.
7. Quit ADSI Edit.

Method 5: Fix the Kerberos realm (confirm that the

PolAcDmN registry key and the PolPrDmN registry key
match)

７ Note

This method is valid only for Windows 2000 Server.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

1. Start Registry Editor.

2. In the left pane, expand Security.
3. On the Security menu, click Permissions to grant the Administrators local group
Full Control of the SECURITY hive and its child containers and objects.
4. Locate the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN key.
5. In the right pane of Registry Editor, click the <No Name>: REG_NONE entry one
time.
6. On the View menu, click Display Binary Data. In the Format section of the dialog
box, click Byte.
 7. The domain name appears as a string in the right side of the Binary Data dialog
box. The domain name is the same as the Kerberos realm.
8. Locate the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN registry key.
9. In the right pane of Registry Editor, double-click the <No Name>: REG_NONE
entry.
10. In the Binary Editor dialog box, paste the value from PolPrDmN. (The value from
PolPrDmN will be the NetBIOS domain name).
11. Restart the domain controller.

Method 6: Reset the machine account password, and then

obtain a new Kerberos ticket
1. Stop the Kerberos Key Distribution Center service, and then set the startup value
to Manual.

2. Use the Netdom tool from the Windows 2000 Server Support Tools or from the
Windows Server 2003 Support Tools to reset the domain controller's machine
account password:

Console

netdom resetpwd /server: <another domain controller>

/userd:domain\administrator /passwordd: <administrator password>

Make sure that the netdom command is returned as completed successfully. If it is

not, the command did not work. For the domain Contoso, where the affected
domain controller is DC1, and a working domain controller is DC2, you run the
following netdom command from the console of DC1:

Console

netdom resetpwd /server:DC2 /userd:contoso\administrator /passwordd:

<administrator password>

3. Restart the affected domain controller.

4. Start the Kerberos Key Distribution Center service, and then set the startup setting
to Automatic.

For more information about this issue, click the following article numbers to view the
articles in the Microsoft Knowledge Base:
323542 You cannot start the Active Directory Users and Computers tool because the
server is not operational

Feedback
Was this page helpful?  Yes  No

Provide product feedback

LDAP queries are executed more slowly
than expected in the AD or LDS/ADAM
directory service and Event ID 1644 may
be logged
Article • 02/19/2024

This article provides a workaround for an issue where LDAP queries perform slowly on a
Windows Server computer that uses an AD LDS or an ADAM directory service.

Applies to: Windows Server 2012 R2

Original KB number: 951581

Symptoms
On a Windows Server computer that uses an Active Directory Lightweight Directory
Services (AD LDS) or Active Directory Application Mode (AD/AM) directory service,
certain applications do not perform at expected performance levels.

When you enable field engineering (debug) logging to trace an LDAP query, the
following event log shows that the LDAP query is an inefficient query.

７ Note

The attributes that are used in this event are only examples.

Additionally, you experience high CPU utilization and a slow response time. If the
database is considerably bigger than physical memory available to the directory server,
you may also see increased disk IO while the processing such a query.

When you inspect the attributes in the search filter, you find that they all have indexes
that are defined. And if attributes do not have indexes that are defined, and you add the
indexes through a schema change, the problem persists or does not improves much.

Cause
When you create a network trace of the LDAP query, you notice that it is a paged query.
The LDAP server can only use one index while processing a paged query. This is because
the LDAP implementation for paged searches does not create an expensive context for
the query and thus only uses one index for a paged query.

Workaround
To work around this problem, you can send the query without using the paged query
control. This allows the LDAP server to optimize for more complex filters.

７ Note

By default, paged queries are enabled for some LDAP client libraries. Therefore, you
may have to write additional code in your application to enable and disable paged
queries as appropriate for your specific situation.

Status
Microsoft has confirmed that this is a problem.

References
How to configure Active Directory and LDS diagnostic event logging

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot high Lsass.exe CPU
utilization on Active Directory Domain
Controllers
Article • 02/19/2024

This article solves the high Lsass.exe CPU usage on Active Directory Domain Controllers.

Applies to: Windows Server 2012 R2

Original KB number: 2550044

Symptoms
This problem may be seen in the following ways:

A System Center Advisor alert has been triggered. It calls out that the Lsass.exe
process is using a consistently large percentage of the CPU's capabilities (CPU
utilization counter).
A domain controller is responding slowly, or isn't responding at all to client service
requests for authentication or directory lookups.
Active Directory domain clients consistently or frequently stop requesting service
from a domain controller. Instead, they locate a different domain controller to gain
services from.
Performance monitoring using Perfmon.msc or Task Manager reveals that the
Lsass.exe process is using a consistently large percentage of the CPU's capabilities
(Process Object, % Processor Time counter).

Cause
This problem can be caused by many different single, or combined issues. Nearly each
cause and resolution for these issues are unique. In Windows Server 2008 and later, the
following tool is available to help determine the problem cause:

The Performance Monitor's Active Directory Data Collector Set

Resolution
To fix this issue, run the Performance Monitor's Active Directory Data Collector Set on
the domain controller while the problem is occurring. This tool uses performance
counters and tracing to monitor the issue. Then it compiles a report that shows details
of potential problems. These problems need to be investigated as possible causes.

To run the Active Directory Data Collector, follow these steps:

1. Open Server Manager on a Full version of Windows Server 2008 or later, or go to

Start > Run > Perfmon.msc and then press enter.
2. Expand Diagnostics > Reliability and Performance> Data Collector Sets >
System.
3. Right-click on Active Directory Diagnostics and then select Start in the menu that
appears.
4. The default setting will gather data for the report for 300 seconds (5 minutes).
Then it will take an extra period to compile the report. The amount of time needed
to compile the report is proportional to how much data has been gathered.

After the report has compiled, go to Diagnostics > Reliability and Performance >
Reports > System > Active Directory Diagnostics. View the report or reports that have
been completed.

The report contains eight broad categories under Diagnostic Results that will contain
information and conclusions in the report. It won't always tell the exact cause of the
problem. But you can use it to determine where to investigate to find the exact cause.

When facing high CPU usage by Lsass.exe, check the Diagnostic Results portion of the
report. It shows general performance concerns. Also examine the Active Directory
category. It details what actions the domain controller is busy doing at that time. For
example, what LDAP queries are affecting performance.

Domain controllers are often most effected by remote queries from computers in the
environment asking expensive queries. Or they are subject to a higher volume of
queries. The Network portion of the report is useful to determine the remote clients that
are communicating most with the domain controller while the diagnostic was gathering
data.

More information
Local Security Authority Subsystem Service (Lsass.exe) is the process on an Active
Directory domain controller. It's responsible for providing Active Directory database
lookups, authentication, and replication.

For more information about how to troubleshoot high CPU usage of the Lsass.exe
process on an Active Directory domain controller, see Son of SPA: AD Data Collector
Sets in Win2008 and beyond.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Issues when AD replication and
Netlogon RPCs request backlog values
are exceeded
Article • 02/19/2024

This article describes how to configure Active Directory (AD) replication and Netlogon
remote procedure calls (RPCs) request backlog values in Windows Server.

You encounter one of the following issues:

Transmission Control Protocol (TCP) resets occur frequently, but a network trace
analysis doesn't provide the root cause.
Microsoft Exchange servers receive 401 errors intermittently when authenticating
to domain controllers.
Exchange servers fail to connect to domain controllers and report "The server is
unavailable."
Microsoft Outlook repeatedly prompts for user credentials when authenticating to
a domain controller.
You receive this error message when you sign in:

"The trust relationship between this workstation and the primary domain
failed."

You might also see the following events in Windows Server:

Event ID 3210

Output

Event Log: System

Event Type: Error
Event Source: Netlogon
Event ID: 3210
Event Text:
This computer could not authenticate with [file://%3cDomain]\\<Domain
Controller Name>.<Domain Name>, a Windows domain controller for domain
<Domain Name>, and therefore this computer might deny logon requests.

This inability to authenticate might be caused by another computer on

the same network using the same name or the password for this computer
account is not recognized. If this message appears again, contact your
system administrator.
 Event ID 5719

Output

Event Log: System

Event Type: Error
Event Source: Netlogon
Event ID: 5719
Event Text:
This computer was not able to set up a secure session with a domain
controller in domain <Domain Name> due to the following:

The remote procedure call failed and did not execute.

This may lead to authentication problems. Make sure that this computer
is connected to the network. If the problem persists, please contact
your domain administrator.

Event ID 7

Output

Event Log: System

Event Type: Error
Event Source: Microsoft-Windows-Security-Kerberos
Event ID: 7
Event Text:
The digitally signed Privilege Attribute Certificate (PAC) that
contains the authorization information for client <Hostname>$ in realm
<Domain Name> could not be validated.

Events after installing Windows preview

updates June 2022
Windows Server 2019 June 23, 2022—KB5014669 (OS Build 17763.3113) Preview
update and Windows Server 2022 June 23, 2022—KB5014665 (OS Build 20348.803)
Preview update report the problem and adjust settings for the RPC request backlog.
After installing these updates, you might receive the following events.

The Netlogon service starts successfully with the given RPC backlog size.

Output

Event Log: System

Event Type: Info
Event Source: Netlogon
Event ID: 5836
 Event Text:
The Netlogon service was able to bind to a TCP/IP port with the
configured backlog size of <Configured Backlog Size>

The Netlogon service related backlog size failure.

Output

Event Log: System

Event Type: Warning
Event Source: Netlogon
Event ID: 5837
Event Text:
The Netlogon service tried to bind to a TCP/IP port with the configured
backlog size of <Configured RPC Backlog Size> but failed.

More information can be found in the following log file

'%SystemRoot%\debug\netlogon.log' and, potentially, in the log file
'%SystemRoot%\debug\netlogon.bak' created if the former log becomes
full. For steps in enabling the log, please visit
https://go.microsoft.com/fwlink/?linkid=2163327.

Active Directory replication related backlog limit failure.

Output

Event Log: Active Directory Domain Services

Event Type: Warning
Event Source: ActiveDirectory_DomainService
Event ID: 3042
Event Text:
Active Directory Domain Services could not configure the TCP port with
the backlog limit as specified in registry.

Additional Data

TCP Port:

<Configured Port>

Configured backlog limit:

<Backlog Limit Configured on Port>

Registry backlog limit:

<Backlog Limit Specified in Registry>

User Action:

Make sure the same TCP port is not being used by other services such as
 Netlogon and the Active Directory Domain Controller has been rebooted
after configuring the backlog limit value in registry.

Backlog limit value is exceeded

The Transmission Control Protocol/Internet Protocol (TCP/IP) ports registered for AD
replication and RPCs for the Netlogon service are configured with a backlog limit value.
The default value is 10. This value represents the maximum number of requests that can
be queued on the registered TCP/IP port. When the backlog limit value is exceeded, the
TCP SYN packets are immediately reset by the RPC layer on the server. This behavior will
affect authentication on the systems.

Increase RPC backlog limit value for DRSUAPI

and Netlogon

） Important

This section contains instructions to modify the registry. Serious problems might
occur if the registry is modified incorrectly. As a precaution, back up the registry
before you modify it. For more information about how to back up, restore, and
modify the registry, see How to back up and restore the registry in Windows .

You can use Registry Editor to increase the RPC backlog limit values for DRSUAPI and
the Netlogon service as follows:

７ Note

We recommend that administrators configure proper values in the registry keys.

Large values on your Windows servers can cause large amounts of non-paged pool
memory usage. Administrators should balance memory footprint versus scalability
requirements.

Registry key for DRSUAPI

Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Registry value: TCP/IP Backlog Limit

Value type: REG_DWORD
Value data: Any value between 10 and 100
 Restart the system for the setting to take effect.

Registry key for Netlogon

Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Registry value: DcTcpipBacklogLimit

Value type: REG_DWORD
Value data: Any value between 10 and 100

Restart the Netlogon service for the setting to take effect. You may also need to
restart the domain controller.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

LDAP and Kerberos Server may not
respond to UDP requests or reset TCP
sessions immediately after creation
Article • 02/19/2024

This article provides a solution to an issue where Transmission Control Protocol (TCP)
sessions created to the server ports 88, 464, 389 and 3268 are reset. Sessions using
Secure Sockets Layer (SSL) or Transport Layer Security (TLS) on ports 636 and 3269 are
also affected.

You may also notice requests on User Datagram Protocol (UDP) ports 88 and 464 don't
get a response.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
Original KB number: 2000061

You're running the Windows Server roles Active Directory Domain Services (AD DS) or
Active Directory Lightweight Directory Services (AD LDS). Sporadically, you experience a
situation where TCP sessions created to the server ports 88, 464, 389 and 3268 are reset.
Sessions using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) on ports 636
and 3269 are also affected.

In a trace of the network traffic, you can see the frame with the TCP RESET (or RST) is
sent by the server almost immediately after the session is established using the TCP
three-way handshake. The client might be able to send some request data before the
RESET is sent, but this request isn't responded to nor is the data acknowledged.

In the case of UDP, you can see requests on ports 88 and 464 don't get a response.

Incorrect idle session monitoring

The library that manages the TCP sessions for the LDAP Server and the Kerberos Key
Distribution Center (KDC) uses a scavenging thread to monitor sessions that are inactive,
and disconnects these sessions if they're idle for too long. The scavenging thread runs
every 30 seconds to clean out these sessions.

The KDC registry entry NewConnectionTimeout controls the idle time, using a default of
10 seconds. However, based on the implementation of the scavenging, the effective
interval is 0-30 seconds. Therefore newly created sessions may be disconnected
immediately by the server sporadically.

Reset NewConnectionTimeout
For the KDC ports, many clients, including the Windows Kerberos client, will perform a
retry and then get a full timer tick to work on the session. LDAP applications have a
higher chance of considering the connection reset a fatal failure.

When you set NewConnectionTimeout to 40 or higher, you receive a time-out window of

30-90 seconds. When you use 70 or higher, you receive 60-120 seconds for the time-
out. For more information about the NewConnectionTimeout registry value, see Kerberos
protocol registry entries and KDC configuration keys in Windows.

KDC might not respond to certain UDP

Kerberos authentication requests
You're running the Windows Server role AD DS. The client sends a Kerberos
authentication or password change request from source port 22528/UDP or 53249/UDP,
but the KDC might not respond.

７ Note

The Microsoft Kerberos client uses TCP Kerberos authentication by default since
Windows Vista. Therefore, this issue likely occurs only with third-party products
that use UDP for Kerberos requests.

The KDC has a built-in protection against request loops and blocks Kerberos
authentication requests on source ports 88/UDP and 464/UDP. However, the
implementation has a bug in byte ordering, so source ports 22528/UDP and 53249/UDP
are blocked.

You have to exclude 22528/UDP and 53249/UDP from the ephemeral port range of UDP
on the client.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Domain Controller delayed response to
LDAP or Kerberos requests
Article • 02/19/2024

This article provides help to solve performance issues (such as logon delays and Outlook
hangs) that occur after you upgrade your Domain Controllers (DCs).

Applies to: Windows Server 2012 R2

Original KB number: 2668820

Symptoms
After upgrading your DCs, you may be affected by this issue. Possible symptoms are
logon delays, Outlook, and other application hangs, increasing Exchange queue.

A more obvious indicator is Event Warning Netlogon 5807 on the slow responding DC
with a high number of clients, like the following:

Event Type: Warning

Event Source: NETLOGON
Event Category: None
Event ID: 5807
User: N/A
Computer: <MyW2k8R2DC1>

Description: During the past 4.23 hours, there have been 123450 connections to this
Domain Controller from client machines whose IP addresses don't map to any of the
existing sites in the enterprise. Those clients, therefore, have undefined sites and
may connect to any Domain Controller including those that are in far distant
locations from the clients. A client's site is determined by the mapping of its subnet
to one of the existing sites. To move the above clients to one of the sites, consider
creating subnet object(s) covering the above IP addresses with mapping to one of
the existing sites. The names and IP addresses of the clients in question have been
logged on this computer in the following log file
'%SystemRoot%\debug\netlogon.log' and, potentially, in the log file
'%SystemRoot%\debug\netlogon.bak' created if the former log becomes full. The
log(s) may contain additional unrelated debugging information. To filter out the
needed information, search for lines that contain text'NO_CLIENT_SITE:'. The first
word after this string is the client name and the second word is the client IP address.
The maximum size of the log(s) is controlled by the following registry DWORD value
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFil
eMaxSize ; the default is 20000000 bytes. The current maximum size is 20,000,000

bytes. To set a different maximum size, create the above registry value and set the
desired maximum size in bytes.

Cause
For site-unmapped Client IPs, a DC performs name resolution, because since Vista and
the introduction of IPv6 a client may have multiple IPs. The IP address the client uses
during the LDAP UDP Netlogon ping to contact the DC may not be the only one
available. If the DC has no subnet configured for this IP, it tries finding a different one
having a mapping and would return the according Sitename to the client.

Depending on the Name Resolution mechanism configured on the DC this name

resolution may take some seconds. During this time, the LDAP Ping request holds an
ATQ Thread from a limited ATQ pool. A high number of such site-unmapped LDAP Pings
may saturate this Pool. Since other LDAP and Kerberos request also need this pool, they
may be affected as well.

The typical setup when stepping into this issue is a Client- with a trusting Resource
Forest, where the Client IP Segments have no Subnet/Site match in the Resource Forest.
The Resource Forest DCs may log Event Warning Netlogon 5807 with a high number of
clients.

Resolution
There was an update released that allows turning off this DNS lookup:

2922852 Update resolves a problem in which LDAP, Kerberos, and DC locator

responses are slow or time out with Windows

You may apply the workaround:

create matching subnet/sites, avoid Netlogon 5807 with a high number of

unmapped connections

increase MaxPoolThreads to 10 (counts per core) Ref. 315071 How to view and set
LDAP policy in Active Directory by using Ntdsutil.exe

optimize DC Name resolution, disable Netbios or use P-Node when WINS is

required Ref. Chapter 11 - NetBIOS over TCP/IP - Microsoft TechNet: Resources
More information
ATQ (Active Thread Queue) Performance Counter monitoring: "Monitoring Your Branch
Office Environment", https://technet.microsoft.com/library/dd736504(WS.10).aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Event1644Reader.ps1 to analyze LDAP
query performance in Windows Server
Article • 02/19/2024

This article describes a script that helps analyze Active Directory event ID 1644 in Windows Server.
Review the steps to use the script and then analyze your problems.

Applies to: Windows Server 2012 R2

Original KB number: 3060643

About the Event1644Reader.ps1 script

Active Directory event ID 1644 is logged in the Directory Service event log. This event identifies
expensive, inefficient, or slow Lightweight Directory Access Protocol (LDAP) searches that are
serviced by Active Directory domain controllers. NTDS General event ID 1644 can be filtered to
record LDAP searches in the Directory Services event log based on the number of objects in the
Active Directory database that were visited, the number of objects that were returned, or the LDAP
search execution time on the domain controller. For more information about event ID 1644, see
Hotfix 2800945 adds performance data to Active Directory event log .

Event1644Reader.ps1 is a Windows PowerShell script that extracts data from 1644 events that are
hosted in saved Directory Service event logs. Then, it imports that data into a series of pivot tables
in a Microsoft Excel spreadsheet to help administrators gain insights about the LDAP workloads
that are being serviced by the domain controllers and clients that are generating those queries.

How to obtain the script

You can obtain the script from the Core Infrastructure and Security Blog post How to find
expensive, inefficient and long running LDAP queries in Active Directory .

７ Note

The script is attached on the blog post with file name Event1644Reader.zip

Script Center disclaimer

The sample scripts are not supported under any Microsoft standard support program or service.
The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all
implied warranties including, without limitation, any implied warranties of merchantability or of
fitness for a particular purpose. The entire risk arising out of the use or performance of the sample
scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone
else involved in the creation, production, or delivery of the scripts be liable for any damages
whatsoever (including, without limitation, damages for loss of business profits, business
interruption, loss of business information, or other pecuniary loss) arising out of the use of or
inability to use the sample scripts or documentation, even if Microsoft has been advised of the
possibility of such damages.

Online peer support

For online peer support, join The Official Scripting Guys Forum! To provide feedback or report
bugs in sample scripts, start a new discussion on the Discussions tab for this script.

How to use the script

To better analyze the LDAP queries that are captured in event ID 1644, follow these steps:

1. Make sure that the domain controllers that you are troubleshooting capture enhanced **
1644 event metadata.

７ Note

Windows Server 2012 R2 added enhanced 1644 event logging by recording the
duration of LDAP queries and other metadata. The enhanced 1644 event logging was
backported to Windows Server 2012, Windows Server 2008 R2, and Windows Server
2008 by hotfix 2800945 .

2. Set the value of the following Field Engineering registry entry to 5:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering

７ Note

Setting field engineering log verbosity to 5 will cause other events to be logged in the
directory service event log. Reset field engineering back to its default value of 0 when
you are not actively collecting 1644 events. (This action does not require a restart.)

3. If the following registry entries exist, change the values to the desired threshold in
milliseconds. If a particular registry entry does not exist, create a new entry with that name,
and then set its value to the desired threshold in milliseconds.

ﾉ Expand table

Registry path Data Default

type value

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search DWORD 30,000

Time Threshold (msecs)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive DWORD 10,000

Search Results Threshold

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient DWORD 1,000

Search Results Threshold
 ７ Note

When the Field Engineering logging level is enabled and the Search Time
Threshold (msecs) registry entry is not used or is set to 0, the default value of the
time threshold is 30,000 milliseconds. (This action does not require a restart.)
One strategy would be to set the registry value for both the Inefficient Search
Results Threshold and Expensive Search Results Threshold registry settings, and
then focus on events that are identified by Search Time hold (msecs). Start with a
larger value like 100 milliseconds and then incrementally decrease the value as you
optimize the queries that are occurring in your environment.
Event1644Reader.ps1 can parse events from multiple domain controllers.
Configure the field engineering, search time, expensive, and inefficient registry key
settings on all domain controllers on which you want to review LDAP searches.

4. Download the Event1644Reader.ps1 file from You can obtain the script from the Core
Infrastructure and Security Blog post How to find expensive, inefficient and long running
LDAP queries in Active Directory to the computer that will analyze saved Active Directory
Service EVTX files that contain 1644 events.

This computer should have Microsoft Excel 2010 or a later version installed and should have
sufficient disk space to host the directory service event logs that the script will parse.

5. Copy saved Directory Service event logs that contain 1644 events from the domain
controllers where you enabled 1644 event logging to the 1644 analysis computer.

6. In Windows Explorer, right-click the Event1644Reader.ps1 file, and then select Run with
PowerShell.

The following is the screenshot for this step:

7. Press Y to bypass PowerShell Execution Policy as required.

8. Specify the path of the EVTX files to be parsed.

9. When you see the prompt as the following screenshot, take the following actions:
 Press Enter to parse all EVTX files that are located in the same directory as the
Enent1644Reader.ps1 file.
Type the drive:\path path that contains the EVTX files to be parsed.

７ Note

Event1644Reader.ps1 parses 1644 events in all up-level directory service event logs that
are located in the targeted path every time that the script runs.

10. Open the worksheet to review data and walk through the series of tabs, and then save the
Excel spreadsheet as required. For more information about the tabs in the worksheet, see the
Walkthrough of the Excel spreadsheet created by 1644Reder.ps1 section.

７ Note

*.csv files that are built by the tool are not automatically removed. Consider purging
*.csv files after your investigation is complete.

More information

Walkthrough of the Excel spreadsheet that is created by

Event1644Reader.ps1
Event1644Reader.ps1 extracts metadata from 1644 events in saved Directory Service event logs
and imports that data into a series of tabbed worksheets in a Microsoft Excel spreadsheet.

The following table summarizes the data that is contained in each tab:

ﾉ Expand table

Tab Description

RawData Each data field that is captured by event ID 1644 is imported into discrete columns.
Data Filtering is auto-enabled so that you can sort or filter on any column header. If
1644 event logs from multiple domain controllers resided in the same directory as the
PowerShell script or the admin-specified directory, use filters to view LDAP queries that
are targeting specific domain controllers.

Top_StartingNode Provides a sorted list of the directory partitions that are targeted by LDAP queries in a
given sample. If most of the queries are occurring in a single partition (schema,
configuration, or domain), consider adding that partition as a filter in the remaining
 Tab Description

pivot tables. Drillthrough detail exposes the top filters (such as the LDAP query), the
client IPs that issued those queries, and the date and time stamps for those queries.

Top_Callers Lists client IP addresses that issued LDAP queries in descending search count order
with percentage of grand total. Percentage of running total helps you identify top
callers. (That is, the top 10 or 20 callers may be generating 80 percent of the query
volume, assuming that too many calls are your problem). Drillthrough detail exposes
filters and date and time steps that each client-issued LDAP queries in a given sample.

Top_Filters Lists most frequently issued LDAP queries in descending volume order. This includes
average search time. Drillthrough detail exposes the LDAP client's IP address and the
date and time when each query was submitted.

TotalSearchTime by Lists client IP addresses in descending order of total search time across all LDAP
Callers queries in the sample. Drillthrough detail identifies the LDAP queries and the date and
time when each query was issued.

TotalSearchTime by Lists LDAP queries in descending order of total search time. Drillthrough detail exposes
Filters the LDAP client's IP address and the date and time when each matching query was
submitted.

Search time ranks Displays the number of LDAP queries that occurred in time-based quartiles. Slower
queries are bad. Faster queries are good if they aren't issued too often. Microsoft
Exchange wants LDAP queries that are issued by Exchange servers to be resolved in 50
milliseconds or less. So, the first quartile group focuses on that time "bucket."

Blank Pivot This is a blank pivot table that you can change as required to show the specific data
for your scenario.

Scenario analysis
If LDAP queries are slow, or if CPU usage is high on domain controllers, this may be caused by
excessively issued queries, inefficient queries, some combination of these queries, Asynchronous
Thread Queue (ATQ) pool exhaustion, or lots of change notifications.

If clients issue expensive, inefficient, or lots of LDAP queries, use Event1644Reader.ps1 to collect
data on the domain controllers to identify the IP addresses of the clients. Then, map such queries
to the process ID, the process name, or the calling application on the client computers.

The following table lists the possible optimizations for this issue.

ﾉ Expand table

Optimization/mitigation Synopsis

Stop the excessive workload. If lots or LDAP queries cause service stops, focus on top calling
clients, and work to identify and eliminate the source of the
excessive workload.

Possible options to identify applications include using PROCMON,

ETL/ETW tracing, and debug analysis to identify the application
 Optimization/mitigation Synopsis

that generates LDAP queries on the client. Another strategy is to

use a divide-by-two approach of either topping services or
removing applications that are generating LDAP queries. The
issued queries may implicate the calling application or process.

Install an updated LDAP query Windows Server 2012 R2 contains an updated LDAP query
optimizer. optimizer that improves performance for most queries. Subsets of
the Windows Server 2012 R2 are backported to Windows Server
2008 R2 and Windows Server 2012 in hotfix 2862304 .

Make sure that clients are submitting Sending LDAP queries across the WAN introduces network latency
queries to site-optimal domain into the delivery of the LDAP query to the domain controller and its
controllers. reply to the client. Make sure that Active Directory sites and subnet
definitions exist for client and server computers in Active Directory.

Make sure that applications do not have hard-coded references to

remote-site domain controllers or to read-writable domain
controllers only when site-optimal domain controllers exist.

Work with software developers to Even efficiently issued queries can beat down an appropriately
reduce the frequency at which queries sized and configured domain controller if queries are issued too
are issued. This includes the use of often.
caching. Applications may have to throttle their query volume or cache
query results to reduce network, LDAP, and CPU load.

Optimize the LDAP query to execute Query syntax may have to be restructured to execute more quickly.
more quickly. Moving query elements to the left or right within the filter can
improve performance.
Adding a double "not" may improve query performance.
Consider reducing the number of objects that are visited by
starting queries lower in the tree.
Reduce the number of attributes that are being returned by
queries.

Add indexes to Active Directory Adding indexes can improve query performance. This has the side
attributes as required. effect of increasing database size and may temporarily delay Active
Directory replication during index build.

Determine whether a code defect exists Defects in the LDAP query optimizer and other components can
in the query optimizer and other reduce throughput.
components.

Known issue
The values in the Excel spreadsheet are not displayed or rendered appropriately on computers
that use non-English languages.

For example, this occurs on a computer when the Get-Culture Windows PowerShell cmdlet
indicates the regional setting as follows:

PowerShell
 PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-Culture
LCID Name DisplayName
---- ---- -----------
1031 de-DE German (Germany)

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-UICulture

LCID Name DisplayName

---- ---- -----------
1033 en-US English (United States)

In this situation, numbers in the Excel spreadsheet are rendered as in the following screenshot:

To resolve this issue, change the Decimal symbol to a period (.) in the Region settings item in
Control Panel.

For more information about LDAP queries, see the following blog: How to find expensive,
inefficient, and long running LDAP queries in Active Directory

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory installation stalls at the
Creating the NTDS settings object stage
Article • 02/19/2024

This article provides a solution to an issue where Active Directory installation fails with
an error: Creating the NTDS Settings object for this Active Directory Domain Controller
on the remote AD DC.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Original KB number: 2737935

Symptoms
After you start Active Directory installation in Windows Server by using Server Manager
or the AddsDeployment Windows PowerShell module, the installation stalls at the stage at
which you receive the following message:

Creating the NTDS Settings object for this Active Directory Domain Controller on
the remote AD DC dc1-full.corp.contoso.com

Regardless of how long you wait, the installation never proceeds beyond this point.
Additionally, when you examine the Directory Services event logs, you see the following
repeated events:

Event 1

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 1963
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: dc2-full
Description:
Internal event: The following local directory service received an exception from
a remote procedure call (RPC) connection. Extensive RPC information was
 requested. This is intermediate information and might not contain a possible
cause.

Process ID: 556 Reported error information:

Error value:
Could not find the domain controller for this domain. (1908)
directory service:
dc1-full.corp.contoso.com

Extensive error information:

Error value:
A security package specific error occurred. 1825
directory service:
DC2-FULL

Additional Data Internal ID: 5000dfc

Event 2

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 1962
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: dc2-full
Description:
Internal event: The local directory service received an exception from a remote
procedure call (RPC) connection. Extended error information is not available.

directory service:
dc1-full.corp.contoso.com

Additional Data
Error value:
Could not find the domain controller for this domain. (1908)

Event 3

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
 Date: <DateTime>
Event ID: 1125
Task Category: Setup
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: dc2-full
Description:
The Active Directory Domain Services Installation Wizard (Dcpromo) was
unable to establish connection with the following domain controller.

Domain controller:
dc1-full.corp.contoso.com

Additional Data
Error value:
1908 Could not find the domain controller for this domain.

Cause
This issue occurs for one or more of the following reasons:

The server's built-in Administrator account has the same password as the built-in
domain Administrator account.
The NetBIOS domain prefix or UPN was not provided as credentials for installation.
Instead, only the user name Administrator was provided.

Resolution
To resolve this issue, follow these steps:

1. Restart the server on which Active Directory could not be installed.

2. Use Dsa.msc or Dsac.exe on an existing domain controller to delete the failed
server's computer account. (The domain controller will not yet be a domain
controller object but only a member server.) Then, let Active Directory replication
converge.
3. On the failed server, forcibly remove the server from the domain by using the
System Properties Control Panel item or netdom.exe.
4. On the failed server, remove the Active Directory Domain Services (AD DS) role by
using Server Manager or Uninstall-WindowsFeature .
5. Restart the failed server.
 6. Install the AD DS role, and then try the promotion again. When you do this, make
sure that you provide promotion credentials in the form domain\user or
[email protected].

More information
This is a code defect in Windows Server 2012 and late.

If you set different passwords on the two Administrator accounts but do not provide the
domain, you receive a bad password error.

We do not recommend that you use the built-in Administrator for domain
administration. Instead, we recommend that you create a new domain user for each
administrator in the environment. Then, the actions of administrators can be audited
individually.

We strongly discourage you from using matching Administrator passwords on member

servers and the domain Administrator account. Local passwords are more easily
compromised than AD DS accounts, and knowledge of the matching Administrator
passwords grants full enterprise administrative access.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot connect to the Internet, and
you cannot join or log on to the domain
if Windows Server 2003 SP1 is installed
on the authenticating domain controller
Article • 02/19/2024

This article provides a solution to an issue where clients cannot join or log on to the
domain.

Applies to: Windows Server 2003

Original KB number: 912023

Symptoms
Consider the following scenario. A Microsoft Windows XP-based client computer is
joined to a Microsoft Windows Server 2003 domain. Additionally, Windows Server 2003
Service Pack 1 (SP1) is installed on the authenticating domain controller. In this scenario,
you experience the following symptoms:

You cannot connect to the Internet.

You cannot join or log on to the domain. Therefore, the domain controller is in
IPsec Block mode.

When you start the IPSEC Services component on the domain controller, you may
receive an error message that is similar to the following:

The system cannot find the file specified.

Additionally, the following events may be logged in the server's System log:

Event Type: Error

Event Source: IPSEC
Event Category: None
Event ID: 4292
Date: <DateTime>
Time: <DateTime>
User: N/A
Computer: <ComputerName>
 Description:
The IPSec driver has entered Block mode. IPSec will discard all inbound and
outbound TCP/IP network traffic that is not permitted by boot-time IPSec Policy
exemptions.

Event Type: Error

Event Source: Service Control Manager
Event Category: None
Event ID: 7023
Date: <DateTime>
Time: <DateTime>
User: N/A
Computer: <ComputerName>
Description:
The IPSEC Services service terminated with the following error: The system cannot
find the file specified

Cause
This problem can occur if the IPSec\Policy\Local registry key is deleted or when there is
a corrupted file in the policy store. The file may become corrupted if an interruption
occurs when the policy is being written to the disk.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To resolve this issue, follow these steps:

1. Delete the local policy registry subkey. To do this, follow these steps:

a. Click Start, click Run, type regedit in the Open box, and then click OK.
 b. In Registry Editor, locate and then click the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local

c. On the Edit menu, click Delete.

d. Click Yes to confirm that you want to delete the subkey.

e. Quit Registry Editor.

2. Rebuild a new local policy store. To do this, Click Start, click Run, type regsvr32
polstore.dll in the Open box, and then click OK.

3. Verify that the IPSEC Services component is set to automatic, and then restart the
domain controller.

Workaround
To temporarily work around this problem, disable the IPSEC Services component, and
then restart the domain controller.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Default limit to number of workstations
a user can join to the domain
Article • 02/19/2024

This article describes how to the change the AD to allow more or fewer machine
accounts in the domain.

Applies to: Windows Server 2012 R2

Original KB number: 243327

Summary
By default, Windows 2000 allows authenticated users to join 10 machine accounts to the
domain.

This default was implemented to prevent misuse. But an administrator can make a
change to an object in Active Directory to override it.

The following users aren't restricted by this limitation:

Users in the Administrators or Domain Administrators groups.

Users who have delegated permissions on containers in Active Directory to create
and delete computer accounts.

More information
To calculate the number of workstations currently owned by a user, check the ms-DS-
CreatorSID attribute of machine accounts.

To modify Active Directory to allow more (or fewer) machine accounts on the domain,
use the Adsiedit tool.

２ Warning

Using Adsiedit incorrectly can cause serious problems that may require you to
reinstall your operating system. Microsoft cannot guarantee that problems
resulting from the incorrect use of Adsiedit can be solved. Use Adsiedit at your own
risk.
 1. Install the Windows Support tools if they haven't already been installed. It's
necessary only for Windows 2000 and Windows Server 2003. For Windows Server
2008 and Windows Server 2008 R2, Adsiedit is installed automatically when you
install the Active Directory Domain Services role.
2. Run Adsiedit.msc as an administrator of the domain. Expand the Domain NC node.
This node contains an object that begins with "DC=" and reflects the correct
domain name. Right-click this object, and then select Properties.
3. In the Select which properties to view box, select Both. In the Select a property to
view box, select ms-DS-MachineAccountQuota.
4. In the Edit Attribute box, type the number of workstations that you want users to
be able to maintain concurrently.
5. Select Set > OK.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How domain controllers are located in
Windows
Article • 02/19/2024

This article describes the mechanism used by Windows to locate a domain controller in
a Windows-based domain.

７ Note

This article applies to Windows 2000. Support for Windows 2000 ends on July 13,
2010. The Windows 2000 End-of-Support Solution Center is a starting point for
planning your migration strategy from Windows 2000. For more information, see
the Microsoft Support Lifecycle Policy.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 247811

Summary
This article details the process of locating a domain by its DNS-style name and its flat-
style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other
cases, DNS-style names should be used as a matter of policy. This article also addresses
troubleshooting the domain controller location process.

How the Locator finds a domain controller

This sequence describes how the Locator finds a domain controller:

On the client (the computer that's locating the domain controller), the Locator is
started as a remote procedure call (RPC) to the local Netlogon service. The Locator
DsGetDcName application programming interface (API) call is implemented by the
Netlogon service.

The client collects the information that's needed to select a domain controller.
Then it passes the information to the Netlogon service by using the DsGetDcName
call.

The Netlogon service on the client uses the collected information to look up a
domain controller for the specified domain in one of two ways:
 For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible
Locator. That is, DsGetDcName calls the DnsQuery call to read the Service
Resource (SRV) records and "A" records from DNS after it appends the domain
name to the appropriate string that specifies the SRV records.

A workstation that's logging on to a Windows-based domain queries DNS for

SRV records in the general form:

Output

_service._protocol.DnsDomainName

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP)
service over the TCP protocol. So clients find an LDAP server by querying DNS
for a record of the form:

_ldap._tcp.DnsDomainName

For a NetBIOS name, Netlogon performs domain controller discovery by using the
Microsoft Windows NT version 4.0-compatible Locator. That is, by using the
transport-specific mechanism, such as WINS.

In Windows NT 4.0 and earlier, "discovery" is a process to locate a domain

controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the
name. For NetBIOS domain names, the datagram is implemented as a mailslot
message. For DNS domain names, the datagram is implemented as an LDAP User
Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport
protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented
transport protocol.)

Each available domain controller responds to the datagram to indicate that it's
currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another

computer. UDP includes a protocol port number, which allows the sender to distinguish
among multiple destinations (programs) on the remote computer.

Each available domain controller responds to the datagram to indicate that it's
currently operational and returns the information to DsGetDcName.
The Netlogon service caches the domain controller information so that later
requests need not repeat the discovery process. Caching this information
 encourages consistent use of the same domain controller and a consistent view of
Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller.
The client sends a DNS Lookup query to DNS to find domain controllers, preferably in
the client's own subnet. So clients find a domain controller by querying DNS for a record
of the form:

Output

_LDAP._TCP.dc._msdcs.domainname

After the client locates a domain controller, it establishes communication by using LDAP
to gain access to Active Directory. As part of that negotiation, the domain controller
identifies which site the client is in based on the IP subnet of that client.

If the client is communicating with a domain controller that isn't in the closest (most
optimal) site, the domain controller returns the name of the client's site. If the client has
already tried to find domain controllers in that site, the client uses the domain controller
that isn't optimal. For example, the client sends a DNS Lookup query to DNS to find
domain controllers in the client's subnet.

Otherwise, the client does a site-specific DNS lookup again with the new optimal site
name. The domain controller uses some of the directory service information for
identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the
domain controller isn't in the optimal site, the client flushes the cache after 15 minutes
and discards the cache entry. It then attempts to find an optimal domain controller in
the same site as the client.

After the client has established a communications path to the domain controller, it can
establish the logon and authentication credentials. And if necessary for Windows-based
computers, it can set up a secure channel. The client then is ready to perform normal
queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon
process uses Security Accounts Manager. The communications path uses the LDAP
interface and the client is authenticated by a domain controller. So the client account is
verified and passed through Security Accounts Manager to the directory service agent,
then to the database layer, and finally to the database in the Extensible Storage engine
(ESE).
Troubleshooting the domain locator process
To troubleshoot the domain locator process:

1. Check Event Viewer on both the client and the server. The event logs may contain
error messages indicating that there's a problem. To view Event Viewer, select
Start, point to Programs > Administrative Tools, and then select Event Viewer.
Check the System log on both the client and the server. Also check the Directory
Service logs on the server and DNS logs on the DNS server.

2. Check the IP configuration by using the ipconfig /all command at a command

prompt.

3. Use the Ping utility to verify network connectivity and name resolution. Ping both
the IP address and the server name. You may also want to ping the domain name.

4. Use the Netdiag tool to determine whether networking components are working
correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt

Review the log file, looking for problems, and investigate any implicated
components. This file also contains other network configuration details.

5. To fix minor problems, use the Netdiag tool with the following syntax:

netdiag /fix .

6. Use the nltest /dsgetdc:domainname command to verify that a domain controller

can be located for a specific domain.

7. Use the NSLookup tool to verify that DNS entries are correctly registered in DNS.
Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:

nslookup servername. childofrootdomain. rootdomain.com

nslookup guid._msdcs. rootdomain.com

8. If either of these commands doesn't succeed, use one of the following methods to
reregister records with DNS:

To force host record registration, type ipconfig /registerdns.

To force domain controller service registration, stop and start the Netlogon
service.
 9. To detect domain controller problems, run the DCdiag utility from a command
prompt. The utility runs many tests to verify that a domain controller is running
correctly. Use this command to send the results to a text file: dcdiag /v
>dcdiag.txt

10. Use the Ldp.exe tool to connect and bind to the domain controller to verify
appropriate LDAP connectivity.

11. If you suspect that a particular domain controller has problems, it may be helpful
to turn on Netlogon debug logging. Use the NLTest utility by typing this command:
nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in

the Netlogon.log file.

12. If you still haven't isolated the problem, use Network Monitor to monitor network
traffic between the client and the domain controller.

References
For more information, see the Windows Resource Kit, Chapter 10, "Active Directory
Diagnostic, Troubleshooting, and Recovery."

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Netlogon service doesn't keep settings
after an in-place upgrade to Windows
Server 2016 or Windows Server 2019
Article • 02/19/2024

This article provides a resolution for an issue that prevents the Netlogon service on
domain controllers from starting automatically after you upgrade to Windows Server
2016 or Windows Server 2019.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 3201247

Symptoms
Assume that you have one or more computers that are running Windows Server 2012 or
Windows Server 2012 R2 and configured as domain controllers or member servers in an
Active Directory domain. You decide to do an in-place upgrade on the domain
controllers to Windows Server 2016 or Windows Server 2019.

After you upgrade the domain controllers, you notice that one or more of the following
symptoms occur:

User logon failures

SID to name translation fails in object picker UIs
RDP connection failures
DNS SRV resource record registration failures
The firewall profile on member servers and workstations fails to select the domain
profile

Additionally, you may receive the following event in the System log:

Log Name: System

Source: Microsoft-Windows-Time-Service
Date: date time
Event ID: 46
Task Category: None
Level: Error
Keywords:
User: LOCAL SERVICE
 Computer: computer_name
Description:
The time service encountered an error and was forced to shut down. The error was:
0x80070700: An attempt was made to logon, but the network logon service was not
started.

Cause
This issue occurs because the in-place upgrade process doesn't set the startup value for
the Netlogon service type to Automatic on the upgraded server. When the Netlogon
service isn't running, a domain controller doesn't advertise itself as a domain controller,
and all the other functionality and dependencies of the Netlogon service fail. Any service
that depends on Netlogon to be running also fails.

Resolution
This issue can be avoided by letting the setup process install the latest updates during
the in-place upgrade.

If the issue already occurs, to resolve this problem, change the Netlogon service Startup
type to Automatic. To do this, follow these steps:

1. Click Start, type services.msc in the Start Search box, and then click Services
Desktop app.
2. Locate and double-click Netlogon, and then click Automatic in the Startup type
box.
3. Click OK, and then start the Netlogon service.

Although this action doesn't require a restart, we recommend that you restart the
computer to make sure that all services that depend on Netlogon are started and
correctly registered on the Network.

References
Windows Time Service settings aren't preserved during an in-place upgrade to Windows
Server 2016 or Windows 10 Version 1607

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of support boundaries for
Active Directory over NAT
Article • 02/19/2024

This article describes the support boundaries for Active Directory over NAT.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 978772

Summary
Network Address Translation (NAT) is a selection of network techniques that alter the
address information of network traffic while in transit so as to remove details about the
originating network. This is most often done by network devices, and is intended to
enable the easy use of private network address schemes, and sometimes as a less than
ideal security measure.

Domain Controller (DC)-to-DC communication and Client-to-DC communication over a

NAT is a scenario that customers frequently encounter in merger and acquisition
scenarios. One required service when connecting the networks of the two companies is
the authentication, authorization and directory services offered by Active Directory.

There's no evidence to indicate that a NAT cross-forest configuration inherently breaks

DC-to-DC communications, or Client-to-DC communications. Microsoft hasn't tested
this scenario with Active Directory, and other technologies that are related with Active
Directory. Examples of other technologies include the Kerberos protocol or DFS.

Microsoft statement regarding Active Directory

over NAT
Active Directory over NAT has not been tested by Microsoft.
We do not recommend Active Directory over NAT.
Support for issues related to Active Directory over NAT will be limited and will
reach the bounds of commercially reasonable efforts quickly.

If you are tasked with configuring a network with NAT and you plan to run any Microsoft
Server solution (including Active Directory) across the NAT, please contact Microsoft
customer technical support using your preferred approach or visit Microsoft Support .
Additionally, you can contact Microsoft Consulting Sevices.
There is no explicit or implied guarantee that following any provided guidance will work
in any given scenario because it is untested. The support teams will work on issues that
arise from using the provided guidance to the limits of commercially reasonable effort.

The only configuration with NAT that was tested by Microsoft is running client on the
private side of a NAT and have all servers located on the public side of the NAT. The NAT
would also function as a DNS server.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Sync Center: Slow syncing of offline files
on some file servers
Article • 02/19/2024

This article describes an issue that slows down the progress of offline folder file sync
operations by Microsoft Sync Center.

Applies to: Windows Server 2012 R2

Original KB number: 3046857

Summary
When Microsoft Sync Center syncs offline files, the sync operation may take longer than
expected. This behavior occurs when the back-end file server enumerates unsorted
directory contents (a list in which the file names are not sorted alphabetically). This
affects Microsoft Sync Center performance when it syncs offline files with non-Microsoft
file servers.

More information
Microsoft Sync Center compares the local system's directory list against a list of files that
it receives from the remote file server. Sync Center does this by making query directory
calls against the remote file server through the Server Message Block protocol (CIFS,
SMB, SMB2, and SMB3). Microsoft file servers always return query directory results in
alphabetical order, sorted by file name. (The underlying NTFS file system maintains
sorted lists.)

Many underlying file systems do not maintain sorted lists. This includes the file systems
that are used by most third-party SMB protocol implementers and Microsoft file systems
such as FAT32. Therefore, most third-party file servers exhibit performance delays when
they sync offline files by using Sync Center.

７ Note

The SMB protocol does not require query directory results to be sorted.

Just how significantly performance is affected depends on several factors, including the
number of files, the length of the file names (both properties affect the total size of the
file metadata), and how unsorted the results are. When there are lots of files (hundreds
or thousands) with large file names that are profoundly out of order, more directory
queries of the local file system and more remote directory queries on the remote file
server are required.

You can ease this problem by using smaller folders (either in terms of file count or file
name size). It also helps if you can increase the extent to which files are recorded in
sorted order on the underlying file system.

The scenario affects performance only. Offline file syncing otherwise occurs successfully
and correctly.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message: The account is not
authorized to login from this station
Article • 02/19/2024

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010.
The Windows 2000 End-of-Support Solution Center is a starting point for planning your
migration strategy from Windows 2000. For more information, see the Microsoft
Support Lifecycle Policy.

Applies to: Windows 2000

Original KB number: 281648

Symptoms
When you attempt to join a Windows 2000-based computer to a Microsoft Windows NT
4.0-based domain, you may receive the following error message:

The following error occurred attempting to join the domain "domainname": The
account is not authorized to login from this station.

Cause
This behavior can occur because the Local Group Policy, specifically those in the
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options folder have a restrictive setting.

Some of the policies that may cause this behavior are:

Digitally sign client communications (always)

Digitally sign server communications (always)
Digitally sign server communications (when possible)
LAN Manager Authentication Level set to Send LM and NTLM - use NTLMv2
session security if negotiated
Secure channel: Digitally encrypt or sign secure channel data (always)
Secure channel: Require strong (Windows 2000 or later) session key

Resolution
To work around this behavior, set the values back to what they would be if a clean install
had occurred.

Examine the preceding policies and set them back to their default settings.

The default settings of these policies are:

Digitally sign client communications (always) - disabled

Digitally sign server communications (always)- disabled
Digitally sign server communications (when possible) - disabled
LAN Manager Authentication Level set to Send LM and NTLM - use NTLMv2
session security if negotiated - (default) send LM & NTLM responses
Secure channel: Digitally encrypt or sign secure channel data (always) - disabled
Secure channel: Require strong (Windows 2000 or later) session key - disabled

Restart your computer and you should be able to join the domain.

Status
This behavior is by design.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot errors that occur
when you join Windows-based
computers to a domain
Article • 02/19/2024

This article describes several common error messages that can occur when you join
client computers that are running Windows to a domain. This article also provides
troubleshooting suggestions for these errors.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 4341920

Where to find the Netsetup.log file

Windows clients log the details of domain join operations in the
%windir%\debug\Netsetup.log file.

Networking error messages and resolutions

Error 1
An attempt to resolve the DNS name of a DC in the domain being joined has failed.
Please verify this client is configured to reach a DNS server that can resolve DNS
names in the target domain.

Resolution

When you type the domain name, make sure that you type the Domain Name System
(DNS) name and not the Network Basic Input/Output System (NetBIOS) name. For
example, if the DNS name of the target domain is contoso.com , make sure that you
enter contoso.com instead of the NetBIOS domain name of "contoso."

Additionally, verify that the computer can reach a DNS server that hosts the DNS zone
of the target domain or can resolve DNS names in that domain. Make sure that the
correct DNS server is configured on this client as the preferred DNS, and that the client
has connectivity to that server. To verify this, you can run one of the following
commands:
 Console

nltest /dsgetdc:<netbios domain name> /force

Console

nltest /dsgetdc:<DNS domain name> /force

Error 2
An attempt to resolve the DNS name of a domain controller in the domain being
joined has failed. Please verify this client is configured to reach a DNS server that
can resolve DNS names in the target Domain.

Resolution

When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name.

Additionally, verify that the computer can reach a DNS server that hosts the DNS zone
of the target domain or can resolve DNS names in that domain. Make sure that the
correct DNS server is configured on this client as the preferred DNS, and that the client
has connectivity to that server. To verify this, you can run one of the following
commands:

Console

nltest /dsgetdc:<netbios domain name> /force

Console

nltest /dsgetdc:<DNS domain name> /force

Error 3
An operation was attempted on a nonexistent network connection.

Resolution
When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name. Additionally, restart the computer before you try to join the computer to
the domain.

Error 4
Multiple connections to a server or shared resource by the same user, using more
than one user name, are not allowed. Disconnect all previous connections to the
server or shared resource and try again.

Resolution
Restart the computer that you are trying to join to the domain to make sure that there
are no latent connections to any of the domain servers.

When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name.

Error 5
Network name cannot be found.

Resolution

Verify that the computer can reach a DNS server that hosts the DNS zone of the target
domain or can resolve DNS names in that domain. Make sure that the correct DNS
server has been configured on this client as the preferred DNS, and that the client has
connectivity to that server. To verify this, you can run one of the following commands:

Console

nltest /dsgetdc:<netbios domain name> /force

Console

nltest /dsgetdc:<DNS domain name> /force

When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name.

Additionally, you can update the network adapter driver.

Error 6
No more connections can be made to this remote computer at this time because
there are already as many connections as the computer can accept.

Resolution

Before joining the computer to the domain, make sure that you have cleared all mapped
connections to any drives.

Restart the computer that you are trying to join to the domain to make sure that there
are no latent connections to any of the domain servers.

When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name.

The error may be transient. Try again later. If the issue persists, verify the status of the
DC that the client is connecting to (active connections, network connectivity, and so on).
You may want to restart the DC if the issue persists.

Error 7
The format of the specified network name is invalid.

Resolution
Verify that the computer can reach a DNS server that hosts the DNS zone of the target
domain or can resolve DNS names in that domain. Make sure that the correct DNS
server has been configured on this client as the preferred DNS, and that the client has
connectivity to that server. To verify this, you can run one of the following commands:

Console

nltest /dsgetdc:<netbios domain name> /force

Console

nltest /dsgetdc:<DNS domain name> /force

When you type the domain name, make sure that you type the DNS name and not the
NetBIOS name. Make sure that you have the most up-to-date drivers installed for the
client computer's network adapter. Verify connectivity between the client that is being
joined and the target DC over the required ports and protocols. Disable the TCP
Chimney offload feature and IP offloading.

Error 8
The directory service has exhausted the pool of relative identifiers.

Resolution
Make sure that the DC that hosts the relative ID (RID) operations master is online and
functional. For more information, see Event ID 16650: The account-identifier allocator
failed to initialize in Windows Server.

７ Note

You can use the netdom query fsmo command to determine which DC has the RID
Master role.

Verify that Active Directory is replicating between all DCs. You can use the following
command to detect any errors:

Console

repadmin /replsummary /bysrc /bydest /sort:delta

Error 9
The remote procedure call failed and did not execute.

Resolution
Make sure that you have the most up-to-date drivers installed for the client computer's
network adapter. Verify connectivity between the client that is being joined and the
target DC over the required ports and protocols. Disable the TCP Chimney offload
feature and IP offloading.

This problem can also be caused by one of the following conditions:

A network device (router, firewall, or VPN device) is blocking connectivity over the
ports and protocols that are used by the MSRPC protocol.
 A network device (router, firewall, or VPN device) is rejecting network packets
between the client that is being joined and the DC.

７ Note

The following articles contain port requirement information:

832017 Service overview and network port requirements for Windows
179442 How to configure a firewall for domains and trusts

Error 10
Changing the Primary Domain DNS name of this computer to "" failed. The name
will remain ".".The specified server cannot perform the operation.

Resolution
This error occurs when you use the domain join UI to join a Windows 7 or Windows
Server 2008 R2 workgroup computer to an Active Directory domain by specifying the
target DNS domain. To fix this error, see 2018583 Windows 7 or Windows Server 2008
R2 domain join displays error "Changing the Primary Domain DNS name of this
computer to "" failed...." .

Authentication error messages and resolutions

Error 1
You have exceeded the maximum number of computer accounts you are allowed to
create in this domain.

Resolution

Make sure that you have permissions to add computers to the domain, and that you
have not exceeded the quota that is defined by your Domain Administrator.

To join a computer to the domain, the user account must be granted Create computer
object permissions in Active Directory.

７ Note
 By default, a non-administrator user can join a maximum of 10 computers to an
Active Directory domain.

Error 2
Logon failure: The target account name is incorrect.

Resolution
Check that the domain controllers (DCs) are registered by using correct IP addresses on
the DNS server, and that their Service Principal Names (SPNs) are registered correctly in
their Active Directory accounts.

Error 3
Logon failure: the user has not been granted the requested logon type at this
computer.

Resolution

Make sure that you have permissions to add computers to the domain. To join a
computer to the domain, the user account must be granted the Create computer object
permission in Active Directory.

Additionally, make sure that the specified user account is allowed to log on locally to the
client computer. To do this, configure the Allow log on locally setting in Group Policy
under Computer Configuration > Windows Settings > Security Settings > Local
Policies > User Rights Assignment.

Error 4
Logon failure: unknown user name or bad password.

Resolution
Make sure that you use the correct user name and password combination of an existing
Active Directory user account when you are prompted for credentials to add the
computer to the domain.
Error 5
No mapping between account names and security IDs was done.

Resolution
This error is likely a transient error that is logged when a domain join searches the target
domain to determine whether a matching computer account was already created or
whether the join operation has to dynamically create a computer account on the target
domain.

Error 6
Not enough storage is available to complete this operation.

Resolution

This error can occur when the Kerberos token size is larger than the maximum default
size. If this situation, you have to increase the Kerberos token size of the computer that
you try to join to the domain. For more information, see the following Knowledge Base
articles:
935744 "Not enough storage is available to complete this operation" error message
when you use a domain controller to join a computer to a domain
327825 Problems with Kerberos authentication when a user belongs to many groups

Error 7
The account is not authorized to login from this station.

Resolution
This problem is related to mismatched SMB Signing settings between the client
computer and the DC that is being contacted for the domain join operation. Review the
following documentation to further investigate the current and recommended values in
your environment:
281648 Error message: The account is not authorized to login from this station 823659
Client, service, and program issues can occur if you change security settings and user
rights assignments

Error 8
 The account specified for this service is different from the account specified for
other services running in the same process.

Resolution

Make sure that the DC through which you are trying to join the domain has the
Windows Time service started.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
1908: Could not find the domain
controller for this domain
Article • 02/19/2024

This article provides a resolution for troubleshooting AD Replication error 1908: Could not
find the domain controller for this domain.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2712026

７ Note

Home users: This article is only intended for technical support agents and IT professionals.
If you're looking for help with a problem, please ask the Microsoft Community .

Symptoms
1. REPADMIN.exe reports that replication attempt has failed with status 1908.

REPADMIN commands that commonly cite the 1908 status include but are not limited
to:

REPADMIN /ADD

REPADMIN /REPLSUM *
REPADMIN /REHOST

REPADMIN /SHOWVECTOR /LATENCY

REPADMIN /SHOWREPS

REPADMIN /SHOWREPL

Sample output from repadmin /syncall command:

Console

Syncing all NC's held on CONTOSO-DC02.

Syncing partition: DC=ForestDnsZones,DC=Contoso,DC=com
CALLBACK MESSAGE: Error contacting server 1b136427-14f0-448a-965c-
9cbb61400fcd._msdcs.Contoso.com (network error): 1908 (0x774):
Could not find the domain controller for this domain.
 Sample output from repadmin /showreps command:

Console

DC=ForestDnsZones,DC=Contoso,DC=com
HQ\Contoso-DC02 via RPC
DC object GUID:1b136427-14f0-448a-965c-9cbb61400fcd._msdcs.Contoso.com/
Last attempt @ <DATE> <TIME> failed, result 1908 (0x774):
Could not find the domain controller for this domain.
<# consecutive failure>
<Last Success>

2. NTDS KCC, NTDS Replication events with the 1908 status are logged in the directory
service event log.

Active Directory events that commonly cite the 1908 status include but are not
limited to:

ﾉ Expand table

Event Event Event Event Event String

Source Category ID Type

NTDS KCC Knowledge 1926 Warning The attempt to establish a replication link
Consistency to a read-only directory partition with the
Checker following parameters failed.

NTDS KCC Knowledge 1925 Warning The attempt to establish a replication link
Consistency for the following writable directory
Checker partition failed.

NTDS Replication 1943 Error Active Directory was unable to remove all
Replication of the lingering objects on the local
domain controller. However, some
lingering objects might have been deleted
on this domain controller before this
operation stopped. All objects had their
existence verified on the following source
domain controller.

NTDS Setup 1125 Error The Active Directory Domain Services

Replication Installation Wizard (Dcpromo) was unable
to establish connection with the following
domain controller.

These events will contain the following sub Error Value:

Additional Data
Error Value:
 Could not find the domain controller for this domain. 1908

3. When trying to force replication in Active Directory Sites and Services console
(dssite.msc) via the "Replicate now" option, we may receive below error:

Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to
synchronize naming context <Naming Context> from Domain Controller
<Source-DC-Name> to Domain Controller <Destination-DC-Name>: Could not
find the domain controller for this domain.

Failure Message: Could not find the domain controller for this domain.

Buttons in Dialog: OK

4. Domain Controller Promotion/Demotion

Dialog Box on Dcpromo.exe Failure:

Dialog title text: Active Directory Installation Wizard

Dialog message text: Active Directory could not create the NTDS Settings object for
this Domain Controller CN=NTDS Settings,CN=<DC_Name>,CN=Servers,CN=
<SiteName>,CN=Sites,CN=Configuration,<DomainDN> on the remove domain
controller <Remote_DC_FQDN>. Ensure the provided network credentials have
sufficient permissions.

Failure Message: Could not find the Domain Controller for this domain.

Buttons in Dialog: OK

DCPromo.log file reports(%windir%\debug\DCPromo.log):

[INFO] Error - Active Directory Domain Services could not create the NTDS Settings
object for this Active Directory Domain Controller CN=NTDS Settings,CN=CONTOSO-
DC02,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=Contoso,DC=com on the remote AD DC
contoso-dc01.Contoso.com . Ensure the provided network credentials have sufficient

permissions. (1908)
[INFO] NtdsInstall for Contoso.com returned 1908
[INFO] DsRolepInstallDs returned 1908
[ERROR] Failed to install to Directory Service (1908)

Cause
Error Code 1908 represents the error that displays as "Could not find the domain controller
for this domain." This error has two primary causes:

1. The destination DC is unable to contact a Key Distribution Center(KDC)

2. The computer is experiencing Kerberos related errors

An important concept to understand for this scenario is that the KDC used for replication
operations may be:

a. The destination DC
b. The source DC
c. An entirely different DC (not the source or destination DC).

Resolution
1. Verify the Key Distribution Service is running on the Target Domain Controller

Discover the Kerberos Key Distribution Center you are contacting. It can be
discovered by using a packet capture program like Network Monitor 3.4 .

a. Use Network Monitor to capture the reproduced error message. (You may need to
stop the DNS client service first so that you see the DNS query traffic)

b. Review the packet capture for the DNS query for a KDC: Sample Address Queries:

_kerberos.tcp.<SiteName>._sites.dc._msdcs.<Domain>.com
_kerberos._tcp.dc._msdcs.<Domain>.com

c. Review for any DCLocator Traffic:

Sample Network Monitor 3.4 capture of DcLocator Traffic. In this example,
10.0.1.11 is the KDC we discovered and 10.0.1.10 is the client requesting a ticket. It
uses the default Network Monitor Column layout.

ﾉ Expand table

Frame Time Time Source Destination Details

# and Offset IP IP
Date

42 3/7/2012 3.6455760 10.0.1.10 10.0.1.11 LDAPMessage: Search Request,

MessageID: 371 *** This packet is a
UDP LDAP call for DC Locator looking
for Netlogon***

43 3/7/2012 3.6455760 10.0.1.11 10.0.1.10 NetLogon:LogonSAMPauseResponseEX

(SAM Response when Netlogon is
 Frame Time Time Source Destination Details
# and Offset IP IP
Date

paused): 24 (0x18)

d. Verify that 10.10.1.11's KDC and Netlogon services are running. On discovered
Domain Controller(10.0.1.11), verify the KDC and Netlogon service status with SC
Query

Example - Query the KDC service with: "SC Query KDC" and the Netlogon Service
with: "SC Query Netlogon" These commands should return "State: Running"

2. Verify that the destination Domain Controller is Advertising as a Key Distribution

Center
Use DCDIAG.exe to verify that the destination Domain Controller is advertising. From
a CMD.exe prompt, run the following command:

Console

C:\DCDiag.exe /v /test:Advertising /test:SysVolCheck

Verify that the Domain Controller passes the Advertising and SYSVOLCHeck tests and
is advertising as a Key Distribution Center and SysVol is ready. If SysVol is not ready,
the server will not be able to advertise as a Domain Controller.

Testing server:<SiteName><DC Name>

Starting test: Advertising
The DC <DC Name> is advertising itself as a DC and having a DS
The DC <DC Name> is advertising as an LDAP server
The DC <DC Name> is advertising as having a writeable directory
The DC <DC Name> is advertising as a Key Distribution Center
The DC <DC Name> is advertising as a time server
The DS <DC Name> is advertising as a GC.

Starting Test: SysVolCheck * The File Replication Service SYSVOL ready test
File Replication Service's SYSVOL is ready
..<DC Name> passed test SysVolCheck

3. Verify that source computer and target computer are within 5 minutes of each other.

4. Check for any Kerberos failures

a. Enable Kerberos Event Logging on Client Machine and Domain Controllers in site.
b. KB: 262177 How to enable Kerberos event logging
 c. Troubleshooting Kerberos

More information
This error is one of the featured exercises in the following TechNet hands-on lab: TechNet
hands-on lab: Troubleshooting Active Directory replication errors
In this lab, you will walk through the troubleshooting, analysis, and implementation phases
of commonly encountered Active Directory replication errors. You will use a combination of
ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five DC, three-domain
environment. AD replication errors encountered in the lab include -2146893022, 1256,
1908, 8453 and 8606.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory domain join
troubleshooting guidance
Article • 02/19/2024

This guide provides the fundamental concepts used when troubleshooting Active
Directory domain join issues.

Troubleshooting checklist
Domain Name System (DNS): Anytime you have an issue joining a domain, one of
the first things to check is DNS. DNS is the heart of Active Directory and makes
things work correctly, including domain join. Make sure of the following items:
DNS server addresses are correct.
DNS suffix search order is correct if multiple DNS domains are in play.
There are no stale or duplicate DNS records referencing the same computer
account.
Reverse DNS doesn't point to a different name as the A record.
The domain name, domain controllers (DCs), and DNS servers can be pinged.
Check for DNS record conflicts for the specific server.

Netsetup.log: The Netsetup.log file is a valuable resource when you troubleshoot a

domain join issue. The netsetup.log file is located at
C:\Windows\Debug\netsetup.log.

Network trace: During an AD domain join, multiple types of traffic occur between
the client and some DNS servers and then between the client and some DCs. If you
see an error in any of the above traffic, follow the corresponding troubleshooting
steps of that protocol or component to narrow it down. For more information, see
Using Netsh to Manage Traces.

Domain join hardening changes: Windows updates released on and after October
11, 2022, contain additional protections introduced by CVE-2022-38042 . These
protections intentionally prevent domain join operations from reusing an existing
computer account in the target domain unless one of the following conditions
exist:
The user attempting the operation is the creator of the existing account.
The computer was created by a member of domain administrators.

For more information, see KB5020276—Netjoin: Domain join hardening changes .

Port Requirements
The following table lists the ports required to be open between the client computer and
the DC.

ﾉ Expand table

Port Protocol Application System service name

protocol

53 TCP DNS DNS Server

53 UDP DNS DNS Server

389 UDP DC Locator LSASS

389 TCP LDAP Server LSASS

88 TCP Kerberos Kerberos Key Distribution Server

135 TCP RPC RPC Endpoint Mapper

445 TCP SMB LanmanServer

1024- TCP RPC RPC Endpoint Mapper for DSCrackNames, SAMR and
65535 Netlogon calls between Client and Domain Controller

Common issues and solutions

Error code 0x569

The user has not been granted the requested logon type at this computer.

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: failed to find a DC having account

<computer name>$': 0x525
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: found DC '\\<DC name>.<domain>.
<tld>' in the specified domain
mm/dd/yyyy hh:mm:ss:ms NetUseAdd to \\<DC name>.<domain>.<tld>\IPC$ returned
1385
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: status of connecting to dc '\\<DC
Name>.<Domain>.<tld>': 0x569
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x569
Error 0x569 is logged when the domain join user lacks the Access this computer from
the network user right. Make sure of the following items:

Verify that the user account performing the domain join operation (or the security
group that owns the member of the domain join user) has been granted the
Access this computer from the network right in the default domain controllers
policy.
The default domain controllers policy is linked to the OU that hosts the DC
computer account that's servicing the domain join operation.
The DC servicing the domain join operation applies the policy successfully,
specifically the user rights settings defined in the default domain controllers policy.

Error code 0x534

No mapping between account names and security IDs was done.

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpCreateComputerObjectInDs: NetpGetComputerObjectDn

failed: 0x534
mm/dd/yyyy hh:mm:ss:ms NetpProvisionComputerAccount: LDAP creation failed:
0x534
mm/dd/yyyy hh:mm:ss:ms ldap_unbind status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: Function exits with status of:
0x534
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: status of disconnecting from '\\
<DC name>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x534

The domain join graphical user interface (GUI) can call the NetJoinDomain API twice to
join a computer to a domain. The first call is made without the "create" flag being
specified to locate a pre-created computer account in the target domain. If no account
is found, a second NetJoinDomain API call may be made with the "create" flag specified.

In another scenario, the 0x534 error code is logged when you attempt to change the
password for a machine account. However, the account can't be found on the targeted
DC, likely because the account was not created or due to replication latency or a
replication failure.

The 0x534 error code is commonly logged as a transient error when domain join
searches the target domain. The search determines whether a matching computer
account was pre-created or the join operation needs to dynamically create a computer
account on the target domain. Check the bit flags in the join options to see if the type of
join being performed is relying on a pre-created or newly created computer account.

Error code 0x6BF or 0xC002001C

The remote procedure call failed and did not execute.

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpGetLsaHandle: LsaOpenPolicy on \\<DC name>.

<domain>.<tld> failed: 0xc002001c
mm/dd/yyyy hh:mm:ss:ms NetpGetLsaPrimaryDomain: status: 0xc002001c
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: initiaing a rollback due to earlier
errors
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: status of disconnecting from '\\<DC
name>.<domain>.<tld>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x6bf

This error occurs when a network device (router, firewall, or VPN device) rejects network
packets between the client being joined and the DC.

Make sure of the following items:

Verify the connectivity between the client being joined and the target DC over the
required ports and protocols.
Disable bind time feature negotiation.
Disable TCP Chimney Offload and IP offload.

Error code 0x6D9

There are no more endpoints available from the endpoint mapper.

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpGetDnsHostName: Read NV Hostname: <hostname>

mm/dd/yyyy hh:mm:ss:ms NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS
domain name: <DNS domain>.<TLD>
mm/dd/yyyy hh:mm:ss:ms NetpLsaOpenSecret: status: 0xc0000034
mm/dd/yyyy hh:mm:ss:ms NetpGetLsaPrimaryDomain: status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpLsaOpenSecret: status: 0xc0000034
mm/dd/yyyy hh:mm:ss:ms NetpManageMachineAccountWithSid: NetUserAdd on \\
 <hostname>.<domain> for <computername>$ failed: 0x8b0
mm/dd/yyyy hh:mm:ss:ms NetpManageMachineAccountWithSid: status of attempting
to set password on \\<DC name>.<domain>.<tld> for <hostname>$: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: status of creating account: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpGetComputerObjectDn: Unable to bind to DS on \\
<DC name>.<domain>.<tld>: 0x6d9
mm/dd/yyyy hh:mm:ss:ms NetpSetDnsHostNameAndSpn: NetpGetComputerObjectDn
failed: 0x6d9
mm/dd/yyyy hh:mm:ss:ms ldap_unbind status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: status of setting DnsHostName and
SPN: 0x6d9
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: initiaing a rollback due to earlier
errors
mm/dd/yyyy hh:mm:ss:ms NetpGetLsaPrimaryDomain: status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpManageMachineAccountWithSid: status of disabling
account <hostname>$ on \\<DC name>.<domain>.<tld>: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: rollback: status of deleting computer
account: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpLsaOpenSecret: status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: rollback: status of deleting secret:
0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomain: status of disconnecting from \\<DC
name>.<domain>.<tld>: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x6d9

Error 0x6D9 is logged when network connectivity is blocked between the joining client
and the helper DC. The network connectivity services the domain join operation over
port 135 or a port in the ephemeral range between 1025 to 5000 or 49152 to 65535. For
more information, see Service overview and network port requirements for Windows.

To resolve this error, follow these steps:

1. On the joining client, open the %systemroot%\debug\NETSETUP.LOG file and

determine the name of the helper DC selected by the joining client to perform the
join operation.
2. Verify that the joining client has network connectivity to the DC over the required
ports and protocols used by the applicable operating system (OS) versions.
Domain join clients connect a helper DC over TCP port 135 by the dynamically
assigned port in the range between 49152 and 65535.
3. Ensure that the OS, software and hardware routers, firewalls, and switches allow
connectivity over the required ports and protocols.

Error code 0xA8B

An attempt to resolve the DNS name of a DC in the domain being joined has failed.
Please verify this client is configured to reach a DNS server that can resolve DNS
names in the target domain.
Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: status of verifying DNS A record

name resolution for '<DC name>.<domain>.<tld>': 0x2746
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: failed to find a DC in the specified
domain: 0xa8b, last error is 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpDsGetDcName returned: 0xa8b
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: Function exits with status of:
0xa8b
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0xa8b

Error 0xA8B occurs if:

The workgroup computer being joined points to an invalid DNS server.

The DNS server(s) used by the joining computer is invalid, is missing the required
zones, or is missing the required records for the target domain.
The target Active Directory domain contains a problematic DNS name.
Network problems exist on the workgroup computer, the target DC, or the
network used to connect the client and target DC.

To resolve this error, follow these steps:

1. Verify that the computer being joined points to valid DNS server IP addresses.
Invalid examples include:

A stale or non-existent ISP DNS server on the corporate intranet.

A DNS server in an error state that prevents it from loading the _msdcs.
<Forest Root Domain> or target AD domain zones or resolving queries for
those zones. Event ID 4521 may be logged.

2. Verify that all DNS servers configured on the client host the required zones and
valid records for a DC in the target domain. Check for the following
misconfigurations:

Forward lookup zone for the target AD domain is missing.

The _msdcs forward lookup zone is missing.
The _msdcs.<Forest Root Domain> zone doesn't contain a Lightweight
Directory Access Protocol (LDAP) SRV record for a DC in the target domain.
Host A record is missing from the target AD domain zone.
Host A record is present but contains the wrong IP address for the target DC.
The host A record is present but was registered by a network interface that
isn't accessible to the client computer.
 3. Check for special names in the target Active Directory domain that require
additional configuration:

Single-label DNS name

Disjoint Namespace
All numeric top-level domains (TLDs) or TLDs containing numeric characters

4. Check for network problems on the workgroup computer, target DC, or the
network connecting the computer and the target DC:

A broken Network Interface Card (NIC) on the client computer or the target
DC
A broken network switch that drops network packets between the client and
target DC

Error code 0x40

The following error messages occur when you try to join the computer to the domain:

The specified network name is no longer available

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpValidateName: checking to see if '<domain_name>'

is valid as type 3 name
mm/dd/yyyy hh:mm:ss:ms NetpCheckDomainNameIsValid [ Exists ] for
'<domain_name>' returned 0x0
mm/dd/yyyy hh:mm:ss:ms NetpValidateName: name '<domain_name>' is valid for
type 3
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: trying to find DC in domain
'<domain_name>', flags: 0x40001010
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: failed to find a DC having account
'CLIENT1$': 0x525, last error is 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: status of verifying DNS A record
 name resolution for 'DCA.<domain_name>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDsGetDcName: found DC '\\<dc_fqdn>' in the
specified domain
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpDsGetDcName returned: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDisableIDNEncoding: using FQDN <domain_name> from
dcinfo
mm/dd/yyyy hh:mm:ss:ms NetpDisableIDNEncoding:
DnsDisableIdnEncoding(UNTILREBOOT) on '<domain_name>' succeeded
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpDisableIDNEncoding returned:
0x0
mm/dd/yyyy hh:mm:ss:ms NetUseAdd to \\<dc_fqdn>\IPC$ returned 64
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: status of connecting to dc '\\
<dc_fqdn>': 0x40
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: Function exits with status of:
0x40
mm/dd/yyyy hh:mm:ss:ms NetpResetIDNEncoding: DnsDisableIdnEncoding(RESETALL)
on '<domain_name>' returned 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpResetIDNEncoding on
'<domain_name>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x40

This error is logged when the client computer lacks network connectivity on TCP port 88
between the client machine and the DC. To troubleshoot this issue, you can run the
following command to test the connection:

PowerShell

Test-NetConnection <IP_address_of_the_DC> -Port 88

Expected Output:

The output indicates that the Kerberos Port TCP 88 is open between the client and the
DC.

Error code 0x54b

Here's an example of the error message:

Note: This information is intended for a network administrator. If you are not your
network's administrator, notify the administrator that you received this information,
which has been recorded in the file C:\WINDOWS\debug\dcdiag.txt.

The following error occurred when DNS was queried for the service location (SRV)
resource record used to locate an Active Directory Domain Controller (AD DC) for
domain "<domain_name>":

The error was: "This operation returned because the timeout period expired." (error
code 0x000005B4 ERROR_TIMEOUT)

The query was for the SRV record for <srv_record>

The DNS servers used by this computer for name resolution are not responding.
This computer is configured to use DNS servers with the following IP addresses:

<ip_address>

Verify that this computer is connected to the network, that these are the correct
DNS server IP addresses, and that at least one of the DNS servers is running.

Here's an example from the netsetup.log file:

 Output

mm/dd/yyyy hh:mm:ss:ms NetpValidateName: checking to see if '<domain_name>'

is valid as type 3 name
mm/dd/yyyy hh:mm:ss:ms NetpCheckDomainNameIsValid for <domain_name> returned
0x54b, last error is 0x0
mm/dd/yyyy hh:mm:ss:ms NetpCheckDomainNameIsValid [ Exists ] for
'<domain_name>' returned 0x54b

To resolve the 0x54b error, follow these steps:

Check the network connectivity between the client and the Domain controller.

Verify if the Preferred DNS Server is the correct DNS Server.

Run nltest /dsgetdc (DC Discovery) to verify if you can discover a DC.

For example:

Console

nltest /dsgetdc:<domain_name> /force

Expected Output:

Run DCDiag /v on the closest domain controller and verify if SRV records are
registered. For example: _ldap._tcp.dc._msdcs.<domain_name>.com .

Error code 0x0000232A

Error 0x0000232A is logged when the client computer lacks NetBIOS name resolution to
the domain.
Here's an example of the error message:

Note: This information is intended for a network administrator. If you are not your
network's administrator, notify the administrator that you received this information,
which has been recorded in the file C:\WINDOWS\debug\dcdiag.txt.

The domain name "<NetBIOS_name>" might be a NetBIOS domain name. If this is

the case, verify that the domain name is properly registered with WINS.

If you are certain that the name is not a NetBIOS domain name, then the following
information can help you troubleshoot your DNS configuration.

The following error occurred when DNS was queried for the service location (SRV)
resource record used to locate an Active Directory Domain Controller (AD DC) for
domain "<NetBIOS_name>":

The error was: "DNS server failure." (error code 0x0000232A

RCODE_SERVER_FAILURE)

The query was for the SRV record for _ldap._tcp.dc._msdcs.<NetBIOS_name>

Common causes of this error include the following:

 The DNS servers used by this computer contain incorrect root hints. This
computer is configured to use DNS servers with the following IP addresses:

<ip_address>

One or more of the following zones contains incorrect delegation:

<NetBIOS_name> . (the root zone)

Here's an example from the netsetup.log file:

Output

mm/dd/yyyy hh:mm:ss:ms NetpValidateName: checking to see if '<NetBIOS_name>'

is valid as type 3 name
mm/dd/yyyy hh:mm:ss:ms NetpCheckDomainNameIsValid for <NetBIOS_name>
returned 0x54b, last error is 0x0
mm/dd/yyyy hh:mm:ss:ms NetpCheckDomainNameIsValid [ Exists ] for
'<NetBIOS_name>' returned 0x54b

When you enter the domain name, make sure you enter the DNS Domain Name rather
than the NetBIOS name. For example, if the DNS name of the domain is contoso.com,
make sure you enter that name instead of just contoso.

Error code 0x3a

The following error occurred when attempting to join the domain:

The specified server cannot perform the requested operation.

Here's an example from the netsetup.log file:

Output
 mm/dd/yyyy hh:mm:ss:ms NetpLdapBind: ldap_bind failed on <dc_fqdn>: 81:
Server Down
mm/dd/yyyy hh:mm:ss:ms NetpJoinCreatePackagePart: status:0x3a.
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: Function exits with status of:
0x3a
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: status of disconnecting from '\\
<dc_fqdn>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpResetIDNEncoding: DnsDisableIdnEncoding(RESETALL)
on '<domain_name>' returned 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpResetIDNEncoding on
'<domain_name>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x3a

Error 0x3a is logged when the client computer lacks network connectivity on TCP port
389 between the client computer and the DC. To troubleshoot this issue, use the
following command to test the connection:

PowerShell

Test-NetConnection <IP_address_of_the_DC> -Port 389

Expected Output:

It indicates that the LDAP Port TCP 389 is open between the client and the DC.

Error code 0x216d

The following error occurred when attempting to join the domain:

Your computer could not be joined to the domain. You have exceeded the maximum
number of computer accounts you are allowed to create in this domain. Contact
your system administrator to have this limit reset or increased.
 Output

mm/dd/yyyy hh:mm:ss:ms NetpMapGetLdapExtendedError: Parsed [0x216d] from

server extended error string: 0000216D: SvcErr: DSID-031A124C, problem 5003
(WILL_NOT_PERFORM), data 0
mm/dd/yyyy hh:mm:ss:ms NetpModifyComputerObjectInDs: ldap_add_s failed: 0x35
0x216d
mm/dd/yyyy hh:mm:ss:ms NetpCreateComputerObjectInDs:
NetpModifyComputerObjectInDs failed: 0x216d
mm/dd/yyyy hh:mm:ss:ms NetpProvisionComputerAccount: LDAP creation failed:
0x216d
mm/dd/yyyy hh:mm:ss:ms NetpProvisionComputerAccount: Retrying downlevel per
options
mm/dd/yyyy hh:mm:ss:ms NetpManageMachineAccountWithSid: NetUserAdd on
'<dc_fqdn>' for 'CLIENT1$' failed: 0x216d
mm/dd/yyyy hh:mm:ss:ms NetpProvisionComputerAccount: retry status of
creating account: 0x216d
mm/dd/yyyy hh:mm:ss:ms ldap_unbind status: 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinCreatePackagePart: status:0x216d.
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: Function exits with status of:
0x216d
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: status of disconnecting from '\\
<dc_fqdn>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpResetIDNEncoding: DnsDisableIdnEncoding(RESETALL)
on '<domain_name>' returned 0x0
mm/dd/yyyy hh:mm:ss:ms NetpJoinDomainOnDs: NetpResetIDNEncoding on
'<domain_name>': 0x0
mm/dd/yyyy hh:mm:ss:ms NetpDoDomainJoin: status: 0x216d

Error 0x216d is logged in one of these conditions:

The user account trying to join the machine to the domain has exceeded the limit
of 10 machines joined to the domain.
There is a GPO restriction to block authenticated users from joining a machine to
the domain.
Verify that the user account is a member of the group mentioned in the Add
Workstations to domain policy of the Default Domain Controller Policy GPO or the
Winning GPO.

The GPO setting is located at Computer Configuration > Policies > Windows Settings
> Security Settings > Local Policies User Rights Assignment > Add workstations to
domain.

To verify the default limit to the number of workstations a user can join to the domain,
see Default limit to number of workstations a user can join to the domain.

Other errors that occur when you join Windows-based

computers to a domain
For more information, see:

Troubleshoot Networking error messages and resolutions

Troubleshoot Authentication error messages and resolutions

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unable to Join Windows Server 2008 R2
or Windows 7 Computer to Active
Directory Domain
Article • 02/19/2024

This article helps fix an issue where users can't join a computer to an Active Directory
domain.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2008652

Symptoms
You try to join a Windows Server 2008 R2 or a Windows 7 machine to an Active
Directory domain using Computer Name/Domain Changes under System Properties.
The destination domain has either Windows 2000, Windows Server 2003, or Windows
Server 2008 domain controllers and may have Windows NT 4.0 domain controllers
present. When trying to join the Windows Server 2008 R2 machine to the domain by
specifying the fully qualified domain name (FQDN) in the domain join UI, the operation
fails and you receive the error:

An Active Directory Domain Controller (AD DC) for the domain <target DNS domain
name> couldn't be contacted
Ensure that the domain name is typed correctly

In the %windir%\debug\Netsetup.log on the client you see the following sequence:

<DateTime> NetpValidateName: checking to see if 'CLIENT-NAME' is valid as type 1

name
<DateTime> NetpCheckNetBiosNameNotInUse for 'CLIENT-NAME'[MACHINE]
returned 0x0
<DateTime> NetpValidateName: name 'CLIENT-NAME' is valid for type 1
<DateTime>

<DateTime> NetpValidateName: checking to see if 'CLIENT-NAME' is valid as type 5

name
<DateTime> NetpValidateName: name 'CLIENT-NAME' is valid for type 5
<DateTime>
 <DateTime> NetpValidateName: checking to see if domain.com is valid as type 3
name
<DateTime> NetpCheckDomainNameIsValid for domain.com returned 0x54b, last
error is 0x0
<DateTime> NetpCheckDomainNameIsValid [ Exists ] for domain.com returned
0x54b

When trying to join the Windows Server 2008 R2 computer to the domain by specifying
the NetBIOS name in the domain join UI, you receive a different error:

The following error occurred attempting to join the domain <NetBIOS target
domain name>. The specified domain either does not exist or could not be
contacted.

In the %windir%\debug\Netsetup.log on the client you see the following sequence:

<DateTime> -----------------------------------------------------------------
<DateTime> NetpDoDomainJoin
<DateTime> NetpMachineValidToJoin: 'CLIENT-NAME'
<DateTime> OS Version: 6.1
<DateTime> Build number: 7600 (7600.win7_rtm.090713-1255)
<DateTime> SKU: Windows Server 2008 R2 Enterprise
<DateTime> NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0
<DateTime> NetpGetLsaPrimaryDomain: status: 0x0
<DateTime> NetpMachineValidToJoin: status: 0x0
<DateTime> NetpJoinDomain
<DateTime> Machine: CLIENT-NAME
<DateTime> Domain: Domain_Name
<DateTime> MachineAccountOU: (NULL)
<DateTime> Account: Domain_Name\admx054085
<DateTime> Options: 0x27
<DateTime> NetpLoadParameters: loading registry parameters...
<DateTime> NetpLoadParameters: DNSNameResolutionRequired not found,
defaulting to '1' 0x2
<DateTime> NetpLoadParameters: DomainCompatibilityMode not found, defaulting
to '0' 0x2
<DateTime> NetpLoadParameters: status: 0x2
<DateTime> NetpValidateName: checking to see if 'Domain_Name' is valid as type 3
name
<DateTime> NetpValidateName: 'Domain_Name' is not a valid Dns domain name:
 0x2554
<DateTime> NetpCheckDomainNameIsValid [ Exists ] for 'Domain_Name' returned
0x0
<DateTime> NetpValidateName: name 'Domain_Name' is valid for type 3
<DateTime> NetpDsGetDcName: trying to find DC in domain 'Domain_Name', flags:
0x40001010
<DateTime> NetpDsGetDcName: failed to find a DC in the specified domain:
0x54b, last error is 0x0
<DateTime> NetpJoinDomainOnDs: NetpDsGetDcName returned: 0x54b
<DateTime> NetpJoinDomainOnDs: Function exits with status of: 0x54b
<DateTime> NetpDoDomainJoin: status: 0x54b

Domain joins by Windows Server 2003 computers to the same target domain succeed
by specifying the NetBIOS domain name in the domain join UI. Domain joins using the
FQDN also fail.
You can also successfully join the same Windows Server 2008 R2 machine to a different
Active Directory domain in the same forest specifying the FQDN domain name.

Cause
The errors occur if NT4Emulator is set to 0x1 in the following registry subkey of the
helper domain controller used to join the target domain:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

Value Name: NT4Emulator

Value Type: REG_DWORD
Value Data: 1

Resolution
To resolve this issue either delete the NT4Emulator registry value on the Active
Directory domain controllers in the destination domain if Windows NT 4.0 domain
controllers are no longer present or can be retired. Otherwise, set the following registry
value on the Windows 7 or Windows Server 2008 R2 client before attempting to join the
domain:

1. Start Registry Editor ( Regedit.exe ).

2. Locate the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
 3. If it does not exist, create a new REG_DWORD value named
NeutralizeNT4Emulator, and set the value to 0x1.

4. Quit Registry Editor.

This registry setting allows the Active Directory domain controllers with the
NT4Emulator setting to respond normally to the requesting client (avoiding Windows
NT 4.0 emulation mode).

More information
In the case of the join by FQDN, the joining client does not receive an adequate
response to the LDAP pings it sends to the domain controllers at the beginning of the
domain join process. The helper domain controller responds but the joining client
considers the response incomplete.

After receiving the same replies from all domain controllers located using DNS, it falls
back to performing a NetBIOS name query for the FQDN domain name to locate a
domain controller, however this gets no response and the join operation fails. If the
NetBIOS scenario the client sends a NetLogonSamRequest to all domain controllers it
receives from the WINS query for the domain name. However it receives no adequate
response and fails with the second error.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows 7 or Windows Server 2008 R2
domain join displays error (Changing
the Primary Domain DNS name of this
computer to "" failed....)
Article • 02/19/2024

This article provides a solution to an error that occurs when you use the domain join
User Interface (UI) to join a Windows 7 or Windows Server 2008 R2 workgroup
computer to an Active Directory domain by specifying the target DNS domain name.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2018583

Symptoms
Using the domain join UI to join a Windows 7 or Windows Server 2008 R2 workgroup
computer to an Active Directory domain by specifying the target DNS domain name
fails with the following on-screen error:

Changing the Primary Domain DNS name of this computer to "" failed. The name
will remain "<DNS domain>.<top level domain>".
The error was:

The specified server cannot perform the required operation.

The NETSETUP.LOG on the computer being joined contains the following text:

<date> <time> NetpSetDnsHostNameAndSpn: NetpLdapBind failed: 0x3a

where 0x3a maps to:

ﾉ Expand table

UI Error Symbolic Error String Hex Error Decimal Error

# #

The specified server cannot perform the ERROR_BAD_NET_RESP 0x3a 58

operation
Cases where the "Changing the Primary Domain DNS name.." error appears in
conjunction with extended errors other than "the specified server cannot perform the
required operation", including those listed in the table below, are NOT related to the
symptom, cause, or resolution text discussed in this article.

The Extended errors that make the "Changing the Primary DNS name..." error unrelated
to this KB include:

ﾉ Expand table

Extended Error

A security package specific error occurred

The remote procedure call failed and did not execute

Cause
When a computer is joined to the domain, it attempts to register a Service Principal
Name to ensure that its DNS suffix is allowed in the target domain. The domain join UI
queries information from the Local Security Authority (LSA) policy database for the short
(NetBIOS) and long (DNS) names of the target domain.

The error described in the Symptoms section occurs because a function in the domain
join UI improperly performs a LDAP bind to a Domain Controller in the target domain by
its short name, which fails in one of the following conditions:

The Disable NetBIOS over TCP/IP checkbox has been disabled in the IPv4
properties of the computer being joined.
Connectivity over UDP port 137 is blocked between client and the helper DC
servicing the join operation in the target domain.
The TCP/IPv4 protocol has been disabled so that the client being joined or the DC
in the destination domain targeted by the LDAP BIND is running TCP/IPv6 only.

Resolution
Despite the appearance of the on-screen error described in the Symptoms section, the
domain join operation completes as evidenced by the status in the NETSETUP.LOG.

NetpCompleteOfflineDomainJoin SUCCESS: Requested a reboot :0x0

NetpDoDomainJoin: status: 0x0
To eliminate the error, use one of the following methods:

Verify that NetBIOS over TCP/IP is enabled.

1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. In Network Connections, right-click Local Area Connection, and then click
Properties.
3. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
4. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click
Advanced.
5. On the WINS tab, verify Enable NetBIOS Over TCP/IP is enabled, and then
click OK three times.

Verify end-to-end network connectivity over UDP port 137 over the network path
connecting the client being and the helper DC serving the join operation.

If the error occurred in an IPv6 only environment or you require a fix to resolve the
error, open a support incident with Microsoft Customer Service and Support
requesting a post RTM fix for Windows 7/Windows Server 2008 R2.

Add Domain DNS Suffix in the TCP/IP Properties.

1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. In Network Connections, right-click Local Area Connection, and then click
Properties.
3. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
4. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click
Advanced.
5. On the DNS tab, select these DNS Suffixes, click Add, type the FQDN of the
domain in the DNS Server dialog box, click Add, and then click OK three
times.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Domain controllers can't be located and
high-rate outbound sessions
Article • 02/19/2024

This article describes how to troubleshoot the issue that a machine creates outbound
sessions at a high rate.

Original KB number: 4458261

When this issue occurs, the Netlogon service tries to locate domain controllers (DCs) for
domain users and resources, and establish the trust path between the users and the
resource domains.

In some scenarios, the issue may affect the communication between application servers
(For example, Exchange servers), or the communication between application servers and
backend servers (For example, web, database, or reporting servers). If the level of
application activity crosses a threshold, the application servers will fail to have sessions
with each other or backend servers.

Many UDP ports are used by the LSASS process

There are many User Datagram Protocol (UDP) ports that are used by the Local Security
Authority Subsystem Service (LSASS) process.

Output

[lsass.exe]
UDP 0.0.0.0:54335 *:* 908

In the Netlogon log file (netlogon.log), many entries that resemble the following are
recorded:

Output

[CRITICAL] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Cannot LdapOpen ip

address XX.YY.ZZ.26: 58
[CRITICAL] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Cannot LdapOpen ip
address XX.YY.ZZ.70: 58
[CRITICAL] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Cannot LdapOpen ip
address XX.YY.ZZ.119: 58
You also find requests time out. When you relate the thread ID, you can find what kind
of requests time out. See the following logs for an example:

Output

[MAILSLOT] [32192] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Sent UDP ping to

XX.YY.ZZ.119
…
[CRITICAL] [32192] NetpDcGetPingResponse: it took 117063 msecs to poll|

Eventually, the requests to locate DCs fail, and the following logs are recorded:

Output

[MISC] [32192] DsGetDcName function called: client PID=180,

Dom:INTERNAL.CONTOSO.COM Acct:(null) Flags: IP KDC
…
[MISC] [32192] DsGetDcName function returns 1355 (client PID=180):
Dom:INTERNAL.CONTOSO.COM Acct:(null) Flags: IP KDC

You can check more requests to establish patterns to identify which domains are
affected the most, and whether all the requests fail in the netlogon.log file. To search a
pattern, use a command as follows:

Console

findstr DsGetDcName netlogon.log | findstr /i /c:"internal." > netlogon-

internal-calls.txt

It helps to determine whether a DC is requested frequently because another DC is

unresponsive. If you identify a DC that works slowly or unresponsive, reestablish the
communication to the DCs of the domain or improve the performance.

In a memory dump of the LSASS process, threads are waiting with stack as follows:

Output

# Call Site
00 ntdll!RtlLeaveCriticalSection+0x29
01 Wldap32!ReferenceLdapRequest+0x44
02 Wldap32!LdapGetResponseFromServer+0x207
03 Wldap32!LdapWaitForResponseFromServer+0x27a
04 Wldap32!ldap_result_with_error+0x293
05 Wldap32!ldap_result+0x74
06 netlogon!NetpDcGetPingResponse+0xec
07 netlogon!NetpDcPingListIp+0x1df
08 netlogon!NetpDcGetNameSiteIp+0xa3
 09 netlogon!NetpDcGetNameIp+0x188
0a netlogon!NetpDcGetName+0x11bb
0b netlogon!DsIGetDcName+0x463
0c netlogon!DsrGetDcNameEx2+0x3a0
0d kerberos!KerbGetKdcBinding+0x8e8
0e kerberos!KerbMakeSocketCall+0x165
0f kerberos!KerbGetTgsTicketEx+0x9ee
10 kerberos!KerbGetTgsTicket+0x84
11 kerberos!KerbGetServiceTicketInternal+0x739
12 kerberos!KerbGetServiceTicket+0xca
13 kerberos!KerbILogonUserEx2+0x1b2f
14 kerberos!LsaApLogonUserEx2+0xa6
15 lsasrv!NegLogonUserEx2Worker+0x7c7
16 lsasrv!NegLogonUserEx2+0x673
17 lsasrv!LsapCallAuthPackageForLogon+0xd0
18 lsasrv!LsapAuApiDispatchLogonUser+0x4ab
19 lsasrv!SspiExLogonUser+0x20e
1a sspisrv!SspirLogonUser+0x1eb
1b rpcrt4!Invoke+0x65

UDP sockets exhaustion

When a UDP port is used, the connection is in a TIME_WAIT state before it can be
reused. If applications on the system use different UDP sockets at a high rate, or if new
sockets are required at a rate higher than the rate at which unused sockets are cleaned
up, the system may run out of sockets. The system may go into a state that never
recovers, especially if the applications retry the communication attempt frequently. In
this scenario, the Netlogon service uses a new UDP socket for each DC discovery
attempt.

７ Note

The default socket range is 16384 sockets since Windows Vista.

When a DC isn't responsive (for example, DCs are offline or blocked by a firewall), the
Netlogon service backs up a queue of threads waiting to resolve DCs.

Allow more UDP sockets and reuse old sockets

earlier
Configure the registry to allow more UDP sockets to be used for application requests. In
addition, shorten the length of time that a connection stays in the TIME_WAIT state, so
that the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol can reuse old
sockets earlier. Here are the steps:

1. Open Registry Editor.

2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters .

3. Modify or create the registry entries as follows:

ﾉ Expand table

Value name Value data

TcpTimedWaitDelay 30

MaxUserPort 65000

StrictTimeWaitSeqCheck 1

Windows Server 2019 introduces a new registry entry that enables the Netlogon service
not to use a new socket for each DC discovery attempt. The entry named
DCLocatorLdapConnectionCacheEnabled is in the registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters . The value

data can be set to 1 for enabling this feature.

７ Note

You can set the value data to 0 to disable the feature.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Enable LDAP over SSL with a third-party
certification authority
Article • 02/19/2024

This article describes how to enable Lightweight Directory Access Protocol (LDAP) over
Secure Sockets Layer (SSL) with a third-party certification authority.

Applies to: Windows Server 2012 R2

Original KB number: 321051

Summary
The LDAP is used to read from and write to Active Directory. By default, LDAP traffic is
transmitted unsecured. You can make LDAP traffic confidential and secure by using
SSL/Transport Layer Security (TLS) technology. You can enable LDAP over SSL (LDAPS) by
installing a properly formatted certificate from either a Microsoft certification authority
(CA) or a non-Microsoft CA according to the guidelines in this article.

There's no user interface for configuring LDAPS. Installing a valid certificate on a domain
controller permits the LDAP service to listen for, and automatically accept, SSL
connections for both LDAP and global catalog traffic.

Requirements for an LDAPS certificate

To enable LDAPS, you must install a certificate that meets the following requirements:

The LDAPS certificate is located in the Local Computer's Personal certificate store
(programmatically known as the computer's MY certificate store).

７ Note

If there is a certificate in the NT Directory Services (NTDS) store, DC use the

certificate in the NTDS store instead.

A private key that matches the certificate is present in the Local Computer's store
and is correctly associated with the certificate. The private key must not have
strong private key protection enabled.
 The Enhanced Key Usage extension includes the Server Authentication
(1.3.6.1.5.5.7.3.1) object identifier (also known as OID).

The Active Directory fully qualified domain name of the domain controller (for
example, dc01.contoso.com) must appear in one of the following places:
The Common Name (CN) in the Subject field.
DNS entry in the Subject Alternative Name extension.

The certificate was issued by a CA that the domain controller and the LDAPS clients
trust. Trust is established by configuring the clients and the server to trust the root
CA to which the issuing CA chains.

Use the Schannel cryptographic service provider (CSP) to generate the key.

Create the certificate request

Any utility or application that creates a valid PKCS #10 request can be used to form the
SSL certificate request. Use Certreq to form the request.

Certreq.exe requires a text instruction file to generate an appropriate X.509 certificate

request for a domain controller. You can create this file by using your preferred ASCII
text editor. Save the file as an .inf file to any folder on your hard drive.

To request a Server Authentication certificate that is suitable for LDAPS, follow these
steps:

1. Create the .inf file. Following is an example .inf file that can be used to create the
certificate request.

;----------------- request.inf -----------------

[Version]

Signature="$Windows NT$

[NewRequest]

Subject = "CN=<DC fqdn>" ; replace with the FQDN of the DC

KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
 MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

;-----------------------------------------------

Cut and paste the sample file into a new text file named Request.inf. Provide the
fully qualified DNS name of the domain controller in the request.

Some third-party certification authorities may require additional information in the

Subject parameter. Such information includes an e-mail address (E), organizational
unit (OU), organization (O), locality, or city (L), state or province (S), and country or
region (C). You can append this information to the Subject name (CN) in the
Request.inf file. For example:

Subject="[email protected], CN=<DC fqdn>, OU=Servers, O=Contoso,

L=Redmond, S=Washington, C=US."

2. Create the request file by running the following command at the command
prompt:

Console

certreq -new request.inf request.req

A new file called Request.req is created. It's the base64-encoded request file.

3. Submit the request to a CA. You can submit the request to a Microsoft CA or to a
third-party CA.

4. Retrieve the certificate that's issued, and then save the certificate as Certnew.cer in
the same folder as the request file by following these steps:
a. Create a new file called Certnew.cer.
 b. Open the file in Notepad, paste the encoded certificate into the file, and then
save the file.

７ Note

The saved certificate must be encoded as base64. Some third-party CAs return
the issued certificate to the requestor as base64-encoded text in an e-mail
message.

5. Accept the issued certificate by running the following command at the command
prompt:

Console

certreq -accept certnew.cer

6. Verify that the certificate is installed in the computer's Personal store by following
these steps:
a. Start Microsoft Management Console (MMC).
b. Add the Certificates snap-in that manages certificates on the local computer.
c. Expand Certificates (Local Computer), expand Personal, and then expand
Certificates. A new certificate should exist in the Personal store. In the
Certificate Properties dialog box, the intended purpose displayed is Server
Authentication. This certificate is issued to the computer's fully qualified host
name.

7. Restart the domain controller.

For more information about creating the certificate request, see the following Advanced
Certificate Enrollment and Management white paper. To view this white paper, see
Advanced Certificate Enrollment and Management.

Verify an LDAPS connection

After a certificate is installed, follow these steps to verify that LDAPS is enabled:

1. Start the Active Directory Administration Tool (Ldp.exe).

2. On the Connection menu, click Connect.

3. Type the name of the domain controller to which you want to connect.

4. Type 636 as the port number.

 5. Click OK.

RootDSE information should print in the right pane, indicating a successful

connection.

Possible issues
Start TLS extended request

LDAPS communication occurs over port TCP 636. LDAPS communication to a

global catalog server occurs over TCP 3269. When connecting to ports 636 or
3269, SSL/TLS is negotiated before any LDAP traffic is exchanged.

Multiple SSL certificates

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in
the local computer store. If there are multiple valid certificates available in the local
computer store, Schannel may not select the correct certificate.

Pre-SP3 SSL certificate caching issue

If an existing LDAPS certificate is replaced with another certificate, either through a

renewal process or because the issuing CA has changed, the server must be
restarted for Schannel to use the new certificate.

Improvements
The original recommendation in this article was to put certificates in the Local Machine's
Personal store. Although this option is supported, you can also put certificates in the
NTDS Service's Personal certificate store in Windows Server 2008 and in later versions of
Active Directory Domain Services (AD DS). For more information about how to add the
certificate to the NTDS service's Personal certificate store, see Event ID 1220 - LDAP over
SSL.

AD DS preferentially looks for certificates in this store over the Local Machine's store.
This makes it easier to configure AD DS to use the certificate that you want it to use. It's
because there might be multiple certificates in the Local Machines Personal store, and it
can be difficult to predict which one is selected.

AD DS detects when a new certificate is dropped into its certificate store and then
triggers an SSL certificate update without having to restart AD DS or restart the domain
controller.
A new rootDse operation that's named renewServerCertificate can be used to manually
trigger AD DS to update its SSL certificates without having to restart AD DS or restart
the domain controller. This attribute can be updated using adsiedit.msc, or by importing
the change in LDAP Directory Interchange Format (LDIF) using ldifde.exe. For more
information on using LDIF to update this attribute, see renewServerCertificate.

Finally, if a Windows Server 2008 or a later version domain controller finds multiple
certificates in its store, it will random chose one of these certificates.

All these work for Windows Server 2008 AD DS and for 2008 Active Directory
Lightweight Directory Services (AD LDS). For AD LDS, put certificates into the Personal
certificate store for the service that corresponds to the AD LDS instance instead of for
the NTDS service.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to disable TLS 1.3 for AD and LDAP
Article • 02/19/2024

The Windows updates KB5014668 and KB5014665 add support for Transport Layer
Security (TLS) 1.3 when using LDAP over SSL or issuing the StartTLS command. The
updates were released on 6/21/2022.

You may need to disable the TLS 1.3 support for compatibility reasons. This article
introduces how to disable or re-enable the TLS 1.3 support.

Disable or re-enable TLS 1.3

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

LDAP server side

Use Registry Editor to modify the following values to disable or re-enable TLS 1.3 for
Lightweight Directory Access Protocol (LDAP) on the server side:

Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Registry value: LdapDisableTLS1.3

Value type: REG_DWORD
Value data: 0 (Default Enabled) / 1 (Disabled)

Restart the Active Directory Domain Services service for the setting to be effective.

LDAP client side

Use Registry Editor to modify the following values to disable or re-enable TLS 1.3 for
LDAP on the client side:

Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP

Registry value: DisableTLS1.3
Value type: REG_DWORD
 Value data: 0 (Default Enabled) / 1 (Disabled)

The setting starts taking effect at the next LDAP connection.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to enable LDAP signing in
Windows Server
Article • 02/22/2024

This article describes how to enable LDAP signing in Windows Server 2022, Windows
Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10, and
Windows 11.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 11 - all editions, Windows 10 - all editions
Original KB number: 935834

Summary
You can significantly improve the security of a directory server by configuring the server
to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not
request signing (integrity verification), or to reject LDAP simple binds that are performed
on a clear text (non-SSL/TLS-encrypted) connection. SASL binds may include protocols
such as Negotiate, Kerberos, NTLM, and Digest.

Unsigned network traffic is susceptible to replay attacks. In such attacks, an intruder

intercepts the authentication attempt and the issuance of a ticket. The intruder can
reuse the ticket to impersonate the legitimate user. Additionally, unsigned network
traffic is susceptible to man-in-the-middle (MIM) attacks in which an intruder captures
packets between the client and the server, changes the packets, and then forwards them
to the server. If this occurs on an LDAP server, an attacker can cause a server to make
decisions that are based on forged requests from the LDAP client.

How to discover clients that do not use the

Require signing option
After you make this configuration change, clients that rely on unsigned SASL (Negotiate,
Kerberos, NTLM, or Digest) LDAP binds or on LDAP simple binds over a non-SSL/TLS
connection stop working. To help identify these clients, the directory server of Active
Directory Domain Services (AD DS) or Lightweight Directory Server (LDS) logs a
summary Event ID 2887 one time every 24 hours to indicate how many such binds
occurred. We recommend that you configure these clients not to use such binds. After
no such events are observed for an extended period, we recommend that you configure
the server to reject such binds.

If you must have more information to identify such clients, you can configure the
directory server to provide more detailed logs. This additional logging will log an Event
ID 2889 when a client tries to make an unsigned LDAP bind. The log entry displays the IP
address of the client and the identity that the client tried to use to authenticate. You can
enable this additional logging by setting the 16 LDAP Interface Events diagnostic
setting to 2 (Basic). For more information about how to change the diagnostic settings,
see How to configure Active Directory and LDS diagnostic event logging .

If the directory server is configured to reject unsigned SASL LDAP binds or LDAP simple
binds over a non-SSL/TLS connection, the directory server logs a summary Event ID
2888 one time every 24 hours when such bind attempts occur.

How to configure the directory to require LDAP

server signing for AD DS
For information about possible affects of changing security settings, see Client, service,
and program issues can occur if you change security settings and user rights
assignments .

Using Group Policy

How to set the server LDAP signing requirement

1. Select Start > Run, type mmc.exe, and then select OK.
2. Select File > Add/Remove Snap-in, select Group Policy Management Editor, and
then select Add.
3. Select Group Policy Object > Browse.
4. In the Browse for a Group Policy Object dialog box, select Default Domain
Controller Policy under the Domains, OUs, and linked Group Policy Objects area,
and then select OK.
5. Select Finish.
6. Select OK.
7. Select Default Domain Controller Policy > Computer Configuration > Policies >
Windows Settings > Security Settings > Local Policies, and then select Security
Options.
8. Right-click Domain controller: LDAP server signing requirements, and then select
Properties.
 9. In the Domain controller: LDAP server signing requirements Properties dialog
box, enable Define this policy setting, select Require signing in the Define this
policy setting list, and then select OK.
10. In the Confirm Setting Change dialog box, select Yes.

How to set the client LDAP signing requirement by using local

computer policy
1. Select Start > Run, type mmc.exe, and then select OK.
2. Select File > Add/Remove Snap-in.
3. In the Add or Remove Snap-ins dialog box, select Group Policy Object Editor, and
then select Add.
4. Select Finish.
5. Select OK.
6. Select Local Computer Policy > Computer Configuration > Policies > Windows
Settings > Security Settings > Local Policies, and then select Security Options.
7. Right-click Network security: LDAP client signing requirements, and then select
Properties.
8. In the Network security: LDAP client signing requirements Properties dialog box,
select Require signing in the list, and then select OK.
9. In the Confirm Setting Change dialog box, select Yes.

How to set the client LDAP signing requirement by using a domain

Group Policy Object
1. Select Start > Run, type mmc.exe, and then select OK.
2. Select File > Add/Remove Snap-in.
3. In the Add or Remove Snap-ins dialog box, select Group Policy Object Editor, and
then select Add.
4. Select Browse, and then select Default Domain Policy (or the Group Policy Object
for which you want to enable client LDAP signing).
5. Select OK.
6. Select Finish.
7. Select Close.
8. Select OK.
9. Select Default Domain Policy > Computer Configuration > Windows Settings >
Security Settings > Local Policies, and then select Security Options.
10. In the Network security: LDAP client signing requirements Properties dialog box,
select Require signing in the list, and then select OK.
11. In the Confirm Setting Change dialog box, select Yes.
How to set the client LDAP signing requirement by using registry
keys

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

By default, for Active Directory Lightweight Directory Services (AD LDS), the registry key
is not available. Therefore, you must create a LDAPServerIntegrity registry entry of the
REG_DWORD type under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters

７ Note

The placeholder <InstanceName> represents the name of the AD LDS instance that
you want to change.

The registry entry has the following possible values:

0: Signing is disabled.
2: Signing is enabled.

When you change this value, the new value takes effect immediately. You don't have to
restart the computer.

How to verify configuration changes

1. Sign in to a computer that has the AD DS Admin Tools installed.

2. Select Start > Run, type ldp.exe, and then select OK.

3. Select Connection > Connect.

4. In Server and in Port, type the server name and the non-SSL/TLS port of your
directory server, and then select OK.

７ Note
 For an Active Directory Domain Controller, the applicable port is 389.

5. After a connection is established, select Connection > Bind.

6. Under Bind type, select Simple bind.

7. Type the user name and password, and then select OK.

If you receive the following error message, you have successfully configured your
directory server:

Ldap_simple_bind_s() failed: Strong Authentication Required

Event reference for LDAP signing requirements

Event ID 2886
After starting DS services, Event ID 2886 is logged to remind administrators to enable
signing requirements:

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2886
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
Description:
The security of this directory server can be significantly enhanced by
configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest)
LDAP binds that do not request signing (integrity verification) and LDAP
simple binds that are performed on a clear text (non-SSL/TLS-encrypted)
connection. Even if no clients are using such binds, configuring the server
to reject them will improve the security of this server.

Some clients may currently be relying on unsigned SASL binds or LDAP simple
binds over a non-SSL/TLS connection, and will stop working if this
configuration change is made. To assist in identifying these clients, if
such binds occur this directory server will log a summary event once every
24 hours indicating how many such binds occurred. You are encouraged to
configure those clients to not use such binds. Once no such events are
observed for an extended period, it is recommended that you configure the
server to reject such binds.

For more details and information on how to make this configuration change to
the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.
 You can enable additional logging to log an event each time a client makes
such a bind, including information on which client made the bind. To do so,
please raise the setting for the "LDAP Interface Events" event logging
category to level 2 or higher.

Event ID 2887
When a problem client is detected but permitted, a summary event (Event ID 2887) of
the past 24 hours is logged:

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2887
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
Description:
During the previous 24 hour period, some clients attempted to perform LDAP
binds that were either:
(1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not
request signing (integrity validation), or
(2) A LDAP simple bind that was performed on a clear text (non-SSL/TLS-
encrypted) connection

This directory server is not currently configured to reject such binds. The
security of this directory server can be significantly enhanced by
configuring the server to reject such binds. For more details and
information on how to make this configuration change to the server, please
see http://go.microsoft.com/fwlink/?LinkID=87923.

Summary information on the number of these binds received within the past 24
hours is below.

You can enable additional logging to log an event each time a client makes
such a bind, including information on which client made the bind. To do so,
please raise the setting for the "LDAP Interface Events" event logging
category to level 2 or higher.

Number of simple binds performed without SSL/TLS: <count of binds>

Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing:
<count of binds>

Event ID 2888
When a problem client is rejected, a summary event (Event ID 2888) of the past 24 hours
is logged:
 Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2888
Task Category: LDAP Interface
Level: Information
Keywords: Classic
Description:
During the previous 24 hour period, some clients attempted to perform LDAP
binds that were either:
(1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not
request signing (integrity validation), or
(2) A LDAP simple bind that was performed on a clear text (non-SSL/TLS-
encrypted) connection

This directory server is configured to reject such binds. This is the

recommended configuration setting, and significantly enhances the security
of this server. For more details, please see
http://go.microsoft.com/fwlink/?LinkID=87923.

Summary information on the number of such binds received within the past 24
hours is below.

You can enable additional logging to log an event each time a client makes
such a bind, including information on which client made the bind. To do so,
please raise the setting for the "LDAP Interface Events" event logging
category to level 2 or higher.

Number of simple binds rejected because they were performed without SSL/TLS:
<count of binds>
Number of Negotiate/Kerberos/NTLM/Digest binds rejected because they were
performed without signing: <count of binds>

Event ID 2889
When a problem client tries to connect, Event ID 2889 is logged:

Output

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2889
Task Category: LDAP Interface
Level: Information
Keywords: Classic
Description:
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP
bind without requesting signing (integrity verification), or performed a
simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
 Client IP address:
<IP address>:<TCP port>
Identity the client attempted to authenticate as:
contoso\<username>
Binding Type:
0 – Simple Bind that does not support signing
1 – SASL Bind that does not use signing

References
ADV190023: Microsoft Guidance for Enabling LDAP Channel Binding and LDAP
Signing
2020 LDAP channel binding and LDAP signing requirement for Windows
2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for
Windows (KB4520412)
How to configure Active Directory and LDS diagnostic event logging

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to turn on debug logging of the
LDAP client (Wldap32.dll)
Article • 02/19/2024

This article describes how to turn on debug logging of the LDAP client (Wldap32.dll).

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Window 10 - all editions
Original KB number: 325616

Summary
In Windows Vista and newer versions of Windows, you can use Event Tracing for
Windows (ETW) to trace LDAP client activity, including encrypted (TLS or SASL) activity.

More information
To turn on LDAP client tracing, follow these steps:

1. Create the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap\Tracing\

<ProcessName>

７ Note

In this subkey, <ProcessName> is the full name of the process that you want
to trace, including its extension. For example: "ldp.exe." Inside this subkey, you
can place an optional entry that is named "PID" and that has a DWORD value.
If you set the value to a process ID, only the instance of the application that
has this process ID will be traced.

） Important

If you don't have such a registry subkey for at least one process, the trace file
will not contain data.

2. To start a tracing session, run the following command at a command prompt:

 Console

logman create trace "ds_ds" -ow -o c:\ds_ds.etl -p "Microsoft-Windows-

LDAP-Client" 0x1a59afa3 0xff -nb 16 16 -bs 1024 -mode Circular -f
bincirc -max 4096 -ets

７ Note

In this command, "0x1a59afa3" is a trace flag. Such flags control what information
gets recorded, and the verbosity of data. You can use individual flags or combine
bit values to specify multiple flags simultaneously. For common tracing scenarios,
the following flag combinations are useful:

0x1A59AFA3. Log settings that should get the information that you
require most of the time.
0x18180380. Get information specifically on connection establishment
problems.
0x1bddbf73. Verbose session information.

For information about the available flags, see the "Values for trace flags"
section of "Using ETW to troubleshoot LDAP connections."

3. Reproduce the behavior that you want to investigate.

4. To stop the tracing session, run the following command:

Console

logman stop "ds_ds" -ets

To view the trace as text, use the netsh tool to decode the ETL file as a .txt file, as
follows:

Console

netsh trace convert input=c:\ds_ds.etl output=LDAP_CLIENT-formatted.txt

For more information about netsh trace convert , see the netsh trace convert help. To
do this, enter netsh trace convert /? at the command prompt.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

LDAP Paged Queries with subordinate
referrals are not chased properly
Article • 02/19/2024

This article provides some approaches to avoid the problem that LDAP Paged Queries
with subordinate referrals are not chased properly.

Applies to: Windows 8

Original KB number: 2561166

Symptoms
You have an application that searches the Active Directory with paged searches using
ldap_search_ext or ldap_search_ext_s, and it is set to chase referrals. When it searches off
the root of a domain NC, the paged searches end prematurely after the first page.

In the application, the paged cookie it receives is empty and thus the application ends
the query. In a network trace, you can verify that the paged query does return a non-
empty cookie along with one or more referrals. Most queries will see no result set when
chasing the referral, as often the objects searched for in the domain NC do not exist in
the subordinate NCs, unless they are also domain NCs.

The application may also receive an "operational error" after the first page.

A Domain Controller returns subordinate referrals for the following naming contexts:

1. When Searching the Forest root: Configuration NC (followed by a referral for the
Schema NC)
2. When Searching the Forest root: ForestDnsZones NC
3. DomainDnsZones NC
4. All child domains. And recursively all grand-child domains down the whole domain
tree.

Cause
There are multiple problems when chasing referrals during a paged query:

1. When chasing naming contexts that are located on the same server (see 1., and
maybe 2. and 3. above), the chasing is happening on the same LDAP session,
wiping the paged cookie returned in the primary query in the client LDAP runtime.
 2. When the last referral chased also exceeds the page size, the referral cookie
received from the last NC chased is used to continue the primary search. This
causes the LDAP search to fail with an "operational error" as the cookie does not fit
the server knowledge about the index and index position of the search.
3. When the primary search is done using a simple bind without SSL, the chasing of
the referrals fails with "operational error", because the LDAP client is designed to
not send the clear-text credentials when chasing referrals.

Resolution
There is currently no resolution for the problem.

You can use the following approaches in your application to avoid the problems:

1. Use a base DN that avoids that the server returns subordinate referrals, for
example, search an OU under the domain root object.
2. Search the Global Catalog instead of the forest root domain NC. You need to
ensure all attributes you want are present in the GC, and that you really want the
whole forest instead of the domain tree you searched previously.
3. If you don't want the referrals to be chased automatically: As referrals are chased
by default, use ldap_set_option with flag LDAP_OPT_REFERRALS to turn off referral
chasing. You can always chase the referrals manually after completing the primary
query.
4. Use the control LDAP_SERVER_DOMAIN_SCOPE_OID when searching, it turns off
continuation referrals when searching domain roots.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

When you run an LDAP query against a
domain controller, you obtain a partial
attribute list
Article • 02/19/2024

This article provides workarounds for the issue when you run an LDAP query against a
domain controller, you obtain a partial attribute list.

Applies to: Windows Server 2012 R2

Original KB number: 976063

Symptoms
When you run a Lightweight Directory Access Protocol (LDAP) request against a
Windows Server 2008-based domain controller, you obtain a partial attribute list.
However, if you run the same LDAP query against a Windows Server 2003-based domain
controller, you obtain a full attribute list in the response.

７ Note

You can run this query from the domain controller or from a client computer that is
running Windows Vista or Windows Server 2008.

The user account that you use to run the LDAP query has the following properties:

The account is a member of the built-in Administrators group.

The account is not the built-in administrator account.
The account is a member of the Domain Admins group.
The discretionary access control list (DACL) of the user object contains full control
permission for the Administrators group.
The effective permissions of the object that you query against shows that the user
has full control permission.

Cause
This issue occurs because the Admin Approval Mode (AAM) feature is enabled for the
user account in Windows Vista and in Windows Server 2008. It is also known as "User
Account Control" (UAC). For local resource access, the security system has a loopback
code so it uses the active Access Token from the interactive logon session for the LDAP
session and the access checks during the LDAP query processing.

For more information about the AAM feature, visit the following Microsoft TechNet Web
site: https://technet.microsoft.com/library/cc772207(WS.10).aspx

Workaround
To work around this issue, use one of the following methods.

Method 1
1. Use the Run as administrator option to open a Command Prompt window.
2. Run the LDAP query in the Command Prompt window.

Method 2
Specify the No prompt value for the following security setting:
User Account Control: Behavior of the elevation prompt for administrators in Admin
Approval Mode
For more information about how to specify the value of this security setting, visit the
following Microsoft TechNet Web site:
https://technet.microsoft.com/library/cc772207(WS.10).aspx

Method 3
1. Create a new group in the domain.
2. Add the Domain Admins group to this new group.
3. Grant the Read permission on the domain partition to this new group. To do this,
follow these steps:
a. Click Start, click Run, type adsiedit.msc, and then click OK.
b. In the ADSI Edit window, right-click DC=<Name>,DC=com, and then click
Properties.
c. In the Properties window, click the Security tab.
d. On the Security tab, click Add.
e. Under Enter the object names to select, type the name of the new group, and
then click OK.
f. Make sure that the group is selected under Group or user names, click to select
Allow for the Read permission, and then click OK.
g. Close the ADSI Edit window.
 4. Run the LDAP query again.

Status
This behavior is by design.

More information
By default, the AAM feature is disabled for the built-in administrator account in
Windows Vista and in Windows Server 2008. Additionally, the AAM feature is enabled
for other accounts that are members of the built-in Administrators group.

To verify this, run the following command in a Command Prompt window.

whoami /all

If the AAM feature is enabled for the user account, the output resembles the following.

USER INFORMATION
----------------

User Name SID

============== ==============================================
MyDomain\MyUser S-1-5-21-2146773085-903363285-719344707-326360

GROUP INFORMATION
-----------------

Group Name Type SID Attributes

============================================= ================
=================================================
===============================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default,
Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only

The built-in Administrators group has the following attribute:

 Group used for deny only

The "Domain Admins" group is shown as enabled group with "Mandatory group,
Enabled by default, Enabled group" in whoami /all, but really is disabled for Allow ACEs.
This is a known problem in Windows Server 2008 R2 and Windows Server 2012.

Based on this output, the user account that you used to run the LDAP query has the
AAM feature enabled. When you run the LDAP query, you use a filtered access token
instead of a full access token. Even if full control permission for the Administrators
group is granted to the user object, you still do not have full control permission.
Therefore, you obtain only a partial attribute list.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

New sessions setup for LDAP services
take longer than expected if targeting
host names
Article • 02/19/2024

This article discusses a problem in which a new session setup for LDAP services takes
longer than expected if it targets host names.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows 10 – all editions
Original KB number: 4559609

Symptoms
Lightweight Directory Access Protocol (LDAP) queries that target host names randomly
take longer than expected to respond.

Additionally, DNS client events such as the following may be logged In the event log:

Log Name: System

Source: Microsoft-Windows-DNS-Client
Event ID: 1014
Level: Warning
User: NETWORK SERVICE
Description:
Name resolution for the name _ldap._tcp.<site>._sites.<name> timed out after none
of the configured DNS servers responded.

７ Note

In this log entry, the <name> parameter can be any of the following:

Domain NETBIOS name

Domain Controller host name
Domain Controller DNS FQDN host name

This problem causes multiple issues that affect administrators, users, and applications.
These issues include but aren't limited to the following:
 An LDAP connection against Windows Server 2008 R2 domain controllers (DCs) or
later version DCs takes about six seconds. The same connections against Windows
Server 2003 or Windows Server 2008 DCs usually takes less than one second.
When this occurs, the subsequent LDAP operations, such as bind and LDAP
searches, appear to have no additional delay after the initial LDAP connect.
The LDIFDE.EXE command is slow regardless of whether the/Sparameter is used.
The Microsoft System Center Active Directory Management Pack (SCOM ADMP)
health check script (AD_General_Response.vbs) experiences slow run times.
Microsoft Active Directory Users and Computers (ADUC) is slow to start or slow to
open OU containers. Extensions in the Active Directory Users and Computers snap-
in, DSA.MSC, uses the DC FQDN computer name as a domain name.
Microsoft Active Directory Administrative Center (ADAC) Extensions in the Active
Directory Administrative Center use the DC FQDN computer name as a domain
name.
Microsoft Group Policy Management Console (GPMC) doesn't consistently use
name resolution flags.
Visual Basic Script (VBS) scripts that make LDAP calls that reference the DC fully
qualified DNS name are slow to run.
.NET Framework applications that use System.DirectoryServices and
System.DirectoryServices.Protocols may experience delays when they create
server sessions.

Cause
Starting in Windows 7 and Windows Server 2008 R2, Windows introduced a change in
name lookup behavior to fix two earlier problem scenarios:

LDAP clients fall back to NTLM whenever the NetBIOS domain name is supplied as
the host name in the LDAP connection.
LDAP clients don't connect to a DC in the domain if a client has the same name as
the targeted NetBIOS domain name.

The delay occurs because one of the following two conditions is true:

You encounter a long wait time for a broadcast response. You don't see this delay
if NetBIOS over TCP/IP (NetBT) name resolution through broadcasts is turned off.
Delays in the DNS name resolution occur as the application queries for several
DNS names that don't exist.

The delays can be observed in a network trace that shows LDAP clients running NetBIOS
name lookups for a "[HOSTNAME]<0x1C>" record before they run a DNS lookup to
locate the application host computer (see Figure A).
Figure A

The network trace of a Windows Server 2003 or 2008 LDAP client showed that it directly
ran the DNS lookup for the host computer without performing the NetBIOS lookup for
the "<0x1C>" record.

Figure B

In the case of DNS, you see name queries for names that end in a DC computer name,
such as the following:

_ldap._tcp.Default-First-Site-Name._sites.ADDC01.contoso.com
_ldap._tcp.ADDC01.contoso.com
_ldap._tcp.Default-First-Site-Name._sites.ADDC01
_ldap._tcp.ADDC01

Resolution
When you target an LDAP server by host name instead of domain name, you should use
the LDAP_OPT_AREC_EXCLUSIVE session option to indicate that the target is a host
name instead of a domain name.
This option is set differently depending on the programming interface that is used. Use
the following information as reference.

Wldap32
If an Active Directory DNS server name is passed for theHostNameparameter,
ldap_set_option should be called to set the LDAP_OPT_AREC_EXCLUSIVE flag before
calling any LDAP function that creates the actual connection.

Doing this forces an A-record lookup and bypasses any SRV record lookup when the
computer resolves the host name. In some scenarios, it improves network performance.
For example, in a branch office that uses a dial-up connection, using A-Record lookup
can avoid forcing the dialup to query a remote DNS server for SRV records when it
resolves names.

ADSI
If you must specify a server, use the ADS_SERVER_BIND flag to avoid unnecessary or
incorrect queries to the DNS server. For more information, see this documentation of
ADsOpenObject() and related functions.

System.DirectoryServices
If your ADsPath includes a server name, specify the AuthenticationTypes.ServerBind
flag when you use the LDAP provider. Don't use this flag for paths that include a domain
name or for serverless paths. Specifying a server name without also specifying this flag
causes unnecessary network traffic.

For example:

DirectoryEntry ent = new

DirectoryEntry("LDAP://server01",null,null,AuthenticationTypes.ServerBind);

System.DirectoryServices.Protocols
When you prepare a new LDAP connection, include an LdapDirectoryIdentifier object
that is constructed by using a host name and optional port that you want to contact,
and also includes a <fullyQualifiedDnsHostName> parameter that is set to True.

The new default behavior in Windows 7, Windows Server 2008 R2, and later versions can
be reverted to pre-Windows 7 behavior. This may reintroduce problems that affect
NetBIOS names as described in the "Cause" section. However, there are also scenarios in
which the Pre-Windows 7 behavior provides better results. Therefore, which setting
produces the better results depends on the main LDAP client use scenario.

The long-term solution should always be to get the application to use server and
domain names that have the appropriate flags when calling into LDAP, ADSI, or .NET
interfaces. You should use the correct flags to make the application independent from
scenario dependencies when the directory services client code has to decide the
resolution method in ambiguous situations.

You can revert to pre-Windows 7 behavior by setting the following registry value:

Subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
Entry: UseOldHostResolutionOrder
Type: REG_DWORD
Value data: 1

As an additional approach, you can turn off name resolution by using broadcasting for
NetBt. See 819108 Settings for minimizing periodic WAN traffic to configure
NodeType as "p-mode."

Configuration for nodes

Use 0x00000008 for hybrid node or h-node
Use 0x00000004 for mixed node or m-node
Use 0x00000002 for point-to-point WINS or p-node
Use 0x00000001 for broadcast node or b-node

Name resolution node types

B-Node (broadcasting): Uses broadcasts to resolve names. (Not recommended for
larger networks.)
P-Node (peer to peer): Uses WINS only, no broadcasts. No WINS server, no
resolution.
M-Node (mixed): Broadcast first, then WINS. (Not recommended because you
want to minimize broadcasts.)
H-Node (hybrid) - uses WINS first, then broadcasts. (Recommended because it
reduces the number of broadcasts by trying WINS first and resorting to
broadcasting only as last resort.)

References
For more information, see the following articles:

Ldap_init function

LDAP session options (see LDAP_OPT_AREC_EXCLUSIVE, 0x98)

ADSI function AdsopenObject

ADSI AuthenticationEnum with the ADS_SERVER_BIND value

S.DS AuthenticationTypes Enum with the ServerBind value

S.DS.P LdapDirectoryIdentifier constructor with the fullyQualifiedDnsHostName flag

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 36884 when you try to connect
to an LDAPS server
Article • 02/19/2024

This article introduces how to troubleshoot the event ID 36884 issue that occurs when
you try to build a Lightweight Directory Access Protocol (LDAP) connection.

Issue scenario and event log

Consider the following scenario:

You installed a certificate on an LDAPS connection point.

The certificate has the following characteristics:
Subject: ldap.contoso.com
Subject Alternate Name (SAN): ldap.contoso.com
In the DNS server, you have the following entries:
ldap.contoso.com CNAME myldapserver.contoso.com
myldapserver.contoso.com HOST 10.0.0.1

When you try to connect to the LDAPS connection point, the connection is dropped,
and you receive event ID 36884.

Output

Log Name: System

Source: Schannel
Date: <date_and_time>
Event ID: 36884
Task Category: None
Level: Error
Keywords:
User: CONTOSO\<user_name>
Computer: <computer_name>
Description:
The certificate received from the remote server does not contain the
expected name. It is therefore not possible to determine whether we are
connecting to the correct server. The server name we were expecting is
<computer_name>. The TLS connection request has failed. The attached data
contains the server certificate.
The SSPI client process is ldp (PID: 5148).

Cause
LDAPS is looking for myldapserver.contoso.com to be associated with it. However,
myldapserver.contoso.com isn't covered by the SAN entries. Therefore, a server name
match isn't made, and the connection is dropped.

How to fix the issue

To fix this issue, use one of the following solutions:

Use extra SAN(s) to cover the resolved HOST names on the certificate.

Use a HOST record in DNS instead of the CNAME record.

Configure the following registry value on the client to use the CNAME for the
server name comparison.

） Important

This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
protection, back up the registry before you modify it so that you can restore it
if a problem occurs. For more information about how to back up and restore
the registry, see How to back up and restore the registry in Windows .

1. Start Registry Editor.

2. Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP

3. Create a new REG_DWORD value that is named UseHostnameAsAlias, and

set the value to anything other than zero.
4. Exit Registry Editor, and then restart the computer.

After the registry value is configured, the client computer uses ldap.contoso.com
to make the match. It's covered by the certificate SANs, so the connection is
allowed.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot LDAP over SSL connection
problems
Article • 02/19/2024

This article discusses steps about how to troubleshoot LDAP over SSL (LDAPS)
connection problems.

Applies to: Windows Server 2003

Original KB number: 938703

Step 1: Verify the Server Authentication

certificate
Make sure that the Server Authentication certificate that you use meets the following
requirements:

The Active Directory fully qualified domain name of the domain controller appears
in one of the following locations:
The common name (CN) in the Subject field.
The Subject Alternative Name (SAN) extension in the DNS entry.

The enhanced key usage extension includes the Server Authentication object
identifier (1.3.6.1.5.5.7.3.1).

The associated private key is available on the domain controller. To verify that the
key is available, use the certutil -verifykeys command.

The certificate chain is valid on the client computer. To determine whether the
certificate is valid, follow these steps:

1. On the domain controller, use the Certificates snap-in to export the SSL
certificate to a file that is named Serverssl.cer.

2. Copy the Serverssl.cer file to the client computer.

3. On the client computer, open a Command Prompt window.

4. At the command prompt, type the following command to send the command
output to a file that is named Output.txt:

Console
 certutil -v -urlfetch -verify serverssl.cer > output.txt

７ Note

To follow this step, you must have the Certutil command-line tool
installed.

5. Open the Output.txt file, and then search for errors.

Step 2: Verify the Client Authentication

certificate
In some cases, LDAPS uses a Client Authentication certificate if it is available on the
client computer. If such a certificate is available, make sure that the certificate meets the
following requirements:

The enhanced key usage extension includes the Client Authentication object
identifier (1.3.6.1.5.5.7.3.2).

The associated private key is available on the client computer. To verify that the key
is available, use the certutil -verifykeys command.

The certificate chain is valid on the domain controller. To determine whether the
certificate is valid, follow these steps:

1. On the client computer, use the Certificates snap-in to export the SSL
certificate to a file that is named Clientssl.cer.

2. Copy the Clientssl.cer file to the server.

3. On the server, open a Command Prompt window.

4. At the command prompt, type the following command to send the command
output to a file that is named Outputclient.txt:

Console

certutil -v -urlfetch -verify serverssl.cer > outputclient.txt

5. Open the Outputclient.txt file, and then search for errors.

Step 3: Check for multiple SSL certificates
Determine whether multiple SSL certificates meet the requirements that are described in
step 1. Schannel (the Microsoft SSL provider) selects the first valid certificate that
Schannel finds in the Local Computer store. If multiple valid certificates are available in
the Local Computer store, Schannel may not select the correct certificate. A conflict with
a certification authority (CA) certificate may occur if the CA is installed on a domain
controller that you are trying to access through LDAPS.

Step 4: Verify the LDAPS connection on the

server
Use the Ldp.exe tool on the domain controller to try to connect to the server by using
port 636. If you cannot connect to the server by using port 636, see the errors that
Ldp.exe generates. Also, view the Event Viewer logs to find errors. For more information
about how to use Ldp.exe to connect to port 636, see How to enable LDAP over SSL
with a third-party certification authority .

Step 5: Enable Schannel logging

Enable Schannel event logging on the server and on the client computer. For more
information about how to enable Schannel event logging, see How to enable Schannel
event logging in Windows and Windows Server .

７ Note

If you have to perform SSL debugging on a computer that is running Microsoft

Windows NT 4.0, you must use a Schannel.dll file for the installed Windows NT 4.0
service pack and then connect a debugger to the computer. Schannel logging only
sends output to a debugger in Windows NT 4.0.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

LDAP session security settings and
requirements after ADV190023 is
installed
Article • 02/19/2024

This article discusses LDAP session security settings and requirements after security
advisory ADV190023 is installed.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4563239

Summary
This article introduces the functional changes that are provided by security advisory
ADV190023 . Additionally, this article describes the security settings for each kind of
Lightweight Directory Access Protocol (LDAP) session, and what is required to operate
the LDAP sessions in a secure way.

ADV190023 discusses settings for both LDAP session signing and additional client
security context verification (Channel Binding Token, CBT). In the implementation, there
are two separate items:

LDAPServerIntegrity and events logged on Domain Controllers

LdapEnforceChannelBinding and events logged on Domain Controllers.

When you determine the best path to improve security according to ADV190023, there
may be actions needed by application owners in both areas. However, the settings and
requirements to meet them are different. It's also quite possible that a solution for both
topics consists in a single change. For example, by moving from simple bind to SASL
using Kerberos or TLS with simple bind.

The new Channel Binding Token (CBT) option is the LDAP TLS implementation of the
Extended Protection for Authentication (EPA) scheme that is described in RFC 5056.

７ Note

"EPA" and "CBT" can be used interchangeably in this context.

More information
The method by which LDAP session security is handled depends on which protocol and
authentication options are chosen. There are several possible session options:

Sessions on ports 389 or 3268 or on custom LDS ports that don't use TLS/SSL for a
simple bind: There's no security for these sessions. This is because credentials are
transmitted in clear text. Therefore, there's no secure key material to provide
protection. These sessions should be disabled by setting LDAPServerIntegrity to
Required.
Sessions on ports 389 or 3268 or on custom LDS ports that don't use TLS/SSL for a
Simple Authentication and Security Layer (SASL) bind.
Sessions that use TLS/SSL by using a predetermined port (636, 3269, or a custom
LDS port), or standard ports (389, 3268, or a custom LDS port) that use the
STARTTLS extended operation.

LDAP sessions not using TLS/SSL, binding by using SASL

If LDAP sessions are signed or encrypted by using an SASL logon, the sessions are
secure from Man-In-the-Middle (MITM) attacks. This is because you can obtain the
signing keys only if you know the user password. You don't have to have Extended
Protection for Authentication (EPA) information.

The SASL method that is chosen may have its own attack vectors, such as NTLMv1. But
the LDAP session itself is secure. If you're using Kerberos AES 256-bit encryption, that is
as good as it gets in 2020. The following policy guidelines apply:

The LDAPServerIntegrity=2 setting is important for this session option because it

enforces the use of signing by the client. When you encrypt the sessions, this
requirement is also met.
The LdapEnforceChannelBinding setting has no bearing on this session option.

LDAP sessions using TLS/SSL and simple bind for user

authentication
There's no CBT information added for these sessions. The quality of the TLS client
implementation governs whether the client can detect an MITM attack (through server
certificate name checking, verification of CRL, and so on).

The following policy guidelines apply:

 The requirement for LDAPServerIntegrity is met because the TLS channel provides
signing. The level of security that the TLS channel provides depends on the TLS
client implementation.
The LdapEnforceChannelBinding setting has no bearing on this session option.

LDAP sessions using TLS/SSL, binding by using certificate

for user authentication
Currently, there's no CBT information added for these sessions. The quality of the TLS
client implementation governs whether the client can detect an MITM attack (through
server certificate name checking, verification of CRL, and so on). Client certificate
authentication is sufficient to block MITM attacks, but it doesn't prevent other
categories of attacks that can be mitigated only by appropriate client-side validation of
the TLS certificate that is presented by the server.

The following policy guidelines apply:

The requirement for LDAPServerIntegrity is met because the TLS channel provides
signing. The level of security that the TLS channel provides depends on the TLS
client implementation.
The LdapEnforceChannelBinding setting has no bearing on this session option.

LDAP Sessions using TLS/SSL, binding with SASL for user

authentication
In this scenario, TLS provides the session security for encryption, and the encryption
keys are based on the server certificate. Specifically for SASL authentication that uses
NTLM, the NTLM authentication data may have been relayed from the session that was
held by the MITM attacker. In the case of such an attack, there's no proof that the client
has a valid password hash. The CBT information is protected against tampering through
signing or encryption (depending on the authentication protocol) by using a session key
that can be obtained only by knowing the user's or server's credentials. The MITM
attacker wouldn't have this password hash if it intercepted an NTLM authentication.

The following policy guidelines apply:

The LdapEnforceChannelBinding setting is used for this session option. When you
set this value to 2, the LDAP server requires CBT information (equivalent to EPA),
and it's required to pass verification.
The requirement for LDAPServerIntegrity is met because the TLS channel provides
signing. The level of security that it provides depends on the TLS client
 implementation and whether CBT is required.

References
For more information, see the following articles:

Extended Protection for Authentication

Control Extended Protection for Authentication using Security Policy
Supporting Extended Protection for Authentication (EPA) in a service

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How Domain Controllers respond to
LDAP Ping on UDP 138 port
Article • 02/19/2024

This article describes how to make domain controllers to reply to LDAP Ping.

Applies to: Windows Server 2012 R2

Original KB number: 3088277

Symptoms
Consider the following scenario:

LMHOSTS file on Windows Server does not contain client hostname.

WINS server is not configured on Windows Server, or WINS server does not resolve
client hostname.
Windows Server and client are in another network segment.

In this scenario, Windows Server 2008 or later OS doesn't respond to LDAP Ping (UDP
138 port) from client machine.

More information
In Windows Server 2003 or older, Windows Server operating systems reply to LDAP Ping
on UDP 138 port from client, the behavior however changed since Windows Server
2008.

To make Windows Server 2008 or later to reply to LDAP Ping, configure either of the
following settings.

(A) Add LMHOSTS

1. Move to %windir%\system32\drivers\etc folder

2. Add IP address and hostname of client to LMHOSTS file.

(B) Add WINS server

Configure TCP/IP to use WINS server that can resolve client hostname to Windows
Server.

Configure TCP/IP to use WINS

(C) Place Windows Servers and client machines in the same segment.

Windows Server resolves client hostname by using NetBIOS broadcast if Windows

Server and clients are on the same subnet.

Note: DNS is the primary method of resolving name queries in Active Directory starting
with Windows Server 2000 and including Windows Server 2003, Windows Server 2008,
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 and beyond.

References
For more information on DCLOCATOR, see:

Domain Controller Locator

Domain Controller Location Process
Domain Locator Across a Forest Trust
How DNS support for Active Directory works

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use the online dbdump feature
of Active Directory
Article • 02/19/2024

This article describes how to use the online dbdump feature of Active Directory.

Applies to: Windows Server 2012 R2

Original KB number: 315098

Summary
You can use the online dbdump feature in Ldp.exe to view the values that are stored in
the database while a domain controller is running. You trigger the online dbdump
feature by modifying the dumpDatabase attribute on the rootDSA.

The values that you specify for this attribute are the attributes other than the default
attributes that you want to dump. The values that you specify are the name for this
attribute. The dumpDatabase feature first checks that you have enough rights for
dumping the database. It then dumps the database into the Ntds.dmp file. The
Ntds.dmp file is located in the same folder as the database file (.dit). The default
attributes are:

DNT
PDNT
OBJ
RDNTyp
CNT
ABCNT
DelTime
NCDNT
ABVis

Usage example: Investigate an SPN issue with

conflicting CNF or deleted DEL attributes
To create the Ntds.dmp file, follow these steps:

1. Start Ldp.exe on the domain controller that is logging the NTDS event 1645.

2. Connect locally, and then bind as an Enterprise administrator.

 3. Click Modify on the Browse menu.

4. Edit for Attribute: dumpdatabase.

5. Edit for Values: name ncname objectclass objectguid instancetype. You must leave
one space between the attributes.

6. Click Enter. The Entry List box contains the following entry:
[Add]dumpdatabase: name ncname objectclass objectguid instancetype

7. Click the Extended and Run options.

8. The %systemroot%\NTDS\Ntds.dmp file is created, or you receive an error

message in Ldp.exe that you must investigate.

You can also get this triggered by using an LDIFDE import file dump-db.txt like:

Dn:
Changetype: modify
Add: dumpdatabase
Dumpdatabase: name ncname objectclass objectguid instancetype
-

To import the file with LDIFDE, use a command line like ldifde /s \<targetserver> /i
/f dump-db.txt .

Use the output

The Ntds.dmp file is a text file. Look for the conflicting or deleted GUID that was
reported in event 1645 to see the internal reference mismatch.

Sample Dump File

The following sample shows that the CROSSREF object for domain PDT is pointing to a
wrong object that has already been deleted:

3953 2326 true 3 1 0 - 1163 - 4

3947 196619 56.6E.52.8A.2E.B4.00.43.BE.B1.B3.57.91.AD.F5.BE PDT
...
3947 1161 false 1376281 2 0 2001-08-04 11:02.47 - -
- - - 9E.4C.AB.36.81.65.2B.4F.A0.31.59.D5.C2.74.68.F2 pdt
DEL:36ab4c9e-6581-4f2b-a031-59d5c27468f2
 ...
3958 1161 false 1376281 3 0 2001-08-04 23:02.47 - -
- - - 85.0B.3B.A1.EC.68.37.46.9E.D0.FF.F6.66.BA.FB.84 pdt

The internal reference points to 3947, although it should point to the new 3958 object
for dc=pdt,dc=net.

You may resolve this issue with the semantic checker of the latest version of the
Ntdsutil.exe tool.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

View and set LDAP policy in Active
Directory by using Ntdsutil.exe
Article • 02/19/2024

This article describes how to manage Lightweight Directory Access Protocol (LDAP)
policies by using the Ntdsutil.exe tool.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 315071

Summary
To make sure that domain controllers can support service-level guarantees, you must
specify operational limits for many LDAP operations. These limits prevent specific
operations from adversely affecting the performance of the server. They also make the
server more resilient to some types of attacks.

LDAP policies are implemented by using objects of the queryPolicy class. Query Policy
objects can be created in the Query Policies container, which is a child of the Directory
Service container in the configuration naming context. For example, cn=Query-
Policies,cn=Directory Service,cn=Windows NT,cn=Services configuration naming
context.

LDAP administration limits

The LDAP administration limits are:

InitRecvTimeout - This value defines the maximum time in seconds that a domain
controller waits for the client to send the first request after the domain controller
receives a new connection. If the client does not send the first request in this
amount of time, the server disconnects the client.

Default value: 120 seconds

MaxActiveQueries - The maximum number of concurrent LDAP search operations

that are permitted to run at the same time on a domain controller. When this limit
is reached, the LDAP server returns a busy error.

Default value: 20
 ７ Note

This control has an incorrect interaction with the MaxPoolThreads value.

MaxPoolThreads is a per-processor control, while MaxActiveQueries defines
an absolute number. Starting with Windows Server 2003, MaxActiveQueries is
no longer enforced. Additionally, MaxActiveQueries does not appear in the
Windows Server 2003 version of NTDSUTIL.

Default value: 20

MaxConnections - The maximum number of simultaneous LDAP connections that a

domain controller will accept. If a connection comes in after the domain controller
reaches this limit, the domain controller drops another connection.

Default value: 5000

MaxConnIdleTime - The maximum time in seconds that the client can be idle
before the LDAP server closes the connection. If a connection is idle for more than
this time, the LDAP server returns an LDAP disconnect notification.

Default value: 900 seconds

MaxDatagramRecv - The maximum size of a datagram request that a domain

controller will process. Requests that are larger than the value for
MaxDatagramRecv are ignored.

Default value: 4,096 bytes

MaxNotificationPerConnection - The Maximum number of outstanding notification

requests that are permitted on a single connection. When this limit is reached, the
server returns a busy error to any new notification searches that are performed on
that connection.

Default value: 5

MaxPageSize - This value controls the maximum number of objects that are
returned in a single search result, independent of how large each returned object
is. To perform a search where the result might exceed this number of objects, the
client must specify the paged search control. It's to group the returned results in
groups that are no larger than the MaxPageSize value. To summarize, MaxPageSize
controls the number of objects that are returned in a single search result.

Default value: 1,000

MaxPoolThreads - The maximum number of threads per-processor that a domain
controller dedicates to listening for network input or output (I/O). This value also
determines the maximum number of threads per-processor that can work on LDAP
requests at the same time.

Default value: 4 threads per-processor

MaxResultSetSize - Between the individual searches that make up a paged result

search, the domain controller may store intermediate data for the client. The
domain controller stores this data to speed up the next part of the paged result
search. The MaxResultSize value controls the total amount of data that the domain
controller stores for this kind of search. When this limit is reached, the domain
controller discards the oldest of these intermediate results to make room to store
new intermediate results.

Default value: 262,144 bytes

MaxQueryDuration - The maximum time in seconds that a domain controller will

spend on a single search. When this limit is reached, the domain controller returns
a " timeLimitExceeded" error. Searches that require more time must specify the
paged results control.

Default value: 120 seconds

MaxTempTableSize - While a query is processed, the dblayer may try to create a

temporary database table to sort and select intermediate results from. The
MaxTempTableSize limit controls how large this temporary database table can be.
If the temporary database table would contain more objects than the value for
MaxTempTableSize, the dblayer performs a much less efficient parsing of the
complete DS database and of all the objects in the DS database.

Default value: 10,000 records

MaxValRange - This value controls the number of values that are returned for an
attribute of an object, independent of how many attributes that object has, or of
how many objects were in the search result. In Windows 2000, this control is hard-
coded at 1,000. If an attribute has more than the number of values that are
specified by the MaxValRange value, you must use value range controls in LDAP to
retrieve values that exceed the MaxValRange value. MaxValueRange controls the
number of values that are returned on a single attribute on a single object.
Minimum Value: 30
Default value: 1500
Start Ntdsutil.exe
Ntdsutil.exe is located in the Support tools folder on the Windows installation CD-ROM.
By default, Ntdsutil.exe is installed in the System32 folder.

1. Click Start, and then click Run.

2. In the Open text box, type ntdsutil, and then press ENTER. To view help at any time,
type ? at the command prompt.

View current policy settings

1. At the Ntdsutil.exe command prompt, type LDAP policies , and then press ENTER.
2. At the LDAP policy command prompt, type connections , and then press ENTER.
3. At the server connection command prompt, type connect to server <DNS name of
server> , and then press ENTER. You want to connect to the server that you are

currently working with.

4. At the server connection command prompt, type q , and then press ENTER to
return to the previous menu.
5. At the LDAP policy command prompt, type Show Values , and then press ENTER.

A display of the policies as they exist appears.

Modify policy settings

1. At the Ntdsutil.exe command prompt, type LDAP policies , and then press ENTER.

2. At the LDAP policy command prompt, type Set <setting> to <variable> , and then
press ENTER. For example, type Set MaxPoolThreads to 8.

This setting changes if you add another processor to your server.

3. You can use the Show Values command to verify your changes.

To save the changes, use Commit Changes.

4. When you finish, type q , and then press ENTER.

5. To quit Ntdsutil.exe, at the command prompt, type q , and then press ENTER.

７ Note
 This procedure only shows the Default Domain Policy settings. If you apply your
own policy setting, you cannot see it.

Reboot requirement
If you change the values for the query policy that a domain controller is currently using,
those changes take effect without a reboot. However, if a new query policy is created, a
reboot is required for the new query policy to take effect.

Considerations for changing query values

To maintain domain server resiliency, we do not recommend that you increase the
timeout value of 120 seconds. Forming more efficient queries is a preferred solution. For
more information about creating efficient queries, see Creating More Efficient Microsoft
Active Directory-Enabled Applications.

However, if changing the query isn't an option, increase the timeout value only on one
domain controller or only on one site. For instructions, see the next section. If the
setting is applied to one domain controller, reduce the DNS LDAP priority on the
domain controller, so that clients less likely use the server for authentication. On the
domain controller with the increase priority, use the following registry setting to set
LdapSrvPriority :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

On the Edit menu, select Add Value, and then add the following registry value:

Entry name: LdapSrvPriority

Data type: REG_DWORD
Value: Set the value to the value of the priority that you want.

For more information, see How to optimize the location of a domain controller or global
catalog that resides outside of a client's site .

Instructions for configuring per domain

controller or per site policy
1. Create a new query policy under CN=Query-Policies,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration, forest root.
 2. Set the domain controller or site to point to the new policy by entering the
distinguished name of the new policy in the Query-Policy-Object attribute. The
location of the attribute is as follows:

The location for the domain controller is CN=NTDS Settings, CN=

DomainControllerName, CN=Servers,CN= site
name,CN=Sites,CN=Configuration, forest root.

The location for the site is CN=NTDS Site Settings,CN= site

name,CN=Sites,CN=Configuration, forest root.

Sample script
You can use the following text to create a Ldifde file. You can import this file to create
the policy with a timeout value of 10 minutes. Copy this text to Ldappolicy.ldf, and then
run the following command, where forest root is the distinguished name of your forest
root. Leave DC=X as-is. It's a constant that will be replaced by the forest root name
when the script runs. The constant X doesn't indicate a domain controller name.

Console

ldifde -i -f ldappolicy.ldf -v -c DC=X DC= forest root

Start Ldifde script

Output

dn: CN=Extended Timeout,CN=Query-Policies,CN=Directory Service,CN=Windows

NT,CN=Services,CN=Configuration,DC=X
changetype: add
instanceType: 4
lDAPAdminLimits: MaxReceiveBuffer=10485760
lDAPAdminLimits: MaxDatagramRecv=1024
lDAPAdminLimits: MaxPoolThreads=4
lDAPAdminLimits: MaxResultSetSize=262144
lDAPAdminLimits: MaxTempTableSize=10000
lDAPAdminLimits: MaxQueryDuration=300
lDAPAdminLimits: MaxPageSize=1000
lDAPAdminLimits: MaxNotificationPerConn=5
lDAPAdminLimits: MaxActiveQueries=20
lDAPAdminLimits: MaxConnIdleTime=900
lDAPAdminLimits: InitRecvTimeout=120
lDAPAdminLimits: MaxConnections=5000
objectClass: queryPolicy
showInAdvancedViewOnly: TRUE
After you import the file, you can change the query values by using Adsiedit.msc or
Ldp.exe. The MaxQueryDuration setting in this script is 5 minutes.

To link the policy to a DC, use an LDIF import file like this:

Output

dn: CN=NTDS
Settings,CN=DC1,CN=Servers,CN=site1,CN=Sites,CN=Configuration, DC=X
changetype: modify
add: queryPolicyobject
queryPolicyobject: CN=Extended Timeout,CN=Query-Policies,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

Import it by using the following command:

Console

ldifde -i -f link-policy-dc.ldf -v -c DC=X DC= **forest root**

For a site, the LDIF import file would contain:

Output

dn: CN=NTDS Site Settings,CN=site1,CN=Sites,CN=Configuration, DC=X

changetype: modify
add: queryPolicyobject
queryPolicyobject: CN=Extended Timeout,CN=Query-Policies,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

７ Note

Ntdsutil.exe only displays the value in the default query policy. If any custom
policies are defined, they are not displayed by Ntdsutil.exe.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Delays when domain members are
required to communicate to DCs on
remote domains
Article • 02/19/2024

This article provides help to solve the delays that occur when domain members are
required to communicate to DCs on remote domains.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4550655

Symptoms
Assume that you have an Active Directory environment that has one or more forests,
and each forest has one or more domain trees. In this environment, a domain tree is a
DNS name root that is independent of the forest root.

You have member computers in all the domains of all the forests. You also have a
network security policy that limits the communication from your computers to the
servers and peers that are required for the business function of your computers and also
to the users who work with that business function.

In this scenario, you notice that domain members access domain controllers (DCs) in
domains other than the domain that they are a member of. They may access servers that
are different from the server that users log on to. This communication may be restricted
by the firewall rules that you have set.

This activity causes frequent delays and errors when the member computer tries
unsuccessfully to access the server ports of the other domain DCs.

When this problem occurs, you receive an error message that's based on the protocol
that's used, as follows:

RPC: error code 1722 (RPC_S_SERVER_UNAVAILABLE)

LDAP: error code 85 (LDAP_TIMEOUT)
WinSock: error code 10060 (WSAETIMEDOUT)

Analysis and cause

Typically, you would expect the computer and users to primarily use DCs from the same
domain that they are a member of. They may also connect to Global Catalogs for forest-
wide searches in their own forest or in remote forests.

However, domain members sometimes reach outside their own domain. They may do
this based on their configuration. They may also do this after they discover the overall
forest structure and then send requests to all domains that they discovered.

Examples of such communication requirements:

The configuration can be Group Policy settings that are linked to the scope of
policy settings for the domain members. Or, it can be policy settings on the Active
Directory site that the computer is in.

There may be applications that want to search or synchronize objects from all the
domains that they find. For example, the SharePoint topology discovery.

There is also the group of applications that search a domain root object by using LDAP
searches and that allow and receive continuation referrals. This means that they redirect
referrals to all child NCs (application partitions and child domains). Therefore, they
require access to child domain DCs.

The delays that you experience depend on the number of domains, the DCs that are
referenced, and the number of retries that are made by an application. The delay can
take many minutes. Some applications also eventually time out before all the DCs and
domains have returned errors frequently enough. In your analysis, you may see the
original LDAP query marked as successful because they received results from the
domain in which the query was started. However, the query is still delayed because it is
waiting for the referrals to be completed.

Recommendations
Microsoft does not have documentation about how to determine which DCs of any
domain in any forest in the scope of the enterprise are used based on a particular
configuration. There are also no rules to control which DCs can be accessed. This applies
to Windows and all Microsoft applications.

You must expect any domain member to reach out to all DCs of all forests. If you want
to restrict the domain members, you have to use a trial and error approach. If you find
that delays occur because additional DCs are contacted, you have to adopt firewall rules
that allow access to those DCs.
If you are not sure which ports are available or blocked by the firewall, use the PortQry
tool to test the settings. For more information, see New features and functionality in
PortQry version 2.0.

References
ADConnection Overview
LDAP Referrals
Handling and following referrals
Service overview and network port requirements for Windows

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you run the Active Directory
Installation Wizard: The version of the
Active Directory schema of the source
forest is not compatible with the version
of Active Directory on this computer
Article • 02/19/2024

This article provides a solution to an error that occurs when you try to run the Active
Directory Installation Wizard.

Applies to: Window Server 2003

Original KB number: 917385

Symptoms
When you try to run the Active Directory Installation Wizard on a Microsoft Windows
Server 2003 R2 server, the wizard does not finish, and you may receive the following
error message:

The Active Directory Installation Wizard cannot continue because the forest is not
prepared for installing Windows Server 2003. Use the Adprep command-line tool to
prepare both the forest and the domain. For more information about using the
Adprep, see Active Directory Help.

The version of the Active Directory schema of the source forest is not compatible
with the version of Active Directory on this computer.

Cause
This issue may occur when Active Directory has not been updated with the Windows
Server 2003 R2 schema extensions.

Resolution
To resolve this issue, run the adprep.exe /forestprep command from the Windows
Server 2003 R2 installation disk 2 on the schema master. To do this, insert the Windows
Server 2003 R2 installation disk 2, and then type the command:
<Drive>:\CMPNENTS\R2\ADPREP\adprep.exe /forestprep .

More information
The correct version of the ADPrep.exe tool for Windows Server 2003 R2 is 5.2.3790.2075.

You can verify the operating system support level of the schema by looking at the value
of the Schema Version registry subkey on a domain controller. You can find this subkey
in the following location:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

You can also verify the operating system support level of the schema by using the
Adsiedit.exe utility or the Ldp.exe utility to view the objectVersion attribute in the
properties of the cn=schema,cn=configuration,dc= <domain> partition. The value of
the Schema Version registry subkey and the objectVersion attribute are in decimal.

Schema Version ObjectVersion values and corresponding operating system support

level:

13=Microsoft Windows 2000

30=Original release version of Microsoft Windows Server 2003 and Microsoft
Windows Server 2003 Service Pack 1 (SP1)
31=Microsoft Windows Server 2003 R2

Windows Server 2003 R2 installation disks

Windows Server 2003 R2 comes on two installation disks. Installation disk 1 contains a
slip-streamed version of Windows Server 2003 with Service Pack 1 (SP1). Installation disk
2 contains the Windows Server 2003 R2 files. If the computer has Windows Server 2003
SP1 installed, you may only have to run installation disk 2 to upgrade to Windows Server
2003 R2.

Installation disk 2 is specific to the edition of Windows Server 2003. For example, you
must use a Windows Server 2003 R2, Standard Edition installation disk to upgrade a
Windows Server 2003, Standard Edition-based computer. Installation disk 2 contains
installation files for the x86-based version and the x64-based version of Windows Server
2003 R2.

The Adsiedit.exe utility and the Ldp.exe utility are included with Windows Server 2003 R2
support tools. To install support tools, run Suptools.msi from the \Support\Tools folder
on installation disk 1.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Finding the current Schema Version
Article • 02/19/2024

This article describes how to find the current Schema Version. The original author of the
article was Yuval Sinay , Microsoft MVP.

Applies to: Windows Server 2012 R2

Original KB number: 558112

Find the current Active Directory Schema

Version
To find the current Active Directory Schema Version, you can use one of the following
methods:

７ Note

The internal root domain that we use in this demo is contoso.local.

Method 1
1. Use ADSIEdit.msc or LDP.exe to navigate to:
CN=Schema,CN=Configuration,DC=contoso,DC=local.

2. Review the objectVersion attribute.

Method 2
Use the DSQuery command line. Run the following command:

Console

dsquery * "cn=schema,cn=configuration,dc=contoso,dc=local" -scope base -attr

objectVersion

Method 3
Use the Get-ItemProperty PowerShell cmdlet. Run the following command:
 PowerShell

Get-ItemProperty 'AD:\CN=Schema,CN=Configuration,DC=contoso,DC=local' -Name

objectVersion

"objectVersion" attribute to Operating System

The following information provides a mapping between the objectVersion attribute
value and the Active Directory Schema commutability:

ﾉ Expand table

Version Operating System

13 Windows 2000 Server

30 Windows Server 2003 RTM, Windows 2003 Service Pack 1, Windows 2003 Service Pack
2

31 Windows Server 2003 R2

44 Windows Server 2008 RTM

47 Windows Server 2008 R2

56 Windows Server 2012

69 Windows Server 2012 R2

87 Windows Server 2016

88 Windows Server 2019

88 Windows Server 2022

Find the current Exchange Schema Version

To find the current Exchange Schema Version, you can use one of the following
methods:

７ Note

The internal root domain that we use in this demo is contoso.local.

Method 1
1. Use ADSIEdit.msc or LDP.exe to navigate to:
CN=ms-Exch-Schema-Version-Pt,
CN=Schema,CN=Configuration,DC=contoso,DC=local

2. Review the current rangeUpper attribute.

Method 2
Use the DSQuery command line:

Console

dsquery * "CN=ms-Exch-Schema-Version-
Pt,cn=schema,cn=configuration,dc=contoso,dc=local" -scope base -attr
rangeUpper

Method 3
Run the Get-ItemProperty PowerShell cmdlet:

PowerShell

Get-ItemProperty "AD:\CN=ms-Exch-Schema-Version-
Pt,cn=schema,cn=configuration,$((get-addomain).DistinguishedName)" -Name
rangeUpper

Some "rangeUpper" attribute map

The following articles provide a mapping between the rangeUpper attribute value and
the Exchange Schema commutability:

Exchange 2016 Active Directory versions

Exchange 2019 Active Directory versions

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A batch of Event ID 4780 are logged in
the primary domain controller
Article • 02/19/2024

This article helps to resolve the issue in which you see a batch of Event ID 4780 logged
in the primary domain controller (PDC) security event log.

You've changed the audit or system access control list (SACL) of container type objects
(organizational units and containers) in Active Directory where admin users and groups
are located. When you check the security event log, you see a batch of Event ID 4780
logged in the PDC every hour.

Here's an example of Event ID 4780:

Output

Level: Information
Source: Microsoft-Windows-Security-Auditing
Message: The ACL was set on accounts which are members of administrators
groups.

Subject:
Security ID: *No String Type*
Account Name: ANONYMOUS LOGON
Account Domain: NT AUTHORITY
Logon ID: 998

Target Account:
Security ID: *No String Type*
Account Name: <Account Name>
Account Domain: DC=contoso,DC=com

Additional Information:
Privileges: -

The reported accounts are all members of administrator-type groups. They're protected
by the AdminSDHolder task, and the Security Descriptor (SD) is overwritten from the
template SD.

When you inspect the discretionary access control list (DACL) of the reported users, it's
the same as AdminSDHolder DACL and the DACL of admin users that aren't reported in
Event ID 4780.
The SD differs from the template SD of the
AdminSDHolder object
The AdminSDHolder enforcement job runs on the PDC emulator once an hour. The job
builds a list of accounts it protects and ensures the current SD is the same as the
template SD of the AdminSDHolder object on the binary level.

The event is triggered by the different SD. The difference in the SD is in the SACL. The
SACL, by default, has three entries, and the inheritance is enabled.

The inheritance flag means that when the AdminSDHolder enforcement job writes the
SD to enforce AdminSDHolder, the codes merge the SACL written with the SACL of the
parent object. This action may lead to additional system access control entries (SACEs)
on the freshly written SD.

On the next run of the AdminSDHolder enforcement job, the different SACL leads to a
different SD. Then, a new SD will be built and written, but the same happens again. The
new SACL written will differ from the template on the AdminSDHolder object.

Edit the SD of the AdminSDHolder object to

not inherit the SACL

７ Note

There's no resolution in a software update as of October 2022. It's complex to solve

the issue in a software update. The current SACL used by customers may be
suitable for deployment, and the inheritance flag may be set on purpose. You can
ignore Event ID 4780, and we don't recommend clearing the inheritance flag for
existing domains.

If you have problems due to Event ID 4780 and the excessive updates, edit the SD of the
AdminSDHolder object to not inherit the SACL. Select Advanced in the AdminSDHolder
Properties window and select Disable inheritance on the Auditing tab of the Advanced
Security Settings for AdminSDHolder window. Here are the screenshots:
Avoid the entries inherited from the parent object. Copy or remove the existing entries
as needed. Alternatively, adjust the SACL to fit the needs of the protected users and
groups.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive access denied errors after
you log on to a local administrator
domain account
Article • 02/19/2024

This article helps solve access denied errors that occur after you log on to a local
administrator domain account.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 2738746

Symptoms
Consider the following scenario:

You create a local administrator account on a computer this is running Windows

Server 2003 or later operating system.
You log on by using the local administrator account instead of the built-in
Administrator account and then configure the server to be the first domain
controller in a new domain or forest. As expected, this local account becomes a
domain account.
You use this domain account to log on.
You try to perform various Active Directory Domain Services (AD DS) operations.

In this scenario, you receive access denied errors.

Cause
When you configure the first domain controller in a forest or a new domain, the user's
local account is converted to a domain security principal and is added to matching
domain built-in groups, such as Users and Administrators. Because there are no built-in
local Schema Admins, Domain Admins, or Enterprise Admins groups, these
memberships are not updated in the domain groups, and you are not added to the
Domain Admins group.

Workaround
To work around this behavior, use Dsa.msc, Dsac.exe, or the Active Directory Windows
PowerShell module to add the user to the Domain Admins and Enterprise Admins
groups as necessary. We do not recommend that you add the user to the Schema
Admins group unless you are currently performing a schema upgrade or modification.

After you log off and then log back on, the group membership changes will take effect.

More information
This behavior is expected and is by design.

Although this behavior has always been present in AD DS, improved security procedures
in business networks have exposed the behavior to customers who follow Microsoft best
practices for using the built-in Administrator account.

The built-in Administrator account makes sure that at least one user has full
administrative group membership in a new forest.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Applications using NetUserGetInfo and
similar APIs rely on read access to
certain AD objects
Article • 02/19/2024

This article discusses an issue where applications that use down-level APIs of the
NetUser or NetGroup class like NetUserGetInfo or NetGroupGetInfo fails with the
ACCESS DENIED error.

Applies to: Windows Server 2012 R2

Original KB number: 2281774

Summary
You have an application that uses the down-level APIs of the NetUser or NetGroup class
like NetUserGetInfo , NetUserSetInfo , NetUserEnum , NetGroupGetInfo , NetGroupSetInfo ,
NetGroupEnum , NetLocalGroupGetInfo , NetLocalGroupSetInfo , and NetLocalGroupEnum . In

this scheme, the NetUser class APIs are also used to manage computer account.

The same APIs are used when you invoke the ADSI WINNT provider.

These APIs may fail with ACCESS DENIED although the calling account has sufficient
permissions on the target accounts. The reason for this is that the client-side API
implementation does not have a 1:1 relationship with Security Account Manager (SAM)
RPC APIs. The client side performs additional checks and preparation for these calls that
require additional permissions in Active Directory.

One application that uses these APIs is the cluster service, and in the cluster service log
you will see:

00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Network Name <cluster-

resource1>: Couldn't determine if computer account cluster-resource1 is already
disabled. status 5

Another symptom of this effect might be excessive audit records in the Security
Eventlog of your DCs for these API calls and the objects quoted below, if successful or
failure access auditing for the calling account is enabled.
More information
The implementation of the APIs uses multiple RPC calls directed at the Domain
Controller, to set up the session and verify the domain. It accesses the following objects
with read access:

Domain Root Object: It looks up the primary domain of the Domain Controller and
opens the domain for reading, which in turn opens the AD object for the domain,
like DC=contoso,dc=com.

Builtin container: This is the root object of the builtin domain. It is opened as the
caller wants to verify its existence. Thus the caller needs read access to the
container CN=Builtin,DC=contoso,dc=com.

SAM server object: This object stores general permissions about general SAM
account access and enumeration. It will be used on certain calls only. The object
name is cn=server,cn=system,DC=contoso,dc=com.

In most Active Directory domains, permissions to these objects are granted based on
the membership in generic groups like Authenticated Users, Everyone or the Pre-
Windows 2000 Compatible Access group. The change to trigger the problem may have
been that the user was removed from the last group (maybe together with Everyone,
and/or the permissions on the objects listed were removed in a move to harden the
Active Directory permissions.

The approaches to resolve the problem are to either grant the required read
permissions or to change the application to use LDAP instead of the older APIs or the
ADSI WINNT provider. LDAP will not touch the objects above and it will also support the
granular permissions you may have set on the target object.

Excessive auditing
When you have auditing enabled on these objects, you will see up to three audit records
for the objects above for both opening and closing the objects, plus the actual target
object access. If the events are logged excessively, it makes sense to remove the entries
in the Auditing ACL so these generic access types are not logged anymore. The problem
is that the Domain Root object and the Builtin Container inherit to many subordinate
objects.

To solve this, you need to break inheritance at the builtin container and redefine the
ACEs that inherit to only apply to this object. You also need to touch the ACEs on the
Domain Root object so the problem SACEs don't apply to the domain root object
anymore. The exact steps depend on the actual SACL settings that are in effect in your
environment.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error: Access is denied when non-
administrator users who have been
delegated control try to join computers
to a domain controller
Article • 02/19/2024

This article provides a solution to an error message when non-administrator users who
have been delegated control try to join computers to a domain controller.

Applies to: Windows Server 2012 R2

Original KB number: 932455

Symptoms
On a domain controller, non-administrator users may experience one or more of the
following symptoms:

After a specific user or a specific group is provided with the permission to add or
to remove computer objects to the domain on an organizational unit (OU) through
the Delegation Wizard, users can't add some of the computers to the domain.
When the user tries to join a computer to a domain, users may receive the
following error message:

Access is denied.

７ Note

Administrators can join computers to the domain without any issues.

Users who are members of the Account Operators group or who have been
delegated control can't create new user accounts or reset passwords when they
sign in locally or when they sign in through Remote Desktop to the domain
controller.

When users try to reset a password, they may receive the following error message:

Windows cannot complete the password change for username because:

Access is denied.
 When users try to create a new user account, they receive the following error
message:

The password for username cannot be set due to insufficient privileges,

Windows will attempt to disable this account. If this attempt fails, the account
will become a security risk. Contact an administrator as soon as possible to
repair this. Before this user can log on, the password should be set, and the
account must be enabled.

Cause
These symptoms may occur if one or more of the following conditions are true:

A user or a group hasn't been granted the Reset Passwords permission for the
computer objects.

７ Note

A user or a group cannot join a computer to a domain if the specified user or

specified group does not have the Reset Password permission set for the
computer objects. Users can create new computer accounts for the domain
without this permission. But if the computer account is present in Active
Directory already, they will receive the "Access is denied" error message
because the Reset Password permission is required to reset the computer
object properties for the existing computer object.

Users have been delegated control of the Account Operators group or are
members of the Account Operators group. These users haven't been granted the
Read permission on the built-in OU in "Active Directory Users and Computers."

Resolution
To resolve the issue in which users can't join a computer to a domain, follow these steps:

1. Select Start, select Run, type dsa.msc, and then select OK.
2. In the task pane, expand the domain node.
3. Locate and right-click the OU that you want to modify, and then select Delegate
Control.
4. In the Delegation of Control Wizard, select Next.
5. Select Add to add a specific user or a specific group to the Selected users and
groups list, and then select Next.
 6. In the Tasks to Delegate page, select Create a custom task to delegate, and then
select Next.
7. Select Only the following objects in the folder, and then from the list, click to
select the Computer objects check box. Then, select the check boxes below the
list, Create selected objects in this folder and Delete selected objects in this
folder.
8. Select Next.
9. In the Permissions list, click to select the following check boxes:

Reset Password
Read and write Account Restrictions
Validated write to DNS host name
Validated write to service principal name

10. Select Next, and then select Finish.

11. Close the "Active Directory Users and Computers" MMC snap-in.

To resolve the issue in which users can't reset passwords, follow these steps:

1. Select Start, select Run, type dsa.msc, and then select OK.

2. In the task pane, expand the domain node.

3. Locate and right-click Builtin, and then select Properties.

4. In the Builtin Properties dialog box, select the Security tab.

5. In the Group or user names list, select Account Operators.

6. Under Permissions for Account Operators, click to select the Allow check box for
the Read permission, and then select OK.

７ Note

If you want to use a group or a user other than the Account Operators group,
repeat steps 5 and 6 for that group or that user.

7. Close the "Active Directory Users and Computers" MMC snap-in.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Event ID 16650: The account-identifier
allocator failed to initialize in Windows
Server
Article • 02/19/2024

This article provides a solution to solve errors that occurs when you add objects to
Active Directory or restore a domain controller from a system state backup.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 839879

Symptoms
This article applies to Windows 2000 and all later versions. When you try to add new
users, groups, computers, mailboxes, domain controllers, or other objects to Active
Directory on a Microsoft Windows Server computer, you may receive the following error
message:

Cannot create the object because directory service was unable to allocate a relative
identifier.

When you restore a domain controller from a system state backup, the System log may
contain the following error message:

Event Type:Error

Event Source: SAM Event

Category:None

Event ID: 16650

The account-identifier allocator failed to initialize properly. The record data contains
the NT error code that caused the failure. Windows will retry the initialization until it
succeeds; until that time, account creation will be denied on this Domain Controller.
Look for other SAM event logs that may indicate the exact reason for the failure.

You can also use the Dcdiag command together with the verbose switch to look for
additional errors. To do this, follow these steps:

1. Click Start, click Run, type cmd in the Open box, and then click OK.
 2. At the command prompt, type DCdiag /v , and then press Enter.

When you type Dcdiag /v , you may see error messages that resemble the following:

Starting test: RidManager

* Available RID Pool for the Domain is 2355 to 1073741823

* dc01.contoso.com is the RID Master

* DsBind with RID Master was successful

* rIDAllocationPool is 1355 to 1854

* rIDNextRID: 0 The DS has corrupt data: rIDPreviousAllocationPool value is not valid

* rIDPreviousAllocationPool is 0 to 0 No rids allocated -- please check eventlog.

......................... DC01 failed test RidManager

Warning: rid set reference is deleted.

ldap_search_sW of CN=RID SetDEL:cfe0828c-8842-4cb1-a642-

6d9991d0516d,CN=Deleted Objects,DC= contoso,DC= com for rid info failed with
2: The system cannot find the file specified.

......................... DC01 failed test RidManager

Starting test: RidManager

* Available RID Pool for the Domain is 3104 to 1073741823

Warning: FSMO Role Owner is deleted.

* dc01.contoso.com is the RID Master

* DsBind with RID Master was successful

Warning: rid set reference is deleted.

ldap_search_sW of CN=RID SetDEL:5a128cf2-f365-47bc-a883-

8ff9561ff545,CN=Deleted Objects,DC=contoso,DC=com for rid info failed with 2:
The system cannot find the file specified. ......................... DC01 failed test RidManager

Starting test: KnowsOfRoleHolders

Role Rid Owner = CN="NTDS Settings DEL:fd615439-1ebb-4652-b16f-

3f8517d25593",CN=dc01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com Warning: CN="NTDS
 Settings DEL:fd615439-1ebb-4652-b16f-
3f8517d25593",CN=dc01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com is the Rid Owner, but is
deleted.

You may also receive other errors in the system event log that can help you to
troubleshoot the problem:

Event ID: 16647

Event Source: SAM

Description: The domain controller is starting a request for a new account-identifier

pool.

Event Type: Error

Event Source: SAM Event Category:None

Event ID: 16645

Description: The maximum account identifier allocated to this domain controller has
been assigned. The domain controller has failed to obtain a new identifier pool. A
possible reason for this is that the domain controller has been unable to contact the
master domain controller. Account creation on this controller will fail until a new
pool has been allocated. There may be network or connectivity problems in the
domain, or the master domain controller may be offline or missing from the
domain. Verify that the master domain controller is running and connected to the
domain.

Cause
This problem occurs in one of the following scenarios:

When the relative ID (RID) Master is restored from backup, it tries to synchronize
with other domain controllers to verify that there are no other RID Masters online.
However, the synchronization process fails if there are no domain controllers
available to synchronize with, or if replication is not working.

７ Note
 If the domain has always contained only one domain controller, the RID
Master will not try to synchronize with other domain controllers. The domain
controller has no knowledge of any other domain controllers.

The RID pool has been exhausted, or objects in Active Directory that are related to
RID allocation use incorrect values or are missing.

Resolution

Delete the replication links for the naming contexts in

Windows
In Windows 2000 and later versions, you can restore a second domain controller to
complete initial synchronization. If you cannot restore a second domain controller, you
must either perform a metadata cleanup on the non-existent domain controllers or
delete the replication links to the Active Directory naming contexts. If you plan to
restore the other domain controllers later, you must delete the replication links instead
of performing a metadata cleanup.

Before you can delete the replication links to the Active Directory naming contexts, you
must identify the objectGUID value by using the Repadmin command. To do this, follow
these steps:

1. Click Start, click Run, type cmd in the Open box, and then click OK.

2. At the command prompt, type repadmin /showreps . You will see output that
resembles the following:

CN=Schema,CN=Configuration,DC=contoso,DC=comDefault-First-Site-
Name\DC02 via RPC objectGuid: <GUID> Last attempt @ <DateTime> was
successful.

CN=Configuration,DC=contoso,DC=com Default-First-Site-Name\DC02 via

RPC objectGuid: <GUID> Last attempt @ <DateTime> was successful.

DC=contoso,DC=com Default-First-Site-Name\DC02 via RPC objectGuid:

<GUID> Last attempt @ <DateTime> was successful.

3. Type repadmin /delete to delete the replication links. Specify the naming context
and the objectGUID as shown in the following examples:
 Console

repadmin /delete CN=Schema,CN=Configuration,DC=contoso,DC=com DC01

<GUID>._msdcs.contoso.com /localonly
repadmin /delete CN=Configuration,DC=contoso,DC=com DC01
<GUID>._msdcs.contoso.com /localonly
repadmin /delete DC=contoso,DC=com DC01 <GUID>._msdcs.contoso.com
/localonly

4. Restart the RID Master computer. The RID Master will initialize correctly.

Remove domain controller metadata for all other domain

controllers in the domain
You can restore or connect a second domain controller to complete initial
synchronization. If you cannot add a second domain controller, you must either perform
a metadata cleanup on the non-existent domain controllers to remove them from the
domain permanently or delete the replication links to the Active Directory naming
contexts. For more information about how to remove metadata, click the following
article number to view the article Clean up Server Metadata.

Verify that Active Directory objects that are related to RID

allocation are valid
To verify that the Active Directory objects that are related to RID allocation are valid,
follow these steps:

1. Verify that the Everyone group has the Access this computer from the network user
right. The setting can be configured in the following location in the Group Policy
Object Editor: Computer Configuration\Windows Settings\Security Settings\Local
Policies\User Rights Assignment .

2. Install the Windows 2000 Support Tools. These tools are available in the support
folder on the Windows 2000 and the Windows Server 2003 CD-ROMs. When you
have installed these tools, start ADSI Edit . To do this, follow these steps:
a. Click Start, click Run, type mmc in the Open box, and then click OK.
b. In Windows 2000, click Console, and then click Add/Remove Snap-in. In
Windows Server 2003, click File, and then click Add/Remove Snap-in.
c. In the Add/Remove snap-in, click Add, click ADSIEdit, and then click Add.
d. Click Close, and then click OK.

3. In MMC, right-click ADSIEdit, and then click Connect to.

 4. In Connections Settings, under Connection Point, click Select a well known
naming context. In the drop-down list, click domain, and then click OK.

5. Expand domain, and then expand the distinguished name of the domain. For
example, expand DC=contoso, DC=com.

6. Expand OU=Domain Controllers.

7. Right-click the domain controller that you want to check, and then click Properties.

8. Click the Select a property to view menu, and then click userAccountControl.

9. Verify that the value for userAccountControl is 532480. To change the

userAccountControl value, click Edit on the domain controller property dialog box.

10. In the Integer Attribute Editor, type 532480 in the Value field, and then click OK.

Verify that the RID Master is replicating with another

domain controller
If a newly promoted domain controller generates Event 16650, the domain controller
may have obtained replication information from another domain controller that is not
the RID Master. During promotion, the computer account for the new domain controller
is modified. If these changes have not replicated to the domain controller that holds the
RID master role, the request will fail when the newly promoted domain controller tries to
obtain a RID pool.

To verify that the RID Master is replicating with at least one of its direct partners, follow
these steps:

1. Verify that the CN=RID Set object exists.

The CN=RID Set object is in the right pane of ADSI Edit when the domain
controller is selected under OU=Domain Controllers in the left pane.

If no CN=RID Set object exists, you must demote that domain controller and then
promote it again to create the object.

2. If the CN=RID Set object exists, make sure that the rIDSetReferences attribute on
the domain controller's computer account object points to the distinguished name
of the RID Set object, as shown in the following example: CN=RID Set,
CN=DC01,OU=Domain Controllers,CN=contoso,DC=local

If the rIDSetReferences attribute does not point to the distinguished name of the
RID Set object, contact Microsoft Product Support Services for more information.
Status
This behavior is by design.

References
822053 Error message: "Windows cannot create the object because the Directory
Service was unable to allocate a relative identifier"

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to add special groups to built-in
groups
Article • 02/19/2024

This article describes how to add special groups to built-in groups.

Applies to: Windows Server 2012 R2

Original KB number: 292781

Summary
If you, as the administrator, delete one of the memberships of a special group, such as
Authenticated Users, from a Built-in Domain Local Users group on a domain controller
in Windows, you cannot readd the group by using the Active Directory Users and
Computers tool. To add one of the special groups to a domain local group on a domain
controller, use the net localgroup command.

For example, use the following command to add the Authenticated Users group back to
the Built-in Domain Local Users group on a domain controller:

net localgroup users "nt authority\authenticated users" /add

More information
In Windows, there are certain special groups that are created by the system and that are
used for special purposes. A list of these special groups includes:

Authenticated Users
Anonymous Logon
Batch
Creator Owner
Creator Group
Dialup
Enterprise Domain Controllers
Everyone
Interactive
Network
Proxy
Restricted
Self
Service
System
Terminal Server User

Because you cannot alter the membership of these groups, the groups are not listed in
Active Directory Users and Computers ( Dsa.msc ). However, these groups are useful for
operations such as assigning permissions to directories, files, shared network directories,
or printers.

Users become members of these special groups depending on the operation that
they're trying to perform. For example, a user gains the Interactive group membership in
their token whenever they use a computer locally. The Network group would be added
to a user's token anytime that a user connects over the network to a computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

All members of a group may not be
returned when you enumerate members
of a group by using the Active Directory
Service Interfaces WinNT provider
Article • 02/19/2024

This article provides a solution to an issue that all members of a group may not be
returned when you enumerate members of a group by using the Active Directory
Service Interfaces WinNT provider.

Applies to: Windows Server 2012 R2

Original KB number: 321538

Symptoms
When you enumerate members of a group by using the Active Directory Service
Interfaces (ADSI) WinNT provider, and you use a binding string, a problem may occur.
Some members of the group may not be returned if the group that you are
enumerating has members of the following:

A local group that contains domain users and domain groups as members
A domain local group that contains groups from trusted domains as members

Workaround
You can use the GetObject method to obtain the full member list. The GetObject
method uses the credentials for the currently logged on user. The following code
example demonstrates this.

VB

GetObject("WinNT://<server>/<group>,group")

If the account that you want to use for enumerating the group is not the currently
logged on user, you can use impersonation before you use the GetObject method.

Status
This behavior is by design.

Steps to reproduce the problem

The Active Directory Service Interfaces WinNT provider does not connect to more than
one server to compile the member list. This problem occurs if explicit credentials are
passed. Therefore, only a partial member list is returned. For example, if you run the
following script to enumerate a local group that contains a group from a trusted
domain, all members of the group are returned, except the group from the trusted
domain.

VB

'Start of the script

Dim oRoot
Dim oSourceGroup
Dim oMember
Const ADS_SECURE_AUTHENTICATION=1

'Binding
Set oRoot = GetObject("WinNT:")
Set oTargetGroup = oRoot.OpenDSObject("WinNT://<server>/<group>,group", "
<domain>\<user>", "<password>",ADS_SECURE_AUTHENTICATION)'All of the
following are placeholders: <server> <group> <domain> <user> <password>
msgbox oTargetGroup.ADSPath

For Each oMember in oTargetGroup.Members

msgbox oMember.ADsPath
Next
'End of the script

） Important

We do not recommend that you pass credentials in Active Directory Service

Interfaces by using the Active Directory Service Interfaces WinNT provider.

For more information, see User authentication issues with the Active Directory Service
Interfaces WinNT provider.

References
Active Directory Service Interfaces
Feedback
Was this page helpful?  Yes  No

Provide product feedback

AuditPol and Local Security Policy
results may differ
Article • 02/19/2024

This article helps fix an issue where audit policy settings with AuditPol and the Local
Security Policy (SECPOL.msc) show different results.

Applies to: Windows Server 2012 R2

Original KB number: 2573113

Symptoms
When viewing audit policy settings with AuditPol and the Local Security Policy
(SECPOL.msc), the settings may show different results.

Cause
AuditPol directly calls authorization APIs to implement the changes to the granular audit
policy. Secpol.msc manipulates the Local Group Policy Object, which results in writing
the changes to %SYSTEMROOT%\system32\GroupPolicy\Machine\Microsoft\Windows
NT\Audit\Audit.csv. The settings saved to the .csv file aren't applied directly to the
system at the time of modification, but are instead written to the file and read later by
the client-side extension (CSE). At the next group policy refresh cycle, the CSE applies
the modifications that are present in the .csv file.

Secpol.msc displays what is set in the local GPO. There's no "effective settings" view in
secpol.msc that will merge granular AuditPol settings and what is defined locally as seen
with secpol.msc.

Resolution
From an administrative command prompt, you can use AuditPol to view the defined
auditing settings by running:

Console

auditpol /get /category:*

More information
Auditpol get

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Object reference not set to an instance
of an object" while accessing Active
Directory information from TFS Source
Control Explorer
Article • 02/19/2024

This article provides help to solve an error that occurs when you access Active Directory
information from Team Foundation Server Source Control Explorer.

Applies to: Windows Server 2012 R2

Original KB number: 957969

Rapid publishing
Rapid publishing articles provide information directly from within the Microsoft support
organization. The information contained herein is created in response to emerging or
unique topics, or is intended supplement other knowledge base information.

Action
Create a Windows group in Active Directory (AD), and assign AD users to the group,
then...

1. Open Visual Studio as a TFS Administrator

2. Open Source Control Explorer
3. Right-click on a version control folder and select Properties
4. Click the Security tab on the Properties dialog
5. Select the Windows User or Group option and click the Add button
6. Browse for the AD group; and attempt to add the group

Result
Error: Object reference not set to an instance of an object.

Cause
This issue is caused by a bug in the version control permission dialog window in Visual
Studio 2008\ Team Explorer 2008.

Resolution
This problem is resolved in Visual Studio 2008 SP1. If you are using Visual Studio 2008
RTM, there are two workarounds:

1. Assign version control permissions with command-line tool: tf.exe

You can enter tf perm /? or review the MSDN documentation for this command
TF Permission command for more information about how to assign version
control permissions from command line.

2. Explicitly make the AD group in question a valid TFS identity:

a. Create a new user group on the server.
b. Add the AD group in question to this group.
c. You should now be able to assign version control permissions to the AD group.

Disclaimer
Microsoft and/or its suppliers make no representations or warranties about the
suitability, reliability, or accuracy of the information contained in the documents and
related graphics published on this website (the "materials") for any purpose. The
materials may include technical inaccuracies or typographical errors and may be revised
at any time without notice.

To the maximum extent permitted by applicable law, Microsoft and/or its suppliers
disclaim and exclude all representations, warranties, and conditions whether express,
implied or statutory, including but not limited to representations, warranties, or
conditions of title, non infringement, satisfactory condition or quality, merchantability
and fitness for a particular purpose, with respect to the materials.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot add a user name or an
object name that only differs by a
character with a diacritic mark
Article • 02/19/2024

This article provides a solution to an issue where you can't add a user name or an object
name that only differs by a character with a diacritic mark.

Applies to: Windows Server 2012 R2

Original KB number: 938447

Symptoms
You try to add a new user or a new object to the Active Directory directory service.
However, the user or the object is not added. Additionally, you may receive any one of
the following error messages:

Error message 1:

The object username could not be created.

The problem encountered was;
An attempt was made to add an object to the directory with a name that is
already in use.

Error message 2:

Windows cannot create the new user object because the name username is
already in use. Select another name, and try again.

Error message 3:

Windows cannot create the specified object because: The specified user
already exists.

Error message 4:

The user logon name you have chosen is already in use in this enterprise.
Choose another logon name, and then try again.
 ７ Note

In these error messages, username is the name of the user or of the object that you
tried to add.

Cause
This problem occurs because the user name or the object name contains diacritic marks,
for example, German umlauts. A German umlaut character contains a dieresis over the
base character itself, such as in the following characters:

Ää
Öö
Üü

The German umlaut characters are interpreted to be the same as their base characters.
For example, the ü character is interpreted to be the same as the u character. When this
problem occurs, a user who is named Muller cannot be created if a user who is named
Müller already exists. Similarly, a user who is named Meissner cannot be created if a user
who is named Meißner already exists.

Resolution
To resolve this problem, use a different name for the user or for the object that you want
to add.

Status
This behavior is by design.

More information
Microsoft has published rules for valid characters for various object types that further
reduces the freedom of name choice. For more information, see Naming conventions in
Active Directory for computers, domains, sites, and OUs.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot start the Active Directory
Users and Computers tool because the
server is not operational
Article • 02/19/2024

This article provides a solution to an issue where you cannot start the Active Directory
Users and Computers tool because the server is not operational.

Applies to: Windows Server 2012 R2

Original KB number: 323542

Symptoms
Any of the following symptoms may occur:

When you try to start the Active Directory Users and Computers tool, you receive
the following error message:

Naming Information cannot be located because:

The Server is not operational.
Contact your system administrator to verify that your domain is properly
configured and is currently online.

When you try to start the Active Directory Sites and Services tool, you receive the
following error message:

Naming Information cannot be located because:

The server is not operational.
Contact your system administrator to verify that your domain is properly
configured and is currently online.

When you try to start the Active Directory Domains and Trusts tool, you receive the
following error message:

The configuration information describing this enterprise is not available.

The server is not operational.

Logon processing is very slow.

 If you have multiple domain controllers, you can connect with the Active Directory
Users and Computers tool to another domain controller that has port 389 open
without receiving an error message. But you cannot access a domain controller
until port 389 is opened.

Cause
These issues may occur if TCP/IP filtering is configured to permit only port 80 for TCP/IP
traffic.

Resolution
Port 389 is used for Lightweight Directory Access Protocol (LDAP) connections. This port
is blocked if TCP/IP filtering is configured incorrectly. By default, TCP/IP filtering is
configured with the Permit All setting. To verify and correct this setting:

1. Right-click My Network Places on the domain controller on which you cannot start
Active Directory Users and Computers, and then click Properties.
2. Click Internet Protocol, and then click Properties.
3. Click Advanced.
4. Click Options.
5. Click TCP/IP Filtering, and then click Properties.
6. For the TCP/IP Port setting, click Permit All.
7. Restart the computer. This opens all TCP ports, including port 389.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Compatibility with user accounts ending
with the dollar sign ($)
Article • 02/19/2024

This article describes the potential compatibility issues in using domain user accounts
ending with the dollar sign ($) as a service account.

Applies to: Windows Server 2012 R2, Windows 7 Service Pack 1

Original KB number: 2666116

Summary
Starting in Windows 7/2008R2, there are potential compatibility issues with using
domain user accounts ending with the dollar sign ($) as a service account. Managed
service accounts are identified by ending in a dollar sign ($). The system may evaluate
the account as a managed service account and block the change.

More information
In the services console, if you enter a user account in a trusted domain that ends in the
dollar sign ($), it will warn you that "The name provided is not a properly formed
account name." This occurs because managed service accounts can't be used in a
trusted domain.

Managed Service Accounts

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Define Security Templates By Using the
Security Templates Snap-In
Article • 02/19/2024

This article provides some steps to define Security Templates by using the Security
Templates Snap-In.

Applies to: Windows Server 2003

Original KB number: 816297

Summary
This step-by-step article describes how to create and define a new security template by
using the Security Templates snap-in in Microsoft Windows Server 2003.

With the Security Templates snap-in, you can create a security policy for your network or
computer by using security templates. A security template is a text file that represents a
security configuration. You can apply a security template to the local computer, import a
security template to Group Policy, or use a security template to analyze security. You can
use a predefined security template that is included in Windows Server 2003, modify a
predefined security template, or create a custom security template that contains the
security settings that you want. Security templates can be used to define the following
components:

Account Policies
Password policy
Account lockout policy
Kerberos policy

Local policies
Audit policy
User rights assignment
Security Options

Event log: Application, System, and Security Event log settings

Restricted groups: Membership of security-sensitive groups

System Services: Startup modes and permissions for system services

Registry: Registry key permissions

 File system: File and folder permissions

Add the Security Templates Snap-In to a Microsoft

Management Console (MMC) Console
To add the Security Templates snap-in to an MMC console, follow these steps:

1. Click Start, and then click Run.

2. In the Open box, type mmc, and then click OK.

3. On the File menu, click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click the Standalone tab, and then click
Add.

5. In the Add Standalone Snap-in dialog box, click Security Templates, click Add,
click Close, and then click OK.

6. In the console tree, expand Security Templates, and then expand

%SystemRoot%\Security\Templates.

A list of predefined security templates and their descriptions appears in the right
pane.

Create and Define a New Security Template

To define a new security template, follow these steps:

1. In the console tree, expand Security Templates.

2. Right-click %SystemRoot%\Security\Templates, and then click New Template.

3. In the Template name box, type a name for the new template.

If you want, you can type a description in the Description box, and then click OK.

The new security template appears in the list of security templates. Note that the
security settings for this template are not yet defined. When you expand the new
security template in the console tree, expand each component of the template,
and then double-click each security setting that is contained in that component, a
status of Not Defined appears in the Computer Setting column.

4. To define Account Policies, Local Policies, or Event Log policies, follow these steps:
 a. In the console tree, expand the component that contains the security setting
that you want to configure.
For example, to set a maximum password age policy, expand Account Policies.
b. In the right-pane, double-click the security setting that you want to configure.
For example, to set the maximum password age policy, double-click Password
Policy, and then double-click Maximum password age.
c. Click to select the Define this policy setting in the template check box, specify
the option or setting that you want as appropriate to the security setting, and
then click OK.

5. To define a Restricted Groups policy, follow these steps:

a. Right-click Restricted Groups, and then click Add Group.
b. Click Browse.
c. In the Select Groups dialog box, type the name of the group that you want to
restrict access, click OK, and then click OK.
d. In the GroupName Properties dialog box, under Members of this group, click
Add Members to add the members that you want to the group.
To add this group as a member of another group, under This group is a
member of, click Add Groups.
e. Click OK.

6. To define a System Services policy, follow these steps:

a. Expand System Services.
b. In the right pane, double-click the service that you want to configure.
c. Specify the options that you want, and then click OK.

7. To define security for registry keys, follow these steps:

a. Right-click Registry, and then click Add Key.
b. In the Select Registry Key dialog box, click the registry key that you want to
define security for, and then click OK.
c. In the Database Security for RegistryKey dialog box, specify the permissions
that you want for the registry key, and then click OK.
d. In the Add Object dialog box, specify how you want permissions on this key
inherited, click OK, and then click OK.

8. To define security for files or folders, follow these steps:

a. Right-click File System, and then click Add File.
b. In the Add a file or folder dialog box, click a file or folder that you want to add
security to, and then click OK.
c. In the Database Security for FileName or FolderName dialog box, specify the
permissions that you want, click OK, and then click OK.
Copy Security Settings from a Predefined Template to
Another Template
To copy security settings from a predefined template to your custom template, follow
these steps:

1. In the console tree, expand a predefined template that contains the settings that
you want to copy, right-click the component that you want to copy, and then click
Copy.

2. In the console tree, expand your custom template, right-click the appropriate
component, and then click Paste.

For example, to use the Account Policies settings from the Hisecdc template in
your custom template, expand Hisecdc, right-click Account Policies, and then click
Copy. Expand your custom template, right-click Account Policies, and then click
Paste.

Create a New Security Template Based on a Predefined

Template
To create a new security template based on settings from a predefined template, save
the predefined template by using another file name. To do so, follow these steps:

1. Right-click the template that you want to copy, and then click Save As.

2. In the Save As dialog box, type a name for the security template in the File name
box, and then click Save.

The new security template appears in the list of security templates. Configure the
template with the settings that you want.

References
For more information about security templates in Windows Server 2003, see the
"Security Configuration Manager" topic in the Security section of the Windows 2003
Server documentation.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"The directory datatype cannot be
converted to or from a native DS
datatype" error
Article • 02/19/2024

This article helps to fix the error "The directory datatype cannot be converted to or from
a native DS datatype".

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 907462

Symptoms
You are running or managing applications that use information from the Active
Directory directory service in Windows. You may receive errors when the applications
use information for linked attributes. For example, you may receive the following error:

The directory datatype cannot be converted to / from a native DS datatype.

In this case, when you export the affected object by using the LDIFDE utility (Ldifde.exe),
an attribute is listed. However, the attribute has no value.

This may be the expected behavior when the value is long. But the next line in the
output has the next attribute. For a group and its managedBy attribute, the output may
resemble the following:
...
showInAddressBook: <Address Book object DN>
managedBy:
legacyExchangeDN: <X500 name>
groupType: -2147483640
...

In a database dump with the RootDSE command verb dumpdatabase, the affected
groups will be shown as follows:

38661 29827 1 1790 true - - 4 3 Group-DN Group-DN - 655368 6d03f309-ded2-

41d5-9794-081d40343876 4
objectclass: 655368, 65536
DNT Base BDNT DelTime DeactiveTime USNChanged NCDNT Data
 38661 1 38662 - - 55247898 1790 -
38661 36 2 - - - - -

The link attribute ID is always 36, and the link partner is always 2.
For information about how to dump the database, see How to Use the Online Dbdump
feature of Active Directory .

Cause
An application can add an object link that refers to the internal root object of the Active
Directory database. This object does not have a name or any other properties that are
usable for applications. Therefore, the client applications display error messages that do
not indicate the cause of a problem.

Resolution
If you use domain controllers that are running Windows Server 2003 with Service Pack 1,
the problem does not occur. But the object with this invalid link is still in the database.
You can find the groups affected for a domain controller when you search the
NTDS.DMP file, as follows:

findstr /i /c:" 36 2 - - " ntds.dmp

38661 36 2 - - - - -

Windows Server 2003:

You cannot resolve the problem by deleting the attribute. If you delete the attribute, the
following error is logged in the Application Directory Services log:

Event Type: Error

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1694
Description:
Active Directory could not update the following object with an attribute value
change received from the following source domain controller. This is because an
error occurred during the application of the changes to Active Directory on the local
domain controller.
Object:
<group DN>
 Object GUID:
<GUID>
Source domain controller:
<GUID-based DC name>
Attribute:
managedBy:
Attribute value:
[]
Attribute value GUID:
00000000-0000-0000-0000-000000000000
Present:
0
This operation will be tried again at the next scheduled replication. The
synchronization of the local domain controller with the source domain controller is
blocked until the update problem is corrected.
Additional Data
Error value:
The replication system encountered an internal error.

If this error is logged, the object is in a broken state. To achieve the original state or to
delete the object, you can only run an authoritative restore on the object. To repair
objects that exhibit this behavior, we recommend that you delete and rebuild the object
by using the LDIFDE utility.

Ｕ Caution

All back-links are removed when you delete an object.

If you have to keep certain attributes that you cannot set the value on, such as the
objectSid attribute or the SidHistory attribute, delete and then undelete the object.
(Windows Server 2003 Service Pack 1 retains the SidHistory attribute on when you
delete an object.) When you delete and undelete an object, you do not have to run a
semantic checker.

However, no tools currently exist to recover the attributes and the back-links. To restore
group memberships, you can use the Groupadd.exe tool. For more information, click the
following article number to view the article in the Microsoft Knowledge Base:

840001 How to restore deleted user accounts and their group memberships in Active
Directory
If you use the Microsoft Provisioning System, you can use the system to recover the
attributes and the back-links.

Some backup and recovery applications may offer a more convenient way of removing
these problematic attributes. The application must let you select attributes during a
restore operation. For example, an application must let you exclude the managedBy
attribute when you restore a deleted object.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section. This problem was first corrected in Microsoft Windows Server
2003 Service Pack 1.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 5722 is logged on your domain
controller
Article • 02/19/2024

This article describes how to diagnose and resolve a problem where event 5722 appears
in the system log of your domain controller.

Applies to: Windows 2000

Original KB number: 810977

７ Note

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010.
For more information, see the Microsoft Support Lifecycle Policy.

Summary
When you use Event Viewer to view the system log in a Windows domain controller, you
may find event 5722 logged. This problem may occur in either of two scenarios:

When a computer updates its computer account password with a domain

controller
When a computer is joined to a domain with a name that already exists

This article describes how to differentiate the two scenarios and how to resolve the
problem.

Symptoms
On a Microsoft Windows domain controller, the following event is logged in the system
log:

Event Type: Error

Event Source: NETLOGON
Event Category: None
Event ID: 5722
Date: Date
Time: Time
User: N/A
 Computer: ComputerName
Description: The session setup from the computer ComputerName failed to
authenticate. The name of the account referenced in the security database is
AccountName $.
The following error occurred:
Access is denied.

Cause
In a Microsoft Windows domain, starting with Windows 2000, a discrete communication
channel helps provide a more secure communication path between the domain
controller and the member servers or workstations. This channel is known as a secure
channel. When you join a computer to a domain, a computer account is created, and a
password is shared between the computer and the domain. By default, this password is
changed every 30 days. The secure channel's password is stored together with the
computer account on the primary domain controller (PDC). The password is replicated
to all replica domain controllers.

Event 5722 is logged in the following scenarios:

When a computer updates its computer account password with a domain

controller, the event is logged in the system log of the authenticating domain
controller.

In this scenario, the computer's secure channel with the authenticating domain
controller is still valid.

When you join a computer to a domain by using a name that is already in use by
another computer, or when an existing computer account is reset. An existing
computer account may be reset by using Active Directory Users and Computers or
by using the Netdom.exe utility.

In this scenario, the computer's account password does not match the password
on the domain controller, and you cannot set a secure channel from the original
computer to the domain controller.

Resolution

２ Warning
 If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client,
and you incorrectly modify the attributes of Active Directory objects, you can cause
serious problems. These problems may require you to reinstall Microsoft Windows
2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server,
Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot
guarantee that problems that occur if you incorrectly modify Active Directory
object attributes can be solved. Modify these attributes at your own risk.

To resolve this problem, first determine which scenario is the cause of the problem. You
can follow these steps:

1. Note the date and the time that the event was logged in the system log.

2. Click Start, point to Programs, point to Resource Kit, and then click Tools
Management Console.

3. In the console tree, click Tools A to Z.

4. In the details pane, click ADSI Editor.

７ Note

ADSI Edit is included with the Windows Support Tools. You can install the
Windows Support Tools from the Support\Tools folder of the Windows 2000
Server CD-ROM.

To install ADSI Edit on computers running Windows Server® 2003 or Windows®

XP operating systems, install Windows Server 2003 Support Tools from the
Windows Server 2003 product CD. For more information about how to install
Windows Support Tools from the product CD, see Install Windows Support Tools .

On servers running Windows Server 2008 or Windows Server 2008 R2, ADSI Edit is
installed when you install the Active Directory Domain Services (AD DS) role to
make a server a domain controller. You can also install Windows Server 2008
Remote Server Administration Tools (RSAT) on domain member servers or stand-
alone servers. For specific instructions, see Installing or Removing the Remote
Server Administration Tools Pack .

To install ADSI Edit on computers running Windows Vista® with Service Pack 1
(SP1) or Windows 7, you must install RSAT.

5. In ADSI Edit, locate and then right-click the computer that is causing the problem.
 6. Click Properties.

7. In Select which properties to view, click Both.

8. In Select a property to view, click PwdLastSet.

If the ntte value is not converted in the UI to a readable date and timestamp, run
the following command or proceed to step 9 for an alternate method:

Console

w32tm /ntte pwdlastsetvalue

9. Copy the value that appears in the Value(s) box to the clipboard.

10. Click Start, point to Programs, point to Accessories, and then click Calculator.

11. On the View menu, click Scientific.

12. Click Dec to set the numbering system to decimal.

13. Paste the value from the clipboard into Calculator.

14. To change the value from decimal to hexadecimal decimal numbering system, click
Hex.

15. On the Edit menu, click Copy.

16. Paste the hexadecimal number from the clipboard to a file in Notepad.

17. Count eight characters from the rightmost character of the hexadecimal string, and
then press SPACEBAR.

７ Note

This action splits the hexadecimal string into two hexadecimal strings.

18. If the hexadecimal string on the left side contains only seven characters, add a zero
to the beginning of the string.

19. At a command prompt, type

Console

Nltest /time: RightSideHexadecimalstringLeftSideHexadecimalString

 You will receive output that is similar to:

Console

C:\>nltest /time:a25cc370 01c294bc

a25cc370 01c294bc = 11/25/2002 13:55:41
The command completed successfully.

20. Note the decoded date and time.

21. Check whether the date and time that you noted in step 1 and the decoded date
and time that you noted in step 20 match.

22. If the date and time that event 5722 was logged and the decoded date and time
match, check whether the computer that is causing the problem has a secure
channel established with a domain controller by typing the following command at
a command prompt:

Console

Nltest /server: **ComputerName** /sc_query: **DomainName**

If the problem computer has a valid secure channel established with a domain
controller, you receive output that is similar to:

Console

C:\>Nltest /server:computer1 /sc_query: DomainName Flags: 30

HAS_IP HAS_TIMESERV
Trusted DC Name \\homenode1.myhouse.com Trusted DC Connection Status
Status = 0 0x0 NERR_Success The command completed successfully.

If the problem computer does not have a valid secure channel established with a
domain controller, you receive output that is similar to:

Console

C:\>nltest /server:machine1 /sc_query: DomainName Flags: 0

Trusted DC Name
Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED The
command completed successfully.
If the date and time of event 5722 and the decoded date and time do not match, the
problem computer's account password may not match the password that is on the
domain controller. This issue can occur under either of the following circumstances:

An administrator resets a computer account by using Active Directory Users and

Computers or another tool such as Netdom.exe.
A new computer is joined to the domain by using a name that already exists in the
domain.

７ Note

If Netlogon service logging is turned on for the domain controller, you confirm this
scenario by checking for a Netlogon.log entry that is similar to the following:

05/06 13:35:25 [MISC] NlMainLoop: Notification that trust account added (or
changed) TRUSTING_DOMAIN$ 0x#### 4

This message is not logged if a computer updates its own computer account password.

To resolve problems that are related to duplicate computer names, rejoin the original
computer to the domain.

You can ignore event 5722 if both of the following conditions are true:

If the date and time of event 5722 and the decoded date and time match.
A valid secure channel is established between the problem computer and a
domain controller.

７ Note

When both of these conditions are true, event 5722 is logged on the domain
controller when the computer tries to authenticate with a domain controller during
the computer account update process.

Administrators can also query Active Directory information from any computer in the
domain by using Ldp.exe. The version of Ldp.exe that is included in the Windows XP
Service Pack 2 Support Tools can also be used to decode the PwdLastSet value.

References
For additional information about enabling debug logging, click the following article
number to view the article in the Microsoft Knowledge Base:
109626 enabling debug logging for the Net Logon service

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error Message: DSA Object Cannot Be
Deleted
Article • 02/19/2024

This article provides a solution to an issue where you fail to delete an orphaned NTDS
Settings from Active Directory Sites and Services.

Applies to: Windows Server 2012 R2

Original KB number: 318698

Symptoms
When you try to delete an orphaned NTDS Settings from Active Directory Sites and
Services, you may receive the following error message: DSA object cannot be deleted.

Only one NTDS Settings ordinarily exists under each server in the Servers folder in Active
Directory Sites and Services. If two NTDS Settings are shown, the one that doesn't have
connection objects associated with it (in the right pane) is probably the orphaned NTDS
Settings.

Cause
The Dcpromo.exe demotion process must delete NTDS Settings from a server. However,
the Dcpromo.exe process may not delete NTDS Settings even if connection objects are
deleted. If you have multiple domain controllers, the Active Directory replication process
may not delete NTDS Settings from this domain controller.

Resolution
To work around this problem, complete the following procedure on a domain controller
that has an orphaned NTDS Settings:

1. Start ADSI Edit, and then expand the following branches:

Configuration NC
CN=Configuration,DC=domain, DC=com
CN=Sites
CN= your site name
CN=Servers
 2. Locate the server that has an orphaned NTDS Settings. Right-click the orphaned
NTDS Settings, and then click Delete.

3. If you have multiple domain controllers, make sure that this change is replicated to
all domain controllers.

An orphaned NTDS Settings object may also be found in the LostAndFoundConfig

Container under the Configuration Container in ADSI Edit. You can use the analogous
procedure to delete this object. To do this:

1. Start ADSI Edit, and then expand the following branches:

Configuration NC
CN=Configuration,DC=domain, DC=com
CN=LostAndFoundConfig

2. Right-click the orphaned NTDS Settings object, and then click Delete. Make sure
that the related server object doesn't exist before deleting the NTDS Settings
object.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

More information
ADSIEDIT is part of the Windows 2000 Support Tools.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Get-ADGroupMember returns error for
domain local group to members from
remote forests
Article • 02/19/2024

This article helps fix an error that occurs when you run the Get-ADGroupMember cmdlet in
a scenario where a group has a member from a remote forest.

Applies to: Windows Server 2012 R2

Original KB number: 3171600

Symptoms
Assume that you use the Get-ADGroupMember cmdlet to identify the members of a group
in Active Directory Domain Services (AD DS). However, when you run the cmdlet for a
domain local group, the following error is returned:

Get-ADGroupMember -verbose -identity "CN=Test-Local1,OU=Test

Accounts,DC=contoso,DC=com"
Get-ADGroupMember : An unspecified error has occurred
At line:1 char:1
+ Get-ADGroupMember -verbose -identity "CN=Test-Local1,OU=Test
Accounts,DC=contoso ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (CN=Test-Local1,...bertm-w7,DC=com:ADGroup)
[Get-ADGroupMember], ADExceptionon + FullyQualifiedErrorId :
ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADGr
oupMember

７ Note

In a one-way trust, when using the Get-ADGroupMember cmdlet on a group from the
trusting forest, you receive the following errors if the group contains members from
the trusted forest:

"An unspecified error has occurred"

 "The server was unable to process the request due to an internal error"

As a workaround, use the Active Directory Users and Computers snap-in to view the
members of the group, or convert the one-way trust into a two-way trust.

Cause
This issue occurs if the group has a member from another forest whose account has
been removed from the account forest. The member is represented in the local domain
by a Foreign Security Principal (FSP). In the LDIFDE export of the group, a membership is
shown as follows:

dn: CN=Test-Local1,OU=Test Accounts,DC=contoso,DC=com

member:

CN=S-1-5-21-3110691720-3620623707-1182478234-
698540,CN=ForeignSecurityPrincipals,DC=contoso,DC=com

member:

CN=S-1-5-21-3110691720-3620623707-1182478234-
695739,CN=ForeignSecurityPrincipals,DC=contoso,DC=com

When the source account with the SID is deleted, the FSP is not updated or removed to
reflect this deletion. You must manually verify that these FSP references are removed.

Resolution
To resolve this issue, enable logging for the resolution requests that concern these SIDs
and that are performed by the Active Directory Webservice. In this way, you can identify
the accounts that fail resolution. To do this, run the Get-ADGroupMember cmdlet on the
domain controller of contoso.com (where the placeholder represents the domain in
question).

To enable logging, run the following command lines:

PowerShell

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name

LspDbgInfoLevel -Value 0x800 -Type dword -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name
LspDbgTraceOptions -Value 0x1 -Type dword -Force
Remember turning off the logging when you have the log:

PowerShell

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name

LspDbgInfoLevel -Value 0x0 -Type dword -Force

You will see a file that's named c:\windows\debug\lsp.log, which tracks the SID-Name
resolution attempts. When you rerun the cmdlet on the domain controller where the
cmdlet was executed, the file will log the failures and will resemble the following:

LspDsLookup - Entering function LsapLookupSidsLspDsLookup - LookupSids

request for 1 SIDs with level=1, mappedcount=0, options=0x0, clientRevision=2 is
being processed. SIDs are;LspDsLookup - Sids[ 0 ] = S-1-5-21-3110691720-
3620623707-1182478234-698540LspDsLookup - Requestor details: Local Machine,
Process ID = 1408, Process Name =
C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe LspDsLookup -
Entering function LsapDbLookupSidsUsingIdentityCacheLspDsLookup - 1 sids
remain unmappedLspDsLookup - Exiting function
LsapDbLookupSidsUsingIdentityCache with status 0x0LspDsLookup - LookupSids
chain request (using Netlogon) to \ dc3.northwindtraders.com for 1 sids will be made
with level=6, mappedcount=0, options=0x0, serverRevision=0. Sids
are;LspDsLookup - Sids[ 0 ] = S-1-5-21-3110691720-3620623707-1182478234-
698540 LspDsLookup - Lookup request (using Netlogon) to
\ dc3.northwindtraders.com returned with 0xc0000073 and mappedcount=0,
serverRevision=0LspDsLookup - Exiting function LsapLookupSids with status
0xc0000073

Check for the following items to verify that this is the relevant section for this problem
(in the preceding sample output):

The process is C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.

The request is sent to a domain controller in a different forest, for example,
northwindtraders.com .

The return code is 0xc0000073, which equals STATUS_NONE_MAPPED.

To find the FSP object, run the following command (replace domain names and SIDs):

PowerShell

get-AdObject -Searchbase "CN=ForeignSecurityPrincipals,DC=contoso,DC=com" -

ldapfilter "(cn=S-1-5-21-3110691720-3620623707-1182478234-698540)"
The original object for this FSP no longer exists, so you can safely delete it. Doing this
will also remove it from all groups that it's a member of:

PowerShell

get-AdObject -Searchbase "CN=ForeignSecurityPrincipals,DC=contoso,DC=com" -

ldapfilter "(cn=S-1-5-21-3110691720-3620623707-1182478234-698540)" | Remove-
AdObject -Confirm:$false

References
How SIDs and account names can be mapped in Windows

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to change display names of Active
Directory users
Article • 02/19/2024

This article describes how to change display names of Active Directory (AD) users.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 250455

Summary
When a new user is created in Active Directory, the Full name field is always generated
in FirstName LastName format. In turn, this field sets the Display Name field on creation,
so you end up with a FirstName LastName formatted global address list.

You can make this change by using the Adsiedit utility. Adsiedit not only changes the
default way the Display Name field is built, but also the Full Name (that is, the "cn") field,
that's why users appear in the chosen format when you look in the Users and
Computers snap-in.

ADSIEdit Instructions

２ Warning

If you use the ADSI (Active Directory Service Interfaces) Edit snap-in, the LDP utility,
or any other LDAP (Lightweight Directory Access Protocol) version 3 client, and you
incorrectly modify the attributes of Active Directory objects, you can cause serious
problems. These problems may require you to reinstall Microsoft Windows 2000
Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft
Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee
that problems that occur if you incorrectly modify Active Directory object attributes
can be solved. Modify these attributes at your own risk.

1. Insert your Windows 2000 Server CD.

2. Navigate to the \support\tools directory.

3. Double-click on the Support.cab file.

 4. Locate the files adsiedit.msc and adsiedit.dll. Extract them to your
%systemroot%\system32 directory.

5. Run regsvr32 adsiedit.dll.

6. Start Microsoft Management Console (MMC), and then add the ADSI Edit snap-in.

7. Right-click the top node, and then select Connect to.

8. Change the Naming Context to Configuration Container, and then select OK to

bind and authenticate.

9. Expand the Configuration Container node, and then expand the Configuration
node.

10. Expand the cn=DisplaySpecifiers node, and then double-click CN=409.

７ Note

409 is the Locale ID for U.S. English. If you are in a multi-lingual environment,
you may need to make changes to the other codes. Most of the Asian codes
are already set.

The International Telecommunication Union (ITU) and International Organization

for Standardization (ISO) define the code pages. For more information, visit the ITU
Web pages

11. In the right-hand pane, open the properties for CN=user-Display.

12. Scroll to the createDialog optional property.

13. Set the attribute to %<sn>.%<givenName>. Make sure that you select Set.

７ Note

The only tokens that can be formatted in the dislayName are %<sn>, %
<givenName>, and %<initials>.

14. Select OK to close the dialog box.

15. In Active Directory Users and Computers, create a new User; the Full Name (and
thus, the Display Name) are built in accordance with your rule.

Making these changes can have adverse effects.

Notes
The instructions show you how to modify user objects. There's a separate setting
for Contacts--change step 11 to "contact-Display".
You don't need to close the Users and Computers snap-in; changes are picked up
automatically.
In multi-domain controller environments, you may need to wait for replication to
complete before the user interface picks up the changes.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft doesn't guarantee the
accuracy of this third-party contact information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to enable Kerberos event logging
Article • 02/19/2024

This article describes how to enable Kerberos event logging.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows 10, version 1809 and later versions, Windows 7 Service Pack 1
Original KB number: 262177

Summary
Windows 7 Service Pack 1, Windows Server 2012 R2, and later versions offer the
capability of tracing detailed Kerberos events through the event log. You can use this
information when troubleshooting Kerberos.

） Important

The change in logging level will cause all Kerberos errors to be logged in an event.
In the Kerberos protocol, some errors are expected based on the protocol
specification. As a result, enabling Kerberos logging may generate events
containing expected false-positive errors even when there are no Kerberos
operational errors.

Examples of false-positive errors include:

1. KDC_ERR_PREAUTH_REQUIRED is returned on the initial Kerberos AS request. By

default, the Windows Kerberos Client is not including pre-authentication
information in this first request. The response contains information about the
supported encryption types on the KDC, and in case of AES, the salts to be used to
encrypt the password hashes with.

Recommendation: Always ignore this error code.

2. KDC_ERR_S_BADOPTION is used by the Kerberos client to retrieve tickets with

particular options set, for example, with certain delegation flags. When the
requested type of delegation is not possible, this is the error that is returned. The
Kerberos client would then try to get the requested tickets using other flags, which
may succeed.

Recommendation: Unless you are trouble-shooting a delegation problem, ignore

this error.
 3. KDC_ERR_S_PRINCIPAL_UNKNOWN may be logged for a wide variety of problems
with the application client and server liaison. The cause can be:

Missing or duplicate SPNs registered in AD.

Incorrect server names or DNS suffixes used by the client, for example, the
client is chasing DNS CNAME records and use the resulting A record in SPNs.
Using non-FQDN server names that need to be resolved across AD forest
boundaries.

Recommendation: Investigate the use of server names by the applications. It is

most likely a client or server configuration problem.

4. KRB_AP_ERR_MODIFIED is logged when an SPN is set on an incorrect account, not

matching the account the server is running with. The second common problem is
that the password between the KDC issuing the ticket and the server hosting the
service is out of sync.

Recommendation: Similar to KDC_ERR_S_PRINCIPAL_UNKNOWN, check whether

the SPN is correctly set.

Other scenarios or errors require the attention of the System or Domain Administrators.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

Enable Kerberos event logging on a specific

computer
1. Start Registry Editor.

2. Add the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Para
meters
Registry Value: LogLevel
 Value Type: REG_DWORD
Value Data: 0x1

If the Parameters subkey does not exist, create it.

７ Note

Remove this registry value when it is no longer needed so that performance is

not degraded on the computer. Also, you can remove this registry value to
disable Kerberos event logging on a specific computer.

3. Quit Registry Editor. The setting will become effective immediately on Windows
Server 2012 R2, Windows 7, and later versions.

4. You can find any Kerberos-related events in the system log.

More information
Kerberos event logging is intended only for troubleshooting purpose when you expect
additional information for the Kerberos client-side at a defined action timeframe.
Restated, kerberos logging should be disabled when not actively troubleshooting.

From a general point of view, you may receive additional errors that are correctly
handled by the receiving client without user or admin intervention. Restated, some
errors captured by Kerberos logging don't reflect a severe problem that must be solved
or even can be solved.

For example, an event log 3 about a Kerberos error that has the error code 0x7
KDC_ERR_S_PRINCIPAL_UNKNOWN for Server Name cifs/<IP address> will be logged
when a share access is made against a server IP address and no server name. If this error
is logged, the Windows client automatically tries to fail back to NTLM authentication for
the user account. If this operation works, receive no error.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to reset the Directory Services
Restore Mode administrator account
password in Windows Server
Article • 02/19/2024

This article describes how to reset the Directory Services Restore Mode (DSRM)
administrator password for any server in your domain without restarting the server in
DSRM.

Applies to: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2,
Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server
2022
Original KB number: 322672

Summary
Microsoft Windows 2000 uses the Setpwd utility to reset the DSRM password. In newer
versions of Microsoft Windows Server, that functionality has been integrated into the
NTDSUTIL tool. Note that you can't use the procedure that is described in this article if
the target server is running in DSRM. A member of the Domain Administrators group
sets the DSRM administrator password during the promotion process for the domain
controller. You can use Ntdsutil.exe to reset this password for the server on which you're
working, or for another domain controller in the domain.

Reset the DSRM administrator password

1. Click Start > Run, type ntdsutil, and then click OK.

2. At the Ntdsutil command prompt, type set dsrm password.

3. At the DSRM command prompt, type one of the following lines:

To reset the password on the server on which you're working, type reset
password on server null. The null variable assumes that the DSRM password is
being reset on the local computer. Type the new password when you're
prompted. Note that no characters appear while you type the password.

-or-
 To reset the password for another server, type reset password on server
servername, where servername is the DNS name for the server on which
you're resetting the DSRM password. Type the new password when you're
prompted. Note that no characters appear while you type the password.

4. At the DSRM command prompt, type q.

5. At the Ntdsutil command prompt, type q to exit.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Phantoms, tombstones, and the
infrastructure master
Article • 02/19/2024

This article describes how phantoms are used in Windows Server.

Applies to: Windows Server 2012 R2

Original KB number: 248047

More information
Phantom objects are low-level database objects that Active Directory uses for internal
management operations. Two common instances of phantom objects are as follows:

An object that has been deleted.

The tombstone lifetime has passed, but references to the object are still present in
the directory database.

A domain local group has a member user from another domain in the Active
Directory forest. Phantom objects are special kinds of internal database tracking
objects and can't be viewed through any LDAP or Active Directory Service
Interfaces (ADSI).

Object deletion
When an object is deleted from the active directory, the object follows the following
process.

Stage 1: Normal objects

The object first exists as a typical Active Directory object. You can view the object by
using the appropriate Active Directory and through the LDAP interface.

The object moves to Stage 2 when the object is deleted by an administrator or through
another means.

Stage 2: Deleted objects before the tombstone lifetime expires

The object now exists as a Tombstone object for the length of the tombstone lifetime
interval. While the object maintains some of its original form:

Object is still a typical (non-phantom) object.

The objectGUID attribute has not changed.

The object has also been significantly modified from its original form:

The object moves to the DeletedObjects container (unless the object is flagged as
a special system object)
The object's DN attribute contains (esc)DEL:GUID
Most of the object's other attributes have been removed completely.

The schema of the object determines the attributes that are removed, and the attributes
that are kept after deletion. The designation of each attribute for an object class can be
changed.

The objects can't be seen from normal Active Directory management tools. You may
configure a low-level LDAP interface like LDP to view these objects.

The object moves to one of two possible states (Stage 3 or 4) when the tombstone
lifetime has expired. The default tombstone lifetime is 60 days.

Stage 3: (Normal) object is removed from the active directory

database Completely
If there no references to this object remain in the Active Directory, the row in the
database is completely removed and there are no traces of the object left.

Stage 4: (External references still exist) phantom object

If there are any references to this object remain in the Active Directory, the object itself
is deleted and a phantom object is created in its place until those references are
removed. This phantom object is deleted when all references to the object are removed.

You can't view these phantom objects through any LDAP or ADSI interface.

７ Note

During the removal of the global catalog from a domain controller, the read-only
objects that are removed from the global catalog do not go through the deletion
 process. They are immediately removed from the database and any references to
them are unaffected.

Cross-domain references and the infrastructure master

role
Certain types of groups in an active directory domain can contain accounts from trusted
domains. To make sure that the names in the group's membership are accurate, the user
object's GUID is referenced in the membership of the group. When Active Directory
Tools displays these groups that have users from foreign domains, they must be able to
display the accurate and current name of the foreign user without relying on immediate
contact with a domain controller for the foreign domain or a global catalog.

Active Directory uses a phantom object for cross-domain group-to-user references on

Domain Controllers that aren't Global Catalogs. This phantom object is a special kind of
object that can't be viewed through any LDAP interface.

Phantom records contain a minimal amount of information to let a domain controller

refer to the location in which the original object exists. The index of phantom objects
contains the following information about the cross-referenced object:

Distinguished name of the object

Object GUID
Object SID

During the addition of a member from a different domain to a local user group, the
local domain controller that is performing the addition to the group creates the
phantom object for the remote user.

If you change the foreign user's name or delete the foreign user, the phantoms must be
updated or removed in the group's domain from every domain controller in the domain.
The domain controller holding the infrastructure master (IM) role for the group's
domain handles any updates to the phantom objects.

You can't view these phantom objects through any LDAP or ADSI interface.

Phantom update and cleanup processes

If the object to which a phantom object refers has been deleted, the phantom object
must be removed from the local domain (cleaned up). A phantom object must also be
updated if the name of the original object changes so that the group membership list
for the group has an accurate listing. The domain controller holding the IM role in a
domain handles both operations for its domain.

The IM compares the information about the phantom objects against the latest versions
on a global catalog server and makes changes to the phantoms as needed. The interval
can be customized by adding the Days per database phantom scan registry entry to the
following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

To make this change, note the following:

Registry entry: Days per database phantom scan

Type: DWORD

Default value: 2

Function: Specifies the interval in days that the IM compares the phantom objects
against the latest versions on a global catalog server.

７ Note

The minimum DWORD value is 1 day.

After the IM determines that the original object that the phantom object refers to has
changed or been deleted:

The IM creates an infrastructureUpdate object in the

CN=Infrastructure,DC=DomainName,DC=... container and immediately deletes it.

This (tombstone) object is replicated by special proxy to the other domain

controllers in the domain that aren't global catalog servers.

If the original object is renamed, the value in the DNReferenceUpdate attribute of

the infrastructureUpdate contains the new name. If the original object was deleted,
the deleted objects DN is changed so that (esc)DEL:GUID is appended to the
original DN.

The domain controllers then take the information in the infrastructureUpdate

objects and apply the changes to the local copies of their phantom objects
accordingly.

If the original object has been deleted, the receiving domain controllers delete the local
phantom object and remove the corresponding attribute that references it (such as the
member attribute on a group).

７ Note

Global catalog servers in the group's domain receive the special proxy replication
for the objects in the CN=Infrastructure,DC=DomainName,DC=... container.
However, they ignore them because a read-only copy of the object itself is already
instantiated in the local database. So they do not need the phantom to track the
group membership and will learn about the removal of the object with regular AD
replication.

Global catalog and infrastructure master role conflict

If the IM Flexible Single Master Operation (FSMO) role holder is also a global catalog
server, the phantom indexes are never created or updated on that domain controller.
(The FSMO is also known as the operations master.) This behavior occurs because a
global catalog server contains a partial replica of every object in Active Directory. The IM
does not store phantom versions of the foreign objects because it already has a partial
replica of the object in the local global catalog.

For this process to work correctly in a multidomain environment, the infrastructure

FSMO role holder can't be a global catalog server. Be aware that the first domain in the
forest holds all five FSMO roles and is also a global catalog. Therefore, you must transfer
either role to another computer as soon as another domain controller is installed in the
domain if you plan to have multiple domains.

If the infrastructure FSMO role and global catalog role reside on the same domain
controller, you continually receive event ID 1419 in the directory services event log.

There are two conditions where placing the Infrastructure Master role on a Global
Catalog is OK:

1. All Domain Controllers in the Domain are Global Catalog. In this situation, there
can't be any phantoms to clean up.
2. The Forest Mode is "Windows Server 2008 R2" and the Recycle Bin feature is
activated. In this mode, removed object links aren't phantomized but set to a
different state, and still present in the database.

For information on the AD Recycle Bin, see: Scenario Overview for Restoring Deleted
Active Directory Objects
For more information about FSMO role placement in the domain and how to transfer an
FSMO role to another domain controller, click the following article numbers to view the
articles in the Microsoft Knowledge Base:

223346 FSMO placement and optimization on Active Directory domain controllers

223787 Flexible Single Master Operation transfer and seizure process

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Information about devices from
Riverbed Technology that are
configured as RODCs
Article • 02/19/2024

This article describes the information about devices from Riverbed Technology that are
configured as RODCs.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 3192506

Summary
Microsoft offers commercially reasonable support for its software. If we can't resolve a
customer's problem when third-party software is involved, we'll request the involvement
of the third-party vendor. Depending on the scenario, Microsoft Support might ask the
customer to remove or reconfigure the component from the configuration to see
whether the problem persists. If the problem is confirmed to be caused or greatly
influenced by the third-party component, the component's vendor must be involved in
helping to resolve the problem. This policy also applies to devices from Riverbed
Technology, Inc.

More information
Riverbed Technology, Inc. makes intermediate network devices that aim to optimize
network traffic network by compressing and otherwise shaping traffic that travels over
loaded WAN connections.

The devices can intercept end-user SMB sessions and can achieve performance gains if
the Riverbed device can generate a valid signed checksum of the payload in the security
context of the server. To accomplish it, the device sets itself up as a trusted server
instance so that it can act as, and for a server that's in the scope of the network traffic
that's being optimized.

The current deployment approach (September 2016) involves either enabling read-only
domain controller (RODC) UserAccountControl settings on a regular computer account;
or using a highly privileged service account that has Replicate Directory Changes All
permissions. In some configurations, both types of accounts will be used. This approach
has a number of security consequences, which may not be obvious at the time of
configuration.

Expectations
When a computer account is set up as domain controller, it receives certain flags and
group memberships that allow it to perform security and Active Directory-specific
procedures. These include the following ones:

The account can impersonate any user in the Active Directory except those who
are marked as "sensitive and not allowed for delegation." Because of Kerberos
Protocol transition, the account can do this even without having the password for
impersonation-allowed users.
The "Replicate Directory Changes All" permission allows the device to access the
password hashes of all users in the domain, including sensitive accounts like
KrbTgt, Domain Controller accounts, and Trust relationships.
The account is eligible for monitoring as a domain controller by monitoring
solutions.
Based on the existence of these flags, "callers" (including administration tools)
expect a Windows-based server and try to access or interoperate with entities
representing themselves as domain controllers. This includes services that are
based on WMI, WinRM, LDAP, RPC, and Active Directory Web Services. Similarly,
applications, member computers, and partner domain controllers expect entities
that represent themselves as domain controllers to interact and respond in a
consistent, well-defined manner.

Security implications
As with any other computing device in a networking environment, Riverbed devices may
come under attack by malware. Because of their ability to impersonate Active Directory
users, Riverbed devices are attractive targets for such attacks.

Microsoft strongly recommends using the same level of physical and network protection
and auditing as you use for your Read-Write Domain Controllers (RWDCs).
Administration of these devices should follow current guidance regarding securing
privileged access at Securing privileged access. If you currently use Riverbed devices in
locations that aren't secure enough for RWDCs, we strongly recommend that you review
the placement of these devices.

Operational implications
Domain controllers have a special flag and additional objects associated with their
accounts that provide unique role identification. These are as follows:

UserAccountControl values on the domain controller's computer account

RWDC 0x82000 (Hex)
RODC 0x5011000 (Hex)
NTDS Settings object in the configuration container, within the domain controller's
site

Tools, services, and applications may query these attributes to generate a list of domain
controllers and then perform an operation, such as query, that assumes a normal DC
response. Riverbed devices don't implement the full set of Windows domain controller
services and do not respond to normal DC queries. Microsoft is aware of the following
problems that are caused by this configuration:

Migration of sysvol replication from File Replication Service (FRS) to Distributed

File System Replication (DFSR)

When a domain has transitioned to the Windows Server 2008 domain mode or
later, Microsoft recommends that you migrate the sysvol replication engine from
FRS to DFSR.

The DFSR migration tool (dfsrMig.exe) builds an inventory of all domain controllers
in the domain when the migration begins. This includes the DC-like accounts used
by the Riverbed devices. Riverbed devices don't respond to the changes to Active
Directory objects that are required for the migration to progress. So the DFSR
migration tool fails to complete, and administrators must ignore errors to proceed
to the next step in the sysvol migration. These false errors might overlap with
actual errors from real Windows Server-based computers.

Because sysvol migration cannot be completed when there's a Riverbed device in

the domain, Microsoft recommends that you remove Riverbed devices during a
migration.

Monitoring tools

Most server monitoring tools on the market support using Active Directory queries
to populate an inventory of client and server systems. Tools that leverage the
UserAccountControl or NTDS Setting object to find domain controllers may
incorrectly identify the Riverbed accounts as domain controller accounts. As a
result, Riverbed devices appear as manageable servers in this inventory list.

Many solutions then allow the remote deployment of monitoring agents or let you
query the device remotely for diagnostic information. However, Riverbed devices
 don't support these interfaces, and the monitoring tools report them as triggering
failures.

Contact Riverbed for information about how to successfully monitor Riverbed

devices through the monitoring tool of your choice. If no monitoring tool is
available, investigate the option of excluding the device from monitoring.
Microsoft strongly recommends monitoring device health, given the sensitivity of
the functions such devices perform.

Group Policy Administration Tool (GPMC)

In Windows Server 2012 and later versions, the GPMC can show the replication
status of Group Policy settings in the domain or per policy. Riverbed devices are
included in the list of eligible accounts for this status check.

However, the information that's returned to GPMC by Riverbed is incomplete,

because they have no NTDS Settings object in the Active Directory Configuration
Partition. Because GPMC doesn't expect this, the GPMC console crashes.

To prevent this failure, deploy the following update on your administration

computers:

Group Policy Management Console crashes when you click the target domain

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to let non-administrators view the
Active Directory deleted objects
container
Article • 02/19/2024

This article explains how to change permissions so that non-administrators can view the
Active Directory deleted objects container.

Applies to: Windows Server 2012 R2

Original KB number: 892806

Summary
When an Active Directory object is deleted, a small part of the object stays in the
deleted objects container for a specified time. It stays there so that other domain
controllers that are replicating changes will become aware of the deletion. By default,
only the System account and members of the Administrators group can view the
contents of this container. This article describes how to modify the permissions on the
deleted objects container.

You may have to modify the permissions on the deleted objects container if the
following conditions are true:

You have enterprise applications or services that bind to Active Directory with a
non-System account or a non-Administrator account.
These enterprise applications or services poll for directory changes.

More information
To modify the permissions on the deleted objects container so that non-administrators
can view this container, use the DSACLS.exe program. The DSACLS.exe program is
included with the Active Directory Application Mode (ADAM) Administration Tools.

For Windows Server 2008 and newer the tool is included in the operating system.

For Windows 2000 and Server 2003 you can get this done by obtaining and installing
the ADAM Administration Tools, follow these steps:

1. Download the ADAM retail package.

 For more information about how to download Microsoft Support files, click the
following article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services Microsoft
scanned this file for viruses. Microsoft used the most current virus-detection
software that was available on the date that the file was posted. The file is stored
on security-enhanced servers that help prevent any unauthorized changes to the
file.

７ Note

This version of the ADAM Administration Tools is an upgrade from the version
in the Windows Server 2003 Support Tools. This version of the ADAM
Administration Tools is supported by Microsoft Windows Server 2003,
Standard Edition; Microsoft Windows Server 2003, Enterprise Edition;
Microsoft Windows Server 2003, Datacenter Edition; and Microsoft Windows
XP Professional.

2. To extract the contents of the file that you downloaded in step 1, double-click the
file, and then specify a directory when you are prompted.

3. In the directory that you extracted the file to in step 2, double-click the
Adamsetup.exe program to start the Active Directory Application Mode Setup

Wizard, and then click Next.

4. Review and accept the license terms, and then click Next.

5. Select ADAM administration tools only, and then click Next.

6. Review your selections, and then click Next.

7. When Setup has concluded, click Finish.

After you have installed the ADAM Administration Tools, you can modify the
permissions on the deleted objects container. To do this, follow these steps:

1. Log on with a user account that is a member of the Domain Admins group.

2. Click Start, point to All Programs, point to ADAM, and then click ADAM Tools
Command Prompt.

3. At the command prompt, type a command that is similar to the following example:
dsacls "CN=Deleted Objects,DC=Contoso,DC=com" /takeownership.
 When you type this command, use the name of the deleted objects container
for your domain.

Each domain in the forest will have its own deleted objects container. Output
that is similar to the following example should be displayed:

Owner: Contoso\Domain Admins

Group: NT AUTHORITY\SYSTEM
Access list:
{This object is protected from inheriting permissions from the parent}
Allow BUILTIN\Administrators SPECIAL ACCESS
LIST CONTENTS
READ PROPERTY
Allow NT AUTHORITY\SYSTEM SPECIAL ACCESS
DELETE
READ PERMISSONS
WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
DELETE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
The command completed successfully

4. To grant a security principal permission to view the objects in the deleted objects
container, type a command that is similar to the following example: dsacls
"CN=Deleted Objects,DC=Contoso,DC=com" /g CONTOSO\EricLang:LCRP

Output that is similar to the following example should be displayed:

Owner: CONTOSO\Domain Admins

Group: NT AUTHORITY\SYSTEM
Access list:
{This object is protected from inheriting permissions from the parent}
Allow BUILTIN\Administrators SPECIAL ACCESS
LIST CONTENTS
READ PROPERTY
Allow NT AUTHORITY\SYSTEM SPECIAL ACCESS
DELETE
READ PERMISSONS
 WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
DELETE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
Allow CONTOSO\EricLang SPECIAL ACCESS
LIST CONTENTS
READ PROPERTY
The command completed successfully

In this example, the user "CONTOSO\EricLang" has been granted List Contents and Read
Property permissions on the deleted objects container in the "CONTOSO" domain. These
permissions let this user view the contents of the deleted objects container, but do not
let this user make any changes to objects in the container. These permissions are
equivalent to the default permissions that are granted to the Administrators group. By
default, only the System account has permission to modify objects in the deleted objects
container.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Linux accounts can't get AES-encrypted
tickets in AD DS
Article • 02/19/2024

Symptoms
In an Active Directory Domain Services (AD DS) environment, Linux-integrated accounts
receive RC4-encrypted tickets instead of Advanced Encryption Standard (AES)-encrypted
tickets when they use Kerberos authentication. To troubleshoot this issue, go to the Key
Distribution Center (KDC).

In the log of Event ID 4769, the value of Ticket Encryption Type is 0x17 for the
affected computer. That corresponds to an RC4 encryption type.

Output

Source: Microsoft-Windows-Security-Auditing
Event ID: 4769
Task Category: Kerberos Service Ticket Operations
Level: Information
Computer: MyDC.contoso.com
Description:
A Kerberos service ticket was requested.
…
Service Information:
Service Name: MYLINUX
Service ID: CONTOSO\MYLINUX
Network Information:
Client Address: ::ffff:10.20.30.40
Client Port: 57499
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -

After you run the klist command, the value of KerbTicket Encryption Type is
RSADSI RC4-HMAC(NT). That indicates that the encryption type is RC4.

Output

C:\> Klist get [email protected]

Current LogonId is 0:0xb532bccf
A ticket to [email protected] has been retrieved successfully.
Cached Tickets: (2)
 …
#1> Client: [email protected]
Server: [email protected]
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent
ok_as_delegate name_canonicalize
Start Time: <DateTime> (local)
End Time: <DateTime> (local)
Renew Time: <DateTime> (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: MyDC.Contoso.com

７ Note

Setting the msDS-SupportedEncryptionTypes attribute value to 24 (0x18) to force

AES256 or AES128 encryption doesn't solve the issue. Similarly, disabling RC4
encryption and enabling AES encryption by using the Network security: Configure
encryption types allowed for Kerberos Group Policy Object (GPO) doesn't resolve
the issue.

Cause
This issue occurs because the operatingSystemVersion attribute value of Linux is set to
3.10.0x. AD DS reads the attribute value from left to right, stopping at the first decimal
point (.) If the first character of the value is a digit and the value is less than six, the KDC
determines that the requesting operating system might not support newer encryption
types. In this case, the value is 3. Therefore, the KDC ignores msDS-
SupportedEncryptionTypes and uses RC4 to encrypt the ticket.

This behavior is by design. It accommodates older versions of Windows (including

Windows 2000 Server, Windows Server 2003, and Windows XP) that do not support the
msDS-SupportedEncryptionTypes attribute or the AES encryption type. The following
specifications describe this design:

If the server or service has a KerbSupportedEncryptionTypes attribute that's

populated by using supported encryption types<58>, then the KDC should<59>
return in the encrypted part ([Referrals-11] Appendix A) of TGS-REP message, a
PA-DATA structure that has padata-type set to PA-SUPPORTED-ENCTYPES [165]
to indicate which encryption types (section 2.2.7) are supported by the server or
service. If it doesn't, the KDC should<60> check the server or service account's
UseDESOnly flag.
 <58> Section 3.3.5.7: If the account is for a computer object, and the value of
OperatingSystemVersion ([MS-ADA3] section 2.56) is less than 6,
KerbSupportedEncryptionTypes is treated as if it's not populated. This approach
makes sure that newer encryption types aren't attempted if the requesting
computer runs Windows 2000, Windows XP, or Windows Server 2003. These
systems don't support setting KerbSupportedEncryptionTypes.

For more information, see the specifications in TGS Exchange and Appendix A <58> of
Kerberos protocol extensions.

Solution
To resolve this issue, use one of the following methods:

Remove the operatingSystemVersion attribute.

Set the attribute value so that the first character isn't a numeric digit. For example,
set the value to Linux 3.10.0x instead of 3.10.0x.
Upgrade to an updated system version that complies with the specifications.
Obtain the update from the third-party vendor (for example, Linux).

For more information about how the KDC selects the encryption type, see Encryption
Type Selection in Kerberos Exchanges.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to modify the filtered properties of
an object in ACL Editor for Directory
Services objects
Article • 02/19/2024

This article describes how to modify the filtered properties of an object in ACL Editor for
Directory Services objects.

Applies to: Windows Server 2012 R2

Original KB number: 296490

Summary
The Per-Property Permissions tab for a user object that you view through Active
Directory Users and Computers may not display every property of the user object. This is
because the user interface for access control filters out object and property types to
make the list easier to manage. While the properties of an object are defined in the
schema, the list of filtered properties that are displayed is stored in the Dssec.dat file
that is located in the %systemroot%\System32 folder on all domain controllers. You can
edit the entries for an object in the file to display the filtered properties through the user
interface.

Filtered properties in the Dssec.dat file

A filtered property looks like this in the Dssec.dat file:

[User]
propertyname=7

To display the read and write permissions for a property of an object, you can edit the
filter value to display one or both of the permissions. To display both the read and write
permissions for a property, change the value to zero (0):

[User]
propertyname=0

To display only the write permission for a property, change the value to 1:

[User]
propertyname=1
To display only the read permissions for a property, change the value to 2:

[User]
propertyname=2

７ Note

After you edit the Dssec.dat file, you must quit and restart Active Directory Users
and Computers to see the properties that are no longer filtered.

７ Note

The ACL Editor called by ADSIEdit seems to ignore the contents of DSSEC.DAT and
shows all attributes by default.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows 7 RSAT: Multiple tabs are
missing when viewing user properties in
Active Directory Users and Computers
Article • 02/19/2024

This article provides a solution to an issue where multiple tabs are missing when you
view user properties in Active Directory Users and Computers.

Applies to: Windows 7 Service Pack 1

Original KB number: 2028835

Symptoms
After installing the Remote Server Administration Tools for Windows 7 (Windows 7
RSAT) on a domain-joined Windows 7 client, you add the Role Administration Tools for
"AD DS Snap-ins and Command-line Tools":

You then start the Active Directory Users and Computers snap-in (DSA.MSC) and
examine the properties of a user. You notice that some or all of the following tabs are
missing: Published Certificates Password Replication Object Security Attribute Editor
Environment Sessions Remote Control Remote Desktop Services Profile Personal Virtual
Desktop UNIX Attributes Dial-in These tabs are visible when running DSA.MSC on the
console of Windows Server 2008 R2 servers.
Cause
Multiple root causes exist. See the Resolution section for more information.

Resolution
1. Enable "Advanced Features" via the View menu. This will show at least the
following new tabs:
Published Certificates
Password Replication
Object
Security
Attribute Editor

2. If still not seeing the "Environment", "Sessions", "Remote Control", "Personal Virtual
Desktop", and "Remote Desktop Services Profile" tabs, add the following RSAT
feature: "Remote Desktop Services Tools". Then restart DSA.MSC and enable the
Advanced View to make these tabs appear.

3. If still not seeing the "UNIX Attributes" tab, add the following RSAT feature: "Server
for NIS Tools". Restart DSA.MSC with Advanced View enabled to make this tab
appear.
 4. The "Dial-In" tab will always be missing, as its libraries are not included in Remote
Server Administration Tools for Windows 7.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Naming conventions in Active Directory
for computers, domains, sites, and OUs
Article • 02/19/2024

This article describes the naming conventions for computer accounts in Windows,
NetBIOS domain names, DNS domain names, Active Directory sites, and organizational
units (OUs) that are defined in Active Directory Domain Services (AD DS).

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
Original KB number: 909264

Summary
This article discusses the following topics:

The valid characters for names

The minimum and maximum name lengths
Reserved names
Names that we don't recommend
General recommendations for supporting AD DS in small, medium, and large
deployments

All objects that are named within AD DS, Active Directory Application Mode (ADAM), or
Active Directory Lightweight Directory Services (AD LDS) are subject to a name matching
process that's based on the algorithm that's described in the following article:

You can't add a user name or an object name that only differs by a character with a
diacritic mark .

In that article, this naming convention applies to computer names, OU names, and site
names.

Computer names

NetBIOS computer names

Allowed characters: NetBIOS computer names can contain all alphanumeric
characters except for the extended characters that appear in the following
Disallowed characters list. Names can contain a period, but names can't start with
a period.

７ Note

Microsoft Windows NT allows non-DNS names to have period. Periods

shouldn't be used in Windows. If you're upgrading a computer whose
NetBIOS name contains a period, change the computer name. For more
information, see Special characters later in this section.

Disallowed characters: NetBIOS computer names can't contain the following

characters:
backslash (\)
slash (/)
colon (:)
asterisk (*)
question mark (?)
quotation mark (")
less than sign (<)
greater than sign (>)
vertical bar (|)
Computers that are members of an Active Directory domain can't have names
that contain only numerals. This is a DNS restriction.

For more information about the NetBIOS name syntax, see NetBIOS name syntax.

Name length rules:

Minimum name length: One character
Maximum name length: 15 characters

７ Note

The 16th character of a NetBIOS computer name is reserved for identifying

the functionality that is installed on the registered network device.

Reserved names: See Table of reserved words.

Special characters: Period (.)

A period character divides the name into a NetBIOS scope identifier and the
computer name. The NetBIOS scope identifier is an optional string of characters
that identify logical NetBIOS networks that run on the same physical TCP/IP
 network. For NetBIOS to work between computers, the computers must have the
same NetBIOS scope identifier and unique computer names.

The use of NetBIOS scopes in names is a legacy configuration. It shouldn't be used

in Active Directory forests. For more information about NetBIOS scopes, see the
following Request for Comments (RFC) documents:
RFC 1001: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport:
Concepts and Methods
RFC 1002: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport:
Detailed Specifications

DNS host names

Allowed characters: DNS names can contain only alphabetic characters (A-Z),
numeric characters (0-9), the minus sign (-), and the period (.). Period characters
are allowed only when they're used to delimit the components of domain style
names.

Windows domain name system (DNS) supports Unicode characters. Other

implementations of DNS don't support Unicode characters. Avoid Unicode
characters if queries will be passed to the servers that use non-Microsoft
implementations of DNS. For more information, see the following RFCs:
RFC 952: DOD Internet Host Table Specification
RFC 1123: Requirements for Internet Hosts--Application and Support

Disallowed characters: DNS host names can't contain the following characters:
comma (,)
tilde (~)
colon (:)
exclamation point (!)
at sign (@)
number sign (#)
dollar sign ($)
percent (%)
caret (^)
ampersand (&)
apostrophe (')
period (.)
parentheses (())
braces ({})
underscore (_)
white space (blank)
 ７ Note

The underscore has a special role. It's permitted for the first character in
SRV records by RFC definition. However, newer DNS servers might also
allow it anywhere in a name. For more information, see Complying with
Name Restrictions for Hosts and Domains.

The DNS host name registration process substitutes a hyphen (-)

character for invalid characters.

Name length rules:

The FQDN of a domain controller must be smaller than 155 bytes.
Minimum name length: Two characters
Maximum name length: 63 characters

７ Note

If you use UTF-8 (Unicode) characters, remember that some UTF-8

characters exceed one octet in length. In that case, you can't determine
the size of a name by counting the characters. The maximum size of the
host name and of the fully qualified domain name (FQDN) is 63 bytes
per label and 255 bytes per FQDN.

Windows doesn't permit computer names that exceed 15 characters,

and you can't specify a DNS host name that differs from the NetBIOS
host name. However, you might create host headers for a website that's
hosted on a computer. In that case, the host headers are subject to this
rule.

Additional rules for DNS host names:

All characters preserve their case formatting except for American Standard Code
for Information Interchange (ASCII) characters.
The first character in a DNS host name must be alphabetic or numeric.
The last character must not be a minus sign or a period.
Two-character security descriptor definition language (SDDL) user strings that
are listed in well-known SIDs list can't be used. Otherwise, import, export, and
take control operations fail.
 Computers that are members of an Active Directory domain can't have names
that contain only numerals. This is a DNS restriction.

Reserved names per RFC: For more information, see RFC 952 .
GATEWAY
GW
TAC

Reserved names in Windows: See Table of reserved words.

Best practices: When you create names for computers in a Windows DNS
infrastructure, follow these guidelines:

Use a computer name that's easy for users to remember.

Identify the owner of the computer in the computer name.

Use a name that describes the purpose of the computer.

Match the Active Directory domain name to the primary DNS suffix of the
computer name. For more information, see Disjointed namespaces.

Use a unique name for every computer in your organization. Avoid using the
same computer name for computers in different DNS domains.

Use ASCII characters. This guarantees interoperability with computers that aren't
running Windows.

When you use ASCII characters, don't use character case to indicate the owner
or the purpose of a computer. For ASCII characters, DNS isn't case-sensitive.
Windows and Windows applications don't preserve case in all situations.

Use only the characters that are listed in RFC 1123 . These characters include
A-Z, a-z, 0-9, and the hyphen (-). Windows DNS allows most UTF-8 characters in
names. Don't use extended ASCII or UTF-8 characters unless all the DNS servers
in your environment support them.

Domain names
The following sections describe NetBIOS domain names and DNS domain names.

NetBIOS domain names

Allowed characters: NetBIOS domain names can contain all alphanumeric
characters except for the extended characters that appear in the Disallowed
characters list. Names can contain a period, but names can't start with a period.

７ Note

Microsoft Windows NT allows non-DNS names to have period. Periods

shouldn't be used in Active Directory NetBIOS domain names. If you're
upgrading a computer whose NetBIOS name contains a period, change the
name by migrating the domain to a new domain structure. Don't use periods
in new NetBIOS domain names.

The ampersand (&) character in NetBIOS domain names was allowed

previously and is supported for historical purposes only. Don't create new
Active Directory domains whose NetBIOS domain names contain ampersand
(&) characters.

Disallowed characters: The DNS host name checking function verifies NetBIOS
domain names. These names can't contain the following characters:
comma (,)
tilde (~)
colon (:)
exclamation point (!)
at sign (@)
number sign (#)
dollar sign ($)
percent (%)
caret (^)
apostrophe (')
period (.)
parentheses (())
braces ({})
underscore (_)
white space (blank)
backslash (\)
slash (/)

７ Note
 Computers that are members of an Active Directory domain can't have
names that contain only numeral. This is a DNS restriction.

Name length rules:

Minimum name length: One character
Maximum name length: 15 characters

７ Note

The 16th character of the name is reserved for identifying the functionality
that is installed on the registered network device.

Reserved names in Windows: See Table of reserved words. The names of an

upgraded domain can include a reserved word. However, trust relationships with
other domains fail in this situation.

Special characters: Period (.)

A period character divides the name into a NetBIOS scope identifier and the
computer name. The NetBIOS scope identifier is an optional string of characters
that identify logical NetBIOS networks that run on the same physical TCP/IP
network. For NetBIOS to work between computers, the computers must have the
same NetBIOS scope identifier and unique computer names.

） Important

The use of NetBIOS scopes in names is a legacy configuration. It shouldn't be

used in Active Directory forests. This is not an inherent problem. However,
some applications might filter the name and assume a DNS name if a period
is found.

DNS domain names

Allowed characters: DNS names can contain only alphabetic characters (A-Z),
numeric characters (0-9), the minus sign (-), and the period (.). Period characters
are allowed only when they're used to delimit the components of domain style
names.

Windows DNS supports Unicode characters. Other implementations of DNS don't

support Unicode characters. Avoid Unicode characters if queries will be passed to
the servers that use non-Microsoft implementations of DNS. For more information,
see RFC 952 and RFC 1123 .

Disallowed characters: DNS domain names can't contain the following characters:
comma (,)
tilde (~)
colon (:)
exclamation point (!)
at sign (@)
number sign (#)
dollar sign ($)
percent (%)
caret (^)
ampersand (&)
apostrophe (')
period (.)
parentheses (())
braces ({})
underscore (_)
white space (blank)

７ Note

The underscore has a special role. It's permitted for the first character in
SRV records by RFC definition. But newer DNS servers might also allow it
anywhere in a name. When you create a domain, you receive a warning
message that states that an underscore character might cause problems for
some DNS servers. However, you can still create the domain. For more
information, see Complying with Name Restrictions for Hosts and
Domains.

Additional rules:
All characters preserve their case formatting except for ASCII characters.
The first character must be alphabetic or numeric.
The last character must not be a minus sign or a period.

Name length rules:

Minimum name length: Two characters

Maximum name length: 255 characters

 ７ Note

If you use UTF-8 (Unicode) characters, remember that some UTF-8

characters exceed one octet in length. In that case, you can't determine the
size of a name by counting the characters. The maximum size of the host
name and of the FQDN is 63 bytes per label and 255 bytes per FQDN.

The maximum name length is based on the requirements of SYSVOL paths, and
also on the MAX_PATH limitation of 260 characters.
A path in SYSVOL resembles the following example:

Console

\\<FQDN domain name>\sysvol\<FQDN domain name>\policies\{<policy

GUID>}\[user|machine]\<CSE-specific path>

７ Note

The AD FQDN domain name appears in the path two times. Therefore,
the length of an AD FQDN domain name is restricted to 64 characters.

The <CSE-specific path> might contain user input, such as the sign-in
script file name. Therefore, it can be significantly long.

Single-label domain namespaces: Single-label DNS names are names that don't
contain a suffix, such as .com , .corp , .net , .org , or companyname . For example,
host is a single-label DNS name. Most Internet registrars don't allow the
registration of single-label DNS names.

Generally, we recommend that you register DNS names for internal and external
namespaces with an Internet registrar. This includes the DNS names of Active
Directory domains, unless such names are subdomains of DNS names that are
registered by your organization name. For example, corp.example.com is a
subdomain of example.com . Registering your DNS name with an Internet registrar
may help prevent a name collision. A name collision might occur if another
organization tries to register the same DNS name, or if your organization merges
with another organization that uses the same DNS name.

Problems that are associated with single-label namespaces include:

Single-label DNS names can't be registered by using an Internet registrar.
 Domains that have single-label DNS names require additional configuration.
The DNS Server service can't locate domain controllers in domains that have
single-label DNS names.
By default, Windows domain members don't provide dynamic updates to
single-label DNS zones. For more information, see Deployment and operation
of Active Directory domains that are configured by using single-label DNS
names.

Reserved names: See Table of reserved words. Don't use top-level internet domain
names, such as .com , .net , and .org on an intranet. If you use top-level internet
domain names on an intranet, computers on the intranet that also connect to the
internet might experience resolution errors. Additionally, avoid using names that
are used in internet-standard special features, such as .local .

Disjointed namespaces

A disjointed namespace occurs if a computer's primary DNS suffix doesn't match the
DNS domain of which it's a member. For example, a disjointed namespace occurs if a
computer that has the DNS name of dc1.contosocorp.com is in a domain that has the
DNS name of contoso.com .

How disjointed namespaces occur:

A Windows NT 4.0 primary domain controller is upgraded to a Windows 2000

Server domain controller by using the original release version of Windows 2000
Server. In the Networking item in Control Panel, multiple DNS suffixes are defined.
The domain is renamed when the forest is at the Windows Server 2003 forest
functional level. Additionally, the primary DNS suffix isn't changed to reflect the
new DNS domain name.

Effects of a disjointed namespace:

Suppose a domain controller that's named DC1 resides in a Windows NT 4.0 domain
whose NetBIOS domain name is contoso . This domain controller is upgraded to
Windows 2000 Server. When this upgrade occurs, the DNS domain is renamed
contoso.com . In the original release version of Windows 2000 Server, the upgrade

routine clears the checkbox that links the primary DNS suffix of the domain controller to
its DNS domain name. Therefore, the primary DNS suffix of the domain controller is the
Windows NT 4.0 DNS suffix that was defined in the Windows NT 4.0 suffix search list. In
this example, the DNS name is DC1.northamerica.contoso.com .
The domain controller dynamically registers its service location (SRV) records in the DNS
zone that corresponds to its DNS domain name. However, the domain controller
registers its host records in the DNS zone that corresponds to its primary DNS suffix.

For more information about disjointed namespaces, see the following articles:

Event IDs 5788 and 5789 occur on a Windows-based computer

Create a Disjoint Namespace

Other factors
Forests that connect to the internet: A DNS namespace that connects to the
internet must be a subdomain of a top-level or second-level domain of the
internet DNS namespace.

Maximum number of domains in a forest: In Windows Server, the maximum

number of domains at Forest Functional Level 2 is 1,200. This restriction is a
limitation of multivalued non-linked attributes in Windows Server.

Best practices:

The DNS names of all the nodes that require name resolution include the
organization's internet DNS domain name. Because DNS is hierarchical, DNS
domain names grow when you add subdomains to your organization.
Therefore, you should choose an internet DNS domain name that is short and
easy to remember. Short domain names make the computer names also easy to
remember.

If the organization has an internet presence, use names that are relative to the
registered internet DNS domain name. For example, if you've registered the
internet DNS domain name contoso.com , use a DNS domain name such as
corp.contoso.com for the intranet domain name.

Don't use the name of an existing corporation or product as your domain name.
Doing this might cause a name collision later.

Avoid a generic name such as domain.localhost . This is because another

company that you merge with in the future might follow the same practice.

Don't use an acronym or an abbreviation as a domain name. Users might have

difficulty recognizing the business unit that an acronym represents.

Avoid the use of underscores (_) in domain names. Applications might be very
RFC-obedient and reject the name. They might also not install or work in your
 domain. You might also experience problems that affect older DNS servers.

Don't use the name of a business unit or a division as a domain name. Business
units and other divisions change, and these domain names can be misleading or
become obsolete.

Don't use geographic names that are difficult to spell and remember.

Avoid extending the DNS domain name hierarchy more than five levels from the
root domain. You can reduce administrative costs by limiting the extent of the
domain name hierarchy.

If you're deploying DNS in a private network, and you don't plan to create an
external namespace, register the DNS domain name that you create for the
internal domain. Otherwise, if you try to use it on the internet, or if you connect
to a network that connects to the internet, you might find that the name is
unavailable.

Site names
We recommend that you use a valid DNS name when you create a new site name.
Otherwise, your site will be available only where a Microsoft DNS server is used. For
more information about valid DNS names, see the DNS host names section.

Allowed characters: DNS names can contain only alphabetic characters (A-Z),
numeric characters (0-9), the minus sign (-), and the period (.). Period characters
are allowed only if they're used to delimit the components of domain style names.

Windows DNS supports Unicode characters. Other implementations of DNS don't

support Unicode characters. Avoid Unicode characters if queries will be passed to
the servers that use non-Microsoft implementations of DNS. For more information,
see RFC 952 and RFC 1123 .

Disallowed characters: DNS names can't contain the following characters:

comma (,)
tilde (~)
colon (:)
exclamation point (!)
at sign (@)
number sign (#)
dollar sign ($)
percent (%)
caret (^)
 ampersand (&)
apostrophe (')
period (.)
parentheses (())
braces ({})
underscore (_)
white space (blank)

７ Note

The underscore has a special role. It's permitted for the first character in
SRV records by RFC definition. But newer DNS servers might also allow it
anywhere in a name. For more information, see Complying with Name
Restrictions for Hosts and Domains.

Additional rules:
All characters except for ASCII characters preserve their case formatting.
The first character must be alphabetic or numeric.
The last character must not be a minus sign or a period.

Name length rules:

Minimum name length: One character
Maximum name length: 63 characters

７ Note

If you use UTF-8 (Unicode) characters, remember that some UTF-8

characters exceed one octet in length. In that case, you can't determine the
size of a name by counting the characters. The maximum length of the
DNS name is 63 bytes per label.

OU names
Allowed characters: All characters are allowed, even extended characters.
Although Active Directory Users and Computers lets you name an OU with
extended characters, we recommend that you use names that describe the
purpose of the OU and that are short enough to easily manage. Lightweight
Directory Access Protocol (LDAP) doesn't have any restrictions because the CN of
the object is put into quotation marks.
 Disallowed characters: No characters are disallowed.

Name length rules:

Minimum name length: One character
Maximum name length: 64 characters

Special issues for OUs

When the OU at the domain root level has the same name as a future child domain, you
might experience database problems. Consider a scenario in which you delete an OU
named marketing to create a child domain that has the same name. For example,
marketing.contoso.com (leftmost label of the child domain FQDN name has the same

name).

You delete the OU. During the tombstone lifetime of the deleted OU, you create a child
domain that has the same name. Then, you delete the child domain, and then create it a
second time. In this scenario, a duplicate record name in the ESE database causes a
phantom-phantom name collision when the child domain is re-created. This problem
prevents the Active Directory Configuration container from replicating.

７ Note

This problem is not restricted to DC and OU name types. A similar name conflict
might also occur for other RDN name types under certain conditions.

Table of reserved words

ﾉ Expand table

Reserved words for Windows NT Windows Windows Windows Server

names 4.0 2000 Server 2003 2008 and later

ANONYMOUS X X X X

AUTHENTICATED X X X
USER

BATCH X X X X

BUILTIN X X X X

CREATOR GROUP X X X X
Reserved words for Windows NT Windows Windows Windows Server
names 4.0 2000 Server 2003 2008 and later

CREATOR GROUP X X X X
SERVER

CREATOR OWNER X X X X

CREATOR OWNER X X X X
SERVER

DIALUP X X X X

DIGEST AUTH X X

DOMAIN X

ENTERPRISE X

INTERACTIVE X X X X

INTERNET X X X

LOCAL X X X X

LOCAL SYSTEM X X

NETWORK X X X X

NETWORK SERVICE X X

NT AUTHORITY X X X X

NT DOMAIN X X X X

NTLM AUTH X X

NULL X X X X

PROXY X X X

REMOTE INTERACTIVE X X

RESTRICTED X X X

SCHANNEL AUTH X X

SELF X X X

SERVER X X X

SERVICE X X X X
 Reserved words for Windows NT Windows Windows Windows Server
names 4.0 2000 Server 2003 2008 and later

SYSTEM X X X X

TERMINAL SERVER X X X

THIS ORGANIZATION X X

USERS X X

WORLD X X X X

Feedback
Was this page helpful?  Yes  No

Provide product feedback

NET.EXE /ADD command does not
support names longer than 20
characters
Article • 02/19/2024

This article provides a solution to an error that occurs when you use the NET.EXE /ADD
command with user or group names longer than 20 characters.

Applies to: Windows 10 - all editions, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2
Original KB number: 324639

Symptoms
When you use the NET.EXE command together with the /ADD switch and long user or
group names, this only redisplays the NET syntax. You receive no error message.

Example:

Console

C:\>NET.EXE localgroup MyRemoteUsers "REMOTE INTERACTIVE LOGON" /ADD

The syntax of this command is:

NET LOCALGROUP [groupname [/COMMENT:"text"]] [/DOMAIN]

groupname {/ADD [/COMMENT:"text"] | /DELETE} [/DOMAIN]
groupname name [...] {/ADD | /DELETE} [/DOMAIN]

The same action does work with the GUI Computer Management, Local Users, and
Groups Microsoft Management Console (MMC).

Cause
The NET.EXE command does not support names longer than 20 characters for reasons
of backward compatibility with LAN Manager 2.0.

Resolution
If the graphical user interface (GUI) method cannot be used and a scripting method is
required, use the Windows 2000 Resource Kit utility Cusrmgr.exe. Or, use VBScript, using
an application programming interface (API) that supports names longer than 20
characters.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
In the example in the "Symptoms" section of this article, use the following Cusrmgr.exe
syntax:

Console

C:\>CUSRMGR.EXE -u "REMOTE INTERACTIVE LOGON" -alg "MyRemoteUsers"

This issue may also occur with localized versions in which built-in groups exceed the 20
character name limit. For example, with the German name for "Authenticated Users" (19
characters): "Authentifizierte Benutzer" (25 characters).

The following sample VBScript may be adapted and used as an additional workaround.
It adds "Authenticated Users" to "Power Users" for the English and German version:

Visual Basic Script

##### VBScript ADDGRP.VBS #####

On Error Resume Next

Dim oContainer
Dim oGroup
Dim oIADs

Dim oComputerInformation
Dim bolGroupSet
bolGroupSet = False

Set oComputerInformation = CreateObject("WScript.Network")

Set oContainer = GetObject("WinNT://" +

oComputerInformation.ComputerName)'get the IADsContainer object for the
local computer
 oContainer.Filter = Array("Group")'We only need to enumerate groups,
therefore the filter
For Each oIADs In oContainer 'for each IADs object we find there
If oIADs.Name = "Hauptbenutzer" Or oIADs.Name = "Power Users" Then
'check if it has the name "Power Users" or "Hauptbenutzer"

Set oGroup = oIADs 'If so put it into the IADsGroup object

oGroup.Add ("WinNT://S-1-5-11")'add the group "Authenticated Users"
oGroup.SetInfo 'and save the info

If Err <> 0 Then 'if error number is not 0 (Error occurred)

MsgBox Err.Number, vbCritical, "AddGroup" 'print out the error message
Else 'if everything seems to be ok
bolGroupSet = True 'set the boolean value to True so we know the group was
added
End If

End If
Next

If bolGroupSet = True Then 'if bolGroupSet is False there was nothing done
MsgBox "Group added successfully", vbInformation, "AddGroup"
Else
MsgBox "No action has taken place!", vbExclamation, "AddGroup"
End If
##### script end #####

Workaround
To work around this issue in Windows Server 2008 and later, use the Add-
ADGroupMember PowerShell command, as described in the following TechNet article:
Add-ADGroupMember

If you are using PowerShell 5.1, use the Add-LocalGroupMember -Group PowerShell
command, as described in the following article:
Add-LocalGroupMember

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Netlogon service doesn't start and
event IDs 2114 and 7024 are logged
Article • 02/19/2024

This article provides a solution to an issue where the Netlogon service doesn't start
when you start a Windows-based computer.

Applies to: Windows Server 2012 R2

Original KB number: 269375

Symptoms
When you start your Windows 2000-based computer, the Netlogon service doesn't start,
even though the Startup type is set to automatic.

Event Viewer logs the following errors:

Message 1

Output

Event Type: Error

Event Source: NETLOGON
Event Category: None
Event ID: 2114
Description: The Server service is not started.

Message 2

Output

Event Type: Error

Event Source: Service Control Manager
Event Category:None
Event ID: 7024
Description: The Netlogon service terminated with service-specific
error 2114.

After your computer starts, you can manually start the Netlogon service.

Cause
This issue can occur if either of the following conditions exist:

The dependent services of the Netlogon service have been changed from the
default values and are not properly configured. You may be unable to access some
network resources on the computer because the Netlogon service is not started.

You removed Client for Microsoft Networks, and then reinstalled it. The
dependencies are not reset correctly if the Client for Microsoft Networks
component is removed and then reinstalled.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To resolve this issue, follow these steps:

1. Start Registry Editor (Regedt32.exe).

2. Locate the registry key:

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Netlogon/ .

3. In the right pane, double-click the DependOnService value.

4. In the Multi-String Editor dialog box, type the following strings on separate lines,
and then click OK:

LanmanServer
LanmanWorkstation

5. Quit Registry Editor, and then restart the computer.

The Netlogon service starts as expected.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Outdated cached credentials are used
when you run an elevated task
Article • 02/19/2024

This article helps to resolve the issue in which outdated cached credentials are used
when you run an elevated task.

Applies to: Supported versions of Windows Server and Windows Client

You log on to a Windows computer using a non-administrator account and run an

elevated task by selecting the Run as Administrator option. Then, you are prompted for
an administrator credential, and you enter an administrator account credential to
continue the operation.

７ Note

When you use an administrator account for the first time on the computer, the
administrator group membership and password are cached locally on the
computer.

When you run an elevated task by selecting the Run as Administrator option again,
you're still prompted for an administrator credential.

The cached credentials aren't updated

The cached credentials aren't updated when you run an elevated task. The cached
credentials aren't updated on the computer even when the group membership for the
administrator account is changed in the domain environment. Therefore, the cached
group membership is used on the computer.

Create a registry entry for authenticating the

user credentials at a domain controller first

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For protection, back up
 the registry before you modify it so that you can restore it if a problem occurs. For
more information about how to back up and restore the registry, see How to back
up and restore the registry in Windows .

To resolve this issue, you can create a registry entry for authenticating the user
credentials at a domain controller first by using the following steps:

1. Select the Windows logo key+ R and type regedit in the Run dialog box, and then
press Enter.

７ Note

If you're prompted for an administrator password, provide the password. If

you're prompted for a confirmation, provide the confirmation.

2. Locate and select the registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

3. On the Edit menu, point to New, and then select DWORD (32-bit) Value.

4. Type InteractiveLogonFirst and press Enter.

5. Right-click InteractiveLogonFirst and select Modify.

6. Type 1 in the Value data box and select OK.

7. Exit Registry Editor.

７ Note

When the value of the InteractiveLogonFirst registry entry is set to 1, the domain
controller verification is required when you run an elevated task. If the domain
controller isn't available, the system uses the cached credentials internally.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Password change for expired password
failing for workgroup scenario
Article • 02/19/2024

This article helps fix an error that occurs when processing the password change for a
user where the password is expired or set to change at next logon.

Applies to: Windows Server 2012 R2

Original KB number: 2879424

Symptoms
You have a server in a DMZ that's not member of a domain. For administration, you
have a series of local users that are administrators.

When you add a new user on the server for administration, you set an initial password
and set "User must change password at next logon". The user logs on to the server
through Remote Desktop Services. The user is prompted to change the password, and
after entering it, the user receives an error message "Not enough storage is available to
process this command":

If the RDS server has NLA enabled the attempt to log on to the server fails with the
expired password showing the error:

[Window Title]
Remote Desktop Connection[Content]

An authentication error has occured.

The Local Security Authority cannot be contacted

Remote computer: <Computer Name>

This could be due to an expired password.
Please update your password if it has expired.
For assistance, contact your administrator or technical support.
 [OK]

The error dialog looks like this:

Cause
When processing the password change for a user where the password is expired or set
to change at next logon, Winlogon uses an anonymous token to process the password
change request.

The password change dialog allows changing passwords against remote computers as
well, so the API calls use remotable interfaces through RPC over Named Pipes over SMB.
For this protocol sequence, the RPC runtime reads a policy setting
"Server2003NegotiateDisable" from the key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc .

This fails in the context of the anonymous token as the default permissions allow only
authenticated users, administrators, and LocalSystem to read the key.

When NLA is enabled, the user session request doesn't validate and thus fails.

Resolution
The approaches to avoid this problem are:

1. Change the password remotely. Note that currently the user in the context you run
the remote password change needs to be able to log on to the target server with
the default credentials (or already connected using SMB to the server at the time
of the password change already).
2. Change the permissions of the key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc to allow

anonymous to read the key. If the key doesn't exist, you may create it and then
add the read permissions for the anonymous account.
 ７ Note

For approach 2, in an attempt to recover from an error, it might happen that the
group policy service deletes the keys and recreates them using default permissions.
In this case, you have to reapply the permissions.

You can automate setting the permissions on using Registry Security Policy when the
machine is member of the domain. For workgroup machines you can import this text as
rpc-pol.inf file:

INF

---------------------------
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Registry Keys]
"MACHINE\SOFTWARE\Policies\Microsoft\Windows
NT\rpc",0,"D:PAR(A;CIIO;KA;;;CO)(A;CI;KA;;;SY)(A;CI;KA;;;BA)(A;CI;KR;;;S-1-
5-7)(A;CI;KR;;;BU)"
------------------------------

You can apply it using:

secedit /configure /db C:\Windows\security\database\rpc-pol.sdb/cfg rpc-pol.inf /log

rpc-pol.log Note the key must exist so this is successful.

More information
The functionality to change workgroup or remote member machine passwords needs to
take a number of compatibility requirements into account. The scenario is very much a
borderline topic by today.

For RDS sessions secured with NLA, it's not allowing starting a remote session with an
expired password to begin with. If you want to use NLA, you have to change the
password remotely up-front in a session authenticated with another user.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

Description of password-change
protocols in Windows
Article • 02/19/2024

This article describes the mechanisms for changing passwords in Windows.

Applies to: Windows 10, Windows Server 2012 R2

Original KB number: 264480

Summary
Windows uses many different mechanisms for changing passwords. This article
describes those mechanisms.

More information
The supported password-change protocols are:

1. The NetUserChangePassword protocol

2. The NetUserSetInfo protocol
3. The Kerberos change-password protocol (IETF Internet Draft Draft-ietf-cat-kerb-
chg-password-02.txt) [port 464]
4. Kerberos set-password protocol (IETF Internet Draft Draft-ietf-cat-kerberos-set-
passwd-00.txt) [port 464]
5. Lightweight Directory Access Protocol (LDAP) write-password attribute (if 128-bit
Secure Sockets Layer [SSL] is used)
6. XACT-SMB for pre-Microsoft Windows NT (LAN Manager) compatibility

Change-password operations require that the user's current password be known before
the change is allowed. Set-password operations don't have this requirement, but are
controlled by the Reset Password permissions on the account.

When you're using LDAP (method 5), the domain controller and the client must both be
able to use 128-bit SSL to protect the connection. If the domain controller isn't
configured for SSL or if appropriately long keys aren't available, the password-change
write is denied.

An Active Directory domain controller listens for change-password requests on all of

these protocols.
As stated earlier in this article, different protocols are used in different circumstances.
For example:

Interoperable Kerberos clients use the Kerberos protocols. UNIX-based systems

with MIT Kerberos version 5 1.1.1 can change user passwords in a Windows-based
domain by using the Kerberos change-password protocol (method 3).
When users change their own passwords by pressing CTRL+ALT+DELETE and then
clicking Change Password, Windows NT up to Windows 2003 the
NetUserChangePassword mechanism (method 1) is used if the target is a domain.
From Windows Vista onwards, the Kerberos change password protocol is used for
domain accounts. If the target is a Kerberos realm, the Kerberos change-password
protocol (method 3) is used.
Requests to change a password from computers that are running Microsoft
Windows 95/Microsoft Windows 98 use XACT-SMB (method 6).
A program that uses the ChangePassword method on the Active Directory Services
Interface (ADSI) IaDSUser interface first tries to change the password by using
LDAP (method 5), and then by using the NetUserChangePassword protocol
(method 1).
A program that uses the SetPassword method on the ADSI IaDSUser interface first
tries to change the password by using LDAP (method 5), then the Kerberos set-
password protocol (method 4), and then the NetUserSetInfo protocol (method 2).
The Active Directory Users and Computers snap-in uses ADSI operations for
setting user passwords.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Password Reset using Active Directory
Users & Computers fails with error "The
System cannot find the path specified"
Article • 02/19/2024

This article provides a solution to an error that occurs when you reset the password of a
user.

Applies to: Windows Server 2012 R2

Original KB number: 2001522

Symptoms
You have the task to manage users in your domain and you need to reset the password
of a user. You can right-click the user and select Reset Password and enter the new
password. After you click OK, you receive the error message:

Windows cannot complete the password change for <user name> because:
The System cannot find the path specified

The password for the user isn't changed afterwards. The same task may work with other
administrator user accounts, and also for the same administrator accounts on other
workstations. Resetting the user password may also work through other tools, for
example using the LDIFDE as outlined in How to set a user's password with Ldifde.

Cause
The dialog handler function encrypts the new password strings when it pulls them from
the edit controls. The encryption fails because it doesn't find the supporting files in the
user AppData folder in the following location:
%AppData%\Microsoft\Protect\<user sid>

This may happen if the AppData user shell folder is redirected to a different location
without moving or copying the original data. The folder location is specified in the
AppData registry value in the following registry location:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders
Resolution
To resolve the problem, either move or copy the original data to the redirected location,
or revert the redirection of the AppData folder.

Using the Process Monitor tool, you can see the LSASS.EXE process will fail to open files
in the AppData path after the new password dialog is acknowledged. For more
information about the Process Monitor tool, visit the following Microsoft Web site:
Process Monitor v3.60

More information
Microsoft recommends using Folder Redirection Policies to redirect parts of the user
profile to different locations. These policies also allow the contents of the folder to be
moved automatically.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Poor performance when calling lookup
functions to resolve names
Article • 02/19/2024

Original KB number: 818024

When calling the LookupAccountName or LsaLookupNames function to resolve

isolated names (ambiguous or non-domain-qualified user accounts) to security
identifiers (SIDs), you may notice an increased usage of memory and CPU on the
domain controller and decreased performance.

For example, poor performance might occur when using scripts or tools (such as
Cacls.exe, Xcacls.exe, icacls.exe, Dsacls.exe, and Subinacl.exe) to call the functions to edit
security settings.

The problem may show up when you have many trusted domains or forests (applies to
both external and forest trusts), and/or some of these domains or forests are offline or
slow to respond.

When the functions are called for an isolated name (the format is AccountName in
contrast to domain\AccountName), a remote procedure call (RPC) is made to domain
controllers on all trusted domains/forests. This issue might occur if the primary domain
has many trust relationships with other domains/forests or if it's doing many lookups at
a same time. For example, a script is configured to run at the startup of many clients, or
many trusted domains/forests use the same script simultaneously.

Disable the lookup of isolated names in trusted

domains/forests

７ Note

Create this registry entry only on domain controllers.

Here's how to create a registry entry to disable the lookup of isolated names in trusted
domains/forests:

） Important
 This article contains instructions to modify the registry. Severe issues might occur if
the registry is modified incorrectly. As a precaution, back up the registry before you
modify it. For more information about how to back up, restore, and modify the
registry, see How to back up and restore the registry in Windows .

1. Open Registry Editor.

2. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa .

3. On the Edit menu, select New > DWORD Value.

4. Type LsaLookupRestrictIsolatedNameLevel, and press Enter.

5. Right-click LsaLookupRestrictIsolatedNameLevel and select Modify. Type 1 in the

Value data box.

７ Note

By default, the LsaLookupRestrictIsolatedNameLevel entry is either set to 0

or doesn't exist. That means that the lookup for isolated names in trusted
domains/forests is enabled.

6. Select OK and close Registry Editor.

More information
The lookup functions can directly target a domain controller on an appropriate domain
for the following name formats that contain an authoritative domain of a security
principal:

NetBIOSDomainName\AccountName
DnsDomainName\AccountName
AccountName@DnsDomainName

For more information, see Network access validation algorithms and examples for
Windows.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Redirect the users and computers
containers in Active Directory domains
Article • 02/19/2024

You can use redirusr and redircmp to redirect user, computer, and group accounts that
are created by earlier-version APIs. So they are put in admin-specified organizational
unit (OU) containers.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 324949

Summary
In a default installation of an Active Directory domain, user, computer, and group
accounts are put in CN=objectclass containers instead of a more desirable OU class
container. Similarly, the accounts that were created by using earlier-version APIs are put
in the CN=Users and CN=computers containers.

） Important

Some applications require specific security principals to be located in default

containers like CN=Users or CN=Computers. Verify that your applications have
such dependencies before you move them out of the CN=users and CN=computes
containers.

More information
Users, computers, and groups created by earlier-version APIs place objects in the DN
path that's specified in the WellKnownObjects attribute. The WellKnownObjects attribute
is located in the domain NC head. The following code example shows the relevant paths
in the WellKnownObjects attribute from the CONTOSO.COM domain NC head.

Dn: DC=CONTOSO,DC=COM

conosle

wellKnownObjects (11):
B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=CONTOSO,DC=COM;
B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Program
Data,DC=CONTOSO,DC=COM;
 B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data,DC=CONTOSO,DC=COM;
B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:CN=ForeignSecurityPrincipals,DC=CONTOS
O,DC=COM;
B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=Deleted Objects,DC=CONTOSO,DC=COM;
B:32:2FBAC1870ADE11D297C400C04FD8D5CD:CN=Infrastructure,DC=CONTOSO,DC=COM;
B:32:AB8153B7768811D1ADED00C04FD8D5CD:CN=LostAndFound,DC=CONTOSO,DC=COM;
B:32:AB1D30F3768811D1ADED00C04FD8D5CD:CN=System,DC=CONTOSO,DC=COM;
B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:OU=Domain
Controllers,DC=CONTOSO,DC=COM;
B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=CONTOSO,DC=COM;
B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=GPN,DC=COM;

For example, the following operations use earlier-version APIs, which rely on the paths
defined in the WellKnownObjects attribute:

Domain Join UI
NET COMPUTER
NET GROUP
NET USER
NETDOM ADD, where the /ou command is either not specified or supported

It's helpful to make the default container for user, computer, and security groups an OU
for several reasons, including:

Group policies can be applied on OU containers but not on CN class containers,

where security principals are put by default.

The best practice is to arrange security principals into an OU hierarchy that mirrors
your organizational structure, geographic layout, or administration model.

If you're redirecting the CN=Users and CN=Computers folders, be aware of the

following issues:

The target domain must be configured to run in the Windows Server 2003 domain
functional level or higher. For the Windows Server 2003 domain functional level, it
means that:
Windows Server 2003 ADPREP /FORESTPREP or newer
Windows Server 2003 ADPREP /DOMAINPREP or newer
All domain controllers in the target domain must run Windows Server 2003 or
newer.
Windows Server 2003 domain functional level or higher must be enabled.

Unlike CN=USERS and CN=COMPUTERS, OU containers are subject to accidental

deletions by privileged user accounts, including administrators.
 CN=USERS and CN=COMPUTERS containers are system-protected objects that
can't, and mustn't, be removed for backward compatibility. But they can be
renamed. Organizational units are subject to accidental tree deletions by
administrators.

Windows Server 2008 and newer versions of the Active Directory Users and
Computers snap-in feature a Protect object against accidental deletion check box
that you can select when you create a new OU container. You can also select it on
the Object tab of the Properties dialog box for an existing OU container.

Redirecting CN=USERS affects the default location for new users, groups, and trust
user accounts. Trust user accounts are hidden in most UI admin tools, but you can
show and move them in tools like LDIFDE and LDP. The CN of the account is
<downlevel domain name>$, for example, "contoso$".

If you experience Exchange Server Active Directory preparation failures, make sure
you're running the latest cumulative update and security update.

Redirect CN=Users to an administrator-

specified OU
1. Log on with domain administrator credentials in the domain where the CN=Users
container is being redirected.

2. Transition the domain to the Windows Server 2003 domain functional level or
newer in either the Active Directory Users and Computers snap-in (Dsa.msc) or the
Domains and Trusts (Domains.msc) snap-in. For more information about increasing
the domain functional level, see How to raise domain and forest functional
levels .

3. Create the OU container where you want users and groups who are created with
earlier-version APIs to be located, if the OU container that you want doesn't exist.

4. Run Redirusr.exe at the command prompt by using the following syntax. In the
command, container-dn is the distinguished name of the OU that will become the
default location for newly created user and group objects created by down-level
APIs:

Console

c:\windows\system32\redirusr container-dn
 Redirusr is installed in the %SystemRoot%\System32 folder on Windows Server 2003-
based or newer computers. For example, to change the default location for users
who are created with down-level APIs such as Net User to the OU=MYUsers OU
container in the CONTOSO.COM domain, use the following syntax:

c:\windows\system32>redirusr ou=myusers,DC=contoso,dc=com

７ Note

When Redirusr.exe is run to redirect the CN=Users container to an OU

specified by an administrator, the CN=Users container will no longer be a
protected object. This means that the Users container can now be moved,
deleted, or renamed. If you use ADSIEDIT to view attributes on the CN=Users
container, you will see that the systemflags attribute was changed from
-1946157056 to 0. This is by design.

To delete the container, you have to move out the default users and groups to
other OUs and containers, and also the trust user accounts. These trust
accounts can be shown and moved using tools like LDIFDE and LDP. We
recommend keeping the container unchanged and the default accounts in
place for consistency.

Redirect CN=Computers to an administrator-

specified OU
1. Log on with Domain Administrator credentials in the domain where the
CN=computers container is being redirected.

2. Transition the domain to the Windows Server 2003 domain in the Active Directory
Users and Computers snap-in (Dsa.msc) or in the Domains and Trusts
(Domains.msc) snap-in. For more information about increasing the domain
functional level, see How to raise domain and forest functional levels .

3. Create the OU container where you want computers that are created with earlier-
version APIs to be located, if the desired OU container doesn't exist.

4. Run Redircmp.exe at a command prompt by using the following syntax. In the

command, container-dn is the distinguished name of the OU that will become the
default location for newly created computer objects that are created by down-level
APIs:
 Console

redircmp container-dn

Redircmp.exe is installed in the %Systemroot%\System32 folder in Windows Server

2003 or later versions. To change the default location for a computer created with
earlier-version APIs, such as Net Computer, to the OU=MyComputers container in
the CONTOSO.COM domain, use the following syntax:

Console

C:\windows\system32>redircmp ou=mycomputers,DC=contoso,dc=com

７ Note

When Redircmp.exe is run to redirect the CN=Computers container to an OU

specified by an administrator, the CN=Computers container will no longer be
a protected object. This means that the Computers container can now be
moved, deleted, or renamed. If you use ADSIEDIT to view attributes on the
CN=Computers container, you will see that the systemflags attribute was
changed from -1946157056 to 0. This is by design.

Description of error messages

Here are error messages that occur in some cases.

Error messages that you receive if the PDC is offline

Redircmp and Redirusr change the wellKnownObjects attribute on the primary domain
controller (PDC). If the PDC of the domain that is being changed is offline or
inaccessible, you receive the following error messages.

Error message 1:

C:>redirusr OU=userOU,DC=udc,dc=jkcertcontoso,dc=loc com

Error, could not locate the Primary Domain Controller for the current domain:
The specified domain either does not exist or could not be contacted.
Redirection was NOT successful.
 Error message 2:

C:>redircmp OU=computerOU,DC=contoso,dc=com DC=udc,dc=jkcert,dc=loc

Error, could not locate the Primary Domain Controller for the current domain:
The specified domain either does not exist or could not be contacted.
Redirection was NOT successful.

Error messages that you receive if the domain functional

level isn't Windows Server 2003
You try to redirect the users or computer OU in a domain that hasn't transitioned to the
Windows Server 2003 domain functional level. In this situation, you receive the following
error messages:

Error message 1:

C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: Unwilling To
Perform Redirection was NOT successful.

Error message 2:

C:>redircmp ou=computersou,DC=contoso,dc=comdc=company,dc=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: Unwilling To
Perform

Error messages that you receive if you log on without the

required permissions
If you try to redirect the users or computer OU by using incorrect credentials in the
target domain, you may receive the following error messages:

Error message 1

C:>redircmp OU=computersou,DC=contoso,dc=comDC=company,DC=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: Insufficient
 Rights Redirection was NOT successful.

Error message 2:

C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: Insufficient
Rights Redirection was NOT successful.

Error messages that you receive if you redirect to an OU

that doesn't exist
You try to redirect the users or computer OU to an OU that doesn't exist. In this
situation, you may receive the following error messages:

Error message 1:

C:>redircmp OU=nonexistantou,DC=contoso,dc=com dc=rendom,dc=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: No Such Object
Redirection was NOT successful.

Error message 2:

C:>redirusr OU=nonexistantou,DC=contoso,dc=com DC=company,DC=com

Error, unable to modify the wellKnownObjects attribute. Verify that the domain
functional level of the domain is at least Windows Server 2003: No Such Object
Redirection was NOT successful.

Error messages that you receive in Exchange Server 2000

setup /domainprep when CN=Users is redirected
If Exchange Server 2000 and Exchange Server 2003 setup /domainprep is unsuccessful,
you receive the following error message:

Setup failed while installing sub-component Domain-level permissions with error

code 0x80072030) (please consult the installation logs for a detailed description).
You may cancel the installation or try the failed step again. (Retry / Cancel)
The following data appears in the Exchange Server 2000 Setup log that is parsed with
log parser. Exchange Server 2003 should be similar.

Output

[HH:MM:SS] Completed DomainPrep of Microsoft Exchange 2000 component

[HH:MM:SS] ScGetExchangeServerGroups
(K:\admin\src\libs\exsetup\dsmisc.cxx:301) Error code 0X80072030 (8240):
There is no such object on the server.
[HH:MM:SS] ScCreateExchangeServerGroups
(K:\admin\src\libs\exsetup\dsmisc.cxx:373) Error code 0X80072030 (8240):
There is no such object on the server.
[HH:MM:SS] CAtomPermissions::ScAddDSObjects
(K:\admin\src\udog\exsetdata\components\domprep\a_permissions.cxx:144) Error
code 0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] mode = 'DomainPrep' (61966) CBaseAtom::ScSetup
(K:\admin\src\udog\setupbase\basecomp\baseatom.cxx:775) Error code
0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] Setup encountered an error during Microsoft Exchange Domain
Preparation of DomainPrep component task. CBaseComponent::ScSetup
(K:\admin\src\udog\setupbase\basecomp\basecomp.cxx:1031) Error code
0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] CBaseComponent::ScSetup
(K:\admin\src\udog\setupbase\basecomp\basecomp.cxx:1099) Error code
0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] CCompDomainPrep::ScSetup
(K:\admin\src\udog\exsetdata\components\domprep\compdomprep.cxx:502) Error
code 0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] CComExchSetupComponent::Install
(K:\admin\src\udog\BO\comboifaces.cxx:694) Error code 0X80072030 (8240):
There is no such object on the server.
[HH:MM:SS] Setup completed

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to rename an object after a
replication collision has occurred
Article • 02/19/2024

This article describes how to rename an object after a replication collision has occurred.

Applies to: Windows 2000

Original KB number: 297083

Summary
When a replication collision occurs, objects that were created on two or more different
domain controllers with the same RDN (Relative Distinguished Name) and in the same
container may be renamed. For example, the name changes from
CN=APPSRV,OU=Domain Controllers,DC=domain,DC=com to the following:
CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com

Many tools and wizards, including the Active Directory Installation Wizard, may not work
correctly because of the length of the new name of the object. Therefore, after the
conflicting objects have been manually resolved, it is best to change the name back to
the original name.

７ Note

If the object that is affected in the collision is a computer or a domain controller,

only the RDN that is used to locate the object in Active Directory is changed after
the collision. The computer name and the way that the computer is identified on
the network are not changed.

Change the name of the RDN of an object

1. Find the new RDN.

To get the changed RDN, you can use the LDIFDE utility. This utility can support
batch operations that are based on the LDIF (LDAP Data Interchange Format) file
format standard. You can export all the information from Active Directory to a file
by using this utility.
 For example, if you want to export the following information to a file that is named
Bluesky.txt, type the following at a command prompt, and then press ENTER:

Computer name: bluesky

Location in Active Directory:
OU=Workstations,OU=DELTA,OU=OandM,DC=ad,DC=water,DC=ca,DC=gov
Domain Controller: dc1

Console

ldifde -f c:\bluesky.txt -s dc1 -d

"OU=Workstations,OU=DELTA,OU=OandM,DC=ad,DC=water,DC=ca,DC=gov" -r
"(&(objectClass=computer)(cn=bluesky*))

Running this command exports all information from the Active Directory to the
specified file (Bluesky.txt). From the specified text file, you can find the new RDN.

For more information about LDIFDE utility program, see Step-by-Step Guide to
Bulk Import and Export to Active Directory.

2. Encode the new RDN in base 64.

The new RDN contains characters that you cannot use in a literal string; therefore,
you have to encode the RDN by using Base 64. After the following RDN is encoded
in Base 64:

CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com

the result will be the following:

Q049QVBQU1JWQ05GOmI5ZTAwMjVjLWY5YjAtNDhmMC1iYTdiLWE3NzQ0Nzc
xNjkxMSxPVT1Eb21haW4gQ29udHJvbGxlcnMsREM9ZG9tYWluLERDPW

3. Rename the changed RDN. To rename the changed RDN follow these steps:

a. Create a file with an extension .ldf. When you modify attributes in Active
Directory, it is important that the following format be followed:

Sample LDIF File to change RDN (changerdn.ldf)

=================
#Modify an rdn for ##### APPSRV ########
dn::
 Q049QVBQU1JWQ05GOmI5ZTAwMjVjLWY5YjAtNDhmMC1iYTdiLWE3NzQ0
NzcxNjkxMSxPVT1Eb21haW4gQ29udHJvbGxlcnMsREM9ZG9tYWluLERDPW
NvbW==
changetype:modrdn
newrdn: cn=APPSRV
deleteoldrdn: 1

dn:: represents the current RDN in base 64. The (::) instructs Ldifde that the
following string is Base 64 encoded.

newrdn: represents the new name of the object.

b. At a command prompt, type ldifde -i -f c:\changerdn.ldf -s your server

name .

Running this command changes the RDN, using the LDIFDE utility, to the new
RDN that is specified by you in the LDIF file (Changerdn.ldf).

When you run this command, you may receive an output that is similar to the
following:

Connecting to "appsrv.domain.com"
Logging in as current user using SSPI
Importing directory from file "changedc.ldf"
Loading entries
1: CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com
Entry DN: CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-
a77447716911,OU=Domain Controllers,DC=domain,DC=com change: dn
Renaming to cn=APPSRV with deleteold of 1
Entry modified successfully.
1 entry modified successfully.
The command has completed successfully.

This process can change the name back to Appsrv. This change is relational so
all references to this object are changed in the Active Directory.

When you correct the name on the domain controllers' objects, ensure that you change
the name back to what it had been originally. This change does not rename the domain
controller. If you rename a domain controller, it is not supported in Windows 2000.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to restrict use of a computer to
one domain user only
Article • 02/19/2024

This article describes how to restrict use of a computer to one domain user only.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 555317

This article was written by Yuval Sinay , Microsoft MVP.

Symptoms
When you create trust connection/s from one domain(forest) to another, users have the
option to sign in different domain/s than their home domain (The domain that host
their account/s).

Cause
Trust connection/s from one domain to another or/and one forest to another enable
user to log in different domain/s than their home domain (The domain that host their
account/s). The "Authenticated Users" group on each computer allow users from trusted
domain to be authenticated and logon to computer.

Resolution

Option A: Domain-Wide Policy

By using group policy capabilities in Windows 2000/2003 Domain, you can prevent from
user/s to sign in to different domain/s than their home domain.

1. Create a new domain-wide GPO and enable "Deny logon locally" user right to the
source domain user account/sIn the target domain.

７ Note
 Some services (Like Backup software services) may effect by this policy, and
wouldn't function. To eliminate future problems, apply this policy and use
GPO security filter feature.

Deny logon locally

Filter using security groups

2. Run on Gpupdate /force on the domain controller.

Option B: Remove "NT AUTHORITY\Authenticated Users"

uses from the list of users group
To eliminate the option of logging in one or few computers, follow the instructions
bellow:

1. Right-click "My Computer" icon on the desktop.

2. Choose on "Manage".

3. Extract "Local Users and Groups".

4. Select on "Groups".

5. On the right side of the screen, double-click "Users" group.

6. Remove: "NT AUTHORITY\Authenticated Users" from the list.

7. Add the require user/s or and group/s to the "Users" local group.

Option C: Configure "Deny logon locally" user right on

the local computer/s
To eliminate the option of logging on one or few computers, follow the instructions
bellow:

1. Go to "Start" -> "Run".

2. Write "Gpedit.msc"

3. Enable "Deny logon locally" user right to the source domain user accounts.

７ Note
 Some services (Like Backup software services) may effect by this policy, and
wouldn't function.

Deny logon locally

4. Run Gpupdate /force on the local computer.

Option D: Use Selective Authentication when use Forest

Trust
Creating Forest Trusts

More information
Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Resultant Set of Policy (RSoP) planning
mode is not supported in a cross-forest
scenario
Article • 02/19/2024

This article describes limitations to the resultant set of policy (RSoP) planning mode
when you try to use it across multiple forests.

Applies to: Windows 10 - all editions, Windows Server 2012 R2, Windows Server 2016,
Windows Server 2019
Original KB number: 910206

Symptoms
You cannot use the RSoP planning mode to plan for scenarios that span forests in
Windows Server 2003 and later versions. For example, you cannot plan for a scenario in
which a user logs on to a workstation in Forest 1 from Forest 2. When you try to run
RSoP planning mode in a cross-forest environment, you receive the following Group
Policy error message:

Cross forest planning mode scenarios are not currently supported.

Cause
This issue occurs because RSoP planning mode does not support cross-forest scenarios.
In many scenarios, RSoP cannot validate the information that is returned from a domain
controller that is located in another forest. The Authenticated Users group must have
read permissions for relevant policies to successfully read a particular policy in a cross-
forest environment.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set a user's password with
Ldifde
Article • 02/19/2024

This article describes how to set a user's password by using the Ldifde tool.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 263991

More information
The password attribute used by Active Directory is "unicodePwd". This attribute can be
written under restricted conditions, but cannot be read. This attribute can only be
modified, not added on object creation or read by a search.

To modify this attribute, the client must have a 128-bit Secure Sockets Layer/Transport
Layer Security(SSL/TLS) or SASL encrypted connection to the server. The High Encryption
pack must be installed on both the client and the server.

７ Note

When you want to use SASL encryption, you can use the "/h" argument of LDIFDE.
When you use a base-64 encoder, you must make sure that it supports Unicode, or
you will create an incorrect password.

There are two ways to modify the unicodePwd attribute. The first is analogous to a
typical user change-password operation. In this case, the modify request must contain
both a delete operation and an add operation. The delete operation must contain the
current password enclosed in quotation marks and be Base64 encoded as described in
RFC 1521. The add operation must contain the new password enclosed in quotation
marks and be Base64 encoded.

The second way to modify the attribute is analogous to an administrator resetting a

password for a user. To do this, the client must have bound as an administrator a user
who has sufficient rights to modify other users' passwords. The modify request should
contain a single replace operation with the new password enclosed in quotation marks
and be Base64 encoded. If the client has sufficient rights, this password becomes the
new password regardless of what the old password was.

The following sample Ldif file (chPwd.ldif) changes a password to newPassword:

 dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgA=
-

To import the chPwd.ldif file, use the following command:

SSL/TLS:
ldifde -i -f chPwd.ldif -t 636 -s \<dcname> -b \<username> \<domain> \
<password>

SASL:
ldifde -i -f chPwd.ldif -h -s \<dcname> -b \<username> \<domain> \<password>

If the password does not fulfill the criteria of the enforced Password Policies, then it will
throw an error:

Add error on entry starting on line 1: Unwilling To Perform The server-side error is
"A device attached to the system is not functioning

For more information, see the following documents:

The "LDAP Data Interchange Format (LDIF) - Technical Specification" document on the
following IETF Web site:

IETF 109 Online

RFC 1521 on the following IETF Web site:

RFC 1521

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Some applications and APIs require
access to authorization information on
account objects
Article • 02/19/2024

This article describes some applications and application programming interfaces (APIs)
must have access to the token-groups-global-and-universal (TGGAU) attribute on user
account objects, or on computer account objects in the Active Directory directory
service.

Applies to: Windows Server 2012 R2

Original KB number: 331951

Summary
Some applications have features that read the token-groups-global-and-universal
(TGGAU) attribute on user account objects or on computer account objects in the
Microsoft Active Directory directory service. Some Win32 functions make it easier to
read the TGGAU attribute. Applications that read this attribute or that call an API
(referred to as a function in the rest of this article) that reads this attribute don't succeed
if the calling security context doesn't have access to the attribute.

By default, access to the TGGAU attribute is determined by the Permission

Compatibility decision (made when the domain was created during the DCPromo.exe
process). The default permission compatibility for new Windows Server 2003 domains
doesn't grant broad access to the TGGAU attribute. Access to read the TGGAU attribute
can be granted as required to the new Windows Authorization Access (WAA) group in
Windows Server 2003.

More information
The token-groups-global-and-universal (TGGAU) attribute is a dynamically computed
value on computer account objects and on user account objects in Active Directory. This
attribute enumerates the global group memberships and the universal group
memberships for the corresponding user account or computer account. Applications
can use the group information that is provided by the TGGAU attribute to make various
decisions about a specific user when the user isn't logged on.
For example, an application can use this information to determine whether a user has
been granted access to a resource that the application controls access for. Applications
that require this information can read the TGGAU attribute directly by using either
Lightweight Directory Access Protocol interfaces or Active Directory Services Interfaces.
However, Microsoft Windows Server 2003 introduced several functions (including the
AuthzInitializeContextFromSid function and the LsaLogonUser function) that simplify
reading and interpretation of the TGGAU attribute. Therefore, applications that use
these functions may unknowingly be reading the TGGAU attribute.

For applications to be able to directly read this attribute or indirectly read this attribute
(through the use of an API), the security context that the application runs in must have
been granted read access to the TGGAU object on the user objects and on the computer
objects. You do not expect applications to assume that they have access to TGGAU.
Therefore, you can expect applications to be unsuccessful when access is denied. In this
situation, you (the user) may receive an error message or a log entry that explains that
access was denied while trying to read this information, and that provides instructions
about how to obtain access (as described later in this article).

Several existing applications depend on the information that is provided by TGGAU

because the information is available by default in Microsoft Windows NT 4.0 and in
earlier operating systems. So on Microsoft Windows 2000 and Windows Server 2003
operating systems, read access to the TGGAU attribute is granted to the Pre-Windows
2000 Compatible Access group.

For domains that use existing applications, you can handle these applications by adding
the security contexts that those applications run as to the Pre-Windows 2000
Compatible Access group. Instead, you can select the "Permissions compatible with
pre-Windows 2000 servers" option during the DCPromo process when you create a
domain. (On Windows Server 2003, this option is worded as follows: "Permissions
compatible with pre-Windows 2000 server operating systems".) This selection adds
the Everyone group to the Pre-Windows 2000 Compatible Access group, and thereby
grants the Everyone group read access to the TGGAU attribute and to many other
domain objects.

When a new Windows Server 2003 domain is created, the default access compatibility
selection is Permissions compatible only with Windows 2000 or Windows Server 2003
operating systems. When this option is set, the Pre-Windows 2000 Compatibility
Access group includes only the Authenticated Users built-in security identifier, and read
access to the TGGAU attribute on objects is limited. In this case, applications that require
access to the TGGAU group are denied access unless the account under which the
applications run has domain administrator rights or similar user rights.
Enabling Applications to read the TGGAU
attribute
To simplify the process of granting read access on the token-groups-global-and-
universal (TGGAU) attribute to users who must read the attribute, Windows Server 2003
introduces the Windows Authorization Access (WAA) group.

On new installations of Windows Server 2003 domains, the WAA group is granted
access to the read TGGAU attribute on user objects and on group objects.

Windows 2000 Domains

If the domain is in pre-Windows 2000 compatibility access mode, the Everyone group
has read access to the TGGAU attribute on user account objects and on computer
account objects. In this mode, applications and functions have access to TGGAU.

If the domain isn't in pre-Windows 2000 compatibility access mode, you may have to
enable certain applications to read the TGGAU. Because the Windows Authorization
Access Group doesn't exist on Windows 2000, it's recommended that you create a
domain local group for this purpose, and that you add the user or computer account
that requires access to the TGGAU attribute to that group. This group would have to be
given access to the tokenGroupsGlobalAndUniversal attribute on user objects, on
computer objects, and on iNetOrgPerson objects.

Mixed mode domains and upgraded domains

When a Windows Server 2003 domain controller is added to a Windows 2000 domain,
the access compatibility selection that was previously selected isn't changed. So mixed
mode domains and domains that were upgraded to Windows Server 2003 that were in
pre-Windows 2000 compatibility access mode continue to have the Everyone group in
the Pre-Windows 2000 Compatibility Access group. Additionally, the Everyone group
still has access to the TGGAU attribute. In this mode, applications and functions have
access to TGGAU.

If the mixed mode domain isn't in pre-Windows 2000 compatibility access mode, you
can grant permissions by means of the WAA group:

The WAA group is automatically created when a Windows Server 2003 domain
controller is promoted to the Floating Single Master Operations Server.
The WAA group isn't automatically granted access to the TGGAU attribute on
mixed-mode domains and on upgraded domains.
After the Windows Authorization Access (WAA) group has access to the TGGAU
attribute, you can place the accounts that require access in the WAA group.

New Windows Server 2003 Domains

If the domain is in pre-Windows 2000 compatibility access mode, the Everyone group
has read access to the TGGAU attribute on user account objects and on computer
account objects. In this mode, applications and functions have access to TGGAU.

If the domain isn't in pre-Windows 2000 compatibility access mode, add to the WAA
group those accounts that require access to TGGAU. In new installations of Windows
Server 2003, the WAA group already has read access to TGGAU on user objects and on
computer objects.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of the Lingering Object
Liquidator tool
Article • 02/19/2024

This article describes the Lingering Object Liquidator (LoL) tool for finding and removing
lingering objects.

Applies to: Windows Server 2012 R2

Original KB number: 3141939

Introduction
The Lingering Object Liquidator (LOL) is a tool to automate the discovery and removal
of lingering objects. The tool uses the DRSReplicaVerifyObjects method, which is
leveraged by the repadmin /removelingeringobjects command and the repldiag tool in
combination with the removeLingeringObject rootDSE primitive that's used by LDP.EXE.

Benefits and availability

Combines discovery and removal of lingering objects in one interface.
The tool is available from the Microsoft download center .

See this ASKDS blog post for detailed instructions on tool usage.

Key features
Removes all the lingering objects across all domain controllers (DCs) without any
prompting.
Performs an (n * (n-1)) comparison across every DC in the forest.
Performs topology detection, which lets you pick and choose DCs to use for
Lingering object comparison (source and target).
Exports a list of lingering objects as a CSV file, so that it can be edited offline and
then imported back into the tool to remove the objects if necessary (useful for
advanced removal operations).
Saves the contents of the object in a log file in case a new object must be hydrated
from the lingering object.

Tools requirements
 Download and run Lingering Object Liquidator on a DC or member computer in
the forest you want to remove lingering objects from.

The Microsoft .NET Framework 4.5.2 must be installed on the computer that's
running the tool.

Permissions: The user account running the tool must have Domain Administrator
credentials for each domain in the forest that the executing computer resides in.
Members of the Enterprise Administrators group have domain administrator
credentials in all domains within a forest by default. Domain Administrator
credentials are sufficient in a single domain or a single domain forest.

You must enable the Remote Event Log Management (RPC) firewall rule on any DC
that needs scanning. Otherwise, the tool returns an "Exception: The RPC server is
unavailable" error.

ﾉ Expand table

The liquidation of lingering objects in Active Directory Lightweight Directory

Services (AD LDS / ADAM) environments isn't supported.

Walkthrough

Lingering object detection

Run the tool as a domain administrator (or as an Enterprise administrator if you want to
scan the entire forest). To do this follow these steps.

７ Note

You will receive error 8453 if the tool isn't run as elevated.

1. In the Topology Detection section, select Fast.

Fast detection populates the Naming Context, Reference DC, and Target DC lists by
querying the local DC. Thorough detection does a more exhaustive search of all
DCs and leverages DC Locator and DSBind calls. Be aware that Thorough detection
will likely fail if one or more DCs are unreachable.

2. The following are the fields on the Lingering Objects tab:

Naming Context

Reference DC
 This is the DC you'll compare to the target DC. The reference DC hosts a writeable
copy of the partition.

７ Note

All DCs in the forest are displayed even if they are unsuitable as reference DCs
(ChildDC2 is an RODC and is not a valid Reference DC since it doesn't host a
writable copy of a DC).

Target DC

The target DC that lingering objects are to be removed from.

3. Click Detect to use these DCs for the comparison or leave all fields blank to scan
the entire environment.

The tool does a comparison with all DCs for all partitions in a pair-wise fashion
when all fields are left blank. In a large environment, this comparison will take a
great deal of time (possibly even days) as the operation targets (n * (n-1)) number
of DCs in the forest for all locally held partitions. For shorter, targeted operations,
select a naming context, reference DC, and target DC. The reference DC must hold
a writable copy of the selected naming context. Be aware that clicking Stop doesn't
actually stop the server-side API, it just stops the work in the client-side tool.
During the scan, several buttons are disabled, and the current count of lingering
objects is displayed on the status bar at the bottom of the screen, together with
the current tool status. During this execution phase, the tool is running in an
advisory mode and reading the event log data that's reported on each target DC.

When the scan is complete, the status bar updates, buttons are re-enabled, and
total count of lingering objects is displayed. The Results pane at the bottom of the
window updates with any errors encountered during the scan.

If you see error 1396 or error 8440 in the status pane, you're using an early beta-
preview version of the tool and should update to the latest version. - Error 1396 is
logged if the tool incorrectly used an RODC as a reference DC. - Error 8440 is
logged when the targeted reference DC doesn't host a writable copy of the
partition.

Notes about the Lingering Object Liquidator discovery method

Leverages DRSReplicaVerifyObjects method in Advisory Mode.

Runs for all DCs and all partitions.
Collects lingering object event ID 1946 and displays objects in main content
pane.
List can be exported to CSV for offline analysis (or modification for import).
Supports import and removal of objects from CSV import (leverage for
objects not discoverable using DRSReplicaVerifyObjects).
Supports removal of objects by DRSReplicaVerifyObjects and LDAP rootDSE
removeLingeringobjects modification.

The tool leverages the Advisory Mode method exposed by

DRSReplicaVerifyObjects that both repadmin /removelingeringobjects
/Advisory_Mode and repldiag /removelingeringobjects use. In addition to the
 normal Advisory Mode-related events logged on each DC, it displays each of the
lingering objects within the main content pane.

Results of the scan are logged in the Results pane. Many more details of all
operations are logged in the linger<Date-TimeStamp>.log.txt file in the same
directory as the tool's executable.

The Export button allows you to export a list of all lingering objects listed in the
main pane into a CSV file. View the file in Excel, modify if necessary and use the
Import button later to view the objects without having to do a new scan. The
Import feature is also useful if you discover abandoned objects (not discoverable
with DRSReplicaVerifyObjects) that you need to remove.

A note about transient lingering objects:

Garbage collection is an independent process that runs on each DC every 12 hours

by default. One of its jobs is to remove objects that have been deleted and have
existed as a tombstone for greater than the tombstone lifetime number of days.
There's a rolling 12-hour period where an object eligible for garbage collection
exists on some DCs but has already been removed by the garbage collection
process on other DCs. These objects will also be reported as lingering object by
the tool, however no action is required as they'll automatically get removed the
next time the garbage collector process runs on the DC.

4. To remove individual objects, select a single object or multi-select multiple objects

by using the Ctrl or Shift key. Press Ctrl to select multiple objects, or Shift to select
a range of objects and then select Remove.
The status bar is updated with the new count of lingering objects and the status of
the removal operation:

The tool dumps a list of attributes for each object before removal and logs this
along with the results of the object removal in the removedLingeringObjects.log.txt
log file. This log file is in the same location as the tool's executable.
C:\tools\LingeringObjects\removedLingeringObjects<DATE-TIMEStamp.log.txt

Example contents of the log file:

the obj DN: <GUID=0bb376aa1c82a348997e5187ff012f4a>;

<SID=010500000000000515000000609701d7b0ce8f6a3e529d669f040000>;C
N=<CN_Name>,OU=<OU_Name>,DC=root,DC=contoso,DC=com
objectClass:top, person, organizationalPerson, user;
sn:Schenk;
whenCreated:20121126224220.0Z;
name:<CN_Name>;
objectSid:S-1-5-21-3607205728-1787809456-1721586238-
1183;primaryGroupID:513;
 sAMAccountType:805306368;
uSNChanged:32958;
objectCategory:
<GUID=11ba1167b1b0af429187547c7d089c61>;CN=Person,CN=Schema,CN=
Configuration,DC=root,DC=contoso,DC=com;
whenChanged:20121126224322.0Z;
cn:<CN_Name>;
uSNCreated:32958;
l:Boulder;
distinguishedName:<GUID=0bb376aa1c82a348997e5187ff012f4a>;
<SID=010500000000000515000000609701d7b0ce8f6a3e529d669f040000>;C
N=<CN_Name>,OU=<OU_Name>,DC=root,DC=contoso,DC=com;
displayName:<CN_Name>;
st:Colorado;
dSCorePropagationData:16010101000000.0Z;
userPrincipalName:<User_Name>@root.contoso.com;
givenName:<User_Name>;
instanceType:0;
sAMAccountName:<Account_Name>;
userAccountControl:650;
objectGUID:aa76b30b-821c-48a3-997e-5187ff012f4a;
value is :<GUID=70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e>:<GUID=aa76b30b-
821c-48a3-997e-5187ff012f4a> Lingering Obj CN=<CN_Name>,OU=
<OU_Name>,DC=root,DC=contoso,DC=com is removed from the directory,
mod response result code = Success
---------------------------------------------
RemoveLingeringObject returned Success

After all objects are identified, they can be bulk-removed by selecting all objects
and then Remove, or exported into a CSV file. The CSV file can later be imported
again to do bulk removal. Be aware that there's a Remove All button that leverages
the repadmin /removelingeringobject method of lingering object removal

Support: While this tool has been thoroughly tested in many environments, it's
provided to you as-is: There will be no official Microsoft support provided.

For questions or feedback on the tool:

Add a comment to this blog post , or submit an idea to our UserVoice Feedback
page--ensure you code the idea using the "Lingering Object Liquidator" category.
Access the Troubleshooting Active Directory Lingering Objects TechNet Virtual Lab if
you would like practice using this tool in a lab environment containing lingering objects.

Workflow

More information
ﾉ Expand table

Removal method Object / Partition & and Details

Removal Capabilities

Lingering Object Liquidator Per-object and per-

partition removal - GUI-based
- Quickly displays all lingering
Leverages: objects in the forest to which
- RemoveLingeringObjects the executing computer is
LDAP rootDSE modification joined
Removal method Object / Partition & and Details
Removal Capabilities

- DRSReplicaVerifyObjects - Built-in discovery through

method the DRSReplicaVerifyObjects
method
- Automated method to
remove lingering objects from
all partitions
- Removes lingering objects
from all DCs (including RODCs)
but not lingering links
- Windows Server 2008 and
later DCs (will not work against
Windows Server 2003 DCs)

Repldiag /removelingeringobjects Per-partition removal

- Command line only
Leverages: - Automated method to
- DRSReplicaVerifyObjects remove lingering objects from
method all partitions
- Built-in discovery through
DRSReplicaVerifyObjects
- Displays discovered objects
in events on DCs
- Doesn't remove lingering
links. Doesn't remove lingering
objects from RODCs (yet).

LDAP RemoveLingeringObjects Per-object removal

rootDSE primitive (most - Requires a separate discovery
commonly executed using method
LDP.EXE or an LDIFDE import - Removes a single object per
script) execution unless scripted.

Repadmin Per-partition removal

/removelingeringobjects - Command line only
Leverages: - Built-in discovery through
- DRSReplicaVerifyObjects DRSReplicaVerifyObjects
method - Displays discovered objects
in events on DCs
- Requires many executions if
a comprehensive (n * (n-1))
pairwise cleanup is required.

The repldiag tool and the

Lingering Object Liquidator
tool automate this task.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you try to add
more than 64 logon workstations: "This
property is limited to 64 values"
Article • 02/19/2024

This article provides a solution to an error that occurs when try to add more than 64
logon workstations.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 938458

Symptoms
In Active Directory Users and Computers, you try to add more than 64 logon
workstation entries on the Logon To tab in the user account properties dialog box. After
you do this, you may receive the following error message:

This property is limited to 64 values. You must remove some of the existing values
before you can add new ones.

Cause
This problem occurs because the User-Workstations attribute has a Range-Upper value
of 1,024 characters. When you enter the NetBIOS computer names by using Active
Directory Users and Computers, the NetBIOS name has a maximum length of 16
characters. Therefore, you can store only 64 logon workstation entries.

Status
This behavior is by design.

７ Note

You can change the rangeUpper value on the User-Workstations attribute in the
schema to a value up to 8192 to allow more entries in the list. Microsoft does not
recommend higher values as you might hit object size limits.
More information
rangeUpper is the Ldap-Display-Name for the Range-Upper value. Range-Upper is the
maximum value or the maximum length of an attribute. The User-Workstations attribute
is defined in the userWorkstations property of a user. The User-Workstations attribute is
a single-valued property that represents a comma-separated list of NetBIOS computer
names.

For more information about the User-Workstations attribute, visit the following
Microsoft Web site: User-Workstations attribute

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshooting AD Replication error
8589: The DS cannot derive a service
principal name (SPN)
Article • 02/19/2024

This article describes symptoms, cause, and resolution steps for cases where AD
operations fail with Win32 error 8589.

７ Note

Home users: This article is only intended for technical support agents and IT
professionals. If you're looking for help with a problem, please ask the Microsoft
Community .

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2703028

Symptoms
Error 8589: "The DS cannot derive a service principal name (SPN) with which to
mutually authenticate the target server because the corresponding server object in
the local DS database has no serverReference attribute.

Symbolic error: ERROR_DS_CANT_DERIVE_SPN_WITHOUT_SERVER_REF

You will see any of the following errors/warning when troubleshooting Active Directory
replication.

1. DCDIAG reports that the Active Directory Replications test has failed with error
status (8589): The DS cannot derive a service principal name (SPN) ith which to
mutually authenticate the target server because the corresponding server object in
the local DS database has no serverReference attribute.

Sample error text from DCDIAG is shown below:

Testing server: <site><DC name>

Starting test: Replications

 * Replications Check

[Replications Check,<DC name>] A recent replication attempt failed:

From <source DC> to <destination DC>

Naming Context: DC=<DN path>

The replication generated an error (8589):

The DS cannot derive a service principal name (SPN) with which to mutually
authenticate the target server because the corresponding server object in the
local DS database has no serverReference attribute.

The failure occurred at <date> <time>.

The last success occurred at (never)| <date>.

2. DCDiag.exe shows the following warning:

An Warning Event occurred. EventID: 0x80000785

Time Generated: <DateTime>

Event String: The attempt to establish a replication link for the following
writable directory partition failed.
Directory partition:
DC=ForestDnsZones,DC=contoso,DC=com
Source domain controller:
CN=NTDS Settings,CN=DCSRV01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contosoDC=com
Source domain controller address:

<source DC NTDS Settings Obejct GUID>._msdcs.contoso.com

Intersite transport (if any):
This domain controller will be unable to replicate with the source domain
controller until this problem is corrected.

User Action
Verify if the source domain controller is accessible or network connectivity is
available.

Additional Data
Error value:
8589
 The DS cannot derive a service principal name (SPN) with which to mutually
authenticate the target server because the corresponding server object in the
local DS database has no serverReference attribute.

3. REPADMIN.EXE reports that the last replication attempt has failed with status 8589

REPADMIN commands that commonly cite the 8589 status include but are not

limited to:

REPADMIN /SHOWREPL

REPADMIN /SHOWREPS
REPADMIN /REPLSUM

REPADMIN /SYNCALL

Repadmin /showrepl returns the following error:

Source: <Site Name>\<DC Name>

******* <n> CONSECUTIVE FAILURES since <Date & Time>

Last error: 8589 (0x218d):

The DS cannot derive a service principal name (SPN) with which to mutually
authenticate the target server because the corresponding server object in the
local DS database has no serverReference attribute.

4. Events in the Directory Services event log that cite the error status 8589

Events, which commonly cite the 8589 status, include but are not limited to:

ﾉ Expand table

Event Source and Event ID Message String

NTDS Replication / Active Directory failed to construct a mutual

ActiveDirectory_DomainService 1411 authentication service principal name (SPN) for the
following domain controller.

NTDS Replication 2023 The local domain controller was unable to

replicate changes to the following remote domain
controller for the following directory partition.

NTDS KCC 1925 The attempt to establish a replication link for the
following writable directory partition failed.
Cause
The event most commonly occurs on a DC after a replication partner has been forcefully
demoted and repromoted prior to allowing end-to-end replication to complete. This can
also happen when you rename a domain controller and the serverReference attribute is
not updated. The serverReference attribute in this instance is the Server object viewable
in the Active Directory Sites and Services MMC (adsiedit.msc). The server object is the
parent object of the domain controller's NTDS Settings object.

Resolution
Verify the serverReference attribute is not missing or set to an incorrect value and
update it to the correct value.

1. Find the domain controller that is referenced in the event ID 1411. There are a few
options we can use to find this. The simples is to use ping (option A). If ping fails,
use PowerShell (option B). If PowerShell is not an option, then you can use ldp.exe
(option C). (Note: if your DCs are 2003 and you are not able to install PowerShell
on it, you may use PowerShell from a Windows 7 domain joined client or a
Windows 2008 or Windows 2008 R2 server)

Option A
Use NSLookup or ping to find the DC listed in <source DC NTDS Settings Obejct
GUID>._msdcs.contoso.com

Example:

Ping 3dab7f9b-92e7-4391-b8db-71df532c1493._msdcs.contoso.com

Console

Pinging DCSRV02.contoso.com [IP] with 32 bytes of data :

Reply from [IP]: bytes=32 time<1ms TTL=128

Reply from [IP]: bytes=32 time<1ms TTL=128
Reply from [IP]: bytes=32 time<1ms TTL=128
Reply from [IP]: bytes=32 time<1ms TTL=128

Option B
Use PowerShell to find the DC referenced. There are two PowerShell methods you
can use. To do this open the "Active Directory Module for Windows PowerShell"

Method 1: Run the following two PowerShell cmdlets. In the first cmdlet, replace
the partition name CN=Configuration,DC=contoso,DC=com with the DN of your
Configuration partition. Replace the server name DCSRV01.contoso.com with the
name of your domain controller. In the second cmdlet, replace the GUID 3dab7f9b-
92e7-4391-b8db-71df532c1493 with the GUID in your event ID 1411.

PowerShell

$list = Get-ADObject -Filter 'ObjectClass -eq "ntdsdsa"' -SearchBase

'*CN=Configuration,DC=contoso,Dc=com*' -Server *DCSRV01.contoso.com*
-includedeletedobjects -Properties *

foreach ($dc in $list) {if ($dc.ObjectGUID -match "*3dab7f9b-92e7-4391-

b8db-71df532c1493*") {Echo $dc.DistinguishedName }}

Method 2: Another PowerShell option is to run the following and then search the
output text file. Replace the DCSRV01.contoso.com with a DC in your environment.

PowerShell

Get-ADObject -Filter 'ObjectClass -eq "ntdsdsa"' -SearchBase

'CN=Configuration,DC=contoso,Dc=com' -Server DCSRV01.contoso.com -
includedeletedobjects > C:\NTDSDSA.txt

Then search NTDSA.txt for the GUID referenced in event ID 141

Option C

Use Ldp.exe
a. Click Start, and then click Run
b. Type LDP.exe and then press ENTER.
c. On the Connections menu, click Bind and click OK.
d. On the View menu, click Tree.
e. In BaseDN, click the drop-down list arrow, click the distinguished name of your
Configuration partition and click OK.
f. In the Options menu, click Controls.
g. In the Controls dialog box, expand the Load Predefined menu, click Return
deleted objects and click OK.

７ Note

The 1.2.840.113556.1.4.417 control will show in the Active Controls list.

h. On the Browse menu, click Search

i. In the Base DN box, type: CN=Sites, CN=Configuration,DC=contoso,DC=com
(Replace contoso and com with the appropriate domain name.)
 j. In the Filter box, type (objectClass=ntdsdsa)
k. In the Scope box, select Subtree
l. In the Attributes box type, an * (asterisk)
m. Click Run
n. On the right side search for the GUID in objectGUID attribute to find the server
it is referencing.

Option D
a. Obtain repadmin /showrepl output from the destination DC reporting the 8589
status.
b. Using the repadmin /showrepl output obtained from the previous step, identify
the 8589 replication status within the output and document the date and time-
stamp following the Last Attempt message.
c. Using the date and timestamp from the previous step, locate the corresponding
event ID 1411 in the Directory Services event log on the destination DC. Take
note that the DSA object GUID listed in the repadmin /showrepl output is
different from what is reported in the event ID 1411.(see example scenario
below)
d. Then find the domain controller listed in the event ID 1411, by either checking
the NTDS Settings Properties General Tab or by pinging the GUID in the event
ID.
e. Bind to the Source DC using ADSIEDIT or Active Directory Users and Computers
and open up the Attribute Editor and copy the value in serverReference. Paste in
the value of this attribute on the destination DCs copy of the object. (Step 2)

2. Once you have located the server being referenced using one of the above
methods, do the following:
a. Click Start, and then click Run
b. Type ADSIEDIT.msc and press ENTER
c. Right-click " ADSI Edit " and select " Connect to... "
d. In " Connection Point " under " Select a well known Naming Context: " select "
Configuration " and click OK.
e. On left pane, expand " Configuration "
f. Next expand " CN=Configuration,DC=contoso,DC=com "
g. Next expand " CN=Sites "
h. Under CN=Sites, expand the site in which the server is located. Example:
Default-First-Site-Name
i. Under that site expand CN=Servers. Example: If DCSRV02 is in the Default-First-
Site-Name site in Contoso.com, you should be in: CN=DCSRV02, CN=Servers,
CN=Default-First-Site-Name, CN=Sites, CN=Configuration, DC=contoso,
DC=com
 j. Right click on the domain controller (found using Option A, B, or C) and select
Properties.
k. In the " Attribute Editor " tab scroll down to serverReference attribute.
l. The serverReference should be similar to CN=DCSRV02,OU=Domain
Controllers,DC=Contoso,DC=com If it's missing or incorrect then change it to
the correct value.
m. Close ADSIEDIT.msc

More information
Example Scenario

1. Obtain repadmin /showrepl output from the destination DC reporting the 8589
status.

2. Using the repadmin /showrepl output obtained from the previous step, identify the
8589 replication status within the output and document the date and time-stamp
following the Last Attempt message.

Repadmin /showrepl output:

Liverpool\LIVCONTOSODCDSA Options: IS_GC

Site Options: (none)
DSA object GUID: <GUID>

DSA invocationID: <InvocationID>

==== INBOUND NEIGHBORS

======================================

DC=Contoso,DC=com

Charlotte\CONTOSOROOTDC1 via RPC

DSA object GUID: <GUID>

Last attempt @ <DateTime> was successful.

CN=Configuration,DC=Contoso,DC=com

Houston\5THWARDCORPDC via RPC

DSA object GUID: <GUID>

Last attempt @ <DateTime> failed, result 8589 (0x218d):

 The DS cannot derive a service principal name (SPN) with which to mutually
authenticate the target server because the corresponding server object in the
local DS database has no serverReference attribute.

1700 consecutive failure(s).

Last success @ (never).

Using the date and timestamp from the previous step, locate the corresponding event
ID 1411 in the Directory Services event log on the destination DC. Take note that the
DSA object GUID listed in the repadmin /showrepl output is different from what is
reported in the event ID 1411.

Directory Services Event Log:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 1411
Task Category: DS RPC Client
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: LIVCONTOSODC.Contoso.com
Description:
Active Directory Domain Services failed to construct a mutual authentication service
principal name (SPN) for the following directory service.

Directory service: <GUID>._msdcs.Contoso.com

The call was denied. Communication with this directory service might be affected.

Additional Data
Error value:
8589 The DS cannot derive a service principal name (SPN) with which to mutually
authenticate the target server because the corresponding server object in the local
DS database has no serverReference attribute.
Click Cancel and then view the properties for the server object (5thWardCorpDC in this
example) select the Attribute Editor tab (Server 2008 and later) or use ADSIEDIT to edit
the object on Server 2003

Notice that the serverReference attribute is not set in the following image
Bind to the Source DC using ADSIEDIT or Active Directory Users and Computers and
open up the Attribute Editor and copy the value in serverReference. Paste in the value of
this attribute on the destination DCs copy of the object.
After the serverReference attribute is set correctly for the domain controller is shows as
follows:
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use the Administration Tools
Pack to remotely administer computers
that are running Windows Server 2003,
Windows XP, or Windows 2000
Article • 02/19/2024

This article describes how to remotely administer computers by using the Administration
Tools Pack.

Applies to: Windows 10 - all editions, Windows 7 Service Pack 1, Windows Server 2012
R2
Original KB number: 304718

Summary
This article describes options to administer computers that are running Windows Server
2003, Windows XP, or Microsoft Windows 2000. Additionally, this article discusses how
to download the Windows Server 2003 Administration Tools Pack (Adminpak). This
article also discusses the various compatibility issues that occur when you remotely
administer Windows 2000-based computers from Windows XP-based computers and
from Windows Server 2003-based computers and vice versa.

Introduction
The following topics are discussed in this article:

Options to remotely administer computers that are running Windows Server 2003,
Windows XP, or Windows 2000.
Download locations for the original-release (RTM), Service Pack 1, and Service Pack
2 versions of the Windows Server 2003 Administration Tools Pack
Issues that are specific to the administration of 64-bit versions of Windows
Compatibility issues that occur when Windows 2000 Professional-based computers
that have Windows 2000 administration tools installed are upgraded to Windows
XP.
Compatibility issues that occur when Windows 2000-based domain controllers are
upgraded to Windows Server 2003-based domain controllers.
 Known issues that may occur when you use administration tools from the original-
release (RTM), Service Pack 1, and Service Pack 2 versions of the Windows Server
2003 Administration Tools Pack to manage Windows 2000-based, Windows XP-
based, and Windows Server 2003-based computers

Remote administration options

The most seamless administrative experience occurs when the computer that is used to
perform administrative tasks runs the same operating system as the computer that is
being remotely administered.

Windows Server 2003 and Windows 2000 installation media contain command-line and
graphical administrative tools that can be used to locally and in most cases remotely
administer up-level and down-level operating systems with a high degree of
interoperability.

To remotely administer computers that are running Windows Server 2003 or Windows
2000 from computers that are running Windows Server 2003, Windows XP, or Windows
2000, use one of the following methods:

Install and use graphical administrative tools that are packaged in the
Administration Tools Pack to remotely administer computers that are running
Windows Server 2003, Windows XP, or Windows 2000. Where interoperability
problems exist between operating systems, perform administrative tasks on the
console of the target computer or on a computer that is running the same
operating system as the computer that is being remotely administered.

Use Terminal Services to remotely administer computers that have command-line

and graphical user interface (GUI) administration tools locally installed. To avoid
the two-session limit, you can use Application Server mode to create a Windows
Server 2003-based or Windows 2000-based installation that is running Terminal
Server or Terminal Services. Where interoperability problems exist between
operating systems, perform administrative tasks from a server that has Terminal
Server or Terminal Services enabled and that is running the same operating system
as the remote computer that is being administered.

Use command-line tools and scripts to locally and remotely administer computers
that are running Windows Server 2003, Windows XP, or Windows 2000. These tools
and scripts include Active Directory Service Interfaces (ADSI), Windows Net.exe
commands, and the tools that are packaged with Suptools.msi. Where
interoperability problems exist between operating systems, perform administrative
tasks on the console of the target computer or on a designated computer for
 administrative tasks that is running the same operating system as the remote
computer that is being administered. For example, the Windows Server 2003
Service Pack 2 (SP2) Support Tools will install on a computer that is running
Windows XP Professional. However, the tools are not guaranteed to work correctly
in this scenario. Tools that are known to have issues include the following:
Dfsutil.exe
Netdiag.exe
Netcap.exe
Ntfrsutil.exe

If you want to run these tools against a Windows Server 2003 SP2-based computer, we
recommend that you run them from a computer that is running Windows Server 2003
SP2. You can use the Remote Desktop feature to connect to a Windows Server 2003
SP2-based computer that is running the Support Tools.

Windows Server 2003 and Windows 2000 Server

Administration Tools Packs
To make the remote management of your servers easier, Microsoft has included typically
used graphical administrative tools in a self-extracting file that is named Adminpak.msi
(Adminpak).

７ Note

On 64-bit versions of Windows Server 2003, this file is called Wadminpak.msi.

The Windows 2000 Administration Tools Pack is located in the I386 folder on the
Windows 2000 Server-family CD and installs on computers that are running Windows
2000. Most of the tools in the Windows 2000 Adminpak can remotely administer
Windows 2000 in addition to the 32-bit and 64-bit versions of Windows XP Professional
and the 32-bit and 64-bit versions of Windows Server 2003.

The Windows Server 2003 Administration Tools Pack is located in the I386 folder of the
Windows Server 2003 CD and is available as a free download on www.microsoft.com . The
following table summarizes the operating systems on which you can install the
Adminpak from Windows 2000, from Windows Server 2003 original (RTM), from
Windows Server 2003 Service Pack 1 (SP1), or from Windows Server 2003 Service Pack 2.
Additionally, the table summarizes the operating systems that the Adminpaks from
these sources can remotely administer.
 ﾉ Expand table

Windows Windows Windows Windows Remote Server

2000 Server 2003 Server 2003 Server 2003 Administration
Server original SP1 SP2 Tool (RSAT)
Adminpak (RTM) Adminpak Adminpak
Adminpak

Installs and
runs on these
operating
systems

Windows No Yes Yes Yes

Server 2003
32-bit family

Windows No No Yes Yes

Server 2003
64-bit family

Windows XP No Yes Yes Yes

Professional
with Service
Pack 2

Windows XP No Yes Yes Yes

Professional
SP1 or later
versions

Windows XP No No Yes Yes

Professional
64-bit Edition

Windows Yes No No No
2000
Professional

Windows Yes No No No
2000 Server
family

Windows No No No No Yes, RSAT for

Vista Windows Vista

Windows 7 No No No No Yes, RSAT for

Windows 7

Windows No No No No Yes, RSAT for

Server 2008 Windows Server
 Windows Windows Windows Windows Remote Server
2000 Server 2003 Server 2003 Server 2003 Administration
Server original SP1 SP2 Tool (RSAT)
Adminpak (RTM) Adminpak Adminpak
Adminpak

2008

Windows No No No No Yes, RSAT for

Server 2008 Windows Server
R2 2008

Remotely
manages
these
operating
systems

Windows Yes Yes Yes Yes

Server 2003
32-bit family

Windows Yes Yes Yes Yes

Server 2003
64-bit family

Windows Yes Yes Yes Yes

2000 Server
family

Windows Server 2003 Administration Tools Pack

installation and compatibility overview
If you want to remotely administer Windows Server 2003 or Windows 2000 member-
based computers and domain controllers from Windows Server 2003-based clients or
from Windows XP Professional-based clients, note the following installation issues:

You must remove earlier beta versions of the Windows Server 2003 Administration
Tools Pack before you install the final release version.

７ Note

In some limited cases, servers must be administered from clients that are
running the same operating system. For example, some remote administration
operations against Windows 2000-based servers can be performed only from
Windows 2000-based clients. Similarly, some operations against Windows
 Server 2003-based computers can be performed only from Windows Server
2003-based clients or from Windows XP-based clients. This article documents
these limitations or restrictions for each tool that is included in the
Administration Tools Pack.

If you do not uninstall earlier versions of the Administration Tools Pack

(Adminpak.msi) before you upgrade to Windows Server 2003 Service Pack 2, the
Administration Tools Pack cannot uninstall after you upgrade. If you try to uninstall
the Administration Tools Pack through Add or Remove Programs or by running
Adminpak.msi, you receive the following error messages:

Error message 1

Windows Server 2003 Administration Tools Pack can only be installed on

Windows XP Professional with hotfix Q329357 applied, on Windows XP
Professional Service Pack 1 or later versions, or on computers that are running
Windows Server 2003 operating systems.

Error message 2

Setup Failed - Due to an error, Windows Server 2003 Administration Tools Pack
Setup Wizard was unable to finish.

You cannot install the Windows 2000 Adminpak.msi file on Windows Server 2003-
based computers or on Windows XP-based clients. These tools no longer work on
these operating systems and are not supported. Use the Windows Server 2003
version of the Administration Tools Pack on Windows XP-based computers.

The Windows Server 2003 Administration Tools Pack cannot be installed or run on
Windows 2000-based computers. If you try to install the Windows Server 2003
Administration Tools Pack on a Windows 2000-based computer, you receive the
following error message: Windows Server 2003 Administration Tools Pack can only
be installed on Windows XP Professional with hotfix Q329357 applied, or on
Windows XP Professional SP1 or later, or on computers that are running Windows
Server 2003 operating systems.

Service pack level mismatch. Obtain the Administration Tools Pack that matches
the service pack level of your operating system.

Similarly, the command-line utilities from the Windows Server 2003 Administration
Tools Pack run only on computers that are running Windows XP or Windows Server
2003. Command-line utilities in the Windows Server 2003 Administration Tools
 Pack do not run if there is a DLL mismatch or an entry-point error. Such a
mismatch or error may occur if you copy the utilities to a Windows 2000-based
computer. If you try to install the Windows 2000 Administration Tools Pack on a
Windows Server 2003-based computer, you receive the following error message:

Windows 2000 Administration Tools are incompatible with Windows Server 2003
operating systems. Install Windows Server 2003 Administration Tools Pack.

Windows XP Professional does not include the Windows Server 2003

Adminpak.msi file because these tools are part of the Windows Server 2003
product and are shipped when that product is released.

If you are using Windows XP Professional with Service Pack 2 and the Windows
Server 2003 Administration Tools Pack, you cannot administer Cluster servers.
However, if you are using Windows XP Professional with SP1 and the Windows
Server 2003 Administration Tools Pack, you can manage Cluster servers.

Most Windows Server 2003 administration tools work the same as their Windows
2000 counterparts. Sometimes, the Windows Server 2003 administration tools offer
increased functionality with regard to their Windows 2000 counterparts. For
example, the new drag-and-drop feature of the Windows Server 2003 Users and
Computers snap-in is fully functional against Windows 2000-based domain
controllers. In other cases, increased functionality in Windows Server 2003
administration tools is not turned on or is not supported when you administer
Windows 2000-based computers.

For example, features in the administration tools that depend on functionality in

Windows Server 2003, such as the "Saved query for last logon time" functionality, are
not supported against Windows 2000 Server-based computers because earlier-version
servers do not have the required server-side support. In rare cases, Windows Server
2003 administration tools are incompatible with Windows 2000 Server-based computers
and are unsupported for managing those computers. Similarly, in rare cases, Windows
2000 administration tools are incompatible with Windows Server 2003-based
computers.

Upgrade Windows 2000 computers to Windows Server

2003 or to Windows XP
When a Windows 2000-based computer that has the Windows 2000 Adminpak installed
is upgraded to Windows Server 2003 or to Windows XP, the System Compatibility
Report that is displayed in the upgrade process reports that the Windows 2000
administration tools are incompatible with Windows Server 2003 or with Windows XP. If
you click Details, you receive the following error message: Setup has detected Windows
2000 Administration Tools on your computer. Windows 2000 Administration Tools are
incompatible with Windows Server 2003 operating systems. Use one of the following
methods:

Cancel this upgrade, remove Windows 2000 Administration Tools, and then restart
the upgrade.
Complete this upgrade, and then immediately install the Windows Server 2003
Administration Tools Pack by running the Adminpak.msi Windows Installer package
file. Adminpak.msi is located in the \i386 folder of your Windows Server 2003 CD.

７ Note

If the Windows 2000 administration tools were left in place when the Windows
2000-based computer was upgraded to Windows Server 2003, do not try to
remove the Windows 2000 Administration Tools icon that appears in the Add or
Remove Programs item in Control Panel.

If you try to remove the Windows 2000 administration tools by using the Add or
Remove Programs tool, you may receive the following error message:

apphelp dialog cancelled thus preventing the application from starting.

Ignore this error message. When you install the Windows Server 2003 Administration
Tools Pack, the Windows 2000 Administration Tools icon is replaced by the Windows
Server 2003 Administration Tools Pack icon.

Download and install the Windows Server 2003

Administration Tools Pack on 32-bit and 64-bit Windows
XP Professional and 32-bit and 64-bit Windows Server
2003
You can install the original-release version of the Windows Server 2003 Administration
Tools Pack on computers that are running the following operating systems:

Windows XP Professional with Service Pack 2

Windows XP Professional with Service Pack 1
Windows Server 2003, 32-bit versions The original-release version of the Windows
Server 2003 Adminpak.msi file was repackaged on the Microsoft Web site as
Adminpak.exe after the release of Windows Server 2003.
You can install the Service Pack 1 version of the Windows Server 2003 Administration
Tools Pack on computers that are running the following operating systems:

Windows XP Professional with Service Pack 2

Windows XP Professional 64-bit Edition
Windows Server 2003, 32-bit versions
Windows Server 2003, 64-bit versions The latest revision of the Windows Server
2003 Administration Tools Pack is the Windows Server 2003 Service Pack 2 version.
You can install the Service Pack 2 version of the Windows Server 2003
Administration Tools Pack on computers that are running the following operating
systems:
Windows XP Professional 64 Edition
Windows Server 2003 All Editions (32-bit x86)
Windows Server 2003 Itanium-based Edition
Windows Server 2003 x64 Editions
Windows Server 2003 R2 Editions
Windows Server 2003 Storage Server R2 Edition
Windows Server 2003 Compute Cluster Edition
Windows Server 2003 for Small Business Servers R2 Edition

７ Note

The version of Adminpak that is included in the I386 folder of the installation media
for the 64-bit versions of Windows Server 2003 is called Wadminpak.msi. The
Wadminpak.msi file is identical to and interchangeable with the Adminpak.msi file
that can be downloaded from www.microsoft.com and that is included with 32-bit
versions of Windows Server 2003 Service Pack 2. For ease of installation, you can
install the Windows Server 2003 SP2 Adminpak.msi file on 32-bit or 64-bit versions
of Windows XP Professional or on 32-bit or 64-bit versions of Windows Server
2003. Similarly, you can install Wadminpak.msi on 32-bit or 64-bit versions of
Windows XP Professional or on 32-bit or 64-bit versions of Windows Server 2003.

To install the Windows Server 2003 Administration Tools Pack, follow these steps:

1. Download the Windows Server 2003 Service Pack 2 Administration Tools Pack. To
do this, visit the following Microsoft Web site: Microsoft Download Center

Perform a keyword search for "adminpak" for the "Windows XP" or "Windows
Server" operating system.

2. Log on to the local computer by using administrator credentials.

3. Remove earlier versions of the Administration Tools Pack.

You must remove earlier versions of the Administration Tools Pack before you can
install a later version, including the final release.

If you cannot use Add or Remove Programs in Control Panel to remove earlier
versions of the Administration Tools Pack, you can use the MSIZap tool from the
Support\Tools\Suptools.msi package to remove the older cached package.

If the Windows Server 2003 Beta 3 version of the Administration Tools Pack is
installed, follow these steps:

a. Save the following text as a file that is named Rrasreg.cmd:

Console

rem
rem RAS user snap-in extension - registry key cleanup, Beta 3 to RC1
rem upgrades only.
rem
rem use Reg.exe to delete the old key that was created by the Beta 3
rem RAS user extension snapin.
rem
reg delete HKEY_CLASSES_ROOT\RasDialin.UserAdminExt /f
reg delete HKEY_CLASSES_ROOT\RasDialin.UserAdminExt.1 /f
reg delete HKLM\SOFTWARE\Microsoft\MMC\NodeTypes\{19195a5b-6da0-
11d0-afd3-00c04fd930c9}\Extensions\NameSpace /f

b. Type Rrasreg.cmd at the command prompt.

4. Install the Administration Tools Pack.

Adminpak.exe is a self-extracting file that creates the Adminpak-readme.txt file and

the Adminpak.msi file in a folder that you specify when you install the file. To install
the Administration Tools Pack, right-click the .msi file, and then click Install, or
double-click the .msi file. Alternatively, by using Group Policy, you can use Active
Directory to remotely install or to publish the file to a Windows XP-based
computer or to a Windows Server 2003-based computer when a user logs on to
the computer.

For more information about how to remotely install the Administration Tools Pack,
click the following article numbers to view the articles in the Microsoft Knowledge
Base:
816102 How to use Group Policy to remotely install software in Windows Server
2003
 ７ Note

When you upgrade a Windows 2000-based server to Windows Server 2003,

the system compatibility check in Windows Server 2003 Winnt32.exe or in the
Winnt32 /checkupgradeonly process may incorrectly detect that the
Administration Tools Pack has been installed on your Windows 2000 domain
controller. This issue occurs because the Active Directory Installation Wizard
(Dcpromo.exe) on Windows 2000 uses a feature in the Windows 2000
Adminpak file to create shortcut menu items for the domain administration
tools. You may safely ignore this message and continue with the upgrade
process from Windows 2000 to Windows Server 2003.

What to expect from the original-release version of the

Windows Server 2003 Administration Tools Pack
Before you contact Microsoft Customer Support Services (CSS), see the known
compatibility issues that are described in this article, and note the release date of
their resolution.

You must remove earlier versions of Adminpak.msi (Beta 3, RC1, RC2) before you
install Windows XP SP1 on your Windows XP-based computer. If you have installed
Windows XP SP1 on a Windows XP-based computer that has the Administration
Tools Pack beta 3 version installed, you cannot use Add or Remove Programs in
Control Panel to remove earlier versions of the Administration Tools Pack.

Windows XP Home Edition-based computers cannot join Microsoft Windows NT

4.0-based, Windows 2000-based, or Windows Server 2003-based domains.
Windows XP Home Edition is not a supported operating system for Administration
Tools Pack installations.

What to do when you experience remote administration

problems
1. Confirm that you are using the latest supported version of the Adminpak.msi snap-
ins and DLL files that are available from the Microsoft Web site. You can use the
APVer.vbs script that is included with the original-release version of the Adminpak
Web download package to determine the version of the Administration Tools Pack
that you have installed on your computer. To do this, change to the folder where
you expanded Adminpak.exe, and then type apver /? to see a list of options for this
diagnostic script.
 2. See the known compatibility issues that are described in this article to determine
whether the issue is known.

3. Notify Microsoft Customer Support or your support provider.

More information

Known issues for the Windows Server 2003 original-

release version of Adminpak.msi

Installation and upgrade issues

Windows Server 2003 Winnt32.exe and the Winnt32 /checkupgradeonly process on

Windows 2000 domain controllers report that Adminpak.msi is installed when it was
never installed or when it has already been removed.

This issue occurs because the Active Directory Installation Wizard (Dcpromo.exe) in
Windows 2000 uses an internal feature of the Windows 2000 version of Adminpak.msi
to install menu shortcuts on domain controllers. You can safely ignore this warning in
Winnt32.exe and continue the upgrade. After the upgrade is complete, install the
Windows Server 2003 version of Adminpak.msi from the I386 folder of the installation
media to make sure that you have the latest version of the domain administration tools.

Active Directory Domains and Trusts

The original-release version of the Windows Server 2003 Administration Tools Pack
introduces Lightweight Directory Access Protocol (LDAP) signing. Windows 2000
domain controllers that are being remotely administered by Windows 2000-based
computers that are running Service Pack 4 (SP4), by Windows XP-based computers,
or by Windows Server 2003-based computers that are using NTLM authentication
must have Windows 2000 Service Pack 3 installed.

If you use a Windows 2000-based computer to administer Windows Server 2003-based

domains, you do not see advanced user interface (UI) features that are supported by
Windows Server 2003-based domains. For example, you do not see domain and forest
functionality or advanced trusts.

Active Directory Schema

 The original-release version of the Windows Server 2003 Administration Tools Pack
introduces LDAP signing. Windows 2000 domain controllers that are being
remotely administered by Windows 2000-based computers that are running
Service Pack 4 (SP4), by Windows XP-based computers, or by Windows Server
2003-based computers that are using NTLM authentication must have Windows
2000 SP3 installed.

The Schema may be modified on this Domain Controller check box has been
removed from the Change Schema Master dialog box. By default, schema updates
are enabled on Windows Server 2003-based domain controllers.

Active Directory Sites and Services

The original-release version of the Windows Server 2003 Administration Tools Pack
includes LDAP signing. Windows 2000 domain controllers that are being remotely
administered by Windows 2000-based computers that are running Service Pack 4
(SP4), by Windows XP-based computers, or by Windows Server 2003-based
computers that are using NTLM authentication must have Windows 2000 SP3
installed.

There is no support for editing certificate templates.

When you click Show Services Node on the View menu, the Services Node
enabled command has been removed on Windows XP clients.

When the Service Pack 1 version of Active Directory Sites and Services is started on
64-bit systems, it may not edit Group Policy. Additionally, you receive the following
error message:

Windows cannot find gpedit.msc. Make sure you typed the name correctly, and
then try again. To search for a file, click the Start button, and then click Search.

Modify the syntax of your command line or shortcut to use the following syntax:
%windir%\syswow64\mmc.exe %systemroot%\system32\dssite.msc -32

There are no known issues when Windows 2000-based forests are administered
from Windows Server 2003-based clients or from Windows XP Professional-based
clients.

Active Directory Users and Computers

The original-release version of the Windows Server 2003 Administration Tools Pack
includes LDAP signing. Windows 2000 domain controllers that are being remotely
 administered by Windows 2000-based computers that are running Service Pack 4
(SP4), by Windows XP-based computers, or by Windows Server 2003-based
computers that are using NTLM authentication must have Windows 2000 SP3
installed.

The Dial-in tab that configures Routing and Remote Access dial-in or VPN access
and callback settings is removed when the original-release version of the
Administration Tools Pack is installed on Windows XP-based clients.

Fixes or workarounds for this problem include the following:

Install Q837490 on the pre-Service Pack 2 Windows XP-based client. This hotfix
adds the remote access dial-in tab on pre-Service Pack 2 Windows XP-based
clients that are running the original-release version of the Windows Server 2003
Active Directory Users and Computers snap-in, Dsa.msc, that is installed by the
original-release version of the Windows Server 2003 Adminpak.msi.

Install the Windows Server 2003 Service Pack 2 version of Adminpak on

Windows XP-based computers that have Windows XP Service Pack 2 or later
versions installed.

Use Remote Access Policy.

Start Active Directory Users and Computers from a Windows Server 2003-based
computer or from a Windows 2000-based computer that is accessed over
Terminal Services or Remote Desktop Access.

Start Active Directory Users and Computers from the console of a Windows
Server 2003-based computer or of a Windows 2000-based computer.

To manage dial-in properties on the user account, use the remote access policy
administration model. The remote access policy administration model was
introduced in Windows 2000 to address the limitations of the earlier dial-in
account permission model. The remote access policy administration model uses
Windows groups to manage remote access permissions.

Customers who use the recommended administration model that is named "remote
access policy administration model," can use the administration package from Windows
XP to manage remote access permission for users in Active Directory. Settings on the
Dial-in tab are not typically used for VPN or wireless deployments. There are several
exceptions. For example, administrators who deploy dial-up networks may use callback
number. In these cases, use Terminal Services or Remote Desktop to access a Windows
Server 2003-based or Windows 2000-based computer, or log on to the console of a
Windows Server 2003-based computer or of a Windows 2000-based computer to
manage the Dial-in tab.

The remote access policy administration model has the following benefits:

Detailed administration

Administrators who manage dial-in permission must also have access to the whole user
account. The user account has many more security properties. In the policy
administrative model, a separate group can be created to grant dial-in permissions.
Additionally, permissions to manage access to that group can be granted to a different
administrator.

Groups for access control

Most Microsoft Windows programs use groups for access control. Groups reduce the
additional attempt of managing separate permissions network access. You can use the
same groups for controlling access to dial-up, VPN, wireless network, or file shares.

Precise connection-specific Access Policy control

There are many challenges that are introduced when you are deploying more than one
access technology at the same time. The permissions and the settings for dial-up, VPN,
and wireless technologies may be different. For example, contractors may be permitted
to access wireless networks but may not be permitted to connect from home by VPN.
Wireless may require different security settings with regard to VPN and dial-up
connections. Callback settings may be useful when you are connecting from a local area
code. However, you may want to disable callback when the user is connecting from an
international telephone number.

You can configure the remote access policy administration model in the Remote Access
Policies node of the Routing and Remote Access snap-in when the domain is configured
in Windows 2000 native mode or a later version. To remotely manage the remote access
dial-in tab in Active Directory Users or Computers or in Internet Authentication Server
(IAS) from a Windows XP-based computer, use Terminal Services or Remote Desktop to
access a Windows Server 2003-based or Windows 2000-based computer. Or, log on to
the console of a Windows Server 2003-based computer or of a Windows 2000-based
computer to configure these settings directly.

Windows XP-based computers that are joined to Windows 2000-based domain

controller domains do not support the enhanced functionality to select multiple
users and to make bulk edits for attributes such as the home folder and the profile
path. The multiple-select functionality is supported in forests where the schema
version is 15 or later versions. For example, executing the Windows Server 2003
 ADDPREP /ForestPrep and /DomainPrep in a Windows 2000-based forest and
domain would enable multiple-selection support on systems that have the
Windows Server 2003 Active Directory Users and Computers snap-in installed.

When the Service Pack 1 version of Active Directory Users and Computers is
started on 64-bit systems, it may not always edit Group Policy. Additionally, you
receive the following error message:

Windows cannot find gpedit.msc. Make sure you typed the name correctly, and then try
again. To search for a file, click the Start button, and then click Search.

Modify the syntax of your command line or shortcut to use the following syntax:
%windir%\syswow64\mmc.exe %systemroot%\system32\dsa.msc -32 back

Authorization Manager
This has been added to the Administration Tools Pack in the Windows Server 2003 RC1
version and later versions.

Certification Authority
Because of extensive schema changes, you cannot use Windows XP Professional-based
clients to administer Windows 2000-based computers, and you cannot use Windows
2000-based clients to administer Windows Server 2003-based computers. To administer
Windows Server 2003-based computers, perform remote administration from the
console or from a Terminal Services session on the destination computer, or use
Windows 2000-based clients to manage Windows 2000 Server-based computers and
Windows XP-based and Windows Server 2003-based clients.

Cluster Administrator

If you are using Windows XP Professional with Service Pack 2 and the Windows Server
2003 Administration Tools Pack, you cannot administer Cluster servers. However, if you
use Windows XP Professional with SP1 and Windows Server 2003 Administration Tools
Pack, you can manage Cluster servers.

Connection Manager Administration Kit

We do not recommend cross-version administration from Windows 2000 to Windows

Server 2003 because this does not produce Windows XP profiles.
Delegation Wizard
No known issues.

DHCP

Windows 2000 tools cannot generate a dump file of Windows Server 2003
Dynamic Host Configuration Protocol (DHCP) configurations because of code
changes.

There are no new issues in Windows Server 2003 Service Pack 2.

Distributed File System (DFS)

Adds ring, hub and spoke, and custom topology support for File Replication
Service (FRS) replication of DFS roots and links.

Configures connection priority in the Q321557 and SP3 release of Windows 2000
Ntfrs.exe.

If you are using a Windows XP-based client, you must use the Windows XP SP1
update to administer Windows Server 2003 DFS.

Adminpak now includes the Windows Server 2003 DFS Server Help file.

DNS
When you access a Domain Name System (DNS) server through an IP address, some
information that is returned, such as Forwarder information, will be incorrect. To work
around this problem, access the DNS server through a host name instead of through an
IP address. This issue applies to the original-release version of the Windows Server 2003
Administration Tools Pack.

Directory Service command-line utilities

The original-release version of the Windows Server 2003 Administration Tools Pack
includes LDAP signing. Windows 2000 domain controllers that are being remotely
administered by Windows 2000-based computers that are running Service Pack 4 (SP4),
by Windows XP-based computers, or by Windows Server 2003-based computers that
are using NTLM authentication must either have Windows 2000 SP3 installed.

Drag-and-drop functionality of Active Directory snap-ins

The original release version of Windows Server 2003 Adminpak.msi added drag-and-
drop capabilities to the following snap-ins:

Active Directory Users and Computers

Active Directory Sites and ServicesBe careful that you do not accidentally or
unknowingly move organizational units (OUs) under different parent OUs. This
action may have the following results:
User and computer accounts do not apply Group Policy as expected. Specifically,
Group Policy objects (GPOs) that are applied to user and computer accounts may
no longer apply because of a different OU hierarchy or because new GPOs may
now apply that are based on the objects' new location. The application or
nonapplication of Group Policy may affect the operating system behavior. For
example, access to operating system features and to shared resources on the
network may be affected.
Programs that are configured to use hard-coded distinguished name paths may
not always locate required objects.

Drag-and-drop behavior changes in the Windows Server 2003 SP2

version of Adminpak.msi

In the Windows Server 2003 SP2 version of Adminpak.msi, two new options are available
to control drag-and-drop behavior in the Active Directory Users and Computers snap-in
and in the Active Directory Sites and Services snap-in:

By default, a warning dialog box is presented when you try to perform a drag-and-
drop operation. You can dismiss the warning dialog box for the session. However,
the dialog box will appear again the next time that you start the snap-in.

You can disable drag-and-drop capabilities by setting the first part of the
DisplaySpecifiers attribute to 0 (zero) in the configuration naming context in
Active Directory. Because this is a forest-wide setting, drag-and-drop capabilities
will be disabled for every domain in the forest. To disable the drag-and-drop
feature, follow these steps:

７ Note

You must have the Active Directory Service Interfaces (ADSI) Edit tool installed
to complete this procedure. ADSI Edit is included with the Windows Server
2003 SP2 Support Tools. For more information, click the following article
number to view the article in the Microsoft Knowledge Base:
 892777 Updates to the Windows Server 2003 Support Tools are included in
Windows Server 2003 Service Pack 2

1. If you have the Active Directory Users and Computers snap-in or the Active
Directory Sites and Services snap-in open, close the snap-ins.
2. Click Start, click Run, type adsiedit.msc in the Open box, and then click OK.
3. Expand Configuration.
4. Expand CN=Configuration,DC=ForestRootName.
5. Right-click CN=DisplaySpecifiers, and then click Properties.
6. In the list of attributes, double-click flags.
7. In the Integer Attribute Editor dialog box, type 1 in the Value box.
8. Click OK two times.
9. Close ADSI Edit.

Microsoft Exchange

The Microsoft Exchange Simple Mail Transfer Protocol (SMTP) and Network News
Transfer Protocol (NNTP) DLL files were added to Adminpak.msi. The additional
Staxmem.dll, Smtpapi.dll, Smtpadm.dll, Smtpsnap.hlp, and Nntpsnap.hlp files were
added to Adminpak.msi to allow 32-bit Windows XP Professional-based clients to
administer the release of Exchange after Microsoft Exchange 2000.

Administration of Exchange-based servers after the Exchange 2000 version from

64-bit clients is not supported.

Help
The Ntcmds.chm Help file was added to support command-line administration.
The Windows XP Professional Help files are reinstalled when the Administration
Tools Pack is removed. Windows XP Professional versions of the Ntart.chm and
Ntcmds.chm files are backed up during the installation of the Administration Tools
Pack and are restored during removal.

Internet Information Services command-line utilities

This section applies to the following utilities:

IisApp.vbs

Iisback.vbs
 IisCnfg.vbs

IisFtp.vbs

IisFtpdr.vbs

Iisvdir.vbs

Iisweb.vbs

The following issues have been reported:

All scripts are compatible with Microsoft Internet Information Services (IIS) 6.0 only.

IISCnfg: When you use the iiscnfg /export command, the destination file (the file
that you specify after the /f switch) is created on the remote computer (the
Windows Server-based computer). For example, to export the metabase, type the
following command:

Console

iiscnfg /s RemoteServer /u UserName /p UserPwd /export /f d:\Config.xml

/sp /LM/W3SVC/1

When you run this command, the D:\Config.xml file is created on the remote
server. To import the metabase, type the following command:

Console

iiscnfg /s RemoteServer /u UserName /p UserPwd /import /f d:\Config.xml

/sp /LM/W3SVC/1 /dp /LM/W3SVC/2

７ Note

These commands are one line each. They have been wrapped for readability.

IISCnfg checks that the D:\Config.xml file (the file that you specify after the /f
switch) exists on both the local and the remote computer (RemoteServer).
However, the actual import uses only the file on the remote server. When you
import or copy the Config.xml file from the remote server, use the same path on
the local computer.

Internet Authentication Service

The Internet Authentication Service (IAS) snap-in has been removed from the
Administration Tools Pack.

Netsh

The netsh dhcp server ip dump command output is truncated. The output from
this command that is issued from a Windows Server 2003-based computer against
a Windows Server 2003-based DHCP server returns the following output:

Dhcp Server 157.59.136.135 Add Optiondef 100 "Byte Array" BYTE 1

comment="" 4 3 2 1 0 Dhcp Server 157.59.136.135 Add Optiondef 101 "String
Array" STRING 1 comment="" "hello" "cathy" "jim" "bob" Dhcp Server
157.59.136.135 Add Optiondef 102 "IP Array" IPADDRESS 1 comment=""
4.4.4.4 3.3.3.3 2.2.2.2 1.1.1.1

The same command that is issued from a Windows XP-based client is truncated as
follows:

Dhcp Server 220.0.80.23 Add Optiondef 100 "Byte Array" BYTE 1 comment=""
4 Dhcp Server 220.0.80.23 Add Optiondef 101 "String Array" STRING 1
comment="" hello Dhcp Server 220.0.80.23 Add Optiondef 102 "IP Array"
IPADDRESS 1 comment="" 4.4.4.4

By default, the netsh dhcp server command does not run from Windows XP-
based clients. For example, the following command runs successfully from a
Windows Server 2003-based computer but does not run from a Windows XP-
based client:

Dhcp Server 157.59.136.135 Add Optiondef 101 "String Array" STRING 1

comment="" "hello" "cathy" "jim" "bob"

If you run this command from a Windows XP-based client, you receive the
following error message:

DHCP Server Add OptionDef failed.

Parameter(s) passed are either incomplete or invalid.

To remotely administer a DHCP server from a Windows XP-based client, install the
Administration Tools Pack, and then type the following command at the command
prompt:
 Console

netsh add helper dhcpmon.dll

Network Load Balancing Manager

No known issues in the release version of the Windows Server 2003 Adminpak.

The Service Pack 2 Adminpak installs a 32-bit Network Load Balancing Manager
that does not bind on 64-bit versions of Windows.

Ntdsutil.exe
The authoritative restore command in Ntdsutil depends on Ntdsbsrv.dll. Ntdsbsrv.dll is
not included in Windows XP Professional or in the Windows Server 2003 Administration
Tools Pack. Perform authoritative restores from the console of Active Directory-based
domain controllers. If you must run this command on Windows XP-based clients, copy
the Ntdsbsrv.dll file from a release version of a Windows Server 2003 installation.

Object Picker

The original-release version of the Windows Server 2003 Administration Tools Pack
introduces LDAP signing. Windows 2000 domain controllers that are being remotely
administered by Windows 2000-based computers that are running Service Pack 4 (SP4),
by Windows XP-based computers, or by Windows Server 2003-based computers that
are using NTLM authentication must have Windows 2000 SP3 installed.

Remote Access User Extensions

Remote Access User Extensions have been removed from the original-release version of
the Windows Server 2003 Administration Tools Pack. The Remote Access User Extensions
are available if the version of the Adminpak.msi file that is included in Windows Server
2003 Service Pack 2 (SP2) is installed on your Windows XP Professional-based computer.
If you have the RTM or SP1 version of the Adminpak.msi file installed, you must uninstall
it and then install the Windows Server 2003 SP2 version.

Remote Desktop
Connect to Console mode is supported against Windows Server 2003-based and
Windows XP-based computers only.
Remote Storage
Cross-version administration is not supported. Remote Storage administration
from Windows 2000-based computers is not supported against Windows Server
2003-based and Windows XP-based computers. Perform remote administration
from a Windows 2000-based computer, from the console of the destination
computer, or over a Terminal Services session.

Cross-version administration is not supported. Versions of Windows Server 2003

and Windows XP that are running the Windows Server 2003 Administration Tools
Pack cannot administer Windows 2000-based computers. Perform remote
administration from a Windows Server 2003-based computer, from a Windows XP-
based computer, from the console of the destination computer, or from a Terminal
Services session.

Remote Installation Services (RIS) UI Administration Extension

No known issues.

Routing and Remote Access

This has been removed from the Administration Tools Pack.

Telephony

Telephony administrators cannot administer remote lines on a Windows 2000 Server-

based computer from a Windows XP Professional-based computer. Specifically, the Edit
users option is unavailable.

Terminal Services Licensing Manager

No known issues.

UDDI
No known issues.

Windows Server 2003 Administration Tools issues on x64-based

versions of Windows Server 2003
When you try to modify a Group Policy on an x64-based version of Windows Server
2003 from the Active Directory Users and Computers snap-in, the Active Directory Sites
and Services snap-in, or the Group Policy Management Console snap-in, you receive the
following error message:

Windows cannot find 'gpedit.msc'. Make sure you typed the name correctly and
then try again. To search for a file click the Start button and then click Search

When you try to modify a GPO from any one of the snap-ins that is listed earlier, a call is
made to start the Gpedit.msc file. Currently, the snap-ins that call the Gpedit.msc file are
32-bit tools. However, on x64-based versions of Windows Server 2003, Gpedit.msc is a
64-bit snap-in. This problem will be corrected in a future release of a 64-bit
Adminpak.msi package. To work around this problem, use either of the following
methods.

Method one

Modify the GPOs from a computer that is running a 32-bit version of Windows Server
2003, a 32-bit version of Windows XP, or a version of Windows 2000.

Method two

Use the following commands to start the snap-ins, and then modify the GPOs:

To start the Active Directory Users and Computers snap-in:

%windir%\syswow64\mmc.exe %windir%\system32\dsa.msc -32

To start the Active Directory Sites and Service snap-in: %windir%\syswow64\mmc.exe

%windir%\system32\dssite.msc -32

Compatibility of the out-of-band (OOB) version of Microsoft Group

Policy Management Console (GPMC) with 64-bit versions of
Windows XP, Windows Server 2003 and Windows Server R2
The OOB version of GPMC must be run on 32-bit platforms. The OOB version of GPMC
is not supported on 64-bit versions of Microsoft Windows. There are no plans to update
the OOB version of GPMC to support 64-bit versions of Microsoft Windows for Windows
Server 2003 or Windows XP Service Pack 2 (SP2). In 64-bit versions of Windows Vista
and of Windows Server 2008. the 64-bit version of GPMC is supported. However, GPMC
Reporting cannot be installed on all 64-bit versions of Microsoft Windows. This version
of GPMC is not part of any current Administration Tools package.
Also, you may receive the following error message when you try to open
GPMC:Windows cannot find GPEDIT.MSC. This problem occurs even though you use the
following command to open GPMC: %windir%\syswow64\mmc.exe
%windir%\system32\gpmc.msc -32

For more information, click the following article number to view the article in the
Microsoft Knowledge Base:

304718 How to use the Administration Tools Pack to remotely administer computers
that are running Windows Server 2003, Windows XP, or Windows 2000

WINS
The change to the Windows Internet Name Service (WINS) remote procedure call (RPC)
API among Windows Server 2003, Windows XP Professional, Windows 2000, and
Windows NT 4.0 prevents the remote administration of Windows NT 4.0-based WINS
servers from Windows 2000 versions of the WINS Microsoft Management Console
(MMC) snap-in and from Windows Server 2003 versions of the WINS MMC snap-in. This
is not a regression, because Windows 2000 shares the same limitation.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use the Directory Service command-line
tools to manage Active Directory
objects in Windows Server 2003
Article • 02/19/2024

This article describes how to use the Directory Service command-line tools to perform
administrative tasks for Active Directory in Windows Server 2003. The following tasks are
broken down into task groups.

Applies to: Supported versions of Windows Server

Original KB number: 322684

How to manage users

The following sections provide detailed steps to manage groups.

Create a New User Account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsadd user <user_dn> -samid <sam_name>

The following values are used in this command:

user_dn specifies the distinguished name (also known as the DN) of the user
object that you want to add.
sam_name specifies the security account manager (SAM) name used as the
unique SAM account name for this user (for example, Linda).

4. To specify the user account password, type the following command, where
password is the password that is to be used for the user account:

Console
 dsadd user <user_dn> -pwd password

７ Note

To view the complete syntax for this command, and to obtain more information
about entering more user account information, at a command prompt, type dsadd
user /? .

Reset a user password

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod user <user_dn> -pwd <new_password>

This command uses the following values:

user_dn specifies the distinguished name of the user for which the password
will be reset.
new_password specifies the password that will replace the current user
password

4. If you want to require the user to change this password at the next logon process,
type the following command:

Console

dsmod user <user_dn> -mustchpwd {yes|no}

If a password is not assigned, the first time the user tries to log on (by using a blank
password), the following logon message is displayed:

You are required to change your password at first logon

After the user has changed the password, the logon process continues.
You must reset the services that are authenticated with a user account if the password
for the service's user account is changed.

７ Note

To view the complete syntax for this command, and to obtain more information
about entering more user account information, at a command prompt, type dsmod
user /? .

Disable or enable a user account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod user <user_dn> -disabled {yes|no}

This command uses the following values:

user_dn specifies the distinguished name of the user object to be disabled or

enabled.
{yes|no} specifies whether the user account is disabled for logon (yes) or not
(no).

７ Note

As a security measure, instead of deleting that user's account, you can disable user
accounts to prevent a particular user from logging on. If you disable user accounts
that have common group memberships, you can use disabled user accounts as
account templates to simplify user account creation.

Delete a user account

1. Click Start, and then click Run.
2. In the Open box, type cmd.
 3. At the command prompt, type the dsrm <user_dn> command, where user_dn
specifies the distinguished name of the user object to be deleted.

After you delete a user account, all of the permissions and memberships that are
associated with that user account are permanently deleted. Because the security
identifier (SID) for each account is unique, if you create a new user account that has the
same name as a previously deleted user account, the new account does not
automatically assume the permissions and memberships of the previously deleted
account. To duplicate a deleted user account, you must manually re-create all
permissions and memberships.

７ Note

To view the complete syntax for this command, and to obtain more information
about entering more user account information, at a command prompt, type dsrm
/? .

How to manage groups

The following sections provide detailed steps to manage groups.

Create a new group

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsadd group <group_dn> -samid <sam_name> -secgrp {yes|no} -scope

{l|g|u}

This command uses the following values:

group_dn specifies the distinguished name of the group object that you want
to add.
sam_name specifies the SAM name that is the unique SAM account name for
this group (for example, operators).
 {yes|no} specifies whether the group you want to add is a security group (yes)
or a distribution group (no).
{l|g|u} specifies the scope of the group you want to add (domain local [l],
global [g], or universal [u]).

If the domain in which you are creating the group is set to the domain functional level
of Windows 2000 mixed, you can select only security groups with domain local scopes
or global scopes.

To view the complete syntax for this command, and to obtain more information about
entering more group information, at a command prompt, type dsadd group /? .

Add a member to a group

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod group <group_dn> -addmbr <member_dn>

This command uses the following values:

group_dn specifies the distinguished name of the group object that you want
to add.
member_dn specifies the distinguished name of the object that you want to
add to the group.

In addition to users and computers, a group can contain contacts and other groups.

To view the complete syntax for this command, and to obtain more information about
entering more user account and group information, at a command prompt, type dsmod
group /? .

Convert a group to another group type

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

 Console

dsmod group <group_dn> -secgrp {yes|no}

This command uses the following values:

group_dn specifies the distinguished name of the group object for which you
want to change the group type.
{yes|no} specifies that the group type is set to security group (yes) or
distribution group (no).

To convert a group, the domain functionality must be set to Windows 2000 Native or
higher. You cannot convert groups when the domain functionality is set to Windows
2000 Mixed.

To view the complete syntax for this command, at a command prompt, type dsmod group
/? .

Change group scope

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod group <group_dn> -scope {l|g|u}

This command uses the following values:

group_dn specifies the distinguished names of the group object to which the
scope will be changed.
{l|g|u} specifies the scope that the group is to be set to (local, global, or
universal). If the domain is still set to Windows 2000 mixed, the universal
scope is not supported. Also, it is not possible to convert a domain local
group to global group or vice versa.

７ Note
 You can only change group scopes when the domain functional level is set to
Windows 2000 native or higher.

Delete a group
1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsrm <group_dn> .

The group_dn specifies the distinguished name of the group object to be deleted.

７ Note

If you delete the group, the group is permanently removed.

By default, local groups that are provided automatically in domain controllers that are
running Windows Server 2003, such as Administrators and Account Operators, are
located in the Builtin folder. By default, common global groups, such as Domain Admins
and Domain Users, are located in the Users folder. You can add or move new groups to
any folder. Microsoft recommends that you keep groups in an organizational unit folder.

To view the complete syntax for this command, at a command prompt, type dsrm /? .

Find groups in which a user is a member

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsget user <user_dn> -memberof

The user_dn specifies the distinguished name of the user object for which you
want to display group membership.

To view the complete syntax for this command, at a command prompt, type dsget user
/? .
How to manage computers
The following sections provide detailed steps to manage computers.

Create a new computer account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsadd computer <computer_dn>

The computer_dn specifies the distinguished name of the computer you want to
add. The distinguished name indicates the folder location.

To view the complete syntax for this command, at a command prompt, type dsadd
computer /? .

To modify the properties of a computer account, use the dsmod computer command.

Add a computer account to a group

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod group <group_dn> -addmbr <computer_dn>

This command uses the following values:

group_dn specifies the distinguished name of the group object to which you
want to add the computer object.
computer_dn specifies the distinguished name of the computer object to be
added to the group. The distinguished name indicates the folder location.
When you add a computer to a group, you can assign permissions to all of the
computer accounts in that group, and then filter Group Policy settings on all accounts in
that group.

To view the complete syntax for this command, at a command prompt, type dsmod group
/? .

Reset a computer account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod computer <computer_dn> -reset

The computer_dn specifies the distinguished names of one or more computer

objects that you want to reset.

７ Note

When you reset a computer account, you break the computer's connection to
the domain. You must rejoin computer account to the domain computer
account after you reset it.

To view the complete syntax for this command, at a command prompt, type dsmod
computer /? .

Disable or enable a computer account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsmod computer <computer_dn> -disabled {yes|no}

 This command uses the following values:

computer_dn specifies the distinguished name of the computer object that

you want to disable or enable.
{yes|no} specifies whether the computer is disabled for logon (yes) or not
(no).

When you disable a computer account, you break the computer's connection with the
domain and the computer cannot authenticate to the domain.

To view the complete syntax for this command, at a command prompt, type dsmod
computer /? .

How to manage organizational units

The following sections provide detailed steps to manage organizational units.

Create a new organizational unit

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the following command:

Console

dsadd ou <organizational_unit_dn>

The organizational_unit_dn specifies the distinguished name of the organizational

unit to be added.

To view the complete syntax for this command, at a command prompt, type dsadd ou
/? .

７ Note

To modify the properties of an organizational unit, use the dsmod ou command.

Delete an Organizational Unit

1. Click Start, and then click Run.
 2. In the Open box, type cmd.

3. At the command prompt, type the command dsrm <organizational_unit_dn> .

The organizational_unit_dn specifies the distinguished name of the organizational

unit to be deleted.

To view the complete syntax for this command, at a command prompt, type dsrm /? .

７ Note

If you delete an organizational unit, all of the objects that it contains are deleted.

How to search Active Directory

The following sections provide detailed steps to search Active Directory.

Find a user account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery user <parameter> .

The parameter specifies the parameter to use. For the list of parameters, see the
online help for the d squery user command.

To view the complete syntax for this command, at a command prompt, type dsquery
user /? .

Find a contact
1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery contact <parameter> .

The parameter specifies the parameter to use. For the list of parameters, see the
online help for the dsquery user command.
Find a group
1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery group <parameter> .

The parameter specifies the parameter to use. For the list of parameters, see the
online help for the dsquery user command.

By default, local groups that are provided automatically in domain controllers that are
running Windows Server 2003, such as Administrators and Account Operators, are
located in the Builtin folder. By default, common global groups, such as Domain Admins
and Domain Users, are located in the Users folder. You can add or move new groups to
any folder. Microsoft recommends that you keep groups in an organizational unit folder.

Find a computer account

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery computer -name <name> .

The name specifies the computer name that the command searches for. This
command searches for computers whose name attributes (value of CN attribute)
match name.

To view the complete syntax for this command, at a command prompt, type dsquery
computer /? .

Find an organizational unit

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery ou <parameter> .

The parameter specifies the parameter to use. For the list of parameters, see the
online help for dsquery ou .
To view the complete syntax for this command, at a command prompt, type dsquery ou
/? .

Find a domain controller

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery server <parameter> .

The parameter specifies the parameter to use. There are several attributes of a
server that you can search by using this command. For the list of parameters, see
online help for dsquery server.

Perform a custom search

1. Click Start, and then click Run.

2. In the Open box, type cmd.

3. At the command prompt, type the command dsquery * <parameter> .

The parameter specifies the parameter to use. There are several attributes that you
can search by using this command. For more information about LDAP searches,
see the Windows Server 2003 Resource Kit.

References
For more information about the Directory Services command-line tools in Windows
Server 2003, click Start, click Help and Support Center, and then type directory service
command-line tools in the Search box.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use the UserAccountControl flags to
manipulate user account properties
Article • 02/19/2024

This article describes information about using the UserAccountControl attribute to

manipulate user account properties.

Applies to: Windows Server 2012 R2 , Windows Server 2016, Windows Server 2019,
Windows Server 2022
Original KB number: 305144

Summary
When you open the properties for a user account, click the Account tab, and then either
select or clear the check boxes in the Account options dialog box, numerical values are
assigned to the UserAccountControl attribute. The value that is assigned to the
attribute tells Windows which options have been enabled.

To view user accounts, click Start, point to Programs, point to Administrative Tools, and
then click Active Directory Users and Computers.

List of property flags

You can view and edit these attributes by using either the Ldp.exe tool or the
Adsiedit.msc snap-in.

The following table lists possible flags that you can assign. You can't set some of the
values on a user or computer object because these values can be set or reset only by the
directory service. Ldp.exe shows the values in hexadecimal. Adsiedit.msc displays the
values in decimal. The flags are cumulative. To disable a user's account, set the
UserAccountControl attribute to 0x0202 (0x002 + 0x0200). In decimal, it's 514 (2 + 512).

７ Note

You can directly edit Active Directory in both Ldp.exe and Adsiedit.msc. Only
experienced administrators should use these tools to edit Active Directory. Both
tools are available after you install the Support tools from your original Windows
installation media.
 ﾉ Expand table

Property flag Value in Value in

hexadecimal decimal

SCRIPT 0x0001 1

ACCOUNTDISABLE 0x0002 2

HOMEDIR_REQUIRED 0x0008 8

LOCKOUT 0x0010 16

PASSWD_NOTREQD 0x0020 32

PASSWD_CANT_CHANGE 0x0040 64

You can't assign this permission by directly modifying the

UserAccountControl attribute. For information about how to set
the permission programmatically, see the Property flag
descriptions section.

ENCRYPTED_TEXT_PWD_ALLOWED 0x0080 128

TEMP_DUPLICATE_ACCOUNT 0x0100 256

NORMAL_ACCOUNT 0x0200 512

INTERDOMAIN_TRUST_ACCOUNT 0x0800 2048

WORKSTATION_TRUST_ACCOUNT 0x1000 4096

SERVER_TRUST_ACCOUNT 0x2000 8192

DONT_EXPIRE_PASSWORD 0x10000 65536

MNS_LOGON_ACCOUNT 0x20000 131072

SMARTCARD_REQUIRED 0x40000 262144

TRUSTED_FOR_DELEGATION 0x80000 524288

NOT_DELEGATED 0x100000 1048576

USE_DES_KEY_ONLY 0x200000 2097152

DONT_REQ_PREAUTH 0x400000 4194304

PASSWORD_EXPIRED 0x800000 8388608

TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000 16777216

PARTIAL_SECRETS_ACCOUNT 0x04000000 67108864

 ７ Note

In a Windows Server 2003-based domain, LOCK_OUT and PASSWORD_EXPIRED

have been replaced with a new attribute called ms-DS-User-Account-Control-
Computed. For more information about this new attribute, see ms-DS-User-
Account-Control-Computed attribute.

Property flag descriptions

SCRIPT - The logon script will be run.

ACCOUNTDISABLE - The user account is disabled.

HOMEDIR_REQUIRED - The home folder is required.

PASSWD_NOTREQD - No password is required.

PASSWD_CANT_CHANGE - The user can't change the password. It's a permission

on the user's object. For information about how to programmatically set this
permission, see Modifying User Cannot Change Password (LDAP Provider).

ENCRYPTED_TEXT_PASSWORD_ALLOWED - The user can send an encrypted

password.

TEMP_DUPLICATE_ACCOUNT - It's an account for users whose primary account is

in another domain. This account provides user access to this domain, but not to
any domain that trusts this domain. It's sometimes referred to as a local user
account.

NORMAL_ACCOUNT - It's a default account type that represents a typical user.

INTERDOMAIN_TRUST_ACCOUNT - It's a permit to trust an account for a system

domain that trusts other domains.

WORKSTATION_TRUST_ACCOUNT - It's a computer account for a computer that is

running Microsoft Windows NT 4.0 Workstation, Microsoft Windows NT 4.0 Server,
Microsoft Windows 2000 Professional, or Windows 2000 Server and is a member of
this domain.

SERVER_TRUST_ACCOUNT - It's a computer account for a domain controller that is

a member of this domain.
 DONT_EXPIRE_PASSWD - Represents the password, which should never expire on
the account.

MNS_LOGON_ACCOUNT - It's an MNS logon account.

SMARTCARD_REQUIRED - When this flag is set, it forces the user to log on by

using a smart card.

TRUSTED_FOR_DELEGATION - When this flag is set, the service account (the user or
computer account) under which a service runs is trusted for Kerberos delegation.
Any such service can impersonate a client requesting the service. To enable a
service for Kerberos delegation, you must set this flag on the userAccountControl
property of the service account.

NOT_DELEGATED - When this flag is set, the security context of the user isn't
delegated to a service even if the service account is set as trusted for Kerberos
delegation.

USE_DES_KEY_ONLY - (Windows 2000/Windows Server 2003) Restrict this principal

to use only Data Encryption Standard (DES) encryption types for keys.

DONT_REQUIRE_PREAUTH - (Windows 2000/Windows Server 2003) This account

doesn't require Kerberos pre-authentication for logging on.

PASSWORD_EXPIRED - (Windows 2000/Windows Server 2003) The user's password

has expired.

TRUSTED_TO_AUTH_FOR_DELEGATION - (Windows 2000/Windows Server 2003)

The account is enabled for delegation. It's a security-sensitive setting. Accounts
that have this option enabled should be tightly controlled. This setting lets a
service that runs under the account assume a client's identity and authenticate as
that user to other remote servers on the network.

PARTIAL_SECRETS_ACCOUNT - (Windows Server 2008/Windows Server 2008 R2)

The account is a read-only domain controller (RODC). It's a security-sensitive
setting. Removing this setting from an RODC compromises security on that server.

UserAccountControl values
Here are the default UserAccountControl values for the certain objects:

Typical user: 0x200 (512)

Domain controller: 0x82000 (532480)
Workstation/server: 0x1000 (4096)
 Trust: 0x820 (2080)

７ Note

A Windows trust account is exempt from having a password through

PASSWD_NOTREQD UserAccountControl attribute value because trust objects don't
use the traditional password policy and password attributes in the same way as
user and computer objects.

Trust secrets are represented by special attributes on the interdomain trust

accounts, indicating the direction of the trust. Inbound trust secrets are stored in
the trustAuthIncoming attribute, on the "trusted" side of a trust. Outbound trust
secrets are stored in the trustAuthOutgoing attribute, on the "trusting" end of a
trust.

For two-way trusts the INTERDOMAIN_TRUST_ACCOUNT object on each side

of the trust will have both set.
Trust secrets are maintained by the domain controller which is the primary
domain controller (PDC) emulator Flexible Single Master Operation (FSMO)
role in the trusting domain.
For this reason the PASSWD_NOTREQD UserAccountControl attribute is set on
INTERDOMAIN_TRUST_ACCOUNT accounts by default.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Things to consider when you host Active
Directory domain controllers in virtual
hosting environments
Article • 02/19/2024

This article describes the issues that affect a Windows Server-based domain controller
(DC) running as a guest OS in virtual hosting environments. It also discusses things to
consider when a DC runs in a virtual hosting environment.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 888794

Summary
A virtual hosting environment lets you run multiple guest operating systems on a single
host computer at the same time. Host software virtualizes the following resources:

CPU
Memory
Disk
Network
Local devices

By virtualizing these resources on a physical computer, host software lets you use fewer
computers to deploy operating systems for testing and development, and in production
roles. Certain restrictions apply to an Active Directory DC that runs in a virtual hosting
environment. These restrictions don't apply to a DC that runs on a physical computer.

This article discusses the things to consider when a Windows Server-based DC runs in a
virtual hosting environment. Virtual hosting environments include:

Windows Server Virtualization with Hyper-V.

VMware family of virtualization products.
Novell family of virtualization products.
Citrix family of virtualization products.
Any product on the hypervisor list in the Server Virtualization Validation Program
(SVVP).

For more information about the current status of system robustness and security for
virtualized DCs, see the following article:
Virtualizing Domain Controllers using Hyper-V.

The Virtualizing Domain Controllers article provides general recommendations that

apply to all configurations. Many of the considerations that are described in that article
also apply to third-party virtualization hosts. It might include recommendations and
settings that are specific to the hypervisor that you are using, including:

How to configure time synchronization for DCs.

How to manage disk volumes for data integrity.
How to take advantage of Generation ID support in restoration or migration
scenarios.
How to manage allocation and performance of RAM and processor cores on the
virtual machine host.

７ Note

If you are using third-party virtualization hosts, consult the virtualization host
documentation for specific guidance and recommendations.

This article supplements the Virtualizing Domain Controllers article by providing more
hints and considerations that weren't in scope for the Virtualizing Domain Controllers
article.

Things to consider when you host DC roles in a

virtual hosting environment
When you deploy an Active Directory DC on a physical computer, certain requirements
must be satisfied throughout the DC's lifecycle. The deployment of a DC in a virtual
hosting environment adds certain requirements and considerations, including:

The Active Directory service helps preserve the integrity of the Active Directory
database if a power loss or other failure occurs. To do so, the service runs
unbuffered writes, and tries to disable the disk write cache on the volumes that
host the Active Directory database and log files. Active Directory also tries to work
in this manner if it's installed in a virtual hosting environment.

If the virtual hosting environment software correctly supports a SCSI-emulation

mode that supports forced unit access (FUA), unbuffered writes performed by
Active Directory in this environment are passed to the host OS. If FUA isn't
supported, you must manually disable the write cache on all volumes of the guest
OS that host:
 the Active Directory database
the logs
the checkpoint file

７ Note
You must disable the write cache for all components that use Extensible
Storage Engine (ESE) as their database format. These components include
Active Directory, the File Replication Service (FRS), Windows Internet Name
Service (WINS), and Dynamic Host Configuration Protocol (DHCP).
As a best practice, consider installing uninterruptable power supplies on
virtual machine hosts.

An Active Directory DC is intended to run Active Directory mode continuously as

soon as it's installed. Don't stop or pause the virtual machine for an extended time.
When the DC starts, replication of Active Directory must occur. Ensure that all the
DCs do inbound replication on all locally held Active Directory partitions according
to the schedule that's defined on site links and connection objects. It's especially
true for the number of days that's specified by the tombstone lifetime attribute.

If the replication doesn't occur, you might experience inconsistent content of

Active Directory databases on DCs in the forest. The inconsistency occurs because
knowledge of deletions persists for the number of days that's defined by the
tombstone lifetime. When DCs don't transitively complete inbound replication of
Active Directory changes within this number of days, objects will linger in Active
Directory. Cleaning up lingering objects can be time-consuming, especially in
multi-domain forests that include many DCs.

To recover from various problems, an Active Directory DC requires regular system

state backups. The default useful life of a system state backup is 60 or 180 days. It
depends on the OS version and the service pack revision that's in effect during the
installation. This useful life is controlled by the tombstone lifetime attribute in
Active Directory. At least one DC in every domain in the forest should be backed
up on a regular cycle, per the number of days that's specified in the tombstone
lifetime.

In a production environment, you should make daily system state backups from
two different DCs.

７ Note
 When the virtual machine host takes a snapshot of a virtual machine, the
guest OS doesn't detect this snapshot as a backup. When the host supports
the Hyper-V Generation ID, this ID would be changed when the image is
started from a snapshot or replica. By default, the DC would consider itself to
be restored from a backup.

Things to consider when you host DC roles on

clustered hosts or when you use Active
Directory as a backend in a virtual hosting
environment
When your DCs run on clustered host servers, you would expect that they are fault
tolerant. The same expectation applies to virtual server deployments that aren't
from Microsoft. However, there's one problem in this assumption: In order for the
nodes, disks and other resources on a clustered host computer to autostart,
authentication requests from the computer must be serviced by a DC in the
computer's domain. Alternatively, part of the configuration of the clustered host
must be stored in Active Directory.

To ensure that such DCs can be accessed during cluster system startup, deploy at
least two DCs in the computer's domain on an independent hosting solution
outside this cluster deployment. You can use physical hardware or another virtual
hosting solution that doesn't have an Active Directory dependency. For more
information about this scenario, see Avoid creating single points of failure.

These DCs on separate platforms should be kept online and be network-accessible

(in DNS and in all required ports and protocols) to the clustered hosts. In some
cases, the only DCs that can service authentication requests during cluster startup
are on a clustered host computer that's being restarted. In this situation,
authentication requests fail, and you must manually recover the cluster.

７ Note

Do not assume that this situation applies to Hyper-V only. Third-party

virtualization solutions can also use Active Directory as a configuration store
or for authentication during certain steps of VM startup or configuration
changes.
Support for Active Directory DCs in virtual
hosting environments
For more information, see Support policy for Microsoft software that runs on non-
Microsoft hardware virtualization software .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive Windows Time Service
event IDs 24, 29, and 38 on a virtualized
domain controller
Article • 02/19/2024

This article provides a solution to an issue where you receive the Windows Time Service
event IDs 24, 29, and 38 on a host server.

Applies to: Windows Server 2012 R2

Original KB number: 976924

７ Note

If you are a Small Business customer, find additional troubleshooting and learning
resources at the Support for Small Business site.

Symptoms
When a virtualized domain controller is running in a guest operating system on a host
server that is running Windows Server 2008 with Hyper-V, and the Windows Time
Service (W32Time) synchronizes with a primary domain controller, Windows Time
Service event IDs 24, 29, and 38 may be logged in the System log on the virtualized
domain controller.

If you enable Windows Time Services Debug logging on the domain controller,
information that resembles the following is logged in the Debug log:

149040 14:15:14.2970940s - Logging information: The time service is now

synchronizing the system time with the time source VM IC Time Synchronization
provider.

Cause
On a host server that is running Windows Server 2008 with Hyper-V, virtualized domain
controllers that are running on a guest operating system are allowed to synchronize
their system clocks with the clock of the host operating system. The events that are
listed in the Symptoms section are recorded in the System log because domain
controllers have their own time synchronization mechanism. If domain controllers
synchronize time from their own source and synchronize time from the host, the domain
controller time can change frequently. Because many domain controller tasks are tied to
the system time, a jump in the system time can cause lingering objects to be left in
caches, and may cause replication to stop.

Resolution
To resolve this issue, disable time synchronization on the host by using Integration
Services, and then configure the virtualized domain controller to accept the default
Windows Time Service (W32time) domain hierarchy time synchronization.

To do this, follow these steps:

1. Open Hyper-V Manager.

2. Click Settings.
3. Click Integration services.
4. Clear the Time Synchronization option.
5. Exit Hyper-V Manager.
6. Restart the server.

References
For more information about virtualized domain controllers, see Microsoft TechNet article
Deployment Considerations for Virtualized Domain Controllers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows computer clock resets to a
previous date and time
Article • 02/22/2024

This article provides workarounds for an issue in which the computer clock resets
incorrectly if you restart the computer while it doesn't have an internet connection.

Applies to: Windows 10 and later versions

Original KB number: 3160312

Symptoms
The system date and time setting on a computer that's running Windows 10 or a later
version incorrectly resets to a date and time that's at least one day in the past. This issue
might occur in the following scenario:

The computer is originally connected to the internet.

The computer is turned off and then restarted while it's connected to a closed
private network.
The private network has no SSL servers (therefore, the computer has no outbound
SSL traffic).

Other symptoms include, but aren't limited to, the following:

Kernel-General event ID 1 in the system log indicates that the time setting has
been reset to a past value.
Events that are recorded in the event log have invalid time stamps that are in the
past.
Kerberos authentication fails.

This behavior overrides changes that were made by an administrator.

Cause
This issue occurs because of a problem in the Secure Time Seeding feature that's part of
Windows Time service. This feature uses metadata from the computer's outgoing SSL
connections to determine the approximate current date and time values. It stores this
data in the registry. Windows can use this data to set the date and time instead of using
data from the Active Directory Domain Services (AD DS) domain hierarchy or from
another Network Time Protocol (NTP) server.

When the computer restarts in an environment where it doesn't send any outgoing SSL
traffic, the Secure Time Seeding feature doesn't clear or update the old registry data.
Instead, the Windows Time service sets the date and time based on the stale Secure
Time Seeding information from the registry.

Workaround

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

To work around this issue, try either Method 1 or Method 2, depending on your network
environment. If neither of these methods offer a practical solution, try Method 3.

Method 1: Clear the W32time registry values and force

the clock to resynchronize
You can clear the w32time registry state to force synchronize the time on the computer
with the internal NTP/NT5DS server. To do this, open an administrative Command
Prompt window, and then run the following commands, in sequence:

Console

Net stop w32time

W32tm.exe /unregister
W32tm.exe /register
net start w32time
W32tm.exe /resync /force

Method 2: Reconnect to the internet

Reconnect the computer to the internet. This issue is corrected after the computer has
access to the SSL servers on the internet and has outbound SSL traffic.

Method 3: Disable Secure Time Seeding (optional)

 ） Important

We recommend that you try the Method 1 or Method 2 workaround before you
disable the Secure Time Seeding feature. If you disable the feature, it remains
disabled even after you upgrade to a newer version of Windows.

To disable the Secure Time Seeding feature, follow these steps:

1. In an administrative Command Prompt window, run the following command:

Console

reg add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v
UtilizeSslTimeData /t REG_DWORD /d 0 /f

７ Note

This command sets the value of UtilizeSslTimeData (DWORD) to 0.

2. Restart the computer.

3. In an administrative Command Prompt window, run the following commands:

Console

Net start w32time

W32tm.exe /resync /force

These commands force the system to resynchronize the date and time. Because
Secure Time Seeding is disabled, Windows Time uses NTP to resynchronize.

７ Note

To re-enable the Secure Time Seeding feature, change the UtilizeSslTimeData

value data to 1. To do this, run the following command in an administrative
Command Prompt window, and then restart the computer:

Console

reg add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v
 UtilizeSslTimeData /t REG_DWORD /d 1 /f

More information
For more information about Secure Time Seeding, see Time accuracy improvements for
Windows Server 2016: Secure Time Seeding.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure the Windows Time
service against a large time offset
Article • 02/19/2024

This article describes how to configure the Windows Time service against a large time
offset.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 884776

Introduction
Windows operating systems include the Time Service tool (W32Time service) that is
used by the Kerberos authentication protocol. Kerberos authentication will work if the
time interval between the relevant computers is within the maximum enabled time skew.
The default is 5 minutes. You can also turn off the Time Service tool. Then, you can
install a third-party time service.

The purpose of the Time Service tool is to make sure that all the computers in an
organization that are running Microsoft Windows 2000 or later versions of Windows
operating systems use a common time. To make sure that there's an appropriate
common time usage, the Time Service uses a hierarchical relationship that controls
authority. By default, Windows-based computers use the following hierarchy:

All the client desktop computers nominate the authenticating domain controller as
their authoritative time source.

In a domain, all the servers follow the same process that client desktop computers
follow.

All domain controllers in a domain nominate the primary domain controller (PDC)
operations master as their time source.

All PDC operations masters follow the hierarchy of domains in the selection of their
time source. However, the PDC operations masters may use a parent domain
controller that is based on stratum numbering.

７ Note
 A stratum number defines how close a time server is to the primary reference
source.

The smaller the number, the closer the server is to the primary time source. In this
hierarchy, the PDC operations master at the root of the forest becomes the authoritative
time server for the organization. We highly recommend that you configure the
authoritative time server to collect the time from a hardware source. When you try to
configure the authoritative time server to sync with an Internet time source, there's no
authentication. We also recommend that you reduce your time correction settings for
the servers and for the stand-alone clients. When you follow these recommendations,
more accurate time is provided to the domain.

More information
A review of time rollbacks has shown that computers can adopt time that can be days,
months, years, or even tens of years in the future or in the past. The following issues can
occur when computers roll forward or roll backward in time:

Passwords on computer accounts, on user accounts, and on trust relationships can

be prematurely updated.
Quarantines can be identified by NTDS Replication Event 2042 in Active Directory
directory service replication.
The mismatch of passwords is authoritatively restored for computer accounts, for
user accounts, or for trust relationships. The recovery from such mismatches may
require manual password resets on all accounts and trusts that are affected.

How to protect against time that rolls forward

and time rollbacks
When computers and power cycles are restarted, the BIOS maintains time in the local
EPROM that is located on the computer's motherboard. When Windows starts, the
kernel pulls the current time from the BIOS. This current time is used as the initial time
until the W32Time service can sync up with another time source.

The Windows 32 time service supports two registry entries, the MaxPosPhaseCorrection
and the MaxNegPhaseCorrection . These entries restrict the samples that the time service
accepts on a local computer when those samples are sent from a remote computer.

When a computer that is running in a steady state receives a time sample from its time
source, the sample is checked against the phase correction boundaries that the
MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries impose. If the time

sample falls within the limits that the two registry entries enforce, this sample is
accepted for additional processing. If the time sample doesn't fall within these limits, the
time sample is ignored, and the time service logs the following message in the W32Time
private log file:

TOO BIG

If administrators reduce the value for positive and negative phase corrections,
administrators can reduce the threat that computers will receive time from invalid time
samples for a Windows-based computer. On the other hand, if administrators reduce
the value, administrators may prevent computers from being ahead or behind the
current time by more than the limits these values impose.

７ Note

If the registry entry values for positive and negative corrections are reduced, time
will be increased or decreased.

The default value for the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry

entries in Windows 2000, in Windows XP, in Windows Server 2003, and in Windows Vista
is the following value:
0xFFFFFFF

This value enables the computer to receive the time that is contained in any time
sample, whatever inaccuracy.

In Windows Server 2008, a new default value for the MaxPosPhaseCorrection and
MaxNegPhaseCorrection registry entries has been adopted. This new default value is 48
hours. This 48-hour value can be represented as either of the following values:

2a300 (hexadecimal)
172800 (decimal)

We recommend that the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry

entries are set to a value that is other than the following value:
MAX (0xFFFFFFFF)

７ Note

When you set the value to a value other than MAX (0xFFFFFFFF), you can prevent
computers from adopting time that is very inaccurate in the scenarios where the
 computer is restarted or the connectivity to external time sources is disrupted. For
example, consider the case in which you have the MaxPosPhaseCorrection and
MaxNegPhaseCorrection registry entries set for 48 hours on all domain controllers
in the forest. If any single domain controller experiences an unusual time jump of
more than 48 hours, the value that you set for the MaxPosPhaseCorrection and
MaxNegPhaseCorrection registry entries will prevent other computers from making
the same time jump. Therefore, computers that are out of sync can be kept apart
from the other computers until the administrator can investigate and take
corrective action.

Time accuracy is especially important on the forest root primary domain controller
(PDC). Because the PDC is the root time source for the domain, inaccurate time changes
on the PDC can potentially cause a domain-wide time jump. If you impose phase
correction restrictions on the PDC, you can prevent other domain controllers in the
forest from accepting the new time.

The default value of 48 hours instead of a default value of 5 minutes or 15 minutes is

based on the following reasons:

Output from W32TM utility is difficult to read.

W32TM currently doesn't target time on member computers and on member
servers.
The errors and the events that the Windows operating system and stand-alone
third-party applications log are highly inconsistent. Possible errors include return
codes that resemble the following one:
access denied
RPC Server is unavailable

７ Note

These errors have a low correlation to the time skew because the cause may
prevent Windows-based computers from adopting an accurate time value.

Daylight saving time bugs can cause 1-hour time differences.

AM or PM misconfiguration can cause a 12-hour time difference.
Day or date mistakes can cause a 24-hour time difference.

So 48 hours was the next obvious time offset after 25 or 36 hours. Administrators can
also reduce the value with correct tools that report infrastructure and testing.

Specific recommendations according to operating system version and computer role are
described in the following sections.
Windows XP Professional and all versions of
Windows Server 2003
Domain servers

Forest root PDC (authoritative time server)

We highly recommend that you configure the authoritative time server to collect the
time from a hardware source. When you configure the authoritative time server to sync
with an Internet time source, there's no authentication. You must reconfigure the
following registry entries:

MaxPosPhaseCorrection
MaxNegPhaseCorrection

The default value of these two registry entries is 0xFFFFFFFF. This default value means
"Accept any time change." We recommend a value that is 48 hours. It's represented in
the registry as 2a300 (hexadecimal) or 172800 (decimal). We recommend that you set
the value of the MaxPollInterval registry entry to 10 or less or that you set the value of
the SpecialPollInterval registry entry to 3600 (1 hour) or less.

Domain controllers and member servers inside the

domain
The MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries have a default
value of 0xFFFFFFFF. This default value means "Accept any time change." We
recommend setting this value to 48 hours on all domain controllers. The 48 hours value
can also be set on member servers that are running time sensitive-based applications.

７ Note

For more information about these registry entries, see the Windows Server 2003
and Windows XP Time Service registry entries section.

Stand-alone clients
The MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries have a default
value of 54,000 (15 hours). As a security best practice, we recommend that you reduce
this default value. We also recommend that you set the value to 3600 (1 hour) or an
even smaller value, depending on time source, on network condition, on poll interval,
and on security requirements.

Windows Server 2003 and Windows XP Time

Service registry entries
ﾉ Expand table

Type Details

Registry MaxPosPhaseCorrection
Entry

Value DWORD
Type

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Notes This entry specifies the largest positive time correction in seconds that the service can
make. If the service determines that a change larger than it's required, it logs an event
instead. Special case: 0xFFFFFFFF means to always make the time correction. The default
value for domain members is 0xFFFFFFFF. The default value for stand-alone clients and
servers is 54,000 (15 hours).

Registry MaxNegPhaseCorrection
Entry

Value DWORD
Type

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Notes This entry specifies the largest negative time correction in seconds that the service can
make. If the service determines that a change larger than this is required, it logs an event
instead. Special case: -1 means always make the time correction. The default value for
domain members is 0xFFFFFFFF. The default value for stand-alone clients and servers is
54,000 (15 hours).

Registry MaxPollInterval
Entry

Value DWORD
Type

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Notes This entry specifies the largest interval, in seconds, that is enabled for the system polling
interval. Notice that, although a system must poll according to the scheduled interval, a
 Type Details

provider can refuse to produce samples when samples are requested. The default value
for domain members is 10. The default value for stand-alone clients and servers is 15.

Registry SpecialPollInterval
Entry

Value DWORD
Type

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Notes This entry specifies the special poll interval in seconds for manual peers. When the
SpecialInterval 0x1 flag is enabled, W32Time uses this poll interval instead of a poll
interval that the operating system determines. The default value on domain members is
3,600. The default value on stand-alone clients and servers is 604,800.

７ Note

We recommend that you use the Global Policy object Editor to deploy these
settings. For more information about the Windows Time service in a Windows
Server 2003-based forest, see Windows Time Service (W32Time).

The default Windows Time service parameter values that are defined in the Group Policy
object (GPO) may not match the default values that are defined in the registry of
Windows Server 2003-based domain controllers. When you deploy
MaxPosPhaseCorrection and MaxNegPhaseCorrection values to Windows Server 2003
domain controllers by using a GPO, make sure that the GPO isn't changing the values of
other Windows Time service parameters in the registry. Other Windows Time service
parameter values may also have to be changed in the GPO to match the default registry
values in the domain controllers.

All versions of Windows 2000 Service Pack 4

(SP4)
Domain servers

Forest root PDC (authoritative time server)

We highly recommend that you configure the authoritative time server to collect the
time from a hardware source. When you configure the authoritative time server to sync
with an Internet time source, there's no authentication in manual mode. You can
reconfigure the MaxAllowedClockErrInSecs registry entry. The default value is 43,200. The
recommended value is 900 (15 minutes) or an even smaller value, depending on time
source, on network conditions, and on security requirements. It also depends on the poll
interval. We recommend that the poll interval value is set to one hour for every 24 hours.

７ Note

For more information about this registry entry, see Windows Server 2000 SP 4
registry entry section.

Domain controllers and member servers inside the

domain
The synchronization type is NT5DS. The time service synchronizes from the domain
hierarchy and the time service accepts all-time changes. Because NT5DS accepts any
time change without considering the time offset, it's important to set up a reliable forest
root time source in the time sync subnet.

７ Note

The NT5DS value indicates that the synchronization type is obtained from a registry
entry.

Stand-alone clients
The MaxAllowedClockErrInSecs registry entry has a default value of 43,200 (12 hours). As
a security best practice, we recommend that you reduce this default value. We
recommend that you set the value to 3600 (1 hour) or to an even smaller value,
depending on time source, on network conditions, on poll interval, and on security
requirements.

Windows Server 2000 SP 4 registry entry

ﾉ Expand table

Type Details

Registry MaxAllowedClockErrInSecs
Entry
 Type Details

Value DWORD
Type

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Notes Specifies the maximum clock change that is enabled in seconds. When the event is
logged, the time isn't adjusted based on the value. This behavior occurs to help protect
against any suspicious time stamp activity. The default value for domain members is
43,200.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to convert date/time attributes in
Active Directory to standard time
format
Article • 02/19/2024

This article describes how attributes that contain a date/time value can be converted to
standard meaningful date/time formats.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 555936

Summary
The Active Directory stores date/time values as the number of 100-nanosecond intervals
that have elapsed since the 0 hour on January 1, 1601 until the date/time that is being
stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory.
Some examples of Active Directory attributes that store date/time values are LastLogon,
LastLogonTimestamp, and LastPwdSet. In order to obtain the date/time value stored in
these attributes into a standard format, some conversion is required. This article
describes how this conversion can be done.

Procedure
1. Obtain the value of the Active Directory attribute that you want to convert. There
are many ways to extract values of Active Directory attributes. Using ADSI Edit is
one method.
2. Open the Command Prompt.
3. Type the following command:
w32tm.exe /ntte [time in Windows NT time format]

4. The date/time value is converted to local time and displayed.

Example
The command w32tm.exe /ntte 128271382742968750 will yield "148462 05:57:54.2968750
- 6/24/2007 8:57:54 AM (local time)" on a computer that is in a time zone three hours
ahead of Greenwich Mean Time (GMT +3:00). Notice that the first half of the output
displays the time in GMT (05:57:54) and then converts it by adding the Time Zone Offset
(8:57:54).

Community solutions content disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title, and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you run the
"w32tm /resync" command to
synchronize Windows Server 2003 or
Windows SBS to an external time
source: "The computer did not resync
because no time data was available"
Article • 02/19/2024

This article provides a solution to an error that occurs when you run the w32tm /resync
command to synchronize Windows Server 2003 or Windows SBS to an external time
source.

Applies to: Windows Server 2003

Original KB number: 929276

Symptoms
When you run the w32tm /resync command to synchronize Microsoft Windows Server
2003 or Microsoft Windows Small Business Server 2003 (Windows SBS) to an external
time source, you receive the following error message:

The computer did not resync because no time data was available.

If you run the w32tm /config /syncfromflags:manual command or the w32tm /config
/manualpeerlist:peerlist command to determine whether Windows is configured

correctly, the commands complete successfully.

Cause
This problem occurs if a Group Policy object for a Windows Time Service object is
configured incorrectly.

Resolution
To resolve this problem, examine the Group Policies that set the Windows Time Service
Group Policy objects to their default values or to a value of Not Configured. Examine
Group Policies on the computer and in the organization. Set these Windows Time
Service Group Policy objects to use a value of Not Configured. To do this, follow these
steps:

1. Open the container that contains the Group Policy object that you want to modify.
To do this, follow these steps.

For a domain object

a. On a domain controller, click Start, click Run, type dsa.msc, and then click OK.

b. In the Active Directory Users and Computers Microsoft Management Console

(MMC) snap-in, right-click the container that contains the Group Policy object,
and then click Properties. For example, right-click the container that represents
the domain or the organizational unit, and then click Properties.

７ Note

If the server that has this problem is a domain controller, examine the
Group Policy objects in the Domain Controllers container.

c. In the ContainerName Properties dialog box, click the Group Policy tab.

d. Click the Group Policy object that you want to modify, and then click Edit. For
example, if you are examining the Group Policy objects in the Domain
Controllers container, click Default Domain Controllers Policy, and then click
Edit.

For a local computer object

Click Start, click Run, type gpedit.msc, and then click OK.

2. In the Group Policy Object Editor MMC snap-in, expand Computer Configuration,
expand Administrative Templates, expand System, and then click Windows Time
Service.

3. In the right pane, right-click Global Configuration Settings, and then click
Properties.

4. In the Global Configuration Settings Properties dialog box, click Not Configured,
and then click OK.
 5. Expand Windows Time Service, click Time Providers, and then set all the objects in
this node to Not Configured. To do this, follow these steps:
a. In the right pane, double-click Enable Windows NTP Client, click Not
Configured, and then click OK.
b. In the right pane, double-click Configure Windows NTP Client, click Not
Configured, and then click OK.
c. In the right pane, double-click Enable Windows NTP Server, click Not
Configured, and then click OK.

6. Exit Group Policy Object Editor, and then click OK to exit the ContainerName
Properties dialog box.

7. Update Group Policy on the server that has this problem. To do this, follow these
steps:
a. Click Start, click Run, type cmd, and then click OK.
b. At the command prompt, type gpupdate /force , and then press ENTER.

More Information
For more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
816042 How to configure an authoritative time server in Windows Server 2003

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event 142: The time service has stopped
advertising as a time source
Article • 03/20/2024

This article provides a resolution for event 142: The time service has stopped advertising
as a time source.

Applies to: Windows Server 2012 R2

Original KB number: 2468336

Symptoms
Microsoft-Windows-Time-Service Event 142 is logged with one of four error strings
listed in the table below (less the event_<hex error> string:

Log Name: System

Source: Microsoft-Windows-Time-Service
Date: <date> <time>
Event ID: 142
Task Category: None
Level: Warning
Keywords:
User: LOCAL SERVICE
Computer: <hostname>.<domain name>.<top level domain>
Description:

ﾉ Expand table

Error status Error string

event_0x0038 The time service has stopped advertising as a time source because the local
machine is not an Active Directory Domain Controller.

event_0x0039 The time service has stopped advertising as a time source because there are no
providers running.

event_0x003A The time service has stopped advertising as a time source because there are no
providers running.

event_0x003B The time service has stopped advertising as a good time source.

The local clock is not synchronized

 Event Xml:
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event ">
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{06EDCFEB-0FD0-
4E53-ACCA-A6F8BBF81BCB}" />
<EventID>142</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="YYYY-MM-DDTHH:MM:SS.MSZ" />
<EventRecordID>3965</EventRecordID>
<Correlation />
<Execution ProcessID="<PID>" ThreadID="<TID>" />
<Channel>System</Channel>
<Computer> DC1.contoso.com </Computer>
<Security UserID="<SID>" />
</System>
<EventData Name="TMP_EVENT_STOP_ADVERTISING">
</EventData>
</Event>

Cause
ﾉ Expand table

Error string Cause

The time service has stopped advertising as a time The local machine no longer host the DC
source because the local machine is not an Active role or there is a configuration problem
Directory Domain Controller. with the local machine.

The time service has stopped advertising as a time The NTP client service has stopped or is
source because there are no providers running. non-responsive

The time service has stopped advertising as a time Time on the local computer has fallen out of
source because there are no providers running. sync with its peer

The time service has stopped advertising as a good The local DC is unable to locate a time
time source. server
Resolution
The dominant error string logged by Microsoft-Windows-Time-Service Event 142 is the
third example:

"The time service has stopped advertising as a time source because there are no
providers running."

1. Execute the action plan in Technet's "Event ID 142 - Time Service Advertisement "

2. Verify that the forest root PDC is online, healthy and that the current root domain
PDC is both (1.) correctly configured to sync time with an external time source and
(2.) able to reliably source time from that source.

3. Verify service startup values and service state: automatic + running

4. Verify that the DC logging the 142 event can discovery a time server using
DCLocator

nltest /dsgetdc:<dns domain> /timeserv /force

nltest /dsgetdc:<dns domain> /gtimeserv /force <- if a gtimesrv is configured
in the environment

5. Verify port and protocol connectivity to peer time servers

w32tm /query /source

6. Check for the use of dueling time protocols by looking for the following events:

ﾉ Expand table

Microsoft- note the protocol + source DC in event

Windows-Time-
Service event
35

Microsoft- <note the protocol + source DC in event

Windows-Time-
Service event 37

Microsoft- The Microsoft-Windows-Kernel-General event 1 indicates that time has

Windows- been changed in the VM. Every time W32time updates the clock, this
Kernel-General event is logged. Every time Hyper-V Time Synch updates the clock,
event 1. Microsoft-Windows-Kernel-General event 1 is logged. This event is not
 Microsoft- note the protocol + source DC in event
Windows-Time-
Service event
35

specific to VMs as it is also logged in physical machines when w32time

updates the clock

7. Other root causes

AnnounceFlags = 10 on forest-root PDC. This setting may be explicitly set or in the

registry or defined in group policy.

If the computer logging Microsoft-Windows-Time-Service event 142 is a virtualized

guest computer residing on a Hyper-V host, disable VMICTimeSync on the Hyper-
V host.

More information
Real-world customer experience
RDP logons from \\workstation1 (joined to the fabrikam.com domain) to \\DC1 in the
untrusted contoso.com domain fails with the following error:

Title Bar text: Remote Desktop Connection

Dialog message text: Remote Desktop cannot verify the identity of the remote
computer because there is a time or date difference between your computer and
the remote computer. Make sure your computer's clock is set to the correct time,
and then try the connecting again. If the problem occurs again, contact your
network administrator or the owner of the remote computer

The contoso.com domain contains two virtualized DCs, \\DC1 and \\DC2 running on the
same W2K8 R2 Hyper-V host. The Hyper-V host computer for \\DC1 and \\DC2 is a
member server in the fabrikam.com domain - that is, the same domain as the RDCP
client, \\workstation1 .

The system time on \\workstation1 is reported as being seconds apart from the system
time on \\DC1 . The system time on \\DC2.contoso.com domain was reported as being
45 minutes from current time and the time that existed on \\DC1 .

For more information about how to troubleshoot the error, see "Remote Desktop
cannot verify the identity of the remote computer" when connecting to a remote
machine.
A review of the SYSTEM event log to look for Kerberos and Time-related errors showed
the following events.

Microsoft-Windows-Time-Service Event 142 was logged on \\DC2.contoso.com . The

primary cause if the 142 error is the inability to locate a time server or sync from a peer
server.

Log Name: System

Source: Microsoft-Windows-Time-Service
Date: <date> <time>
Event ID: 142
Task Category: None
Level: Warning
Keywords:
User: LOCAL SERVICE
Computer: DC2.contoso.com
Description:
The time service has stopped advertising as a time source because the local clock is
not synchronized.
Event Xml:
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event ">
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>}" />
<EventID>142</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="YYYY-MM-DDTHH:MM:SS.MSZ" />
<EventRecordID>3965
<Correlation />
<Execution ProcessID="<PID>" ThreadID="<TID>" />
<Channel>System</Channel>
<Computer>DC1.contoso.com</Computer>
<Security UserID="<SID>" />
</System>
<EventData Name="TMP_EVENT_STOP_ADVERTISING">
</EventData>
</Event>
Microsoft-WIndows-Time-Service event 35 logged on the console of \\DC1.contoso.com
indicates that PDC \\DC1 is using the VM IC time sync provider to sync time.

Log Name: System

Source: Microsoft-Windows-Time-Service
Date: <date> <time>
Event ID: 35
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: dc1.contoso.com
Description:
The time service is now synchronizing the system time with the time source VM IC
Time Synchronization Provider.
Event Xml:
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event "
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>}" />
<EventID>35</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="<DateTime>" />
<EventRecordID>2614</EventRecordID>
<Correlation />
<Execution ProcessID="1012" ThreadID="2508" />
<Channel>System</Channel>
<Computer>dc1.contoso.com</Computer>
<Security UserID="<sid>" />
</System>
<EventData Name="TMP_EVENT_TIME_SOURCE_CHOSEN">
<Data Name="TimeSource">VM IC Time Synchronization Provider
</EventData>
</Event>

Microsoft-WIndows-Time-Service event 37 logged on the console \\DC2.contoso.com

indicates that \\DC2 is also sourcing NTP time from \\DC1.contoso.com
 Log Name: System
Source: Microsoft-Windows-Time-Service
Date: <date><time>
Event ID: 37
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: DC2.contoso.com
Description:
The time provider NtpClient is currently receiving valid time data from jwesth-
t1.jwesth.nttest.microsoft.com (ntp.d|[::]:123->

[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123).
Event Xml:
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event ">
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>}" />
<EventID>37
<Version>0
<Level>4
<Task>0
<Opcode>0
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="<DateTime>" />
<EventRecordID>3972
<Correlation />
<Execution ProcessID="1012" ThreadID="1596" />
<Channel>System</Channel>
<Computer>DC2.contoso.com</Computer>
<Security UserID="<sid>" />
</System>
<EventData Name="TMP_EVENT_TIME_SOURCE_REACHABLE">
<Data Name="TimeSource"> dc1.contoso.com (ntp.d|[::]:123->
[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123)
</EventData>
</Event>

Another event, Microsoft-Windows-Kernel-General, which was not logged in this

particular case, indicates that the Hyper-V host computer may be changing time on VM
guests computers. A sample event is shown below.
 Log Name: System
Source: Microsoft-Windows-Kernel-General
Date: <date> <time>
Event ID: 1
Task Category: None
Level: Information
Keywords: Time
User: LOCAL SERVICE
Computer: <hostname>.<DNS domain>.<top level domain>
Description:
The system time has changed to <
‎ new time in the format "like"
2010‎-‎08‎-‎26T20:40:07.210000000Z > from <old time in the format "like"
‎2010‎-‎08‎-‎26T20:40:07.210642400Z>.

That Microsoft-Windows-Kernel-General event 1 indicates that time has been changed

in the VM. Every time W32time updates the clock, this event is logged. Every time
Hyper-V Time Synch updates the clock, Microsoft-Windows-Kernel-General event 1 is
logged. This event is not specific to VMs as it is also logged in physical machines when
w32time updates the clock.

Problem Summary
The RDP client is believed to depend on SPNego that picks the best authentication
mechanism available, and in this case used Kerberos, event though there was no trust
between the fabrikam and contoso.com forests. Kerberos auth requires that the clocks of
the two machines to be less than 5 minutes apart but does not care about the clock
accuracy.

The RDP logon failure is caused by the authenticating DC in the contoso.com domain
(DC1) refusing to authenticate the RDP client logon request because the client's time
doesn't match the server's time. Either the client, or the server, or both could have an
unsynchronized clock.

The time difference in this case was exacerbated by several factors

1. The RDP Client and KDC / RDP Server existed in two different forests with each
forest using different time sourcing configurations

2. The KDC and RDP Server used by the RDC client are both virtualized domain
controllers that require additional configuration changes to accurately source time
then DCs running on physical hardware.
 3. The virtual host computer was a domain-joined member server in a different
domain than the Hyper-V hosts

Time accuracy on virtual host computers is important because VM guest

computers initially derive time from virtual host computer during OS startup.

Two negative factors for \\DC1 and |DC2 is that member computers poll time less
frequently by default than domain controllers. Secondly, the Hyper-V host
computer was joined to a different domain than the DC guests and was subject to
different time source configurations

Finally, the VMICTimeSync was used by \\DC2 to source time that is not
recommended for virtualized computers hosting the DC role computers.

4. The forest root PDC in the contoso.com domain was not configured to source time
from an external time source

In this case, the use of multiple time providers in the contoso.com domain ( ntp ,
VMICTimeSync) was deemed to be the root cause of the inaccurate time that lead to the
RDP logon failure.

There are differing opinions about how to configure time in host and guest computers
within the AD and Hyper-V teams. Ryan Sizemores recommendation as of 2010.11.22
was to leave VMIC enabled but pay close attention to the configuration and accuracy of
time on the host computer. For example, the "Configuring the Windows Time service for
Windows Server 2008 and Windows Server 2008 R2" section of "Deploying W2K8 and
W2K8 R2 DCs in existing domains " recommends that virtual host computers be
configured with "DC-like" polling intervals and max*phase correction settings + an
accurate time server, similar to what you'd do on a forest-root PDC.

The use of different time providers and time sources on the virtual host and virtual guest
environments can lead to a situation where time on the guest computer will ping pong
between the VMIC values passed from the host computer. This condition may exist
when virtualized DC guests in one forest are hosted by virtual hosts computers in
another forests or even a workgroup computer where each uses a different time source
/ time configuration and the time samples are different between the two.

The Hyper-V team recommends that you don't disable VMICTimeSync as it provides
protection against time synchronization issues if you used saved state. The key issue
here is not the use of VMICTimeSync - but the fact that if you are running a domain
controller something needs to be getting accurate time from a remote server. You can
do it by either configurating a remote time source inside the virtual machine, or by
leaving the VMICTimeSync enabled and configuring the host to use a reliable time
source.

By setting up a virtual machine with VMICTimeSync disabled - and no external time

source the domain controller will use local time - which is the one thing that is always
guaranteed to be wrong in a virtual machine.

Recommendations from the Microsoft Windows time team to correct this environment
consisted of:

1. Configure the forest root PDC with an NTP Server.

2. Configure a GTIMEServer in the forest root domain as a backup

3. If using virtualization, disable VMICTimeSync (it is being evaluated

4. Configure Hyper-V hosts with an external time server

5. Configure Hyper-V hosts with the same polling intervals as domain controllers

6. Enable time rollback protection on Hyper-V hosts.

Useful commands (source: Carlos Trueba Salinas)

net stop vmictimesync

sc config vmictimesync start= disabled

reg delete

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTim
eProvider" /f

w32tm /config /manualpeerlist:ntdev-dc-05.ntdev.corp.microsoft.com

/syncfromflags:MANUAL /update
net stop w32time & net start w32time

w32tm /query /source

w32tm /resync /force

Event ID 142 - Time Service Advertisement

Time Service Advertisement - Technet
Configuring the Windows time service on the PDC emulator in the Forest root domain
Configuring the Windows Time service for Windows Server 2008 and Windows Server
2008 R2
Running Domain Controllers in Hyper-V
Configuring the Windows Time Service in an Active Directory Forest - A Step by Step
with a Contingency Plan
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure an authoritative time
server in Windows Server
Article • 02/19/2024

This article describes how to configure the Windows Time service and troubleshoot
when the Windows Time service doesn't work correctly.

Applies to: Windows Server 2012 Standard, Windows Server 2012 Essentials
Original KB number: 816042

To configure an internal time server to synchronize with an external time source, use the
following method:

To configure the PDC in the root of an Active Directory forest to synchronize with an
external time source, follow these steps:

1. Change the server type to NTP. To do this, follow these steps:

a. Select Start > Run, type regedit, and then select OK.

b. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

c. In the pane on the right, right-click Type, and then select Modify.

d. In Edit Value, type NTP in the Value data box, and then select OK.

2. Set AnnounceFlags to 5. To do this, follow these steps:

a. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

b. In the pane on the right, right-click AnnounceFlags, and then select Modify.

c. In Edit DWORD Value, type 5 in the Value data box, and then select OK.

７ Note

If an authoritative time server that is configured to use an AnnounceFlag

value of 0x5 does not synchronize with an upstream time server, a client
server may not correctly synchronize with the authoritative time server
when the time synchronization between the authoritative time server
and the upstream time server resumes. Therefore, if you have a poor
 network connection or other concerns that may cause time
synchronization failure of the authoritative server to an upstream server,
set the AnnounceFlag value to 0xA instead of to 0x5.
If an authoritative time server that is configured to use an AnnounceFlag
value of 0x5 and to synchronize with an upstream time server at a fixed
interval that is specified in SpecialPollInterval , a client server may not
correctly synchronize with the authoritative time server after the
authoritative time server restarts. Therefore, if you configure your
authoritative time server to synchronize with an upstream NTP server at
a fixed interval that is specified in SpecialPollInterval , set the
AnnounceFlag value to 0xA instead of 0x5.

3. Enable NTPServer. To do this, follow these steps:

a. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\
NtpServer

b. In the pane on the right, right-click Enabled, and then select Modify.

c. In Edit DWORD Value, type 1 in the Value data box, and then select OK.

d. Specify the time sources. To do this, follow these steps:

i. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

ii. In the pane on the right, right-click NtpServer, and then select Modify.

iii. In Edit Value, type Peers in the Value data box, and then select OK.

７ Note

Peers is a placeholder for a space-delimited list of peers from which

your computer obtains time stamps. Each DNS name that is listed must
be unique. You must append ,0x1 to the end of each DNS name. If you
do not append ,0x1 to the end of each DNS name, the changes that you
make in step 5 will not take effect.

4. Configure the time correction settings. To do this, follow these steps:

 a. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

b. In the pane on the right, right-click MaxPosPhaseCorrection, and then select

Modify.

c. In Edit DWORD Value, click to select Decimal in the Base box.

d. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
select OK.

７ Note

TimeInSeconds is a placeholder for a reasonable value, such as 1 hour

(3600) or 30 minutes (1800). The value that you select will depend on the
poll interval, network condition, and external time source.
The default value of MaxPosPhaseCorrection is 48 hours in Windows
Server 2008 R2 or later.

e. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

f. In the pane on the right, right-click MaxNegPhaseCorrection, and then select

Modify.

g. In Edit DWORD Value, click to select Decimal in the Base box.

h. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
select OK.

７ Note

TimeInSeconds is a placeholder for a reasonable value, such as 1 hour

(3600) or 30 minutes (1800). The value that you select will depend on the
poll interval, network condition, and external time source.
The default value of MaxNegPhaseCorrection is 48 hours in Windows
Server 2008 R2 or later.

5. Close Registry Editor.

6. At the command prompt, type the following command to restart the Windows
Time service, and then press Enter:
 Windows Command Prompt

net stop w32time && net start w32time

Troubleshooting
For the Windows Time service to function correctly, the networking infrastructure must
function correctly. The most common problems that affect the Windows Time service
include the following:

There is a problem with TCP/IP connectivity, such as a dead gateway.

The Name Resolution service is not working correctly.
The network is experiencing high volume delays, especially when synchronization
occurs over high-latency wide area network (WAN) links.
The Windows Time service is trying to synchronize with inaccurate time sources.

We recommend that you use the Netdiag.exe utility to troubleshoot network-related

issues. Netdiag.exe is part of the Windows Server 2003 Support Tools package. See Tools
Help for a complete list of command-line parameters that you can use with Netdiag.exe.
If your problem is still not solved, you can turn on the Windows Time service debug log.
Because the debug log can contain very detailed information, we recommend that you
contact Microsoft Customer Support Services when you turn on the Windows Time
service debug log.

７ Note

In special cases, charges that are ordinarily incurred for support calls may be
canceled if a Microsoft Support Professional determines that a specific update will
resolve your problem. The usual support costs will apply to additional support
questions and issues that do not qualify for the specific update in question.

More information
Windows Server includes W32Time, the Time Service tool that is required by the
Kerberos authentication protocol. The Windows Time service makes sure that all
computers in an organization that are running the Microsoft Windows 2000 Server
operating system or later versions use a common time.

To guarantee appropriate common time usage, the Windows Time service uses a
hierarchical relationship that controls authority, and the Windows Time service does not
allow for loops. By default, Windows-based computers use the following hierarchy:

All client desktop computers nominate the authenticating domain controller as

their in-bound time partner.
All member servers follow the same process that client desktop computers follow.
All domain controllers in a domain nominate the primary domain controller (PDC)
operations master as their in-bound time partner.
All PDC operations masters follow the hierarchy of domains in the selection of their
in-bound time partner.

In this hierarchy, the PDC operations master at the root of the forest becomes
authoritative for the organization. We highly recommend that you configure the
authoritative time server to obtain the time from a hardware source. When you
configure the authoritative time server to sync with an Internet time source, there is no
authentication. We also recommend that you reduce your time correction settings for
your servers and stand-alone clients. These recommendations provide more accuracy
and security to your domain.

References
For more information about Windows Time service, see:

How to turn on debug logging in the Windows Time service

How to configure the Windows Time service against a large time offset

For more information about the Windows Time service, see Windows Time Service
(W32Time).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How the Windows Time service treats a
leap second
Article • 02/19/2024

This article describes how the Windows Time service treats a leap second.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 909614

When the Windows Time service is working as

a Network Time Protocol (NTP) client
The Windows Time service does not indicate the value of the Leap Indicator when the
Windows Time service receives a packet that includes a leap second. (The Leap Indicator
indicates whether an impending leap second is to be inserted or deleted in the last
minute of the current day.) Therefore, after the leap second occurs, the NTP client that is
running Windows Time service is one second faster than the actual time. This time
difference is resolved at the next time synchronization.

For more information about Windows time synchronization, see How the Windows Time
Service Works.

When the Windows Time service is working as

an NTP server
No method exists to include a leap second explicitly for the Windows Time service when
the service is working as an NTP server.

However, if an external NTP server sends a Leap Indicator that has a value of 01 to the
Windows Time service NTP server, the Windows NTP server sends the same value to
following NTP client.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Support boundary for high-accuracy
time
Article • 02/19/2024

This article describes the support boundaries for the Windows Time service (W32Time)
in environments that require highly accurate and stable system time.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10 version 1607 or later, Azure Stack HCI, versions 21H2 and 20H2

High accuracy support for Windows 8.1 and

2012 R2 (or prior)
Earlier versions of Windows (Prior to Windows 10 1607 or Windows Server 2016 1607)
can't guarantee highly accurate time. The Windows Time service on these systems:

Provided the necessary time accuracy to satisfy Kerberos version 5 authentication

requirements
Provided loosely accurate time for Windows clients and servers joined to a
common Active Directory forest

Tighter accuracy requirements were outside of the design specification of the Windows
Time Service on these operating systems and isn't supported.

Windows 10 and Windows Server 2016

Time accuracy in Windows 10 and Windows Server 2016 has been substantially
improved, while maintaining full backwards NTP compatibility with older Windows
versions. Under the right operating conditions, systems running Windows 10 or
Windows Server 2016 and newer releases can deliver 1 second, 50 ms (milliseconds), or
1-ms accuracy.

） Important

Highly accurate time sources

The resulting time accuracy in your topology is highly dependent on using an

accurate, stable root (stratum 1) time source. There are Windows based and
non-Windows based highly accurate, Windows compatible, NTP Time source
 hardware sold by 3rd-party vendors. Please check with your vendor on the
accuracy of their products.

Time accuracy

Time accuracy entails the end-to-end distribution of accurate time from a

highly accurate authoritative time source to the end device. Anything that
introduces network asymmetry will negatively influence accuracy, for example
physical network devices or high CPU load on the target system.

High accuracy requirements

The rest of this document outlines the environmental requirements that must be
satisfied to support the respective high accuracy targets.

Target accuracy: 1 second (1 s)

To achieve 1-s accuracy for a specific target machine when compared to a highly
accurate time source:

The target system must run Windows 10, Windows Server 2016.
The target system must synchronize time from an NTP hierarchy of time servers,
culminating in a highly accurate, Windows compatible NTP time source.
All Windows operating systems in the NTP hierarchy mentioned above must be
configured as documented in the Configuring Systems for High Accuracy
documentation.
The cumulative one-way network latency between the target and source must not
exceed 100 ms. The cumulative network delay is measured by adding the
individual one-way delays between pairs of NTP client-server nodes in the
hierarchy starting with the target and ending at the source. For more information,
please review the high accuracy time sync document.

Target accuracy: 50 milliseconds

All requirements outlined in the section Target accuracy: 1 second apply, except where
stricter controls are outlined in this section.

The other requirements to achieve 50-ms accuracy for a specific target system are:
 The target computer must have better than 5 ms of network latency between its
time source.

The target system must be no further than stratum 5 from a highly accurate time
source.

７ Note

Run w32tm /query /status from the command line to see the stratum.

The target system must be within 6 or less network hops from the highly accurate
time source.

The one-day average CPU utilization on all stratums must not exceed 90%.

For virtualized systems, the one-day average CPU utilization of the host must not
exceed 90%.

Target accuracy: 1 millisecond

All requirements outlined in the sections Target accuracy: 1 second and Target accuracy:
50 milliseconds apply, except where stricter controls are outlined in this section.

The other requirements to achieve 1-ms accuracy for a specific target system are:

The target computer must have better than 0.1 ms of network latency between its
time source

The target system must be no further than stratum 5 from a highly accurate time
source

７ Note

Run w32tm /query /status from the command line to see the stratum.

The target system must be within 4 or less network hops from the highly accurate
time source.

The one-day average CPU utilization across each stratum must not exceed 80%.

For virtualized systems, the one-day average CPU utilization of the host must not
exceed 80%.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Support for the leap second
Article • 02/19/2024

This article provides information about Microsoft support for the leap second.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows Server 2008 R2 Service Pack 1, Windows 10, version 2004, Windows 10, version
1909, Windows 10, version 1803, Windows 10, version 1709, Windows 7 Service Pack 1
Original KB number: 2722715

Summary
This article contains information about Microsoft support for the leap second. The leap
second is a one-second adjustment, which is occasionally applied to Coordinated
Universal Time (UTC) in order to keep its time of day close to the mean solar time, or
UT1.

７ Note

Windows Server 2019 and Windows 10 October 2018 Update do support leap
seconds in the platform. However, this article does not apply strictly to these or
later operating systems. For more information, see:

Leap Second Announcement

Leap Second Validation for IT Pros
Leap Second Validation for Developers

More information

(1) Windows
About the OS
Leap second processing is not handled separately by the Windows operating system
(OS). For example, year, month, date, and time information in the following format is not
supported by the Windows OS:

yyyy/mm/dd 08:59:60
Therefore, 2012/7/1 08:59:60 is processed as 2012/7/1 09:00:00, per the ISO 8601
format.

About the Time Synchronization Service (Windows Time Service)

Windows Time Service does not implement a leap second even though it passes
through the Leap Indicator (LI) flag from the NTP server to the server that hosts the
Windows Time Service and the down-level clients that synchronize from it. The Windows
Time Synchronization Service (W32Time) does not insert a leap second, and instead
proceeds with the usual time synchronization process.

During the brief period that follows the introduction of a leap second on an upstream
NTP server (including W32time Server), a time difference of about one second occurs
between that upstream NTP server and the W32time clients that synchronize from it.
The W32time clients correct their local clocks when they subsequently synchronize time
from their upstream server.

For more information, see the following Microsoft Knowledge Base (KB) article:

909614 How the Windows Time Service treats a leap second

Additionally, in the Windows Time Service, it's not always possible to prevent the
occurrence of marginal time differences, such as one second. The operating system is
designed to handle time variations. Leap second variations are handled cleanly, allowing
for uninterrupted execution. For more information, see the following KB article:

939322 Support boundary to configure the Windows Time service for high-accuracy
environments

About the cluster service As for the cluster configuration, it's same as with the OS: leap
second processing is not performed.

(2) SQL Server 2000, 2005, 2008, 2008 R2, 2012, and 2014
SQL Server does not use time data for managing internal operations such as
transactions. Therefore, even if a one-second deviation occurs in the system time
because of the leap second, it does not affect SQL Server operations. As with the
Windows OS, SQL Server does not independently recognize the leap second.

Be aware the date data type (for example, datetime) does not support the format in
which the seconds value reaches 60 such as 2012/7/1 08:59:60. Therefore, if a
connection is established to SQL Server from an application that's running on an OS that
supports the leap second, and the OS tries to set a leap second (data in which the
second's value is 60) in the column and variable of the date data type, an error is
returned. For more information, see the following "Reference information" section.

Reference information

[Example] When the leap second is handled as the date data type in the SQL Server

SQL

create table leap_second(

a int,
b datetime,
)
go
insert into [leap_second] values (1,convert(datetime,'2012/07/01 08:59:60'))
go
select convert(datetime,'2012/07/01 08:59:60')
go
select datediff(day,convert(datetime,'2012/07/01 08:59:60'),getdate())
go
declare @b datetime
set @b='2012/07/01 08:59:60'
go
declare @c time
set @c='08:59:60'
go
declare @d datetime2
set @d='2012/07/01 08:59:60'
go
declare @e datetimeoffset
set @e='2012/07/01 08:59:60'
go

Result
Message 242, Level 16, Status 3, Row 1
As a result of conversion from the varchar data type to the datetime data type, the value
is set outside the range.
The statement has ended.

Message 242, Level 16, Status 3, Row 1

As a result of conversion from the varchar data type to the datetime data type, the value
is set outside the range.

Message 242, Level 16, Status 3, Row 1

As a result of conversion from the varchar data type to the datetime data type, the value
is set outside the range.
Message 242, Level 16, Status 3, Row 3
As a result of conversion from the varchar data type to the datetime data type, the value
is set outside the range.

Message 241, Level 16, Status 1, Row 2

The conversion process failed during conversion from the character string to the date
and time, or to either of the two.

Message 241, Level 16, Status 1, Row 2

The conversion process failed during conversion from the character string to the date
and time, or to either of the two.

Message 241, Level 16, Status 1, Row 2

The conversion process failed during conversion from the character string to the date
and time, or to either of the two.

(3) Exchange Server 2003, 2007, 2010, and 2013

The time that's used in Exchange Server includes the time that's measured by the system
clock and the time that's calculated as the elapsed period since the start of the service.
In the processing that uses the system clock, the Exchange server operates without
recognizing the leap second. On the other hand (where the elapsed time period is
concerned), although a difference of one second occurs with the insertion of the leap
second, this deviation can occur even under normal circumstances. As with the Windows
OS, Exchange Server is designed to handle minor time variations. Therefore, Exchange
Server operations are not affected.

In addition to the internal operation, a schedule in the iCalendar format represents a

case in which it's possible to receive (from the outside) a time value to which a leap
second has been added. However, when Exchange Server receives schedules in the
iCalendar format, the program supports only those formats in which the time notation is
defined in compliance with RFC 5545 . With regard to the leap second, the seconds
notation is supported in the 060 range. If a number that's greater than 60 is specified as
the seconds value, it is processed as an invalid format and is not recognized as the
correct iCalendar format.

In Outlook, 60 seconds is considered 0. Therefore, 2012/07/01 08:59:60 becomes

2012/07/01 08:59:00. It means that there is a possibility of a one-minute deviation at
most. In such a case, the order of reception of emails may appear to have deviated, but
otherwise there is no effect on operations.

For more information, see the following:

2.2.36 [RFC5545] Section 3.3.12 Time

(4) Internet Information Services (IIS)

The leap second has no effect in IIS.

(5) Others

Applications that are running in Windows typically use the system clock. Therefore, they
can be used without consideration for the leap second.

However, if a Microsoft product is accessed from an application that manages the time
on its own and that supports the leap second, or from an application that's running on
an OS that supports the leap second, problems are likely to occur. This is because
Microsoft products do not recognize the leap second.

Additionally, applications should not rely on the system time to increase monotonically.
Instead, they should use the GetTickCount64() function to read the current tick count,
which is the time since startup in milliseconds.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

When SpecialPollInterval is used as a
polling interval, the Windows Time
service does not correct the time if the
service gets into Spike state
Article • 02/19/2024

This article provides a resolution for the issue that Windows Time service does not
correct the time if the service gets into Spike state.

Applies to: Windows 10, version 1511, Windows 10 Pro released in July 2015, Windows
Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008
R2, Windows 7, Windows Server 2008, Windows Vista
Original KB number: 2638243

Symptoms
An NTP client computer that is running Windows Server editions or Windows Client
editions may not correct the time if the following conditions are true:

The NTP client syncs its time with the manually specified NTP server.
The NTP client uses SpecialPollInterval as a polling interval.
The time offset between the NTP client and the NTP server is greater than the
LargePhaseOffset as configured in the NTP client.

In this situation, the NTP client cannot correct its time even after waiting for
SpikeWatchPeriod to pass.

Cause
This problem occurs because the NTP client gets into SPIKE state every time the client
polls the time sample to the NTP server. The Time service manages its internal status,
and if the client gets into SPIKE state, the client does not sync its time.

Resolution
To work around this issue so that the NTP client is enabled to sync with the NTP server
after a SPIKE state, configure Windows Time to use the MinPollInterval/MaxPollInterval
as the polling interval.

To configure Windows Time to use the MinPollInterval/MaxPollInterval as the polling

interval, follow these steps:

1. Click Start, click Run, type cmd, and then press ENTER.

７ Note

In Windows 8 or Windows Server 2012, press the Windows logo Key+R to

open the Run box, type cmd in the Run box, and then press ENTER.

2. At the command prompt, type the following command. After you type the
command, press ENTER.

Console

w32tm /config /update /manualpeerlist:NTP_server_IP_Address,0x8

/syncfromflags:MANUAL

７ Note

When you use the 0x1 flag with the /manualpeerlist switch, you specify use
of SpecialPollInterval . To work around this problem, do not use the 0x1 flag.

Workaround
If you want to use "SpecialPollinterval", you should change the following registry:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Value: MinPollInterval
Type: DWORD

To avoid this issue, the registry key should apply conditional expression as follows:
Conditional expression:
SpecialPollInterval<(2^MinPollInterval)*(HoldPeriod+1)
Domain member computer has default values:

MinPollInterval=10
HoldPeriod=5

７ Note
 If you set Windows Time Service's settings by Group Policy or Local Group Policy,
this workaround does not work and you have to delete Policy settings.

Status
Microsoft has confirmed that it is a problem in the Microsoft products that are listed in
the "Applies to" section.

More information
The polling interval that Windows Time uses is set by the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

If the value of the NtpServer entry in this subkey contains 0x1, Windows Time uses
SpecialPollInterval as the polling interval. Otherwise, Windows Time uses
MinPollInterval/MaxPollInterval. For additional Information about the Windows Time
Service and registry values, visit the following Microsoft Web site:
https://technet.microsoft.com/library/cc773263(WS.10).aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Time synchronization may not succeed
when you try to synchronize with a non-
Windows NTP server
Article • 02/19/2024

When you try to synchronize a Windows-based computer to a Network Time Protocol

(NTP) server that isn't running Windows, the synchronization may not succeed. This
article provides a resolution to this issue.

Applies to: Support versions of Windows Server

Original KB number: 875424

Cause
This problem may occur when your computer sends synchronization requests by using
symmetric active mode. By default, Windows Server 2003 domain controllers are
configured as time servers and use symmetric active mode to send synchronization
requests. Some NTP servers that don't run Windows respond only to requests that use
client mode.

Resolution
To resolve this problem, configure Windows Time to use client mode when it
synchronizes with the time server. Follow these steps:

1. Select Start, search for cmd, right-click Command Prompt, and then select Run as
administrator.

2. In the Command Prompt window, run the following commands:

Console

w32tm /config /manualpeerlist:<NTP_server_IP_Address>,0x8

/syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync

More information
The mode that Windows Time uses to send requests is set by the following registry
subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServe
r

If the value of the Enabled entry in this subkey is 1, Windows Time uses symmetric
active mode. Otherwise, Windows Time uses client mode.

The 0x8 setting that is referenced in the command in the "Resolution" section sets
Windows Time to use client mode.

The valid settings for the mode used with the /manualpeerlist switch include:

0x01 - use special poll interval SpecialInterval

0x02 - UseAsFallbackOnly
0x04 - send request as SymmetricActive mode
0x08 - send request as Client mode

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Turn on debug logging in the Windows
Time Service
Article • 02/19/2024

This article describes how to turn on debug logging for the Windows Time service (also
known as W32time). If you are an administrator, you can use the debug logging feature
of the Windows Time service to help troubleshoot issues.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Window 10 – all editions, Windows 7 Service Pack 1
Original KB number: 816043

７ Note

Microsoft recommends that you use debug logging after you have performed all
other troubleshooting steps. Because of the nature of the detailed information in
the debug log, you may have to contact a Microsoft Support Professional.

Turn on debug logging for Windows Time

Service

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To turn on debug logging in the Windows Time service:

1. Start Registry Editor.

2. Locate and then click the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config .

3. On the Edit menu, click New Value, and then add the following registry values:
 Value Name: FileLogSize
Data Type: DWORD
Value data: 10000000

This registry value specifies the size of the log file in bytes. A value of 10000000
bytes will limit the log file to approximately 10 MB.

Value name: FileLogName

Data Type: String
Value data: C:\Windows\Temp\w32time.log

This registry value specifies the location of the log file. The path is not fixed. You
can use a different path.

Value name: FileLogEntries

Data Type: String
Value: 0-116

This registry value specifies the level of detail of the information in the debug log.
If you must have more detailed logging information, contact a Microsoft Support
Professional.

７ Note

The Data Type value must be of type REG_SZ (String). You must type the value
exactly as shown (that is, type 0-116 ). The highest possible value is 0-300 for
most detailed logging. The meaning of this value is: Log all entries within the
range of 0 and 116.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Time Service settings aren't
preserved during an in-place upgrade to
Windows Server 2016 or Windows 10
Version 1607
Article • 02/19/2024

This article describes an issue in which Windows Time service settings are disabled in the
registry after you upgrade to Windows Server 2016 or Windows 10 Version 1607.

Applies to: Windows Server 2016, Windows Server 2012 R2, Windows 10 - all editions
Original KB number: 3201265

Symptoms
When you do an in-place upgrade on the following operating systems upgrade paths,
the Windows Time service doesn't preserve its configuration. Instead, it shows the
default values for a workgroup server or workstation.

ﾉ Expand table

Upgrade from Upgrade to

Windows Server 2012 or Windows Server 2012 R2 Windows Server 2016

Windows 7, Windows 8, or Windows 8.1 Windows 10 Version 1607

Affected roles
After the in-place upgrade is completed, the following roles may be affected.

Domain controllers
The domain controllers (DC) that hosts the PDC emulator role is the default authoritative
time server for the domain. Typically, it's configured to sync with a highly accurate time
source. All other DCs in the domain sync their time with the PDC.

After you do an in-place upgrade, the PDC loses its connection to the external time
server that it's configured to sync with. It also no longer announces that it's a time
server.
All other DCs in the domain no longer announce that they're time servers, and they no
longer use the domain hierarchy to sync their time. Therefore, their time setting may no
longer be in sync with the setting for their peers, and domain members can no longer
sync their time.

You may notice the following warning in the DCDIAG output:

Warning: <DCNAME> is not advertising as a time server

You may also notice that the DC doesn't respond to NTP client requests. It includes
failures that occur when you test the NTP server availability by using the w32tm.exe
/stripchart tool. For example, the text output may resemble the following output:

c:>w32tm /stripchart /computer: <DCName> Tracking <DCName> [10.1.1.100:123].

The current time is 10/28/2016 9:00:00 AM. 09:00:00 error: 0x800705B4:

Domain Members
Domain member servers and computers that are upgraded are no longer configured to
use the domain hierarchy to synchronize their time. Instead, they'll sync their time with
the time.windows.com website.

Authoritative Time Server

Windows computers that are manually configured as an Authoritative Time Server lose
their configuration. Therefore, devices that are configured to use these computers to
synchronize their time may not sync.

You may also notice that the Authoritative NTP server doesn't respond to NTP client
requests. It includes failures that occur when you test the NTP server availability by using
the w32tm.exe /stripchart tool. For example, the text output may resemble the
following output:

c:>w32tm /stripchart /computer:<myAuthoritativeTimeServer> Tracking

<myAuthoritativeTimeServer> [10.1.1.100:123]. The current time is <DateTime>.
<DateTime> error: 0x800705B4:

７ Note

This issue shouldn't occur when you do an in-place upgrade of the following
operating systems:
 Windows 10 version 1507 through Windows 10 version 1511
Windows 10 version 1511 through Windows 10 version 1607
Windows Server 2016 Technical Preview 5 (TP5) through Windows Server 2016
(RTM)

Cause
It's a known issue in the Windows upgrade paths that are listed in the "Symptoms"
section. This issue occurs because the registry values for the Windows Time service
aren't preserved during an upgrade. Therefore, all Windows Time service values are
reverted to the default state of a Workgroup Member Server or a stand-alone computer.

Workaround

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, go to the following Microsoft Knowledge Base article:
322756 How to back up and restore the registry in Windows

７ Note

On DCs and domain-joined computers, the Netlogon service must be running

before the W32time service can start. After you upgrade the system, make sure that
Netlogon is running before you try any of these workarounds.

To work around this issue, use one of the following methods.

Method 1
Before you upgrade to Windows 10 Version 1607 or Windows Server 2016, manually
back up the contents under the w32time registry key. To do so, follow these steps:

1. Open the Run box by pressing the Windows logo key‌+R.

 2. Type regedit, and then press Enter.

3. Locate and then select the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\

4. Select File > Export.

5. In the Export Registry File dialog box, select the location where you want to save
the backup copy, and then type a name for the backup file in the File name field.

6. Select Save.

7. Save the W32time configuration for validation by running the following commands
at an elevated command prompt:

Console

Net start w32time w32tm /query /configuration /verbose >

PreUpgradeW32timeConfiguration.txt

You can now upgrade the computer to Windows Server 2016 or Windows 10 Version
1607. After the upgrade is completed, follow these steps to restore the contents under
the w32time registry key:

1. Open the Run box by pressing the Windows logo key‌+R.

2. Type regedit, and then press Enter.

3. Open the Run box by pressing the Windows logo key‌+R.

4. Type regedit, and then press Enter.

5. In Registry Editor, select File > Import.

6. In the Import Registry File dialog box, select the location where you saved the
backup copy, select the backup file, and then select Open.

7. Exit Registry Editor.

8. Run the following command to remove a deprecated service trigger:

Console

reg delete
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TriggerInf
o\1 /f
 9. Restart W32time service to enable it to use the new configuration. To do so, run
the following commands at an elevated command prompt:

Console

net stop w32time

net start w32time

Method 2
If you're experiencing issues that affect the Windows Time Service after you upgrade to
Windows Server 2016 or Windows 10 Version 1607, follow these steps to reregister
w32tm.exe .

７ Note

This procedure restores the default settings that are appropriate for the computer
role. It does not restore any customizations that were made by the administrator.

At an elevated command prompt, run the following sequence of commands:

Console

net stop w32time

w32tm.exe /unregister

w32tm.exe /register

net start w32time

Method 3
If you're experiencing issues that affect the Windows Time Service after you upgrade to
Windows Server 2016 or Windows 10 Version 1607, follow these steps to restore your
settings from the Windows.old folder.

） Important

The following steps should be done only by advanced users.

1. Export the registry key from Windows.old folder.

a. Open the Windows Run box by pressing the Windows logo key+R.

b. Type regedit and then press Enter.

c. Locate and then click HKEY_LOCAL_MACHINE .

d. On the File menu, click Load Hive.

e. Locate and then click the C:\Windows.old\Windows\System32\Config\System file,

and then click Open.

f. In the Load Hive dialog box, type Offline, and then click OK.

g. Expand Offline.

h. Locate and then click the following registry subkey:

ControlSet001\Services\W32Time\

i. Click File > Export.

j. In the Export Registry File dialog box, select the location on a local hard disk
where you want to save the registry, and then type a name for the backup file in
the File name field.

k. Click Save.

l. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\Offline

m. On the File menu, click Unload Hive, and then click Yes in the Confirm Unload
Hive dialog box.

n. Exit Registry editor.

2. Restart the computer in Recovery mode.

a. Select Start > Settings > Update & Security > Recovery
b. From the right-side pane, click Restart now under Advanced startup.
c. After the computer restarts, select Troubleshoot, and then select Command
Prompt.
d. Select a local admin user, and then insert the password.

７ Note
 This restarts the computer in Recovery mode and provides a Command
Prompt window.

3. Import the saved registry key from step 1.

a. At the command prompt, type regedit and then press Enter

b. Locate and then select HKEY_LOCAL_MACHINE

c. On on the File menu, click Load Hive.

d. Locate and then select the C:\Windows\System32\Config\System file, and then

click Open.

e. In the Load Hive dialog box, type Offline, and then click OK

f. Expand Offline.

g. Locate and then click the following registry subkey:

ControlSet001\Services\W32Time\

h. Click File > Import.

i. In the Import Registry File dialog box, select the location where you saved the
backup copy, select the backup file, and then click Open.

j. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\Offline

k. On the File menu, click Unload Hive, and then click Yes in the Confirm Unload
Hive dialog box.

l. Exit Registry Editor, and then restart the computer in Normal mode.

Verify the workaround results

To verify that the Windows Time service can now preserve its configuration, follow these
steps:

1. Run DCDiag.exe on DCs to make sure that they're advertising as a time server.

2. Make sure that DCs or Authoritative NTP Servers respond to NTP client requests
without errors. For example, the command output resembles the following one:

c:<w32tm /stripchart /computer:<myTimeServer>

Tracking <myTimeServer> [10.1.1.100:123].
 The current time is <DateTime>.
<DateTime> d:+00.0013494s o:-00.0891868s [ * ]

3. For advanced users, query the W32time configuration, and make sure that the time
providers are configured as expected. If you used Method 1 as the workaround,
you can compare the post-upgrade configuration to the saved pre-configuration
data. For example, the command output resembles the following one:

c:\ >w32tm /query /configuration /verbose >

PostUpgradeW32timeConfiguration.txt

References
For more information about related Netlogon issues, click the following article number
to view the article in the Microsoft Knowledge Base:
3201247 Netlogon service doesn't retain settings after upgrade to Windows Server
2016

Feedback
Was this page helpful?  Yes  No

Provide product feedback

W32Time: Sync: SpecialPollInterval may
be ignored on workgroup computers
Article • 02/19/2024

This article helps fix an issue where the NTP client doesn't synchronize time at the
SpecialPollInterval period as expected.

Original KB number: 3205089

Symptoms
Assume that you modify W32time settings to always run and that one of the following
conditions is true:

You use the default workstation settings.

You use custom NTP synchronization settings with a large SpecialPollInterval
setting value.

In this scenario, the NTP client doesn't synchronize time at the SpecialPollInterval period
as expected.

Cause
Because of the way that the Windows Time Service handles large SpecialPollInterval
values, time may be synchronized from the NTP server at longer intervals than expected.

Resolution

Workaround 1
Specify a smaller SpecialPollInterval value than the default value. The default values are
as follows:

MinPollInterval = 0xA (== 2^10 seconds == 1024 seconds)

MaxPollInterval = 0xF (== 2^15 seconds == 32768 seconds)
SpecialPollInterval = 604800 seconds

Specify a SpecialPollInterval value that falls between the MinPollInterval and

MaxPollInterval. An example value is 3600 seconds (== 1 hour).
To configure W32time with the new setting, follow these steps:

1. Start Registry Editor.

2. Change the value of the following registry key:

HKEY_LOCAL_MACHINE

\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Value name: SpecialPollInterval

Default: 604800
Modified value: 3600

3. Restart the Windows Time Service, or run the following command to signal
W32time about the modified configuration:

Console

w32tm /config /update

Workaround 2
Use the built-in poll interval adjustments based on MinPollInterval, MaxPollInterval
instead of using SpecialPollInterval. This built-in tool automatically adjusts the polling
interval from MinPollInterval all the way up to MaxPollInterval if the client machine
keeps fairly accurate time. You need only modify a flag in the NtpServer configuration in
order to switch from SpecialPollInterval to the automatic poll interval, as follows:

1. Start Registry Editor.

2. Change the value of the following registry key:

HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Value name: NtpServer

Default value: time.windows.com , 0x9
Modified value: time.windows.com , 0x8

3. Restart the Windows Time service, or run the following command:

Console

w32tm /config /update

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Admin Development troubleshooting
documentation for Windows Server
Article • 03/18/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Admin Development-related issues. The topics are divided
into subcategories. Browse the content or use the search feature to find relevant
content.

Admin Development sub categories

Active Directory Services Interface (ADSI)
Windows Management Instrumentation (WMI)
Windows Remote Management (WinRM)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Convert a String Formatted GUID to a
Hexadecimal String Form For Use When
Querying the Active Directory
Article • 12/26/2023

This article describes how to convert a string formatted GUID (for example, {XXXXXXXX-
XXXX-XXXX-XXXX-XXXXXXXXXXXX}) to its hexdecimal string form for use in a GUID bind
string in the Active Directory.

Applies to: Windows Server 2012 R2

Original KB number: 325648

To convert a string formatted GUID to its hexadecimal string form, follow these steps:

1. Paste the following code into a .vbs file.

Visual Basic Script

'================================================================
' Replace the value of strGUID with an actual GUID
'================================================================
strGUID = "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
Set obj = GetObject("LDAP://<GUID=" &
ConvertStringGUIDToHexStringGUID(strGUID) & ">")
MsgBox "The octet guid for " & obj.Get("displayname") & " is " &
obj.GUID

'================================================================
' ConvertGUIDtoOCTET function
'================================================================
Function ConvertStringGUIDToHexStringGUID(strGUID)
Dim octetStr, tmpGUID

For i = 0 To Len(strGUID)
t = Mid(strGUID, i + 1, 1)
Select Case t
Case "{"
Case "}"
Case "-"
Case Else
tmpGUID = tmpGUID + t
End Select
Next

octetStr = Mid(tmpGUID, 7, 2)' 0

octetStr = octetStr + Mid(tmpGUID, 5, 2)' 1
octetStr = octetStr + Mid(tmpGUID, 3, 2)' 2
 octetStr = octetStr + Mid(tmpGUID, 1, 2)' 3
octetStr = octetStr + Mid(tmpGUID, 11, 2)' 4
octetStr = octetStr + Mid(tmpGUID, 9, 2)' 5
octetStr = octetStr + Mid(tmpGUID, 15, 2)' 6
octetStr = octetStr + Mid(tmpGUID, 13, 2)' 7
octetStr = octetStr + Mid(tmpGUID, 17, Len(tmpGUID))

ConvertGUIDtoOCTET = octetStr
End Function

2. Run the script.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Best practice for configuring EventLog
forwarding in Windows Server 2012 R2
Article • 12/26/2023

This article introduces the best practice for configuring EventLog forwarding in a large
environment in Windows Server 2012 R2.

Applies to: Windows Server 2012 R2

Original KB number: 4494356

Summary
There are important scalability fixes that have been rolled out to Windows Server 2016,
Windows Server 2019 in the February 25, 2020 cumulative updates.

See "Improves Event Forwarding scalability to ensure thread safety and increase
resources." bullet in the following two articles:

February 25, 2020-KB4537806 (OS Build 14393.3542)

February 25, 2020-KB4537818 (OS Build 17763.1075)

Events latency
As soon as events are generated on the client, the Event Forwarding mechanism takes
some time to forward them to the collector.

This delay may be caused by the subscription configuration, such as the

DeliveryMaxLatency parameter, the performance of the collector, the forwarder, or the
network.

７ Note

Make sure that the events are not overwritten on the client before they are
forwarded. We usually have to manage this issue only when the clients generate a
large amount of events, such as a busy server or the DC forwarding the Security
log.

Limitation and system requirement

You deploy EventLog Forwarding in a large environment. For example, you deploy
40,000 to 100,000 source computers. In this situation, we recommend that you deploy
more than one collector that has 2,000 to not more than 4,000 clients per collector.

Additionally, we recommend that you install at least 16 GB of RAM and four (4)
processors on the collector to support an average load of 2,000 to 4,000 clients that
have one or two subscriptions configured.

Fast disks are recommended, and the ForwardedEvents log can be put onto another disk
for better performance.

The memory usage of the Windows Event Collector service depends on the number of
connections that are received by the client. The number of connections depends on the
following factors:

The frequency of the connections

The number of subscriptions
The number of clients
The operating system of the clients

For example, for the default values of 4,000 clients and five to seven subscriptions, the
memory that is used by the Windows Event Collector service may quickly exceed 4 GB
and continue to grow. This can make the computer unresponsive.

Frequency of the client connections

Three parameters control the frequency of the client connections:

Refresh= (specified in the configuration URL of the GPO)

DeliveryMaxLatency (specified in the subscription)
HeartbeatInterval (specified in the subscription)

The Refresh= parameter in the GPO

This parameter is measured in seconds. It controls how frequently the client connects to
the /WEC URL to enumerate the available subscriptions.

The collector responds by providing a list of the subscriptions that are enabled for the
client. The response includes the bookmarks for each channel and the Xpath query. As
soon as the client receives the information, it starts to send the events or the heartbeat
packets to the /Subscriptions URL. If the subscriptions don't change frequently, this
parameter can be configured to check every few hours or even less often.
DeliveryMaxLatency
Controls the frequency of the client connections. For a large deployment, you can create
a subscription for urgent events set to a 5-minute frequency, and another for less urgent
events set to a 2-hour frequency.

HeartbeatInterval
Controls the Inactive status in the Runtime status window of the console. Can be set to
the same value as DeliveryMaxLatency or a larger value to give clients additional time
before they are marked as Inactive.

Custom parameters
To configure custom parameters, you must use the command line to run Wecutil. For
more information, see Wecutil.exe.

You can list the configured subscription as wecutil es .

You must first switch the subscription to "Custom":

Console

wecutil ss <SubscriptionName> /cm:"Custom"

Then, set the DeliveryMaxLatency parameter:

Console

wecutil ss <SubscriptionName> /dmlt:7200000

(Value is in milliseconds: 7200000 = 2 hours)

Adjust HeartbeatInterval to the same value. This setting affects the "Inactive"
status for each client in the console:

Console

wecutil ss <SubscriptionName> /hi:7200000

Subscription delivery optimization

The clients are sending the events to the /subscriptions URL. These connections are very
important for collectors memory usage.

The following preconfigured modes are available.

Normal
Provides reliable delivery of events, and does not try to conserve bandwidth.
The appropriate choice unless you require tighter control over bandwidth usage
or you require that forwarded events be delivered as quickly as possible.
Uses pull delivery mode, batches five items at a time, and sets a batch time-out
of 15 minutes.

Minimize Bandwidth
Makes sure that the use of network bandwidth for event delivery is strictly
controlled.
The appropriate choice if you want to limit the frequency of network
connections to deliver events.
Uses push delivery mode, and sets a batch time-out of 6 hours and a heartbeat
interval of 6 hours.

Minimize Latency
Makes sure that events are delivered by having minimal delay.
The appropriate choice if you collect alerts or critical events.
Uses push delivery mode, and sets a batch time-out of 30 seconds.

The client connects to the collector at the specified frequency to either send the events
or send a heartbeat. The default "Normal" settings can cause high memory usage by
having 2,000 to 4,000 clients per collector.

Configure the collector name

You can configure the collector name on the client by configuring the following Group
Policy Object (GPO):
Computer Configuration/Administative Templates/Windows Components/ Event
Forwarding/ Configure Target Subscription Manager

Alternatively, you can make registry settings in the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\Sub
scriptionManager

The GPOs that assign the collector to each client can be filtered by using either the
security setting on the GPO itself or a WMI filter. For example, if the computer name
always ends in a numeral (such as computer1, computer2, and so on), we can create
GPOs to point the clients to 10 different collectors.

Consolidation of the subscriptions

Configuring multiple subscriptions increases the number of connections. The
considerations that are discussed earlier in this article apply to each subscription.

We recommend that you configure the subscription by editing the Xpath query and
putting multiple queries into the same subscription.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Suggested hotfixes for WMI related
issue on Windows platforms
Article • 12/26/2023

This article provides suggested hotfixes for Windows Management Instrumentation

(WMI) related issue on Windows platforms.

Applies to: Windows 10 - all editions, Windows 7 Service Pack 1, Windows Server 2012
R2
Original KB number: 2591403

Symptoms
Due to the volume of support incidents handled by Microsoft Support Services for
issues related to the following hotfixes, these are recommended for installation for the
platforms indicated below. These hotfixes are associated with the operation and
functionality of the WMI service and its related components. When experiencing issues
related to WMI on a system the symptoms can vary widely depending upon the root
cause. The following are a few examples of high-level symptoms noted in support
incidents that may be resolved with the application of the indicated hotfixes:

Loss of functionality with enterprise management/monitoring software for various

machines. Software examples: Microsoft SCOM/SMS, IBM Tivoli, LANDesk
Management, HP OpenView, BMC Patrol, etc.
Loss of functionality related to Citrix terminal services load-balancing.
Loss of functionality for WMI-based scripts.
Slow user logon times on Citrix terminal servers.
Slow user logon times on Windows clients where WMI-based group policy filters
are in-place.

More granular symptoms

Unable to connect to root\default, root\cimv2 and/or root\citrix namespaces via
WBEMTEST.
Repository growing large related to OBJECTS.DATA file.
Note repeating-nested CITRIX namespace entries in WMIMGMT.MSC. WMI
CONTROL > PROPERTIES > SECURITY > expand ROOT structure to note
missing/repeating namespaces.
Resolution
Hotfix for Windows Vista and Windows Server 2008

2464876 The WMI repository is corrupted on a computer that is running

Windows Server 2008 or Windows Vista

Hotfix list for Windows 7 and Windows Server 2008 R2

2692929 0x80041001 error when the Win32_Environment WMI class is

queried by multiple requestors in Windows 7 or in Windows Server 2008 R2

2617858 Unexpectedly slow startup or logon process in Windows Server 2008

R2 or in Windows 7

７ Note

MSKB 2617858 includes the a resolution for the high CPU fix in MSKB
2505348 AND a fix for WMI repositories being improperly marked drity
after graceful shutdowns, triggering full verification on the following OS
startup. MSKB 2505348 is there fore superceded by MKSB 2617858 .

2492536 Msinfo32.exe takes a long time to display or export system

information on a computer that has many MSI-X-supported devices and that is
running Windows 7 or Windows Server 2008 R2

７ Note

MSKB 2492536 updates Cimwin32.dll on the computers running Windows

7 and Windows Server 2008 R2 RTM or with Service Pack 1 (SP1) installed.
While as MSKB 2692929 updates Cimwin32.dll to a latest version and is
applicable to the computer that have SP1 installed.

982293 The Svchost.exe process that has the WMI service crashes in Windows
Server 2008 R2 or in Windows 7 Note: MSKB 982293 is applicable to the
computers running Windows 7 or Windows Server 2008 R2 without Service Pack
1 (SP1)

974930 An application or service that queries information about a failover

cluster by using the WMI provider may experience low performance or a time-
out exception
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
User Experience issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event log message indicates that the
Windows Installer reconfigured all
installed applications
Article • 12/26/2023

This article helps fix slow system startup or slow login issues that occur when a group
policy with a WMIFilter or installed application queries the Win32_Product class.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 974524

Symptom
You may experience slow system startup or slow login issues. Additionally, you may see
the following event in the Application Event log:

Log Name: Application

Source: MsiInstaller
Date: mmddyyy hh:mm:ss
Event ID: 1035
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer:
Description:
Windows Installer reconfigured the product. Product Name: <ProductName>.
Product Version: <VersionNumber>. Product Language: <languageID>.
Reconfiguration success or error status: 0.

You'll see this event for each of the installed application on the computer.

The system Event log will show that the Windows Installer Service is starting and
stopping automatically.

Event Type: Information

Event Source: Service Control Manager
Event Category: None
Event ID: 7035
 Date: mmddyyyy
Time: hh:mm:ss
User: NT AUTHORITY\SYSTEM
Computer: <ComputerName>
Description:
The Windows Installer service was successfully sent a start control. For more
information, see Help and Support Center at
< http://go.microsoft.com/fwlink/events.asp >.

Event Type: Information

Event Source: Service Control Manager
Event Category: None
Event ID: 7036
Date: mmddyyyy
Time: hh:mm:ss
User: N/A
Computer: <ComputerName>
Description:
The Windows Installer service entered the stopped state.
For more information, see Help and Support Center at
< http://go.microsoft.com/fwlink/events.asp >.

Cause
This problem can happen if one of the following conditions is true:

You have a group policy with a WMIFilter that queries Win32_Product class.
You have an application installed on the machine that queries Win32_Product class.

Resolution
If you're using a group policy with the WMIFilter that queries Win32_Product , modify the
filter to use Win32reg_AddRemovePrograms .

If you have an application that uses the previous class, contact the vendor to get an
updated version that doesn't use this class.

To narrow down the application that causes the problem, you can follow the Clean boot
troubleshooting method.
 ７ Note

Using Win32Reg_AddRemovePrograms requires System Center Configuration Manager

(SCCM) client to be installed. If SCCM is not installed, use the StdRegProv class
instead.

More information
Win32_product class isn't query optimized. Queries such as select * from Win32_Product
where (name like 'Sniffer%') require WMI to use the MSI provider to enumerate all of

the installed products and then parse the full list sequentially to handle the where
clause. This process also starts a consistency check of packages installed, verifying, and
repairing the install. An account with only user privileges may cause delay in application
launch and an event 11708 stating an installation failure, as the user account may not
have access to quite a few locations.

Win32reg_AddRemovePrograms is a much lighter and effective way to do so, which avoids

the calls to do a resiliency check, especially in a locked down environment. So when

using Win32reg_AddRemovePrograms , we won't be calling on msiprov.dll and won't be
initiating a resiliency check.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Events are not forwarded if the collector
is running Windows Server
Article • 12/26/2023

This article helps fix an issue that occurs when you use source-initiated event forwarding
to send events to a Microsoft Windows Server event collector.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4494462

Symptoms
You configure a Windows Server 2019 or Windows Server 2016 computer as an event
collector. You also configure a source-initiated subscription (and related Group Policy
Objects) for event forwarding. However, the events are not forwarded and the event
source computers log event messages that resemble the following:

Output

Log Name: Microsoft-Windows-Forwarding/Operational

Event ID: 105
Task Category: None
User: NETWORK SERVICE
Description:
The forwarder is having a problem communicating with subscription manager at
address http://W19SRV.contoso.com:5985/wsman/SubscriptionManager/WEC. Error
code is 2150859027 and Error Message is The WinRM client sent a request to
an HTTP server and got a response saying the requested HTTP URL was not
available. This is usually returned by a HTTP server that does not support
the WS-Management protocol. </f:Message></f:WSManFault>.

Cause
This behavior is caused by the permissions that are configured for the following URLs:

http://+:5985/wsman/
http://+:5986/wsman/

On the event collector computer, both the Windows Event Collector service (WecSvc)
and the Windows Remote Management service (WinRM) use these URLs. However, the
default access control lists (ACLs) for these URLs allow access for only the svchost
process that runs WinRM. In the default configuration of Windows Server 2016, a single
svchost process runs both WinRM and WecSvc. Because the process has access, both
services function correctly. However, if you change the configuration so that the services
run on separate host processes, WecSvc no longer has access and event forwarding no
longer functions.

The services function differently in Windows Server 2019. If a Windows Server 2019
computer has more than 3.5 GB of RAM, separate svchost processes run WinRM and
WecSvc. Because of this change, event forwarding may not function correctly in the
default configuration. For more information about the service changes, see Changes to
Service Host grouping in Windows 10.

Resolution
To view the URL permissions, open an elevated Command Prompt window and run the
command netsh http show urlacl .

To fix the URL permissions, use the elevated Command Prompt window and run the
following commands:

Windows Command Prompt

netsh http delete urlacl url=http://+:5985/wsman/

netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-
569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-
4059739203-877974739-1245631912-527174227-2996563517)
netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-
569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-
4059739203-877974739-1245631912-527174227-2996563517)

Default URL permissions used by Windows Server 2019

and Windows Server 2016
Reserved URL: http://+:5985/wsman/
User: NT SERVICE\WinRM
Listen: Yes
‎Delegate: No
SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-
412116970)

Reserved URL: https://+:5986/wsman/

User: NT SERVICE\WinRM
Listen: Yes
 Delegate: No SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-
1301513147-412116970)

Default URL permissions used by Windows Server 2012

R2
Reserved URL: http://+:5985/wsman/
‎User: NT SERVICE\WinRM
‎Listen: Yes
‎Delegate: No
User: NT SERVICE\Wecsvc
‎Listen: Yes
Delegate: No
SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-
412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-
2996563517)

Reserved URL: https://+:5986/wsman/

User: NT SERVICE\WinRM
Listen: Yes
Delegate: No
User: NT SERVICE\Wecsvc
Listen: Yes
Delegate: No
SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-
412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-
2996563517)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Application Management
troubleshooting documentation for
Windows Server
Article • 12/26/2023

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Application Management-related issues. The topics are
divided into subcategories. Browse the content or use the search feature to find relevant
content.

Application Management sub categories

.NET Framework installation
1st Party Applications
Application Compatibility Toolkit (ACT)
COM and COM+ performance and stability
COM and DCOM programming
COM+ administration, configuration, and security
DTC startup, configuration, connectivity, and cluster
Event System
MSI
Multilingual User Interface (MUI) and Input Method Editor (IME)
Windows Script Host (CScript or WScript)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Dial-in tab is not available in the
Active Directory Users and Computers
MMC snap-in after you install Remote
Server Administration Tools for
Windows 7
Article • 12/26/2023

This article provides workarounds for an issue where the Dial-in tab is not available in
the Active Directory Users and Computers MMC snap-in.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 975448

Symptoms
After you install Remote Server Administration Tools for Windows 7 on a computer that
is running Windows 7, the Dial-in tab is missing in the properties of a user account in
the Active Directory Users and Computers Microsoft Management Console (MMC) snap-
in.

Cause
This issue occurs because the RSAT manifest and the installation package do not include
the Rasuser.dll and Rtrfiltr.dll modules that are required to load the Dial-In tab.

Workaround
To work around this issue, use one of the following workarounds, as appropriate.

Workaround 1
On the computer that is running Windows 7, use Remote Desktop Services to connect to
a server that is running Windows Server 2008 R2, Windows Server 2008, or Windows
Server 2003. Then, start the Active Directory Users and Computers MMC snap-in on the
server.
Workaround 2 (Windows Server 2008)
1. On a server that is running Windows Server 2008, install the Terminal Services role,
and then install the Terminal Server role service to enable the use of RemoteApp
Manager.

2. Add Active Directory Users and Computers (DSA.MSC) as a remote application.

3. On the computer that is running Windows 7, access the RemoteApp DSA.MSC.

Workaround 2 (Windows Server 2008 R2)

1. On the server that is running Windows Server 2008 R2, install the Remote Desktop
Services role, and then install the Remote Desktop Session Host role service to
enable use of RemoteApp Manager.

2. Add Active Directory Users and Computers (DSA.MSC) as a remote application.

3. On the computer that is running Windows 7, access the RemoteApp DSA.MSC.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
For more information about Windows Server 2008 Terminal Services, visit the following
Microsoft Web site: https://technet.microsoft.com/library/cc268349.aspx
For more information about Windows Server 2008 R2 Remote Desktop Services, visit the
following Microsoft Web site:
https://technet.microsoft.com/library/dd647502(WS.10).aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Direct-X diagnostics tool may report an
unexpected value for the display
adapters memory
Article • 12/26/2023

This article describes an issue where Direct-X diagnostics tool (DXDIAG) reports an
unexpected value for the display adapters memory.

Applies to: Windows Server 2012 R2

Original KB number: 2026022

Symptoms
You have a system with 1GB or greater of Video memory, and 4GB or greater of system
memory (RAM). You run the Direct-X Diagnostics tool, and it reports that you have an
unexpectedly low amount of Approximate Total Memory on the display tab. You may
also see issues with some games or applications not allowing you to select the highest
detail settings.

Cause
The API that DXDiag uses to approximate the system memory was not designed to
handle systems in this configuration

Resolution
Microsoft is working to resolve this in future releases.

More information
On a system with 1GB of video memory, the following values are returned with the
associated system memory:

ﾉ Expand table

System Memory Reported Approximate Total Memory

4GB 3496MB
 System Memory Reported Approximate Total Memory

6GB 454MB

8GB 1259MB

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error "The Best Practices Analyzer scan
has failed" when running Best Practice
Analyzer
Article • 12/26/2023

This article provides a resolution for the error "The Best Practices Analyzer scan has
failed" when running Best Practice Analyzer.

Applies to: Windows Server 2012 R2

Original KB number: 2028818

Symptoms
When you run a Best Practices Analyzer (BPA) in Windows Server 2008 R2 Server
Manager, it returns the following error:

The Best Practices Analyzer scan has failed.

There has been a Best Practice Analyzer engine error for Model Id:
'Microsoft/Windows/FileServices' during execution of the Model. (Inner Exception:
One or more model documents are invalid: {0}Discovery exception occurred
processing file '{0}'.
Windows PowerShell updated your execution policy successfully, but the setting is
overridden by a policy defined at a more specific scope. Due to the override, your
shell will retain its current effective execution policy of "RemoteSigned". Type "Get-
ExecutionPolicy -List" to view your execution policy settings. For more information,
please see "Get-Help Set-ExecutionPolicy.")

Cause
The BPA error will occur if you enable the Turn on Script Execution policy to control
PowerShell script execution and set it to Allow only signed scripts or Allow local scripts
and remote signed scripts. The error will also occur if the Turn on Script Execution is
set to Disabled.

The error will not occur if the policy is set to Allow all scripts.

Resolution
Remove, disable, or set to "Not Configured" the following Group Policy setting that is
being applied to the server with the BPA error.

Computer Configuration\Administrative Templates\Windows

Components\Windows PowerShell
Turn on Script Execution

The BPA will start working once the policy change applies. No reboot is required for the
change to take effect.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you start many COM+
applications: Error code 80080005 --
server execution failed
Article • 12/26/2023

This article provides a workaround for an issue where you receive error code 80080005
when you start many Microsoft COM+ applications manually from a Component
Services Microsoft Management Console (MMC) snap-in.

Applies to: Windows Server 2012 R2

Original KB number: 870655

Symptoms
When you start many Microsoft COM+ applications manually from the Component
Services Microsoft Management Console (MMC) snap-in where each COM+ application
is running under a different user account, you may receive the following error message:

Catalog Error: An error occurred while processing the last operation. Error code
80080005 -- server execution failed. The event log may contain additional
troubleshooting information.

You will receive an error message that is similar to the following in the application log of
Event Viewer:

Output

Type: Error
Source: DCOM

Category: None
Event ID: 10010

Date: 31/03/2004

Time: 15:13:30

User: NT AUTHORITY\SYSTEM

Computer: MSHSRMSWEBP0007
 Description: The server {F1673109-CF44-468D-9E23-FE4116F84CFA} did not
register with DCOM within the required timeout.

Cause
If many COM+ applications run under different user accounts that are specified in the
This User property, the computer cannot allocate memory to create a new desktop heap
for the new user. Therefore, the process cannot start.

Workaround

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To work around this problem, modify the value of the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session

Manager\SubSystems\Windows

To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. In Registry Editor, locate the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session

Manager\SubSystems

By default, the Windows entry in the subkey has a value that is similar to the
following (all on one line):

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
SharedSection=1024,3072 Windows=On SubSystemType=Windows
ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off
MaxRequestThreads=16

3. Right-click the Windows entry, and then click Modify. The Edit String dialog box
appears.

4. In the Value data box, locate SharedSection, add 512 to SharedSection, and then
click OK.

The newly changed Windows entry reads as follows:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
SharedSection=1024,3072,512 Windows=On SubSystemType=Windows
ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off
MaxRequestThreads=16

Steps to reproduce the behavior

1. Create 100 different local user accounts on your computer.

2. Open the Component Services MMC snap-in. To do this, follow these steps:
a. Click Start, point to Settings, and then click Control Panel.
b. In Control Panel, double-click Administrative Tools, and then double-click
Component Services. The Component Services MMC snap-in appears.
c. In the left pane, expand Component Services, expand Computers, and then
expand My Computer.

3. Create a COM+ application, and then set the application identity of the COM+
application. To do this, follow these steps:
a. Right-click COM+ Applications, point to New, and then click Application. The
Welcome to the COM Application Install Wizard dialog box appears.
b. In the Welcome to the COM Application Install Wizard dialog box, click Next.
The Install or Create a New Application dialog box appears.
c. Click Create an empty application. The Create Empty Application dialog box
appears.
d. In the Enter a name for the new application box, type MyCOM1, and then click
Next. The Set Application Identity dialog box appears.
e. Click This user, and then type a user name that you created in step 1 in the User
box.
f. In the Set Application Identity dialog box, type your password in the Password
box and in the Confirm Password box, and then click Next. The Thank you for
 using the COM Application Install Wizard dialog box appears.
g. Click Finish.

4. Add a component to the COM+ application. To do this, follow these steps:

a. In the left pane of the Component Services MMC snap-in, expand MyCom1.
b. Right-click Components, point to New, and then click Component. The
Welcome to the COM Component Install Wizard dialog box appears.
c. Click Next. The Import or Install a Component dialog box appears.
d. Click Import component(s) that are already registered. The Choose
Components to Import dialog box appears.
e. In the Components on: My Computer list, click a component, and then click
Next. The Thank you for using the COM Application Install Wizard dialog box
appears.
f. Click Finish.

5. Repeat step 3 to create 100 COM+ applications that run under different local user
accounts.

6. Repeat step 4 to add components to the 100 COM+ applications that you created
in step 5.

7. In the left pane of the Component Services MMC snap-in, right-click each COM+
application that you created, and then click Start. After you start some COM+
applications, you receive the error message that is described in the Symptoms
section.

References
Creating a New COM+ Application

Feedback
Was this page helpful?  Yes  No

Provide product feedback

0x80004027 error when you try to
remotely access COM+ object after you
upgrade to Windows Server 2016 or
later versions
Article • 12/26/2023

This article provides a solution to the 0x80004027-CO_E_CLASS_DISABLED error that

occurs when you remotely access COM+ object after you upgrade to Windows Server
2016 or later versions.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019,
Windows Server 2022
Original KB number: 3182294

Symptoms
After you upgrade from an earlier release of Windows Server to Windows Server 2016 or
later versions, applications cannot remotely access a COM+ object, and you receive the
following error message:

0x80004027-CO_E_CLASS_DISABLED

Cause
This problem occurs because support for the Application Server role was removed from
Windows Server 2016 or later versions. This change blocks applications that rely on
COM+ remote access.

Resolution

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.
To resolve this problem and enable COM+ remote access, follow these steps:

1. Enable COM+ Network Access in Windows Firewall. To do this, open Control Panel,
click the Windows Firewall item, and then click Allow an app or feature through
Windows Firewall.

2. In the Allowed apps and features list, select the COM+ Network Access check
box, and then select the appropriate scope that's required for your application. For
enterprises, this is typically Domain. However, your application may require
additional settings, depending on the scenario.

3. Set the registry value that allows COM+ remote access. To do this, follow these
steps:
a. In the Start search box, type regedit, and then click regedit.exe in the results
list.
b. Locate the following subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3

c. Right-click the RemoteAccessEnabled DWORD.

d. In the Value data box, enter 1.
e. Click OK.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A COM+ application may stop working
in Windows when a user logs off
Article • 12/26/2023

This article provides a solution to an issue where a COM+ application stops working in
Windows when a user logs off.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows 10 - all editions, Windows 7 Service Pack 1
Original KB number: 2287297

Symptoms
On a Windows server, you have a COM+ server application in which the identity is
configured to run as a specific user. After working for some time, the application may
stop working and keep failing. You have to restart the COM+ application to resolve the
issue.

You may see an error that resembles the following in the Application log on the CLIENT
machine. If the client executable runs on the same computer as the COM+ server
application, you will see this error on the COM+ server:

Event Type: Error

Event Source: DCOM
Event Category: None
Event ID: 10006
Date: <DateTime>
Time: <DateTime>
User: Domain\user
Computer: *****
Description:
DCOM got error "Unspecified error" from the computer 'servername' when
attempting to activate the server: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

In this case, the event message tells you that the error (E_FAIL or 80004005 or
Unspecified error) is returned from the server. The CLSID of the component will be listed
in the event log entry.

You'll also see events that resemble the following in the Application log of the computer
on which the COM+ application runs:
 Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: <DateTime>
Event ID: 1530
Task Category: None
Level: Warning
Keywords: Classic
User: SYSTEM
Computer: SERVERNAME
Description:
Windows detected your registry file is still in use by other applications or services.
The file will be unloaded now. The applications or services that hold your registry file
may not function properly afterwards.

DETAIL -
1 user registry handles leaked from \Registry\User\S-1-5-21-1049297961-
3057247634-349289542-1004_Classes:
Process 2428 (\Device\HarddiskVolume1\Windows\System32\dllhost.exe) has
opened key \REGISTRY\USER\S-1-5-21-1123456789-3057247634-349289542-
1004_CLASSES

You may see the call to create an instance of the component returns 0x800703fa.

Cause
The user identity that is associated with the COM+ application is logged on when the
COM+ application is first initialized. If this user were to log off of the machine, then the
user's profile would get unloaded and the COM+ application can no longer read registry
keys in the profile of the user identity. Starting with Windows Vista the User Profile
Service will force the unloading of a user profile when that user logs off. This is a
situation where the functionality of forcing the unload of the user profile may break an
application if registry handles are not closed in the process. This new User Profile Service
functionality is the default behavior.

Resolution
As a workaround it may be necessary to modify the default behavior of the User Profile
Service. The policy setting Do not forcefully unload the user registry at user logoff
counters the default behavior of Vista and newer operating systems. When enabled, the
User Profile Service will not forcefully unload the registry, instead it waits until no other
processes are using the user registry before it unloads it. The policy can be found in the
group policy editor (gpedit.msc). The Do not forcefully unload the user registry at user
logoff policy is located under Computer Configuration > Administrative Templates >
System > User Profiles.

Change the setting from Not Configured to Enabled which disables the new User Profile
Service feature. DisableForceUnload is the value added to the registry.

More information
Windows will always unload the users registry, even if there are any open handles to the
per-user registry keys at user logoff. Using this policy setting, an administrator can
negate this behavior, preventing Windows from forcefully unloading the users registry
at user logoff.

７ Note

This policy should only be used for cases where you may be running into
application compatibility issues due to this specific Windows behavior. It is not
recommended to enable this policy by default as it may prevent users from getting
an updated version of their roaming user profile.

If you enable this policy setting, Windows will not forcefully unload the users registry at
logoff, but will unload the registry when all open handles to the per-user registry keys
are closed.

If you disable or do not configure this policy setting, Windows will always unload the
users registry at logoff, even if there are any open handles to the per-user registry keys
at user logoff.

Even if you enabled the Do not forcefully unload the user registry at user logoff policy
setting, the Event ID 1530 warning may be logged. The warning is logged after the first
attempt to unload the registry hive. If this fails, the policy is checked to determine
whether the registry hive should be forced to unload regardless of open registry
handles.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Performance degrades when you access
large files with
FILE_FLAG_RANDOM_ACCESS
Article • 12/26/2023

This article provides a solution to an issue that operating system performance may
degrade when one or more processes access multiple large files using the CreateFile()
API and the FILE_FLAG_RANDOM_ACCESS flag.

Applies to: Windows Server 2012 R2

Original KB number: 2549369

Symptoms
Operating system performance may degrade when one or more processes access
multiple large files using the CreateFile() API and the FILE_FLAG_RANDOM_ACCESS flag.
The performance degradation is because of the system cache consuming available
memory (visible in the performance counter Memory\Cache Bytes).

Cause
The FILE_FLAG_RANDOM_ACCESS flag is a hint to the Cache Manager that the file will be
opened for random I/O. Random I/O means there is no predictable pattern to the I/O
that will take place. This flag disables intelligent read-aheads and prevents automatic
unmapping of views after pages are read to minimize mapping/unmapping when the
process revisits that part of the file. This keeps previously read views in the Cache
Manager working set. However, if the cumulative size of the accessed files exceeds
physical memory, keeping so many views in the Cache Manager working set may be
detrimental to overall operating system performance because it can consume a large
amount of physical RAM.

Resolution
Remove the FILE_FLAG_RANDOM_ACCESS flag when the application opens the file(s) with
CreateFile . This will allows the views to be unmapped and moved to the standby list

after page reads are completed. This will require involvement from the software
developer.
References
CreateFileA function (fileapi.h)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Configure Microsoft Distributed
Transaction Coordinator (DTC) to work
through a firewall
Article • 12/26/2023

This article describes how to configure Microsoft Distributed Transaction Coordinator

(DTC) to work through firewalls.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019,
Windows Server 2022
Original KB number: 250367

More information
You can configure DTC to communicate through firewalls, including network address
translation firewalls.

DTC uses Remote Procedure Call (RPC) dynamic port allocation by default. RPC dynamic
port allocation randomly selects port numbers in the 49152-65535 range. By modifying
the registry, you can control which ports RPC dynamically allocates for incoming
communication. You can then configure your firewall to confine incoming external
communication to only those ports and port 135 (the RPC Endpoint Mapper port). It is
recommended to use either fixed port for DTC services or the default dynamic 49152-
65535 range in firewalls to avoid port exhaustion and only change to custom RPC ports
if firewalls cannot filter on computer or IPs.

You can have one local DTC instance and multiple clustered DTC instances. You may
need to provide more incoming dynamic ports for other subsystems that rely on RPC so
it is recommended to keep default RPC range even if using fixed port for DTC services.

The registry keys and values described in this article don't appear in the registry by
default; you must add them by using Registry Editor.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
 problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Window .

Configure DTC to use single fixed port

Follow these steps on computers involved in DTC transactions to set fixed port for DTC.
The firewall must be open in both directions for the fixed port and port 135 (the RPC
Endpoint Mapper port):

1. To start Registry Editor, select Start, select Run, type regedt32, and then select OK.
2. In Registry Editor, select HKEY_LOCAL_MACHINE in the Local Machine window.
3. Expand the tree by double-selecting the folders named in the
HKEY_LOCAL_MACHINE\Software\Microsoft\MSDTC path.

4. Select the MSDTC folder, and then select New > DWORD (32-bit) Value on the
Edit menu.
5. Change the Name to ServerTcpPort.
6. Right-click and choose Modify on the new value.
7. In the Value Editor dialog box, select Decimal and then put your fixed port
number, e g 40001, in the Value data field, and then select OK.

To configure fixed port for clustered DTC instances, you need to find the cluster resource
GUID and add the ServerTcpPort value under this location. Use different port number
for each DTC instance. For example, if your DTC resource GUID is 012345678-9abc-def0-
1234-56789abcdef0, then it would be in this path:
HKEY_LOCAL_MACHINE\Cluster\Resources\012345678-9abc-def0-1234-
56789abcdef0\MSDTCPRIVATE\MSDTC . Repeat the steps for additional DTC clustered

resources.

Alternative, you can use the reg add commands in scripts with administrator privileges
to do this operation. Adjust the following example to your specific cluster GUID if
clustered DTC instance is used:

Console

reg add HKLM\SOFTWARE\Microsoft\MSDTC /v ServerTcpPort /t REG_DWORD /d 40001

/f
reg add HKLM\Cluster\Resources\012345678-9abc-def0-1234-
56789abcdef0\MSDTCPRIVATE\MSDTC /v ServerTcpPort /t REG_DWORD /d 40002 /f

Configure RPC to use customer port range

Follow these steps on computers involved in DTC transactions where firewalls prevent
full communication to control RPC dynamic port allocation. The firewall must be open in
both directions for the specified ports and port 135 (the RPC Endpoint Mapper port):

1. To start Registry Editor, select Start, select Run, type regedt32, and then select OK.

Use Regedt32.exe instead of Regedit.exe. Regedit.exe doesn't support the

REG_MULTI_SZ data type that's required for the Ports value.

2. In Registry Editor, select HKEY_LOCAL_MACHINE in the Local Machine window.

3. Expand the tree by double-selecting the folders named in the

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc path.

4. Select the RPC folder, and then select Add Key on the Edit menu.

5. In the Add Key dialog box, in the Key Name box, type Internet, and then select OK.

6. Select the Internet folder, and then select Add Value on the Edit menu.

7. In the Add Value dialog box, in the Value Name box, type Ports.

8. In the Data Type box, select REG_MULTI_SZ, and then select OK.

9. In the Multi-String Editor dialog box, in the Data box, specify the port or ports you
want RPC to use for dynamic port allocation, and then select OK.

Each string value you type specifies either a single port or an inclusive range of
ports. For example, to open port 40000, specify 40000 without the quotation
marks. To open ports 40000 to 42000 inclusive, specify 40000-42000 without the
quotation marks. You can specify multiple ports or ports ranges by specifying one
port or port range per line. All ports must be in the range of 1024 to 65535. If any
port is outside this range or if any string is invalid, RPC will treat the entire
configuration as invalid.

Microsoft recommends that you open up ports from 20000 and up, as lower ports
may often be in use by other applications, and that you open a minimum of 1000
ports to avoid port exhaustion. On high load systems you may need more ports.
The default range of 1024-5000 was moved in Windows 2008 and above to 49152-
65535 range to avoid port exhaustion.

10. Follow steps 6 through 9 to add another key for Internet, by using these values:

Value: PortsInternetAvailable
Data Type: REG_SZ
Data: Y
 This value signifies that the ports listed under the Ports value are to be made
Internet-available.

11. Follow steps 6 through 9 to add another key for Internet, by using these values:

Value: UseInternetPorts
Data Type: REG_SZ
Data: Y

This value signifies that RPC should dynamically assign ports from the list of
Internet ports.

12. Configure your firewall to allow incoming access to the specified dynamic ports
and to port 135 (the RPC Endpoint Mapper port).

13. Restart the computer. When RPC restarts, it will assign incoming ports dynamically,
based on the registry values that you've specified. For example, to open ports
40000 through 42000 inclusive, create these named values:

Ports : REG_MULTI-SZ : 40000-42000

PortsInternetAvailable : REG_SZ : Y
UseInternetPorts : REG_SZ : Y

DTC also requires you can resolve computer names by way of NetBIOS or DNS. Check
that NetBIOS is enabled in the NIC properties and test if NetBIOS can resolve the names
by using ping and the server name. The client computer must be able to resolve the
name of the server. And the server must be able to resolve the name of the client. If
NetBIOS can't resolve the names, add entries to the LMHOSTS files on the computers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to enable network DTC access
Article • 12/26/2023

This article describes the procedures that you follow to enable network Distributed
Transaction Coordinator (DTC) access.

Applies to: Windows Server 2003

Original KB number: 817064

Summary

７ Note

The following procedure is for Windows Server 2003. It does not apply to Microsoft
Windows 2000 Server.

By default, network DTC access is disabled on the Windows Server 2003 products that
are mentioned in the "Applies To" section. When you do not enable network DTC access
on the server, applications can only use transactions that stay on the local computer. For
example, transactions cannot flow from a local computer to a database that runs on a
separate computer if network DTC access is disabled.

When network DTC access is disabled, clients that try to gain access to DTC on the server
may receive the following error message:

error 0x8004D025 (XACT_E_PARTNER_NETWORK_TX_DISABLED)

More information

Steps to enable network DTC access

1. Click Start, point to Control Panel, and then click Add or Remove Programs.
2. Click Add/Remove Windows Components.
3. Select Application Server, and then click Details.
4. Select Enable network DTC access, and then click OK.
5. Click Next.
6. Click Finish.
If you are running Windows Server 2003 Service Pack 1 (SP1), you must follow these
additional steps:

1. Click Start, click Run, type comexp.msc, and then click OK to open Component
Services.

2. Expand Component Services, expand Computers, right-click My Computer, and

then click Properties.

3. On the MSDTC tab, click Security Configuration under Transaction Configuration,

click to select the Network DTC Access check box under Security Settings, and
then click to select the following check boxes under Transaction Manager
Communication:

Allow Inbound
Allow Outbound

4. On Microsoft Cluster Server (MSCS) clusters, you cannot select Mutual

Authentication Required. Therefore, click to select one of the following check
boxes:

Incoming Caller Authentication Required

No Authentication Required

７ Note

For more information about these options, click the following article number
to view the article in the Microsoft Knowledge Base:
899191 New functionality in the Distributed Transaction Coordinator service
in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2

5. Make sure that the Logon Account is set to NTAUTHORITY\NetworkService.

6. Click OK. A message box explains that the MS DTC Service will be stopped and
restarted, and that all dependent services will also be stopped and restarted. Click
Yes.

７ Note

If this is a Majority Node Set (MNS) cluster, do not use the MNS resource as
the storage device for MS DTC. MS DTC requires a storage resource such as a
physical disk.
References
For more information about what is new in Microsoft COM+ 1.5, visit the following
Microsoft Developer Network (MSDN) Web site:
What's New in COM+ 1.5

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to rebuild or move a MSDTC
installation for use with a SQL failover
cluster
Article • 12/26/2023

This article describes how to rebuild a broken Microsoft Distributed Transaction

Coordinator (MSDTC) installation for use with a failover clustered SQL Server installation.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 294209

Summary
The following blog has detailed information around the changes in MSDTC behavior
since the release of Windows Server 2008.

MSDTC Recommendations on SQL Failover Cluster

The purpose of the following Frequently Asked Questions (FAQs) is to address common
questions with MSDTC when used with SQL Server Failover Clustered instances to
include current recommendations and best practices.

The MSDTC is a transaction manager that permits client applications to include several
different data sources in one transaction and which then coordinates committing the
distributed transaction across all the servers that are enlisted in the transaction. This
helps ensure that the transaction is committed, if every part of the transaction succeeds,
or is rolled back, if any part of the transaction process fails.

Many people ask why we need to install MSDTC before installing SQL Server. You no
longer need to do this operation. It was a requirement that SQL Server 2005 had
required. That version of SQL Server has ended its lifecycle and so ended the
requirement to install SQL Server.

When deploying SQL Server in a highly available environment like Windows Failover
Clustering, there are certain best practices that can make the MSDTC services behavior
more predictable.

When the topic of cross-database and/or DTC transaction support, under an

Availability Group, comes up the quick response is NOT SUPPORTED!.
 This is a true statement and the conversation tends to then focus on but why? In
fact, some DBAs have tested various forms of these transaction types and not
encountered errors.

The issue is the testing is not complete and the two-phase commit activity
required can result in data loss or a database that does not recover as expected in
certain configurations. In fact, the SQL Server testers inject failures at strategic
locations to create the scenarios that are difficult (but not impossible) to create on
a production server. For more information, see Not-Supported: AGs with TC/Cross-
Database Transaction.

With Windows 2008 Failover cluster and later, you don't need to cluster MSDTC to use
the functionality of the MSDTC service because MSDTC was re-designed in Windows
2008. Unlike Windows 2003, if you install Windows Failover Cluster, you had to cluster
MSDTC. This is no longer the case when using Windows 2008, since by default MSDTC
service is running locally, even with Failover Clustering installed.

If your SQL Server Failover Clustered Instance does require MSDTC and does require the
MSDTC resources to fail over with the SQL Server Instance, we recommend creating a
MSDTC resource within the FailoverCluster role that contains the SQL Server instance
and that it use:

The SQL Server network name\client access point

A disk within the SQL Server role
Name the MSDTC resource with the SQL virtual server name.

Setup and test a new MSDTC cluster resource

by using PowerShell
1. Create a new MSDTC resource replacing the content between and including the <>
sections below then execute.

PowerShell

$SqlRole = <Actual name of the role containing the SQL Server instance>
$SqlNetName = <Actual SQL Servernetwork resourcename>
$VSqlSrv = <Actual SQL Server virtual server name>
$CluDsk = <Actual disk resource name>

If the MSDTC resource didn't accept the name provided, you can alter the name
using the following PowerShell replacing the New Distributed Transaction
Coordinator with RealSqlVsName:
 PowerShell

Get-ClusterResource "New Distributed Transaction Coordinator" | %

{$_.Name = RealSqlVsName }

You can substitute $VSqlSrv for RealSqlVsName if still active.

2. Verify firewall rules by using the following script:

PowerShell

Set-NetFirewallRule -Name 'RPC Endpoint Mapper' -Enabled True

Set-NetFirewallRule -Name 'DTC incoming connections' -Enabled True
Set-NetFirewallRule -Name 'DTC outgoing connections' -Enabled True

3. Set the MSDTC network authentication by using the following script:

PowerShell

Set-DtcNetworkSetting -AuthenticationLevel Mutual `

-DtcName "Local" -InboundTransactionsEnabled $True `
-LUTransactionsEnabled $True `
-OutboundTransactionsEnabled $True `
-RemoteAdministrationAccessEnabled $False `
-RemoteClientAccessEnabled $False `
-XATransactionsEnabled $True -verbose

4. Verify the new MSDTC resource is now listed by using the following command:

PowerShell

Get-Dtc -Verbose |Sort-Object DtcName

5. Test the new MSDTC resource.

PowerShell

Test-Dtc -LocalComputerName RealSqlVsName -Verbose

You can substitute $VSqlSrv for RealSqlVsName if still active. Use

$Env:COMPUTERNAME to test the local installation. You'll need to execute the firewall

rules and MSDTC authentication PowerShell commands on all the other existing
cluster nodes.

6. Test MSDTC.
 In this example, we'll use the AdventureWorks2012 database, you have to
substitute an actual database name that you want to test against. From a SQL
Server query window, run the following SQL statement:

SQL

USE AdventureWorks2012;

GO

BEGIN DISTRIBUTED TRANSACTION;

-- Enter fake transaction to the database

INSERT SQL_Statement

DELETE SQL_Statement

COMMIT TRANSACTION

GO

You should now see that one row affected and that the inserted record doesn't
exist.

References
Recommended MSDTC settings for using Distributed Transactions in SQL Server

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot connectivity issues
in MS DTC by using the DTCPing tool
Article • 12/26/2023

This article describes how to troubleshoot connectivity issues in Microsoft Distributed

Transaction Coordinator (MS DTC) by using the DTCPing tool.

Applies to: Windows Server 2012 R2

Original KB number: 918331

Introduction
By using the DTCPing tool, you can test the name resolution between two computers.
You can also test the remote procedure call (RPC) communication between two
computers. Additionally, you can obtain the following information by using the DTCPing
tool:

MS DTC security settings.

RPC port range information.
MS DTC HKEY_CLASSES_ROOT\CID registry key information.

Download information
The following file is available for download from the Microsoft Download Center:

Download the Dtcping.exe package now.

For more information about how to download Microsoft support files, click the following
article number to view the article in the Microsoft Knowledge Base:

119591 How to obtain Microsoft support files from online services

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection
software that was available on the date that the file was posted. The file is stored on
security-enhanced servers that help prevent any unauthorized changes to the file.

Files that the Dtcping.exe package contains

ﾉ Expand table
 File name File version File size Date Time

Dtcping.exe 1.9.0.1 266,308 29-Jul-2005 00:54

Dtcping.pdb Not Applicable 1,000,448 29-Jul-2005 00:54

HowtoAnalyze_Dtcping_Output.txt Not Applicable 4,530 27-Jul-2005 15:38

Machinea_failure.log Not Applicable 1,560 24-Nov-2003 22:59

Machinea_success.log Not Applicable 1,901 24-Nov-2003 22:21

Machineb_failure.log Not Applicable 999 24-Nov-2003 22:55

Machineb_success.log Not Applicable 1,750 24-Nov-2003 22:31

Readme.txt Not Applicable 3,244 27-Jul-2005 15:32

Troubleshooting information
The Dtcping.exe package includes the following text files that describe how to use the
DTCPing tool:

See the Readme.txt file for information about how to test RPC communication and
MS DTC communication between two computers.

See the HowtoAnalyze_Dtcping_Output.txt file for information about how to obtain

RPC port information, CID registry key information, and other MS DTC-related
information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of the Shutdown Event
Tracker
Article • 12/26/2023

This article describes the Shutdown Event Tracker.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 293814

Summary
Shutdown Event Tracker is a Microsoft Windows Server 2003 and Microsoft Windows XP
feature that you can use to consistently track the reason for system shutdowns. You can
then use this information to analyze shutdowns and to develop a more comprehensive
understanding of your system environment. Shutdown Event Tracker logs events that
are similar to the following in the system event log:

More information
Windows Server 2003 and Windows XP 64-Bit Edition Version 2003

By default, Shutdown Event Tracker is enabled for all Windows Server 2003
operating systems and for Windows XP 64-Bit Edition Version 2003.

To disable Shutdown Event Tracker on all Windows Server 2003 operating systems
and in Windows XP 64-Bit Edition Version 2003, disable the Display Shutdown
Event Tracker policy by using Group Policy. To do it by using Local Group Policy,
follow these steps:

1. Select Start, and then select Run.

2. Type gpedit.msc, and then select OK.
3. Expand Computer Configuration, expand Administrative Templates, and
then expand System.
4. Double-click Display Shutdown Event Tracker.
5. Select Disabled, and then select OK.

Windows XP Professional

By default, Shutdown Event Tracker is disabled in Windows XP Professional.

 To enable Shutdown Event Tracker in Windows XP Professional, in Windows XP
Tablet PC Edition, and in Windows XP Media Center Edition, enable the Display
Shutdown Event Tracker policy by using Group Policy. To do it by using Local
Group Policy, follow these steps:

1. Select Start, and then select Run.

2. Type gpedit.msc, and then select OK.
3. Expand Computer Configuration, expand Administrative Templates, and
then expand System.
4. Double-click Display Shutdown Event Tracker.
5. Select Enabled.
6. In the Shutdown Event Tracker should be displayed box, select Always, and
then select OK.

Shutdown Event Tracker isn't a functional component in Windows XP Home

Edition. So you can't use Shutdown Event Tracker in Windows XP Home Edition.

７ Note

Microsoft recommends that you don't enable the Shutdown Event Tracker in
Windows XP Professional, Windows XP Tablet PC, or Windows XP Media
Center Editions. Microsoft doesn't support the use of this component in these
Windows XP environments.

Custom Options for identifying a shutdown

cause

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

Windows provides a list of eight generic reasons why your computer was shut down.
You can modify this list to include your own custom reasons. To add your own reasons,
follow these steps:
 1. Start Registry Editor.

2. Locate and then select the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Reliability\UserD
efined

3. On the Edit menu, select New, and then select Multi-String Value. Which creates
the new key and gives it the temporary name "New Value."

4. Type the name of the registry key in the following format, and then press ENTER:
UI_control_flags; major_reason_number; minor_reason_number
The UI_control_flags section of the value name can contain one or more of the
following values:

P (Indicates that the reason is planned. If this value is omitted, the default is
unplanned.)
C or B (Indicates that a comment is required.)
S (Indicates that the reason should be displayed in the user-initiated
shutdown dialog box.)
D (Indicates that the reason should be displayed in the sudden shutdown
dialog box.)For example, if you want a reason to be displayed in the sudden
shutdown dialog box, the shutdown is unplanned, and the shutdown
corresponds to a major reason 2 and to a minor reason 2, type the following
value name: D;2;2

5. Double-click the new key, and then define the value data in the following format:

Title
Description

Each value is made up of two strings on separate lines; the first string is the title
(it's displayed in the list) and the second string is the description (it's the text that
is displayed following the selected reason).

For example, if you want to create a custom reason for a natural disaster, you can
define the value data as follows: Natural Disaster (unplanned)

A flood, an earthquake, a tornado, or another unplanned natural event requires

that the computer shuts down. Specify the natural event in the comment area.

6. Quit Registry Editor.

Notes
 You can specify both S and D for UI_control_flags, but you must specify at least
one of them for the parameters to be valid.
If the UI_control_flags section contains any characters other than the characters
that are listed in the "Custom Options for Identifying a Shutdown Cause" section of
this article, or if the UI_control_flags section exceeds five characters, the message
isn't valid and isn't displayed in the user interface. You can specify that the
characters appear in any order.
The major_reason_number is a number from 0 through 255. If this section is left
blank, if it contains a number that isn't in the valid range, or if it contains a number
that isn't an integer, the message isn't valid and isn't displayed in the user
interface.
The minor_reason_number is a number from 0 through 65,536. If this section is left
blank, if it contains a number that isn't in the valid range, or if it contains a number
that is not an integer, the message isn't valid and isn't displayed in the user
interface.
The custom reasons are sorted in the user interface by two keys in the following
order: MajorReasonNumber, MinorReasonNumber.
The maximum length for the title is 64 characters, and the maximum length for the
description is 96 characters.
If you set the following registry key to any non-zero value, and you've correctly
defined at least one custom reason, the standard Windows reasons aren't
displayed in the Shut Down Windows dialog box:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability\Shutd
ownIgnorePredefinedReasons

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to delete corrupt Event Viewer Log
files
Article • 12/26/2023

This article describes a method to rename or move these files for troubleshooting
purposes.

Applies to: Windows Server 2012 R2

Original KB number: 172156

Symptoms
When you launch Windows Event Viewer, one of the following error messages may
occur if one of the *.evt files is corrupt:

The handle is invalid

Dr. Watson Services.exe

Exception: Access Violation (0xc0000005), Address: 0x76e073d4

When you select OK or cancel on the Dr. Watson error message, you may also receive
the following error message:

Event Viewer
Remote Procedure Call failed

The services.exe process may consume a high percentage of CPU utilization.

Cause
The Event Viewer Log files (Sysevent.evt, Appevent.evt, Secevent.evt) are always in use by
the system, preventing the files from being deleted or renamed. The EventLog service
can't be stopped because it's required by other services, thus the files are always open.

Resolution

） Important
 This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows

NTFS Partition
1. Select the Start button, point to Settings, select Control Panel, and then double-
click Services.

2. Select the EventLog service and select Startup. Change the Startup Type to
Disabled, and then select OK. If you're unable to sign in the computer but can
access the registry remotely, you can change the Startup value in the following
registry key to 0x4:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog

3. Restart Windows.

７ Note

When the system starts up, several services may fail; a message informing the
user to use Event Viewer to review errors may appear.

4. Rename or move the corrupt *.evt file from the following location:
%SystemRoot%\System32\Config

5. In Control Panel Services tool, re-enable the EventLog service by setting it back to
the default of Automatic startup, or change the registry Startup value back to 0x2.

FAT partition (Alternative method)

1. Boot to an MS-DOS prompt using a DOS bootable disk.

2. Rename or move the corrupt *.evt file from the following location:
%SystemRoot%\System32\Config

3. Remove the disk and restart Windows.

When Windows is restarted, the Event Log file will be recreated.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to move Event Viewer log files to
another location
Article • 12/26/2023

This article describes how to move Windows Server 2016 and Windows Server 2019
Event Viewer log files to another location on the hard disk.

Applies to: Windows Server 2016, Windows Server 2019

Original KB number: 315417

Summary
Windows Server records events in the following logs:

Application log

The application log contains events that are logged by programs. Events that are
written to the application log are determined by the developers of the software
program.

Security log

The security log contains events such as valid and invalid logon attempts. It also
contains events that are related to resource use, for example, when you create,
open, or delete files. You must be logged on as an administrator or as a member of
the Administrators group to turn on, to use, and to specify which events are
recorded in the security log.

System log

The system log contains events that are logged by Windows system components.
These events are predetermined by Windows.

Directory Service log

The Directory Service log contains Active Directory-related events. This log is
available only on domain controllers.

DNS Server log

The DNS Server log contains events that are related to the resolution of DNS
names to or from Internet protocol (IP) addresses. This log is available only on DNS
servers.
 File Replication Service log

The File Replication Service log contains events that are logged during the
replication process between domain controllers. This log is available only on
domain controllers.

By default, Event Viewer log files use the .evt extension and are located in the
%SystemRoot%\System32\winevt\Logs folder.

Log file name and location information is stored in the registry. You can edit this
information to change the default location of the log files. You may want to move log
files to another location if you require more disk space in which to log data.

Create an event log folder in another location

Create a folder where you want to store the event logs in your local drive and assign
correct permissions. Here are the steps:

1. Create a folder (for example, C:\EventLogs).

2. Right-click the folder and select Properties.

3. Select the Security tab, and then select Advanced for special permissions or
advanced settings.

７ Note

The folder has "inheritance" enabled by default.

4. Select Change to change the Owner to SYSTEM, and then select Disable
Inheritance as follows:
 You'll be prompted to convert or remove inherited permissions. Select Convert
inherited permissions into explicit permissions on this object, and you'll see the
same permissions explicitly set on the folder.

７ Note

To create subfolders for the logs, check the Replace all child object
permission entries with inheritable permissions entries from this object
option. The permissions set at the parent level are applied to all subfolders
and files.

5. Adjust permissions so that the folder is assigned the correct permissions and check
the Applies to column. These permissions should be the same as the advanced
permissions of the default folder (%SystemRoot%\System32\winevt\Logs) that
stores the Event Viewer logs. Make sure that the Authenticated Users only have
Read permission for This folder and subfolders.
 ７ Note

To add the EventLog user, go to the Security tab of the properties dialog box
and follow these steps:
a. Select Edit > Add.
b. Select Locations, select the local computer name, and then select OK.
c. Type NT SERVICE\EventLog in Enter the object names to select and select
Check Names. The name should be resolved to EventLog. Select OK to
finish.

Make sure Full Control is selected under Permissions for EventLog for the
EventLog user.

Move Event Viewer log files to another location

You can move the log files to the created folder by using the Event Viewer as follows:

1. Open the Event Viewer.

2. Right-click the log name (for example, System) under Windows Logs in the left
pane and select Properties.

3. Change the Log path value to the location of the created folder and leave the log
file name at the end of the path (for example, C:\EventLogs\System.evtx).
 4. Select Clear Log, and then select Save and Clear to retain the event log files in a
different location.

5. Select Apply > OK.

７ Note

Check the folder you moved the event logs to. If the event logs are not in the
folder, restart the system.

You can confirm that the log path has been updated by using Registry Editor. For
example, go to the following registry path and check the Value data of the File value.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System

Move Event Viewer log files by using

Powershell
It is possible to utilize Powershell for this purpose. In the sample, Security event logs will
be migrated to C:\Logs:

PowerShell

$originalFolder = "$env:SystemRoot\system32\winevt\Logs"
$targetFolder = "C:\logs"
$logName = "Security"

$originalAcl = Get-Acl -Path $originalFolder -Audit -

AllCentralAccessPolicies
Set-Acl -Path $targetFolder -AclObject $originalAcl -
ClearCentralAccessPolicy
$targetAcl = Get-Acl -Path $targetFolder -Audit -AllCentralAccessPolicies
$targetAcl.SetOwner([System.Security.Principal.NTAccount]::new("SYSTEM"))

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName"
-Name "AutoBackupLogFiles" -Value "1" -PropertyType "DWord"
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName"
-Name "Flags" -Value "1" -PropertyType "DWord"
Set-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName" -Name "File" -
Value "$targetFolder\$logName.evtx"

References
For more information about how to view and manage logs in the Event Viewer, see How
to delete corrupt Event Viewer Log files . To learn more about general Event Viewer
usage, select the Action menu in Event Viewer, and then select Help.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to fix MSI software update
registration corruption issues
Article • 12/26/2023

This article provides a solution to an issue that repairs or uninstalls for certain products
may fail after you install software updates.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 971187

Symptoms
After you install software updates, repairs or uninstalls for certain products may fail. If
you have MSI logging enabled, the following lines are found in the log:

Couldn't find local patch ''. Looking for it at its source.

...
MainEngineThread is returning 1612

When you look in the registry, you may find that the software update cache registration
is missing from the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\
<SID>\Patches\<SQUID>

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs.

To fix this problem, follow these steps:

1. Confirm that the product is affected.

 To do it, follow these steps:

a. Find the software update registration of the product by opening the following
registry subkey:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User

Data\<SID>\Products\<ProductSQUID>\Patches

Under this subkey, there will be a subkey for every software update that was
applied to the product.

b. For each subkey that is in the following format, perform the following step:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User

Data\<SID>\Products\<ProductSQUID>\Patches\<PatchSQUID>

Verify that the following subkey exists:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User

Data\<SID>\Patches\<PatchSQUID>

If the subkey is missing, the product is affected. Continue to step 2.

If the subkey exists, verify that the LocalPackage string value is set correctly, and
that the package referenced by the LocalPackage string value also exists.
i. If the LocalPackage string value or referenced package is missing, the
product is affected. Continue to step 2.
ii. If the referenced package exists and no additional action is required.

2. Re-create software update cache registry details. To do this, follow these steps:

a. Search the %windir%\installer\*.msp for the software update that you tried to
install. Verify that the software update has the correct Patch Globally Unique
Identifier (GUID) in the Summary Information Stream and targets the correct
product GUIDs.

７ Note

Because this directory serves as the cache for per-user installations and
per-machine installations, you can simulate a software update in this
directory by using a per-user installation.

b. Create the following subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User
Data\<SID>\Patches\<PatchSQUID>
 ７ Note

It's a security risk to re-create the software update cache registry. However,
this is the only way to repair the corruption. You can reduce the security
risk by making sure that the software update is the correct software
update. To do this, verify the checksum of the software update.

c. Create a LocalPackage string value in the registry subkey that you created step
2. Make sure that the LocalPackage string value is set to the path of the
software update.

3. Delete remaining software update references. To do it, follow these steps:

a. Open the following subkey, and then remove <PatchSQUID> from the
"AllPatches" multi-sz value:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User

Data\<SID>\Products\<ProductSQUID>\Patches

b. Delete the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User

Data\<SID>\Products\<ProductSQUID>\Patches\<PatchSQUID>

c. Delete the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\User
Data\<SID>\Patches\<PatchSQUID>

７ Note

If this subkey is missing, skip this step.

d. If the product was installed per-machine, follow these steps:

i. Open the following subkey:

HKEY_LOCAL_MACHINE\Software\Classes\Installer\Products\

<ProductSQUID>\Patches

i. If the <PatchSQUID> string value is present, delete it.

ii. If the <PatchSQUID> string value is present in the "Patches" Multi-sz value,
delete the <PatchSQUID> string value.

ii. If following registry subkey is present, delete it:

HKEY_LOCAL_MACHINE\Software\Classes\Installer\Patches\<PatchSQUID>
 e. If the product was installed per-user unmanaged:

i. Open the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\
<ProductSQUID>\Patches

i. If the <PatchSQUID> string value is present, delete it.

ii. If the <PatchSQUID> from the "Patches" Multi-sz value is present, remove it.

ii. If following registry subkey is present, delete it:

HKEY_CURRENT_USER\Software\Microsoft\Installer\Patches\<PatchSQUID>

f. If the product was installed per-user managed:

i. Open the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\M
anaged\<SID>\Installer\Products\<ProductSQUID>\Patches

i. If the <PatchSQUID> string value is present, delete it.

ii. If the <PatchSQUID> from the "Patches" Multi-sz value is present, remove it.

ii. If the following registry subkey is present, delete it:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\M
anaged\<SID>\Installer\Patches\<PatchSQUID>

References
This article isn't specific for issues occurred by Windows Update or Microsoft Update.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 1603 when you try to install a
Windows Installer package: A fatal error
occurred during installation
Article • 12/26/2023

This article helps fix the error 1603 that occurs when you install a Microsoft Windows
Installer package.

Applies to: Windows 10 - all editions

Original KB number: 834484

Symptoms
When you try to install a Windows Installer package, you may receive the following error
message:

Error 1603: A fatal error occurred during installation.

If you click OK in the message box, the installation rolls back.

Cause
You may receive this error message if any one of the following conditions is true:

Windows Installer is attempting to install an app that is already installed on your

PC.
The folder that you are trying to install the Windows Installer package to is
encrypted.
The drive that contains the folder that you are trying to install the Windows
Installer package to is accessed as a substitute drive.
The SYSTEM account does not have Full Control permissions on the folder that you
are trying to install the Windows Installer package to. You notice the error message
because the Windows Installer service uses the SYSTEM account to install software.

Resolution
To resolve this problem, use any one of the following methods, depending on the cause
of the problem:
Check if the app is already installed on the PC. If so, uninstall and reinstall the app.

If you previously had a desktop shortcut for an app, the shortcut may have been
lost during the upgrade to Windows 10. In such cases, the app is likely still installed
on the PC, resulting in this error when you attempt to reinstall the app. You can
restore the shortcut by searching for the app, and if it's found, press and hold (or
right-click) the app and select Pin to Start. Or you can resolve the issue by
uninstalling and then reinstalling the app. To search for and uninstall apps in
Windows 10:

1. On the Start menu, select Settings.

2. In Settings, select System > Apps & features.
3. If the app is listed, then this is, select it and then select Uninstall.
4. Follow the directions on the screen.

Install the package to a folder that is not encrypted.

Use this method if you receive the error message because you try to install the
Windows Installer package to a folder that is encrypted.

Install the package to a drive that is not accessed as a substitute drive.

Use this method if you receive the error message because the drive that contains
the folder that you try to install the Windows Installer package to is accessed as a
substitute drive.

Grant Full Control permissions to the SYSTEM account.

Use this method if you receive the error message because the SYSTEM account
does not have Full Control permissions on the folder you are installing the
Windows Installer package to.

To grant Full Control permissions to the SYSTEM account, follow these steps:

1. Open File Explorer (or Windows Explorer), right-click the drive that you want
to install the Windows Installer package to, and then click Properties.

2. Click the Security tab. Verify that the Group or user names box contains the
SYSTEM user account. If the SYSTEM user account doesn't appear in the box,
follow these steps to add the SYSTEM account:
a. Click Edit. If prompted, approve the User Account Control.
b. Click Add. The Select Users or Groups dialog box appears.
c. In the Enter the object names to select field, type SYSTEM, and then click
Check names.
d. Click OK.
 3. To change permissions, click Edit. If prompted, approve the User Account
Control.

4. Select the SYSTEM user account, and verify in the Permissions section that
Full Control is set to Allow. If not, select the Allow check box.

5. Close the Permissions dialog and return to the Properties dialog. Click
Advanced.

6. Select Change permissions. If prompted, approve the User Account Control.

7. In the Permissions tab, select the SYSTEM entry and click Edit.

8. Click the Applies to dropdown and select This folder, subfolder, and files.
Click OK.

9. Wait for the operating system to apply the permissions that you have
selected to all child folders.

10. Run the Windows Installer package.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How the Regional and Language
Options settings in Windows Server
2003 are applied
Article • 12/26/2023

This article describes the user-specific and computer-wide settings in Regional and
Language Options in Control Panel, the implications of configuring Regional and
Language Options during Windows Setup, and the effects on Window Server 2003
Terminal Server.

Applies to: Windows Server 2003

Original KB number: 924852

Introduction
This article describes how the Regional and Language Options settings in Windows
Server 2003 are applied. Some of the settings vary from user profile to user profile.
Other settings are computer wide. This article also discusses the effects of configuring
the Regional and Language Options settings during Windows Setup.

Regional options settings

The Regional and Language Options settings are located in Control Panel on a
Windows Server 2003-based computer.

The Regional Options tab contains the following settings:

Standards and formats

These are user-specific settings and are stored as part of the user profile.
Location
This is a user-specific setting and is stored as part of the user profile.

Language settings
The Languages tab contains the following settings:

Default input language

This is a user-specific setting and is stored as part of the user profile.
 Installed services
This is a computer-wide setting.

７ Note

To access these language settings, click Details in Text services and input
languages.

Advanced settings
The Advanced tab contains the following settings:

Language for non-Unicode programs

This is a computer-wide setting.
Default user account settings
Click to select the Apply all settings to the current user account and to the
default user profile check box to apply changes to the default user profile.

Configure Regional and Language Options

during Windows Setup
You're prompted to configure Regional and Language Options during Windows Setup.
Computer-wide settings affect all users who log on to the system. User-specific settings
affect only the default user profile. New user profiles inherit the user-specific settings
that you specified during Setup.

You can change the user-specific settings for the default user profile by selecting the
Apply all settings to the current user account and to the default user profile check box
on the Advanced tab.

Considerations for Windows Server 2003

Terminal Server

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
 back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

The first time that a user uses a Remote Desktop Connection to log on to a server that
has Terminal Server enabled, a new profile is created. The new profile inherits the
Regional and Language Options settings from the default user profile. The profile may
be local to the terminal server or may reside on a network share. However, the Default
input language setting is obtained from the client computer that initiated the Remote
Desktop Connection.

To change the default behavior to obtain the Default input language setting from the
default user profile, you must set a registry entry value on the terminal server. To do this,
follow these steps:

1. On the terminal server, click Start > Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

3. On the Edit menu, click Add Value, and then add the following registry
information:

Value name: IgnoreRemoteKeyboardLayout

Data type: REG_DWORD
Value data: 1

When the IgnoreRemoteKeyboardLayout entry is set to 1, new user profiles inherit the
Default input language setting from the default user profile that the user account uses.

７ Note

This registry entry may not work if you're not running Windows Server 2003 Service
Pack 1.

Existing user profiles

If a user profile already exists, the Regional and Language Options settings in the
existing user profile are applied to new users.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

HTTP Listener fails to initialize when
lacking SeChangeNotifyPrivilege
Article • 12/26/2023

This article provides a solution to an issue that HTTP Listener fails to initialize when user
lacks SeChangeNotifyPrivilege.

Applies to: Windows Server 2016, Windows Server 2019

Original KB number: 4570992

Symptoms
When initializing a new HTTP Listener using the HttpInitialize function or the .NET
HttpListener class, the operation fails and you receive this error message:

HttpInitialize failed with 5 ( -access denied)

Cause
This issue occurs when the account running the code lacks the SeChangeNotifyPrivilege
privilege.

Workaround
Grant the Bypass traverse checking user right to the relevant account.

This privilege is granted to the Everyone group by default.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Services that depend on the ASP.NET
State Service do not start after you
upgrade to the .NET Framework 4.0
Article • 12/26/2023

This article provides a workaround for an issue where services that depend on the
ASP.NET State Service don't start after you upgrade to the Microsoft .NET Framework

4.0.

Applies to: Windows Server 2012 R2

Original KB number: 2963657

Symptoms
Consider the following scenario:

You have a computer that is running Windows Server.

The ASP.NET State Service is installed as part of Internet Information Services (IIS).
An installed service depends on the ASP.NET State Service.
You upgrade the Microsoft .NET Framework 3.51 to the .NET Framework 4.0.

In this scenario, you notice that after you upgrade .NET Framework, any service that
depends on the ASP.NET State Service does not start and generates the following error:

Windows could not start the <service name> service on <computer name>.

Error 1075: The dependency service does not exist or has been marked for deletion.

You also notice that the ASP.NET State Service is no longer listed in the Services
Management console.

Cause
This is a known issue that occurs when you update .NET Framework.

Workaround
To work around this issue, follow these steps:
 1. Open the Services management console (services.msc).

2. Change to Manual the start type of any service that depends on the ASP.NET State
Service and that is set to Automatic.

3. At an Administrative command prompt, type the following command, and then

press Enter:

Console

%SystemRoot%\ Microsoft.NET\Framework64\v4.0.30319 \aspnet_regiis /iru

4. Restart the computer.

5. Open the Services management console (services.msc) again.

6. Change to Automatic the start type of the service or services that had their start
type changed in step 2, that depend on the ASP.NET State Service, and that now
have their start type set to Manual. Restart the computer, and then confirm that
the issue is resolved.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to run a logon script one time
when a new user logs on in Windows
Server 2003
Article • 12/26/2023

This article describes how to configure a logon script or program to run one time when
a user signs in to a computer for the first time.

Applies to: Windows Server 2003

Original KB number: 325347

Summary

） Important

This article contains information about modifying the registry. Before you modify
the registry, make sure to back it up and make sure that you understand how to
restore the registry if a problem occurs. For information about how to back up,
restore, and edit the registry, see Windows registry information for advanced
users .

These steps apply only to new users who have never logged on to the computer. If a
user already has a local user profile or a roaming profile, the script or program doesn't
run.

Configure a script to run one time when a new

user signs in

２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.
When a Windows Server 2003-based product is installed, the Default User profile is
created. The first time that a user logs on, the Default User profile is copied to the user's
profile.

To configure a script or program to run when a new user logs on, follow these steps:

1. Select Start, and then select Run.

2. In the Open box, type regedit.exe, and then select OK.

3. Locate the following subkey in the registry:

HKEY_USERS

4. On the File menu, select Load Hive.

5. In the Load Hive dialog box, locate the Profilepath \Default User\Ntuser.dat file,
where Profilepath is the file system location of the Default User profile. Select
Open.

6. In the Load Hive dialog box type a name for the hive, and then select OK.

７ Note

The Ntuser.dat file is hidden. If you can't locate or load the Ntuser.dat file, you
must change your view settings in Windows Explorer. To do it, follow these
steps:

a. Select Start, and then select Windows Explorer.

b. Select Tools, and then select Folder Options.
c. Select the View tab.
d. Click to clear the Hide extensions for known file types check box.
e. Select Show hidden files and folders, and then select OK.

7. Locate the following subkey in the registry:

HKEY_USERS\Test\Software\Microsoft\Windows\CurrentVersion\Runonce

７ Note

Where Test is the name that you gave to the Ntuser.dat hive in step 6.

8. On the Edit menu, point to New, and then select String Value.

9. In the right pane, double-click the new value.

 10. In the Edit String dialog box, type the full path and file name for the program or
logon script, and then select OK.

11. In the left pane, select the Test hive.

12. On the File menu, select Unload Hive.

13. Select Yes when prompted to confirm you want to unload the hive.

14. Quit Registry Editor. This program or logon script runs for a user who doesn't have
a user profile. To view the user profiles on the local computer, follow these steps:
a. Select Start, point to Control Panel, and then select System.
b. Select the Advanced tab.
c. In the User Profiles area, select Settings.
The user profiles are listed in the User Profiles dialog box.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Backup and Storage troubleshooting
documentation for Windows Server
Article • 12/26/2023

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Backup and Storage-related issues. The topics are divided
into subcategories. Browse the content or use the search feature to find relevant
content.

Backup and Storage sub categories

Active Directory backup and restore, or disaster recovery
Configuring and using Backup software
Data corruption and disk errors
Deduplication
File Server Resource Manager (FSRM)
iSCSI
Multipath I/O (MPIO) and Storport
Partition and volume management
Storage hardware
Storage Spaces
System Restore or resetting your computer
Volume Shadow Copy Service (VSS)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Useful shelf life of a system-state
backup of Active Directory
Article • 12/26/2023

This article describes the useful shelf life of a system-state backup of Active Directory
(AD).

Applies to: Windows Server 2003, Windows 2000, Windows XP

Original KB number: 216993

Summary
Windows Backup, the backup tool that is included with Windows Server 2003 and with
Windows 2000, can back up and restore Active Directory on Windows Server 2003 or
Windows 2000 domain controllers. These backups can be performed while the domain
controller is online. You can restore these backups only when the domain controller is
booted into Directory Services Restore mode by using the F8 key when the server is
starting.

If a nonauthoritative restore is performed by using Backup, the domain controller will

contain the settings and entries that existed in the Domain, Schema, Configuration, and
optionally the Global Catalog Naming Contexts when the backup was performed. Partial
synchronization (replication) from other replicas within the enterprise then update all
naming contexts hosted on the domain controller, overwriting the restored data.

Windows Server 2003 and Windows 2000 don't allow the restoring of old backup
images into a replicated enterprise. Specifically, the useful life of a backup is the same as
the "tombstone lifetime" setting for the enterprise. The default value for the tombstone
lifetime entry is 60 days. This value can be set on the Directory Service (NTDS) config
object.

More information
If your only backup of Active Directory is older than the tombstone lifetime setting,
reinstall the server after confirming there is at least one surviving domain controller in
the domain from which new replicas can be synchronized. You can lose all but one
server in the domain and still recover without a loss of data, assuming that the
remaining survivor holds current information.
If every server in the domain is destroyed when you use the server in a single domain
controller forest or in a single domain that contains multiple domain controllers, restore
one server from an arbitrarily outdated backup. Then, replicate all other servers from the
restored one. However, you cannot restore the server when you use the server in a
multi-domain forest. In this scenario, information that was written to Active Directory
after the outdated backup was performed is not available.

The tombstone lifetime attribute is located on the enterprise-wide DS config object. The
path for this attribute is:CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=COMPANY,DC=COM

Use the Active Directory editing tool of your choice so that the "tombstoneLifetime"
attribute is set to be older than the backup used to restore Active Directory. Supported
tools include Adsiedit.msc, Ldp.exe, and Active Directory Service Interfaces (ADSI)
scripts.

７ Note

This information assumes that the backup is not older than the default
"tombstoneLifetime" setting. Otherwise, the objects have already been deleted
from the database. In this case, an authoritative restore may be the better
alternative if there are multiple domain controllers.

The "tombstoneLifetime" attribute represents the number of days a backup of Active

Directory can be used in addition to the frequency with which Garbage Collection
routines (removing items previously marked for deletion) are run. For more information
about Garbage Collection, see The Active Directory database Garbage Collection
process and calculation of allowed intervals.

Changes to the tombstone lifetime attribute in

Windows Server 2003 Service Pack 1
The default tombstone lifetime value has sometimes proven to be too short. For
example, pre-staged domain controllers are sometimes in transit to their final
destination for longer than 60 days. Administrators regularly do not bring offline
domain controllers into operation or resolve replication failures for longer than the
number of days that is specified by the default tombstone lifetime attribute. Windows
Server 2003 Service Pack 1 (SP1) increases the attribute value from 60 to 180 days in the
following scenarios:
 You use Windows Server 2003 SP1 slipstreamed media to upgrade a Windows NT
4.0 domain to a Windows Server 2003 domain. When you perform the upgrade,
you create a new forest.
You promote a computer that is running Windows Server 2003 SP1 to a domain
controller. When you promote the domain controller, you create a new forest.

The original release version of Windows Server 2003 SP1 does not modify the value of
the tombstone lifetime attribute when the following conditions are true:

You upgrade a Windows 2000 domain to a Windows Server 2003 domain by using
Windows Server 2003 SP1 slipstreamed media.
You install Windows Server 2003 SP1 on domain controllers that are running the
original release version of Windows Server 2003.

Increasing the tombstone lifetime attribute for a domain to 180 days increases the
following items:

The useful life of backups that are used for data recovery scenarios.
The useful life of system state backups that are used for promotions using the
Install from Media feature.
The time that domain controllers can be offline. (Computers that are built in a
staging site and shipped to destination sites frequently approach tombstone
lifetime expiration.)
The time that a domain controller may be offline and still return to the domain
successfully.
The time that a domain controller may experience a replication failure and still
return to the domain successfully.
The number of days that the originating domain controller retains knowledge of
deleted objects.

Technical support for Windows x64 editions

Your hardware manufacturer provides technical support and assistance for Windows x64
editions. Your hardware manufacturer provides support because a Windows x64 edition
was included with your hardware. Your hardware manufacturer might have customized
the Windows x64 edition installation with unique components. Unique components
might include specific device drivers or might include optional settings to maximize the
performance of the hardware. Microsoft will provide reasonable-effort assistance if you
need technical help with your Windows x64 edition. However, you might have to contact
your manufacturer directly. Your manufacturer is best qualified to support the software
that your manufacturer installed on the hardware.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Access is denied when you run a batch
job on a Windows Server 2003-based
computer
Article • 12/26/2023

This article provides solution to an error (Access is denied) that occurs when you run a
batch job on a Microsoft Windows Server 2003-based computer.

Applies to: Windows Server 2003

Original KB number: 867466

Symptoms
When you run a batch job that runs under the context of a regular user account, the
script may not run. If you run the batch job by using the Scheduled Tasks feature, the
following error message may be logged in the Scheduled Tasks log file (Schedlgu.txt):

0x80070005: Access is denied.

If you use a debugger program to try to determine why the batch job does not work,
the following error message may appear in the debug output:

Access Denied (Error 5)

Cause
This issue occurs if all the following conditions are true:

You run the batch job on a Windows Server 2003-based member server.
The batch job runs as a non-interactive process.
The batch job is configured to run under the context of an account that is not a
member of the Administrators group.

In Windows Server 2003, the Users group does not have Read and Execute permissions
to the command processor (Cmd.exe). By default, the Cmd.exe program has the
following permissions settings:

The Interactive implicit group and the Service implicit group have Read and
Execute permissions.
 ７ Note

On a member server, the TelnetClients group also has Read and Execute
permissions. On a domain controller, the Batch implicit group also has Read
and Execute permissions.

The Administrators group and the System implicit group have Full Control
permissions.

To resolve this issue, use either of the following methods.

Resolution 1: Grant Cmd.exe Read and Execute

permissions
Grant the Cmd.exe program Read and Execute permissions for the user account that the
batch job runs under. To do this, follow these steps:

1. Click Start, and then click Windows Explorer.

2. Locate and then right-click the Cmd.exe file. The Cmd.exe file is located in the
%windir%\System32 folder.

3. Click Properties.

4. Click the Security tab.

5. Click Add.

6. In the Enter the object names to select box, type the user name that the batch job
runs under, and then click OK two times.

７ Note

When you add the user, the user is automatically granted Read and Execute
permissions.

7. Click Yes when you are prompted to continue.

Resolution 2: Grant Read and Execute permissions for

Cmd.exe file to Batch group
Grant Read and Execute permissions for the Cmd.exe file to the Batch group. This
permits all batch processes to run the command processor. To do this, follow these
steps:

1. Click Start, and then click Windows Explorer.

2. Locate and then right-click the Cmd.exe file. The Cmd.exe file is located in the
%windir%\System32 folder.
3. Click Properties.
4. Click the Security tab.
5. Click Add.
6. In the Enter the object names to select box, type Batch, and then click OK two
times.
7. Click Yes when you are prompted to continue.

More information
The behavior that is described in this article is different from the default behavior of
Microsoft Windows 2000 Server. By default, Windows 2000 Server grants Read
permissions and Execute permissions to the Users group.

For more information about implicit groups, visit the following Microsoft Web sites:

Default User Accounts and Groups

Using Default Group Accounts

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Backup program is unsuccessful when
you back up a large system volume
Article • 12/26/2023

This article provides a resolution for the issue that backup program is unsuccessful when
you back up a large system volume.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 304101

Symptoms
When you try to create a backup by using NTBackup.exe or by using a third-party
backup program that uses the NT Backup API, the backup may not be completed
successfully. This behavior may occur even if you run the program locally on the server.
Additionally, you may experience one or more of the following symptoms:

One or more of the following error messages appear in the application log:
Error message 1

ERROR 1450: Insufficient system resources exist to complete the requested

service.

ERROR 1450: / hex 0x5aa ERROR_NO_SYSTEM_RESOURCES

Operating system error 1450 Insufficient system resources exist to complete

the requested service.

Write on "device" failed, status = 1450

Error message 2

ERROR 1130: Not enough server storage is available to process this command.

ERROR 1130 / hex 0x46a ERROR_NOT_ENOUGH_SERVER_MEMORY

Backup or restore operation terminating abnormally.

Event ID 2020 and Event ID 2021 messages may be generated by the Server
service.
 ７ Note

Typically, Event ID 2020 and Event ID 2021 messages do not appear.

If you are running the Hewlett-Packard (HP) OmniBack backup program, you may
receive an error message that is similar to the following ones:

[81:78] C:\foldername\file.name

Cannot read 57256 bytes at offset 436176408(:1): ([1450]

Insufficient system resources exist to complete the requested service.).

If you view the Performance tab in Windows Task Manager, you notice that
nonpaged kernel memory is low.

７ Note

You may receive these error messages for reasons that are not related to the
problem that this article describes. If you receive these error messages only when
you back up large system volumes, the two most probable causes are those that
this article describes.

To help determine if you are experiencing this problem, start Windows Task Manager,
and then click the Performance tab. At the lower right, locate the Kernel Memory (K)
area, and then note the value for Paged. You may experience this problem in Microsoft
Windows 2000 or in Microsoft Windows NT 4.0 when this value reaches approximately
160 megabytes (MB). Alternatively, you may experience this problem in Microsoft
Windows Server 2003 when this value exceeds 160 MB. If you have set the registry key
for paged pool memory to a higher value, you will not experience this problem until a
much higher value of paged pool memory is used (the problem may occur when the
paged pool memory usage reaches about 80 percent of the set value). If you have the
gflags setting turned on for pool tags and if you use the Poolmon utility, you see a

higher usage of the MmSt tag. It is the pool tag that is used to map the operating
system memory that is used to track shared files.

Cause
The two causes of this problem are related. The more frequent cause is listed first:
 More files are open than the memory cache manager can handle. As a result, the
cache manager has exhausted the available paged pool memory.

The backup program has tried to back up a file whose size is larger than the
backup API can access on that version of the operating system. It has the same
result (that is, the paged pool is exhausted).

７ Note

This second issue is more likely to occur on a Microsoft Windows NT 4.0-

based computer.

The resolution for each problem differs depending on whether you experience the
problem in Windows Server 2003, in Microsoft Windows 2000, or in Windows NT 4.0.

Resolution

Windows Server 2003 and Windows 2000

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

You may have to change two registry settings. Always change the first setting.
Depending on the configuration of your system, you may also have to change the
second setting.

Registry setting 1

1. Click Start, click Run, type regedit in the Open box, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
 Management

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type PoolUsageMaximum as the entry name, and then press ENTER.

5. Right-click PoolUsageMaximum, and then click Modify.

6. Click Decimal.

7. In the Value data box, type 60, and then click OK.

） Important

Use 60 as your initial value. If your backup does not succeed, use 40 as
your value. If that does not work, you must change the behavior of your
backup program to reduce the demand of paged pool. If the value
works, you may want to increase the value by approximately 25 percent
until the backup does not work. If the backup is unsuccessful, use the
second registry setting that is described in this article.
Make sure that the value for this registry setting is not more than 60.
If you are using the /3GB switch, use 40 as your initial setting. Note that
this value is a percentage value.

8. Quit Registry Editor.

9. Restart your computer.

Because you must test these settings during the most stressful backups, you may have
to wait a month for a whole backup cycle to complete if you are not sure which backup
consumes the most resources. Because of this situation, Microsoft recommends that you
test low values first. For more information, click the following article number to view the
article in the Microsoft Knowledge Base:

312362 Server is unable to allocate memory from the system paged pool

Registry setting 2

1. Click Start, click Run, type regedit in the Open box, and then click OK

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
 Management

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type PagedPoolSize as the entry name, and then press ENTER.

5. Right-click PagedPoolSize, and then click Modify.

6. Click Hexadecimal.

7. In the Value data box, type a value of FFFFFFFF, and then click OK.

） Important

Setting PagedPoolSize to 0xFFFFFFFF (-1) allocates the maximum paged

pool instead of other resources to the computer. This is typically
required on a domain controller or a terminal server. By default, most
Windows 2000 systems seem to be limited to a paged pool maximum
size of 160 MB. You can verify this by downloading the kernel debuggers
from the public Web site and opening a kernel dump in the debugger
that you want to use. The command to use is !vm . This shows a paged
pool maximum of 163840 KB, for example. Adding this value reduces the
Page Table Entries (PTEs) that are available on a system and extends the
paged pool maximum to 343 MB in Windows 2000. The paged pool
maximum size can be extended to a larger value in Windows Server
2003.

The default and maximum paged pool values for Windows Server 2003
are much larger than in Windows 2000. Typically, the Windows Server
2003 values are at least 50 percent higher than the values found in
Windows 2000. These larger values makes it more unlikely that you will
experience the issue where paged pool values contribute to the problem
that is described in this article. However, it is still possible that this issue
may occur.

This value restricts the system PTEs that are available. PTEs are another
unrelated system resource that your system uses. This setting may cause
your operating system to stop unexpectedly and to display a stop 0x3F
error on a blue screen when it starts. You can recover from this by using
the Last Known Good restart option on the system restart menu or
 recovery console. Use Performance Monitor to view the Free System
Page Table Entries counter. You can add the PagePoolSize setting if the
observed free values are over 40,000.

If you are running /3GB and /PAE together, do not set this setting
without extensive testing and before you establish exactly how many
system PTES you must have in your environment. You will probably see
values in the range of 10,000-20,000 free. Use the articles to configure
paged pool memory but never drop below 10,000 free system PTEs. Do
not set this to any other value if you are using the /3GB switch. The only
supported values are 0, 0A000000, and FFFFFFFF.

8. Quit Registry Editor.

9. Restart your computer.

Windows NT 4.0

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

７ Note

You must be using Windows NT 4.0 Service Pack 6a.

Resolve the first problem

1. Start Registry Editor (Regedt32.exe).
 2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session

Manager\Memory_Management

3. On the Edit menu, click Add Value, and then add the following registry value:
Value name: UnusedFileCache
Data type: REG_DWORD
Radix: Decimal
Value data: 15

７ Note

This number represents the percent of pool that can be consumed by unused
segments. A value of 0 indicates that the system will use the default behavior
that is similar to Windows NT 4.0 Service Pack 3. A value of 5 through 40
indicates that the system will trim the unused file cache based on pool usage.
5 is most aggressive (that is, it increases the size of the cache the least) and 40
is least aggressive (that is, it lets the cache grow the largest before it trims the
cache.)

） Important

Use 15 as your initial value. If your backup does not succeed, use 5 as
your value. If this does not work, you must either change the behavior of
your backup program to reduce the demand of paged pool, or you must
upgrade to Windows 2000, where more than double the paged pool is
available (for more information, see the "Windows 2000" section). If this
value works, you may want to increase it by approximately 20 percent
until the backup is unsuccessful. If the backup is unsuccessful, use the
second registry setting that is described in this article.

If you are using the /3GB switch, use 5 as your initial setting.

4. Quit Registry Editor.

5. Restart your computer.

Because you must test these settings during the most stressful backups, you may have
to wait a month for a whole backup cycle to complete if you are not sure which backup
consumes the most resources. Because of it, Microsoft recommends that you test low
values first.

Resolve the second problem

One possible resolution is to restrict the backup so that it backs up one file at a time. It
may or may not work depending on the sizes of the files to be backed up. (It is expected
to work on files that are smaller than 180 gigabytes [GB].) You can also try this resolution
if you are backing up several large files, but each file is smaller than 180 GB. Follow the
steps to resolve the first problem also. For files larger than 180 GB, no workaround
exists. Therefore, you must upgrade the system to Windows 2000. If you try to back up
the system remotely as a workaround, you will experience the same problem.

1. Start Registry Editor (Regedt32.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Memory_Management

3. On the Edit menu, click Add Value, and then add the following registry value:
Value name: DisablePagedPoolHint
Data type: REG_DWORD
Radix: Decimal
Value data: 1

4. Quit Registry Editor.

5. Restart your computer.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
NTBackupread and NTBackupwrite both use buffered I/O. It means that Windows NT
caches the I/O that is performed against the stream. It is also the only API that will back
up the metadata of a file. This cache is pulled from limited resources: namely, pool and
nonpaged pool. Because of this, large numbers of files or files that are large may cause
the pool resources to run low.
Several factors may exhaust the supply of paged pool memory. You can turn on pool
tagging and take poolsnaps at different time intervals to help you to understand which
driver is exhausting paged pool memory. If the poolsnaps indicate that the MmSt tag
(Mm section object prototype PTEs) is the largest consumer and is over 80 MB, a large
number of files are probably open on the server.

The possible maximum paged pool memory on a computer is 343 MB of paged pool in
Windows 2000 with the paged pool key set to FFFFFFFF, or 164 MB if the key is not
present. The possible maximum paged pool memory is 192 MB in Windows NT. By
default, the Memory Manager tries to trim allocated paged pool memory when the
system reaches 80 percent of the total paged pool. For example, 80 percent of 343 MB is
274 MB. If the Memory Manager cannot trim fast enough to keep up with the demand,
the event that is listed in the "Symptoms" section of this article may occur. If you tune
the Memory Manager to start the trimming process earlier (for example, when it reaches
40 percent), the computer can keep up with the paged pool demand during sudden
peak usage so that it does not run out of paged pool memory.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise,
regarding the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you try to add an
additional disk to a scheduled backup:
The filename, directory name, or
volume label syntax is incorrect
Article • 12/26/2023

This article helps fix an error (The filename, directory name, or volume label syntax is
incorrect) that occurs when you add an additional disk to a scheduled backup.

Applies to: Windows Server 2012 R2

Original KB number: 2009365

Symptoms
When you try to add an additional disk to a scheduled backup by using the Windows
Server Backup Schedule Wizard, you may receive the following error message:

"The filename, directory name, or volume label syntax is incorrect"

Cause
This problem may occur if a previously added destination disk is not currently attached
to the server. When the wizard completes, the currently listed destination disks are
verified. If any of these disks are missing, you receive the error message that is described
in the "Symptoms" section.

Resolution
To resolve this issue, use one of the following options.

７ Note

To configure or modify a daily backup schedule, you must be a member of the

Administrators group. In addition, you must run the wbadmin command from an
elevated command prompt. To open an elevated command prompt, click Start,
right-click Command Prompt, and then click Run as administrator.
Option 1
1. Reattach the missing disk or disks.
2. Make sure that all the disks that are defined as backup destination disks are
attached to the server.
3. Try again to add an additional disk to a scheduled backup by using the Windows
Server Backup Schedule Wizard.

７ Note

If you are using offsite storage, or if another situation prevents all destination disks
from being attached at the same time, go to option 3.

Option 2
If the missing disk is no longer available, remove it as a destination disk from the backup
wizard.

７ Note

If the missing disk is the only destination disk that is defined in the backup schedule,
you will receive the following error message when you try to remove it. If this occurs,
click Stop backup, and then create a new backup schedule.

"Error: You cannot remove this backup storage destination unless you add another
storage destination or stop the scheduled backup. A schedule backup requires at
least one backup storage destination.

To remove a destination disk from a scheduled backup, follow these steps:

1. In the Windows Server Backup snap-in, click Backup Schedule.

2. Click Modify backup, and then click Next.

3. Leave the Backup Configuration setting unchanged, and then click Next.

4. Leave the Backup Time setting unchanged, and then click Next.

5. Leave the Destination Type setting unchanged, and then click Next.

6. Select Remove current backup destinations, and then click Next.

 7. Select the backup destination that is no longer attached, and then click Next.

７ Note

Typically, the disk will have the name "(Disk offline)."

8. Verify that the configuration is correct, and then click Finish.

Option 3
Add a new disk to the backup schedule by running the wbadmin command from an
elevated command prompt.

1. Run the following command from an elevated command prompt to determine the
Disk Identifier of the new disk:
wbadmin get disks

2. Based on the output, locate the disk that will be added to the scheduled backup.
Make a note of the Disk Identifier. The output will resemble the following:

Disk name: xxxxxxxxxxx

Disk number: x
Disk identifier: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Total space:xxx.xxGB
Used space: xxx.xxGB

3. Run the following command to add the new disk to the Scheduled backup. Use t
he Disk Identifier from the previous step as the AddTarget parameter.
WBADMIN ENABLE BACKUP -addtarget:{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

4. When you receive the following prompt, type Y for Yes.

"Do you want to enable scheduled backups with the above settings?"

More information
For more information, visit the following Microsoft Web sites:

What's New in Windows Server Backup on Windows Server 2008 R2

What's New in Windows Server Backup
Webadmin
Wbadmin

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DirectAccess clients are unable to
connect over IP-HTTPS with error
0x274d or 0x2afc
Article • 12/26/2023

This article provides a solution to the error 0x274d that occurs when DirectAccess clients
connect to DirectAccess Server by using Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS).

Applies to: Windows Server 2012 R2

Original KB number: 3052855

Symptoms
DirectAccess clients may not be able to connect to DirectAccess Server by using IP-
HTTPS connections or resolve the DirectAccess public hostname.

When you run the netsh interface http show interface command, the output is as
follows:

Error: 0x274d or 0x2afc

Translates to : The requested name is valid, but no data of the requested type was
found

or

No connection could be made because the target machine actively refused it.

Removing the DirectAccess GPO allows the client to resolve the DirectAccess public
hostname.

Running the command netsh namespace show policy on a client will display a policy for
the .contoso.com namespace.

In this policy the DirectAccess (DNS Servers) entry will be set to the internal IPv6
interface of the DirectAccess server, typically ending with 3333::1.

Cause
 Error: 0x2AFC
Role: Client
URL: https://da.contoso.com/IPHTTPS
Last Error Code: 0x2AFC
Interface Status: Failed to connect to IPHTTPs server; Waiting to reconnect.
0x2AFC translates to:
WSANO_DATA
# The requested name is valid, but no data of the requested type was found.
WSANO_DATA
# Successfully returned a NULL value.

There are several reasons this error may occur:

A proxy server is blocking the connection.

Inability to resolve the name of the IP-HTTPS server (DirectAccess server)
mentioned in the IP-HTTPS interface URL.
Client-side or server-side firewall may be blocking the connection to the IP-HTTPS
Server (DirectAccess server).
NAT device is configured incorrectly (if a behind-edge scenario is being used).
All connectivity is fine, but the server does not have the IPv6 prefix published, or
server-side IP-HTTPS is set to disabled.

Error: 0x274D
Role: Client
URL: https://da.contoso.com/IPHTTPS
Last Error Code: 0x274D
Interface Status: Failed to connect to IPHTTPs server; Waiting to reconnect.
0x274D translates to:
WSAECONNREFUSED
# No connection could be made because the target machine actively refused it.

This error is caused by the following causes:

Inability to resolve the name of the IP-HTTPS server (DirectAccess server)

mentioned in the IP-HTTPS interface URL
Incorrectly configured Name Resolution Policy Table (NRPT)
Client-side Firewall may be blocking the IP-HTTPS connection
The internal domain and external DNS entry used by DirectAccess are both in the
same namespace (for example, *.contoso.com)
Resolution
To resolve this issue, we must add an entry to the NRPT instructing the client to use its
internet DNS to resolve the public hostname of the DirectAcess server. To do this, on the
DirectAcess server, open the Remote Access Management Console, under Configuration
select DirectAccess and VPN, find the Infrastructure Servers section under Step 3 and
click Edit.

In the Infrastructure Server Setup window, select DNS on the left-hand side to view the
NRPT settings of the DirectAccess deployment. The last row will show an asterisk (*) on
the left-hand side, right-click this row and select new. In the DNS Server Addresses
window, enter the public hostname of the DirectAccess server as the DNS suffix (for
example, DA.contoso.com), don't attempt to detect or validate the suffix. Instead leave
the rest of the information blank and click apply.

This will create an entry with a Name Suffix and no DNS Server Address, telling the
clients to use their own internet DNS to resolve that name. Finish the Infrastructure
setup process and update the GPO by clicking Finish in the Remote Access Setup
window. Apply the new GPO to the clients and attempt to resolve the hostname of the
DirectAccess server.

More information
DirectAccess clients use multiple methods to connect to the DirectAccess server, which
enables access to internal resources. Clients have the option to use either Teredo, 6to4,
or IP-HTTPS to connect to DirectAccess. This also depends on how the DirectAccess
server is configured.

When the DirectAccess client has a public IPv4 address, it will try to connect by using
the 6to4 interface. However, some ISPs give the illusion of a public IP Address. What
they provide to end users is a pseudo public IP address. What this means is that the IP
address received by the DirectAccess client (a data card or SIM connection) might be an
IP from the public address space, but in reality is behind one or more NATs.

When the client is behind a NAT device, it will try to use Teredo. Many businesses such
as hotels, airports, and coffee shops do not allow Teredo traffic to traverse their firewall.
In such scenarios, the client will fail over to IP-HTTPS. IP-HTTPS is built over an SSL (TLS)
TCP 443-based connection. SSL outbound traffic will most likely be allowed on all
networks.

Having this in mind, IP-HTTPS was built to provide a backup connection that is reliable
and always reachable. A DirectAccess client will make use of this when other methods
(such as Teredo or 6to4) fail.

More information about transition technologies can be found at IPv6 Transition

Technologies .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Diskshadow error when you try to
create a VSS snapshot
Article • 12/26/2023

This article describes an issue that triggers an error message when you try to create a
Volume Shadow Services (VSS) diskshadow snapshot.

Applies to: Windows Server 2012 R2

Original KB number: 3025158

Symptoms
When you open an administrator command prompt and create a VSS diskshadow
snapshot in Windows Server 2012 R2, the output may contain an error:

Commands:

Console

DISKSHADOW> add volume c:

DISKSHADOW> create

Output:

COM call "lvssObject4->GetRootAndLogicalPrefixPaths" failed.

Cause
This error occurs when the backup operation reaches a point, where it tries to process
the boot configuration data (BCD) store data. BCD store is in the system partition. But
because this partition isn't in the list of mounted devices, the error is triggered.

Resolution
This particular COM call failure message is harmless. Despite the message, the
shadowcopy backup is completed successfully. So, no resolution is required.

More information
Microsoft is aware of this issue and will continue to investigate for future updates.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to enable the Volume Shadow
Copy service's debug tracing features in
Windows Server 2003 and Windows
Server 2008
Article • 12/26/2023

This article describes how to enable the Volume Shadow Copy service's debug tracing
features in Windows Server 2003 and Windows Server 2008.

Applies to: Windows Server 2012 R2

Original KB number: 887013

） Important

This article contains information about how to modify the registry. Make sure to
back up the registry before you modify it. Make sure that you know how to restore
the registry if a problem occurs. For more information about how to back up,
restore, and modify the registry, see Windows registry information for advanced
users .

Steps to enable the Volume Shadow Copy

service's debug tracing features

７ Note

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall your operating system. Microsoft cannot guarantee that these problems
can be solved. Modify the registry at your own risk.

To enable the Volume Shadow Copy service's debug tracing features in Windows Server
2003 and Windows Server 2008, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
 2. In Registry Editor, locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS

3. In the left pane, right-click VSS, point to New, and then click Key.

4. Type Debug, and then press ENTER.

5. In the left pane, right-click Debug, point to New, and then click Key.

6. Type Tracing, and then press ENTER.

7. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

8. Type TraceLevel, and then press ENTER.

9. Double-click TraceLevel, and then type ffffffff in the Value data box. That is, type f
eight times in the Value data box. Click OK.

７ Note

The TraceLevel registry entry determines the type of debug tracing that will
occur. A value of 0 (the default) indicates that no tracing will occur. A value of
ffffffff turns on tracing for all events.

10. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

11. Type TraceEnterExit, and then press ENTER.

12. Double-click TraceEnterExit, type 1 in the Value data box, and then click OK.

７ Note

The TraceEnterExit registry entry determines whether the entry and exit
information of the function is output to the trace file and to the debug output
stream. A value of 0 (the default) indicates that no entry and exit information
of the function is output. A value of 1 indicates that the entry and exit
information of the function is output.

13. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

14. Type TraceToFile, and then press ENTER.

15. Double-click TraceToFile, type 1 in the Value data box, and then click OK.
 ７ Note

The TraceToFile registry entry determines whether trace information is output

to the trace file. A value of 0 (the default) indicates that no trace information is
output to the trace file. A value of 1 indicates that the trace information is
output to the trace file. If you set the value to 1, you must also set the
TraceFile registry entry. To set the TraceFile registry entry, follow these steps:
a. In the left pane, right-click Tracing, point to New, and then click String
Value.
b. Type TraceFile, and then press ENTER.
c. Double-click TraceFile, type c:\trace.txt in the Value data box, and then click
OK.

The TraceFile registry entry cannot be stored on the disk where the shadow
copy is created.

16. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

17. Type TraceToDebugger, and then press ENTER.

18. Double-click TraceToDebugger, type 1 in the Value data box, and then click OK.

７ Note

The TraceToDebugger registry entry determines whether trace information is

output to the debug output stream. A value of 0 (the default) indicates that
no trace information is output to the debug output stream. A value of 1
indicates that the trace information is output to the debug output stream.

19. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

20. Type TraceTimeStamp, and then press ENTER.

21. Double-click TraceTimeStamp, type 1 in the Value data box, and then click OK.

７ Note

The TraceTimeStamp registry entry determines whether the time stamp

information is output to the trace file and to the debug output stream. A
 value of 0 (the default) indicates that no time stamp information is output. A
value of 1 indicates that the time stamp information is output.

22. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

23. Type TraceFileLineInfo, and then press ENTER.

24. Double-click TraceFileLineInfo, type 1 in the Value data box, and then click OK.

７ Note

The FileLineInfo registry entry determines whether the module file name
information and the line number information are output to the trace file and
to the debug output stream. A value of 0 (the default) indicates that no
module file name information and no line number information are output. A
value of 1 indicates that the module file name information and the line
number information are output.

25. In the left pane, right-click Tracing, point to New, and then click DWORD Value.

26. Type TraceForceFlush, and then press ENTER.

27. Double-click TraceForceFlush, type 1 in the Value data box, and then click OK.

７ Note

The TraceForceFlush registry entry determines whether a forced flush occurs

after each trace message is written to the trace file. A value of 0 (the default)
indicates that no forced flush occurs. A value of 1 indicates that a forced flush
occurs. When a forced flush occurs, no trace records are ever lost, but
computer performance is greatly reduced.

28. Quit Registry Editor.

For more information about the Volume Shadow Copy service, visit the following
Microsoft Web site:

Volume Shadow Copy Service

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you try to do a
system state backup in Windows Server
2008 and Windows Server 2008 R2
Article • 12/26/2023

This article provides a solution to an error that occurs when you try to do a system state
backup to a volume on which the system state file stays.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2
Original KB number: 944530

Symptoms
When you try to do a system state backup to a volume on which the system state file
stays, you receive an error, as mentioned below:

In Windows Server 2008, you receive the following error:

ERROR - The location for backup is a critical volume.

In Windows Server 2008 R2, you receive the following error:

ERROR - The backup storage location is invalid. You cannot use a volume that is
included in the backup as a storage location.

） Important

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, see How to back up and restore the registry
in Windows .

Cause
This behavior occurs because system state backups to critical volumes are blocked in
Windows Server 2008 and Windows Server 2008 R2.
Resolution
You can change the default behavior of Windows Server 2008 and Windows Server 2008
R2 by adding a registry entry. You must also verify that the following prerequisites are
met before you do a system state backup to a critical volume.

Prerequisites to do system state backups to critical

volumes
Make sure that the target volume has no shadow copy before the backup starts.
If a system state backup is stored on a source volume, backup settings should be
configured for full backups. By default, settings are configured for full backups.
Periodically check that no other user or program maintains a shadow copy on the
target volume.
Don't keep volume level backups and system state backups in the same location.
The volume used to store the system state backup needs twice the amount of free
space as the size of the system state backup until the backup completes.

Notes

1. Any writes on target volume with shadow copies will increase the diff area size. If
the diff area is bounded, it may cause deletion of shadow copies.

2. Incremental backups leave shadow copies behind, it will cause side effect as point
1.

3. Backup stores different versions as shadow copies, it will cause side effect as point
1.

Registry entry to enable system state backups to critical

volumes

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft can't guarantee that these problems can
be solved. Modify the registry at your own risk.

To enable the system state backup files to be targeted to critical volumes, you must set
the value of the AllowSSBToAnyVolume registry entry under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\

Set the value of this entry as follows:

Name:AllowSSBToAnyVolume
Data type:DWORD
Value data:1

７ Note

When this value is set to 1, system state backups to any volume are enabled. To
revert to the default behavior, set the value to 0.

More information
The restriction to target the system state backup to any volume is a new feature in
Windows Server 2008 and Windows Server 2008 R2.

If all the previous prerequisites aren't met, you may see shadow-copy loss when you do
a backup. In worst condition, backup itself may fail because of the snapshot from which
backup was taken is becoming lost while writing the backup.

Steps to reproduce the behavior

1. Install Windows Server 2008 or Windows Server 2008 R2.
2. Install the Windows Server Backup feature from the Server Manager snap-in.
3. Do a system state backup by typing the following command at a command
prompt:
wbadmin start systemstatebackup -backuptarget: Drive_Letter:

７ Note

In this command, Drive_Letter represents a critical volume. Examples of a

critical volume include the boot volume and the system volume. Typically, this
critical volume is drive C.

References
Backup and Recovery Overview for Windows Server 2008
 Backup and Recovery Overview for Windows Server 2008 R2

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 3266 or 3013 when you perform a
database backup to disk or tape or a
database restore from disk or tape
Article • 12/26/2023

This article provides helps to solve error 3266 or 3013 that occurs when you perform a
database backup to disk or tape or a database restore from disk or tape.

Applies to: Windows Server 2012 R2

Original KB number: 290787

Symptoms
When you perform a database backup to disk or tape, or a restore from disk or tape, the
following error message may occur:

SQL Server 7.0 Server:

Msg 3266, Level 16, State 1, Line 1

The Microsoft Tape Format (MTF) soft filemark database on backup device
'devicename' cannot be read, inhibiting random access.
Server: Msg 3013, Level 16, State 1, Line 1
Backup or restore operation terminating abnormally.

SQL Server 2000 Server:

Msg 3266, Level 16, State 1, Line 1

The backup data in 'devicename' is incorrectly formatted. Backups cannot be
appended, but existing backup sets may still be usable.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

SQL Server 2005 Server:

Msg 3013, Level 16, State 1, Line 1

The backup data at the end of 'devicename' is incorrectly formatted. Backup sets on
the media might be damaged and unusable. To determine the backup sets on the
media, use RESTORE HEADERONLY. To determine the usability of the backup sets,
run RESTORE VERIFYONLY. If all of the backup sets are incomplete, reformat the
 media using BACKUP WITH FORMAT, which destroys all the backup sets.
Server: Msg 3013, Level 16, State 1, Line 1

BACKUP DATABASE is terminating abnormally.

Cause
A filemark in the backup device could not be read. There are many reasons why you may
encounter a filemark error. Some of the reasons include the following:

A media failure may occur on the device where the backup is located.

A write failure may occur during the creation of the backup.

For example, a loss of connectivity may occur during a network backup. Or, a
failure of the IO path to flush the write to disk may occur after the write to disk was
reported to SQL server as successful.

Workaround
To allow SQL Server to perform new backups to the backup device, you must manually
delete or erase the device by using the following command:

SQL

BACKUP DATABASE mydatabase TO DISK='C:\MyDatabase.bak' with FORMAT

If the error message occurs during a restore operation, it may be possible to retrieve
other backup sets from the device by specifying the file number. For example, if three
(3) backups were on one (1) backup device, backup sets 1 and 2 may be usable. To
determine if multiple backup sets are on a device, run the following code from Query
Analyzer:

SQL

RESTORE HEADERONLY FROM DISK='C:\MyDatabase.bak'

Each backup set has one entry in the output. To indicate a specific backup set, use this
code:

SQL
 RESTORE DATABASE mydatabase FROM DISK='C:\MyDatabase.bak' WITH FILE =
FileNumber

７ Note

FileNumber is the backup set number you want to restore.

More information
The following list contains important notes regarding backups and SQL Server.

After SQL Server detects a filemark error on a device, SQL Server does not write
additional information to the device.

SQL Server stores all backups in the Microsoft Tape Format, whether the backup is
made to disk or to tape. The Microsoft Tape Format uses filemarks to hold
information such as the block size and the number of blocks in a backup, in
addition to other information about the backup. The Microsoft Tape Format also
uses filemarks to delimit backups in a backup device. The fact that a filemark is
missing or is damaged, suggests that at least one backup on the device is not
valid.

Although you may be able to restore some backup sets from the damaged device,
you must verify the integrity of the restored database.

SQL Server logs details of success or of failure during a backup operation or a

restore operation in the SQL Server error log and in the backup history tables in
the msdb system database.

If you experience an error 3266 when you restore a transaction log or a database
backup, investigate the following logs for more information:
SQL Server error log
Backup and restore history tables
Application event log
System event log

If there are no details of the failure in these logs, you may have experienced an
unreported failure. You should contact Microsoft Product Support Services if you need
help.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

"VSS Error XML document is too long.
hr = 0x80070018" error when you
perform a backup in Windows
Article • 12/26/2023

This article provides a solution to an error that occurs when you perform a backup in
Windows.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 3098315

Symptoms
When you perform a backup in Windows Server 2012 and earlier (back to Windows
Server 2008), one of the following errors is logged in the Application log:

Log Name: Application

Source: VSS
Event ID: 8193
Level: Error
Description:
Volume Shadow Copy Service error: Unexpected error calling routine
XML document is too long. hr = 0x80070018, The program issued a command but
the command length is incorrect.

Operation: Writer Modifying Backup Document

Context: Execution
Context: Requestor
Writer Instance ID: {14BE9B90-62D7-4A2D-B57F-53D21EAB0789}

Cause
When a Volume Shadow Copy Service (VSS)-based backup is performed, each of the
subscribed VSS writers is queried for a list of components. The problem that's described
in the Symptoms section occurs when that list generates a metadata file that's larger
than the size limitation.

Common causes:
 Too many files in the TemporaryInternetFiles directory-specifically, in
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\TemporaryInternetFiles. This
causes the System Writer to hit the size limit of the VSS metadata file.
VSS Writer has added too many components to its metadata file.

Resolution
If there are too many files in TemporaryInternetFiles, back up and then delete the files
from the C:\Windows\Microsoft.NET\Framework64\v2.0.50727\TemporaryInternetFiles
location. Then, the system writer should be able to complete without errors.

If you can't identify the writer that's causing the failure, collect a sample of the writer
metadata document, and then review the components for each writer.

To collect VSS writer metadata, follow these steps:

1. From an administrative command prompt, run the following commands:

Console

diskshadow /l
C:\Metadata.txt
list writers detailed
Exit

2. After the file that's generated is collected, review and count each writer's
components.

3. After the application writer is identified, reduce the number of components until
the limitation is no longer exceeded.

Example of application components

Each component is represented by the lines between the "+ Component" name and the
"- Component Dependencies:" reference. And each is counted as one component.

Hyper-V example

"Microsoft Hyper-V VSS Writer:\006F792F-99EA-4A4A-A241-F8853A3B0CB6"

- Name: 006F792F-99EA-4A4A-A241-F8853A3B0CB6
- Logical path:
- Full path: \006F792F-99EA-4A4A-A241-F8853A3B0CB6
- Caption: Offline\i$
- Type: VSS_CT_FILEGROUP [2]
 - Is selectable: TRUE
- Is top level: TRUE
- Notify on backup complete: FALSE
- Components:
- File List: Path = D:\Hyper-V\Virtual Machines\, Filespec = 006F792F-99EA-4A4A-
A241-F8853A3B0CB6.xml
- File List: Path = D:\Hyper-V\Snapshots, Filespec = A544BB47-0349-4EED-ABDC-
DFE66CAF2927.xml
- File List: Path = D:\Hyper-V\Snapshots\A544BB47-0349-4EED-ABDC-
DFE66CAF2927, Filespec = *
\ Paths affected by this component:
- D:\Hyper-V\Snapshots
- D:\Hyper-V\Snapshots\A544BB47-0349-4EED-ABDC-DFE66CAF2927
- D:\Hyper-V\Virtual Machines\
- Volumes affected by this component:
- \\?\Volume{9710864d-1433-11e5-93ef-806e6f6e6963}\ [D:\]

SQL example:

- Component Dependencies:SQL - + Component "SqlServerWriter:\SQL2012\model"

- Name: model
- Logical path: SQL2012
- Full path: \SQL2012\model
- Caption:
- Type: VSS_CT_FILEGROUP [2]
- Is selectable: TRUE
- Is top level: TRUE
- Notify on backup complete: TRUE
- Components:
- File List: Path = C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\
MSSQL\DATA, Filespec = model.mdf
- File List: Path = C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\DATA, Filespec = modellog.ldf
- Paths affected by this component:
- C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA
- Volumes affected by this component:
- \\?\Volume{e18ba371-5b9e-11e4-9400-806e6f6e6963}\ [C:\]
- Component Dependencies:
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use the backup feature to back
up and restore data
Article • 12/26/2023

This step-by-step article describes how to use the Backup feature to back up and restore
data on your Windows Server 2003-based computer.

Applies to: Windows Server 2003

Original KB number: 326216

Summary
This article is intended for users who back up and restore data, and it includes
information about how to back up and restore the system configuration and local
registry.

To perform the procedures in this article, you must be logged on as a member of the
Administrators group or the Backup Operators group.

Backing up the server

You can manually back up data or use the Backup Wizard, which is included in the
Backup feature. You can back up the whole contents of the server, selected portions of
the server, or the system state data (the system configuration information).

To back up selected files or folders

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

3. Click the Backup tab.

4. On the Job menu, click New.

5. Expand the drive or folder that contains the items that you want to back up. Click
to select the check boxes next to the files, folders, or drives that you want to back
up.
 6. In the Backup destination box, specify the destination for the new job. To do so,
do one of the following:

If you want to back up files and folders to a file, click File.

If you want to back up to tape, click a tape device.

７ Note

If a tape device is not connected to your computer, File is the only backup
media type that is available in the Backup destination box.

7. In the Backup media or file name box, do one of the following:

If you're backing up to a file, specify a path and file name for the backup
(.bkf) file. Or, click Browse, specify a file name and location where you want to
save the file, and then click Save.
If you're backing up to tape, click the tape that you want to use.

8. On the Tools menu, click Options. Specify any additional backup options that you
want on the appropriate tabs of the Options page. Click OK.

9. Click Start Backup.

10. If you want to set advanced backup options, such as data verification or hardware
compressions, click Advanced. Specify the options that you want, and then click
OK.

11. Review the settings on the Backup Job Information page. Specify whether you
want this backup to replace the information that is already present on the
destination media, or add this backup to the existing information.

12. Click Start Backup.

To back up the system state (including registry settings)

To back up the system state (including the registry hives system, software, security, the
Security Accounts Manager (SAM), and the default user (but not
HKEY_CURRENT_USER)), follow these steps:

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

 3. Click the Backup tab.

4. On the Job menu, click New.

5. Click to select the System State check box.

6. Click to select the check boxes next to any other files, folders, or drives that you
want to back up.

7. In the Backup destination box, specify the destination for the new job. To do so,
do one of the following:

If you want to back up files and folders to a file, click File.

If you want to back up to tape, click a tape device.

７ Note

If a tape device is not connected to your computer, File is the only backup
media type that is available in the Backup destination box.

8. In the Backup media or file name box, do one of the following:

If you are backing up to a file, specify a path and file name for the backup
(.bkf) file. Or, click Browse, specify a file name and location where you want to
save the file, and then click Save.
If you are backing up to tape, click the tape that you want to use.

9. On the Tools menu, click Options. Specify any additional backup options that you
want on the appropriate tabs of the Options page. Click OK.

10. Click Start Backup.

11. If you want to set advanced backup options, such as data verification or hardware
compressions, click Advanced. Specify the options that you want, and then click
OK.

12. Review the settings on the Backup Job Information page. Specify whether you
want this backup to replace the information that is already present on the
destination media, or add this backup to the existing information.

13. Click Start Backup.

To schedule a backup for a later time or date

You may want to run a backup operation when there's low system usage. However, such
times may be late at night or on weekends. You can schedule backup jobs to run on a
particular day and time.

７ Note

To schedule a backup operation, the Task Scheduler service must be running.

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

3. Click the Backup tab.

4. On the Job menu, click New.

5. Expand the drive or folder that contains the items that you want to back up. Click
to select the check boxes next to the files, folders, or drives that you want to back
up.

6. In the Backup destination box, specify the destination for the new job. To do so,
do one of the following:

If you want to back up files and folders to a file, click File.

If you want to back up to tape, click a tape device.

７ Note

If a tape device is not connected to your computer, File is the only backup
media type that is available in the Backup destination box.

7. In the Backup media or file name box, do one of the following:

If you're backing up to a file, specify a path and file name for the backup
(.bkf) file. Or, click Browse, specify a file name and location where you want to
save the file, and then click Save.
If you're backing up to tape, click the tape that you want to use.

8. On the Tools menu, click Options. Specify any additional backup options that you
want on the appropriate tabs of the Options page. Click OK.

9. Click Start Backup.

 10. Click Schedule.

If a message prompts you to save your current backup selections, click OK. On the
Save As page that appears, specify a name and location where you want to save
the backup, and then click Save.

11. In the Job name box, type a name for the scheduled backup job, and then click
Properties.

12. Click the Schedule tab. In the Schedule Task box, click how frequently you want the
backup job to run, and then in the Start time box, specify a time when you want
the backup to run, and then click OK.

13. On the Set Account Information page that appears, type a user name and
password of the user whom you want to run the scheduled backup for, and then
click OK.

14. Click OK.

The backup job that you scheduled appears on the calendar on the Schedule Jobs
tab. The scheduled backup job automatically starts at the time and data that you
specified.

15. Close the Backup Utility page.

To back up data by using the Backup Wizard

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

3. On the Welcome tab, click Backup Wizard (Advanced). The Backup Wizard starts.
Click Next.

4. Specify what you want to back up, and then click Next.

5. If you selected Back up selected files, drives, or network data in step 4, expand
the drive or folder that contains the items that you want to back up, click to select
the check boxes next to the drive, folder, or file that you want to back up, and then
click Next.

6. Specify the backup type, destination, and name in the appropriate boxes, and then
click Next.
 ７ Note

If a tape drive isn't connected to your computer, File is the only backup media
type that is available in the Select the backup type box.

7. Review the settings that appear on the Completing the Backup Wizard page. If
you want to specify advanced backup options, click Advanced, specify the options
that you want, and then click OK.

8. Click Finish.

Restoring data to the server

If a data loss occurs, you can restore your backup data manually or by using the Restore
Wizard, which is included in the Backup feature.

To restore selected files from a file or tape

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

3. Click the Restore and Manage Media tab.

4. Click the media that you want to restore, and then click to select the check boxes
next to the drives, folders, or files that you want to restore.

5. In the Restore file to box, specify the location where you want to restore the files
by doing one of the following:

If you want to restore the files or folders to the same location in which they
were when you backed up the data, click Original location, and then go to
step 7.

If you want to restore the files or folders to a new location, click Alternate
location.

This option preserves the folder structure of the backed-up data.

If you want to restore the files and folders to a single location, click Single
folder.
 6. If you selected Alternate location or Single folder, type the location in which you
want the data to be restored, or click Browse and select the location, and then click
OK.

7. On the Tools menu, click Options. Click the Restore tab, specify the restore option
that you want, and then click OK.

8. Click Start Restore.

9. On the Confirm Restore page that appears, click Advanced if you want to set
advanced restore options, and then click OK.

10. Click OK to start the restore operation.

To restore the system state data (including registry

information)
1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.

2. Click Advanced Mode.

3. Click the Restore and Manage Media tab.

4. In the Items to restore box, expand the media that you want to restore, and then
click to select the System State check box.

5. Click to select the check boxes next to any other drives, folders, or files that you
want to restore.

6. In the Restore file to box, specify the location where you want to restore the files
by doing one of the following:

If you want to restore the files or folders to the same location in which they
were when you backed up the data, click Original location, and then go to
step 8.
If you want to restore the files or folders to a new location, click Alternate
location. This option preserves the folder structure of the backed-up data.
If you want to restore the files and folders to a single location, click Single
folder.

７ Note
 If you do not designate an alternate location for the restored data, the restore
operation erases the current system state data and replaces it with the
information that you are restoring.

7. If you selected Alternate location or Single folder, type the location in which you
want the data to be restored, or click Browse and select the location.

8. Click Start Restore.

9. On the Confirm Restore page that appears, click Advanced if you want to set
advanced restore options, and then click OK.

10. Click OK to start the restore operation.

To restore backed up data by using the Restore Wizard

1. Click Start, point to All Programs, point to Accessories, point to System Tools, and
then click Backup. The Backup or Restore Wizard starts.
2. Click Advanced Mode.
3. On the Welcome tab, click Restore Wizard (Advanced). The Restore Wizard starts.
Click Next.
4. In the Items to restore box, expand the media that you want to restore, click to
select the check boxes next to the drives, folders, or files that you want to restore,
and then click Next.
5. Review the settings that appear on the Completing the Restore Wizard page. If
you want to specify advanced backup options, click Advanced, specify the options
that you want, and then click OK.
6. Click Finish.

Troubleshooting

You can't back up or restore data

You must be a member of the Administrators group or the Backup Operators group on
the local computer to back up or restore data.

You can't schedule a backup operation

The Task Scheduler service must be running before you can schedule a backup. If the
Task Scheduler service isn't already running, follow these steps to start it:
 1. Click Start, and then click Run.
2. In the Open box, type cmd, and then click OK.
3. At the command prompt, type net start schedule, and then press ENTER.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

No VSS writers are listed when you run
the vssadmin list writers command in
Windows Server
Article • 12/26/2023

This article helps fix an issue where no VSS writers are listed when you run the vssadmin
list writers command and events are logged.

Applies to: Windows Server 2012 R2

Original KB number: 2009550

Symptoms
When you run the vssadmin list writers command in Windows Server, no VSS writers
are listed. Additionally, the following events are logged in the Application log:

Log Name: Application

Source: VSS
Event ID: 22
Level: Error
Description:
Volume Shadow Copy Service error: A critical component required by the Volume
Shadow Copy service is not registered. This might happened if an error occurred
during Windows setup or during installation of a Shadow Copy provider. The error
returned from CoCreateInstance on class with CLSID {faf53cc4-bd73-4e36-83f1-
2b23f46e513e} and Name VSSEvent is [0x80040154, Class not registered].

Log Name: Application

Source: VSS
Event ID: 8193
Level: Error
Description:
Volume Shadow Copy Service error: Unexpected error calling routine
CoCreateInstance. hr = 0x80040154, Class not registered.

If you open the Windows Server Backup snap-in, you receive the following error
message:
 A fatal error occurred during a Windows Server Backup snap-in (Wbadmin.msc)
operation.
Error details:
Unknown error (0x80042302).
Close Wbadmin.msc and then restart it

Cause
This problem occurs because the registry path of the Eventcls.dll file is incorrect.

Resolution
To resolve this problem, follow these steps:

1. Click Start, type regedit in the Search programs and files box, and then press
ENTER.

2. Locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\\{26c409cc-ae86-11d1-b616-
00805fc79216}\EventClasses\\{FAF53CC4-BD73-4E36-83F1-2B23F46E513E}-{00000000-

0000-0000-0000-000000000000}-{00000000-0000-0000-0000-000000000000}

3. Double-click the TypeLib registry value.

4. In the Value Data box, type %systemroot%\system32\EVENTCLS.DLL, and then click

OK.

5. Exit Registry Editor.

6. Click Start, type services.msc in the Search programs and files box, and then press
ENTER.

7. Right-click the following services, one at a time. Click Restart for each service.

COM+ Event System

Volume Shadow Copy

8. Exit the Services snap-in.

9. Open an elevated command prompt, type vssadmin list writers, and then press
ENTER.

10. Verify that the VSS writers are now listed.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Return codes that are used by the
Robocopy utility in Windows Server
2008 or Windows Server 2008 R2
Article • 12/26/2023

This article discusses the return codes that are used by the Robocopy utility in Windows
Server 2008 or Windows Server 2008 R2.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1,
Windows Server 2012 R2
Original KB number: 954404

Introduction
The following table lists and describes the return codes that are used by the Robocopy
utility.

ﾉ Expand table

Value Description

0 No files were copied. No failure was met. No files were mismatched. The files already exist
in the destination directory; so the copy operation was skipped.

1 All files were copied successfully.

2 There are some additional files in the destination directory that aren't present in the
source directory. No files were copied.

3 Some files were copied. Additional files were present. No failure was met.

5 Some files were copied. Some files were mismatched. No failure was met.

6 Additional files and mismatched files exist. No files were copied and no failures were met.
Which means that the files already exist in the destination directory.

7 Files were copied, a file mismatch was present, and additional files were present.

8 Several files didn't copy.

７ Note
 Any value greater than or equal to 8 indicates that there was at least one failure
during the copy operation.

More information
For more information about how to use the Robocopy utility, open a command prompt,
type the following command, and then press ENTER:
Robocopy /?

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Server backup process fails and
"0x80070005" errors are logged in
Windows Server 2012 Essentials
Article • 12/26/2023

This article describes an issue in which an Error [0x80070005] Access is denied error
occurs during a server backup process in Windows Server 2012 Essentials.

Applies to: Windows Server 2012

Original KB number: 2747459

Symptoms
Assume that you try to back up a server that is running Windows Server 2012 Essentials
by using the Windows Server Backup feature. However, the backup operation doesn't
finish, and the following event is logged in the Application log:

Event ID: 547

Description:
The backup operation that started at '?2012?-?03?-?31T07:00:05.748719600Z' has
encountered errors for the volume(s)'F:'. Log of files not successfully backed up
'C:\Windows\Logs\WindowsServerBackup\Backup_Error-31-03-2012_02-00-05.log'.

If you open the log file that is described in the event, you see logs that resemble the
following:

Error in backup of F:$Extend$RmMetadata$TxfLog\ during write: Error [0x80070005]

Access is denied.
Error in backup of F:$Extend$RmMetadata$TxfLog$TxfLog.blf during write: Error
[0x80070005] Access is denied.

Cause
This issue occurs when a drive that uses the NTFS file system is configured for file-level
backup. Because the $RmMetaData directory is NTFS internal data and cannot be
accessed by other process, this issue occurs.
Workaround
To work around this issue, use one of the following methods.

Method 1
Configure the server backup policy on the affected drive as block-level backup. After
you do this, the whole volume is selected for backup.

Method 2
Set a registry key to exclude the files that are mentioned in the event from file-level
backups. These files are used by NTFS, and they can safely be ignored.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base: 322756 How to back up and restore the registry in Windows

1. In Registry Editor, locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBa

ckup

2. Right-Click FilesNotToBackup, point to New, and then click Multi-String Value.

3. Type IgnoreNTFS, and then press Enter.

4. Right-click IgnoreNTFS, and then click Modify.

5. In the Value data box, type \$Extend\* /s.

6. Click OK, and then close Registry Editor.

7. Restart the server.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Reason for System Event Log srv Event
ID: 2012 - While transmitting or
receiving data, the server encountered a
network error
Article • 12/26/2023

This article discusses the system event log srv event ID 2012.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2885205

Summary
Consider the following scenario:

You have a Windows Server 2012-based file server

Windows Server 2003, Windows Server 2003 R2, or Microsoft Windows XP
Professional-based client computers are accessing the file server with SMB v1
protocol
or any other SMB v1 protocol-based computer with third-party CIFS
implementation is accessing the file server

In this scenario, you see multiple events with Source Srv ID 2012 in the system event log:

Log Name: System

Source: srv
Date: <DateTime>
Event ID: 2012
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: FILEsrv.fqdn
Description:
While transmitting or receiving data, the server encountered a network error.
Occasional errors are expected, but large amounts of these indicate a possible error
in your network configuration. The error status code is contained within the
returned data (formatted as Words) and may point you towards the problem.
 <EventData>
<Data>\Device\LanmanServer</Data>
<Binary>0000040001002C0000000000DC07008000000000840100C0000000000000
0000000000000000000034060000</Binary>
</EventData>

In Words
0000: 00040000 002C0001 00000000 800007DC
0008: 00000000 C0000184 00000000 00000000
0010: 00000000 00000000 00000634

Explanation of these 'Words' logged in this event:

800007DC = EVENT_SRV_NETWORK_ERROR,
C0000184 = STATUS_INVALID_DEVICE_STATE, The device is not in a valid state to
perform this request. 00000634 hex = 1588 decimal, this points to line 1588 in Windows
Server 2012 code for downlevel Clients.
This number depends on Operating System, Service Pack and possibly on SRV.SYS Hotfix
level.

Frequently Asked Questions (FAQ):

----------------------------------
Is such Srv 2012 an indicator for a serious error?
No this is an event of type WARNING, typically you can ignore it. See below for some
typical scenarios, where such Event is expected.
Administrators should just ignore the warning.

What should a normal SMB communication look like?

According to CIFS protocol specification ([MS-CIFS]: Common Internet File System (CIFS)
Protocol )
NEGOTIATE DIALECT - SESSION SETUP - TREE CONNECT - TREE DISCONNECT - LOGOFF

After upgrading our file server to Windows Server 2012 we encounter this Event more
often, why?

you have an environment with many downlevel SMB1 clients like Windows XP or
Windows Server 2003.
Unsuccessfully logon attempts (SESSION SETUP Response with error status)
followed by TCP FIN result in Event 2012.
These clients tend to end their last SMB session with a LOGOFF and TREE
DISCONNEcT SMB command, then they terminate the transport session gracefully
with a TCP FIN.
 This sequence of SMB commands is not fully CIFS-compliant, see above, resulting
in Event 2012.

you have an environment with some SAMBA / UNIX / MAC based downlevel SMB1
clients.
These clients often terminate SMB sessions not CIFS conform (omitting a LOGOFF
command), resulting in Event 2012.

downlevel clients with redirected folders on the Windows Server 2012-based file
server are disconnected from the network without a proper shutdown.
The file server sends in such situation TCP KeepAlive packets to inactive clients and
resets the TCP transport connection if there is no more response from the client.

SMB1 clients encounter some network problems (File server is not answering their
outstanding SMB command within one minute (SessTimeout = 60 sec), so the
client won't send a LOGOFF, but terminates the TCP session with RESET and then
establishes a new TCP / SMB session with a new virtual circuit (VcNumber: 0).
The file server was not aware of the clients network issue and scavenges the former
client session as soon as it detects the same SMB1 client IP with SESSION SETUP
(VcNumber: 0) coming in. (this can happen in NAT Scenario for different clients
resulting in same IP address in the file server subnet as well)

More information
For more information about this topic, click the following article number to view the
article on the Microsoft Web:

[MS-CIFS]: Common Internet File System (CIFS) Protocol

Feedback
Was this page helpful?  Yes  No

Provide product feedback

System State Backup fails when an
invalid ImagePath is specified for
services
Article • 12/26/2023

This article describes an issue in which System State Backup fails when an invalid
ImagePath is specified for services.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 968247

Symptom
Windows Server 2008 System State Backup may fail with the following error:

Summary of backup:
Backup of system state failed [<date> <time>]
Log of files successfully backed up
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup <date> <time>.log'
Log of files for which backup failed
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup_Error <date>
<time>.log'
Enumeration of the files failed.
The file name, directory name, or volume label syntax is incorrect.

In the event log, the following errors are logged:

Log Name: Application

Source: Microsoft-Windows-Backup
Event ID: 517
Computer: <computername>
Description: Backup started at <date time> failed with following error code
'2155348237' (Enumeration of the files failed.). Please rerun backup once issue is
resolved.

Log Name: Microsoft-Windows-Backup

Source: Microsoft-Windows-Backup
Event ID: 5
 Computer: <computername>
Description:
Backup started at <date time> failed with following error code '2155348237'.

Cause
The System state backup fails because the ImagePath that is specified by a service
cannot be backed up. Closer inspection of the System log shows that a service is failing
to start, and you receive an error such as the following.

Event Type: Error

Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Description:
The <servicename> service failed to start due to the following error: The system
cannot find the path specified.

Reviewing the ImagePath of the failing service reflects an invalid path or file name.

Resolution
To resolve this issue, follow these steps:

1. Review the System Log to determine the service that will not start.

2. Contact the services software vendor for any known issues and updated
installation package that may resolve the incorrect ImagePath.

3. Select one of the following options:

Option 1: Uninstall the software related to the problematic service. As soon as it is

removed, restart the system state backup.

Option 2: Correct the ImagePath to have a valid path and file name by using
regedit.

７ Note

Because each service will have a unique ImagePath, you may have to contact the
software vendor if the correct path and file name are not obvious.
 ７ Note

The following blog posting includes an example script that can be used to identify
faulty ImagePath statements. This script is provided as-is and without warrantee:

https://blogs.technet.com/b/askcore/archive/2010/06/18/ps-script-for-blog-
enumeration-of-the-files-failed.aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event IDs 12290 and 16387 are logged
when system state backup fails on a
Windows Server 2008-based computer
Article • 12/26/2023

This article provides a solution to an issue where event IDs 12290 and 16387 are logged
when system state backup fails.

Applies to: Windows Server 2012 R2

Original KB number: 968128

Symptoms
When you try to perform a system state Automated System Recovery (ASR) backup on a
Windows Server 2008-based computer, the backup fails, and error messages that
resemble the following are logged in the Application log.

Cause
This problem occurs if the active EISA partition on the computer is a hidden partition.
The ASR writer in Windows Server 2008 doesn't support hidden active partitions. A
hidden EISA partition may be marked as active when a new operating system installation
is complete on a new computer without first completing the manufacturer's initial Out
Of Box Experience (OOBE) program or without first using a disk utility to clear the disk.

This problem doesn't occur on a new computer if the computer manufacturer's OOBE
program has been run before installing Windows. In this scenario, after the OOBE
program is finished, the hidden partition is marked inactive. You can then install
Windows and the backup is completed successfully.

Resolution
To resolve this problem, follow these steps.

1. Click Start, point to Administrative Tools, click Computer Management, and then
click Disk Management.

2. Click the volume that contains the existing Windows Server 2008 installation.
Typically, this is drive C.
 3. Right-click the volume, and then click Mark Partition as Active.

4. Click Yes to confirm the action.

７ Note

In this scenario, the existing installation of Windows cannot start until the
remaining steps are completed.

5. Close Computer Management.

6. Insert the Windows Server 2008 installation DVD into the DVD drive, and then
restart the computer.

7. Select the following options, and then click Next:

Installation language
Time and currency format
Keyboard layout

8. Click Repair your computer.

9. In the System Recovery Options dialog box, click the operating system that you
want to repair, and then click Next.

10. Under Choose a recovery tool, click Command Prompt.

11. At the command prompt, type the following command, and then press ENTER:

Console

copy c:\windows\boot\PCAT\bootmgr c:\bootmgr

12. Type the following command, and then press ENTER:

Console

Attrib +h +s c:\bootmgr

13. Type the following command, and then press ENTER:

Console

Bootrec /fixboot
 14. Type the following command, and then press ENTER:

Console

Bootrec /rebuildbcd

15. Press Y when you are prompted to add the installation to the boot list.

16. Restart the computer.

17. Try the full system state ASR backup again. Confirm that the backup is successful.

More information
If the operating system is installed on a partition that is not located on the same disk as
the hidden active EISA partition, you have to mark a partition as active that is located on
the same drive as the EISA partition. If no other partition exists on the same drive as the
EISA partition, you have to create a partition and mark it as active.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server Backup MMC fails to
open
Article • 12/26/2023

This article provides a solution to an error that occurs when you launch the Windows
Server Backup on Windows Server 2008.

Applies to: Windows Server 2008

Original KB number: 2000779

Symptoms
When launching the Windows Server Backup on Windows Server 2008, the MMC opens
with following message:

A fatal error occurred during a Windows Server Backup snap-in operation.

Error details: The system cannot find the path specified.
Close Windows Server Backup and then restart it.

Cause
The Scheduled backup policy folder in task scheduler is missing or broken. On startup
the wbadmin.msc snap-in queries, the scheduled tasks resulting in an error when they
are missing or otherwise broken.

Resolution
Remove the scheduled tasks that the MMC snap-in is trying to read. Once removed new
schedules can be created.

To remove any scheduled tasks, open an elevated command prompt and run the
following command:

Console

wbadmin disable backup

７ Note
 If you stop the scheduled backups, the disks where you stored the backups cannot
be used again to store backups until they are reformatted (so that all existing
backups are deleted).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

0x80042306 error occurs when
configuring shadow copies for clustered
mount points on another drive in
Windows Server
Article • 12/26/2023

This article helps fix the error 0x80042306 that occurs when you configure Previous
Versions in Windows Server for the clustered disks that are mounted as folders on a
different volume.

Applies to: Windows Server 2012 R2

Original KB number: 2828270

Symptoms
When trying to configure Previous Versions in Windows Server for the clustered disks
that are mounted as folders on a different volume, it may fail. Additionally, you may
receive the following error message:

Failed to create the storage area association.

Error 0x80042306: The shadow copy provider had an error.

Other symptoms you might observe when trying to configure previous versions for a
mount point on another volume:

Cluster Disk goes offline.

Cause
The error occurs because of mismatch in cluster online and offline timeouts. There's a
premature exit after calling resource online/offline.

Workaround
To work around this problem, consider modifying the registry values by following the
steps mentioned below.
 ） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

1. On the Start screen, click the Search tile.

2. Type regedit in the Search window and then double-click regedit.exe.

3. Locate the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings

4. Right-click ClusterOfflineTimeout, and then click Modify.

5. Select Decimal and then type 2000000000 in the Value data box, and then click
OK.

6. Right-click ClusterOnlineTimeout, and then click Modify.

7. Select Decimal and then type 2000000000 in the Value data box, and then click
OK.

8. Exit Registry Editor, and then restart the computer.

７ Note

The Decimal value can be increased as per requirement.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server Backup doesn't start
after you perform a BMR in Windows
Server 2012
Article • 12/26/2023

This article provides a solution to a problem that prevents Windows Server Backup from
starting after you perform a bare metal recovery (BMR).

Applies to: Windows Server 2012 R2

Original KB number: 2961238

Symptoms
Consider the following scenario:

You have a computer that's running Windows Server 2012 or Windows Server 2012
R2.
You're using a UEFI system with two hard disks, and you have EFI System Partition
on your system disk.
You use Windows Server Backup to perform a complete backup.
You then use the backup data to perform a BMR.

However, after the recovery operation is completed, the Windows Server Backup service
cannot be started.

Cause
This problem occurs because the Windows Server Backup engine (Wbengine.exe) does
not handle cases correctly when the EFI system partition location is changed during the
restore.

Resolution
To resolve this issue, Windows Backup must rebuild the catalog to reflect the latest disk
configurations. To trigger this action, follow these steps:

1. Open an administrative command prompt.

2. Run the following command:

 Console

wbadmin delete catalog

3. Restart the Windows Server Backup service, or restart the computer.

The Windows Server Backup service should now run normally.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

References
Learn more about the wbadmin delete catalog command.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You can't delete a file or a folder on an
NTFS file system volume
Article • 12/26/2023

This article describes why can't delete a file or a folder on an NTFS file system volume. It
also provides help to solve this issue.

Applies to: Windows Server 2012 R2

Original KB number: 320081

７ Note

Internally, NTFS treats folders as a special type of file. Therefore, the word file in this
article indicates either a file or folder.

Cause 1: The file uses an ACL

You can't delete a file if the file uses an Access Control List (ACL). To resolve this issue,
change the permissions on the file. You may have to take ownership of the files to
change the permissions.

Administrators have the implicit ability to take ownership of any file, even if they haven't
been explicitly granted any permission to the file. File owners have the implicit ability to
modify file permissions, even if they aren't explicitly granted any permissions to the file.
So, you may have to take ownership of a file, give yourself permissions to delete the file,
and then delete the file.

You can't use certain security tools to display or to

modify permissions because the file has a non-canonical
ACL
To work around this issue, use another tool (for example, a later build of Cacls.exe).

The Access Control Entries (ACEs) in an ACL have a certain preferred sequence
depending on their type. For example, ACEs that deny access typically come before ACEs
that grant access. However, nothing prevents a program from writing an ACL that has
ACEs in any arbitrary sequence. In some earlier versions of Windows, issues occurred
when Windows tried to read these non-canonical ACLs. Sometimes you can't modify
these ACLs correctly by using the Microsoft Windows Explorer graphical security editor.
This issue has been corrected in later versions of Windows. If you experience this issue,
use the most recent version of Cacls.exe. Even if you can't display or edit an ACL in
place, you can write a new ACL to gain access to the file.

Cause 2: The file is being used

You can't delete a file if the file is being used. To resolve this issue, determine the
process that has the open handle, and then close that process.

Depending on how the file is opened, you may not be able to delete a file that's in use.
For example, the file is open for exclusive access instead of shared access. You can use
various tools to determine the processes that have open handles to files whenever you
want.

The symptoms of this issue may vary. You can use the Delete command to delete a file.
But the file isn't deleted until the process that has the file open releases the file.
Additionally, you may not be able to access the Security dialog box for a file that's
pending deletion. To resolve this issue, determine the process that has the open handle,
and then close that process.

Cause 3: File system corruption is preventing

access to the file
You can't delete the file if the file system is corrupted. To resolve this issue, run the
Chkdsk utility on the disk volume to correct any errors.

The following reasons can corrupt the file system and put files in a problematic state:

Bad sectors on the disk

Other faulty hardware
Software bugs

Typical operations may fail in various ways. When the file system detects corruption, it
logs an event to the event log and you typically receive a message that prompts you to
run Chkdsk. Depending on the nature of the corruption, Chkdsk may or may not recover
file data. However, Chkdsk returns the file system to an internally consistent state.

Cause 4: Files exist in paths that are deeper

than MAX_PATH characters
You can't open, edit, or delete a file if there are issues with the file path.

Resolution 1: Use an autogenerated 8.3 name to access

the file
To resolve this issue, you may want to use the autogenerated 8.3 name to access the file.
This resolution may be the easiest resolution if the path is deep because the folder
names are too long. If the 8.3 path is also too long or if 8.3 names have been disabled
on the volume, go to Resolution 2. For more information about disabling 8.3 file names
on NTFS volumes, see How to disable the 8.3 name creation on NTFS partitions .

Resolution 2: Rename or move a deep folder

Rename the folder so that the target files that are deeper than the MAX_PATH no longer
exist. If you do so, start at the root folder or any other convenient place. Then rename
folders so that they have shorter names. If this step doesn't resolve this issue, for
example, if a file is more than 128 folders deep, go to Resolution 4.

Resolution 3: Map a drive to a folder in the structure of

the path
Map a drive to a folder inside the structure of the path of the target file or folder. This
method shortens the virtual path.

For example, suppose you have a path that is structured as follows:

\\ServerName\SubfolderName1\SubfolderName2\SubfolderName3\SubfolderName4\...

In this path, the total character count is over 255 characters. To short the length of this
path, to 73 characters, map a drive to SubfolderName4.

Resolution 4: Use a network share that is as deep as the

folder
If resolutions 1, 2, and 3 aren't convenient or don't resolve the issue, create a network
share that's as deep in the folder tree as you can. Then rename the folders by accessing
the share.

Resolution 5: Use a tool that can traverse deep paths

Many Windows programs expect the maximum path length to be shorter than 255
characters. These programs only allocate enough internal storage to handle these
typical paths. NTFS doesn't have this limit, and it can hold much longer paths.

You may experience this issue if you create a share at some point in your folder
structure that's already fairly deep, and then create a deep structure below that point by
using the share. Some tools that operate locally on the folder tree may not be able to
traverse the whole tree starting from the root. You may have to use these tools in a
special way so that they can traverse the share. The CreateFile API documentation
describes a method to traverse the whole tree in this situation.

Typically, you can manage files by using the software that creates them. If you have a
program that can create files that are deeper than MAX_PATH , you can typically use that
same program to delete or manage the files. You can typically delete files that are
created on a share by using the same share.

Cause 5: The file name includes a reserved

name in the Win32 name space
If the file name includes a reserved name in the Win32 name space, such as lpt1, you
can't delete the file. To resolve this issue, use a non-Win32 program to rename the file.
You can use a POSIX tool or any other tool that uses the appropriate internal syntax to
use the file.

Additionally, you can use some built-in commands to bypass the typical Win32 reserved
name checks if you use a particular syntax to specify the path of the file.

If you open a handle to a file by using the typical Win32 CreateFile mechanism, certain
file names are reserved for old-style DOS devices. For backward compatibility, these file
names aren't permitted, and they can't be created by using typical Win32 file calls. This
issue isn't a limitation of NTFS.

You can use a Win32 program to bypass the typical name checks that are done when a
file is created or deleted by using the same technique that you use to traverse folders
deeper than MAX_PATH . Additionally, some POSIX tools aren't subject to these name
checks.

Cause 6: The file name includes an invalid name

in the Win32 name space
You can't delete a file if the file name includes an invalid name. For example, the file
name has a trailing space or a trailing period, or the file name is made up of a space
only. To resolve this issue, use a tool that uses the appropriate internal syntax to delete
the file. You can use the "\\?\" syntax with some tools to operate on these files. Here's
an example:

Console

del "\\?\c:\<path_to_file_that contains a trailing space.txt>"

The cause of this issue is similar to Cause 4. If you use typical Win32 syntax to open a
file that has trailing spaces or trailing periods in its name, the trailing spaces or periods
are stripped before the actual file is opened. For example, you have two files in the same
folder named AFile.txt and AFile.txt , note the space after the file name. If you try to
open the second file by using standard Win32 calls, you open the first file instead.
Similarly, if you have a file whose name is just a space character and you try to open it
by using standard Win32 calls, you open the file's parent folder instead. In this situation,
if you try to change security settings on these files, you either may not be able to do so,
or you may unexpectedly change the settings on different files. If this behavior occurs,
you may think that you have permission to a file that actually has a restrictive ACL.

Combinations of causes
Sometimes, you may experience combinations of these causes. It can make the
procedure to delete a file more complex. For example, if you log on as the computer's
administrator, you may experience a combination of Cause 1 (you don't have
permissions to delete a file) and Cause 5 (the file name contains a trailing character that
causes file access to be redirected to a different or nonexistent file), and you can't delete
the file. If you try to resolve Cause 1 by taking ownership of the file and adding
permissions, you still may not be able to delete the file, because the ACL editor in the
user interface can't access the appropriate file due to Cause 6.

In this situation, you can use the Subinacl utility with the /onlyfile switch (this utility is
included in the Resource Kit) to change ownership and permissions on a file that's
otherwise inaccessible. Here's an example:

Console

subinacl /onlyfile "\\?\c:\<path_to_problem_file>" /setowner=

domain\administrator /grant= domain\administrator=F
 ７ Note

This command is a single command line it has been wrapped for readability.

This sample command line modifies the C:\<path_to_problem_file> file that contains a
trailing space so that the domain\administrator account is the owner of the file and this
account has full control over the file. You can now delete this file by using the Del
command with the same "\\?\" syntax.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Change in the behavior of the format
command in Windows Vista and later
versions
Article • 12/26/2023

This article discusses a change in the behavior of the format command in Windows Vista
and later Windows versions.

Applies to: Windows Server 2012 R2, Window 10 – all editions

Original KB number: 941961

Introduction
The behavior of the format command changed in Windows Vista and later Windows
versions. By default in Windows Vista and later versions, the format command writes
zeros to the whole disk when a full format is performed. In Windows XP and earlier
versions of Windows, the format command doesn't write zeros to the whole disk when a
full format is performed.

The new format behavior may cause problems for the on-demand allocation modes that
a volume storage provider, such as a Storage Area Network (SAN), supports. Problems
may occur because the new format behavior prematurely triggers allocation of the
backing space.

In the on-demand scenario, zeros don't have to be written to the whole disk because
the volume storage provider initializes the on-demand-allocated data. To avoid causing
unnecessary on-demand-allocation, you must use the quick format option.

Quick format option

You can use four methods to format a volume in Windows Vista and later versions. You
can use the quick format option for these four methods:

Command line: Use the format /q command.

Diskpart: Use the format command together with the quick parameter.

Windows Explorer: Click to select the Perform a quick format check box.
 Disk Management (Diskmgmt.msc): Click to select the Perform a quick format
check box.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Locate and correct disk space problems
on NTFS volumes
Article • 12/26/2023

This article discusses how to check an NTFS file system's disk space allocation to
discover offending files and folders or look for volume corruption in Microsoft Windows
Server 2003-based computers.

Applies to: Windows Server 2003

Original KB number: 814594

Summary
NTFS supports many volume and file-level features that may lead to what appear to be
lost or incorrectly reported free disk space. For example, an NTFS volume may suddenly
appear to become full for no reason, and an administrator cannot find the cause or
locate the offending folders and files. This may occur if malicious or unauthorized access
to an NTFS volume where large files or a high quantity of small files are secretly copied
has occurred. These files then have their NTFS permissions removed or restricted. This
behavior may also occur after a computer malfunction or power outage occurs that
cause volume corruption.

The disk space allocation of an NTFS volume may appear to be misreported for any of
the following reasons:

The NTFS volume's cluster size is too large for the average-sized files that are
stored there.
File attributes or NTFS permissions prevent Windows Explorer or a Windows
command prompt from displaying or accessing files or folders.
The folder path exceeds 255 characters.
Folders or files contain invalid or reserved file names.
NTFS metafiles (such as the Master File Table) have grown, and you cannot de-
allocate them.
Files or folders contain alternate data streams.
NTFS corruption causes free space to be reported as in use.
Other NTFS features may cause file-allocation confusion.

The following information can help you to optimize, repair, or gain a better
understanding of how your NTFS volumes use disk space.
Cluster size is too large
Only files and folders that include internal NTFS metafiles like the Master File Table
(MFT), folder indexes, and others can consume disk space. These files and folders
consume all the file space allocations by using multiples of a cluster. A cluster is a
collection of contiguous sectors. The cluster size is determined by the partition size
when the volume is formatted.

For more information about clusters, see Default cluster size for NTFS, FAT, and exFAT .

When a file is created, it consumes a minimum of a single cluster of disk space,

depending on the initial file size. When data is later added to a file, NTFS increases the
file's allocation in multiples of the cluster size.

To determine the current cluster size and volume statistics, run a read-only chkdsk
command from a command prompt. To do so, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. At the command prompt, type the command: chkdsk d: .

Where d: is the letter of the drive that you want to check.

3. Click OK.

4. View the resulting output. For example:

4096543 KB total disk space. <--- Total formatted disk capacity.

2906360 KB in 19901 files. <--- Space used by user file data.
6344 KB in 1301 indexes. <--- Space used by NTFS indexes.
0 KB in bad sectors. <--- Space lost to bad sectors.
49379 KB in use by the system. <--- Includes MFT and other NTFS metafiles.
22544 KB occupied by the log file. <--- NTFS Log file - (Can be adjusted using
chkdsk /L:size)
1134460 KB available on disk. <--- Available FREE disk space

4096 bytes in each allocation unit. <--- Cluster Size. (4K)

1024135 total allocation units on disk. <--- Total Clusters on disk.
283615 allocation units available on disk. <--- Available free clusters.

７ Note
 Multiply each value that the output reports in kilobytes (KB) by 1024 to determine
accurate byte counts. For example: 2906360 x 1024 = 2,976,112,640 bytes. You can
use this information to determine how your disk space is being used and the
default cluster size.

To determine whether this is the optimal cluster size, you must determine the wasted
space on your disk. To do so, follow these steps:

1. Click Start, click My Computer, and then double-click the drive letter (for example,
D) of the volume in question to open the volume and display the folders and files
that the root contains.

2. Click any file or folder, and then click Select All on the Edit menu.

3. With all the files and folders selected, right-click any file or folder, click Properties,
and then click the General tab.

The General tab displays the total number of files and folders on the whole volume
and provides two file size statistics: SIZE and SIZE ON DISK.

If you are not using NTFS compression for any files or folders contained on the volume,
the difference between SIZE and SIZE ON DISK may represent some wasted space
because the cluster size is larger than necessary. You may want to use a smaller cluster
size so that the SIZE ON DISK value is as close to the SIZE value as possible. A large
difference between the SIZE ON DISK and the SIZE value indicates that the default
cluster size is too large for the average file size that you are storing on the volume.

You can only change the cluster size you are using by reformatting the volume. To do
this, back up the volume, and then format the volume by using the format command
and the /a switch to specify the appropriate allocation. For example: format D: /a:2048
(This example uses a 2-KB cluster size).

７ Note

Alternately, you can enable NTFS compression to regain space that you lost
because of an incorrect cluster size. However, this may result in decreased
performance.

File attributes or NTFS permissions

Both Windows Explorer and the directory list command dir /a /s display the total file
and folder statistics for only those files and folders that you have permissions to access.
By default, Files hidden files and protected operating system files are excluded. This
behavior may cause Windows Explorer or the dir command to display inaccurate file and
folder totals and size statistics.

To include these types of files in the overall statistics, change Folder Options. To do so,
follow these steps:

1. Click Start, click My Computer, and then double-click the drive letter (for example:
D) of the volume. This opens the volume and displays the folders and files that the
root contains.
2. On the Tools menu, click Folder Options, and then click the View tab.
3. Select the Show Hidden Files and Folders check box, and then click to clear the
Hide protected operating system files check box.
4. Click Yes when you receive the warning message, and then click the Apply button.
This change permits Windows Explorer and the dir /a /s command to total all
the files and folders that the volume contains that the user has permissions to
access.

To determine the folders and files that you cannot access, follow these steps:

1. At the command prompt, create a text file from the output of the dir /a /s
command.

For example: At the command prompt, type the following command: dir d: /a /s
>c:\d-dir.txt .

2. Start the Backup or Restore Wizard.

a. Click Start, click Run, type ntbackup, and then click OK.
b. Click Advanced Mode.

3. Click Options on the Tools menu, click the Backup Log tab, click Detailed, and
then click OK.

4. In the Backup Utility, click the Backup tab, and then select the check box for the
whole volume that is affected (for example: D:), and then click Start Backup.

5. After the backup is complete, open the backup report and compare folder for
folder the NTBackup log output with the d-dir.txt output that you saved in step 1.

Because backup can access all the files, its report may contain folders and files that
Windows Explorer and the dir command do not display. You may find it easier to use the
NTBackup interface to locate the volume without backing up the volume when you want
to search for large files or folders that you cannot access by using Windows Explorer.

After you locate the files that you do not have access to, you can add or change
permissions by using the Security tab while you view the properties of the file or folder
in Windows Explorer. By default, you cannot access the System Volume Information
folder. You must add the correct permissions to include the folder in the dir /a /s
command.

You may notice folders or files that do not have a Security tab. Or, you may not be able
to re-assign permissions to the affected folders and files. You may receive the following
error message when you try to access them:

D:\folder_name\ is not accessible

Access is denied

If you have any such folders, contact Microsoft Product Support Services for
additional help.

Invalid file names

Folders or files that contain invalid or reserved file names may also be excluded from file
and folder statistics. Folders or files that contain leading or trailing spaces are valid in
NTFS, but they are not valid from a Win32 subsystem point of view. Therefore, neither
Windows Explorer nor a command prompt can reliably work with them.

You may not be able to rename or delete these files or folders. When you try to do so,
you may receive one of the following error messages:

Error renaming file or folder

Cannot rename file: Cannot read from the source file or disk.

Or

Error deleting file or folder

Cannot delete file: Cannot read from the source file or disk.

If you have folders or files that you cannot delete or rename, contact Microsoft Product
Support Services.
NTFS Master File Table (MFT) expansion
When an NTFS volume is created and formatted, NTFS metafiles are created. One of
these metafiles is named the Master File Table (MFT). It is small when it is created
(approximately 16 KB), but it grows as files and folders are created on the volume. When
a file is created, it is entered in the MFT as a File Record Segment (FRS). The FRS is
always 1024 bytes (1 KB). As files are added to the volume, the MFT grows. However,
when files are deleted, the associated FRSs are marked as free for reuse, but the total
FRSs and associated MFT allocation remains. That is why you do not regain the space
used by the MFT after you delete a large number of files, .

To see exactly how large the MFT is, you can use the built-in defragmenter to analyze
the volume. The resulting report provides detailed information about the size and
number of fragments in the MFT.

For example:

Master File Table (MFT) fragmentation

Total MFT size = 26,203 KB
MFT record count = 21,444
Percent MFT in use = 81 %
Total MFT fragments = 4

However, for more complete information about how much space (overhead) the whole
NTFS is using, run the chkdsk.exe command, and then view the output for the following
line:

In use by system.

Currently, only third-party defragmenters consolidate unused MFT FRS records and
reclaim unused MFT allocated space.

Alternate data streams

NTFS permits files and folders to contain alternate data streams. With this feature, you
can associate multiple data allocations with a single file or folder. The use of alternate
data streams on files and folders has the following limitations:

Windows Explorer and the dir command do not report the data in alternate data
streams as part of the file size or volume statistics. Instead, they show only the
total bytes for the primary data stream.
 The output from chkdsk accurately reports the space that a user's data files use,
including alternate data streams.
Disk quotas accurately track and report all data stream allocations that are part of
a user's data files.
NTBackup records the number of bytes backed up in the backup log report.
However it does not show which files contain alternate data streams. It also does
not show accurate file sizes for files that include data in alternate streams.

NTFS file system corruption

In rare circumstances, the NTFS Metafiles $MFT or $BITMAP may become corrupted and
result in lost disk space. You can identify and fix this issue by running the chkdsk /f
command against the volume. Toward the end of chkdsk, you receive the following
message if you must adjust the $BITMAP:Correcting errors in the master file table's
(MFT) BITMAP attribute. CHKDSK discovered free space marked as allocated in the
volume bitmap. Windows has made corrections to the file system.

Other NTFS features that may cause file

allocation confusion
NTFS also supports hard links and reparse points that permit you to create volume
mount points and directory junctions. These additional NTFS features may cause
confusion when you try to determine how much space a physical volume is consuming.

A hard link is a directory entry for a file regardless of where the file data is located on
that volume. Every file has at least one hard link. On NTFS volumes, each file can have
multiple hard links, and therefore a single file can appear in many folders (or even in the
same folder with different names). Because all the links refer to the same file, programs
can open any of the links and modify the file. A file is deleted from the file system only
after all the links to it are deleted. After you create a hard link, programs can use it like
any other file name.

７ Note

Windows Explorer and a command prompt show all linked files as being the same
size, even though they all share the same data and do not actually use that amount
of disk space.
Volume mount points and directory junctions permit an empty folder on an NTFS
volume to point to the root or subfolder on another volume. Windows Explorer and a
dir /s command follow the reparse point, count any files and folders on the destination
volume, and then include them in the host volume's statistics. This may mislead you to
believe that more space is being used on the host volume than what is actually being
used.

In summary, you can use chkdsk output, NTBackup GUI or backup logs, and the viewing
of disk quotas to determine how disk space is being used on a volume. However,
Windows Explorer and the dir command have some limitations and drawbacks when
used for this purpose.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Disk Event ID 154: The IO Operation
failed due to a hardware error
Article • 12/26/2023

This article provides a solution to fix event ID 154 that occurs on a computer that's
connected to a storage array such as Fibre Channel (FC) storage.

Applies to: Windows Server 2012 R2

Original KB number: 2806730

） Important

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, see How to back up and restore the registry
in Windows .

Symptoms
On a Windows Server 2012-based computer that is connected to a storage array such as
Fibre Channel (FC) storage, the event ID 154 is logged in the system event log.

Cause
This behavior can occur for one of the following reasons:

The FC connection dropped a packet somewhere between the Host Bus Adapter
(HBA) and the storage array.
The array controller or a device in the array responded to an I/O request and
indicated that the hardware exceeded hardware-defined time-outs in the array.

Resolution
To resolve this issue, contact the vendor of your adapter, switch, or array to determine
the cause of the dropped FC packets or hardware time-outs.
More information

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft cannot guarantee that these problems can
be solved. Modify the registry at your own risk.

Disk Event 154 is a new system event in Windows Server 2012 that is intended to log
cases in which an FC packet may have been dropped. The intention is to make these
issues more discoverable. A dropped FC frame can have a large effect on user
experience, because the time that the operating system will wait for an I/O operation to
finish is based on the disk.sys TimeOutValue value, and the operating system may seem
to be frozen or to hang while it waits for the I/O operation to finish. After the time-out
value is reached, the disk/class layer will retry the I/O operation eight times. (Each
attempt waits the full amount of the TimeOutValue value).

Currently, we recommend that you set the disk.sys TimeOutValue value as low as
possible. (We recommend that you set it to a value no greater than 20 to 30 seconds).
However, as with any change, the value that you use should be evaluated in a test
environment before you implement that value in production.

The value is global. Therefore, avoid very short time-out values. Otherwise, you may
experience time-out errors in scenarios such as when you are waiting for a sleeping disk
or DVD drive to spin up.

To set the disk.sys TimeOutValue value, follow these steps:

1. Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and
then press Enter.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk

3. Locate TimeOutValue.

4. On the Edit menu, click Modify.

5. In the Value data box, type the desired number of seconds.

6. Exit Registry Editor.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A physical disk resource remains in the
Online Pending status, or the Chkdsk
utility automatically starts to run on a
server that is running Windows Server
2008
Article • 12/26/2023

This article helps fix an issue where various errors messages may be logged when you
bring a physical disk resource online.

Applies to: Windows Server 2012 R2

Original KB number: 977516

Symptoms
When you bring a physical disk resource online on a server that is running Windows
Server 2008, you may experience one of the following symptoms:

Symptom 1
When you view the physical disk resource in the Failover Cluster Management snap-in,
the resource may show a status of Online Pending. Additionally, the following error
message is logged in the System log:

Log Name: System

Source: Microsoft-Windows-FailoverClustering
Event ID: 1066
Task Category: Physical Disk Resource
Level: Warning
Description:
Cluster disk resource 'Cluster Disk 3' indicates corruption for volume '\\?
\Volume{ec2fa15d-b438-11de-88bc-00155dd99d36}'. Chkdsk is being run to repair
problems. The disk will be unavailable until Chkdsk completes. Chkdsk output will be
logged to file 'C:\Windows\Cluster\Reports\ChkDsk_ResCluster Disk
3_Disk2Part1.log'.
Chkdsk may also write information to the Application Event Log.
Additionally, the following error message is logged in the Cluster log:

ERR [RES] Physical Disk <Cluster Disk 3>: VerifyFS: Failed to open file \\?
\GLOBALROOT\Device\Harddisk2\Partition1\TextDocument.txt Error: 5.

Symptom 2
When you view the physical disk resource in the Microsoft Cluster Administrator utility,
you may experience one or more of the following symptoms:

The resource may not come online, or it may come online after a brief delay.

The Chkdsk utility together with the /F switch automatically starts to run on the
shared hard disk.

Event ID 1066 that has a description similar to the following appears in the System
log of the Event Viewer:

Cluster resource Disk Y:: is corrupt. Running ChkDsk /F to repair problems.

Cause
These issues occur for one of the following reasons.

Cause of Symptom 1
This issue occurs because a read-only file is located in the root directory of the resource.
When a shared physical disk resource is brought online, the cluster service enumerates
the files of the root directory and tries to open each file together with full access. This
behavior occurs to make sure that the file system is consistent and that the volume is
not corrupted. If any of the files are read-only in the root directory of the resource, the
volume is considered corrupted and Chkdsk is started. To work around this problem, use
the workaround that is mentioned in the Workaround of Symptom 1 section.

Cause of Symptom 2
This issue occurs because the "dirty" flag for the volume is set. When a shared physical
disk resource is brought online, the cluster service enumerates the files of the root
directory and tries to open each file together with full access. This behavior occurs to
make sure that the file system is consistent and that the volume is not corrupted. If any
of the files have the "dirty" flag set in the root directory of the resource, the volume is
considered corrupted and Chkdsk is started. To work around this problem, use the
workaround that is mentioned in the Workaround of Symptom 2 section.

Workaround of Symptom 1
To work around this problem, do one of the following:

Clear the read-only attribute from the files by either viewing the file properties or
by using the attrib -r command at a command prompt.
Move the files that have the read-only attribute from the root directory of the
resource to an appropriate subfolder.

７ Note

If you fail to bring the disk online and perform any further check on the files, please
set the Physical Disk private property DiskRunChkDsk to a property of 4
(ChkDskDontRun). This will disable volume mount checks.

Workaround of Symptom 2
To work around this problem, first determine whether the "dirty" flag for the specified
volume is set.

To determine whether the "dirty" flag is set for the volume in Windows Server 2008, use
the Chkntfs tool.

For more information about the Chkntfs tool, visit the following Microsoft TechNet Web
site:
Chkntfs

To determine whether the "dirty" flag is set for the volume in Windows Server 2008 R2,
use the Validate a Configuration Wizard.

For more information about the Validate a Configuration Wizard, visit the following
Microsoft TechNet Web site:
Validating a Failover Cluster Configuration

If the "dirty" flag is set for the volume, run the Chkdsk utility together with the /F switch.

For more information about the Chkdsk utility, visit the following Microsoft TechNet
Web site:
Chkdsk
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Extending a CSV by using Diskpart or
PowerShell isn't blocked from a non-
coordinator node
Article • 12/26/2023

This article provides a solution to an issue where extending a Cluster Shared Volume by
using Diskpart or PowerShell isn't blocked from a non-coordinator node.

Applies to: Windows Server 2016, Windows Server 2019, Windows Server 2012 R2
Original KB number: 3189825

Symptoms
Consider the following scenario:

You have a failover cluster that has a Cluster Shared Volume (CSV) configured.
You have to extend the CSV volume.
From a non-coordinator node, you use the Diskpart command or a Windows
PowerShell cmdlet to extend the volume.

In this scenario, the extend process is completed successfully. However, the Capacity
section of the Disk Management console continues to show the old disk size value from
before the extend process. In the Cluster GUI, the disk view shows the correct extended
size but the volume size reflects the old values.

Additionally, you can't reduce the extended volume. If you try to do this, the process
fails and you may receive the following error message:

Wrong parameter

Cause
This problem occurs because an extend write operation causes the Cluster Shared
Volumes File System (CSVFS) to extend all or some of the following values:

File allocation size

File size
Valid data length
A read operation could cause the CSVFS to query some information from NTFS. On the
coordinator node, the CSVFS forwards metadata IO directly to the NTFS volume, but
other nodes use the Server Message Block (SMB) to forward the metadata over the
network.

In the Cluster GUI, you may notice that the Extend Volume option is greyed out on a
non-coordinator node.

Resolution
To resolve this problem, don't run any metadata operation from a non-coordinator
node.

More information
For more information about clustering and high-availability, see the following Failover
Clustering and Network Load-Balancing Team Blog article:

Cluster Shared Volume (CSV) Inside Out

Workaround
To work around this problem, increase the disk space that's allocated to the CSV. To do
this, extend the disk on the CSV owner node (coordinator node) by using the Cluster
GUI, the Diskpart tool, or Windows PowerShell.

７ Note

After you extend the disk, all displayed disk sizes and capacity values are updated
to the correct size.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set the Partmgr Attributes
registry value by using PowerShell
Article • 12/26/2023

This article describes how to set the Partmgr Attributes registry value by using
PowerShell.

Applies to: Windows Server 2012 R2

Original KB number: 2849097

Summary
The partmgr.sys Attributes registry key affects the online behavior of a given disk, and
the value corresponds to the SAN policy values in VDS as documented on
VDS_SAN_POLICY enumeration.

C++

typedef enum _VDS_SAN_POLICY {

VDS_SP_UNKNOWN = 0x0,
VDS_SP_ONLINE = 0x1,
VDS_SP_OFFLINE_SHARED = 0x2,
VDS_SP_OFFLINE = 0x3
} VDS_SAN_POLICY;

This value is initially set when a disk is identified based on the SAN Policy value in place
at the time. The SAN policy determines whether a newly discovered disk is brought
online or remains offline, and whether it is made read/write or remains read-only. When
a disk is offline, the disk layout can be read, but no volume devices are surfaced through
Plug and Play (PnP). This means that no file system can be mounted on the disk. When a
disk is online, one or more volume devices are installed for the disk.

This policy can be viewed by using the DISKPART utility as follows:

1. Click Start, click Run, type cmd, and then press ENTER.
2. In the command-line window, type diskpart, and then press ENTER.
3. Type SAN , and then press ENTER. This command will return the current set SAN
policy.
4. Type exit , and then press ENTER.
Setting a value of 0 ( VDS_SP_UNKNOWN ) will be mapped to VDS_SP_ONLINE , so a value of 0
or 1 may be used to bring a disk online.

This script modifies the Attributes registry value located at

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\SCSI\<device>\<instance>\Device

Parameters\Partmgr .

For more information about how to write scripts for Windows PowerShell, see General
information about how to write scripts for Windows PowerShell .

Registry information

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

The vendor string variable is used to restrict the value change to a subset of disks
matching a specific vendor's identifier. Check the registry for the Disk&Ven_ string to
verify what value should be used.

PowerShell

$val = 0
$vendor = Read-Host "Enter Vendor String"
$devIDs = Get-ChildItem
"HKLM:\SYSTEM\CurrentControlSet\Enum\SCSI\Disk*Ven_$vendor*\*\Device
Parameters\"

foreach ($id in $devIDs)

{
$error.Clear()
$regpath = $id.PSPath + "\Partmgr\"
Set-ItemProperty -path $regpath -Name Attributes -Value $val -
ErrorAction SilentlyContinue

if ($error) # didn't find the path, create it and try again

{
New-Item -Path $id.PSPath -Name Partmgr
Set-ItemProperty -path $regpath -Name Attributes -Value $val -
ErrorAction SilentlyContinue
 $error.Clear()
}

Get-ItemProperty -Path $regpath -Name Attributes -ErrorAction

SilentlyContinue | Select Attributes | fl | Out-String -Stream
}

Feedback
Was this page helpful?  Yes  No

Provide product feedback

System logs multiple events that specify
Event ID 640
Article • 12/26/2023

This article provides some information about Event ID 640.

Applies to: Windows Server 2019, Windows Server 2016, Windows 10 - all editions
Original KB number: 4577004

Symptoms
The Application log lists many ESENT events that specify Event ID 640 in Windows 10,
Windows Server 2019, and Windows Server 2016.

Cause
Event ID 640 indicates that the Extensible Storage Engine (ESE) has detected that a
database file and its flush map file are not synchronized. This situation occurs rarely. It is
caused by one of the following conditions:

The database was moved, but not all the required files were moved together with
it.
The sector that hosts the flush map's header is corrupted. This condition is
exceptionally rare.
An existing ESE database was deleted and then re-created, but its flush map file
was not deleted or re-created. This discrepancy typically occurs when an
application migrates its data from one ESE database to another ESE database, and
the application does not clean up correctly. Such migrations may be more frequent
during or shortly after Windows upgrades. After the new database is created, the
system detects the old flush map file. That file is not synchronized with the new
database. In this scenario, there is no risk to the data in the new database. The
condition is benign.

Status
A future release of Windows is expected to include a change that prevents the system
from logging Event ID 640 in the benign case.
Determine the cause of Event ID 640
To determine the cause of Event ID 640, examine the "...FromDb" fields in the event data,
and consider the following situations:

All or some of these fields are not initialized and, therefore, have values of zero. In
this case, Event ID 640 was caused by the creation of a new database. This is a
benign case. You do not have to take any action to mitigate it.

All the "...FromDb" fields have non-zero values. In this case, you should investigate
the problem.

The "...FromDb" fields appear in bold in the following example of an event log entry:

services (836,D,35) Error -1919 validating header page on flush map file '<Drive>:\
<Path>\<FileName>.jfm'. The flush map file will be invalidated. Additional
information: [SignDbHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0
Computer:] [SignFmHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0
Computer:] [SignDbHdrFromFm:Create time:<DateTime> Rand:559408839
Computer:] [SignFmHdrFromFm:Create time:<DateTime> Rand:4291821429
Computer:]

７ Note

In this example, <Drive>:\<Path>\<FileName> represents the actual path and

name of the flush map file.

About Event ID 636

If Windows logs Event ID 640 in the benign case, it may also log Event ID 636. In this
case, you can also ignore Event ID 636.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Data corruption and disk errors
troubleshooting guidance
Article • 12/26/2023

Data corruption and disk errors cover different areas such as issues about accessing a
drive, drive corruption, and slow performance.

The following Event IDs indicate that there's data corruption or a disk error:

Event ID 153

The IO operation at logical block address 123456 for Disk 2 was retried.

Event ID 129

Reset to device, \Device\RaidPort1, was issued.

Event ID 157

Disk 2 has been surprise removed.

Event ID 55

The file system structure on the disk is corrupt and unusable. Please run the
chkdsk utility on the volume.

Event ID 98

Volume C: (\Device\HarddiskVolume3) needs to be taken offline to perform a

Full Chkdsk. Please run "CHKDSK /F" locally via the command line or run
"REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

Troubleshooting checklist

７ Note

This article describes commands that need to be run at an elevated command

prompt.
 In the System event log, search for New Technology File System (NTFS) and disk-
related warnings and errors. For example, Event ID 55, 153, or 98.

Run the chkdsk /scan command and check the result.

７ Note

The chkdsk /scan command is read-only.

Query a drive for NTFS-specific volume information by running the following

command:

fsutil fsinfo ntfsinfo <rootpath>:

７ Note

The placeholder <rootpath> represents the drive letter of the root drive.

Run the fsutil dirty query <volumepath>: command to check if the volume is
dirty.

７ Note

The placeholder <volumepath> represents the drive letter.

For a volume whose file system is NTFS, run the chkdsk /f /r command if the
volume is dirty. The chkdsk /F /R command needs downtime because the disk
won't be accessible.

For a volume whose file system is Resilient File System (ReFS), the disk
corruption will be repaired automatically.

If the "chkdsk" utility doesn't fix the disk errors, perform a restore from a backup.

Run a storage validation to check if there are any storage-related errors.

Remove the disks from the cluster and check the operating system level.

Run the chkdsk /f command on all volumes that the event is logged for.

Update third-party storage drivers or firmware.

If the issue persists, try the following methods:

 Uninstall any third-party disk managing software (for example, Diskeeper).

Remove or update filter drivers.

Contact the hardware vendor and run hardware diagnostics to avoid the possibility
of any hardware issues.

Get in touch with the storage vendor to check the multipathing configuration.

Update the SCSI port or the RAID controller drivers.

Switching to different types of drivers. For example, RAID controller drivers or

monolithic drivers.

Update the Host Bud Adapter (HBA) drivers.

Update the multipathing drivers of device-specific modules (DSM).

Update the HBA firmware.

Troubleshooting Event ID 153

Event ID 153 indicates that there's an error with the storage subsystem. Event ID 153 is
similar to Event ID 129, but the difference is that Event ID 129 is logged when the
Storport driver times out a request to the disk, and Event ID 153 is logged when the
Storport miniport driver times out a request. The miniport driver may also be referred to
as an adapter driver or HBA driver, which is typically written by the hardware vendor.

If Event ID 153 or Event ID 129 is logged, disk I/O timeout is the common cause because
the storage controller can't handle the load. In this case, the I/O operation times out,
and the miniport driver (from a vendor) sends back the messages to the Storport driver
(the last Microsoft storage driver in the stack). Then, the Storport driver translates the
information and logs the event in the Event Viewer.

Because the miniport driver has sufficient knowledge of the request execution
environment, some miniport drivers time the request themselves instead of letting the
Storport driver handle request timing. The miniport driver can abort an individual
request and return an error, whereas the Storport driver resets the drive after a timeout.
Resetting the drive is disruptive to the I/O subsystem and may not be necessary if only
one request has timed out. The miniport driver returns the error to the class driver that
logs Event ID 153 and retries the request.

Here's an example of Event ID 153:

Output
 Log Name: System
Source: disk
Event ID: 153
Level: Warning
Description: The IO operation at logical block address 123456 for Disk 2 was
retried.

This event indicates that a request failed and was retried by the class driver. No error
message was logged in this situation because the Storport driver didn't time out the
request. The lack of messages resulted in confusion when troubleshooting disk errors
because there was no evidence of the error.

On the Details tab of the event log, the detailed information shows the error that
caused the retry and whether the request was a Read or Write request. For example:

Output

0000: 0004010F 002C0003 00000000 80040099

0010: 00000000 00000000 00000000 00000000
0020: 00000000 00000000 28090000

in bytes

0000: 0F 01 04 00 03 00 2C 00 ......,.
0008: 00 00 00 00 99 00 04 80 ......
0010: 00 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 00 00 09 28 ...*

In this example, the byte offset 29 shows the SCSI status, the byte offset 30 shows the
SCSI request block (SRB) status that caused the retry, and the byte offset 31 shows the
SCSI command that is being retried. In this case, the SCSI status is 00 ( SCSISTAT_GOOD ),
the SRB status is 09 ( SRB_STATUS_TIMEOUT ), and the SCSI command is 28 ( SCSIOP_READ ).

Here are the most common SCSI commands:

Output

SCSIOP_READ - 0x28
SCSIOP_WRITE - 0x2A

See scsi.h for a list of SCSI operations and statuses.

Here are the most common SRB statuses:

 Output

SRB_STATUS_TIMEOUT - 0x09
SRB_STATUS_BUS_RESET - 0x0E
SRB_STATUS_COMMAND_TIMEOUT - 0x0B

See srb.h for a list of SRB statuses.

７ Note

The timeout errors ( SRB_STATUS_TIMEOUT or SRB_STATUS_COMMAND_TIMEOUT )

indicate that a request is timed out in the adapter. A request was sent to the
drive, and there was no response within the timeout period.

The bus reset error ( SRB_STATUS_BUS_RESET ) indicates that the device was reset
and the request is being retried because of the reset since all incomplete
requests are aborted when a drive receives a reset.

An administrator needs to verify the health of the disk subsystem. Although an

occasional timeout may be part of the normal operation of a system, the frequent retry
requests indicate a performance issue with storage that should be fixed.

More information
Because the issue is normally outside the operating system, check the following
common causes:

Some type of throttling is configured, such as I/O limitations. Sometimes, Storage

I/O Control in VMware causes this issue.

Too many drives with a high load are on the same storage controller. Therefore the
drives need to be split among different controllers.

If Multipath I/O (MPIO) is configured, a single cable or a damaged NIC can cause
issues with iSCSI.

Troubleshooting Event ID 129

Event ID 129 is logged with the storage adapter (HBA) driver's name as the source. The
Storport driver (Storport.sys) logs this event when it detects that a request is timed out.
The HBA driver's name is used in the event because it's the miniport driver that is
associated with the Storport driver.

Here's an example of Event ID 129:

Output

Event Type: Warning

Event Source: <HBA_Name>
Event Category: None
Event ID: 129
Computer: <Computer_Name>
Description: Reset to device, \Device\RaidPort1, was issued.

Information about Windows I/O stack architecture

Windows I/O operation uses a layered architecture where device drivers are on a device
stack. In a basic model, the top of the stack is the file system. The next is the volume
manager, followed by the disk driver. The port and miniport drivers are at the bottom of
the device stack. When an I/O request reaches the file system, it takes the block number
of the file and translates it to an offset in the volume. Then, the volume manager
translates the volume offset to a block number on the disk and passes the request to
the disk driver. When the request reaches the disk driver, it will create a command
descriptor block (CDB) and send it to the SCSI device. The disk driver embeds the CDB
into the SCSI_REQUEST_BLOCK (SRB) structure. This SRB is sent to the port driver as part
of the I/O request packet (IRP).

The port driver does most of the request processing. There are different port drivers
depending on the architecture. For example, the ATA port driver (Ataport.sys) and the
SCSI port driver (Storport.sys). Here are some responsibilities of a port driver:

Providing timing services for requests

Enforcing queue depth to make sure that a device doesn't have more requests
than it can handle

Building "scatter" and "gather" arrays for data buffers

The port driver interfaces with the miniport driver, and the miniport driver is designed
by the hardware vendor to work with a specific adapter. It's responsible for taking
requests from the port driver and sending them to the target logical unit number (LUN).
The port driver calls the HwStorStartIo() function to send requests to the miniport
driver, and the miniport driver will send the requests to the HBA driver so that they can
be sent over the physical medium (Fibre or Ethernet) to the LUN. When the request is
completed, the miniport driver will call the StorPortNotification() function with the
NotificationType parameter with a value set to RequestComplete , along with a pointer

to the completed SRB.

When a request is sent to the miniport driver, the Storport driver will put the request in
a pending queue, and it's timed. When the request is completed, it's removed from this
queue.

The timing mechanism is simple. There's one timer per logical unit, and it's initialized to
-1 . When the first request is sent to the miniport driver, the timer is set to the timeout

value in the SRB. The disk timeout value is a tunable parameter that's located under the
following registry key:

HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

Some hardware vendors will tune this value to best match their hardware. Don't change
this value without guidance from your storage vendor.

The timer is decremented once per second. When a request is completed, the timer is
refreshed with the timeout value of the head request in the pending queue. Therefore,
the timer will never go to zero as long as requests complete. If the timer goes to zero, it
means that the device has stopped responding. For example, when the Storport driver
logs Event ID 129, the Storport driver has to take corrective action by trying to reset the
unit. When the unit is reset, all incomplete requests are completed with an error, and
they're retried. When the pending queue is cleared, the timer is set to -1 , which is the
initial value.

Each SRB has a timer value set. When requests are completed, the queue timer is
refreshed with the timeout value of the SRB at the head of the list.

The most common causes of Event ID 129 are unresponsive LUNs or a dropped request.
Dropped requests can be caused by faulty routers or other hardware problems on the
storage area network (SAN).

Troubleshooting Event ID 157

This event indicates that the Classpnp.sys driver has received a surprise removal request
from the plug and play manager (PNP) for a non-removable disk.

This issue most often occurs when something disrupts the system's communication with
a disk, such as a SAN fabric error or a SCSI bus problem. The errors can also be caused
by a disk that fails or when a user unplugs a disk while the system is running. In this
case, an administrator needs to verify the heath of the disk subsystem.
Troubleshooting Event ID 55 and 98
If NTFS events such as Event ID 55, 50, 140, and 98 are logged, you need to run the
"chkdsk" utility.

Because NTFS couldn't write data to the transaction log, this could affect the ability of
NTFS to stop or roll back the operations in which the transaction data couldn't be
written.

Here's an example of Event ID 55:

Output

Event Type: Error

Event Source: NTFS
Event ID: 55
Description: The file system structure on the disk is corrupt and unusable.
Please run the chkdsk utility on the volume.

Usually, Event ID 55 is logged when file system corruption occurs. The file system
corruption occurs when one or more of the following issues occur:

A disk has bad sectors.

I/O requests that are delivered by the file system to the disk subsystem aren't
completed successfully.

Most issues are hardware-related, and hardware may be corrupted unexpectedly. You
can try the following methods to fix the issues:

Update the SCSI port or the RAID controller drivers.

Remove or update filter drivers.

Update third-party storage drivers or firmware.

Switching to different types of drivers. For example, RAID controller drivers or

monolithic drivers.

Rearrange hardware into various combinations.

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Microsoft policy for disk duplication
of Windows installations
Article • 12/26/2023

This article describes the SID and supported methods for cloning or duplicating a
Windows installation.

Applies to: Supported versions of Windows Server and Windows Client

Original KB number: 314828

Summary
When you deploy a duplicated or imaged Windows installation, it is required that the
System Preparation (Sysprep) tool is used before the capture of the image. Sysprep
prepares an installation of Microsoft Windows for duplication, auditing, and customer
delivery. For Windows 2000, Windows XP, and Windows Server 2003, Sysprep is included
with the latest service pack Deploy.cab. For later versions of Windows, Sysprep is
included with the operating system, and Sysprep is located in the folder:
%windir%\system32\sysprep .

More information
Sysprep is responsible for removing system-specific data from Windows, such as the
Computer SID. During installation of Windows, a computer SID is computed to contain a
statistically unique 96-bit number. The computer SID is the prefix of the user account
and group account SIDs that are created on the computer. The computer SID is
concatenated together with the Relative ID (RID) of the account to create the account's
unique identifier.

The following example displays the SIDs for four local user accounts. Only the last four
digits are incremented as new accounts are added.

HKEY_USERS on local machine

S-1-5-21-191058668-193157475-1542849698-500 Administrator S-1-5-21-191058668-

193157475-1542849698-1000 User 1a S-1-5-21-191058668-193157475-1542849698-
1001 User 2 S-1-5-21-191058668-193157475-1542849698-1002 User 3

Cloning or duplicating an installation without taking the recommended steps could lead
to duplicate SIDs. For removable media, a duplicate SID might give an account access to
files even though NTFS permissions for the account specifically deny access to those
files. Because the SID identifies both the computer or domain and the user, unique SIDs
are necessary to maintain support for current and future programs. For more
information about issues that might occur if you clone an installation of Windows 8 or
of Windows Server 2012, go to the Windows 8 and Windows Server 2012 specific
information section.

In addition to the computer SID, many other components and features must be cleaned
up, generalized, or specialized in order to be imaged. Some examples include the
following:

Event logs
Network settings
Windows Media player settings
Shell settings
Licensing

７ Note

This is not a comprehensive list.

We support the following operating systems that are prepared by using the Sysprep
utility and then imaged:

Windows NT Workstation 4.0

Windows NT Server 4.0 (stand-alone server, not primary domain controllers or
backup domain controllers)
Windows 2000 Professional
Windows 2000 Server (must be imaged before you run DCPromo)
Windows 2000 Advanced Server
Windows XP Home Edition
Windows XP Professional
Windows Server 2003, Standard Edition
Windows Server 2003, Datacenter Edition
Windows Server 2003, Enterprise Edition
Windows Server 2003, Web Edition
All versions of Windows Vista
All versions of Windows Server 2008
All versions of Windows 7
All versions of Windows Server 2008 R2
All versions of Windows 8
 All versions of Windows Server 2012
All versions of Windows 10
All versions of Windows Server 2016
All versions of Windows Server 2019
All versions of Windows Server 1903
All versions of Windows Server, version 1909
All versions of Windows 11

We do not provide support for computers that are set up by using SID-duplicating tools
other than the System Preparation tool. For example, this includes the following:

NewSID
GhostWalker

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

７ Note

If an image was created without using Sysprep, we do not support the running of
Sysprep after the image is deployed as a way to bring the computer back into
compliance. Sysprep must be run before the capture of the image.

Windows 8 and Windows Server 2012 specific

information
If you clone a Windows 8 or Windows Server 2012 image or virtual machine without
running sysprep.exe /generalize , P2V and keep the physical computer up and running
or create a backup of a computer but keep the original computer running you may
experience issues in which push notifications do not work. For example, you may
experience the following issues:

Tile, badge, and toast notifications do not update even though Internet
connectivity is available.
Apps that rely on RAW notification do not work as expected. For example, you
notice significantly reduced functionality in Mail, Calendar, and Messaging.
It takes a long time to synchronize changes for roaming and family safety settings.
To resolve these issues, use one of the following methods:
Configure the computers by using the Sysprep /generalize command, and then
deploy the image.
 Replace the existing user account with a new account. The device identifier is
stored as part of the user profile. Each new NTUser account that is added to a
computer will receive a new identifier.

References
For more information about the Windows System Preparation Tool, visit the following
Microsoft websites:

Windows Server 2003 What Is Sysprep?

Windows 8 and Windows Server 2012 Sysprep Overview

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SMB Read Andx requests for files
managed by Data Deduplication error in
Windows Server 2012: The request is not
supported
Article • 12/26/2023

This article helps fix the errors that occur in SMB Read Andx requests for files managed
by Data Deduplication.

Applies to: Windows Server 2012 R2

Original KB number: 2817216

Symptoms
Server: Windows Server 2012 RTM, with volume setting [x] Enable data deduplication
SMB v1 Clients: Windows XP SP3, third-party CIFS clients (Macintosh, Unix Samba)

Windows XP clients are unable to open files on Server 2012 shares.

Only deduped files (with the size >32 KB) aren't accessible on the volume, expanded
files are accessible.

Error messages may vary depending on type of access and application accessing file on
Server 2012 share with Data Deduplication.

Explore: Copy file

An unexpected error is keeping you from copying the file. If you continue to
receive this error, you can use the error code to search for help with this
problem.

Error 0x80070032: The request is not supported.

or

Error Copying File or Folder

Cannot copy <filename>: Cannot read from the source file or disk.

or
 Cannot copy <filename>: The request is not supported.

Office: Microsoft Excel'

filename.xls' cannot be accessed. The file may be read-only, or you may be

trying to access a read-only location. Or, the server the document is stored on
may not be responding.

or

Could not open 'filename.xls'.

Microsoft Word

Could not open 'filename.doc'.

Adobe: Open recent file

There was on error opening this document. Access Denied.

Navisworks

Autodesk Navisworks Simulate 2011

Couldn't load <filename.nsd> because the contents are corrupt

Access Denied

ERROR_ACCESS_DENIED

Access is denied.

Network trace shows STATUS_NOT_SUPPORTED for SMB1 Read Andx requests:

1819 <DateTime> XPclient 2012Srv SMB NT Create AndX Request, FID: 0xc003, Path:
\Test-Dedup-file.pdf
1820 <DateTime> 2012Srv XPclient SMB NT Create AndX Response, FID: 0xc003
AllocationSize: 0
EndOfFile: 51362
1829 <DateTime> XPclient 2012Srv SMB Read AndX Request, FID: 0xc003, 32768 bytes
at offset 0
1830 <DateTime> 2012Srv XPclient SMB Read AndX Response, FID: 0xc003, 0 bytes,
Error: STATUS_NOT_SUPPORTED
NTStatus: 0xC00000BB, Facility = FACILITY_SYSTEM, Severity =
STATUS_SEVERITY_ERROR, Code = (187) STATUS_NOT_SUPPORTED

Error code 0xc00000bb = STATUS_NOT_SUPPORTED

or 0x80070032 = ERROR_NOT_SUPPORTED = The request is not supported.

７ Note

Same action on a Windows 7 client with SMBv2 protocol works

tested on Windows 7 client with SMB2: OK

tested on Windows 7 client with SMB1: failed (SMB2 disabled using info from
KB
How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows

Workaround
Server 2012 without volume setting [ ] Enable data deduplication

Start-DedupJob E: -Type UnOptimization

Deduplication Cmdlets in Windows PowerShell

Windows PowerShell

Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> DedupStatus

Get-DedupStatus - Returns a DeduplicationStatus object for every volume that has data
deduplication metadata.
Get-DedupSchedule - Returns the DeduplicationJobSchedule objects defined on the
system.
Get-DedupJob - Returns status and information for currently running or queued
deduplication jobs.
Update-DedupStatus - Scans one or more specified volumes to compute fresh data
deduplication savings information and returns a DeduplicationStatus object.
get the latest status of the unoptimization job by running the Get-DedupJob PowerShell
command

Reported on:

Windows 2012 Deduplication - Access share from Windows XP / 7

Cause
Interoperability issue of components Dedup, SMB, and Non-Default entry EnableECP in
Server registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Paramet
ers
EnableAuthenticateUserSharing REG_DWORD 0x0
ServiceDllUnloadOnStop REG_DWORD 0x1
ServiceDll REG_EXPAND_SZ %SystemRoot%\system32\srvsvc.dll
NullSessionPipes REG_MULTI_SZ
autodisconnect REG_DWORD 0xf
enableforcedlogoff REG_DWORD 0x1
enablesecuritysignature REG_DWORD 0x0 //default = 0x1
requiresecuritysignature REG_DWORD 0x0
restrictnullsessaccess REG_DWORD 0x1
Lmannounce REG_DWORD 0x0
Size REG_DWORD 0x3
AdjustedNullSessionPipes REG_DWORD 0x3
ClusterPipes REG_MULTI_SZ FssagentRpc
CachedOpenLimit REG_DWORD 0x0 //default = 0x5
>> enableecp REG_DWORD 0x1 << //default = 0x0 or not set
Guid REG_BINARY DEF9D10A080B9241932038A7E77DFC2D

７ Note

This is known to happen after you install McAfee ver. 8.8 VirusScan Enterprise +
AntiSpyware Enterprise.
De-installing this product still leaves enableecp=1 behind, so you need to delete
the registry key enableecp manually.

Resolution
We believe that the issue is due to interoperability between three components Dedup,
SMB, and third party like "VMware vShield Endpoint driver (VSEPFLT.SYS)", if the
following registry key had been set manually or by some third party software
installation:

HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\enableecp = 1
To resolve the Deduplication issue:

Delete the Registry entry "EnableECP"

and

1. Reboot

or

2. Restart the Server Service, in elevated CMD window type:

NET STOP SERVER && NET START SERVER

７ Note

it the steps above don't solve the issue: There may be additional application-
related issues:

when Deduped files are accessed using an application like Adobe over SMB, it
may fail.

Adobe confirmed a known issue with Adobe Reader in accessing PDF files on
a Server 2012 with Deduped files.

The issue was fixed by Adobe from 10.3.x. Currently the latest version of
Adobe Reader available is 11.0.

Here is the article about the PDF files server 2012 RTM deduplication causing
PDF file issues

This issue is fixed in version (10.1.4) of Acrobat Reader.

Status as of March 8: Response from McAfee Support: We're actively investigating what
the value "enableecp" is used for in our product and what the impact is (if any) of
reverting this back to 0 or even removing the value altogether.

If the customer relies on data deduplication on server 2012 accessed by XP clients in

their environment, the recommendation for now is, to set the key to 0 as per MSFT
suggestion to guarantee smooth operation of the environment until such times that
we've finished our investigation and come to a conclusion on how to best approach this
issue.

KB77623 - is currently in the pipeline and will be published within the next 5-6 working
days, the KB will be updated as our investigation progresses and more details become
available. It currently contains a general overview of the issue and the workaround
described by MSFT.

March 19: the KB has been published and should be publicly accessible through the
McAfee Knowledgebase . Investigation surrounding the value "enableecp" is on-going.

Windows 7 clients can't access shares on Windows Server 2012 when Data
Deduplication is enabled

More information
Info re. Deduplication on Microsoft Server 2012

Introduction to Data Deduplication in Windows Server 2012

Data Deduplication Overview

Data Deduplication Interoperability

Info on ECP:

What's new in driver development

Extra Create Parameter (ECP) Improvements

Recycling of previously allocated ECPs is new in Windows 8. To avoid the overhead of

freeing an ECP on file close and then allocating a new one later, a file system or file
system filter driver can reuse an existing ECP.

Server & Tools Blogs > Server & Management Blogs > The Storage Team at Microsoft -
File Cabinet

Storage at Microsoft

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Files are corrupted on deduplicated
volumes that were created as NTFS-
compressed
Article • 12/26/2023

This article provides a solution to an issue where files can't be opened and are logged as
corrupted on deduplicated volumes.

Applies to: Windows Server 2012 R2

Original KB number: 3066174

Symptoms
Users can no longer open files on a deduplication-enabled volume that was created by
having NTFS compression enabled at the root of the volume. Additionally, the Data
Deduplication scrubbing job may log an event in the event log to report corruption on
the volume of files that it cannot repair.

Cause
This problem occurs because deduplication metadata that is stored on the compressed
volume root becomes corrupted when a process writes in-place to a file on the
deduplicated volume. The deduplication metadata that is stored on the compressed
volume root is located under the System Volume Information (SVI) folder.

Duplication is not supported on volumes that have compression enabled on the root
when the volume is created. However, deduplication on compressed folders is
supported and functions as expected.

Resolution
To resolve this problem, do not enable data deduplication on an NTFS volume that has
volume-level compression enabled.

Unfortunately, we cannot restore data that is already corrupted on existing compressed

volumes that have deduplication enabled. Files that have already been corrupted must
be restored from backups, if they are available.
To decompress the deduplication metadata folder so that write actions to deduplicated
files on this volume are no longer corrupted, follow these steps.

７ Note

In the example commands, <X> is a volume that has been created as compressed
and that has Data Deduplication enabled.

1. Download the PsExec tool from the following Windows Sysinternals website:
PsExec v2.2

７ Note

The PsExec tool lets users run processes by having "SYSTEM" user rights. This
is necessary to access the protected Data Deduplication metadata folder that
is located in the System Volume Information folder.

2. Block data access for your users on the affected volume. To do this, run the
following Windows PowerShell disable-dedupvolume command:

PowerShell

disable-dedupvolume X: -dataaccess

７ Note

This command dismounts and then remounts the volume without the
data deduplication filter attached. This blocks users from accessing any
deduplicated files.
The dismount action invalidates any open file handles on this volume.

3. Use PsExec to run Cmd.exe as a "SYSTEM" user. To do this, run the following
command:

Console

Psexec.exe -i -s cmd

７ Note
 The Command Prompt window will now open by having "SYSTEM" user rights
assigned.

Ｕ Caution

The "SYSTEM" account is a user account that has a much higher level of
access than an administrator account. Users should be careful to perform only
the steps that are mentioned in the article while they are running the
"SYSTEM" account. Users should be especially careful not to change ACLs or
take ownership of the System Volume Information folder.

4. In the PsExec Command Prompt window, locate the System Volume Information
folder of your affected volume.

5. Verify that the volume's deduplication metadata folder is currently compressed.

6. Decompress the volume's deduplication metadata folder.

7. In the PsExec Command Prompt window, run the following command:

Console

X:\System Volume Information>compact /s:Dedup

The output will include the following summary message:

Of M files within N directories

<X> are compressed and <Y> are not compressed.

If <X> is greater than zero (0), go to step 8. Otherwise, go to step 11 because your
deduplication metadata folder is not compressed.

8. In the PsExec Command Prompt window, run the following command:

Console

X:\System Volume Information>compact /u /s:Dedup

9. Wait for the deduplication metadata folder to be uncompressed. The process

works on one file at a time and can be slow.

７ Note
 The time that is required by this process is proportional to the amount of data
that is on the volume. For volumes that contain terabytes of data, this process
can take several hours to finish. After it finishes, the command exits and
generates the following status message:
N files within M directories were uncompressed.

10. In the PsExec Command Prompt window, run the following "display compression
state" command to verify that there are no compressed files in the Data
Deduplication metadata folder.

Console

X:\System Volume Information>compact /s:Dedup

11. Close the PsExec Command Prompt window.

12. Re-enable data access for your users on the affected volume. To do this, run the
following command:

Console

Enable-DedupVolume X: -DataAccess

７ Note

This command dismounts and then remounts the volume with the data
deduplication filter attached. Users will now be able to access the
deduplicated files.
The dismount action invalidates any open file handles on this volume.

７ Note

To prevent similar corruptions from occurring, perform this procedure on all

deduplication-enabled volumes that were created as compressed.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

Churn from Full Garbage Collection
during deduplication can cause
performance problems in Windows
Server
Article • 12/26/2023

This article provides workarounds for performance problems that are caused by the
churn from full garbage collection during deduplication.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 3066175

Symptoms
Full garbage collection jobs reclaim more free space than "regular" garbage collection.
However, full garbage collection generates much more churn on the volume. This is
because every chunk container is compacted (rewritten) if there are any unreferenced
chunks.

This churn on the volume may cause the following problems and side effects:

Deletion of Volume Shadow Copy Service (VSS) shadow copies

Heavy I/O load on the system, especially if the server is already running a high-
churn or IO-intensive deduplication workload
Increased volume workloads for some solutions (such as incremental backup and
file replication) that grow because of file churn

Cause
This behavior may occur in the following situations:

When a workload includes many file deletes or file in-place writes. This causes
many chunks to become unreferenced. Problems are also triggered by deletes that
cause many chunk containers with old and new chunks to experience compaction.
When a system has relatively little physical free space, NTFS first uses free space
that doesn't cause shadow copy storage-area consumption. If the volume has little
free space, NTFS allocates space for new files in areas that trigger "copy on write"
behavior. When the storage area runs out, VSS deletes the shadow copies.
Workaround
To work around these issues, use one of the following methods:

Configure VSS to use a separate (possibly dedicated) volume for its diff area
("shadow storage area"). You can do this by using Vssadmin.exe and other tools.
This workaround helps with the shadow-copy deletion issue.

７ Note

There are other performance benefits to having the diff area on dedicated
volumes.

Configure deduplication not to run Full GC but to run garbage collection only in
regular mode. By default, garbage collection jobs are scheduled to run weekly.
Also by default, every fourth garbage collection job is set to run in Full GC (on a
monthly cadence).

７ Note

You can run Full GC on demand by manually running the following Windows
PowerShell command:

Start-DedupJob <volume> -Type GarbageCollection -Full

To prevent Full GC, configure the following registry key:

HKLM\System\CurrentControlSet\Services\ddpsvc\Settings /v DeepGCInterval /t
REG_DWORD /d 0xffffffff

If the system is clustered, you will have to configure the following registry key instead:
HKLM\CLUSTER\Dedup\ /v DeepGCInterval /t REG_DWORD /d 0xffffffff

This workaround helps to reduce all the side effects that are described in the
"Symptoms" section. However, regular-mode garbage collection is not as thorough as
Full GC. Some unreferenced deduplication chunks may not be reclaimed if the system
never runs Full GC. Nevertheless, regular-mode garbage collection should still reclaim
more than 95 percent of unreferenced data.

On a system that's running Windows Server 2012, make sure that hotfix 2897997 is
installed. (This is not necessary for Windows Server 2012 R2.)
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Known issues after you enable data
deduplication on CSV
Article • 12/26/2023

This article describes some known issues that may occur after you enable data
deduplication on CSV.

Applies to: Windows Server 2012 R2

Original KB number: 2906888

Summary
Data deduplication in Windows Server 2012 R2 supports optimization of storage for
Virtual Desktop Infrastructure (VDI) deployments and optimization of Cluster Shared
Volumes (CSV). Data deduplication is supported on NTFS-formatted CSV and is not
supported on Resilient File System (ReFS)-formatted CSV.

Known Issues
Issue 1

The LastWriteTime property of a file is changed to the time when the file is
processed by a data deduplication optimization job. Additionally, the archive bit of
the file is reset when the data deduplication optimization job is finished.

This behavior does not affect production performance or limit access to the files
that are stored on the CSV. However, this behavior may affect some backup
applications that use the archive bit or the LastWriteTime property to detect
incremental changes of files. For example, when the file properties are changed by
a data deduplication optimization job, the backup application may be triggered to
back up the files again.

Issue 2

When you use the Update-DedupStatus cmdlet to query a data deduplication job
status on a CSV volume from a passive (non-coordinator) cluster node, you receive
an error that resembles the following:

Update-DedupStatus : MSFT_DedupVolumeStatus.Volume='<CSV volume

path>' - HRESULT 0x80565364, 0x80565304, 0x8056536B
 Additionally, you receive one of the following error messages:

Data deduplication cannot run this job on this CSV volume on this node. Try
running the job on the CSV volume resource owner node.

Data deduplication cannot run this cmdlet on this CSV volume on this node.
Try running the cmdlet on the CSV volume resource owner node.

This behavior is expected because the job status can be queried only from the
coordinator node. To obtain the status of the data deduplication job, log on to the
coordinator node, and then run the Update-DedupStatus cmdlet.

More information
Data deduplication was introduced in Windows Server 2012. Enabling data
deduplication reduces the number of duplicate blocks of data in the storage so that
more data can be stored. Data deduplication is highly scalable, resource efficient, and
nonintrusive and can run on dozens of large volumes of primary data at the same time
and yet have only a minimal effect on the server workload. For more information, see
Data Deduplication Overview and About Data Deduplication.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 10013 (WSAEACCES) is returned
when a second bind to an excluded port
fails in Windows
Article • 12/26/2023

This article provides help to solve an issue where you can't bind an excluded port again
even though the SO_REUSEADDR option is set.

Applies to: Windows Server 2012 R2

Original KB number: 3039044

Symptoms
Assume that you exclude a port by running the following command on a computer that
is running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2:

Console

netsh int ipv4 add excludedportrange protocol = tcp startport = Integer

numberofports = 1

Additionally, assume that you bind the SO_REUSEADDR socket to a specific TCP port on
the computer. In this situation, when you try to bind the SO_REUSEADDR socket to the
TCP port again, the bind fails, and you receive the "WSAEACCES (10013)" error.

Therefore, if you use an application that calls the two binds in Windows Server 2012 R2,
Windows Server 2012, or Windows Server 2008 R2, it cannot work correctly.

７ Note

By default, Windows Server 2008 R2 cannot use the netsh command to

exclude ports. However, after you apply hotfix 2665809 , the operating
system supports this function.
This issue does not occur in Windows Server 2008 or Windows Server 2003.

Cause
This issue occurs because of a problem in the tcpip.sys driver. Specifically, the REUSE
flag was overwritten by the RESERVED flag when the tcpip.sys driver binds an excluded
port.

Workaround
To work around this issue, use one of the following methods:

Use a port that is not included in the default dynamic port range (from 49,152 to
65,535), and do not specify the port as an excluded port by running the netsh
command.
Use the CreatePersistentTcpPortReservation and
LookupPersistentTcpPortReservation functions to reserve a port.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

More information
See the setsockopt function to know more about the SO_REUSEADDR option.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

File Server Resource Manager could not
load WMI objects in Windows Server
Article • 12/26/2023

This article helps fix an error that occurs when starting the File Server Resource Manager
in Windows Server.

Applies to: Windows Server 2012 R2

Original KB number: 2831687

Symptoms
When starting the File Server Resource Manager in Windows Server, you may receive the
following error message:

File Server Resource Manager could not load WMI objects on "Server Name".

If you query the MSFT_FSRMSettings WMI class under root\Microsoft\Windows\FSRM

while having the described error reported, you may then receive the following WMI
error:

Error 0x80041001 (Generic failure).

Cause
This problem occurs because the Windows Management Instrumentation service is
restarted after the FSRM Service and a new provider load/registration for the FSRM
provider is needed.

Resolution
To resolve this problem, restart the FSRM Service.

If you notice this is a reoccurring issue, there are two actions needed:

Verify and investigate the Windows Management Instrumentation Service is restart

issue to solve the behavior.
Add a dependency for the FSRM Service in the registry, so that it gets restarted
when the WMI service is restarted. To add the dependency in the registry, follow
 the steps:

1. On the Start screen, click the Search tile.

2. Type regedit in the Search window and then double-click regedit.exe.

3. Locate the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srmsvc

4. From the right-side pane, right-click DependOnService, and then click

Modify.

5. Add WINMGMT to the Multi-String Value.

6. Click OK and then exit the registry editor.

7. Reboot the computer.

More information
In a particular case, the Windows Management Instrumentation is restarted as part of a
WMI Repository Rebuild action. In that case, an investigation would be needed as to
why the WMI Repository is being rebuilt.

If you're running SCCM 2012, ensure that you're not running in the behavior described
in the following article:

Configuration Manager management points fail after the Client Health Evaluation task
runs

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
User Experience issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The FSRM quota usage is incorrect when
you change the size of the page file in
Windows
Article • 12/26/2023

This article provides a workaround for an issue where the File Server Resource Manager
(FSRM) quota usage is incorrect.

Applies to: Windows Server 2012 R2

Original KB number: 3034439

Symptoms
This issue occurs on a computer that is running Windows Server 2012 R2 that has the
FSRM feature enabled.

Cause
This issue occurs because FSRM detects that the size of the page file is excluded in the
FSRM quota.

Workaround
Run the Update-FsrmQuota-path paths command in Windows PowerShell to perform the
scan again and recalculate quota usage information.

Status
This behavior is expected.

References
Dirquota quota
General information about the Update-FsrmQuota cmdlet
Feedback
Was this page helpful?  Yes  No

Provide product feedback

List of currently available hotfixes for the File
Services technologies in Windows Server
2008 and in Windows Server 2008 R2
Article • 12/26/2023

This article lists the hotfixes that are currently available for users who have installed the File
Services technologies on a Windows Server 2008-based computer or on a Windows Server 2008
R2-based computer.

Applies to: Windows 7 Service Pack 1, Windows Server 2008 R2, Windows Server 2008
Original KB number: 2473205

Summary
File Services provides technologies that help you manage storage, enable file replication, manage
shared folders, ensure fast file searching, and enable access for UNIX client computers. This article
also lists the hotfixes that are currently available for users who utilize File Services from Windows
Vista-based computers or from Windows 7-based computers.

This article contains lists of Microsoft Knowledge Base articles that describe the currently available
fixes. The article is divided into two sections. The first section applies to Windows Server 2008 R2
and to Windows 7, and the second section applies to Windows Server 2008 and to Windows
Vista. Each section is divided into subsections for different component drivers: SRV, MRXSMB, and
RDBSS. In general, the SRV drivers should be updated on the server or client computer that is
hosting the data. The MRXSMB and RDBSS drivers should be updated on the server or client
computer that is initiating access to the data. If you are unsure about which component should be
updated on which computer, you can update all three component drivers both on the computer
that is hosting the data and on the computer that is accessing the data.

Windows Server 2008 R2 and Windows 7

NTFS component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base Article recommend availability
this hotfix

Jan/08/2016 3121255 0x00000024 Stop error in This hotfix To apply this

FsRtlNotifyFilterReportChange contains the hotfix, you must
and VSS backup of PI Data server most current have Windows 7
fails in Windows version of SP1 or Windows
ntfs.sys. Server 2008 R2
 Date added Knowledge Title Why we Hotfix type and
Base Article recommend availability
this hotfix

SP1 installed.
(LDR) Available for
individual
download.

SRV component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base Article recommend this availability
hotfix

May/12/2016 3161561 MS16-075 and MS16- This hotfix contains To apply this security
076: Description of the most current update, you must have
the security update version of Windows 7 SP1, or
for Windows srvnet.sys, srv.sys, Windows Server 2008
Netlogon and SMB and srv2.sys. R2 SP1 installed.
Server: June 14, 2016 Available for individual
(LDR) download.

MRXSMB component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base article recommend this availability
hotfix

May/12/2016 3161561 MS16-075 and This security hotfix To apply this security
MS16-076: contains the most hotfix, you must have
Description of the current version of Windows 7 SP1, or
security update for mrxsmb.sys, Windows Server 2008
Windows Netlogon mrxsmb10.sys R2 SP1 installed.
and SMB Server: and mrxsmb20.sys. Available for individual
June 14, 2016 (LDR) download.

RDBSS component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base article recommend this availability
hotfix

Mar/12/2015 3044428 0x00000027 or This hotfix To apply this hotfix, you

0x00000050 Stop error contains the most must have Windows 7
in the Rdbss.sys driver SP1 or Windows Server
 Date added Knowledge Title Why we Hotfix type and
Base article recommend this availability
hotfix

in Windows 7 SP1 or current version of 2008 R2 SP1 installed.

Windows Server 2008 rdbss.sys. (LDR) Available for individual
R2 SP1 download.

Windows Server 2008 and Windows Vista

NTFS component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base Article recommend this availability
hotfix

Jan/02/2015 2928562 Event 55 when you This hotfix To apply this hotfix, you
copy an encrypted contains the most must have Windows Vista
folder to EFS current version of SP 2 Windows Server 2008
shared folder in ntfs.sys. SP2 installed. Available
Windows from Microsoft Update.

SRV component

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base Article recommend this availability
hotfix

May/14/2016 3161561 MS16-075 and This hotfix To apply this security

MS16-076: contains the most update, you must have
Description of the current version of Windows Vista SP2 or
security update for srvnet.sys, srv.sys, Windows Server 2008
Windows Netlogon and srv2.sys. SP2 or later versions
and SMB Server: installed. Available from
June 14, 2016 (GDR/LDR) Microsoft Update.

MRXSMB component

ﾉ Expand table

Date added Knowledge Title Why we recommend Hotfix type and

Base article this hotfix availability

May/14/2016 3161561 MS16-075 and This security hotfix To apply this security
MS16-076: contains the most hotfix, you must have
Description of the current Version of Windows Vista SP 2 or
security update for mrxsmb .sys, Windows Server 2008
 Date added Knowledge Title Why we recommend Hotfix type and
Base article this hotfix availability

Windows Netlogon mrxsmb10 .sys and SP 2 installed.

and SMB Server: mrxsmb20.sys. Available for
June 14, 2016 (LDR/GDR) individual download.

RDBSS component

ﾉ Expand table

Date added Knowledge Title Why we recommend Hotfix type and

Base article this hotfix availability

Jan/07/2015 3000483 MS15-011: This security hotfix To apply this security

Vulnerability in contains the most hotfix, you must have
Group Policy could current version of Windows Vista SP 2 or
allow remote code rdbss.sys for Windows Windows Server 2008
execution: February Vista SP 2 and for SP 2 installed.
10, 2015 Windows 2008 SP 2. Available for individual
(LDR/GDR) download.

More information
Server 2008 R2 Registry keys that have been introduced with hotfixes or security updates:

ﾉ Expand table

Date Knowledge Registry key

Base
article

5/15/2009 971277 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

Level2Compatibility

9/06/2010 2345886 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

SmbServerNameHardeningLevel

7/13/2012 2732618 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

ABELevel

Server 2008 Registry keys that have been introduced with hotfixes or security updates:

ﾉ Expand table

Date Knowledge Registry key

Base
article

10/05/2012 2761551 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

SrvMaxThreadsPerQueue
 Date Knowledge Registry key
Base
article

03/08/2013 2732618 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

ABELevel

Server Message Block (SMB) model

The Server Message Block (SMB) model consists of two entities: the client and the server.

On the client, applications perform system calls by requesting operations on remote files. These
requests are handled by the redirector subsystem (rdbss.sys) and by the SMB mini-redirector
(mrxsmb.sys), both of which translate the requests into SMB protocol sessions and requests over
TCP/IP. Starting with Windows Vista, the SMB 2.0 protocol is supported. The mrxsmb10.sys driver
handles legacy SMB traffic, and the mrxsmb20.sys driver handles SMB 2.0 traffic.

On the server, SMB connections are accepted, and SMB requests are processed as local file
system operations through NTFS and the local storage stack. The srv.sys driver handles legacy
SMB traffic, and the srv2.sys driver handles SMB 2.0 traffic. The srvnet.sys component implements
the interface between networking and the file server for both SMB protocols. File system
metadata and content can be cached in memory via the system cache in the kernel (ntoskrnl.exe).

The following image provides an overview of the different layers through which a user request on
a client computer must go to perform file operations over the network on a remote SMB file
server by using SMB 2.0.

Services for NFS in a Windows Server 2008 R2

environment
Network File System (NFS) Server components 2008 R2

ﾉ Expand table
 Date Knowledge Title Why we Hotfix type and
added Base article recommend this availability
hotfix

12- 3043762 The process cannot This security update To apply this hotfix, you
Mar- access the file error contains the most must have Windows
2015 when you open files current version of Server 2008 R2 SP1
from NFS server in Nfssvc.exe, and installed. Available for
Windows Server 2008 Nfssvr.sys. individual download.
R2 SP1 Available from Microsoft
(LDR) Update.

29- 2957486 Ls command takes a This hotfix contains To apply this hotfix, you
Aug- long time to list shared the most current must have Windows
2014 files in 2 windows on a version of Server 2008 R2, or
Windows 7 or Rpcxdr.sys. (LDR Windows Server 2008 R2
Windows Server 2008 GDR) SP1 installed. Available for
R2-based NFS server individual download.

NFS Client components

ﾉ Expand table

Date added Knowledge Title Why we Hotfix type and

Base article recommend this availability
hotfix

14-May- 2956990 NFS client can't This hotfix contains To apply this hotfix, you
2014 reconnect to NFS the most current must have Windows 7
server in Windows version of Nfsnp.dll, SP1, or Windows Server
7 SP1 or Windows Nfsclnt.exe, and 2008 R2 SP1 installed.
Server 2008 R2 SP1 Nfsrdr.sys. Available for individual
download.

Apr/03/2015 3042826 POSIX subsystem This hotfix contains To apply this hotfix, you
crashes when you the most current must have Windows 7
try to create a version of Psxdll.dll, SP1, or Windows Server
Telnet session in Psxdllsvr.dll, 2008 R2 SP1 installed.
Windows Psxss.exe, Posix.exe. Available for individual
download.

Services for NFS in a Windows Server 2008

environment
NFS Server components

ﾉ Expand table
 Date added Knowledge Title Why we Hotfix type and
Base article recommend this availability
hotfix

Jan/02/2014 2923150 A memory leak This security update To apply this hotfix,
occurs on an NFS contains the most you must have
share server that is current version of Windows Vista SP2 or
running Windows Nfssvc.exe, Windows Server 2008
Server 2008 Nfssvr.sys, and SP2 installed. Available
Msnfsflt.sys. from Microsoft
Update.

Sep/25/2014 2957486 Ls command takes a This hotfix contains To apply this hotfix,
long time to list the most current you must have
shared files in 2 version of Windows Vista SP2 or
windows on a Rpcxdr.sys. Windows Server 2008
Windows 7 or SP2 installed. Available
Windows Server 2008 from Microsoft
R2-based NFS server Update.

Components included in services for NFS

Server for NFS

This component corresponds to the server-side implementation of the NFS file-sharing

protocol. Server for NFS enables a computer that is running Windows Server 2008 R2 to act
as a file server for UNIX-based client computers.

Client for NFS

This component corresponds to the client-side implementation of the NFS file-sharing

protocol. Client for NFS enables a Windows-based computer that is running Windows Server
2008 R2 (or Windows 7) to access files that are stored on a UNIX-based NFS server.

Windows Server 2008 R2 includes both the Server for NFS and Client for NFS components.
However, Windows 7 includes only Client for NFS.

For more information about the step-by-step guide for the services for NFS, see General
information about the step-by-step guide for the services for NFS.

Microsoft Services for NFS provides a file-sharing solution for enterprises that have a mixed
Windows and UNIX environment. This communication model consists of client computers and a
server. Applications on the client request files that are located on the server through the
redirector (Rdbss.sys) and NFS mini-redirector (Nfsrdr.sys). The mini-redirector uses the NFS
protocol to send its request through TCP/IP. The server receives multiple requests from the clients
through TCP/IP and routes the requests to the local file system (Ntfs.sys), which accesses the
storage stack.

References
 List of currently available hotfixes for Distributed File System (DFS) technologies in Windows
Server 2008 and in Windows Server 2008 R2 .

An enterprise hotfix rollup is available for Windows 7 SP1 and Windows Server 2008 R2 SP1

List of currently available hotfixes for the File Services technologies in Windows Server 2012
and in Windows Server 2012 R2

Performance Tuning for File Servers

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you access file shares on a
SOFS-configured server: Not enough
server storage is available to process
this command
Article • 12/26/2023

This article provides a solution to an issue that occurs when you access file shares on a
SMB server that has the Scale-Out File Server role configured.

Applies to: Windows Server 2012 R2

Original KB number: 3101545

Symptoms
Consider the following scenario:

You configure the Scale-Out File Server (SOFS) role on a server that's running
Window Server 2012 R2.
You have server applications and clients that access file shares frequently.
The applications and clients open many short-lived sessions in which they connect,
authenticate, change files, and close the session immediately.

In this scenario, after some time, access to the file shares is unsuccessful, and a
STATUS_INSUFF_SERVER_RESOURCES error is recorded in a network capture.

Additionally, when users try to connect to SOFS shares, they receive the following error
message:

Not enough server storage is available to process this command.

You also see a high handle count in Lsass.exe on both the coordinator and non-
coordinator nodes of the cluster.

７ Note

If you failover the disk resource to another node, the issue temporarily does not
occur.
Cause
This issue occurs because the applications create new sessions every time that they
change a file instead of reusing sessions to generate many metadata changes.

The CSV File System uses the SMB protocol to keep metadata information consistent
between the cluster nodes. A high volume of metadata changes generate many SMB
sessions between the non-coordinator and coordinator nodes of the cluster and exhaust
the SMB table on the coordinator node.

Resolution
To fix this issue for these kinds of application workloads, we recommend that you use
the File Server for General Use role instead of SOFS.

７ Note

The SOFS role should not be used if the workload generates an exceptionally high
number of metadata operations, such as opening and creating new files or
renaming existing files.

More information
In a network capture between non-coordinator and coordinator nodes, you see that
after an SMB Session Setup request, the coordinator node responds with a
STATUS_INSUFF_SERVER_RESOURCES error.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot File Server Resource
Manager
Article • 12/26/2023

This article lists common issues that you might encounter when using File Server
Resource Manager.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2

７ Note

A good troubleshooting option is to look for event logs that have been generated
by File Server Resource Manager. All event log entries for File Server Resource
Manager can be found in the Application event log under the source SRMSVC.

I don't receive e-mail notifications

Cause: The e-mail options haven't been configured or have been configured incorrectly.

Solution: On the E-mail Notifications tab, in the File Server Resource Manager Options
dialog box, verify that the SMTP server and default e-mail recipients have been specified
and are valid. Send a test e-mail to confirm that the information is correct and that the
SMTP server that is used to send the notifications is working properly. For more
information, see Configure E-Mail Notifications.

I only receive one e-mail notification, even

though the event that triggered that
notification happened several times in a row
Cause: When a user attempts several times to save a file that is blocked or to save a file
that exceeds a quota threshold, and there's an e-mail notification configured for that file
screening or quota event, only one e-mail is sent to the administrator over a 60-minute
period by default. This prevents an abundance of redundant messages in the
administrator's e-mail account.

Solution: On the Notification Limits tab, in the File Server Resource Manager Options
dialog box, you can set a time limit for each of the notification types: e-mail, event log,
command, and report. Each limit specifies a time period that must pass before another
notification of the same type is generated for the same issue. For more information, see
Configure Notification Limits.

My storage reports keep failing and little or no

information is available in the Event Log
regarding the source of the failure
Cause: The volume where the reports are being saved may be corrupted.

Solution: Run chkdsk on the volume and try generating the reports again.

My File Screening Audit reports don't contain

any information
Cause: One or more of the following may be the cause:

The auditing database isn't configured to record file screening activity.

The auditing database is empty (that is, no file screening activity has been
recorded).
The parameters for the File Screening Audit report aren't selecting data from the
auditing database.

Solution: On the File Screen Audit tab, in the File Server Resource Manager Options
dialog box, verify that the Record file screening activity in the auditing database check
box is selected.

For more information about recording file screening activity, see Configure File
Screen Audit.
To configure default parameters for the File Screening Audit report, see Configure
Storage Reports.
To edit report parameters for scheduled report tasks or on-demand reports, see
Storage Reports Management.

The "Used" and "Available" values for some of

the quotas I have created don't correspond to
the actual "Limit" setting
Cause: You may have a nested quota, where the quota of a subfolder derives a more
restrictive limit from the quota of its parent folder. For example, you might have a quota
limit of 100 megabytes (MB) applied to a parent folder and a quota of 200 MB applied
separately to each of its subfolders. If the parent folder has a total of 50 MB of data
stored in it (the sum of the data stored in its subfolders), each of the subfolders will list
only 50 MB of available space.

Solution: Under Quota Management, select Quotas. In the Results pane, select the
quota entry that you're troubleshooting. In the Actions pane, select View Quotas
Affecting Folder, and then look for quotas that are applied to the parent folders. This
will allow you to identify which parent folder quotas have a lower storage limit setting
than the quota you have selected.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

File shares on iSCSI devices may not be
re-created when you restart the
computer
Article • 12/26/2023

This article provides a resolution to an issue that may prevent file shares from being re-
created when you restart the computer.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 870964

Symptoms
You use the Microsoft iSCSI Initiator service to connect to an Internet SCSI (iSCSI) disk
device. The file shares that you create for folders that are located on your iSCSI device
may not be re-created when you restart the computer that the shares are created on.

Cause
The issue may occur when the iSCSI Initiator service isn't initialized when the Server
service initializes. The Server service creates file shares. However, because iSCSI disk
devices aren't available, the Server service can't create file shares for iSCSI devices until
the iSCSI service is initialized.

Resolution

iSCSI Initiator 2.x

To resolve the issue in iSCSI Initiator 2.x, follow these steps on the affected server:

1. Make the Server service dependent on the iSCSI Initiator service. For information
about how to do this, see the "Make the Server service dependent on the iSCSI
Initiator service" section.

2. Configure persistent logons to the target. To do this, use one of the following
methods.
 ７ Note

If you see the target on the Persistent Target tab, the following steps are not
required.

Method 1: Use the iSCSI Initiator in Control Panel

a. In Control Panel, double-click iSCSI Initiator.
b. Select the Targets tab.
c. Select a target in the Select a target list, and then select Log On.
d. Select to select the Automatically restore this connection when the system
boots check box, and then select OK.

Method 2: Use the Command Prompt window

a. Select Start > Run, type cmd, and then select OK.
b. At the command prompt, type the following command, and then press Enter:
iscsicli persistentlogintarget **target_iqn** T * * * * * * * * * * * * * *
* 0

７ Note

target_iqn is the IQN name of the target.

3. Configure the BindPersistentVolumes option for the iSCSI Initiator service. To do

this, use one of the following methods.

Method 1: Use the iSCSI Initiator in Control Panel

a. In Control Panel, double-click iSCSI Initiator.
b. Select the Bound Volumes/Devices tab.
c. Select Bind All to bind all the persistent targets. Or, select Add, and then enter a
drive letter or mount point to bind a specific target.
d. Select OK.

Method 2: Use the Command Prompt window

a. Select Start > Run, type cmd, and then press Enter.

b. Type iscsicli BindPersistentVolumes , and then press Enter.

７ Note

This is the same as selecting the Bind All option in Method 1.

 ７ Note

Use this resolution only if you experience this specific issue with version 2.x of the
iSCSI Initiator service.

Make the Server service dependent on the iSCSI Initiator

service
Use one of the following methods to make the Server service dependent on the iSCSI
Initiator service.

Method 1: Use the Microsoft Service Control utility (Sc.exe)

７ Note

You do not have to modify the registry when you use this method. Therefore, this
method is the preferred way to set the service dependency.

1. Select Start > Run, type cmd, and then press Enter.

2. Type sc config LanManServer depend= Samss/Srv2/MSiSCSI , and then press Enter.

If you have administrative access to the server, you can run this command from a
network computer. Type the following command, and then press Enter:

Console

sc \\computer_name config LanManServer depend= Samss/Srv2/MSiSCSI

Method 2: Use Registry Editor

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
 Knowledge Base:
322756 How to back up and restore the registry in Windows

Microsoft Windows 2000

1. Start Registry Editor.

2. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer

3. On the Edit menu, select Add Value.

4. Type DependOnService in the Value Name box, select REG_MULTI_SZ in the Data
Type box, and then press Enter.

5. In the Multi-String Editor window, type MSiSCSI in the data box, and then select
OK.

6. Exit Registry Editor.

More information
You can script the procedures that are described in the "Resolution" section by using the
Sc.exe and Iscsicli.exe utilities. To do this, create a batch file that uses these commands,
and then either run the batch file directly, or run the batch file in another way. For
example, run the batch file by using Group Policy.

Microsoft provides programming examples for illustration only, without warranty either
expressed or implied. This includes, but isn't limited to, the implied warranties of
merchantability or fitness for a particular purpose. This article assumes that you're
familiar with the programming language that is being demonstrated and with the tools
that are used to create and to debug procedures. Microsoft support engineers can help
explain the functionality of a particular procedure. However, they won't modify these
examples to provide added functionality or construct procedures to meet your specific
requirements.

To script the whole operation that is described in the "Resolution" section, create a
batch file that contains the following text:

Console

sc config LanManServer depend= Samss/Srv2/MSiSCSI

iscsicli BindPersistentVolumes
The issue could also happen to non-iscsi storage if server service is started before the
storage has been initialized. In that case, we can use the below workaround, assuming G
is the drive letter we want to monitor:

1. Save the script as a *.bat file.

Console

:Start
dir G: /AH
if %errorlevel% equ 0 goto :OK
ping 127.0.0.1 /n 5
goto :Start
:OK
net stop browser
net stop netlogon
net stop dfs
net stop lanmanserver /y
net start lanmanserver
net start dfs
net start netlogon
net start browser

2. We can add the bat file to "Start Script":

a. Put the batch file into
%systemroot%\System32\GroupPolicy\Machine\Scripts\Startup

b. Run gpedit to open local computer policy

c. Add the batch file into the startup script.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

iSCSI virtual disk size limits in Server
Manager GUI are incorrect
Article • 12/26/2023

This article provides help to solve issues that occur when you provision new iSCSI Target
virtual disks through the New iSCSI Target Virtual Disk wizard by using Server Manager
File and Storage Services GUI.

Applies to: Windows Server 2012 R2

Original KB number: 2896757

Symptoms
In Windows Server 2012 R2, you can provision new iSCSI Target virtual disks through the
New iSCSI Target Virtual Disk wizard using Server Manager File and Storage Services
GUI. This wizard has the following two incorrect behaviors:

1. The wizard incorrectly blocks any virtual disk size to >= 16TB. Default behavior is
to allow up to 64TB in Windows Server 2012 R2. In this case, the wizard fails with
the following error message:

The size of the iSCSI virtual disk must be between 8MB and 16TB

2. The wizard incorrectly blocks a dynamic virtual disk size to >= free space available
on the hosting volume. Default behavior is to allow virtual disk creation if the initial
dynamic VHDX file (typically a few MB in size) can be successfully created on the
volume. In this case, the wizard fails with the following error message:

The size of the iSCSI virtual disk must be less than or equal to the remaining
free space on the volume

Cause
The GUI behavior corresponds to Windows Server 2012 limits. In Windows Server 2012
R2, support of VHDX as the default storage format for iSCSI virtual disks has increased
the upper limit to 64TB and the newly added support for dynamic VHDX also meant that
the hosting volume is not required to have the capacity for a fully provisioned virtual
disk up front when a dynamic virtual disk is created on this volume. So the GUI behavior
in these cases is erroneous in Windows Server 2012 R2.
Resolution
As of October 2013, there is no GUI resolution to work around these GUI problems.

However, the easy workaround is to use Windows PowerShell instead in these cases, use
the New-iSCSIVirtualDisk cmdlet. The cmdlet documentation is available at New-
IscsiVirtualDisk.

References
iscsi target server in Windows Server 2012 R2

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Supported and tested Microsoft iSCSI
Software Target 3.3 limits
Article • 12/26/2023

This topic provides the supported and tested Microsoft iSCSI Software Target 3.3 limits.

Applies to: Windows Server 2012 R2

Original KB number: 2535811

Summary
The following tables display the tested limits and the enforced limits where applicable.
In addition, the following limits apply:

1. You should not use network adapter teaming with Microsoft iSCSI Software Target
3.3 for iSCSI communication.
2. If you plan to use multiple network adapters for iSCSI communication, you should
separate them into their own subnets, set up virtual IP addresses, and then
implement MPIO.

Basic configuration

ﾉ Expand table

Item Limit Enforced Comment

iSCSI target 256 Not

instances per Enforced
appliance

Initiators that can 16 Enforced When used with MPIO, you can connect no
connect to the same more than 4 sessions per initiator.
iSCSI target
instance

iSCSI initiators per 256 Not

appliance Enforced

Virtual disks per 256 Not

appliance Enforced

Virtual disks per 128 Enforced

iSCSI target
instance
 Item Limit Enforced Comment

Simultaneous 64 Enforced
sessions

Snapshots per 512 Enforced There is a limit of 512 snapshots per

virtual disk independent iSCSI application volume and
64 snapshots for file share volumes. If the
iSCSI virtual disks and file shares are on a
common volume, the iSCSI snapshot limit is
448 (512 - 64).

Locally mounted 32 (on stand- Enforced

virtual disks or alone or
snapshots per snapshots per
appliance appliance)

Fault Tolerance

ﾉ Expand table

Item Limit Enforced Comment

Failover cluster nodes 5 Not

Enforced

Error recovery level 0 Enforced

(ERL)

Multiple Connections Not Enforced

per Session (MCS) supported

Simultaneous 64 Not
connections Enforced

Multipath Supported N/A

Input/Output (MPIO)

MPIO Paths 4 Not

Enforced

Virtual disks over 64 Not There is an initial delay after creating the disks
MPIO per initiator on Enforced before they appear to the Virtual Disk Service
a stand-alone server and the Disk Management snap-in because
PnP first detects the devices and then MPIO
detects the paths for each disk. This happens
only one time per disk per appliance.

Virtual disks over 32 Not

MPIO per initiator on Enforced
 Item Limit Enforced Comment

a clustered
application server

Converting stand- Supported N/A No VHD or target will be preserved.

alone iSCSI Software
Target to failover
cluster or vice versa

Network

ﾉ Expand table

Item Limit Enforced Comment

Maximum number 6 Not Applies to network ports that are dedicated

of active network Enforced to iSCSI traffic, rather than the total number
ports of network ports in the appliance.

Network port 10 gigabits per Not

speed second (Gbps) Enforced

IPv4 Supported

IPv6 Supported

TCP offload Supported

iSCSI offload Not Supported

Jumbo Frames Supported

IPsec Supported

iSCSI virtual disks

ﾉ Expand table

Item Limit Enforced

From an iSCSI initiator, which converts the iSCSI target disk from a Not Not
fixed disk to a dynamic disk supported enforced

VHD minimum size format 8 MB Enforced

Parent VHD size 2088890 MB Enforced

Fixed VHd size 16776703 Enforced

MB
 Item Limit Enforced

Differencing VHD size 2088960 MB Enforced

VHD fixed format Supported N/A

VHD differencing format Supported N/A

VHD dynamic format Not N/A

supported

FAT/FAT32 (hosting volume of VHD) Not Not

supported enforced

NTFS Supported N/A

NTFS cluster size 4 kb N/A

Non-Microsoft CFS Not Enforced

Supported

Number of differencing VHDs per VHD 256 Not

enforced

Number of parent VHDs per differencing VHD 1 Enforced

Number of boot operating systems that can be installed on one 1 Not

VHD enforced

Thin provisioning Not N/A

supported

LUN shrink Not N/A

supported

LUN cloning Not N/A

supported

Windows operating systems on which the VDS and VSS hardware providers are
supported

ﾉ Expand table

Operating System Limit Enforced

Windows Server 2003 R2 x64 Supported Enforced

Windows Server 2003 R2 x86 Supported Enforced

Windows Server 2008 SP2 x64 Supported Enforced

 Operating System Limit Enforced

Windows Server 2008 SP2 x86 Supported Enforced

Windows Server 2008 R2 x64 Supported Enforced

Windows Storage Server 2008 x64 Supported Enforced

Windows Storage Server 2008 x86 Not Enforced

supported

Windows Storage Server 2008 R2 x64 Supported Enforced

All client operating systems (Windows XP, Windows Vista, Windows Not Enforced
7) supported

iSCSI Software Target provider interoperability

ﾉ Expand table

iSCSI target version iSCSI provider version Supported

3.1 3.1 Supported

3.2 3.1 Not supported

3.2 3.1 (in-place upgrade) Not supported

3.1 3.2 Supported

3.2 3.2 Supported

3.2 3.3 Supported

3.3 3.3 Supported

Note: In-place upgrades from Microsoft iSCSI Software Target 3.1 to Microsoft iSCSI
Software Target 3.3 are not supported. To upgrade to Microsoft iSCSI Software Target
3.3, you must first uninstall Microsoft iSCSI Software Target 3.1.

iSCSI Software Target virtual disk compatibility

ﾉ Expand table

Created in version Mounted in version Supported

3.0 3.1 Not supported

3.0 3.2 Supported

 Created in version Mounted in version Supported

3.1 3.2 Supported

3.1 3.3 Supported

3.2 3.3 Supported

Microsoft iSCSI Software Target snap-in interoperability

ﾉ Expand table

Snap-in installed on Managing iSCSI target on Supported

Windows Storage Server 2008 R2 Windows Storage Server 2008 R2 Supported

Windows Storage Server 2008 R2, Windows Storage Server 2008 R2, Supported
stand-alone server failover cluster node

Windows Storage Server 2008 R2, Windows Storage Server 2008 R2, stand- Supported
failover cluster node alone server

Miscellaneous

ﾉ Expand table

Item Supported

Install Microsoft iSCSI Software Target 3.3 snap-in on Windows XP, Windows Not
Vista, or Windows 7 supported

Install Microsoft iSCSI Software Target 3.3 snap-in on x86 version of Windows Not
Storage Server 2008 supported

Use Microsoft iSCSI Software Target 3.3 snap-in to manage Microsoft iSCSI Supported
Software Target 3.2 target

Use Microsoft iSCSI Software Target 3.2 snap-in to manage Microsoft iSCSI Not
Software Target 3.3 target supported

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Redundant subnets are incorrectly
created in an iSCSI IPv6 network
Article • 12/26/2023

This article provides a solution to an issue where redundant subnets are incorrectly
created in an iSCSI IPv6 network.

Applies to: Windows Server 2019

Original KB number: 4536782

Symptoms
You design an iSCSI IPv6 network that contains servers and storage devices. In this
network, some servers use link-local addresses.

In this situation, you encounter an issue in which multiple gateways try to create
separate storage subnets to isolate the traffic. However, the subnets are redundant.

Workaround
To work around this issue, configure the initiator and the target on different subnets.

References
iSCSI Boot Firmware Table (iBFT) as Defined in ACPI 3.0b Specification (download
file)

Storage Services Protocols Overview

Windows Hardware Compatibility Program specifications and policies for the iSCSI
industry and Microsoft

IPv6 Link-local and Site-local Addresses

Feedback
Was this page helpful?  Yes  No
Provide product feedback
The Microsoft iSCSI Initiator may fail to
log in to Favorite Targets after the
Initiator Name is changed in Windows
Article • 12/26/2023

This article provides a solution to an issue where the Microsoft iSCSI Initiator fails to log
in to Favorite Targets after the initiator name is changed.

Applies to: Windows Server 2012 R2, Windows 7 Service Pack 1

Original KB number: 2500271

Symptoms
Consider the following scenario. On a system running Windows, you are connecting to
iSCSI-based storage using the Microsoft iSCSI Initiator. In the iSCSI Initiator Properties,
you have configured Favorite Target entries, so that the iSCSI Initiator will automatically
connect to certain iSCSI targets. The iSCSI target(s) you are connecting to uses access
control, and this access control uses the iSCSI Initiator Name (for example, iQN) or
initiator IP address for authentication.

If you change the Initiator Name in the Configuration tab of the iSCSI Initiator
Properties, you may be unable to access certain access-controlled iSCSI targets when
the system is rebooted, or when connectivity to an iSCSI target is lost. By way of
example:

If an iSCSI target is configured to use the new Initiator Name for authentication,
the iSCSI Initiator may fail to log in to the target using Favorite Target entries that
were created while the iSCSI Initiator was configured to use the old Initiator Name.
If an iSCSI target is configured to use the old Initiator Name for authentication, the
iSCSI Initiator may fail to log in to the target using Favorite Target entries that are
created after the Initiator Name is changed. Also, you may no longer be able to
discover the iSCSI target once the Initiator Name is changed.
If the iSCSI target is configured to use the iSCSI initiator's IP address for
authentication, the iSCSI Initiator will be able to log in using Favorite Target entries
that were created both before and after the Initiator Name was changed. However,
for security reasons the iSCSI target may prevent logons from a single IP address
using multiple Initiator Names, and therefore some logon attempts may fail.
Cause
When a Favorite Target entry is created, the iSCSI Initiator sets the Favorite Target entry
to use the Initiator Name that is configured at the time of creation. If the Initiator Name
is later changed, any pre-existing Favorite Target entries are not updated to reflect the
newly configured Initiator Name.

Resolution
When the Initiator Name is changed in the iSCSI Initiator Properties, any pre-existing
Favorite Target entries should be removed and recreated to ensure they use the new
Initiator Name. Also, ensure the Initiator Name always matches the Initiator Name that
the iSCSI target is using for access control.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Setup in a boot from SAN
configuration reports: Setup was unable
to create a new system partition or
locate an existing system partition
Article • 12/26/2023

This article provides workarounds for an issue where you can't install Windows in the
boot LUN from SAN configuration when there are multiple physical paths to the boot
LUN.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2826787

Symptoms
Consider the following scenario:

You're installing Windows Server 2008, Windows Server 2008 R2, or Window Server
2012 in a boot from SAN configuration.
There are multiple physical paths to the boot LUN.
The boot LUN is raw and hasn't been initialized by Windows.

In this scenario, when you select the boot LUN in on the "Where do you want to install
Windows?" step of the installation wizard, all paths to the LUN are displayed separately
and a message is displayed:

Windows Server 2012 and Windows Server 2008 R2:

"Setup was unable to create a new system partition or locate an existing system
partition. See the Setup log files for more information."
Windows Server 2008:

"Windows cannot find a system volume that meets requirements for installation."

Cause
Windows is unable to install to a RAW disk with multiple physical paths. If the boot LUN
is presented on a single physical path or if the boot LUN has already been initialized
prior to installing Windows, Setup will proceed as expected.

There are two methods for working around this behavior.

Workaround 1: Present the boot LUN on a

single path
Configure a single path to the boot LUN when installing Windows. For multiple HBA
port configurations, only one HBA port should be connected to the SAN during
Windows Setup.
Workaround 2: Initialize the boot LUN prior to
running setup
This method is ideal for scenarios where physically disconnecting the additional SAN
connections isn't possible or is difficult.

In multiple-path disk configurations Windows Setup doesn't recognize a disk as

bootable until the disk is initialized and the disk signature is present. To initialize the
boot LUN and prepare the disk for Windows Setup, you must create a new partition and
then delete the newly created partition. Creating a new partition will initialize the disk,
write the disk signature, and create a partition. Deleting the partition will remove the
newly created partition but leave the disk initialized with the disk signature. It's
important to delete the partition so Windows Setup can create both the System
Reserved partition and the Operating System Volume. Otherwise, Windows Setup
doesn't create the System Reserved partition.

Detailed steps for Workaround 2 are as follows:

1. In the Install Windows dialog box of Windows Setup, under Where do you want to
install Windows?, select Disk 0 and then click the Drive Options (advanced) link.
2. Select New to create a new partition.
3. Click Apply to accept the default partition size.
4. Click OK on the dialog box that explains that additional partitions may be created
automatically by Windows.
5. Now, select Delete to remove the newly created partition while leaving the disk in
its initialized state.
6. Click OK on the warning dialog box to acknowledge that any data on the disk will
be lost.
7. Reboot the system and run Windows Setup normally. Windows Setup will
recognize the disk and Setup will continue.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Enabling MPIO with SAS Storage
decreases performance
Article • 12/26/2023

This article provides help to solve an issue where sequential write performance of disks
decreases by approximately 50% after you enable the Multipath I/O (MPIO) feature on a
system using Serial Attached Storage (SAS) disks.

Applies to: Windows Server 2012 R2

Original KB number: 2744261

Symptoms
On a Windows Server 2012, after enabling the MPIO feature on a system using SAS
disks, the sequential write performance of disks used with MPIO decreases by
approximately 50% when operating with the Round Robin load balancing policy.

Cause
This issue can occur when disks are configured as below:

The MPIO feature is enabled to provide access via both SAS ports.
Disk firmware does not provide optimal performance when both SAS ports are in
use.

７ Note

This issue may occur when using Storage Spaces in conjunction with SAS disks and
MPIO.

Resolution
To resolve this issue, obtain updated firmware from your disk vendor.

You can work around this issue by trying a different Load Balance policy using the
appropriate options mentioned below:
Work around when using Storage Spaces or when LB
policies have not been manually set per-disk
Use the Set-MSDSMGlobalDefaultLoadBalancePolicy cmdlet from the MPIO module in
Windows PowerShell to specify a different LB policy to apply to all pool disks.

Work around when not using Storage Spaces, or when LB

policies have been set per-disk manually
1. Open Disk Management. To open Disk Management, on the Windows desktop,
click Start; in the Start Search field, type diskmgmt.msc; and then, in the Programs
list, click diskmgmt.
2. Right-click the multipathed disk for which you want to change the policy setting,
and click Properties.
3. Click the MPIO tab.
4. In the Select the MPIO Policy dropdown list select another policy, such as Least
Blocks.
5. Click OK.
6. Repeat above steps for all other multipathed disks exhibiting slow performance.

More information
For a complete listing of the cmdlets contained in the iSCSI module for Windows
PowerShell, refer to the following documents:

iSCSI

iSCSI Initiator WMI Classes

Feedback
Was this page helpful?  Yes  No

Provide product feedback

MPIO option not in Disk Management
in Windows Server 2019
Article • 12/26/2023

This article describes a change in Windows Server 2019, in which MPIO option is no
longer available in Disk Management.

Applies to: Windows Server 2019

Original KB number: 4477064

Symptom
After you install the Multipath I/O (MPIO) feature on a server that's running Windows
Server 2019 build 17763, you notice that the MPIO option is not available under Disk
Management > Microsoft Storage Space Device Properties as it was in earlier versions
of Windows.

Workaround
To work around this issue, use a PowerShell cmdlet to configure MPIO. For example:

Run Get-MSDSMGlobalDefaultLoadBalancePolicy in PowerShell to retrieve the

MPIO policy.
Run Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR to set up the MPIO
policy as round robin.

Reference
For more information, see MPIO.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A volume may show up as raw in disk
management after you extend the
partition, but chkdsk shows the file
system as NTFS
Article • 12/26/2023

This article provides solutions to an issue where a volume shows as raw in disk
management but chkdsk shows the file system as NTFS after you extend the partition.

Applies to: Windows Server 2012 R2

Original KB number: 2261358

Symptoms
When you extend a volume by using FSExtend, the volume may show as raw in disk
management. However, when you run chkdsk, the file system is shown as NTFS.

Additionally, you see the following error message in the System log:

Log Name: System

Source: Ntfs
Event ID: 55
Level: Error
Description:
The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the volume <driveletter>:

Cause
The issue occurs because of one of the following reasons:

The file system structure on the disk is corrupted.

There is not enough disk space for the file system extend.

Resolution
To resolve this issue, use one of the following methods.
Method 1
If there is too little disk space to mount the volume, shrink the NTFS transaction log to 4
MB. Then, the disk will have enough space to mount the volume. To do this, follow these
steps.

1. To shrink the NTFS transaction log to 4 MB, run the following command:

Console

chkdsk d: /l:4096 /f

2. Determine whether you can access the disk. If you can access the disk, you should
free up some free space and then return the NTFS transaction log to the default
value of about 65 MB. To do this, run the following command:

Console

chkdsk d: /l: 65536 /f

Method 2
Run the following command on the disk to fix any errors on the disk:

Console

chkdsk /f <drive>

After chkdsk is completed successfully, restart the server. Then, run FSExtend on the
drive to extend the file system. To do this, run the following command:

Console

FSExtend <drive>

This should extend the file system on the drive, and the disk should be accessible.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Best practices for using dynamic disks
on Windows Server 2003-based
computers
Article • 12/26/2023

This article describes the best practices for using dynamic disks on Windows Server
2003-based computers.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 816307

Summary
If you use dynamic disks, you can create fault-tolerant volumes (mirrored volumes and
RAID-5 sets) and large multiple-disk (or logical unit number [LUN]) volumes by using
striped and spanned volumes. These features are available only on dynamic disks.
Dynamic disks are more robust and fault-tolerant in the way they store and replicate
disk and volume configuration information. Dynamic disks are primarily designed to
always be online. For this reason, they aren't available on removable media. Follow the
recommendations in this article to keep your data online and accessible.

More information
After you create a partition on Windows Server 2003, the partition must be formatted
and assigned a drive letter before data can be stored on it. Windows Server 2003
supports two different types of disks for partitions, basic and dynamic disks. On basic
disks, partitions are known as basic volumes. Basic volumes include primary partitions
and logical drives. On dynamic disks, partitions are known as dynamic volumes. Dynamic
volumes include simple, striped, spanned, mirrored, and RAID-5 volumes.

Volumes are an area of storage on a hard disk. A volume is formatted by using a file
system, such as file allocation table (FAT) or NTFS file system, and it has a drive letter
assigned to it. You can view the contents of a volume by clicking its icon in Windows
Explorer or in My Computer. A single hard disk can have multiple volumes, and volumes
can also span multiple disks.
Best practices and limitations of using dynamic
disks
Dynamic disks offer advantages over basic disks. Basic disks use the original MS-DOS-
style master boot record (MBR) partition tables to store primary and logical disk
partitioning information. Dynamic disks use a private region of the disk to maintain a
Logical Disk Manager (LDM) database. The LDM database contains volume types,
offsets, memberships, and drive letters of each volume. The LDM database is also
replicated, so each dynamic disk knows about every other dynamic disk configuration.
This feature makes dynamic disks more reliable and recoverable than basic disks.

Before you use dynamic disks, consider the following recommended best practices and
limitations of using dynamic disks.

Dynamic disks vs. basic disks

Before you convert basic disks to dynamic disks, determine whether you require features
provided by dynamic disks. If you don't require spanned volumes, striped volumes,
mirrored volumes, or RAID-5 sets, it may be best to use basic disks.

７ Note

If you want to increase the size of a hardware RAID-5 disk LUN but don't have to
span the NTFS file system volume across different physical disks (or LUNs), continue
to use basic disks. You can use the DiskPart.exe utility to extend the NTFS volume
after you add new storage capacity to the RAID volume. DiskPart.exe is a text-mode
command interpreter that you can use to manage objects (disks, partitions or
volumes) by using scripts or direct input from a command prompt. For more
information, see Extend a data volume in Windows

Storage devices
If you decide to use dynamic disks and you have both locally attached storage (IDE-
based storage or Small Computer System Interface [SCSI]-based storage) and storage
that is located on a storage area network (SAN), consider the following
recommendations, depending on your situation:

Use dynamic disks on only the SAN storage drives and keep the locally attached
storage as basic disks.
or

Use basic disks on the SAN storage drives and configure the locally attached
storage as dynamic disks. These recommendations are based on the way that the
LDM keeps track of dynamic disks and synchronizes the databases. By following
these recommendations, if you experience an unplanned outage and lose access to
the SAN storage housing the dynamic disks, all dynamic disks drop offline from the
Windows Server 2003-based computer at the same time. Because you have no
dynamic disks attached locally, there are no LDM database synchronization issues
to contend with when the SAN disks eventually come back online. If you have even
one dynamic disk on the locally attached storage, you run the risk of the LDM
databases being mismatched, and you may have trouble getting one or more
SAN-attached dynamic disks back online.

If your environment requires you to have dynamic disks in a mixed configuration that
uses both locally attached storage and SAN-attached storage, it's a good idea to protect
all fiber hubs, routers, switches, SAN cabinets, and the server from power outages by
using uninterruptible power supplies (UPSs) on all connecting devices.

７ Note

In a mixed dynamic disk configuration, if you must take the SAN storage
offline for maintenance, Microsoft recommends that you shut down the server
before you take the SAN storage unit offline and then make sure that all the
SAN devices are available again when you bring the server back online.
Windows does not support mounting a disk volume to multiple hosts at the
same time. This restriction applies to volumes that are located on a BASIC disk
or a dynamic disk. Volume corruption may occur if changes are made to the
volume by both hosts. Windows also does not support exposing and then
importing dynamic disks on multiple hosts (nodes) simultaneously. This
practice can also lead to data loss or to LDM database corruption.

Server clusters
Dynamic disks aren't supported for use with Windows Clustering. This restriction doesn't
prevent you from extending an NTFS volume that is contained on a cluster shared disk
(a disk that is shared between the computers in the cluster) that is basic.
You can use a third-party software such as Veritas Volume Manager to add the dynamic
disk features to a Microsoft cluster infrastructure.

７ Note

By default, Windows 2000 Server and Windows Server 2003 don't support dynamic
disks in a Microsoft Cluster Server (MSCS) environment. You can use Veritas Volume
Manager for Windows to add the dynamic disk features to a Microsoft server
cluster. For customer service support about cluster issues after you install Veritas
Volume Manager, please contact Veritas.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft doesn't guarantee the
accuracy of this third-party contact information.

Moving dynamic disks

If you move dynamic disks between systems, you may not be able to move the dynamic
disks back to the original host. If you must move the dynamic disks, move all the
dynamic disks from a computer at the same time, and make sure that they're all online
and running on the destination computer before you try to import them to the new
host. You must do it because the disk group name and the ID of the primary disk group
of the host system (if a dynamic disk is present) is always kept. What makes the
difference is whether there is at least one dynamic disk on the destination computer.
One problem scenario occurs when there are no dynamic disks on the destination
computer (so that computer ends up with the same disk group name as the source
computer when the disks are moved to it) and then you want to move the disks back to
the source computer. You may experience a problem if foreign disks that are being
reimported have the same disk group name as the local computer.

Disk signatures
When you start the Disk Management snap-in, all disks on the system are enumerated
to see if any disks have changed or if any new disks have been added to the system. If
Disk Management finds any disks that are unknown, that aren't initialized, or that don't
have a disk signature in the MBR, Disk Management starts a wizard. The wizard prompts
you to select the disks that you want to write disk signatures to. By default, no disks are
selected. Select the check boxes next to the disk numbers to select the disks to be
enumerated. You're then prompted to select the disks that you want to upgrade to
dynamic disks. All disks that you upgrade have a disk signature added and are upgraded
to dynamic disks.

When you start Disk Management, if the MBR of a dynamic disk is zeros, the wizard
starts.

７ Note

The MBR of a disk may be read as zeros if there is a hardware failure.

The wizard prompts you to convert the disk to a dynamic disk. If you permit the disk to
be reconverted to dynamic, the original LDM database is overwritten by the newly
initialized LDM database. Disk Management shows that disk as healthy, but it only
shows the unallocated free space. If you have another healthy dynamic disk in the
system at the time of conversion, its LDM database is replicated to the newly converted
dynamic disk and a "missing" disk that represents the original dynamic disk is also
shown in Disk Management.

Missing dynamic disks

If Disk Management shows a missing dynamic disk, which means that a dynamic disk
that was attached to the system can't be located. Because every dynamic disk in the
system knows about every other dynamic disk, this "missing" disk is shown in Disk
Management. Don't delete the missing disk's volumes or select the Remove Disk option
in Disk Management unless you intentionally removed the physical disk from the system
and you don't intend to ever reattach it. It's important because after you delete the disk
and volume records from the remaining dynamic disk's LDM database, you may not be
able to import the missing disk and bring it back online on the same system after you
reattach it.

Text-mode setup and Recovery Console

Never delete or create a partition on a dynamic disk during Windows 2000, Windows XP,
or Windows Server 2003 text-mode Setup or when you start the computer by using the
Recovery Console. If you do so, permanent data loss may occur.

The mirrored drive

Never break a healthy system disk or boot dynamic mirrored volume and expect the
mirrored drive to replace the original primary drive if it fails. The manually broken
mirrored drive is assigned the next available drive letter, and this is updated to the
permanent record in the LDM database. This means that regardless of what position
that drive takes in the boot process, it's assigned the new (and incorrect) drive letter, so
the operating system can't function correctly.

７ Note

Windows software mirroring is a fault-tolerant solution that makes sure you can
maintain access to data if you have a hardware disk failure. Software mirroring is
not intended to be used as an offline backup mechanism.

Hardware Mirroring
If you use dynamic disks with hardware mirroring, make sure that both parts of the
hardware-mirrored drives aren't exposed to the same operating system at the same
time. On hardware-mirrored disks, the LDM databases are exactly the same, but each
dynamic disk on a system contains a unique DiskID in the LDM header so that LDM can
distinguish one dynamic disk from another.

To expose both parts of a hardware-mirrored drive, break the hardware mirror by using
the OEM RAID configuration utility, and then configure both disks as standalone drives
that are both accessible to the operating system.

Unpredictable behavior may occur if two dynamic disks that are exactly the same are
exposed to the operating system at the same time.

References
For more information, see How to use the Disk Management Snap-in to manage Basic
and Dynamic Disks in Windows Server 2003

The third-party products that are discussed in this article are manufactured by
companies that are independent of Microsoft. Microsoft makes no warranty, implied or
otherwise, regarding the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Unable to access ClusterStorage folder
on a passive node in a server cluster
Article • 12/26/2023

This article describes an issue where you can't access a CSV volume from a passive (non-
coordinator) node and receive event ID 5120 or 5142.

Applies to: Windows Server 2012 R2

Original KB number: 2008795

Symptoms
On a Windows Server cluster with Cluster Shared Volume(CSV) feature enabled, a user
may be unable to access a CSV volume from a passive (non-coordinator) node. When
clicking on a CSV volume, explorer may hang. One or all of the following events may be
displayed:

Event ID: 5120

Source: Microsoft-Windows-FailoverCluster
Level: Error
Description: Cluster Shared Volume "volume_name" is no longer available on this
node because of "STATUS_BAD_NETWORK_PATH(c00000be)'. All I/O will temporarily
be queued until a path to the volume is re-established.

Event ID: 5120

Source: Microsoft-Windows-FailoverCluster
Level: Error
Description: Cluster Shared Volume "volume_name" is no longer available on this
node because of 'STATUS_CONNECTION_DISCONNECTED(c000020c)'. All I/O will
temporarily be queued until a path to the volume is reestablished.

Event ID: 5120

Source: Microsoft-Windows-FailoverCluster
Level: Error
Description: Cluster Shared Volume "volume_name" is no longer available on this
node because of 'STATUS_MEDIA_WRITE_PROTECTED(c00000a2)'. All I/O will
temporarily be queued until a path to the volume is reestablished.
 Event ID generated: 5142
Source: Microsoft-Windows-FailoverCluster
Description: Cluster Shared Volume "volume_name" ('Cluster Disk #') is no longer
accessible from this cluster node because of error 'ERROR_TIMEOUT(1460)'. Please
troubleshoot this node's connectivity to the storage device and network
connectivity.

Cause
When accessing a CSV volume from a passive (non-coordinator) node, the disk I/O to
the owning (coordinator) node is routed through a 'preferred' network adapter and
requires SMB be enabled on that network adapter. For SMB connections to work on
these network adapters, the following protocols must be enabled:

Client for Microsoft Networks

File and Printer Sharing for Microsoft Networks

Resolution
Review each cluster node and verify the following protocols are enabled the network
adapters available for Cluster use:

Client for Microsoft Networks

File and Printer Sharing for Microsoft Networks

1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. Right-click the local area connection that is associated with the network adapter,
and then click Properties.
3. Verify that the above protocols appear in the This connection uses the following
items box. If either is missing, follow these steps:
a. Click Install, click Client, and then click Add.
b. Select the missing protocol, click OK, and then click Yes.
4. Verify that the check box that appears next to Client for Microsoft Networks is
selected.

More information
The Event ID 5120 mentioned above will be logged anytime that there's a problem
connecting over the network using SMB to the owning node. If the connection is
restored within a few minutes, then there may be no ill effects other than slowness of
the VMs because of lack of I/O completing.
The meaning of the event codes listed above are as follows:

'STATUS_BAD_NETWORK_PATH(c00000be)' - This error code means that the

network path to the SMB2 share that is created by the node that is currently listed
as the owner for the CSV can't be located.
'STATUS_CONNECTION_DISCONNECTED(c000020c)' - This error code means that a
node has lost access to the SMB2 share that is created by the node that is currently
listed as the owner for the CSV.
'STATUS_MEDIA_WRITE_PROTECTED(c00000a2)' - This error code means that can't
write to the volume. Usually this indicates that we've lost the reservation on the
disk and we no longer have direct I/O with the disk.

The Event ID 5142 indicates that the non-owning node is disconnected and CSV is no
longer queuing the I/O. As a result, the VMs on the node logging the errors will see the
storage as disconnected instead of slow in responding.

The preferred network is the network with the lowest cluster network metric value. If the
preferred network is unavailable (due to problems or reconfiguration), then the cluster
network fault tolerance will cause the network with the next lowest metric to be used. If
that network isn't configured to allow SMB connection, then the above error will be
encountered.

The recommendation is for any network that the cluster might use (any network not
disabled for cluster use) should be configured as shown above to allow CSV use.

Reference Articles:

Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2

Cluster Shared Volumes Support for Hyper-V

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot select or format a hard disk
partition when you try to install
Windows
Article • 12/26/2023

This article provides solutions to an issue where you fail to select or format a hard disk
partition when you try to install Windows.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 927520

７ Note

Support for Windows Vista without any service packs installed ended on April 13,
2010. To continue receiving security updates for Windows, make sure you're
running Windows Vista with Service Pack 2 (SP2). For more information, see
Support is ending for some versions of Windows .

） Important

Dynamic discs are only supported for:

Windows Vista Business

Windows Vista Enterprise
Windows Vista Ultimate.
Windows 7 Enterprise
Windows 7 Professional
Windows 7 Ultimate
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard
Windows Web Server 2008 R2

They are not supported for Windows Vista Home Basic, Windows Vista Home
Premium, Windows 7 Home Basic, Windows 7 Starter, and Windows 7 Home
Premium.
 There is one exception. When you upgrade your computer from Windows XP
Media Center Edition to Windows Vista Home Premium, some dynamic discs are
handled and supported.

Symptoms
When you try to install Windows Vista, Windows 7 or Windows Server 2008 R2, you may
experience one or more of the following symptoms:

The hard disk on which you want to install Windows Vista, Windows 7, or Windows
Server 2008 R2is not listed.

You cannot select a hard disk partition on which to install Windows Vista, Windows
7, or Windows Server 2008 R2.

You cannot format a hard disk partition or partitions.

You cannot set the correct size for a hard disk partition.

You receive the following error message:

Windows is unable to find a system volume that meets its criteria for
installation

Cause
This problem may occur for one of the following reasons:

Windows is incompatible with a mass storage controller or a mass storage driver.

A mass storage controller or a mass storage driver is outdated.
The hard disk on which you want to install Windows Vista, Windows 7 or Windows
Server 2008 R2 is a dynamic disk.
A data cable in the computer is loose, or another hardware issue has occurred.
The hard disk or the Windows file system is damaged.
You tried to select a FAT32 partition or another type of partition that is
incompatible with Windows Vista, Windows 7 or Windows Server 2008 R2.

To resolve this problem, use one or more of the following methods.

Resolution 1: Verify that partition is compatible

with Windows
You cannot install Windows on a FAT32 partition. Additionally, you must correctly
configure dynamic disks for use with Windows. To verify that the partition is compatible
with Windows Vista, Windows 7 or Windows Server 2008 R2, follow these steps:

1. For a dynamic disk that has a simple volume, use the Diskpart.exe utility to
configure the disk as an active disk. For more information about how to use the
Diskpart.exe utility, see DiskPart Command-Line Options.

2. For a FAT32 partition, reformat the partition, or convert the partition to an NTFS file
system partition by using the Convert.exe command.

７ Note

When you format a partition, all data is removed from the partition. This data
includes all the files on the partition.

Resolution 2: Update drivers for the hard disk

controller
If you want to install Windows Vista Windows 7 or Windows Server 2008 R2 as an
upgrade, update the drivers for the hard disk controller to the latest drivers.

７ Note

Windows Setup provides a feature to migrate current drivers to the new operating
system. Therefore, Windows Setup may use the drivers that are currently installed
on the computer. If the computer does not have the latest drivers installed, the
Setup program may use the outdated drivers. In this case, you may experience
compatibility problems.

Resolution 3: Provide correct drivers for hard

disk controller
If you are trying to perform a clean installation of Windows, you must provide the
correct drivers for the hard disk controller. When you are prompted to select the disk on
which to install Windows, you must also click to select the Load Driver option. Windows
Setup will guide you through the rest of the process.
Resolution 4: Examine Setupact.log file to verify
that partition is active
If you receive the following error message, verify that the partition is active by
examining the Setupact.log file:

Windows is unable to find a system volume that meets its criteria for installation

７ Note

If you install Windows Vista, Windows 7 or Windows Server 2008 R2 as an

upgrade, the Setupact.log file is located in the
Drive:$WINDOWS.~BT\Sources\Panther folder. Drive represents the drive that
contains the existing Windows installation.
If you perform a clean installation of Windows Vista, Windows 7 or Windows
Server 2008 R2, the Setupact.log file is located in the
Drive:$WINDOWS\Sources\Panther folder. Drive represents the DVD drive
that contains the Windows Setup files.

To verify that the partition is active, follow these steps:

1. Insert the DVD into the DVD drive.

2. On the disk selection screen, press SHIFT+F10. A Command Prompt (CMD)

window opens.

3. Change the directory to locate the Setupact.log file, and then open the
Setupact.log file.

4. Locate the DumpDiskInformation section. This section contains information about

partition mapping.

5. In the DumpDiskInformation section, locate the log entry that resembles the
following.

Disk [0] partition [1] is an active partition

6. If this log entry appears after an entry that resembles the following, the hard disk
may not be configured to use a Windows-based operating system.
 Unknown

In this case, use the Diskpart.exe utility to configure a different partition as active.

７ Note

This step prevents a third-party operating system from starting.

7. Close the Command Prompt window.

Resolution 5: Check for firmware updates and

for system BIOS updates
For firmware updates and for system BIOS updates, contact the manufacturer of the
hardware in the computer.

Resolution 6: Verify that system BIOS correctly

detects hard disk
For information about how to verify that the system BIOS correctly detects the hard disk,
contact the manufacturer of the computer hardware.

Resolution 7: Use Chkdsk.exe to check for

problems
Run the Chkdsk.exe utility to check for disk problems. Replace the hard disk if it is
damaged.

Resolution 8: Use Diskpart.exe to clean disk

and rerun Windows Setup
If you have tried all the methods that are listed in this section and the problem persists,
use the Diskpart.exe utility to clean the disk, and then run Windows Setup again.

７ Note
 Use this method only if you want to perform a clean installation of Windows. When
you clean the hard disk, it is formatted. All partitions and all data on the hard disk
are permanently removed. We strongly recommend that you back up the files on
the hard disk before you clean the disk.

To use the Diskpart.exe utility to clean the hard disk, follow these steps:

1. Insert the DVD into the DVD drive.

2. On the disk selection screen, press SHIFT+F10. A Command Prompt window
opens.
3. Type diskpart, and then press ENTER to open the diskpart tool.
4. Type list disk , and then press ENTER. A list of available hard disks is displayed.
5. Type sel disk number , and then press ENTER. number is the number of the hard
disk that you want to clean. The hard disk is now selected.
6. Type det disk , and then press ENTER. A list of partitions on the hard disk is
displayed. Use this information to verify that the correct disk is selected.
7. Make sure that the disk does not contain required data, type clean all , and then
press ENTER to clean the disk. All the partitions and all the data on the disk is
permanently removed.
8. Type exit , and then press ENTER to close the diskpart tool.
9. Close the Command Prompt window.
10. Click the Refresh button to update the disk selection screen. This step lists the
disk.
11. Run Windows Setup to perform a clean installation of Windows.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You can't start a computer from a USB
flash drive that is formatted to use the
FAT32 file system
Article • 12/26/2023

This article works around a startup failure when you use a USB flash drive that's
formatted to use the FAT32 file system.

Applies to: Windows Server 2012 R2

Original KB number: 954457

Symptoms
You format a USB flash drive to use the FAT32 file system. When you try to start the
computer from this USB flash drive, the startup process stops responding, and the
screen is black.

Cause
This issue occurs because the USB flash drive is listed as removable media. Therefore,
the Windows operating system doesn't create a master boot record (MBR) on the USB
flash drive when you format the flash drive to use the FAT32 file system. The USB flash
drive is treated as a super floppy disk. The FAT32 startup code doesn't support starting a
computer from a super floppy disk without an MBR.

The BIOS tries to transfer the control of the startup from the USB flash drive to the
FAT32 startup code. However, the FAT32 startup code doesn't support this scenario.

Workaround
To work around this issue, use the Diskpart command prompt utility to create and
format the boot partition on the USB flash drive.

For more information about how to use Diskpart , see DiskPart Command-Line Options.

How to differentiate between the MBR and the

boot sector
Currently, the Windows operating system uses signatures at offset 3 in the boot sector
to determine whether the sector is a boot sector. These signatures don't appear in the
MBR. The signatures are as follows:

FAT16: MSDOS5.0
FAT32: MSDOS5.0
NTFS: NTFS

How to determine whether the boot sector is

FAT32, FAT16, or NTFS
Check two strings in the boot sector to determine if the USB flash drive was formatted
by using one of the following file systems:

FAT32
FAT16
NTFS

If the strings contain FAT32, FAT16, or NTFS, the boot sector was formatted in that
particular file system format.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you use the
DiskPart break command to break a
mirrored set
Article • 12/26/2023

This article describes an issue where an error occurs when you use the DiskPart break
command to break a mirrored set.

Applies to: Windows Server 2012 R2

Original KB number: 331494

Symptoms
When you use the DiskPart text-mode command interpreter (Diskpart.exe) and you
select a mirrored volume and then use the break command to break the mirrored
volume in two volumes, you may receive one of the following error messages:

The arguments you specified for this command are not valid.

-or-

The disk management services could not complete the operation.

Cause
This behavior may occur if one of the two disks that contain the mirrors is missing and
you're using incorrect syntax for the break command.

Resolution
To resolve this behavior, use the disk parameter to refer to the missing disk, and use the
nokeep parameter.

Without the nokeep parameter, the break command tries to convert both mirrors to
simple volumes, retaining the data. If one of the disks is missing, this isn't possible. By
using the nokeep parameter, you retain only one half of the mirror as a simple volume,
and the other half is deleted and converted to free space. Neither volume receives the
focus.
For example, select the mirrored volume, issue the "detail volume" command, then
break the mirror as follows:

Console

diskpart> List Volume

Volume ### Ltr Label Fs Type Size Status Info

---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D data_vol NTFS Mirror 737 KB Failed Rd
Volume 1 C system NTFS Simple 3000 MB Boot

diskpart> select volume 0

Volume 0 is the selected volume.

Diskpart> detail volume

Disk ### Status Size Free Dyn Gpt

---------- ------- ------- --- --- ---
Disk 1 Online 1023 MB 737 KB *
Disk M0 Missing 1022 MB 0 B *

In this example, the correct command to break the mirrored volume is:
Diskpart> break disk=m0 nokeep

After you issue this command, the mirror on Disk 1 is converted to a simple volume, and
the reference to the missing mirror is deleted from the Logical Disk Management (LDM)
database.

Status
This behavior is by design.

More information
For additional information about using DiskPart to manage disks, click the following
article number to view the article in the Microsoft Knowledge Base:

300415 A Description of the DiskPart Command-Line Utility

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Configure a Low Disk Space Alert by
Using the Performance Logs and Alerts
Feature
Article • 12/26/2023

This article describes how to configure a Low Disk Space Alert by using the Performance
Logs and Alerts Feature.

Applies to: Windows Server 2003

Original KB number: 324796

Summary
This step-by-step article describes how to create and configure a low-disk-space alert by
using the Performance Logs and Alerts feature in Microsoft Windows Server 2003.

Create an Alert in System Monitor to Track Free Disk

Space
1. Click Start, point to Administrative Tools, and then click Performance.

2. Expand Performance Logs and Alerts.

3. Right-click Alerts, and then click New Alert Settings.

4. In the New Alert Settings box, type a name for the new alert (for example, Free disk
space), and then click OK.

The AlertName dialog box appears, in which you configure settings for the alert
that you created.

5. Click the General tab, and then in the Comment box, type Monitors free disk space
on logical drive.

Configure the Alert

1. Click Add to open the Add Counters dialog box.

2. Click Select counters from computer, and then select your computer in the list.
 3. In the Performance object box, click LogicalDisk.

4. Click Select counters from list, and then click % Free Space.

5. Click Select interfaces from list, and then click the logical drive or volume that you
want to monitor.

6. Click Add to add the counter, and then click Close.

7. In the Alert when the value is box, click Under, and then type the value that you
want in the Limit box. For example, to trigger an alert message when disk space is
under 1 megabyte (MB), type 1000.

8. Accept the default value of 5 seconds in the Sample data interval, or specify the
value that you want.

9. Click Apply.

10. Click the Action tab, and then specify the action or actions that you want to
perform when an alert occurs, as follows:

If you want the Performance Logs and Alerts service to create an entry in the
application log of event viewer when an alert occurs, click to select the Log
an entry in the application event log check box.
If you want the Performance Logs and Alerts service to trigger the Messenger
service to send a message, click to select the Send a network message to
check box, and then type the IP address or name of the computer on which
the alert should be displayed.
To run a counter log when an alert occurs, click to select the Start
performance data log check box, and then specify the counter log that you
want to run.
To run a command or program when an alert occurs, click to select the Run
this program check box, and then type the file path and name of the
program or command that you want to run. Or, click Browse to locate the file.

When an alert occurs, the service creates a process and runs the specified
command file. The service also copies any command-line arguments that you
define to the command line that is used to run the file. Click Command Line
Arguments , and then click to select the appropriate check boxes to include the

arguments that you want to implement when the program is run.

11. Click Apply.

 12. Click the Schedule tab, and then specify the start and stop parameters for the scan,
as follows:

a. Under Start scan, do one of the following steps:

Click Manually if you want to manually start the scan. After you select this
option, right-click the alert in the right pane, and then click Start to start
the scan.
Click At to start the scan at a specific time and date, and then specify the
time and date that you want.

b. Under Stop scan, do one of the following steps:

Click Manually if you want to manually stop the scan. After you click this
option, right-click the alert in the right pane, and then click Stop to stop
the scan.
Click After to stop the scan after a specified duration, and then specify the
time interval that you want.
Click At to stop the scan at a specific time and date, and then specify the
time and date that you want.

c. If you want to start a new scan after the alert scan is complete, click After, and
then click to select the Start a new scan check box.

13. Click OK.

Troubleshooting
After you complete the procedures in this article, monitoring starts at its scheduled time
and sends alert messages when the threshold is reached or passed. However, the alert
does not automatically restart each time after you restart the computer. To force the
alert to automatically restart after you restart the computer, or after you log off and log
on, follow these steps:

1. Click Start, point to Administrative Tools, and then click Performance.

2. Expand Performance Logs and Alerts.
3. Click Alerts
4. In the right pane, right-click the alert that you created, and then click Properties.
5. Click the Schedule tab.
6. Under Stop scan, click After (if it is not already selected), and then set this value to
a large number of days.
The maximum value is 100,000. 7. Click to select the Start a new scan check box. 8. Click
OK. The alert runs continuously, even after you restart or log off and then log on to the
computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Disk Defragmenter limitations in
Windows
Article • 12/26/2023

This article describes the Disk Defragmenter limitations.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 227463

Summary
The Disk Defragmenter tool is based on the full retail version of Diskeeper by Diskeeper
Corporation. The version that is included with Windows provides limited functionality in
maintaining disk performance by defragmenting volumes that use the FAT, the FAT32, or
the NTFS file system.

More information
This version has the following limitations:

It can defragment only local volumes.

It can defragment only one volume at a time.
It cannot defragment one volume while scanning another.
It cannot be scheduled.
It can run only one Microsoft Management Console (MMC) snap-in at a time.

The third-party products that are discussed in this article are manufactured by
companies that are independent of Microsoft. Microsoft makes no warranty, implied or
otherwise, regarding the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Distributed Link Tracking on Windows-
based domain controllers
Article • 12/26/2023

This article describes how you can use the Distributed Link Tracking services in Windows
to track the creation and movement of linked files across NTFS-formatted volumes and
servers.

Applies to: Windows Server 2012 R2

Original KB number: 312403

An overview of Distributed Link Tracking

You can use the Distributed Link Tracking Server service and the Distributed Link
Tracking Client service to track links to files on NTFS-formatted partitions. Distributed
Link Tracking tracks links in scenarios where the link is made to a file on an NTFS
volume, such as shell shortcuts and OLE links. If that file is renamed, moved to another
volume on the same computer, moved to another computer, or moved in other similar
scenarios, Windows uses Distributed Link Tracking to find the file. When you access a
link that has moved, Distributed Link Tracking locates the link; you're unaware that the
file has moved, or that Distributed Link Tracking is used to find the moved file.

Distributed Link Tracking consists of a client service and a server service. The Distributed
Link Tracking Server service runs exclusively on Windows Server-based domain
controllers. It stores information in Active Directory, and it provides services to help the
Distributed Link Tracking Client service. The Distributed Link Tracking Client service runs
on all Windows 2000-based and Microsoft Windows XP-based computers, including
those in workgroup environments or those that are not in a workgroup. It provides the
sole interaction with Distributed Link Tracking servers.

Distributed Link Tracking clients occasionally provide the Distributed Link Tracking
Server service with information about file links, which the Distributed Link Tracking
Server service stores in Active Directory. Distributed Link Tracking clients also may query
the Distributed Link Tracking Server service for that information when a shell shortcut or
an OLE link cannot be resolved. Distributed Link Tracking clients prompt the Distributed
Link Tracking server to update links every 30 days. The Distributed Link Tracking Server
service scavenges objects that have not been updated in 90 days

When a file that is referenced by a link is moved to another volume (on the same
computer or on a different computer), the Distributed Link Tracking client notifies the
Distributed Link Tracking server, which creates a linkTrackOMTEntry object in Active
Directory. A linkTrackVolEntry object is created in Active Directory for every NTFS volume
in the domain.

７ Note

In Windows Server 2008 and newer, the Distributed Link Tracking Server Service is
not included in Windows anymore. So you can safely remove the objects from
Active Directory.

Distributed Link Tracking and Active Directory

Distributed Link Tracking objects are replicated among all domain controllers in the
domain that is hosting the computer account and all global catalog servers in the forest.
The Distributed Link Tracking Server service creates objects in the following
distinguished name path:

CN=FileLinks,CN=System,DC= domain name container of Active Directory

Distributed Link Tracking objects exist in the following two tables under the
CN=FileLinks,CN=System folder:

CN=ObjectMoveTable,CN=FileLinks,CN=System,DC= domain name:

This object stores information about linked files that have been moved in the domain.

CN=VolumeTable,CN=FileLinks,CN=System,DC= domain name:

This object stores information about each NTFS volume in the domain.

Distributed Link Tracking objects consume little space individually, but they can
consume large amounts of space in Active Directory when they are allowed to
accumulate over time.

If you disable Distributed Link Tracking and delete the Distributed Link Tracking objects
from Active Directory, the following behavior may occur:

Active Directory database size may be reduced (this behavior occurs after the
objects have been tombstoned and garbage collected, and after you perform an
offline defragmentation procedure).
Replication traffic between domain controllers may be reduced.
Distributed Link Tracking Server service
defaults on Windows Server-based domain
controllers
In Windows 2000, Windows XP, and Windows Server 2003, the start value for the
Distributed Link Tracking Client service is set to Automatic. On Windows 2000-based
servers, the Distributed Link Tracking Server service starts manually, by default. However,
if you use Dcpromo.exe to promote a server to a domain, the Distributed Link Tracking
Server service is configured to start automatically.

For Windows Server 2003-based servers, the Distributed Link Tracking Server service is
disabled by default. When you use Dcpromo.exe to promote a server to a domain, the
Distributed Link Tracking Server service is not configured to start automatically. When a
Windows 2000-based domain controller is upgraded to Windows Server 2003, the
Distributed Link Tracking Server service is also disabled during the upgrade. If you are an
administrator and you want to use the Distributed Link Tracking Server service, you must
either use Group Policy or you must manually set the service to start automatically. In
addition, the Distributed Link Tracking Client service on computers that are running
Windows Server 2003 or Windows XP SP1 does not try to use the Distributed Link
Tracking Server service by default. If you want to configure those computers to take
advantage of the Distributed Link Tracking Server service, enable the Allow Distributed
Link Tracking clients to use domain resources policy setting. To do so, open the
Computer Configuration/Administrative Templates/System node in Group Policy.

Microsoft recommendations for Distributed

Link Tracking on Windows 2000-based servers
Microsoft recommends that you use the following settings with Distributed Link
Tracking on Windows 2000-based servers:

1. Turn off the Distributed Link Tracking Server service on all domain controllers (this
is the default configuration on all Windows Server 2003-based servers).

Because of replication overhead and the space that FileLinks tables uses in Active
Directory, Microsoft recommends that you turn off the Distributed Link Tracking
Server service on Active Directory domain controllers. To stop the service, use any
of the following methods:

In the Services snap-in (Services.msc or compmgmt.msc), double-click the

Distributed Link Tracking Server service, and then click Disabled in the
 Startup type box.

Define the Startup value in the Computer Configuration/Windows

Settings/System Services node of Group policy.

Define the policy settings on an organizational unit that hosts all Windows
2000 domain controllers.

Restart the domain controllers after the policy has replicated so that the policy will
be applied. If you do not restart the domain controllers, you will have to manually
stop the service on each domain controller.

2. Delete Distributed Link Tracking objects from Active Directory domain controllers.

See the "How to Delete Distributed Link Tracking Object" section of this article for
more information about how to delete Distributed Link Tracking objects. It is
recommended that you delete objects after you disable the Distributed Link
Tracking Server service.

７ Note

The Directory Information Tree (DIT) size on domain controllers is not reduced
until the following actions are completed.

a. Objects are deleted from the directory service.

７ Note

Deleted objects are stored in the Deleted Objects container until the
tombstone lifetime expires. The default value for a tombstone lifetime is 60
days. The minimum value is two days. By default, the value is 180 days for
new forests that are installed together with Windows Server 2003 Service
Pack 1 or a later version of Windows Server 2003.

Unless you have strong Active Directory replication monitoring, we recommend

that you use the 180-day value. Do not reduce this value to handle DIT size
problems. If you have problems with database size, contact Microsoft Customer
Support Services.

b. Garbage collection has run to completion.

c. You use Ntdsutil.exe to defragment the Ntds.dit file in Dsrepair mode.

How to delete Distributed Link Tracking objects
It is not critical that you manually delete the Distributed Link Tracking objects after you
stop the Distributed Link Tracking server service unless you have to reclaim the disk
space that is being consumed by these objects as quickly as possible. Distributed Link
Tracking clients prompt the Distributed Link Tracking server to update links every 30
days. The Distributed Link Tracking Server service scavenges objects that have not been
updated in 90 days.

When you run the Dltpurge.vbs VBScript, all Active Directory objects that are used by
the Distributed Link Tracking Server service are deleted from the domain where the
script is run. You must run the script on one domain controller for each domain in a
forest. To run Dltpurge.vbs:

1. Obtain the Dltpurge.vbs script from Microsoft Product Support.

2. Stop the Distributed Link Tracking Server service on all domain controllers in the
domain that is being targeted by Dltpurge.vbs.

3. Use administrator privileges to log on to the console of a domain controller or a

member computer in the domain that is being targeted by Dltpurge.vbs.

4. Use the following syntax to run Dltpurge.vbs from a command line:

Console

cscript dltpurge.vbs -s myserver -d dc=mydomain,dc=mycompany,dc=com

In this command line:

-s is the DNS host name of the domain controller on which you want to
delete Distributed Link Tracking objects.
-d is the distinguished name path of the domain on which you want to delete
Distributed Link Tracking objects.

5. Perform an offline defragmentation procedure of the Ntds.dit file after the objects
have been tombstoned and garbage collected. For more information about the
garbage collection process, click the following article number to view the article in
the Microsoft Knowledge Base:

198793 The Active Directory database garbage collection process

A sample customer experience

The worst-case scenario that is described in this section illustrates some issues to
consider when you delete a large number of Distributed Link Tracking objects in a large
production domain.

Trey Research, a fictitious Fortune 500 customer with over 40,000 employees worldwide
deploys a single Active Directory forest that consists of an empty root domain with child
domains that map major geographic regions of the world (North America, Asia, Europe,
and so on). The largest domain in the forest contains about 35,000 user accounts and
the same number of computer accounts.

The Ntds.dit files were placed on 18-gigabyte (GB) raid arrays. Since the initial
deployment of Windows 2000, the global catalog files have grown to 17 GB.

Trey Research wants to deploy Windows Server 2003 within the next 10 days but needs
at least 1.5 GB of available disk space on the database partition before they initiate the
upgrade. They need this much disk space because Adprep.exe is known to add three to
five inherited aces depending on the hotfixes and service packs that have been
previously installed. The following conditions contribute to the large global catalog size
or the lack of disk space:

Condition 1: Trey Research was an early adopter of Windows 2000 and the largest
drives that they received from their preferred hardware vendor were 9 GB or 18 GB
when they were configured in a raid array. Current drives are double the size for
half the cost.

Condition 2: DNS scavenging was not enabled on Active Directory-integrated DNS

zones that were delegated to each domain in the forest.

Condition 3: Domain users were allowed to create computer accounts in the

domain. Administrators did not have a recurring process to identify and delete
orphaned computer accounts.

Condition 4: Over the course of time, security descriptors were defined by

administrators, service packs, and hotfixes on root naming context (NC) heads
(cn=schema, cn=configuration, cn= domain) and other containers that host
thousands of objects in Active Directory. In addition, auditing was enabled on the
same partitions. When you set permissions and enable auditing on objects in
Active Directory, the size of the database increases. The tool that prepares
Windows 2000 forests and domains for Windows Server 2003-based domain
controllers (Adprep) also adds inherited aces; therefore, Trey Research needed to
free space on the disk drive before they upgraded the domain.
Condition 5: Trey Research did not regularly perform offline defragmentation
procedures of Ntds.dit files in Dsrepair mode.

Condition 6: When the CN=FileLinks,CN=System,DC= domain name container in

the largest domain was reviewed, it revealed over 700,000 Distributed Link Tracking
objects. The security descriptor on each Distributed Link Tracking object was
approximately 2 kilobytes (KBs). Each of these conditions was evaluated for its
contribution to the 17-GB .dit file:

Condition 1: Trey Research decided not to deploy new drives because of the cost
and the time it would take to do so. Also, they only needed the disk space
temporarily because they expected the Active Directory Database to shrink after
they upgraded to Windows Server 2003 and the Single Instance Store (SIS) process
was completed (SIS implements a more efficient storage of permissions in Active
Directory databases).

Conditions 2 and 3: Trey Research decided that these conditions were the best
practices; however, even if Trey Research implemented them, they would not
achieve the needed results. They decided to enable DNS scavenging because it is
easily implemented.

Condition 4: Trey Research realized that if they redefined security descriptors and
system access control lists (SACLs), they would achieve the results they are looking
for, but they decided that this procedure would be time consuming to implement
until they could thoroughly test the size reduction, replication overhead and, most
importantly, program/administration compatibility in the lab scenario that mirrors
the production environment.

Because Trey Research has deployed Windows 2000 SP2 and a few hotfixes, they
expected that the incremental inherited aces that were added by Adprep (to
objects in the domain NC) could be as small as 300 megabytes (MBs). They could
verify this behavior in a lab environment that is used to test upgrades of the
production forest.

Condition 5: Trey Research realized that if they performed an offline

defragmentation procedure, they might not recover "whitespace" in the Ntds.dit
file. In fact, Trey Research administrators noticed an increase in database size
immediately after they completed the offline defragmentation procedure. This
behavior occurred because of an inefficiency in the Windows 2000 database
engine; this engine is enhanced in Windows Server 2003.

Condition 6: Trey Research agreed that the obvious course of action would be to
perform a simple bulk deletion of all of the Distributed Link Tracking objects from
 the CN=FileLinks,CN=System,DC= domain name container on a domain controller
in each domain in the forest. However, they realized that if they did so, additional
disk space would not be freed up until the objects had been tombstoned and
garbage collected, and until they completed an offline defragmentation procedure
on each domain controller in that domain. While the tombstone lifetime value can
be set to values as low as two days, several domain controllers in the Trey Research
forest were offline as they awaited hardware and software updates. If objects are
tombstoned before end-to-end replication can take place, deleted objects may be
reanimated or inconsistent data may be reported among global catalog servers in
the forest. To provide immediate relief, Trey Research performed the following
procedure:

1. They removed the default security descriptor for Distributed Link Tracking schema
class objects and replaced it with a single security principal (user account).
2. They wrote a VBScript program that removed all of the existing security
descriptors, and then replaced them with an explicit ace for a single security
principal.
3. They deleted Distributed Link Tracking objects in 10,000-unit increments with a
three-hour delay between each object deletion.
4. They performed an offline defragmentation procedure on each domain controller
in the domain after all Distributed Link Tracking objects were deleted. When Trey
Research removed the descriptor and performed the defragmentation procedure,
the database recovered about 1.5 GB of disk space on all domain controllers in the
domain. This amount of space was enough to comfortably run the Adprep tool and
upgrade all Windows 2000-based domain controllers and global catalogs to
Windows Server 2003.

After Trey Research upgraded the operating system to Windows Server 2003, more disk
space was freed when the single instance store feature in Windows Server 2003 reduced
database size to about 8 GB (you must perform an offline defragmentation procedure to
get these results). More space was recovered after the TSL interval expired, Distributed
Link Tracking objects were garbage collected, and they performed an offline
defragmentation procedure.

Trey Research promoted a new replica Windows 2000-based domain controller into the
domain and placed the computer account in a different organizational unit than they
typically used. In two days, around 8,000 Distributed Link Tracking objects were present
on the Windows 2000-based domain controller. Trey Research either stopped
Distributed Link Tracking or created a policy to stop the service, and then linked the
policy to organizational units that host Windows 2000-based domain controllers. Finally,
Trey Research used Dltpurge.vbs to mark the remaining Distributed Link Tracking objects
for deletion.
Anatomy of DLT object deletion
DLT objects themselves contain few attributes and use little space in Active Directory.
When an object is marked for deletion (tombstoned), all the unnecessary attributes are
stripped away, except for those necessary to track the object until it is purged from
Active Directory.

In the case of the link-tracking objects, marking the object for deletion only amounts to
two attributes being removed: dscorepropagationdata and objectcategory. The deletion
of the two attributes results in an initial savings of 34 bytes. However, the process of
marking the link-tracking object for deletion also updates the object by adding an
IS_DELETED attribute (4 bytes), and by mangling the RDN and the "common name"
attributes, causing each of those attributes to grow by about 80 bytes. In addition, the
"replication metadata" attribute also grows by about 50 bytes to reflect the updates
performed on this object. So, by marking a link-tracking object for deletion, the object
will end up growing by approximately 200 bytes. The NTDS.DIT will not exhibit a
reduction in size until the deleted objects have tombstoned, been garbage collected
and an offline defragmentation performed.

７ Note

If the service is turned off as this article recommends, the autocleanup does not
occur.

Text version of Dltpurge.vbs

To use this script:

1. Copy all of the text between the <Start Copy Here> tag and the <End Copy Here>
tag in this article, and then paste the text to a ASCII text editor file (for example, a
Microsoft Notepad file).
2. Save the file as "Dltpurge.vbs". 3 Complete the procedure that is described in How
to delete Distributed Link Tracking objects

Visual Basic Script

<Start Copy Here>

'===========================================================================
===
'===========================================================================
===
'
' Copyright (C) 2001 by Microsoft Corporation. All rights reserved.
'
' This script deletes all Active Directory objects used by the
' Distributed Link Tracking Server service.
'
' It is assumed that the DLT Server service has been disabled,
' and you wish to recover the DIT space these objects occupy.
'
' Usage: cscript DltPurge.vbs <options>
' Options: -s ServerName
' -d distinguishedname dc=mydomain,dc=mycompany,dc=com
' -b BatchSize BatchDelayMinutes
' -t (optional test mode)
'
' The objects are deleted in batches - BatchSize objects are deleted,
' then there is a BatchDelayMinutes delay before the next batch.
'
'===========================================================================
===
'===========================================================================
===

Option Explicit

'
' Globals, also local to main.
'
Dim oProvider
Dim oTarget
Dim sServer
Dim sDomain
Dim bTest

Dim BatchSize
Dim BatchDelayMinutes

'
' Set defaults
'

BatchSize = 1000
BatchDelayMinutes = 15
bTest = False

'===========================================================================
===
'
' ProcessArgs
'
' Parse the command-line arguments. Results are set in global variables
' (oProvider, oTarget, sServer, sDomain, BatchSize, and
BatchDelayMinutes).
'
'===========================================================================
===
public function ProcessArgs

Dim iCount
Dim oArgs

on error resume next

'
' Get the command-line arguments
'

Set oArgs = WScript.Arguments

if oArgs.Count > 0 then

'
' We have command-line arguments. Loop through them.
'

iCount = 0
ProcessArgs = 0

do while iCount < oArgs.Count

select case oArgs.Item(iCount)

'
' Server name argument
'

case "-s"

if( iCount + 1 >= oArgs.Count ) then

Syntax
ProcessArgs = -1
exit do
end if

sServer = oArgs.Item(iCount+1)
if Len(sServer) > 0 then sServer = sServer & "/"
iCount = iCount + 2

'
' Enable testing option
'

case "-t"

iCount = iCount + 1
bTest = True

'
' Domain name option
 '

case "-d"

if( iCount + 1 >= oArgs.Count ) then

Syntax
ProcessArgs = -1
Exit Do
end if

sDomain = oArgs.Item(iCount+1)
iCount = iCount + 2

'
' Batching option (batch size, batch delay)
'

case "-b"

if( iCount + 2 >= oArgs.Count ) then

Syntax
ProcessArgs = -1
exit do
end if

Err.Clear

BatchSize = CInt( oArgs.Item(iCount+1) )

BatchDelayMinutes = CInt( oArgs.Item(iCount+2) )

if( Err.Number <> 0 ) then

wscript.echo "Invalid value for -b argument" &
vbCrLf
Syntax
ProcessArgs = -1
exit do
end if

iCount = iCount + 3

'
' Help option
'

case "-?"
Syntax
ProcessArgs = -1
exit do

'
' Invalid argument
'

case else
 ' Display the syntax and return an error

wscript.echo "Unknown argument: " & oArgs.Item(iCount) &

vbCrLf
Syntax
ProcessArgs = -1
Exit Do

end select
loop

else

'
' There were no command-line arguments, display the syntax
' and return an error.
'

Syntax
ProcessArgs = -1

end if

Set oArgs = Nothing

end function ' ProcessArgs

'===========================================================================
===
'
' Syntax
'
' Show the command-line syntax
'
'===========================================================================
===

public function Syntax

wscript.echo vbCrLf & _

"Purpose: Delete Active Directory objects from
Distributed Link Tracking" & vbCrLf & _
" Server service (Assumes that DLT Server has
been disabled" & vbCrLf & _
" on all DCs)" & vbCrLf & _
vbCrLf & _
"Usage: " & wscript.scriptname & " <arguments>" &
vbCrLf & _
vbCrLf & _
"Arguments: -s Server" & vbCrLf & _
" -d FullyQualifiedDomain" & vbCrLf & _
" -b BatchSize BatchDelayMinutes (default to
1000 and 15)" & vbCrLf & _
" -t (optional test mode, nothing is deleted)"
& vbCrLf & _
 vbCrLf & _
"Note: Objects are deleted in batches, with a delay
between each" & vbCrLf & _
" batch. The size of the batch defaults to
1000 objects, and" & vbCrLf & _
" the length of the delay defaults to 15
minutes. But these" & vbCrLf & _
" values can be overridden using the -b
option." & vbCrLf & _
vbCrLf & _
"Example: " & wscript.scriptname & " -s myserver -d
distinguishedname dc=mydomain,dc=mycompany,dc=com "

end function ' Syntax

'===========================================================================
===
'
' PurgeContainer
'
' Delete all objects of the specified class in the specified container.
' This subroutine is called once for the volume table and once for
' the object move table.
'
'===========================================================================
===

sub PurgeContainer(ByRef oParent, ByVal strClass)

dim oChild
dim iBatch
dim iTotal

On Error Resume Next

iTotal = 0
iBatch = 0

' Loop through the children of this container

For Each oChild in oParent

'
' Is this a DLT object?
'

if oChild.Class = strClass Then

'
' Yes, this is a DLT object, it may be deleted
'
 iTotal = iTotal + 1
iBatch = iBatch + 1

'
' Delete the object
'

if bTest then
wscript.echo "Object that would be deleted: " &
oChild.adspath
else
oParent.Delete oChild.Class, oChild.Name
end if

'
' If this is the end of a batch, delay to let replication
' catch up.
'

if iBatch = BatchSize then

iBatch = 0

wscript.stdout.writeline "" ' ignored by wscript

wscript.echo "Deleted " & BatchSize & " objects"
wscript.echo "Pausing to allow processing (will restart at "
& DateAdd("n", BatchDelayMinutes, Time) & ")"

wscript.sleep BatchDelayMinutes * 60 * 1000

wscript.echo "Continuing ..."

end if

else

' oChild.Class didn't match strClass

wscript.echo "Ignoring unexpected class: " & oChild.Class

end if

oChild = NULL

Next

wscript.echo "Deleted a total of " & iTotal & " objects"

end sub ' PurgeContainer

'===========================================================================
===
'
' Main
'
'===========================================================================
===

if (ProcessArgs=-1) then wscript.quit

on error resume next

'
' Explain what's about to happen
'

wscript.stdout.writeline "" ' ignored by wscript

wscript.echo "This script will purge all objects from the Active Directory"
& vbCrLf & _
"used by the Distributed Link Tracking Server service
(trksvr)." & vbCrLf & _
"It is assumed that this service has already been disabled on"
& vbCrLf & _
"all DCs in the domain."

'
' When running in cscript, pause to give an opportunity to break out
' (These 3 lines are for cscript and ignored by wscript.)
'

wscript.stdout.writeline ""
wscript.stdout.writeline "Press Enter to continue ..."
wscript.stdin.readline

'
' Get an ADSI object
'

Set oProvider = GetObject("LDAP:")

'
' Purge the System/FileLinks/ObjectMoveTable
'

wscript.stdout.writeline "" ' ignored by wscript

wscript.echo "Purging ObjectMoveTable"

Set oTarget = oProvider.OpenDSObject( "LDAP://" & sServer &

"cn=ObjectMoveTable,CN=FileLinks,CN=System," & sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION

call PurgeContainer( oTarget, "linkTrackOMTEntry" )

oTarget = NULL

'
' Purge the System/FileLinks/VolumeTable
'

wscript.stdout.writeline "" ' ignored by wscript

 wscript.echo "Purging VolumeTable"

Set oTarget = oProvider.OpenDSObject("LDAP://" & sServer &

"cn=VolumeTable,CN=FileLinks,CN=System," & sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION
call PurgeContainer( oTarget, "linkTrackVolEntry" )
oTarget = NULL

oProvider = NULL
<END Copy Here>

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Establish and boot to GPT mirrors in 64-
bit Windows
Article • 12/26/2023

This article describes how to successfully set up dynamic boot partition mirroring on
GUID Partition Table (GPT) disks.

Applies to: Windows Server 2012 R2

Original KB number: 814070

Summary
Unlike Master Boot Record (MBR) mirrors in 32-bit Windows, there are more steps to
successfully create and boot to mirrored boot volumes on GPT disks. This article also
describes how to recover after a primary disk failure if the shadow disk did not already
have an EFI partition established. The disk must have an EFI partition to boot.

You must have the built-in Diskpart.exe and Bootcfg.exe utilities to create bootable
mirror volumes on GPT disks. You can do some of these steps with the Disk
Management console, but others you can do only with the built-in Diskpart.exe utility.

For consistency and ease of use, this article uses the Diskpart.exe utility to perform the
steps. For help with any Diskpart.exe commands, start Diskmgmt.msc, and then open
the help topics on the Help menu.

The steps are performed with real examples. The steps show the expected results
returned from each command. Disk 0 is the primary system and boot drive. Disk 1 is the
shadow drive.

Prepare the shadow drive for mirroring

Before you set up boot volume mirroring, it is a good idea have another GPT disk in the
computer that contains an Extensible Firmware Interface (EFI) partition. The EFI partition
contains the system files used to boot the operating system. If the primary system drive
(disk-0) fails, you can use the EFI partition on the shadow drive (disk-1) to boot. This
step creates and prepares new EFI and Microsoft Reserved (MSR) partitions on the
shadow drive. You can use only the Diskpart.exe utility to create the required EFI and
MSR partitions. You cannot use the Disk Management console to create or mirror EFI or
MSR partitions.
Before you start, make sure that you have another BASIC disk with all unallocated free
space of equal or greater capacity than the primary disks system and boot partitions. If
you already converted the spare drive to dynamic, revert it back to basic before you
follow these steps.

1. At a command prompt, run the Diskpart.exe utility.

This starts the diskpart console. After it is initialized, DISKPART> is displayed. It

waits for your input commands.

2. Select the disk that you want to be the shadow drive, and then convert the drive to
GPT. In this example, disk 1 is used for the mirror (shadow) drive.

７ Note

The disk that you select must not contain any data partitions and must
be a raw basic disk with only unallocated space of equal or greater
capacity than the primary system disk.
The following are the commands that you type at the command prompt.

DISKPART> Select disk 1

Disk 1 is now the selected disk.

DISKPART> Convert GPT

Diskpart successfully converted the selected disk to GPT format.

DISKPART> List partition

Partition ### Type Size Offset

Partition 1 Reserved 32 MB 17 KB

７ Note

If you show more than one partition at this point, you have either
selected the wrong drive, or you did not start with a raw drive. Correct
this before you continue, or data loss may occur.
3. Select partition 1 on disk 1, then delete it - you must use the override command to
delete the Microsoft Reserved (MSR) partition. You will re-create a new MSR
partition after you create the required EFI partition.

DISKPART> Select partition 1

Partition 1 is now the selected partition.

DISKPART> Delete partition override

Diskpart successfully deleted the selected partition.

4. Select disk-0, and then list the partitions on disk-0. With the output of the list
command, create new EFI and MSR partitions on disk 1 that are the same sizes as
those on disk 0.

DISKPART> Select disk 0

Disk 0 is now the selected disk.

DISKPART> List partition

Partition ### Type Size Offset

Partition 1 System 204 MB 32 KB <---- EFI PARTITION

Partition 2 Primary 4996 MB 204 MB
Partition 3 Reserved 32 MB 9 GB <---- MSR PARTITION

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> create partition efi size=204

Diskpart succeeded in creating the specified partition.

DISKPART> create partition msr size=32

Diskpart succeeded in creating the specified partition.

DISKPART> list partition

 Partition ### Type Size Offset

Partition 1 System 204 MB 17 KB <---- NEW EFI PARTITION ON SHADOW

*Partition 2 Reserved 32 MB 204 MB <---- NEW MSR PARTITION ON
SHADOW

5. Select the EFI partition on the shadow drive, and then assign a letter to the EFI
partition so it can be formatted. In this example, the drive letter S is assigned to
the shadow EFI partition. You can use any available drive letter for this step.

DISKPART> Select disk 1

Disk 1 is now the selected disk.

DISKPART> Select partition 1

Partition 1 is now the selected partition.

DISKPART> Assign letter=S

Diskpart successfully assigned the drive letter or mount point.

6. Open a new command prompt, and then use the format utility to format the EFI
partition (S:) with the FAT file system. You must do this so that you can copy the
system files from the primary EFI partition to this new EFI partition. Do not format
with NTFS. The system cannot boot from an EFI partition unless it is formatted with
the FAT file system.

C:\> format s: /fs:fat /q /y

The type of the file system is RAW.

The new file system is FAT.
QuickFormatting 204M
Initializing the File Allocation Table (FAT)...
Format complete.

213,680,128 bytes total disk space.

213,680,128 bytes available on disk.

4,096 bytes in each allocation unit.

52,168 allocation units available on disk.

16 bits in each FAT entry.

 Volume Serial Number is EA34-03C7

7. Press ALT+TAB to return to the diskpart command window. Select the EFI partition
on the primary drive (disk-0), and then assign a drive letter to that EFI partition. In
this example, the drive letter P is assigned to the primary EFI partition on disk-0.
You can use any available drive letter for this step.

DISKPART> Select disk 0

Disk 0 is now the selected disk.

DISKPART> Select partition 1

Partition 1 is now the selected partition.

DISKPART> Assign letter=P

Diskpart successfully assigned the drive letter or mount point.

8. Press ALT+TAB again to return to the other command prompt. Use the xcopy
command to copy the system files from the primary EFI partition (P:) to the
Shadow EFI partition (S:). You must do this to make sure that the shadow drive can
boot the system if disk-0 fails. Make sure that you use the correct drive letters if
you used different letters for your EFI partitions.

C:\> xcopy p:\*.* s: /s /h

p:\EFI\Microsoft\WINNT50\Boot0003
p:\EFI\Microsoft\WINNT50\ia64ldr.efi

p:\EFI\Microsoft\EFIDrivers\fpswa.efi
p:\MSUtil\diskpart.efi

p:\MSUtil\fdisk.efi
p:\MSUtil\format.efi
p:\MSUtil\nvrboot.efi

7 File(s) copied

9. Remove the drive letters assigned to both EFI partitions. This step is optional,
because after a reboot they will not be re-assigned.

DISKPART> Select volume P

 Volume P is the selected volume.

DISKPART> Remove

Diskpart successfully removed the drive letter or mount point.

Repeat the steps for the S volume.

Convert the primary and shadow drives to

Dynamic
Before you can establish a mirror, both the primary (source) drive (Disk-0) and the
shadow (destination) drive (Disk-1) must be converted to Dynamic. After the disks are
Dynamic (after a reboot), you can then establish the mirror. You can do this step with
either the Disk Management console or the Diskpart.exe utility.

1. With Diskpart.exe, select the disk that you want to convert to dynamic, and then
convert it to dynamic. Perform this on both the shadow and primary GPT disks.
Start with the shadow disk.

DISKPART> Select disk 1

Disk 1 is now the selected disk

DISKPART> Convert dynamic

Diskpart successfully converted the selected disk to Dynamic format.

DISKPART> Select disk 0

Disk 0 is now the selected disk

DISKPART> Convert dynamic

You must reboot your computer to complete this operation.

DISKPART> Exit

Leaving Diskpart...
 2. Shut down and restart your computer to complete the conversion of the system
drive (disk-0) to dynamic. This may require two reboots.

Establish a mirror from the boot drive to the shadow

drive
After both the primary (disk-0) and shadow (disk-1) drives are dynamic, you can then
establish the mirror of the boot volume to the shadow drive. You can do this step with
either the Disk management console or the Diskpart.exe utility.

1. With Diskpart.exe, select the boot volume (C:), and then mirror the volume to the
shadow disk (disk-1).

DISKPART> Select volume C

Volume 1 is the selected volume.

DISKPART> add disk=1

Diskpart succeeded in adding a mirror to the volume.

2. Wait for the volume synchronization to complete, and then quit Diskpart.

Use Bootcfg.exe to add new EFI partition boot

entries to NVRAM
Now that you have successfully established the boot mirror, a new boot entry was
automatically added to NVRAM so that you can boot to the shadow drive. This new
entry is displayed as Boot Mirror C: - secondary plex on the boot menu. If you select it,
it will boot into the operating system on the shadow drive. However, if something were
to happen to any of the system files or the EFI partition itself on disk-0 or if disk-0 failed
completely, you would have to boot from the EFI partition on disk-1. Before this will
work, you have to add boot entries into NVRAM with the Bootcfg.exe utility.

1. At a command prompt, run the Bootcfg.exe utility to display the current boot
entries. You have one boot entry for the main operating system (boot entry id:1),
and one boot entry for the Mirror (shadow) drive (boot entry id:5).

C:> bootcfg

Boot Options
 Timeout: 30
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
O
CurrentBootEntryID: 5

Boot Entries

Boot entry ID: 1

OS Friendly Name: Windows 2003 Server, Enterprise OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 2

OS Friendly Name: LS120

Boot entry ID: 3

OS Friendly Name: CDROM

Boot entry ID: 4

OS Friendly Name: EFI Shell

Boot entry ID: 5

OS Friendly Name: Boot Mirror C: - secondary plex
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

2. Before you can add the new entries for the EFI partition and boot partition on the
shadow drive to NVRAM, you have to list the existing partitions on disk-0 so that
you can extract partition GUID information about the current EFI partition. Use the
bootcfg /list command against disk-0 to display all the partitions:

C:\> bootcfg /list 0

Partition table info for Disk: 0

 Partition No: 1
Partition Style: GPT
Starting offset: 32,256
Partition length: 213,825,024
Partition GUID: {68d298c0-1b6a-01c1-507b-9e5f8078f531}
GUID type: {c12a7328-f81f-11d2-ba4b-00a0c93ec93b}
Partition name: EFI system partition

Partition No: 2
Partition Style: GPT
Starting offset: 213,857,280
Partition length: 5,142,056,960
Partition GUID: {68d298c0-1b6a-01c1-f1b3-12714f758821}
GUID type: {af9b60a0-1431-4f62-bc68-3311714a69ad}
Partition name: LDM data partition

Partition No: 3
Partition Style: GPT
Starting offset: 9,153,031,680
Partition length: 1,048,576
Partition GUID: {73e47280-0d38-11d7-b47f-806e6f6e6963}
GUID type: {5808c8aa-7e8f-42e0-85d2-e1e90434cfb3}
Partition name: LDM metadata partition

Partition No: 4
Partition Style: GPT
Starting offset: 9,154,080,256
Partition length: 32,505,856
Partition GUID: {1ca4672d-a37c-4e12-bacb-c5ae97924965}
GUID type: {e3c9e316-0b5c-4db8-817d-f92df00215ae}
Partition name: Microsoft reserved partition

Make a note of the EFI partition GUID. {________-____-____-____-

____________} This will be used as the SOURCE GUID in a later command.

In this example, the value is {68d298c0-1b6a-01c1-507b-9e5f8078f531} and

will be used in a later command.

3. Use the bootcfg /list command against disk-1 to display all of its partitions:

C:\> bootcfg /list 1

Partition table info for Disk: 1

 Partition No: 1
Partition Style: GPT
Starting offset: 17,408
Partition length: 213,909,504
Partition GUID: {476688c5-8ebf-47d2-80e7-cf9d065edb81}
GUID type: {c12a7328-f81f-11d2-ba4b-00a0c93ec93b}
Partition name: EFI system partition

Partition No: 2
Partition Style: GPT
Starting offset: 213,926,912
Partition length: 1,048,576
Partition GUID: {b72d10f6-e94e-4a4d-bb8e-4da985cc1679}
GUID type: {5808c8aa-7e8f-42e0-85d2-e1e90434cfb3}
Partition name: LDM metadata partition

Partition No: 3
Partition Style: GPT
Starting offset: 214,975,488
Partition length: 32,505,856
Partition GUID: {824858f3-b8d5-4b4d-a3c7-18aac4442b7e}
GUID type: {e3c9e316-0b5c-4db8-817d-f92df00215ae}
Partition name: Microsoft reserved partition

Partition No: 4
Partition Style: GPT
Starting offset: 247,481,344
Partition length: 5,142,056,960
Partition GUID: {f3d11286-2582-4d76-889c-b82c346be44e}
GUID type: {af9b60a0-1431-4f62-bc68-3311714a69ad}
Partition name: LDM data partition

Make a note of the EFI partition GUID. {________-____-____-____-

____________} This will be used as the TARGET GUID in a later command.

In this example, the value is {476688c5-8ebf-47d2-80e7-cf9d065edb81} and

will be used in a later command.

4. Now you have the SOURCE and TARGET EFI GUID values that you have to clone the
boot entries in NVRAM. The new entries use the new EFI partition GUID on the
shadow drive to boot the system if disk-0 fails in any way. Use the bootcfg /clone
command to add new NVRAM boot entries with your source and target GUID
values recorded in steps 2 and 3.
 C:>bootcfg /clone /sg {68d298c0-1b6a-01c1-507b-9e5f8078f531} /tg
{476688c5-8ebf-47d2-80e7-cf9d06 5edb81} /d+ Cloned_Entry

INFO: Boot entry whose id is '1' successfully cloned.

INFO: Boot entry whose id is '5' successfully cloned.
SUCCESS: The operation completed successfully.

5. To see the new Cloned entries added to NVRAM, use the bootcfg command and
notice you now have seven entries instead of five. The bottom two entries are the
cloned entries and will use the EFI partition on the shadow drive (disk-1) to boot.

C:\>bootcfg

Boot Options

Timeout: 30
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS
CurrentBootEntryID: 5

Boot Entries

Boot entry ID: 1

OS Friendly Name: Windows 2003 Server, Enterprise
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 2

OS Friendly Name: LS120

Boot entry ID: 3

OS Friendly Name: CDROM

Boot entry ID: 4

OS Friendly Name: EFI Shell

Boot entry ID: 5

OS Friendly Name: Boot Mirror C: - secondary plex
OsLoadOptions: N/A
 BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 6

OS Friendly Name: Windows 2003 Server, Enterprise Cloned_Entry
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume3\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 7

OS Friendly Name: Boot Mirror C: - secondary plex Cloned_Entry
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume3\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Test-boot the shadow drive with the new boot

entries
After you have created the new boot entries in NVRAM, test the entries to make sure
that the system can boot to the shadow drive if disk-0 fails.

1. Perform a graceful shutdown and restart of Windows.

2. On the boot menu, select the boot entry named Boot Mirror C: - secondary plex
Cloned_Entry to boot to the shadow drive. The EFI partition on the shadow drive
will be used to boot the Windows operating system. Although you do not have to,
you can also turn off the computer, remove disk-0, and then redo the test to make
sure that the system will be bootable if the original system disk really fails and is
removed.

Recover a shadow boot drive with missing or

damaged EFI partition
If the original Windows operating system was software mirrored to a Dynamic GPT disk
that did not contain an EFI partition, or the EFI partition becomes damaged, or if the
primary system disk (disk-0) fails, you may receive the following error message when
you try to boot to the shadow disk:

LOADING.: Boot Mirror C: - Secondary plex

Load of Boot Mirror c: - secondary plex failed: Not Found

Paused - press any key to continue.

You must now use the following procedure to recover the original operating system
(shadow) drive. These following steps show you the whole process. The process includes
replacing the failed disk-0, re-installing Windows on the new replacement disk, which
creates a new EFI system partition, and then adding new boot entries into NVRAM so
that you can boot back into the original operating system on the shadow disk-1.

1. Remove the failed system drive (disk-0) and replace it with a good disk. See your
hardware manuals for the correct way to replace the failed disk. The replacement
disk does not have to be partitioned or formatted. It can be a brand new disk.

2. Insert the Windows 2003 Server installation CD into the computer's CD-ROM drive,
then power on the system.

3. When the system boot options menu is displayed, select to boot from CD-ROM.
When you are prompted to press any key to boot from the CD, press any key.

This starts Windows 2003 Server setup.

4. On the Welcome to Windows Setup screen, press ENTER to install and allow Setup
to automatically create the new system partition.

You must do this to boot and allow Setup to continue.

5. After the new EFI and MSR partitions are created, select the free space on disk-0
and create a new partition large enough to install Windows and hold a page file.

6. Select the newly created partition to install Windows on, and then select the
format option that you want to format the partition. Setup continues. Answer all
appropriate questions that you are prompted with, and then let Setup finish.

7. After Setup is complete, log on the console as Administrator.

8. At a command prompt, run the bootcfg command to display the current boot
menu items from NVRAM.
 C:\>bootcfg

Boot Options

Timeout: 5 Default: \Device\HarddiskVolume3\WINDOWS

CurrentBootEntryID: 1

Boot Entries

Boot entry ID: 1

OS Friendly Name: Microsoft Windows Server 2003, Enterprise Edition
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath: \Device\HarddiskVolume3\WINDOWS

Boot entry ID: 2

OS Friendly Name: Windows Server 2003, Enterprise Edition
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath: (null)

Boot entry ID: 3

OS Friendly Name: LS120

Boot entry ID: 4

OS Friendly Name: CDROM

Boot entry ID: 5

OS Friendly Name: EFI Shell

Boot entry ID: 6

OS Friendly Name: Boot Mirror C: - secondary plex
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath: (null)

9. Use the bootcfg /list command to display all of the partitions on the shadow
disk (disk-1). Locate the original Windows boot partition. It has the name of LDM
data partition and has a partition length the same size as the original boot
partition.

In this example, the boot partition is entry No: 3 with the GUID of {9aee294a-fa7d-
4d4a-8a47-51a1dd1f9867}
 C:\bootcfg /list 1

Partition table info for Disk: 1

Partition No: 1
Partition Style: GPT
Starting offset: 17,408
Partition length: 1,048,576
Partition GUID: {646091f1-b826-47e8-a72c-f22072e9a769}
GUID type: {5808c8aa-7e8f-42e0-85d2-e1e90434cfb3}
Partition name: LDM metadata partition

Partition No: 2
Partition Style: GPT
Starting offset: 1,065,984
Partition length: 32,505,856
Partition GUID: {afb1e6b9-d8a6-456d-8df1-31327f94f3fe}
GUID type: {e3c9e316-0b5c-4db8-817d-f92df00215ae}
Partition name: Microsoft reserved partition

Partition No: 3
Partition Style: GPT
Starting offset: 33,571,840
Partition length: 3,142,056,960
Partition GUID: {9aee294a-fa7d-4d4a-8a47-51a1dd1f9867}
GUID type: {af9b60a0-1431-4f62-bc68-3311714a69ad}
Partition name: LDM data partition

Partition No: 4
Partition Style: GPT
Starting offset: 3,175,628,800
Partition length: 1,174,758,912
Partition GUID: {ab104fde-0782-4810-842e-0fb291e385ad}
GUID type: {af9b60a0-1431-4f62-bc68-3311714a69ad}
Partition name: LDM data partition

10. Use the bootcfg /mirror command to add a boot entry into NVRAM for the
shadow disks boot partition and give it a meaningful description. Use the Partition
GUID from the boot partition extracted earlier.

C:\>bootcfg /mirror /add {9aee294a-fa7d-4d4a-8a47-51a1dd1f9867} /D

"Original Shadow drive"

 SUCCESS: The mirrored boot entry has been added.

11. Use bootcfg to display the boot menu items again. Notice the new entry was
added to the bottom of the list. You can now use this entry to boot to the original
Windows operating system.

- C:\>bootcfg

Boot Options

Timeout: 5
Default: \Device\HarddiskVolume3\WINDOWS
CurrentBootEntryID: 1

Boot Entries

Boot entry ID: 1

OS Friendly Name: Microsoft Windows Server 2003, Enterprise Edition
OsLoadOptions: N/A
BootFilePath: \Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath: \Device\HarddiskVolume3\WINDOWS

Boot entry ID: 2

OS Friendly Name: Windows Server 2003, Enterprise Edition
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath: (null)

Boot entry ID: 3

OS Friendly Name: LS120

Boot entry ID: 4

OS Friendly Name: CDROM

Boot entry ID: 5

OS Friendly Name: EFI Shell

Boot entry ID: 6

OS Friendly Name: Boot Mirror C: - secondary plex
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath: (null)

Boot entry ID: 7

OS Friendly Name: Original Shadow drive
 OsLoadOptions: N/A
BootFilePath: \Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath: (null)

12. Shut down the computer, and then restart it. Select the boot menu item Original
Shadow Drive to boot into the original operating system. This brings the server
back into production. To fix the mirroring so that you can use the new disk-0 as
your primary operating system drive and again be in a fault tolerant environment,
continue with the following steps.

Re-establish the primary boot drive mirror

While booted into the shadow drive (disk-1), you must "remove" the broken mirror, and
then delete the missing disk. You can do this with either the Disk Management console
or the Diskpart.exe utility.

７ Note

If there were additional volumes on the original failed dynamic disk-0, they must
also be deleted before you are permitted to delete the missing disk.

1. With Diskpart.exe, list the volumes, and then make a note of the volume number
(Volume #) of the failed mirror. Select the mirror volume (volume #), and then view
the details to see what missing disk (m#) you need to break the mirror from. In this
example, you are working with volume 0 on missing disk m0.

DISKPART> list volume

Volume ### Ltr Label Fs Type Size Status Info

Volume 0 C PRIMARY NTFS Mirror 2996 MB Failed Rd Boot

Volume 1 D CD-ROM 0 B Healthy
Volume 2 Partition 2996 MB Healthy
Volume 3 Partition 102 MB Healthy System

DISKPART> select volume 0

Volume 0 is the selected volume.

DISKPART> detail volume

Disk ### Status Size Free Dyn Gpt

 Disk M0 Missing 2996 MB 0 B *
Disk 1 Online 4149 MB 1120 MB **

2. Break the mirror by specifying the missing disk (m0), and then use the no keep
option to remove the plex (partition) from the missing disk. List the volumes to
make sure the mirror is gone and the volume is now listed as a simple volume.

DISKPART> break disk=m0 nokeep

The service did not update the boot file.

Diskpart successfully broke the mirror volume.

DISKPART> list volume

Volume ### Ltr Label Fs Type Size Status Info

Volume 0 C PRIMARY NTFS Simple 2996 MB Healthy Boot

Volume 1 D CD-ROM 0 B Healthy
Volume 2 Partition 2996 MB Healthy
Volume 3 Partition 102 MB Healthy System

3. Select the missing disk (m0), and then delete it.

DISKPART> select disk m0

Disk M0 is now the selected disk.

DISKPART> delete disk

Diskpart successfully deleted the missing disk.

4. Delete the new Windows Server operating system partition on disk-0, because it is
no longer required. This makes room to re-mirror back to disk-0.

７ Note

This step is optional if you have sufficient free space on disk-0 to re-establish
the mirror.

DISKPART> select disk 0

 Disk 0 is now the selected disk.

DISKPART> list partition

Partition ### Type Size Offset

Partition 1 System 102 MB 32 KB

Partition 2 Reserved 31 MB 102 MB
Partition 3 Primary 2996 MB 133 MB

DISKPART> select partition 3

Partition 3 is now the selected partition.

DISKPART> delete partition

Diskpart successfully deleted the selected partition.

5. Convert disk-0 to Dynamic, and then select the operating system volume on disk-1
and re-establish the mirror back to disk-0. This puts the computer back into a fault
tolerant environment, and after the mirror is healthy you can boot back into disk-0
with the new boot option that was automatically added to the NVRAM.

DISKPART> convert dynamic

Diskpart successfully converted the selected disk to dynamic format.

DISKPART> list volume

Volume ### Ltr Label Fs Type Size Status Info

Volume 0 C PRIMARY NTFS Simple 2996 MB Healthy Boot

Volume 1 D CD-ROM 0 B Healthy
Volume 3 Partition 102 MB Healthy System

DISKPART> select volume 0

Volume 0 is the selected volume.

DISKPART> add disk=0

Diskpart succeeded in adding a mirror to the volume.

6. Wait for the mirror status to become healthy. You can use the list volume
command repeatedly until the status changes from Rebuild to Healthy. Quit the
Diskpart utility.

DISKPART> list volume

Volume ### Ltr Label Fs Type Size Status Info

Volume 0 C PRIMARY NTFS Mirror 2996 MB Healthy Boot

DISKPART> exit

Leaving Diskpart...

7. Use the bootcfg command to view the new boot option that was added to the
NVRAM. This new entry is named Boot Mirror C: - secondary plex and is most
likely menu item ID 1. You can now clean up the original boot entries for the
original operating system and the original secondary plex with the bootcfg /delete
/ID # command.

C:\>bootcfg

Boot Options

Timeout: 30
Default: (null)
CurrentBootEntryID: 7

Boot Entries

Boot entry ID: 1

OS Friendly Name: Boot Mirror C: - secondary plex
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath: (null)

Boot entry ID: 2

OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath:
 \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 3

OS Friendly Name: LS120

Boot entry ID: 4

OS Friendly Name: CDROM

Boot entry ID: 5

OS Friendly Name: EFI Shell

Boot entry ID: 6

OS Friendly Name: Boot Mirror C: - Secondary Plex
OsLoadOptions: N/A
BootFilePath: (null)
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

Boot entry ID: 7

OS Friendly Name: original shadow system
OsLoadOptions: N/A
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WIND
OWS

C:\>bootcfg /delete /ID 6

SUCCESS: Specified boot entry has been deleted.

C:\>bootcfg /delete /ID 2

SUCCESS: Specified boot entry has been deleted.

8. This concludes this procedure and the remaining boot entries in the boot menu
are all valid boot entries to boot to both the primary and shadow drives.

GPT mirroring in Windows Server 2008

If you are using Windows Server 2008, visit the following article to set up a GPT mirror:
How to set up dynamic boot partition mirroring on GUID partition table (GPT) disks in
Windows Server 2008

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Extend a data volume in Windows
Article • 12/26/2023

This article describes the following topics:

How to use the Diskpart.exe command prompt utility to extend a data volume into
unallocated space in Windows Server 2003, Windows XP, and Windows 2000.
How to extend the boot partition in Windows Server 2008.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 325590

Use Diskpart.exe to extend a data volume in

Windows Server 2003, in Windows XP, and in
Windows 2000
You can use the Diskpart.exe utility to manage disks, partitions, and volumes from a
command-line interface. You can use Diskpart.exe on both Basic disks and Dynamic
disks. If an NTFS volume resides on a hardware RAID 5 container that can add space to
the container, you can extend the NTFS Volume with Diskpart.exe while the disk remains
a Basic disk.

Use the extend command to incorporate unallocated space into an existing volume
while preserving the data.

The following are the requirements for the extend command:

The volume must be formatted with the NTFS file system.

For Basic volumes, the unallocated space for the extension must be the next
contiguous space on the same disk.

For Dynamic Volumes, the unallocated space can be any empty area on any
Dynamic disk on the system.

Only the extension of data volumes is supported. System or boot volumes may be
blocked from being extended, and you may receive the following error:

Diskpart failed to extend the volume. Please make sure the volume is valid for
extending
 You can't extend the partition if the system page file is located on the partition.
Move the page file to a partition that you don't want to extend.

To extend a partition or volume, first select the volume to give it the focus, and then
specify how large to make the extension. To extend a volume, follow these steps:

1. At a command prompt, type diskpart.exe.

2. Type list volume to display the existing volumes on the computer.

3. Type Select volume <volume number> where <volume number> is number of the
volume that you want to extend.

4. Type extend [size=n] [disk=n] [noerr]. The following section describes the
parameters:

size=n

The space, in megabytes (MB), to add to the current partition. If you don't
specify a size, the disk is extended to use all the next contiguous unallocated
space.

disk=n

The dynamic disk on which to extend the volume. Space equal to size=n is
allocated on the disk. If no disk is specified, the volume is extended on the
current disk.

noerr

For scripting only. When an error is thrown, this parameter specifies that
Diskpart continue to process commands as if the error didn't occur. Without
the noerr parameter, an error causes Diskpart to exit with an error code.

5. Type exit to exit Diskpart.exe.

When the extend command is complete, you should receive a message that states that
Diskpart successfully extended the volume. The new space should be added to the
existing drive while maintaining the data on the volume.

In Windows XP and Windows 2000, you can't use Diskpart.exe to extend a simple
volume on a Dynamic disk that was originally created on a Basic disk. You can extend
only simple volumes that were created after the disk was upgraded to Dynamic disk. If
you try to extend a simple volume on a Dynamic disk that was originally created on a
Basic disk, you receive the following error message. This restriction was removed in
Windows Server 2003.
 Diskpart failed to extend the volume.
Please make sure the volume is valid for extending

７ Note

Windows Server 2003 and Windows XP include Diskpart.exe as part of the

base operating system.
We recommend that you contact your system vendor for updated BIOS,
firmware, drivers, and agents before you convert to Dynamic disks.

Extend the boot partition in Windows Server

2008
To extend the boot partition in Windows Server 2008, follow these steps:

1. Click Start > Server Manager.

2. In the navigation pane, expand Storage, and then click Disk Management.
3. In the details pane, right-click the volume that you want, and then click Extend
Volume.
4. Follow the instructions in the Extend Volume Wizard to extend the boot partition.

７ Note

You can only extend the boot partition in contiguous unallocated disk space.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Frequently asked questions about
the GUID Partitioning Table disk
architecture
FAQ

This article provides a list of frequently asked questions about the GUID Partition Table
disk architecture.

Applies to: Windows Server 2012 R2

Original KB number: 302873

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

What is a GUID Partition Table disk

The GUID Partition Table disk architecture was introduced as part of the Extensible
Firmware Interface initiative. GUID Partition Table is a new disk architecture that expands
on the older Master Boot Record (MBR) partitioning scheme that has been common to
Intel-based computers.

A partition is a contiguous space of storage on a physical or logical disk that functions

as though it were a physically separate disk. Partitions are visible to the system firmware
and the installed operating systems. Access to a partition is controlled by the system
firmware and the operating system that is currently active.

Why do we need GUID Partition Table

GUID Partition Table disks can grow to a large size. As of July 2001, the Microsoft
implementation supports a hard disk of up to 18 EB (512 KB LBAs).
The number of partitions on a GUID Partition Table disk is not constrained by temporary
schemes such as container partitions as defined by the MBR Extended Boot Record. The
Microsoft implementation of GUID Partition Table is limited to 128 partitions. However,
it is important to note that one partition is used for the EFI System Partition, one for the
Microsoft Reserved and two more are used if you use dynamic disks. This leaves 124
partitions for data use.

The GUID Partition Table disk partition format is well defined and fully self-identifying.
Data that is critical to the operating system is located in partitions and not in
unpartitioned or hidden sectors. GUID Partition Table does not allow for hidden sectors
or partitions. GUID Partition Table disks use primary and backup partition tables for
redundancy and CRC32 fields for improved partition data structure integrity. The GUID
Partition Table partition format uses version number and size fields for future expansion.

Each GUID Partition Table partition has a unique identification GUID and a partition
content type, so no coordination is necessary to prevent partition identifier collision.
Each GUID Partition Table partition has a 36-character Unicode name, which means that
any software can present an easily readable name for the partition without any
additional understanding of the partition.

What is wrong with MBR partitioning

MBR disks support only four primary partitions table entries or multiple logical partitions
in the extended partition. If more partitions are wanted, a secondary structure, an
extended partition, is necessary. Extended partitions are then subdivided into one or
more logical disks.

Only one extended partition can be present on any given drive, and the maximum
number of logical drives is MAXULONG/4. All MBR disk partitions and logical drives
must be cylinder-aligned, even on hardware RAID sets that are built from multiple
different drives with no clear underlying physical geometry.

MBR partitioning rules are complex and poorly specified. For example, does cylinder
alignment mean that each partition must be at least one cylinder in length? An MBR
partition is identified by a two-byte field, and coordination is necessary to avoid
collision. IBM originally provided that coordination, but as of July 2001, there is no
single authoritative list of partition identifiers.

Another common practice is to use partitioned or "hidden" sectors to hold specific

information. That practice is undocumented and results in severe system problems that
are difficult to debug. Over the years, broken implementations and tools have been
released to the public, making support difficult.
Where can I find the specification for
GUID Partition Table disk partitioning
Chapter 16 of the Extensible Firmware Interface specification defines the GUID Partition
Table format. This document is available at the following Intel Web site:

The Unified EFI Specification Defines an Interface Between an Operating System and
Platform Firmware

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Is Extensible Firmware Interface

required for a GUID Partition Table disk
No. GUID Partition Table disks are self-identifying. All the information that is needed to
interpret the partitioning scheme of a GUID Partition Table disk is completely contained
in structures in specified locations on the physical media.

How big can a GUID Partition Table disk

be
In theory, a GUID Partition Table disk can be up to 264 sectors in a single logical block in
length. Logical blocks are commonly 512 bytes or one sector in size.

In practice, Windows XP supports GUID Partition Table disks of up to approximately 18

exabytes in size.

How many partitions can a GUID

Partition Table disk have
In theory, an unlimited number. As the July 2001, the Microsoft implementation is 128
partitions. The number of partitions is limited by the amount of space that is reserved
for making partition entries.
Can a disk be both a GUID Partition
Table disk and an MBR disk
No. However, all GUID Partition Table disks contain a protective MBR that is used for
legacy programs that do not understand the GUID Partition Table disk structure.

What is a Protective MBR

The Protective MBR, beginning in sector 0, precedes the GUID Partition Table partition
table on the disk. The MBR contains one type 0xEE partition that spans the entire length
of the disk. This is the same regardless of the number of partitions that are defined in
the GUID Partition Table disk entry array.

Why does the GUID Partition Table have

a Protective MBR
The Protective MBR protects GUID Partition Table disks from previously-released MBR
disk tools such as Microsoft MS-DOS FDISK or Microsoft Windows NT Disk
Administrator. These tools are not aware of GUID Partition Table and do not know how
to properly access a GUID Partition Table disk. Legacy software that does not know
about GUID Partition Table interprets only the Protected MBR when it accesses a GUID
Partition Table disk. These tools will view a GUID Partition Table disk as having a single
encompassing (possibly unrecognized) partition by interpreting the Protected MBR,
rather than mistaking the disk for one that is unpartitioned.

Why would a GUID Partition Table-

partitioned disk appear to have an MBR
on it
If this occurred, you must have used an MBR-only-aware disk tool to access the GUID
Partition Table disk.

If the disk is larger than the maximum

size an MBR can report, will the entire
disk contents be protected
The EE partition in the Protective MBR is specified to be the maximum size that is
allowable in an MBR.

Can Windows read, write, and boot

from GUID Partition Table disks
Can the 64-bit version of Windows XP read, write, and boot from GUID Partition
Table disks?

The 64-bit version of Windows XP can read and write GUID Partition Table disks,
but cannot boot from GUID Partition Table disks.

Can the 64-bit version of Windows XP read, write, and boot from MBR disks?

Yes.

Can the 32-bit version of Windows XP read, write, and boot from GUID Partition
Table disks?

No. The 32-bit version will see only the Protective MBR. The EE partition will not be
mounted or otherwise exposed to program software.

Can the 32-bit version of Windows XP read, write, and boot from MBR disks?

Yes.

Can Microsoft Windows 2000, Microsoft Windows NT 4.0, or Microsoft Windows

98/95 read, write, and boot from GUID Partition Table?

No. Legacy software will see only the Protective MBR.

What about mixing and matching GUID

Partition Table and MBR disks on the
same computer
GUID Partition Table and MBR disks can be mixed only on 64-bit systems, and the
following restrictions apply:
 The Windows XP loader and the boot partition must reside on a GUID Partition
Table disk. Other hard disks can be either MBR or GUID Partition Table.

Both MBR and GUID Partition Table disks can be present in a single dynamic disk
group. Volume sets can span both MBR and GUID Partition Table disks, however,
the MBR cylinder alignment restriction might cause some difficulties with mirroring
or striping MBR and GUID Partition Table disks.

What about removable media

Removable media must be MBR or superfloppy.

What is a superfloppy
Removable media without either GUID Partition Table or MBR formatting is considered a
superfloppy. The entire media is treated as a single partition.

The media manufacturer performs any MBR partitioning of removable media; Windows
never partitions removable media. If the media does have an MBR, only one partition is
supported. There is little user-discernible difference between MBR-partitioned media
and superfloppies.

Examples of removable media include floppy disk drives, JAZZ disk cartridges, magneto-
optical media, DVD-ROM, and CD-ROM. Hard disk drives on external buses such as SCSI
or IEEE 1394 are not considered removable.

What is the default behavior of

Windows when partitioning media
What is the default behavior of the 64-bit version of Windows XP when
partitioning media?

Fixed disks are partitioned by using GUID Partition Table partitioning. GUID
Partition Table disks can be converted to MBR disks only if all existing partitioning
is first deleted, with associated loss of data.

What is the default behavior of the 32-bit version of Windows XP when

partitioning media?

Only MBR disks can be used. MBR disks cannot be converted to GUID Partition
Table disks.
Extensible Firmware Interface Firmware
How can a drive letter in the operating system be mapped to a partition in
Extensible Firmware Interface Firmware?

There is no inherent mapping between drive letter and partition that can be used
to determine one from the other. A basic data partition must be identified by its
partition GUID.

How can an Extensible Firmware Interface System Partition be created?

Extensible Firmware Interface System Partitions can be created by using the

Extensible Firmware Interface firmware utility Diskpart.efi or the Windows XP
command-line utility Diskpart.exe, or they can be created programmatically by
using IOCTL_SET_DRIVE_LAYOUT .

What can be changed on a partition

You should not change any partition header entry directly. Do not use disk tools or
utilities to make alterations or changes.

What partitioning does Windows XP

support on detachable disks
Detachable disks are commonly expected to migrate between computers or simply to
be unavailable to the operating system at times. Examples of detachable disks are IEEE
1394 disks, which can be easily disconnected by the end user, or Microsoft Cluster
Services (MSCS) shared disks, which move between nodes in a cluster. Windows XP
supports only MBR partitioning on detachable disks.

Extensible Firmware Interface System

Partition
What is the Extensible Firmware Interface System Partition?

The Extensible Firmware Interface System Partition contains the NTLDR, Boot.ini,
and other files that are necessary to boot the computer, such as drivers. The
Partition GUID defines the Extensible Firmware Interface System Partition:
DEFINE_GUID (PARTITION_SYSTEM_GUID, 0xC12A7328L, 0xF81F, 0x11D2, 0xBA,
0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B)

Do only GUID Partition Table disks have Extensible Firmware Interface System
Partitions?

No, MBR disks can also have Extensible Firmware Interface System Partitions.
Extensible Firmware Interface specifies booting from either GUID Partition Table or
MBR. The Extensible Firmware Interface System Partitions on an MBR disk is
identified by partition type 0xEF. However, Windows XP does not support booting
Extensible Firmware Interface from MBR disks or 0xEF partitions.

How big is the Extensible Firmware Interface System Partition?

The Extensible Firmware Interface System Partition is determined by using the

following algorithm:

Max (100MB, min (1 percent of physical disk, 1GB))

In other words, the size of the Extensible Firmware Interface System Partition must
be the larger of these two numbers, 100 MB or 1 percent of the physical disk size
(up to 1 GB). The physical disk size is measured at the time of disk partitioning.

The value 1 percent of the physical disk is calculated at the time that the Extensible
Firmware Interface System Partition is created and does not change if the disk is
extended later (for example, by using RAID).

Can there be two Extensible Firmware Interface System Partitions on a single disk?

Such a configuration should not be created and will not be supported.

What about two Extensible Firmware Interface System Partitions on two different
disks?

Extensible Firmware Interface System Partitions can be replicated for high-

availability configurations. Replication must be done manually and the contents
must be synchronized manually. Extensible Firmware Interface System Partitions
cannot be mirrored.

What does Microsoft place in the Extensible Firmware Interface System Partition?

Microsoft places the loader, and other files that are necessary to boot the
operating system in the Extensible Firmware Interface System Partition.

Where should the Extensible Firmware Interface System Partition be placed on the
disk?
 The Extensible Firmware Interface System Partition must be first on the disk. While
there is no architectural requirement, there are numerous reasons why it is
beneficial to place the Extensible Firmware Interface System Partition first. The
primary reason for this is that it is impossible to span volumes when the Extensible
Firmware Interface System Partition is logically between the two data partitions you
are attempting to span.

What should a computer or device manufacturer place in the Extensible Firmware

Interface System Partition?

The Extensible Firmware Interface System Partition should only include files that
are required for booting an operating system, platform tools that run before
operating system boot, or files that must be accessed before operating system
boot, for example in performing pre-boot system maintenance. Other value-added
files or diagnostics that are used while the operating system is running should not
be placed in the Extensible Firmware Interface System Partition. It is important to
note that the space in the Extensible Firmware Interface System Partition is a
limited system resource; its primary purpose is to provide storage for the files that
are necessary to boot the operating system.

Where should a computer manufacturer

place files such as Platform Diagnostics
or other value-added files
The preferred option is for computer manufacturers to place value-added contents in an
OEM-specific partition. Just like MBR OEM partitions, the contents of GUID Partition
Table OEM (or other unrecognized) partitions are not exposed (given drive letters or
returned in volume lists). Users are warned that deleting the partition can cause the
computer to fail to operate. An OEM-specific partition should be placed before the
Microsoft Reserved Partition and after any Extensible Firmware Interface System Partition
on the disk. Although not architectural, this placement has the same benefits as placing
the Extensible Firmware Interface System Partition first. For example, it is also impossible
to span volumes when an OEM-specific partition is logically between the two data
partitions you are attempting to span.

Placement in the Extensible Firmware Interface System Partition is an option for

programs or files that run in the pre-operating system boot environment. However, the
Extensible Firmware Interface System Partition is architecturally-shared space and
represents a limited resource. Consuming space in the Extensible Firmware Interface
System Partition should be considered carefully. Files that are not relevant to the pre-
operating system boot environment should not be placed in the Extensible Firmware
Interface System Partition.

Microsoft Reserved Partition

What is a Microsoft Reserved Partition?

The Microsoft Reserved Partition reserves space on each disk drive for subsequent
use by operating system software. GUID Partition Table disks do not allow hidden
sectors. Software components that formerly used hidden sectors now allocate
portions of the Microsoft Reserved Partition for component-specific partitions. For
example, converting a basic disk to a dynamic disk causes the Microsoft Reserved
Partition on that disk to be reduced in size and a newly created partition holds the
dynamic disk database. The Microsoft Reserved Partition has the following Partition
GUID:

DEFINE_GUID (PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8,

0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE

What disks require a Microsoft Reserved Partition?

Every GUID Partition Table disk must contain a Microsoft Reserved Partition. The
Microsoft Reserved Partition must be the first partition after the Extensible
Firmware Interface System Partition (if any) on the disk. It is particularly important
that the Microsoft Reserved Partition be created before other primary data
partitions.

Who creates the Microsoft Reserved Partition?

The Microsoft Reserved Partition must be created when disk-partitioning

information is first written to the drive. If the manufacturer partitions the disk, the
manufacturer must create the Microsoft Reserved Partition at the same time. If
Windows partitions the disk during Setup, it creates the Microsoft Reserved
Partition.

Why must the Microsoft Reserved Partition be created when the disk is first
partitioned?

After the disk is partitioned, there will be no free space left to create a Microsoft
Reserved Partition.

How big is the Microsoft Reserved Partition?

 When initially created, the size of the Microsoft Reserved Partition depends on the
size of the disk drive:
On drives that are less than 16 GB, the Microsoft Reserved Partition is 32 MB.
On drives that are greater than or equal to 16 GB, the Microsoft Reserved
Partition is 128 MB. As the Microsoft Reserved Partition is divided into other
partitions, it becomes smaller.

What partitions are required by

Windows XP
Each bootable drive must contain an Extensible Firmware Interface System Partition, a
Microsoft Reserved Partition, and at least one basic data partition that contains the
operating system. Each data drive must contain at least a Microsoft Reserved Partition
and one basic data partition.

All basic data partitions on the drive should be contiguous. As previously noted, placing
an OEM-specific or other unrecognized partition between data partitions imposes
limitations on later volume spanning

What is a basic data partition

Basic data partitions correspond to primary MBR partitions 0x6 (FAT), 0x7 (NTFS), or 0xB
(FAT32). There is a direct one-to-one correlation between a basic data partition and a
drive letter or mount point, other volume device object, or both. Each basic data
partition is represented in Windows as a volume device object, and optionally as a
mount point or a drive letter.

How is a basic data partition identified

It has the following partition type GUID:

DEFINE_GUID (PARTITION_BASIC_DATA_GUID, 0xEBD0A0A2L, 0xB9E5, 0x4433, 0x87,

0xC0, 0x68, 0xB6, 0xB7, 0x26, 0x99, 0xC7)

Will end users see the Extensible

Firmware Interface System Partition,
Microsoft Reserved Partition, and OEM-
specific partitions
The user won't see these partitions exposed in Windows Explorer, nor is any recognized
file system exposed to legacy programs such as Context Indexing. The Extensible
Firmware Interface System Partition, OEM-specific, and other unrecognized partitions
will be visible only in the Disk Management MMC snap-in.

What partitions are mounted by default

by Windows
Windows XP exposes only basic data partitions. Other partitions with FAT file systems
may be mounted, but not exposed (only programmatically). Only basic data partitions
are assigned drive letters or mount points.

The Extensible Firmware Interface System Partition FAT file system is mounted, but not
exposed. This allows programs running under Windows to update the contents of the
Extensible Firmware Interface System Partition. The following registry key locates the
Extensible Firmware Interface System Partition:

HKEY_LOCAL_MACHINE/System/Setup/SystemPartition

The Microsoft Reserved Partition (and any partitions that are created from the Microsoft
Reserved Partition) could have recognizable file systems; none are exposed.

Any OEM-specific partitions or partitions that are associated with other operating
systems are not recognized by Windows. Unrecognized partitions with recognizable file
systems are treated like the Extensible Firmware Interface System Partition. They will be
mounted, but not exposed. Unlike MBR disks, there is no practical difference between
OEM-specific partitions and other operating system partitions; all are unrecognized.

How can the user see the Extensible

Firmware Interface System Partition,
OEM, and other unrecognized partitions
The user can use disk management tools such as the Disk Management MMC snap-in or
Diskpart.exe. The Microsoft Reserved Partition and any partitions that are created from
the Microsoft Reserved Partition are only visible from a command prompt.
What about dynamic disks
Dynamic disks use two different GUID Partition Table partitions:

A data container partition corresponding to the MBR partition 0x42, with the
following GUID:DEFINE_GUID (PARTITION_LDM_DATA_GUID, 0xAF9B60A0L, 0x1431,
0x4F62, 0xBC, 0x68, 0x33, 0x11, 0x71, 0x4A, 0x69, 0xAD)

A partition to contain the dynamic configuration database, with the following

GUID:DEFINE_GUID(PARTITION_LDM_METADATA_GUID, 0x5808C8AAL, 0x7E8F,
0x42E0, 0x85, 0xD2, 0xE1, 0xE9, 0x04, 0x34, 0xCF, 0xB3) Volumes are created in the
data container and are mounted by default. This is the same as the contents of
0x42 MBR partitions.

What happens when a basic disk is

converted to dynamic
For a drive to be eligible for conversion to dynamic, all basic data partitions on the drive
must be contiguous. If other unrecognized partitions separate basic data partitions, the
disk cannot be converted. This is one of the reasons that the Microsoft Reserved
Partition must be created before any basic data partitions.

The first step in conversion is to separate a portion of the Microsoft Reserved Partition
to create the configuration database partition. All non-bootable basic partitions are then
combined into a single data container partition. Boot partitions are retained as separate
data container partitions. This is analogous to conversion of primary partitions.

Windows XP differs from Windows 2000 in that basic and extended partitions are
preferentially converted to a single 0x42 partition, rather than being retained as multiple
distinct 0x42 partitions as on Windows 2000.

How can a specific partition be

mounted
You can access the GUID Partition Table disk partitions of different types by using the
following tools.

Diskpart.efi:
Firmware: Extensible Firmware Interface System Partition
Microsoft Reserved Partition
Diskpart.exe:
Windows XP: Extensible Firmware Interface System Partition
Microsoft Reserved Partition

Diskgmt.msc:
Windows XP: Extensible Firmware Interface System Partition
DATA

Explorer.exe:
Windows XP: DATA

You can also develop your own tools (by using the Microsoft Win32 or Microsoft Win64
APIs) to access the GUID Partition Table disk partitions at their primitive levels.

How are GUID Partition Table disks

managed in Windows XP
GUID Partition Table and MBR disks are managed the same way. Disks can be formatted
as GUID Partition Table or MBR by using the Diskpart.exe command-line utility or by
using the Disk Management snap-in. Volumes can be created on both GUID Partition
Table and MBR disks, and both kinds of disks can be mixed in the same dynamic disk
group.

What about FTdisk sets

There is no FTdisk set support on Windows XP for MBR or GUID Partition Table disks.
The only support for logical volumes is through dynamic disks.

Can a disk be converted from GUID

Partition Table to MBR or MBR to GUID
Partition Table
Yes, but only if the disk contains no partitions or volumes. Any data on the disk will be
destroyed. GUID Partition Table disks are only supported on the 64-bit version of
Windows XP.
What file systems are supported on
GUID Partition Table disks
NTFS is recommended on all basic data partitions and all dynamic volumes. Windows
Setup and the Disk Management snap-in offer only NTFS. However, you can still use
FAT16 and FAT32 on these partitions as well. To circumvent this, the partition or volume
must be formatted explicitly by using the Format tool.

Is it possible to make a sector-by-sector

copy of a GUID Partition Table disk
No. The Disk and Partition GUIDs will no longer be unique. This must never happen. You
can make a sector-by-sector copy of the contents of Extensible Firmware Interface
System Partition or basic data partitions.

Is there anyway to copy a whole GUID

Partition Table disk by using the OPK
imaging tools
Yes; however, there are some key caveats. The OEM Preinstallation Kit (OPK) initializes
the Disk and Partition GUIDs to zero. On first boot of Windows XP, the operating system
generates unique GUIDs. The OPK only supports generation of Extensible Firmware
Interface System Partition, Microsoft Reserved Partition, and basic data partitions.

If a program has recorded any Disk or Partition GUIDs, the program may not work. Any
programs, drivers, utilities, or firmware implementations that are supplied by computer
manufacturers or program vendors that rely on GUIDs should be capable of handling
GUIDs that change from the OPK initialization values to those that are generated by the
operating system.

What is the Diskpart.efi MAKE

command
It is a way for OEMs to simplify operating system pre-installation and system recovery.
This command can easily be extended to create a default disk configuration for the
platform. For example, the computer manufacturer could extend the MAKE command to
automatically partition the boot drive with an Extensible Firmware Interface System
Partition, Microsoft Reserved Partition, an OEM-specific partition, and one basic data
partition. For example, consider a possible disk configuration called BOOT_DISK. In the
event of disaster recovery, MAKE BOOT_DISK would allow the customer to completely
repartition a boot disk to the original factory defaults.

What happens if a duplicate disk or

partition GUID is detected
Windows XP will generate new GUIDs for any duplicate Disk GUID, Microsoft Reserved
Partition GUID, or Microsoft Reserved Partition basic data GUID upon detection. This is
similar to the duplicate MBR signature handling in Windows 2000. Duplicate GUIDs on a
dynamic container or database partition cause unpredictable results.

What is the maximum NTFS volume size

supported on a GPT disk
This depends on the cluster size that is selected at the time of formatting. NTFS is
currently limited to 2^32-1 allocation units. This yields a 256TB volume, using 64k
clusters. However, this has only been tested to 16TB, or 17,592,186,040,320 bytes, using
4K cluster size. The following chart shows the NTFS limits based on cluster size:

ﾉ Expand table

Cluster size Maximum NTFS Volume Size (bytes RAW)

512 2,199,023,255,040 (2TB)

1,024 4,398,046,510,080 (4TB)

2,048 8,796,093,020,160 (8TB)

4,096 17,592,186,040,320 (16TB)

8,192 35,184,372,080,640 (32TB)

16,384 70,368,744,161,280 (64TB)

 Cluster size Maximum NTFS Volume Size (bytes RAW)

32,768 140,737,488,322,560 (128TB)

65,536 281,474,976,645,120 (256TB)

For example, to format a volume that has a cluster size of 8 KB, you would use a
command such as the following from a command prompt, where /a: #### specifies the
number of bytes per cluster:

Console

format d: /fs:ntfs /a:8192

If you choose a cluster size that is too small for the size of the partition, you receive the
following error message when you try to format the partition:

The format operation did not complete because the cluster count is higher than
expected

To determine the cluster size of a volume, run the following command at a command
prompt, and then note the Bytes Per Cluster value:

Console

fsutil fsinfo ntfsinfo <volume>

７ Note

The <volume> placeholder represents the volume letter.

For example, when you run the fsutil fsinfo ntfsinfo c: command, you may receive
results that resemble the following output:

NTFS Volume Serial Number : 0xf4300f6c300f3560

Version : 3.1
Number Sectors : 0x000000001d17dbee
Total Clusters : 0x0000000003a2fb7d
Free Clusters : 0x000000000102bfa0
Total Reserved : 0x0000000000000800
 Bytes Per Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x000000000e630000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000001d17dbe
Mft Zone Start : 0x00000000002185a0
Mft Zone End : 0x0000000000218740
RM Identifier : 1587CC47-A713-11DB-9287-806E6F6E6963

７ Note

In this example, the Bytes Per Cluster value is 4096. This value represents a 4-
kilobyte (KB) cluster size.

Feedback
Was this page helpful?  Yes  No
FIX: Heavy memory usage in ReFS on
Windows
Article • 12/26/2023

This article provides a solution to memory pressure and performance issues that occur
in the Resilient File System (ReFS) in Windows.

Applies to: Windows 10 - all editions, Windows Server 2016, Windows Server 2019
Original KB number: 4016173

Symptoms
You notice heavy memory usage on a computer that's running Windows 10, Windows
Server 2016, Windows Server 2019, Windows Server, 1903 or Windows Server, version
1909.

Cause
To provide greater resiliency for its metadata, the Resilient File System (ReFS) in
Windows Server 2016 uses allocate-on-write semantics for all metadata updates. Which
means that ReFS never makes in-place updates to metadata. Instead, it makes all writes
to newly allocated regions.

However, allocating-on-write causes ReFS to issue more metadata I/O to new regions of
the volume than write-in-place file systems do. Additionally, ReFS uses block caching
logic to cache its metadata in RAM. It isn't as resource-efficient as file caching logic.

Together, the ReFS block caching logic and allocate-on-write semantics cause ReFS
metadata streams to be large. ReFS uses the cache manager to create the metadata
streams, and the cache manager lazily unmaps inactive views. In some situations, this
lazy unmapping causes the active working set on the server to grow. This creates
memory pressure that can cause poor performance.

Resolution
This issue is addressed in cumulative update 4013429 that was released on March 14,
2017. The update introduces three tunable registry parameters.
Cumulative update 4013429 is available through Windows Update. You can also
download it directly through the Microsoft Update Catalog .

For more information, see March 14, 2017—KB4013429 (OS Build 14393.953)

How to set the tunable parameters

This update provides three tunable registry parameters to address large ReFS metadata
streams. You can use the following optional methods to set the parameters. These
parameters can be used in any combination because they don't overlap functionally.

） Important

A restart is required for these parameter changes to take effect.

These parameters must be set consistently on every node of a failover cluster.

Option 1
This option causes ReFS to try a complete an MM unmap of all metadata streams at
every checkpoint. This option will produce the expected result only if the volume is idle
and doesn't have any mapped pages.

Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Value Name: RefsEnableLargeWorkingSetTrim

Set RefsEnableLargeWorkingSetTrim = 1
Value Type: REG_DWORD

Option 2
ReFS has a lazy MM unmap logic. So when ReFS cycles the entire namespace to
complete an MM unmap, it unmaps at a certain granularity. The amount of virtual
address space that is unmapped is determined by the following formula:

RefsNumberOfChunksToTrim 128 MB (for volume of size > 10 TB)

RefsNumberOfChunksToTrim 64 MB (for volume of size < 10 TB)

This option works if the VA range that's being unmapped doesn't have any active
references (that is, mapped metadata pages).
Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Value Name: RefsNumberOfChunksToTrim

Value Type: REG_DWORD
DEFAULT (if not set or 0): 4

７ Note

Setting RefsNumberOfChunksToTrim to higher values causes ReFS to trim more

aggressively. It reduces the amount of memory that's being used. Set the trim value
to an appropriate number: 8, 16, 32, and so on.

Option 3
In this option, ReFS sends down an MM trim inline while it unmaps its metadata page.
This is the most aggressive option because it can cause performance regression if ReFS
is used on high-performance media, such as an SSD or NVMe.

Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Value Name: RefsEnableInlineTrim

Value Type: REG_DWORD
Set RefsEnableInlineTrim = 1

Recommendation:

If a large active working set causes poor performance, first try to set
RefsEnableLargeWorkingSetTrim = 1.

If this setting doesn't produce a satisfactory result, try different values for
RefsNumberOfChunksToTrim, such as 8, 16, 32, and so on.

If this still doesn't provide the wanted effect, set RefsEnableInlineTrim = 1.

More information
To update its metadata, ReFS uses allocate-on-write instead of writing-in-place to
improve its resiliency to corruption.
Writing-in-place is susceptible to torn writes. It occurs if a power failure or an
unexpected dismount causes a write to be only partially completed.

Allocating-on-write enables ReFS to reliably maintain metadata consistency after a

power failure or an unexpected dismount. It's because ReFS can still reference the
previous, consistent metadata copy.

References
Resilient File System (ReFS) overview

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Hot-swap disks are not recognized
Article • 12/26/2023

This article provides some workarounds for the issue where Hot-swap disks are not
recognized.

Applies to: Windows Server 2012 R2

Original KB number: 2992869

Symptoms
Assume that you have a computer that supports hot-swap SATA disks and is running
Windows Server 2012 R2. For some system configurations, when you insert one or more
drives into the computer, Windows cannot detect all the inserted drives. Therefore, you
cannot see the drives in This PC or the Windows Disk Management snap-in.

Cause
This issue occurs because of a communication error that occurs between the affected
drives and Windows.

Workaround
To work around this issue, you can use one of the following methods.

Method 1

Remove and reinsert the affected drives.

Method 2

Use the Windows Disk Management snap-in tool, and then rescan for disks.

Status
Microsoft has confirmed that this is a problem in the Microsoft products at the
beginning of this article.

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How NTFS reserves space for its Master
File Table (MFT)
Article • 12/26/2023

This article describes how NTFS reserves space for its Master File Table (MFT).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 174619

Summary
The NTFS file system contains at its core, a file called the master file table (MFT). There is
at least one entry in the MFT for every file on an NTFS volume, including the MFT itself.

Because utilities that defragment NTFS volumes cannot move MFT entries, and because
excessive fragmentation of the MFT can impact performance, NTFS reserves space for
the MFT in an effort to keep the MFT as contiguous as possible as it grows.

In Windows, the defrag utility defrags the MFT.

The defrag utility

A defrag operation on the MFT combines an MFT file into 1 and prevents it from being
stored in multiple places that are not sequential on disk. In this class of operation, the
MFT file is more sequential. However, it is exactly the size that the MFT file was before
the defrag operation.

An MFT can be too large if a volume used to have lots of files that were deleted. The
files that were deleted cause internal holes in the MFT. These holes are significant
regions that are unused by files. It is impossible to reclaim this space. This is at least true
on a live NTFS volume.

More information
NTFS uses MFT entries to define the files to which they correspond. All information
about a file, including its size, time and date stamps, permissions, and data content is
either stored in MFT entries or in space external to the MFT but described by the MFT
entries.
(Directory entries, external to the MFT, also contain some redundant information
regarding files. But a full discussion of all the structures on NTFS is beyond the scope of
this article.)

As files are added to an NTFS volume, more entries are added to the MFT and so the
MFT increases in size. When files are deleted from an NTFS volume, their MFT entries are
marked as free and may be reused, but the MFT does not shrink. Thus, space used by
these entries is not reclaimed from the disk.

Because of the importance of the MFT to NTFS and the possible impact on performance
if this file becomes highly fragmented, NTFS makes a special effort to keep this file
contiguous. NTFS reserves 12.5 percent of the volume for exclusive use of the MFT until
and unless the remainder of the volume is used up. Thus, space for files and directories
is not allocated from this MFT zone until all other space is allocated first.

７ Note

You can change the NtfsMFTZoneReservation registry key to increase the volume
in Windows. For more information about the MFT, please see the Key elements in
the disk defragmentation process section of Maintaining Windows 2000 Peak
Performance Through Defragmentation.

Depending on the average file size and other variables, either the reserved MFT zone or
the unreserved space on the disk may be used up before the other as the disk fills to
capacity.

Volumes with a small number of relatively large files exhaust the unreserved space first,
while volumes with a large number of relatively small files exhaust the MFT zone space
first. In either case, fragmentation of the MFT starts to take place when one region or
the other becomes full. If the unreserved space becomes full, space for user files and
directories starts to be allocated from the MFT zone competing with the MFT for
allocation. If the MFT zone becomes full, space for new MFT entries is allocated from the
remainder of the disk, again competing with other files.

A new registry parameter can increase the percentage of a volume that NTFS reserves
for its master file table. NtfsMftZoneReservation is a REG_DWORD value that can take
on a value between 1 and 4, where 1 corresponds to the minimum MFT zone size and 4
corresponds to the maximum. If the parameter is not specified or an invalid value is
supplied, NTFS uses a default value of 1 for this parameter. The exact ratios that
correspond to each setting are undocumented because they are not standardized and
may change in future releases. In order to know what setting is best for your
environment, it may be necessary to experiment with different values.
To determine the current size of the MFT on a Windows computer, type the dir /a $mft
command on an NTFS volume.

To determine the current size of the MFT on a Windows computer, use Disk
Defragmenter to analyze the NTFS drive, and then click View Report. This displays the
drive statistics, including the current MFT size and number of fragments.

The Disk Defragmenter displays green for what is called system files and on an NTFS
formatted volume this is simply the combination of the MFT, pagefile.sys (if one exists
on this volume) and what is called the "MFT Zone" or reserved space for MFT Expansion.
The defragmentation report only displays information about the pagefile and MFT; it
does not mention the MFT Zone because it does not affect in any way disk utilization or
capacity.

The MFT Zone is not subtracted from available (free) drive space used for user data files,
it is only space that is used last. When the MFT needs to increase in size, for example,
you created new files and directories, it is taken from the MFT Zone first, thus
decreasing MFT fragmentation and optimizing MFT performance.

The default MFT Zone is calculated and reserved by Ntfs.sys when it mounts the volume,
and is based on volume size. You can increase the MFT Zone by means of the registry
entry documented below, but you cannot make the default MFT Zone smaller than what
is calculated by Ntfs.sys. Increasing the MFT Zone does not decrease in any way disk
space that can be used by users for data files.

７ Note

The results returned by the dir command may not be current. The size reported by
the dir command may reflect cached data that reflects the size of the MFT at the
time the system was started following an orderly shutdown.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To add this value, perform the following steps:

 1. Run Registry Editor (Regedt32.exe), and go to the following subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem

2. From the Edit menu, click Add Value.

3. Type the following information in the dialog box:

Value Name: NtfsMftZoneReservation

Data Type: REG_DWORD
Data: (valid range is 1-4)

4. Quit Registry Editor and restart your computer.

７ Note

This is a run-time parameter and does not affect the actual format of a volume.
Rather, it affects the way NTFS allocates space on all volumes on a given system.
Therefore, to be completely effective, the parameter must be in effect from the
time that a volume is formatted and throughout the life of the volume. If the
registry parameter is adjusted downward or removed, the MFT zone will be
reduced accordingly, but this will not have any affect on MFT space already
allocated and used.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to establish a striped volume (RAID
0) in Windows Server 2003
Article • 12/26/2023

This article describes the steps to establish a striped volume (RAID 0) in Windows Server
2003.

Applies to: Windows Server 2003

Original KB number: 323433

Summary
A striped volume (RAID 0) combines areas of free space from multiple hard disks
(anywhere from 2 to 32) into one logical volume. Data that is written to a striped volume
is interleaved to all disks at the same time instead of sequentially. Therefore, disk
performance is the fastest on a RAID 0 volume as compared to any other type of disk
configuration. Administrators prefer to use striped volumes when input/output (I/O)
speed is important. Any file system, including FAT, FAT32, or NTFS, can be used on a
striped volume.

Requirements
There must be at least two hard disk drives. IDE, small computer system interface
(SCSI), or mixed architecture is permissible.
All disks involved in the striped volume must be dynamic disks.
Each portion of the free space must be exactly the same (for example, the size and
file system type).

How to set up the Disk Management system

1. Click Start, point to Administrative Tools, and then click Computer Management.

2. Expand the Storage node.

3. Click Disk Management.

4. On the View menu, point to Top, and then click Disk List.

In the right pane, a column appears that lists the attributes of each disk in the
system.
 5. On the View menu, point to Bottom, and then click Graphical View.

A color-coded graphical view of the disks on the system is displayed.

The Disk Description pane (which is displayed in gray) is positioned on the left side of
the volume description, which is displayed in color. The disk description contains
information about each disk's disk number, whether it's a basic or dynamic
configuration, its size, and its status (online or offline).

The volume descriptions are color-coded. They hold information about each volume,
such as the drive letter (if assigned), whether the volume is allocated or unallocated, the
partition or volume size, and the health status of the volume.

Requirements to make sure that disks are set

up to support a striped volume
Disks: A minimum of two disks are needed to support striping.
Type: Any disks involved in striping must be dynamic. Conversion from basic to
dynamic goes very quickly without data loss. After you complete the conversion
procedure, you must restart the computer.
Capacity: The striped volume can take the whole disk or as little as 50 megabytes
(MB) for each disk.
Unallocated space: Any disks that you want to upgrade to a dynamic disk must
contain at least 1 MB of free space at the end of the disk for the upgrade to
succeed. Disk Management automatically reserves this free space when it creates
partitions or volumes on a disk, but disks with partitions or volumes that are
created by other operating systems may not have this free space available.
Status: The status of all disks involved in a striped volume must be online when
you create the striped volume.
Device Type: You can install striping on any dynamic disk even if there are mixed
drive architectures on the system. For example, IDE, Enhanced IDE (EIDE), and SCSI
drives can all be used in one striped volume.

How to upgrade to dynamic disks

If the disks that are going to be involved in the striped volume are already dynamic
disks, proceed to the "How to Convert to Striped Volume" section of this article.

７ Note
 You must be logged on as an administrator or a member of the Administrators
group to complete this procedure. If your computer is connected to a network,
network policy settings may also prevent you from completing this procedure.

To upgrade a basic disk to a dynamic disk:

1. Before you upgrade disks, quit any programs that are running on those disks.
2. Right-click the gray Disk Description pane that is located to the left of the color-
coded volume panes, and then click Upgrade to Dynamic Disk.
3. If the second disk isn't a dynamic disk, follow steps 1 and 2 to upgrade it to a
dynamic disk.

How to convert to striped volume

In this scenario, there are two disks on the computer, Disk 0 and Disk 1. Both disks are
dynamic disks and have at least 1 gigabyte (GB) of free unallocated space on each disk
for a total volume of 2 GB.

1. In the lower-right pane of the Disk Management tool, right-click the free,
unallocated volume space on either disk, and then click Create Volume.

2. After the Create Volume Wizard starts, click Next.

3. Under Volume Type, click Striped Volume > Next.

4. In the left pane under Select Two or More Disks, a list is displayed that contains all
disks that have enough free, unallocated space to participate in the striped volume.

In the right pane under Selected, the disk that you right-clicked in step 1 is
displayed.

5. In the left pane under All Available Dynamic Disks, click the disk, and then click
Add.

All disks that are displayed in the right pane are labeled Selected. View the bottom
of the Select Disk dialog box under the Size label. The For All Selected Disks box
displays the maximum size of the striped volume that you can make.

７ Note

The volume on each disk is the same size in the completed striped volume.
For example, if you have 100 MB on the first disk, you have 100 MB on the
 second disk. Therefore, the total size of your combined volumes is double that
of the smaller of the volumes on the two disks.

You can reduce the size of the volume by modifying the value in the Disk Size box.
Keep in mind that on a system that has two disks, the total striped volume size is
double the size that you enter. The Total Volume Size box under the right pane
displays the actual size of the striped volume.

6. Click Next to advance to the Assign Drive Letter Path page of the wizard.

7. At this time, you may want to assign a drive letter to your striped volume (you can
also do this at any other time). To do so, click Assign Drive Letter, and then enter
an available drive letter.

Alternatively, you can click Do not assign drive letter or path. You can also click
Mount this volume on an empty folder that supports drive paths. However, this
selection is beyond the scope of this article.

8. After you enter a drive letter for your striped volume, click Next.

9. Click Format this partition with the following settings, and then follow these
steps:

a. Enter the file system type.

Note that FAT32 or NTFS is acceptable.

b. Leave the default selection in the Allocation Unit Size box.

c. In the Volume Label box, you can keep the default New Volume label or you
can type you own label.

d. At this time, you can click to select the Quick Format and File and Folder
Compression check boxes. Or you can defer both of these tasks if you want.

10. Click Next, check your selection in the Summary window, and then click Finish.

The striped volumes are displayed on the two disks on your system. They have the same
color code, the same drive letter (if you mapped the drive during the procedure), and
they're both the same size.

Troubleshooting
Don't mix hardware RAID 0 with software RAID 0.
 A striped volume can't hold the system or boot partition of a Windows Server
2003-based system.
You can't extend or mirror striped volumes.
There's no fault tolerance on a striped volume. This means that if one of the disks
becomes damaged or no longer functions properly, the whole volume is lost.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to mirror the system and boot
partition (RAID1)
Article • 12/26/2023

This article describes how to mirror the system and boot partition (RAID1).

Applies to: Windows Server 2003

Original KB number: 323432

Summary
This step-by-step article describes how to mirror the system and boot partition in
Windows Server 2003. This scenario is based on the assumption that the system and
boot files are located on disk 0 and that disk 1 is unallocated space.

Requirements
At least two hard-disk drives; IDE, small computer system interface (SCSI), or mixed
architecture is permissible.
The second drive must be at least the size of the volume on which the operating
system boot and system files reside to permit mirroring.
The Windows Server 2003 system and boot files must reside on the same volume
to be mirrored.

７ Note

The memory dump file is written only to the boot hard disk. Windows Server 2003
can continue to work with a mirrored system disk configuration even if one of the
disks in the mirror is removed. However, the memory dump file cannot be written
to the remaining system disk in the mirror. You must schedule a system restart for
the memory dump file to be written to the remaining hard disk.

Set up the disk management system

1. Click Start, point to Administrative Tools, and then click Computer Management to
open the Computer Management console.

2. Expand the Storage node.

 3. Click Disk Management.

4. On the View menu, point to Top, and then click Disk List.
In the right pane, the attributes of each disk in the system are displayed.

5. On the View menu, point to Bottom, and then click Graphical View.

At the bottom of the right pane, a color-coded graphical view of the disks on the
system is displayed:

Disk description panel: The disk description panel (which is gray) is located to
the left of the volume description, which is in color. The disk description
contains information about each disk's disk number, whether its
configuration is basic or dynamic, its size, and its online or offline status.
Volume description panel: The volume description panels are color-coded.
They hold information about each volume, such as the drive letter (if
assigned), whether the volume is allocated or unallocated, the partition or
volume size, and the health status of the volume.

Upgrade to dynamic disks

RAID systems require dynamic disks in Windows Server 2003. Any disks that you are
upgrading must contain at least 1 megabyte (MB) of free space at the end of the disk
for the upgrade to succeed. Disk Management automatically reserves this free space
when it creates partitions or volumes on a disk, but disks with partitions or volumes that
are created by other operating systems may not have this free space available.

７ Note

You must be logged on as an administrator or a member of the Administrators

group to complete this procedure. If your computer is connected to a network,
network policy settings may also prevent you from completing this procedure.

To upgrade a basic disk to a dynamic disk, follow these steps:

1. Before you upgrade disks, quit any programs that are running on those disks.
2. Right-click the gray disk description panel, and then click Upgrade to Dynamic
Disk.
3. If the second disk is not a dynamic disk, follow these steps to upgrade it to a
dynamic disk.

Mirror the boot and system volume

In this scenario, disk 1 is the disk on which the image of disk 0 will be mirrored.

７ Note

Partitions are referred to as volumes when the disks are dynamic.

1. Disk 1 must be unallocated space before you can proceed with mirroring.

2. Right-click disk 0 (which contains the boot and system files), and then click Add
Mirror.

3. A dialog box opens in which any disk on your system that is available for mirroring
is displayed. Select the disk of your choice (in this example, it is disk 1), and then
click Add Mirror.

Both disk 0 and disk 1 will now have the same color code, the same drive letter,
and the volumes will have the status note "Regenerating" displayed while the
information is being copied from the first disk to the second disk. The system will
automatically size the volume of the new mirror to the same size as of the original
boot and system volume.

4. If you now want to boot from the new mirrored disk, you have to change the
Boot.ini ARC path that points the computer to the partition in which the system
files are located.

Troubleshooting
After you upgrade a basic disk to a dynamic disk, any existing partitions on the basic
disk become (dynamic) simple volumes. You cannot change the dynamic volumes back
to partitions.

A dynamic disk cannot contain partitions or logical drives, nor can it be accessed by MS-
DOS or by any Windows operating systems other than Windows Server 2003.

） Important

Do not use a hardware RAID solution and a software RAID solution on the same
disk.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Automating Disk Cleanup tool in
Windows
Article • 12/26/2023

This article describes how to run the Disk Cleanup tool (cleanmgr.exe) by using
command-line switches. cleanmgr.exe is designed to clear unnecessary files from your
computer's hard disk. You can configure cleanmgr.exe with command-line switches to
clean up the files you want. You can then schedule the task to run at a specific time by
using the Scheduled Tasks tool.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1
Original KB number: 253597

Command-line switches
You can start the Disk Cleanup tool by running cleanmgr.exe, or by selecting Start >
Programs > Accessories > System Tools > Disk Cleanup. Disk Cleanup supports the
following command-line switches:

/d <driveletter> : - This switch selects the drive that you want Disk Cleanup to

clean. The /d switch isn't used with /sagerun:n .

/sageset:n - This switch displays the Disk Cleanup Settings dialog box and creates

a registry key to store the settings you select. The n value is stored in the registry
and allows you to specify different tasks for Disk Cleanup to run. The n value can
be any integer value from 0 to 65535. To get all the available options when you use
the /sageset switch, you may need to specify the drive letter that contains the
Windows installation.
For more information, see Registry key information.

/sagerun:n - This switch runs the specified tasks that are assigned to the n value

by using the /sageset switch. All drives in the computer will be enumerated, and
the selected profile will be run against each drive.

For example, in Scheduled Tasks, you could run the following command after
running the cleanmgr /sageset:11 command:
cleanmgr /sagerun:11 .

This command runs Disk Cleanup with the options that were specified with the
cleanmgr /sageset:11 command.
The available options for Disk Cleanup that you can specify by using the /sageset and
/sagerun switches include:

Temporary Setup Files - These files shouldn't be needed anymore. They were
originally created by a Setup program that's no longer running.
Downloaded Program Files - They are ActiveX controls and Java programs that are
downloaded automatically from the Internet when you view certain pages. They're
temporarily stored in the Downloaded Program Files folder on your hard disk. This
option includes a View Files button that allows you to see the files that would be
removed.
Temporary Internet Files - The Temporary Internet Files folder contains Web pages
that are stored on your hard disk for quick viewing. Your personalized settings for
Web pages are left intact. This option includes a View Files button that displays the
files to be deleted.
Old Chkdsk Files - When Chkdsk checks your disk for errors, it might save lost file
fragments as files in your disk's root folder. These files are unnecessary and can be
removed.
Recycle Bin - The Recycle Bin contains files you've deleted from your computer.
These files aren't permanently removed until you empty the Recycle Bin. This
option includes a View Files button that opens the Recycle Bin.
Temporary Files - Programs sometimes store temporary information in a Temp
folder. Before a program quits, it usually deletes this information. You can safely
delete temporary files that haven't been modified in over a week.
Temporary Offline Files - Temporary offline files are local copies of recently used
network files that are automatically cached for you. You can use them when you're
disconnected from the network. There's a View Files button that opens the Offline
Files folder.
Offline Files - Temporary files are local copies of network files that you specifically
made available offline. You can use them when you're disconnected from the
network. There's a View Files button that opens the Offline Files folder.
Compress Old Files - Windows can compress files that you haven't used in a while.
Compressing the files saves disk space while still enabling you to use them. No
files are deleted. Because files are compressed at different rates, the displayed
amount of disk space you'll gain is approximate. You can use the Options button
to specify the number of days to wait before an unused file is compressed.
Catalog Files for the Content Indexer - The Indexing service speeds up and
improves file searches by maintaining an index of the files on the disk. These files
are left over from a previous indexing operation and can be deleted safely.

If you select the drive that contains the Windows installation, all of these options are
available on the Disk Cleanup tab. If you select any other drive, only the Recycle Bin and
Catalog files for content index options are available on the Disk Cleanup tab.

The More Options tab contains options for cleaning up Windows components or
installed programs. You can use the Windows Components option to create free space
by removing optional Windows components that you don't use. Selecting the Clean Up
button for this option starts the Windows Components Wizard. You can use the
Installed Programs option to free more disk space by removing programs that you
don't use. Selecting this Clean Up button starts the Change or Remove Programs
option in the Add/Remove Programs tool.

Registry key information

After you run cleanmgr.exe with the /sageset:n switch, some of the registry sub keys
under the the following registry key are modified:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

Each of the modified registry sub keys may contain a REG_DWORD type registry value
StateFlagsNNNN, where NNNN is the number n specified in the switch. For example,
after you run the cleanmgr /sageset:9 command, a registry value Stateflags0009 is
added. The registry value can be set as one of the following values.

If the option box is not selected, the value is 00000000.

If the option box is selected, the value is 00000002.

７ Note

Under the VolumeCaches registry key, the Offline Pages Files registry sub key
doesn't have the stateflags values. There is not an option to delete these files.

For more information, see Creating a Disk Cleanup Handler.

Additional information
For a Microsoft Windows XP version of this article, see How to Automate the Disk
Cleanup Tool in Windows XP .

７ Note
 Disk Cleanup option on drive's general properties and cleanmgr.exe is not present
in Windows Server 2008 R2 by default. For more information on how to have Disk
Cleanup button or cleanmgr.exe on Windows Server 2008 R2, see Disk Cleanup
option on drive’s general properties and cleanmgr.exe is not present in Windows
Server 2008 R2 by default.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set up dynamic boot partition
mirroring on GUID partition table (GPT)
disks in Windows Server 2008
Article • 12/26/2023

This article contains steps and examples of how to set up dynamic boot partition
mirroring on GUID partition table (GPT) disks in Windows Server 2008.

Applies to: Windows Server 2012 R2

Original KB number: 951985

Introduction
This step-by-step article describes how to successfully set up dynamic boot partition
mirroring on GUID partition table (GPT) disks in Windows Server 2008. Unlike the master
boot record (MBR) mirrors on 32-bit versions of Windows, there are more steps to
successfully create and to start mirrored boot volumes on GPT disks. This article also
describes how to recover after a primary disk failure.

You must have the built-in Diskpart.exe and Bcdedit.exe utilities to create mirrored boot
volumes on GPT disks in Windows Server 2008. You can use the Disk Management
console do some of these tasks. But for other tasks, you have to use the built-in
Diskpart.exe utility.

For consistency and for ease of use, this article uses the Diskpart.exe utility in the
procedures in this article. For help with any of the Diskpart.exe commands, start
Diskmgmt.msc, and then open the Help topics on the Help menu. The steps that are
described in the procedures in this article use real examples.

The procedures in this article show the expected results that each command returns. In
these procedures, disk 0 is the primary system and the boot drive, and disk 1 is the
secondary drive.

７ Note

For Windows Server 2012 documentation, see the following TechNet blog post:
Tip of the Day: Configuring Disk Mirroring for Windows Server 2012
More information

Prepare the secondary drive for mirroring

Before you set up boot volume mirroring, we recommend that you have another GPT
disk in the computer that contains an Extensible Firmware Interface (EFI) partition. The
EFI partition contains the system files that are used to start the operating system. The
disk must have an EFI partition to start. If the primary system drive (disk 0) fails, you can
use the EFI partition on the secondary drive (disk 1) to start the operating system. This
section describes how to create and to prepare new EFI and Microsoft Reserved (MSR)
partitions on the secondary drive. You can use only the Diskpart.exe utility to create the
EFI and MSR partitions that are required. You can't use the Disk Management console to
create or to mirror EFI or MSR partitions.

Before you start the following procedure, make sure that you have another basic disk
that has unallocated free space that is greater than or equal to the capacity of the
system and boot partitions of the primary disk. If you already converted the spare drive
to a dynamic disk, revert it back to a basic drive before you follow these steps.

1. At a command prompt, run the Diskpart.exe utility.

７ Note

This starts the diskpart console. After the console is initialized, DISKPART> is
displayed. The diskpart console is now ready for input commands.

2. Select the disk that you want to be the secondary drive, and then convert the drive
to GPT. In this example, disk 1 is used for the mirror (secondary) drive.

７ Note

The disk that you select must not contain any data partitions. Additionally, the
disk must be a raw basic disk that has unallocated space that is greater than
or equal to the capacity of the primary system disk.

The following are the commands that you type at the command prompt. The
commands are formatted in bold, and the comments about the command or
about the contents of the screen display are formatted in plain text.

Console
 DISKPART> Select disk 1
Disk 1 is now the selected disk.

DISKPART> Convert GPT

Diskpart successfully converted the selected disk to GPT format.

DISKPART> List partition

Partition ### Type Size Offset

--------------- ---------------- --------- -------
Partition 1 Reserved 128 MB 17 KB

７ Note

If you notice that more than one partition is displayed, you have selected the
wrong drive, or you did not start with a raw drive. Correct this before you
continue, or data loss may occur.

3. Select partition 1 on disk 1, and then delete it. You must use the override
command to delete the Microsoft Reserved (MSR) partition. You'll re-create a new
MSR partition after you create the required EFI partition.

Console

DISKPART> Select partition 1

Partition 1 is now the selected partition.

DISKPART> Delete partition override

Diskpart successfully deleted the selected partition.

4. Select disk 0, and then list the partitions that are on disk 0. With the output of the
list command, create new EFI and MSR partitions on disk 1 that are the same sizes
as the EFI and MSR partitions on disk 0.

Console

DISKPART> Select disk 0

Disk 0 is now the selected disk.

DISKPART> List partition

Partition ### Type Size Offset

----------------- ---------------- --------- -------
Partition 1 System 200 MB 1024 KB <- EFI PARTITION
Partition 2 Reserved 128 MB 201 MB <- MSR PARTITION
Partition 3 Primary 50 GB 329 MB
 DISKPART> select disk 1
Disk 1 is now the selected disk.

DISKPART> create partition efi size=200

Diskpart succeeded in creating the specified partition.

DISKPART> create partition msr size=128

Diskpart succeeded in creating the specified partition

DISKPART> list partition

Partition ### Type Size Offset

------------- ---------------- ------- -------
Partition 1 System 200 MB 1024 KB
*Partition 2 Reserved 128 MB 201 MB

Convert the primary and secondary drives to dynamic

disks
Before you can create a mirror, both the primary (source) drive (disk 0) and the
secondary (destination) drive (disk 1) must be converted to dynamic disks. After you
convert both disks to dynamic disks, you can create the mirror. You can use the Disk
Management console or the Diskpart.exe utility to convert both the primary drive and
the secondary drive to dynamic disks.

When you use the Diskpart.exe utility, select the drive that you want to convert to a
dynamic disk, and then convert the drive to a dynamic disk. You must follow this step on
both the secondary and primary GPT drives. To convert both the primary and secondary
drives to dynamic disks, follow these steps:

Console

DISKPART> Select disk 1

Disk 1 is now the selected disk

DISKPART> Convert dynamic

Diskpart successfully converted the selected disk to Dynamic format.

DISKPART> Select disk 0

Disk 0 is now the selected disk

DISKPART> Convert dynamic

DiskPart successfully converted the selected disk to dynamic format.

DISKPART> Exit
Leaving Diskpart...
Establish a mirror from the boot volume to the secondary
drive
After you convert both the primary drive (disk 0) and secondary drive (disk 1) to
dynamic disks, you can establish a mirror from the boot volume to the secondary drive.
To do this, you can use either the Disk management console or the Diskpart.exe utility.
To do this by using the Diskpart.exe utility, follow these steps.

1. At the DISKPART> prompt, select the boot volume (C:), and then mirror the volume
to the secondary drive (disk 1).

Console

DISKPART> Select volum

Volume 1 is the selected volume.

DISKPART> add disk=1

Diskpart succeeded in adding a mirror to the volume.

2. Wait for the volume synchronization to complete, and then exit Diskpart.exe. You
can check the progress of the synchronization in the Diskmgmt.msc console.

Format the EFI partition

You must now copy the BCD store and the contents of the EFI partition from the primary
drive (disk 0) to the secondary drive (disk 1).

７ Note

You must follow these steps when the BCD store is modified on either drive.

Use the Diskpart.exe utility to select the EFI partition on the secondary drive, and then
assign a letter to the EFI partition so that it can be formatted. In the following example,
the drive letter "S" is assigned to the EFI partition on the secondary drive. You can use
any available drive letter for this step.

Console

DISKPART> Select disk 1

Disk 1 is now the selected disk.

DISKPART> Select partition 1

Partition 1 is now the selected partition.
 DISKPART> Assign letter=S
DiskPart successfully assigned the drive letter or mount point.

Use Diskpart to format the "S" partition to use the FAT32 file system. The system can't
start from an EFI partition unless it's formatted to use the FAT32 file system. To do this,
type the following command, and then press ENTER:

Console

DISKPART> format fs=FAT32 quick

Select the EFI partition on the primary drive (disk 0), and then assign a drive letter to
that EFI partition. In this example, the drive letter "P" is assigned to the primary EFI
partition on disk 0. You can use any available drive letter for this step.

Console

DISKPART> Select disk 0

Disk 0 is now the selected disk.

DISKPART> Select partition 1

Partition 1 is now the selected partition.

DISKPART> Assign letter=P

DiskPart successfully assigned the drive letter or mount point.

Exit Diskpart.

Use Bcdedit.exe to configure boot entries for the

mirrored disk
Use the BCDedit command to view the current Windows boot entries. During the "add
disk" operation to create the mirror, the Volume Disk Service (VDS) created a secondary
entry in the Windows Server 2008 boot configuration, also known as the BCD store, for
the Windows Boot Loader on disk 1. To view the current Windows boot entries, follow
these steps:

1. Open a command prompt.

2. At the command prompt, type P: , and then press ENTER to change to drive P.

3. At the command prompt, type cd EFI\Microsoft\Boot , and then press ENTER to

change to the Boot folder.
4. At the command prompt, type bcdedit /enum , and then press ENTER. Then, you
see output that resembles the following:

Windows Boot Manager

--------------------
identifier {bootmgr}
device partition=P:
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
displayorder {current}
{1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader

-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Microsoft Windows Server 2008
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {b158d5f9-d91f-11dc-bc7e-e72bb3afd58e}
nx OptOut

Windows Boot Loader

-------------------
identifier {1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
device partition=C:
path \Windows\system32\winload.efi
description Microsoft Windows Server 2008 - secondary plex
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
 resumeobject {b158d5f9-d91f-11dc-bc7e-e72bb3afd58e}
nx OptOut

The Windows Boot Loader with the description, "Microsoft Windows Server 2008 -
secondary plex," was created by VDS during the "add disk" operation. The
Windows Boot Loader entry "Partition=C:" represents the volume C that is
mirrored, and this entry references the copy of Winload.efi file on disk 1 that will
start Windows Server 2008 from disk 1.Next, create a copy of the current Windows
Boot Manager so that it can be used from the EFI firmware startup menu to make
Windows Server 2008 start from either disk 0 or disk 1. The bcdedit /copy
command copies the current Windows Boot Manager entry to a new Windows
Boot Manager entry that has the description, "Windows Boot Manager Cloned."
The bcdedit /set command uses the GUID of the new Windows Boot Manager, and
the command sets the device partition to reference the copy of the Bootmgr.efi file
that is located on the "S" partition on disk 1. The following is an example of a
GUID:

FD221F0A-5B5D-484A-99FE-DEB4B3F90C32

The following example shows how to use the bcdedit commands.

1. At the command prompt, type bcdedit /copy {bootmgr} /d "Windows Boot Manager
Cloned" , and then press ENTER. An output that resembles the following is

displayed:

The entry was successfully copied to { GUID }.

2. At the command prompt, type bcdedit /set { GUID } device partition=s:

, and then press ENTER. In this command, replace GUID with the GUID in the
output from the previous command. An output that resembles the following is
displayed:

The operation completed successfully.

3. At the command prompt, type bcdedit /enum all , and then press ENTER to verify
the changes that were made. Then, you see output that resembles the following:

Firmware Boot Manager

---------------------
identifier {fwbootmgr}
displayorder {bootmgr}
 {1ba28ce0-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce1-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28cdf-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28cde-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce2-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce3-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce5-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce4-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28ce8-d91e-11dc-bc7e-e72bb3afd58e}
timeout 2

Windows Boot Manager

--------------------
identifier {1ba28ce8-d91e-11dc-bc7e-e72bb3afd58e}
device partition=S:
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager Cloned
locale en-US
inherit {globalsettings}
default {current}
displayorder {current}
{1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Manager

--------------------
identifier {bootmgr}
device partition=P:
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
displayorder {current}
{1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
toolsdisplayorder {memdiag}
timeout 30

4. Close the Command Prompt window.

 ７ Note

That the last GUID in the Firmware Boot Manager display order is the same
GUID as the secondary Windows Boot Manager on the "S" partition. This
means that the new Windows Boot Manager that has the description
"Windows Boot Manager Cloned" is synchronized in the NVRAM that is used
by the firmware when the EFI firmware displays the firmware startup menu.
There are now two NVRAM entries for Windows Boot Manager, one on the
"P" partition and the other on the "S" partition. The EFI firmware lists these
entries in the EFI startup menu.

Copy the EFI partition and the BCD store to the second
drive
To export the EFI partition and the BCD store to the second drive, follow these steps:

1. Export the BCD store to the EFI partition on disk 0. This lets you copy the BCD
store from disk 0 to disk 1. To do this, follow these steps:

a. Open a command prompt.

b. At the command prompt, type bcdedit /export P:\EFI\Microsoft\Boot\BCD2 ,

and then press ENTER to export the BCD store to a file that is named "BCD2."
An output that resembles the following is displayed:

The operation completed successfully.

2. Use the Robocopy command to copy the system files from "P" (the EFI partition on
the primary drive) to "S" (the EFI partition on the secondary drive). You must do
this to make sure that the secondary drive can start the system if disk 0 fails. Make
sure that you use the correct drive letters if you used different letters for your EFI
partitions. To do this, type robocopy p:\ s:\ /e /r:0 at the command prompt, and
then press ENTER.

3. Rename the BCD store on disk 1 so that it matches the name of the store on disk 0.
To do this, type rename S:\EFI\Microsoft\Boot\BCD2 BCD at the command prompt,
and then press ENTER.

4. Delete the duplicate BCD store on disk 0. To do this, type del

P:\EFI\Microsoft\Boot\BCD2 at the command prompt, and then press ENTER.
 5. Remove the drive letters that are assigned to both EFI partitions. This step is
optional because the drive letters aren't re-assigned after a system restart. To
remove the drive letters that are assigned to both EFI partitions, follow these steps:

a. At the command prompt, type diskpart.exe , and then press ENTER.

b. At the DISKPART> prompt, type Select volume P .

Volume 1 is the selected volume.

c. At the DISKPART> prompt, type Remove .

Diskpart successfully removed the drive letter or mount point.

d. Repeat steps 5b and 5c for the "S" partition.

Test the secondary drive by using the new Windows

Server 2008 boot entries
After you've updated the BCD configuration, test the entries to make sure that the
system can start by using the secondary drive if disk 0 fails. To do this, follow these
steps:

1. Shut down and then restart the computer.

2. On the startup menu, select the startup entry in EFI that is named "Windows Boot
Manager Cloned." This option lets you restart to the Windows Boot Manager on
the EFI partition of the secondary drive. Then, select "Microsoft Windows Server
2008 - secondary plex" to start Windows Server 2008 from the secondary drive.

７ Note

In an MUI environment, the secondary plex entry in the Windows Boot

Manager may be displayed as "Microsoft Windows Server 2008 - ????? ?????".
You can use the bcdedit /set { GUID } description "Description" command to
give the secondary plex entry a more meaningful name. For example, you can
use the following command: bcdedit /set {7e4632e7-0b4d-11dd-813b-
bcbfbfe8b578} description "Microsoft Windows Server 2008 - Secondary Plex"

After you complete this step to give the secondary plex entry a more meaningful
name, make sure that you copy the BCD store to the secondary drive by using the
steps that are described in the "Copy the EFI partition and the BCD store to the
second drive" section.
Reestablish the primary boot drive mirror
If there's a failure of the primary drive (disk 0), you must start the computer in the
secondary drive (disk 1), and then re-create the mirror to return the boot volume to a
fault-tolerant state. To do this, follow these steps.

1. Replace the failed dynamic disk 0 by using the directions that are provided by your
hardware vendor. Make sure that the disk has no partition information. The
diskpart clean command can be used to destroy any existing partition information
on the disk.

７ Note

Be careful when you run the diskpart clean command because it will
destroy the partition table on the selected disk, and it will make the
contents of the disk inaccessible.
Throughout this section, the former primary disk will continue to be
known as disk 0, and the former secondary disk will continue to be
known as disk 1. However, after you follow these steps, disk 1 will be the
new primary disk, and disk 0 will be the new secondary disk.

2. Select Windows Boot Manager Cloned to start the computer by using the EFI
partition on the secondary drive. When the Boot Manager appears, select
Microsoft Windows Server 2008 - secondary plex.

3. Import the BCD store located on the EFI partition on disk 1. This sets the BCD store
on disk 1 as the active system store, and lets it be modified. To do this, follow these
steps:

a. Start DiskPart.

b. Run the following commands to select the EFI partition on disk 1, and to assign
to it drive letter "S."

Console

DISKPART> select disk 1

DISKPART> select partition 1
DISKPART> assign letter=s

c. Exit DiskPart.
 d. Run the command bcdedit /import S:\EFI\Microsoft\Boot\BCD /clean to
import the store from the EFI partition on disk 1.

4. You have to break the broken mirror. However, you must first determine which is
the correct disk on which to run the diskpart break command. After you do this,
select the mirror volume (Volume #), and then view the details to determine from
which missing disk (m#) you have to break the mirror. To do this, follow these
steps:

a. Start DiskPart.

b. Select the mirror volume, typically volume C (the boot volume):

Console

DISKPART> select volume c

c. Use the detail volume or list disk command to determine the identifier for the
missing disk, typically m0:

Console

DISKPART> detail volume

d. Break the mirror by specifying the identifier for the missing disk that you
obtained in step 5c (for example, m0):

Console

DISKPART> break disk=m0 nokeep

e. List the volumes to make sure that the mirror is gone and that the volume is
now listed as a simple volume:

Console

DISKPART> list volume

f. Delete the missing disk (m0):

Console

DISKPART> select disk m0

 DISKPART> delete disk

g. Exit DiskPart.

5. Remove all stale entries from the BCD store to return the system to a known clean
state. Also, rename the entries to accurately reflect the current state of the system.
To do this, follow these steps:
a. Run the command bcdedit /enum all /v to determine the GUID of the entry in
NVRAM that has the description "Windows Boot Manager" and that has a
device parameter of unknown or a missing device parameter. After you
determined the GUID for this entry, use the command bcdedit /set {GUID}
device partition=s: to point the entry to disk 1.
b. Use the output from the bcdedit /enum all /v command to determine the
GUID of the "Windows Boot Manager Cloned" entry in NVRAM. After you
determine the GUID for this entry, use the command bcdedit /delete {GUID} to
delete the old entry for disk 1 from NVRAM.
c. In the output for the bcdedit /enum all /v command, look for an entry named
"Windows Resume Application" that has a device parameter of unknown or a
missing device parameter. Delete this entry using the bcdedit /delete {GUID}
command.
d. In the bcdedit /enum all /v output, look for an entry that has the description,
"Windows Resume Application - Secondary Plex." Use the command bcdedit
/set {GUID} description "Windows Resume Application" command to rename

the entry to reflect that this is now the Windows Resume Application entry for
the primary mirror plex.
e. In the output for the bcdedit /enum all /v command, look for an entry that has
the description, "Windows Server 2008" and that has a device parameter of
unknown or a missing device parameter. Delete this entry using the bcdedit
/delete {GUID} command.
f. In the bcdedit /enum all /v output, look for an entry that has the description
"Windows Server 2008 - Secondary Plex." Use the command bcdedit /set
{GUID} description "Windows Server 2008" to rename the entry to reflect that

this is now the boot manager entry for the primary mirror plex.
g. Look for the BCD entry that has the description, "Windows Memory Diagnostic."
Use the command bcdedit /set {GUID} device partition=s: to point the entry to
the memory tester that is located on disk 1.
h. Run the command bcdedit /enum all /v to verify the NVRAM and BCD entries.
i. Restart the computer. Select "Windows Boot Manager" and "Windows Server
2008" to start in disk 1.
6. Convert the newly added disk to GPT format, and then create the partition
structure. To do this, follow these steps:

a. Start DiskPart.

b. Convert disk 0 to GPT format:

Console

DISKPART> select disk 0

DISKPART> convert GPT

c. Delete the partition on disk 0 that is created automatically:

Console

DISKPART> list partition

DISKPART> select partition 1
DISKPART> delete partition override

d. Record the partition layout for disk 1 to duplicate the layout on disk 0:

Console

DISKPART> select disk 1

DISKPART> list partition

e. Duplicate the layout of disk 1 on disk 0. To calculate the size of the MSR
partition for this step, add together the size of the MSR "Reserved" partition and
the "Dynamic Reserved" partition that is listed in DiskPart for disk 1. For
example, if the MSR partition is 127 MB on disk 1, and if the "Dynamic
Reserved" partition is 1 MB on disk 1, then create a 128-MB MSR partition on
disk 0. Generally, the EFI partition should be 200 MB, and the MSR partition
should be 128 MB. To duplicate the layout of disk 1, run these commands:

Console

DISKPART> select disk 0

DISKPART> create partition efi size=200
DISKPART> create partition msr size=128

f. List the partitions that are on the system to verify that disk 0 contains both an
EFI and an MSR partition:

Console
 DISKPART> list partition

7. Convert both disks to dynamic disks if they aren't already dynamic disks:

Console

DISKPART> select disk 0

DISKPART> convert dynamic
DISKPART> select disk 1
DISKPART> convert dynamic

8. Add the new disk 0 to a mirror of the boot volume:

Console

DISKPART> select volume c

DISKPART> add disk=0

9. While the mirror resynchronization is occurring, prepare the EFI partition on disk 0:

Console

DISKPART> select disk 0

DISKPART> select partition 1
DISKPART> format fs=fat32 quick

Exit DiskPart

10. Wait for the mirror resynchronization to finish. You can use Disk Management to
check on the resynchronization process.

11. If the EFI partition on disk 0 isn't already assigned the drive letter "P," and if the EFI
partition on disk 1 isn't already assigned the drive letter of "S," assign the
appropriate drive letters to the EFI partitions on disk 0 and disk 1: Start Diskpart.

Console

DISKPART> select disk 0

DISKPART> select partition 1
DISKPART> assign letter=p
DISKPART> select disk 1
DISKPART> select partition 1
DISKPART> assign letter=s

Exit DiskPart.
12. Clone the boot manager entry in NVRAM for disk 1:
a. Clone the boot manager entry using the bcdedit /copy {bootmgr} /d "Windows
Boot Manager Cloned" command. Record the GUID for the new entry that is

given in the output for this command.

b. Set the device parameter in the cloned entry to point to the EFI partition on disk
0 by using the bcdedit /set {GUID} device partition=p: command. Use the
GUID from the output of the bcdedit /copy command.
c. Run the command bcdedit /enum all /v to verify the changes.

13. Copy the contents of the EFI partition on disk 1 to the EFI partition on disk 0 so
that you can boot from disk 0:
a. Export the active BCD store by using the command bcdedit /export
S:\EFI\Microsoft\Boot\BCD2

b. Copy the EFI partition from disk 1 to disk 0 by using the command robocopy s:\
p:\ /e /r:0

c. Rename the copied BCD store on disk 0 to BCD by using the command rename
P:\EFI\Microsoft\Boot\BCD2 BCD .

d. Delete the duplicate exported BCD store on disk 1 by using the command del
S:\EFI\Microsoft\Boot\BCD2

14. Follow these steps:

a. Remove the drive letters that you assigned in DiskPart:

Console

DISKPART> select volume p

DISKPART> remove
DISKPART> select volume s
DISKPART> remove

b. Restart the computer to verify that you can boot from either disk 0 or disk 1.

７ Note

By default, the boot entries will point to disk 1. If you boot from disk 0, and If you
have to modify the BCD store when you start in disk 0, you first have to import the
store:

1. Start DiskPart.

2. Select the EFI partition on disk 0, and assign to it the drive letter "P":
 Console

DISKPART> select disk 0

DISKPART> select partition 1
DISKPART> assign letter=p

3. Exit DiskPart.

4. Run the command bcdedit /import P:\EFI\Microsoft\Boot\BCD /clean to

import the store from the EFI partition on disk 0.

７ Note

You should always boot from the BCD entry that corresponds to the NVRAM entry
that you selected when you started the computer. For example, if you selected the
"Windows Boot Manager" (primary disk) NVRAM entry, you may have to select the
"Windows Server 2008" (primary disk) BCD entry for the system to start correctly. If
you selected the "Windows Boot Manager Cloned" (secondary disk) NVRAM entry,
you should select the "Microsoft Windows Server 2008 - secondary plex"
(secondary disk) BCD entry.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Intel SSD D3-S4510 and Intel SSD D3-
S4610 series 1.92 TB and 3.84 TB drives
unresponsive after 1,700 cumulative idle
power-on hours
Article • 12/26/2023

This article discusses that Intel SSD D3-S4510 and Intel SSD D3-S4610 series 1.92 TB and
3.84 TB drives become unresponsive after 1,700 cumulative idle power-on hours.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4499612

Symptoms
Intel SSD D3-S4510 and Intel SSD D3-S4610 series drives in the 1.92 TB and 3.84 TB
capacities may experience an NAND "channel hang" condition in firmware release
XCV10100 that could cause the drive to become unresponsive after approximately 1,700
hours of cumulative idle power-on time.

When this issue occurs on a Windows Server Storage Spaces Direct (S2D) cluster, the
cluster may experience any of the following symptoms:

Slow workload performance.

Virtual disks in the cluster have an Operational Status value of Detached or No
Redundancy.
The physical disk reports a status of Lost Communication or IO Error.
The physical disk reports a status of Transient Error if the cluster node is restarted
while the disk is in the unresponsive state.

Resolution
The NAND "channel hang" issue is currently addressed in the Maintenance Release 1
(MR1) of Intel firmware (version XCV10110) as of March 2019. We recommend that you
update to the latest firmware before the drive reaches 1,700 cumulative idle power-on
hours.

Run the Intel SSD Data Center Tool to inspect all affected disks as soon as possible, and
take corrective actions as recommended. For more information, see Intel SSD Data
Center Tool .

The following MR1 firmware binary is available for use together with the Storage Spaces
Direct automated firmware update method, as appropriate for your device.

Dell Serial-ATA_Firmware_8VGP8_WN64_DL63_A00.EXE
Lenovo Intel S4510 and S4610 SATA SSD issue - Lenovo Server, Lenovo
ThinkSystem and IBM Server

７ Note

There is no counter or other attribute that reports drive idle power-on hours. Intel
recommends that you use SMART 09h (drive power-on hours) as an approximation
of the idle power-on hours. Therefore, Intel strongly recommends that you update
the firmware as soon as possible to avoid the risk of unrecoverable data loss. The
new MR1 firmware will not resolve any read-uncorrectable errors that existed
before the firmware upgrade. Intel has released a Data Center Tool (DCT) to identify
whether the issue is successfully corrected by installing the MR1 firmware. The tool
also describes possible next steps.

For more information about the DCT tool, see Intel Solid State Drive Data Center
Tool User Guide .

More information
This is a hardware issue that may affect the Microsoft products that are listed in the
"Applies to" section. Intel has determined the root cause of the issue and confirmed that
the issue is addressed in the firmware version that is based on "Maintenance Release 1."

Known hardware that is affected

Hardware based on the Intel SSD D3-S4510 and Intel SSD D3-S4610 series drives in the
1.92 TB and 3.84 TB capacities.

Known hardware that is not affected

Hardware based on the Intel SSD D3-S4510 and Intel SSD D3-S4610 series drives
in the 240 GB, 480 GB, and 960 GB capacities.
Hardware based on the Intel SSD DC S4500 and Intel SSD DC S4600 family of SATA
devices.
 Hardware based on the Intel SSD DC P4500 and Intel SSD DC P4600 family of
NVMe devices.

References
For more information about how to update storage device firmware in an automated
manner by using Storage Spaces Direct (S2D), see the following Docs website:
Automated firmware updates with Storage Spaces Direct

For a step-by-step video about how to update storage device firmware in an automated
manner by using Storage Spaces Direct (S2D), see the following Windows Server
Channel website:
Update Drive Firmware Without Downtime in Storage Spaces Direct

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Third-party contact disclaimer

Microsoft provides third-party contact information to help you find additional

information about this topic. This contact information may change without notice.
Microsoft does not guarantee the accuracy of third-party contact information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Introduce the new logging mechanism
for the VDS
Article • 12/26/2023

This article introduces the new logging mechanism for Virtual Disk Service (VDS) in
Windows Server 2012.

Applies to: Windows Server 2012 R2

Original KB number: 2759114

Introduction
The VDS in Microsoft Windows Server is a set of APIs that provides a single interface to
manage disks. The VDS provides an end-to-end solution to manage storage hardware
and disks and to create volumes on the disks. This article introduces the new logging
mechanism for VDS in Windows Server 2012. The VDS logging for previous version of
Windows is removed.

More information
To help you troubleshoot any problems with the VDS, capture VDS trace. To capture VDS
trace, follow these steps:

1. Open an elevated command prompt, and then run the following commands:
a. md %systemroot%\system32\LogFiles\VDS
b. Logman start vds -o %systemroot%\system32\LogFiles\VDS\VdsTrace.etl -ets -p
{012F855E-CC34-4da0-895F-07AF2826C03E} 0xffff 0xff

2. Reproduce the problem.

3. After repro, go back to the command prompt from step 1 and run the following
command to stop the VDS trace:
a. Logman stop vds -etsTrace file Vds

Trace.etl can be found under %systemroot%\system32\LogFiles\VDS\ . Use TraceView.exe

to browse the file or send the VdsTrace.etl file to Microsoft customer support. Customers
must obtain the corresponding operating system symbol files from Microsoft public
symbol servers in order to read the VdsTrace.etl file. More information about
TraceView.exe, click on the following article:

TraceView
Feedback
Was this page helpful?  Yes  No

Provide product feedback

ReFS volume using DPM becomes
unresponsive on Windows Server 2016
Article • 12/26/2023

This article helps to resolve an issue in which DPM or ReFS volume becomes
unresponsive on Windows Server 2016.

Applies to: Windows Server 2016

Original KB number: 4035951

Symptom
You notice a Resilient File System (ReFS) volume that uses Data Protection Management
(DPM) become unresponsive or freeze when you perform backups, specifically when
DPM issues large block-clone operations.

Cause
DPM uses loopback-mounted-VHDs. These appear like normal disks to the OS.
Therefore, these disks are displayed in Windows Explorer, Diskmgt, and other GUI tools.
These tools periodically poll the disks to make sure that they are functioning correctly.
This causes IOs to be sent down the loopback stack to the ReFS volume. If the ReFS
volume is busy, these IOs will have to wait. Therefore, when ReFS performs a long-
duration operation, such as flushing or a large block-clone call, these IOs will have to
wait longer. When these IOs are stuck, the UI of Explorer or Diskmgt won't be refreshed.
As a result, it appears like the disks are hung or dismounted.

Additionally, the loopback mount miniport driver (vhdmp) starts generating warning
events if any IOs don't complete within 30 seconds.

７ Note

No IO or file-system-operation fails during this process. All operations will succeed,

and they will just take longer. Also, no volume will be dismounted. This issue is only
a file-system-operation latency issue, which causes the UI to be stuck and port
drivers to log errors.

Resolution
This issue is resolved in the July 18, 2017 cumulative update . The fix contains:

Three tunable registry parameters

A policy change that avoids making unnecessary volume flushes, which prevents
ReFS from adding heavy latency to ongoing ReFS IOs.

More Information

How to set the tunable parameters

） Important

Before you follow these steps, make sure that you have read and implemented the
three registry parameters as described in KB article 4016173 . If these don't
adequately address any issues that you encounter,do not disable these registry
parameters. These parameters and the ones described in this section do not
overlap functionally, so they can be used together.

This update describes additional registry parameters that help address the latency issues
described in the "Symptoms" section. These parameters can be used in any
combination.

２ Warning

Serious problems might occur if you change the registry incorrectly by using
Registry Editor or by using another method. These problems might require you to
reinstall the operating system. Microsoft cannot guarantee that these problems can
be resolved. Change the registry at your own risk.

） Important

A restart is required for these parameter changes to take effect.

These parameters must be set consistently on every node of a failover cluster.

Tunable parameters

Option 1
This option disables cached pins, which were a major cause of the large active working
set.

Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Value Name: RefsDisableCachedPins

Set RefsDisableCachedPins = 1
Value Type: REG_DWORD

Option 2

This option adds a heuristic to ReFS checkpointing logic, which causes ReFS to
checkpoint when the delete queue reach a certain size. IOs are stuck on ReFS because
the checkpoint logic would get stuck processing a large delete queue.

Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Value Name: RefsProcessedDeleteQueueEntryCountThreshold

Set RefsProcessedDeleteQueueEntryCountThreshold = 2048
Value Type: REG_DWORD

７ Note

Setting RefsProcessedDeleteQueueEntryThreshold to lower values causes ReFS to

checkpoint more frequently. Set the value to 2048, then reduce the value to 1024,
then 512.

Option 3
Large duplicate extents calls introduce latency into the system, as other operations will
have to wait until these long-running operations are complete. This option reduces the
size of the duplicate extents call.

７ Note

DPM will set this registry key change as the default value as part of UR4, which will
release within August 2017.

Specify the indicated values in the following subkey:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection
Manager\Configuration\DiskStorage

Value Name: DuplicateExtentBatchSizeinMB

Set DuplicateExtentBatchSizeinMB = 100. (Default is 2000 [2GB]. Any value from 1 -
4095 is accepted).
Value Type: REG_DWORD

Option 4
This option extends the TimeOutValue.

Specify the indicated values in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk

Value Name: TimeOutValue

Set TimeOutValue (in seconds) = 0x78
Value Type: REG_DWORD

７ Note

The default value for TimeOutValue is 0x41 (65 decimal). 0x78 translates to 120
decimal.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Restore the system or boot drive letter
in Windows
Article • 12/26/2023

This article describes how to change the system or boot drive letter in Windows.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 223188

Summary

２ Warning

Don't use the procedure that's described in this article to change a drive on a
computer where the drive letter hasn't changed. If you do so, you may not be able
to start your operating system. Follow the procedure that's described in this article
only to recover from a drive letter change, not to change an existing computer
drive to something else. Back up your registry keys before you make this change.

This article describes how to change the system or boot drive letter. Usually it isn't
recommended, especially if the drive letter is the same as when Windows was installed.
The only time that you may want to do so is when the drive letters get changed without
any user intervention. It may happen when you break a mirror volume or there's a drive
configuration change. This situation should be a rare occurrence, and you should
change the drive letters back to match the initial installation.

To change or swap drive letters on volumes that can't otherwise be changed using the
Disk Management snap-in, use the following steps.

７ Note

In these steps, drive D refers to the (wrong) drive letter assigned to a volume, and
drive C refers to the (new) drive letter you want to change to, or to assign to the
volume.

This procedure swaps drive letters for drives C and D. If you don't need to swap drive
letters, name the \DosDevice\letter: value to any new drive letter not in use.
Change the system or boot drive letter

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

1. Make a full system backup of the computer and system state.

2. Sign in as an Administrator.

3. Start Regedt32.exe.

4. Locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

5. Select MountedDevices.

6. On the Security menu, select Permissions.

7. Verify that Administrators have full control. Change it back when you are finished
with these steps.

8. Quit Regedt32.exe, and then start Regedit.exe.

9. Locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

10. Find the drive letter you want to change to (new). Look for \DosDevices\C: .

11. Right-click \DosDevices\C: , and then select Rename.

７ Note

You must use Regedit instead of Regedt32 to rename this registry key.

12. Rename it to an unused drive letter \DosDevices\Z: .

 It frees up drive letter C.

13. Find the drive letter you want changed. Look for \DosDevices\D: .

14. Right-click \DosDevices\D: , and then select Rename.

15. Rename it to the appropriate (new) drive letter \DosDevices\C: .

16. Select the value for \DosDevices\Z: , select Rename, and then name it back to
\DosDevices\D: .

17. Quit Regedit, and then start Regedt32.

18. Change the permissions back to the previous setting for Administrators. It should
probably be Read Only.

19. Restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Simple volumes may become
inaccessible if a power loss occurs
shortly after creation
Article • 12/26/2023

This article provides a resolution for the issue that simple volumes may become
inaccessible if a power loss occurs shortly after creation.

Applies to: Windows 7 Service Pack 1

Original KB number: 2001877

Symptoms
Consider the following scenario. In Windows 7, you create a new simple volume in Disk
Management or DiskPart.exe on a non-removable disk. If your Windows 7 system
experiences a sudden power loss within a few minutes of volume creation, you may
notice the volume you created before the power loss is inaccessible and is not assigned
a drive letter when you power the system back on.

Additionally, in Disk Management the volume may not have a status (for example,
"Healthy") or a file system type listed. If you try to modify the volume in Disk
Management, you may receive the following error message:

The operation failed to complete because the Disk Management console view is not
up-to-date. Refresh the view by using the refresh task. If the problem persists close
the Disk Management Console, then restart Disk Management or restart the
computer.

Cause
This issue occurs because the configuration information for the new volume was not
written to disk by the time the power loss occurred.

Resolution
If you are experiencing the issue described in the "Symptoms" section, reinstalling the
volume will resolve the issue. Follow these steps to reinstall the volume.
 1. Open Device Manager. You can access Device Manager by typing "Device
Manager" or "devmgmt.msc" in the Start Search box.

2. Once Device Manager is open, click on "Storage Volumes" to expand the Storage
Volumes portion of the device tree.

3. Under Storage Volumes, you should notice a volume listed as "Unknown device."
Right click on this device and choose "Uninstall." When asked to confirm, choose
OK.

4. Restart the system if you are prompted to do so. The volume should be accessible
once the system finishes restarting. If you are not prompted to restart the system,
right click in Device Manager and choose "Scan for hardware changes." Once the
scan is complete and installation of the volume completes, you will be able to
access the volume.

７ Note

If the power loss occurs within a few seconds of volume creation, in rare
circumstances you may be prompted to format the volume after you follow
the above steps. If this occurs, the file system configuration was not written by
the time the power loss occurred. You may need to reformat or recreate the
volume.

If the problem is fixed, you are finished with this section. If the problem is not fixed, you
can contact support .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Disk Management
Article • 12/26/2023

This article lists some common issues you might see when using Disk Management and
it provides basic troubleshooting steps to try.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 11, Windows 10

 Tip

If you get an error or something doesn't work when following these steps, there's
more help available. This article lists just the first few things to try. There's much
more information on the Microsoft community site in the Files, folders, and
storage section. That section lists the wide variety of hardware and software
configurations you might be dealing with. If you still need help, post a question
there, Contact Microsoft Support , or contact the manufacturer of your hardware.

Open Disk Management

Open Disk Management with the following steps.

1. In the search box on the taskbar, enter Computer Management, select and hold (or
right-click) Computer Management, and then choose Run as administrator.
2. After Computer Management opens, go to Storage > Disk Management.

Disks that are missing or not initialized

Cause: If you don't see the disk in File Explorer and it's listed in Disk Management as
Not Initialized, the disk might not have a valid disk signature. It's either because the
disk was never initialized and formatted, or the drive formatting has become corrupted
somehow. It's also possible that the disk is having hardware problems or other issues as
described further on in this article.

Solution:

If the drive is new and just needs to be initialized, the solution is to initialize the disk. For
more information, see Initialize new disks. But there's a good chance you've already
tried this approach, and it didn't work. Or maybe you have a disk full of important files
that you don't want the initializing process to erase.

There are many reasons a disk or memory card might be missing or fail to initialize, but
the most common reason is that the disk is failing. There's only so much you can do to
fix a failing disk. The following are some steps to try to get it working again. If the disk
works after you've completed one of these steps, don't bother with the remaining ones.
At this point, maybe update your backups.

1. Look at the disk in Disk Management. If it displays Offline as shown below, right-
click on the Offline disk and select Online.

2. If the disk appears in Disk Management as Online, and has a primary partition
that's listed as Healthy, as shown here, that's a good sign.

If a partition has a file system, but no drive letter (for example, E:), see Change
a drive letter to manually add a drive letter.
If a partition doesn't have a file system (it's listed as RAW instead of NTFS,
ReFS, FAT32, or exFAT) and you know that the disk is empty, select and hold
(or right-click) the partition and select Format. Formatting a disk erases all
data on it, so don't do this step if you're trying to recover files from the disk.
Instead, skip ahead to the next step.
 If the partition is listed as Unallocated and you know that the partition is
empty, select and hold (or right-click) the unallocated partition. Then select
New Simple Volume and follow the instructions to create a volume in the
free space. Don't do this step if you're trying to recover files from this
partition. Instead, skip ahead to the next step.

７ Note

Ignore any partitions that are listed as EFI System Partition or Recovery
Partition. These partitions are full of important files that your PC needs to
operate properly. It's best to just leave them alone to do their job of starting
your PC and helping you recover from problems.

3. If you have an external disk that's not showing up, unplug the disk, plug it back in,
and then select Action > Rescan Disks.

4. Shut down your PC, turn off your external hard disk (if it's an external disk with a
power cord), and then turn your PC and the disk back on. To turn off your PC in
Windows 10, select the Start button, select the Power button, and then select Shut
down.

5. Plug the disk into a different USB port that's directly on your PC (not on a hub).
Sometimes, USB disks don't get enough power from some ports, or they have
other issues with particular ports. This issue is especially common with USB hubs,
but sometimes there are differences between ports on a PC. So if you have other
ports, try a few different ones.

6. Try a different cable. Cables fail often, so try using a different cable to plug in the
disk. If you have an internal disk in a desktop PC, you need to shut down your PC
before switching cables. See your PC's manual for details.

7. Check Device Manager for issues. Select and hold (or right-click) the Start button,
then select Device Manager from the context menu. Look for any devices with an
exclamation point beside it or other issues. Select the device and then read its
status.

Here's a list of Error codes in Device Manager , but one approach that sometimes
works is to select and hold (or right-click) the problematic device, select Uninstall
device, and then Action > Scan for hardware changes.
8. Plug the disk into a different PC.

If the disk doesn't work on another PC, it's a good sign that there's something
wrong with the disk, and not your PC. Search for and ask for help at the Microsoft
community site, or contact your disk manufacturer or Microsoft Support .

If you just can't get it working, there are apps that can try to recover data from a
failing disk. Or if the files are vitally important, you can pay a data recovery lab to
try to recover them. If you find something that works for you, let us know in the
comments section.

） Important

Disks fail often, so it's important to regularly back up any files you care about. If
you have a disk that sometimes doesn't appear or gives errors, consider this a
reminder to double-check your backup methods. It's OK if you're a little behind -
we've all been there. The best backup solution is one you use, so we encourage you
to find one that works for you and stick with it.

 Tip

For more information on using apps built into Windows to backup files to an
external drive such as a USB drive, see Backup and restore in Windows . You can
also save files in Microsoft OneDrive, which syncs files from your PC to the cloud. If
your hard disk fails, you'll still be able to get any files you store in OneDrive from
OneDrive.com. For more information, see Sync files with OneDrive in Windows .
A basic or dynamic disk's status is Unreadable
Cause: The basic or dynamic disk isn't accessible and might have experienced hardware
failure, corruption, or I/O errors. The disk's copy of the system's disk configuration
database might be corrupted. An error icon appears on disks that display the
Unreadable status.

Disks might also display the Unreadable status while they're spinning up or when Disk
Management is rescanning all of the disks on the system. In some cases, an unreadable
disk has failed and isn't recoverable. For dynamic disks, the Unreadable status usually
results from corruption or I/O errors on part of the disk, rather than failure of the entire
disk.

Solution: Rescan the disks or restart the computer to see if the disk status changes. Also
try the troubleshooting steps described in Disks that are missing or not initialized, plus
general troubleshooting steps.

A dynamic disk's status is Foreign

Cause: The Foreign status occurs when you move a dynamic disk to the local computer
from another computer PC. A warning icon appears on disks that display the Foreign
status.

In some cases, a disk that was previously connected to the system can display the
Foreign status. Configuration data for dynamic disks is stored on all dynamic disks, so
the information about which disks the system owns is lost when all dynamic disks fail.

Solution: Add the disk to your computer's system configuration so that you can access
data on the disk. To add a disk to your computer's system configuration, import the
foreign disk. Select and hold (or right-click) the disk, and then select Import Foreign
Disks. Any existing volumes on the foreign disk become visible and accessible when you
import the disk.

A dynamic disk's status is Online (Errors)

Cause: The dynamic disk has I/O errors on a region of the disk. A warning icon appears
on the dynamic disk with errors.

Solution: If the I/O errors are temporary, reactivate the disk to return it to Online status.

A dynamic disk's status is Offline or Missing

Cause: An Offline dynamic disk might be corrupted or intermittently unavailable. An
error icon appears on the offline dynamic disk.

If the disk status is Offline and the disk's name changes to Missing, the disk was
recently available on the system but can no longer be located or identified. The missing
disk might be corrupted, powered down, or disconnected.

Solution:

To bring a disk that's offline and missing back online:

1. Repair any disk, controller, or cable problems.

2. Make sure that the physical disk is turned on, plugged in, and attached to the
computer.
3. Next, use the Reactivate Disk command to bring the disk back online.
4. Try the troubleshooting steps described in Disks that are missing or not initialized,
plus general troubleshooting steps.
5. If the disk status remains Offline and the disk name remains Missing, and you
determine that the disk has a problem that can't be repaired, you can remove the
disk from the system by selecting and holding (or right-clicking) the disk and then
clicking Remove Disk. However, before you can remove the disk, you must delete
all volumes (or mirrors) on the disk. You can save any mirrored volumes on the disk
by removing the mirror instead of the entire volume. Deleting a volume destroys
the data in the volume, so you should remove a disk only if you're certain that the
disk is permanently damaged and unusable.

To bring a disk that is Offline and is still named Disk # (not Missing) back online, try one
or more of the following procedures:

1. In Disk Management, select and hold (or right-click) the disk and then select
Reactivate Disk to bring the disk back online. If the disk status remains Offline,
check the cables and disk controller, and make sure that the physical disk is
healthy. Correct any problems and try to reactivate the disk again. If the disk
reactivation succeeds, any volumes on the disk should automatically return to the
Healthy status.
2. In Event Viewer, check the event logs for any disk-related errors such as "No good
config copies." If the event logs contain this error, you can search additional
resources for answers. Or contact Microsoft Product Support .
3. Try moving the disk to another computer. If you can get the disk to go Online on
another computer, the problem is most likely due to the configuration of the
computer on which the disk doesn't go Online.
4. Try moving the disk to another computer that has dynamic disks. Import the disk
on that computer and then move the disk back to the computer on which it
 wouldn't go Online.

A basic or dynamic volume's status is Failed

Cause: The basic or dynamic volume can't be started automatically, the disk is damaged,
or the file system is corrupt. Unless the disk or file system can be repaired, the Failed
status indicates data loss.

Solution:

If the volume is a basic volume with Failed status:

Make sure that the underlying physical disk is turned on, plugged in, and attached
to the computer.
Try the troubleshooting steps described in Disks that are missing or not initialized,
plus general troubleshooting steps.

If the volume is a dynamic volume with Failed status:

Make sure the underlying disks are online. If not, return the disks to the Online
status. If this step succeeds, the volume automatically restarts and returns to the
Healthy status. If the dynamic disk returns to the Online status, but the dynamic
volume doesn't return to the Healthy status, you can reactivate the volume
manually.
If the dynamic volume is a mirrored or RAID-5 volume with old data, bringing the
underlying disk online doesn't automatically restart the volume. If the disks that
contain current data are disconnected, bring those disks online first (to let the data
synchronize). Otherwise, restart the mirrored or RAID-5 volume manually, and then
run the error-checking tool or Chkdsk.exe.
Try the troubleshooting steps described in Disks that are missing or not initialized,
plus general troubleshooting steps.

A basic or dynamic volume's status is Unknown

Cause: The Unknown status occurs when the boot sector for the volume is corrupted
(possibly due to a virus) and you can no longer access data on the volume. The
Unknown status also occurs when you install a new disk but don't successfully complete
the wizard to create a disk signature.

Solution: Initialize the disk. For more information, see Initialize new disks.
A dynamic volume's status is Data Incomplete
Cause: You moved some, but not all of the disks in a multi-disk volume. Data on this
volume gets destroyed unless you move and import the remaining disks that contain
this volume.

Solution:

1. Move all the disks that comprise the multi-disk volume to the computer.
2. Import the disks. For more information on how to move and import disks, see
Move disks to another computer.

If you no longer require the multi-disk volume, you can import the disk and create new
volumes on it. To do so:

1. Select and hold (or right-click) the volume with Failed or Failed Redundancy status
and then select Delete Volume.
2. Select and hold (or right-click) the disk and then select New Volume.

A dynamic volume's status is Healthy (At Risk)

Cause: This status indicates that the dynamic volume is accessible, but I/O errors are
detected on the underlying dynamic disk. If an I/O error is detected on any part of a
dynamic disk, all volumes on the disk display the Healthy (At Risk) status and a warning
icon appears on the volume.

When the volume status is Healthy (At Risk), an underlying disk's status is usually
Online (Errors).

Solution:

1. Return the underlying disk to the Online status. Once you return the disk to Online
status, the volume should return to the Healthy status. If the Healthy (At Risk)
status persists, the disk might be failing.
2. Back up the data and replace the disk as soon as possible.

Can't manage striped volumes using Disk

Management or DiskPart
Cause: Some non-Microsoft disk management products replace Microsoft Logical Disk
Manager (LDM) for advanced disk management, which can disable the LDM.
Solution: If you're using non-Microsoft disk management software that has disabled
LDM, contact the software vendor to get troubleshooting support for the disk
configuration.

Disk Management can't start the Virtual Disk

Service
Cause: You might see this error when a remote computer doesn't support the Virtual
Disk Service (VDS). Or the error might occur if you can't establish a connection to the
remote computer because Windows Firewall is blocking the connection.

Solution:

1. If the remote computer supports VDS, you can configure Windows Firewall to
allow VDS connections. If the remote computer doesn't support VDS, you can use
Remote Desktop Connection to connect to it, and then run Disk Management
directly on the remote computer.
2. To manage disks on remote computers that support VDS, configure the Windows
Firewall on both the local computer (on which you're running Disk Management)
and the remote computer.
3. On the local computer, configure Windows Firewall to enable the Remote Volume
Management Exception.

７ Note

The Remote Volume Management Exception includes exceptions for Vds.exe,

Vdsldr.exe, and TCP port 135. Also, work groups don't support remote connections.
Both the local and remote computers must be members of a domain.

Reference
Free up drive space in Windows 10 .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Usability limit for Volume Shadow Copy
Service (VSS)
Article • 12/26/2023

This article provides a workaround for usability limit of Volume Shadow Copy Service
(VSS).

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows 10 - all editions, Windows 7 Service Pack 1
Original KB number: 2967756

Symptoms
You may receive an error message or notice a failure if you try to perform one of the
following operations on Windows client or Windows Server operating systems:

You enable the Volume Shadow Copy Service (VSS) on a volume that is larger than
64 terabytes (TB).
You create writable snapshots or snapshots that are larger than 64 TB.
You enable VSS for a shared folder on a volume that is larger than 64 TB.
You run a backup operation on a volume that is larger than 64 TB that has a
shadow copy enabled.
You run chkdsk.exe on a volume that is larger than 64 TB.

The error message may include:

STOP: 0x0000007E

Failed to create a shadow copy of volume < Drive_letter >.

Error 0x80042306: The shadow copy provider had an error. Check the System
and Application event logs for more information.

Event ID: 12289. Error: 0x80070057. The parameter is incorrect.

Cause
This issue occurs because Microsoft does not support VSS on volumes larger than 64 TB.
Also, writable snapshots or snapshots larger than 64 TB are not supported.
Workaround
To work around this issue, do not perform any of the operations that are described in
the "Symptoms" section on a volume that is larger than 64 TB.

More information
For more information about VSS, go to the following Microsoft websites:
Volume Shadow Copy Service

How Volume Shadow Copy Service works

Scalability factors for shadow copies

Best practices for shadow copies of shared folders

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use the Disk Management Snap-
in to manage Basic and Dynamic Disks
Article • 12/26/2023

This article describes how to use the Disk Management Snap-in to manage Basic and
Dynamic Disks.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 323442

Summary
You can use the Windows Server 2003 Disk Management snap-in tool to manage your
hard disks and the volumes or partitions that they contain. With Disk Management, you
can create and delete partitions; format volumes with the FAT, FAT32, or NTFS file
systems; change basic disks to dynamic disks, and change dynamic disks back to basic
disks; and create fault-tolerant disk systems. You can perform most disk-related tasks
without having to restart your computer because most configuration changes take
effect immediately. This article describes some of the more common disk storage
management tasks that you can perform by using Disk Management.

Start Disk Management

７ Note

You must be logged on as Administrator or a member of the Administrators group

to use Disk Management.

1. Click Start, point to Administrative Tools, and then click Computer Management.

2. In the console tree, click Disk Management.

The Disk Management window that appears displays your disks and volumes in a
graphical view or list view.

To customize whether you view your disks and volumes in the upper or lower pane
of the window, point to Top or Bottom on the View menu, and then click the view
that you want.
 ７ Note

Before a new, unpartitioned disk can be used in Windows (partitioned or

upgraded to Dynamic Disk), it must contain a disk signature. The first time
that you run the Disk Management snap-in after a new hard disk is installed,
the Disk Signature and Upgrade Disk Wizard starts. If you cancel the wizard,
you may find that when you try to create a partition on the new hard disk, the
Create Partition option is unavailable (appears dimmed).

How to Manage Basic Disks

Basic disk storage supports partition-oriented disks. A basic disk is a physical disk that
contains basic volumes (primary partitions, extended partitions, or logical drives). On
master boot record (MBR) disks, you can create up to four primary partitions on a basic
disk, or up to three primary partitions and one extended partition. You can also use free
space on an extended partition to create logical drives. On GUID partition table (GPT)
disks, you can create up to 128 primary partitions. Because you are not limited to four
partitions on GPT disks, you do not have to create extended partitions on logical drives.

Use basic disks, instead of dynamic disks, on computers that run Microsoft Windows XP
Professional or a member of Windows Server 2003 that are configured to dual-boot or
multi-boot with Microsoft Windows XP Home Edition, Microsoft Windows NT 4.0,
Microsoft Windows Millennium Edition (Me), Microsoft Windows 98 or earlier, or
Microsoft MS-DOS. These operating systems cannot access data that is stored on
dynamic disks.

７ Note

Windows Server 2003 operating systems and Windows XP Professional do not

support multidisk basic volumes (such as spanned, mirrored, stripe sets, or stripe
sets with parity) that were created by using Windows NT 4.0 or earlier.

Create a New Partition or Logical Drive

1. In the Disk Management window, choose one to create:

To create a new partition, right-click unallocated space on the basic disk

where you want to create the partition, and then click New Partition.

-or-
 To create a new logical drive, right-click free space on an extended partition
where you want to create the logical drive, and then click New Logical Drive.

2. On the Welcome to the New Partition Wizard page, click Next.

3. On the Select Partition Type page, click the type of partition that you want to
create, and then click Next.

4. On the Specify Partition Size page, specify the size in megabytes (MB) of the
partition that you want to create, and then click Next.

5. On the Assign Drive Letter or Path page, enter a drive letter or drive path, and
then click Next.

6. On the Format Partition page, specify the formatting options that you want, and
then click Next.

7. On the Completing the New Partition Wizard page, verify that the options that
you selected are correct, and then click Finish.

Disk Management creates the new partition or logical drive and displays it in the
appropriate basic disk in the Disk Management window. If you chose to format the
partition in step 6, the format process now starts.

Format a Partition or Logical Drive

1. In the Disk Management window, right-click the partition or logical drive that you
want to format, and then click Format.
2. Specify the formatting options that you want, and then click OK.
3. Click OK when you are prompted to confirm the formatting changes.

View the Properties of a Partition or Logical Drive

1. In the Disk Management window, right-click the partition or logical drive that you
want to view the properties of, and then click Properties.
2. Click the appropriate tab to view a property.

Delete a Partition or Logical Drive

1. In the Disk Management window, right-click the partition or logical drive that you
want to delete, and then click Delete Partition or Delete Logical Drive.

2. Click Yes when you are prompted to confirm the deletion.

 ７ Note

When you delete a partition or logical drive, you delete all data on that
partition or logical drive and the partition or logical drive itself.
You cannot delete the system partition, the boot partition, or a partition
that contains the active paging (swap) file.
You cannot delete an extended partition unless the extended partition is
empty. You must delete all logical drives before you can delete the
extended partition.

Change a Basic Disk to a Dynamic Disk

Before you change a basic disk to a dynamic disk, note the following instructions:

You must have at least 1 megabyte (MB) of unallocated disk space available on any
master boot record (MBR) basic disk that you want to change to a dynamic disk.
When you change a basic disk to a dynamic disk, you change the existing
partitions on the basic disk to simple volumes on the dynamic disk.
After you change a basic disk to a dynamic disk, you cannot change the dynamic
volumes back to partitions. Delete all dynamic volumes on the disk first, and then
change the dynamic disk back to a basic disk.
Windows Server 2003 operating systems, Windows XP Professional, and Windows
2000 support dynamic disks. After you change a basic disk to a dynamic disk, you
can only access the disk locally from these operating systems.

To change a basic disk to a dynamic disk:

1. In the graphical view of the Disk Management window, right-click the basic disk
that you want to change, and then click Convert to Dynamic Disk.

７ Note

To right-click the basic disk, you must right-click the gray area that contains
the disk title at the left of the Disk Management details pane (for example,
Disk 0).

2. Click to select the check box next to the disk that you want to change, and then
click OK.
 3. If you want to view the list of volumes in the disk, click Details in the Disks to
Convert dialog box.

4. Click Convert.

5. Click Yes when you are prompted to confirm the conversion, and then click OK.

How to Manage Dynamic Disks

Dynamic disk storage supports volume-oriented disks. A dynamic disk is a physical disk
that contains dynamic volumes. With dynamic disks, you can create simple volumes,
volumes that span multiple disks (spanned and striped volumes), and fault-tolerant
volumes (mirrored and RAID-5 volumes). Dynamic disks can contain an unlimited
number of volumes.

Local access to dynamic disks (and the data that they contain) is limited to computers
that run Windows Server 2003 operating systems, Windows XP Professional, or Windows
2000. You cannot access or create dynamic volumes on computers that are configured
to dual-boot or multi-boot a Windows Server 2003, Windows XP Professional, or
Windows 2000 and one or more of Windows XP Home Edition, Windows NT 4.0 and
earlier, Windows Millennium Edition, Windows 98 Second Edition and earlier, or MS-
DOS.

You create dynamic disks when you use the Convert to Dynamic Disk command in Disk
Management to change a basic disk.

Create a Simple Volume or Spanned Volume

1. In the Disk Management window, choose one to create:

To create a simple volume, right-click unallocated space on the dynamic disk

where you want to create the simple volume, and then click New Volume.

-or-

To create a spanned volume, right-click unallocated space on the dynamic

disk where you want to create the spanned volume, and then click New
Volume.

2. On the Welcome to the New Volume Wizard page, click Next.

3. On the Select Volume Type page, click either Simple volume or Spanned volume,
and then click Next.
 4. On the Select Disks page, select one below:

If you are creating a simple volume, verify that the disk that you want to
create a simple volume on is listed in the Selected dynamic disks box.

-or-

If you are creating a spanned volume, click to select the disks that you want
under All available dynamic disks, and then click Add.

Verify that the disks that you want to create a spanned volume on are listed
in the Selected dynamic disks box.

5. In the Size box, specify the size (in MB) that you want for the volume, and then
click Next.

6. On the Assign Drive Letter or Path page, enter a drive letter or drive path, and
then click Next.

7. On the Format Volume page, specify the formatting options that you want, and
then click Next.

8. On the Completing the New Volume Wizard page, make sure that the options
that you selected are correct, and then click Finish.

Extend a Simple Volume or Spanned Volume

If you want to increase the size of a simple or spanned volume after you create it, you
can extend it by adding unallocated free space on the dynamic disk. To extend a simple
or spanned volume:

1. In the Disk Management window, right-click the simple or spanned volume that
you want to extend, and then click Extend Volume.

2. On the Welcome to the Extend Volume Wizard page, click Next.

3. On the Select Disks page, click to select the disk or disks that you want to extend
the volume on, and then click Add.

4. Verify that the disks that you want to extend the volume on are listed in the
Selected dynamic disks box.

5. In the Size box, specify how much unallocated disk space (in MB) that you want to
add, and then Next.
 6. On the Completing the Extend Volume Wizard page, make sure that the options
that you selected are correct, and then click Finish.

７ Note

You can only extend NTFS volumes or volumes that do not yet contain a
file system.
If you upgraded from Windows 2000 to Windows Server 2003 (or to
Windows XP Professional), you cannot extend a simple or spanned
volume that you originally created as a basic volume and then changed
to a dynamic volume in Windows 2000.
You cannot extend the system or boot volume.

Create a RAID-5 Volume

A RAID-5 volume is a fault-tolerant volume in which data and parity is striped across
three or more physical disks. If part of one physical disk fails, you can recover the data
on the failed disk by using the data and parity information on the functioning disks.

Format a Dynamic Volume

1. In the Disk Management window, right-click the dynamic volume that you want to
format, and then click Format.
2. Specify the formatting options that you want, and then click OK.
3. Click OK when you are prompted to confirm the formatting changes.

View the Properties of a Dynamic Volume

1. In the Disk Management window, right-click the dynamic volume that you want to
view the properties of, and then click Properties.
2. Click the appropriate tab to view a property.

Delete a Dynamic Volume

1. In the Disk Management window, right-click the dynamic volume that you want to
delete, and then click Delete Volume.
2. Click Yes when you are prompted to confirm the deletion.
 ７ Note

When you delete a volume, you delete all data on the volume and the
volume itself.
You cannot delete the system volume, the boot volume, or any volume
that contains the active paging (swap) file.

Change a Dynamic Disk Back to a Basic Disk

Before you can change a dynamic disk back to a basic disk, you must delete all volumes
from the dynamic disk.

To change a dynamic disk back to a basic disk, right-click the dynamic disk that you
want to change back to a basic disk in the Disk Management window, and then click
Convert to Basic Disk.

７ Note

To right-click the disk, right-click the gray area that contains the disk title at the left
of the Disk Management details pane (for example, Disk 0 ).

Troubleshooting
When a disk or volume fails, Disk Management displays status descriptions of disks and
volumes in the Disk Management window. These descriptions, which are shown in the
following list, inform you of the current status of the disk or volume.

Online: It is the normal disk status when the disk is accessible and functioning
correctly.

Healthy: It is the normal volume status when the volume is accessible and
functioning correctly.

Online (Errors) (displayed with dynamic disks only): I/O errors may have been
detected on the dynamic disk.

To resolve this issue, right-click the disk, and then click Reactivate Disk to return
the disk to Online status.

Offline or Missing (displayed with dynamic disks only): The disk may be
inaccessible. This issue may occur if the disk is corrupted or made temporarily
 unavailable.

To resolve this issue, repair any disk, controller, or connection problems, verify that
the physical disk is turned on and correctly attached to the computer, right-click
the disk, and then click Reactivate Disk to return the disk to Online status.

For a complete list of disk and volume status descriptions, see Disk Management Help.
(In the Disk Management snap-in, click the Action menu, and then click Help. )

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows support for hard disks that are
larger than 2 TB
Article • 12/26/2023

This article discusses the manner in which Windows supports hard disks that have a
storage capacity of more than 2 TB and explains how to initialize and partition disks to
maximize space usage.

Applies to: Windows Server 2022 Standard and Datacenter, Windows Server 2019,
Windows Server 2016, Windows Server 2012 R2
Original KB number: 2581408

Summary
In order for an operating system to fully support storage devices that have capacities
that exceed 2 terabytes (2 TB, or 2 trillion bytes), the device must be initialized by using
the GUID Partition Table (GPT) partitioning scheme. This scheme supports addressing of
the full range of storage capacity. If the user intends to start the computer from one of
these large disks, the system's base firmware interface must use the Unified Extensible
Firmware Interface (UEFI) and not BIOS.

This article outlines Microsoft support across all Windows versions since Windows XP. It
also describes the requirements to address the full storage capability of these devices.

７ Note

This article refers to disk capacity in powers of two instead of powers of 10,
which is the more common designation on storage device capacity labels.
Therefore, references to 2 TB actually refer to a product that is labeled as
having 2.2 TB of capacity.
The operating system-specific behavior that is noted in this article also applies
to the server variants of that system. Therefore, a reference to Windows 7
includes Windows Server 2008 R2, Windows Vista includes Windows Server
2008, and Windows XP includes Windows Server 2003 and Windows Server
2003 R2.

More information
The management of modern storage devices is addressed by using a scheme called
Logical Block Addressing (LBA). It's the arrangement of the logical sectors that
constitute the media. LBA0 represents the first logical sector of the device, and the last
LBA designation represents the last logical sector of the device, one label per sector. To
determine the capacity of the storage device, you multiply the number of logical sectors
within the device by the size of each logical sector. The current size standard is 512
bytes. For example, to achieve a device that has a capacity of 2 TB, you must have
3,906,250,000 512-byte sectors. However, a computer system requires 32 bits (1 s and 0
s) of information to represent this large number. Therefore, any storage capacity that is
greater than what can be represented by using 32 bits would require an additional bit.
That is, 33 bits.

The problem in this computation is that the partitioning scheme that is used by most
modern Windows-based computers is MBR (master boot record). This scheme sets a
limit of 32 for the number of bits that are available to represent the number of logical
sectors.

The 2-TB barrier is the result of this 32-bit limitation. Because the maximum number that
can be represented by using 32 bits is 4,294,967,295, it translates to 2.199 TB of capacity
by using 512-byte sectors (approximately 2.2 TB). Therefore, a capacity beyond 2.2 TB
isn't addressable by using the MBR partitioning scheme.

To make more bits available for addressing, the storage device must be initialized by
using GPT. This partitioning scheme lets up to 64 bits of information be used within
logical sectors. It translates to a theoretical limitation of 9.4 ZB (9.4 zettabytes, or 9.4
billion terabytes). However, the issue that affects GPT is that most currently available
systems are based on the aging BIOS platform. BIOS supports only MBR-initialized disks
to start the computer. To restart from a device that is initialized by using GPT, your
system must be UEFI-capable. By default, many current systems can support UEFI.
Microsoft expects that most future systems will have this support. Customers should
consult with their system vendor to determine the ability of their systems to support
UEFI and disks that have storage capacities that are greater than 2 TB.

Overall requirements for a non-bootable data

volume
For a system to be able to address the maximum capacity of a device that has a storage
capacity of more than 2 TB, the following prerequisites apply:

The disk must be initialized by using GPT.

 The Windows version must be one of the following (32-bit or 64-bit, unless
otherwise noted, but including all SKU editions):
Windows Server 2008 R2 (only 64-bit version available)
Windows Server 2008
Windows 7
Windows Vista

The latest storage drivers from your storage controller manufacturer must be
installed. For example, if your system uses an Intel storage controller that is set to
"RAID" mode, make sure that you have the latest applicable drivers from the Intel
support site .

Overall, you should contact your system vendor to determine whether the system
supports device sizes of more than 2 TB.

Overall requirements for a bootable system

volume
Assume that you want to meet the following conditions:

Have a storage device on which you can install Windows.

Make the storage device bootable.
Enable the operating system to address a maximum storage capacity for that
device of greater than 2 TB.

To meet these conditions, the following prerequisites apply:

The disk must be initialized by using GPT.

The system firmware must use UEFI.

The Windows version must be one of the following (64-bit only, but including all
SKU editions):
Windows Server 2008 R2
Windows Server 2008
Windows 7
Windows Vista

The latest storage drivers from your storage controller manufacturer must be
installed. For example, if your system uses an Intel storage controller set to RAID
mode, make sure that you have the latest applicable drivers from the Intel support
site .
 ７ Note

Windows does not support starting GPT-initialized volumes by using UEFI systems
on 32-bit versions of Windows. Also, legacy BIOS systems do not support starting
GPT-partitioned volumes. Consult your system vendor to determine whether the
system supports both UEFI and the startup of devices that have storage capacities
of greater than 2 TB.

Support matrix
The following tables list Microsoft support for the various concepts that are discussed in
this article. This information provides an overall support statement about disks that have
a storage capacity of greater than 2 TB.

Table 1: Windows support for partitioning schemes as

data volumes

ﾉ Expand table

System MBR Hybrid-MBR GPT

Windows 7 Supported Not Supported Supported

Windows Vista Supported Not Supported Supported

Windows XP Supported Not Supported Not Supported

Hybrid-MBR is an alternative style of partitioning that isn't supported by any version of

Windows.

Table 2: Windows support for system firmware

ﾉ Expand table

System BIOS UEFI

Windows 7 Supported Supported

Windows Vista Supported Supported

Windows XP Supported Not Supported

Table 3: Windows support for combinations of boot
firmware and partitioning schemes for the boot volume

ﾉ Expand table

System BIOS + UEFI + GPT BIOS + GPT UEFI + MBR

MBR

Windows 7 Supported Supported; Boot volume not Boot volume not

requires a 64-bit version supported supported
of Windows

Windows Supported Supported; Boot volume not Boot volume not

Vista requires a 64-bit version supported supported
of Windows

Windows Supported Not supported Boot volume not Boot volume not
XP supported supported

Table 4: Windows support for large-capacity disks as non-

booting data volumes

ﾉ Expand table

System >2-TB single disk - MBR >2-TB single disk - >2-TB single disk
Hybrid-MBR - GPT

Windows 7 Supports up to 2 TB of Not Supported Supports full

addressable capacity** capacity

Windows Supports up to 2 TB of Not Supported Supports full

Vista addressable capacity** capacity

Windows XP Supports up to 2 TB of Not Supported Not Supported

addressable capacity**

Capacity beyond 2 TB cannot be addressed by Windows if the disk is initialized by using

the MBR partitioning scheme. For example, for a 3-TB single disk that is initialized by
using MBR, Windows can create partitions up to the first 2 TB. However, the remaining
capacity cannot be addressed and, therefore, cannot be used.

Initialize a data disk by using GPT

The following steps show how to initialize a fresh disk by using the GPT partitioning
scheme to help ensure that Windows can address the maximum available storage
capacity. Make sure that you back up any important data before you try these steps.

1. Click Start, type diskmgmt.msc in the Start search box, right-click diskmgmt.msc,
and then click Run as Administrator. If it's necessary, enter the credentials for a
user account that has Administrator privileges.

７ Note

When a non-initialized disk is detected by Windows, the following window

opens to prompt you to initialize the disk.

2. In the Initialize Disk dialog box, click GPT (GUID Partition Table), and then press
OK.

７ Note

If you select this option, this hard disk will not be recognized by Windows
versions earlier than and including Windows XP.

3. Check the Disk Management window to verify that the disk is initialized. If it is, the
status row for that disk at the bottom of the window should indicate that the disk
 is Online.

4. After the disk is initialized, you must create a partition, and then format that
partition by using a file system. It's to be able to store data in that partition, and
assign a name and a drive letter to that partition. To do it, right-click the
unallocated space on the right side of the status row for that disk, and then click
New Simple Volume. Follow the steps in the partition wizard to complete this
process.

Convert an MBR disk to GPT

If you have previously initialized the disk by using the MBR partitioning scheme, follow
these steps to initialize the disk by using the GPT scheme. Make sure that you back up
any important data before you try these steps.

1. Click Start, type diskmgmt.msc in the Start search box, right-click diskmgmt.msc,
and then click Run as Administrator. If it's necessary, enter the credentials for a
user account that has Administrator privileges.

2. In the Disk Management window, examine the disk status rows at the bottom. In
the following example, the user has a 3-TB disk that was previously initialized by
using the MBR partitioning scheme. That device is labeled here as Disk 1.
3. Disk 1 contains two separate unallocated sections. This separation indicates that
the first 2 TB of the disk space can be used. However, the remaining space is non-
addressable because of the 32-bit addressing space limitation of the MBR
partitioning scheme. To enable the system to fully address the total capacity of the
storage device, you must convert the disk to use the GPT partitioning scheme.

4. Right-click the label on the left for the disk that you want to convert, and then click
Convert to GPT Disk.

７ Note

The display should now show that the full amount of available space in
unallocated.
 5. Now that the disk is initialized to access the full storage capacity, you must create
a partition, and then format that partition by using a file system. It's to be able to
store data in that partition, and assign a name and a drive letter to that partition.
To do it, right-click the unallocated space on the right side of the status row for
that disk, and then click New Simple Volume. Follow the steps in the partition
wizard to complete this process.

Known issues or limitations

Because the transition to a single-disk capacity of greater than 2 TB has occurred fairly
recently, Microsoft has investigated how Windows supports these large disks. The
results reveal several issues that apply to all versions of Windows earlier than and
including Windows 7 with Service Pack 1 and Windows Server 2008 R2 with Service Pack
1.

To this point, the following incorrect behavior is known to occur when Windows handles
single-disk storage capacity of greater than 2 TB:

The numeric capacity beyond 2 TB overflows. It results in the system being able to
address only the capacity beyond 2 TB. For example, on a 3-TB disk, the available
capacity may be only 1 TB.
 The numeric capacity beyond 2 TB is truncated. It results in no more than 2 TB of
addressable space. For example, on a 3-TB disk, the available capacity may be only
2 TB.

The storage device isn't detected correctly. In this case, it isn't displayed in either
the Device Manager or Disk Management windows. Many storage controller
manufacturers offer updated drivers that provide support for storage capacities of
more than 2 TB. Contact your storage controller manufacturer or OEM to
determine what downloadable support is available for single-disk capacities that
are greater than 2 TB.

SCSI sense data

When a disk encounters errors that are related to unreadable or unwritable sectors, it
reports those errors and the relevant SCSI sense data to the operating system. SCSI
sense data may contain information about LBA for sectors that were found to be
unreadable or unwritable.

For LBA address space that is greater than 2 TB, the disk requires SCSI sense data in
Descriptor format. This format isn't supported by Windows 7 or Windows Server 2008
R2, which retrieves SCSI sense data in Fixed format. Therefore, the retrieved SCSI sense
data either does not contain information about bad sectors or it contains incorrect
information about bad sectors. Administrators should note this limitation when they
look for bad sector LBA information that's recorded in the Windows event log.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"You don't have permission" error
message when you try to mount an ISO
image
Article • 12/26/2023

This article helps to fix the error "You don't have permission" when you try to mount an
ISO image.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 2993573

Symptoms
When you try to mount an ISO image in Windows Server 2012 R2, Windows Server
2012, Windows 8.1, or Windows 8, you receive the following error message:

Couldn't Mount File

You don't have permission to mount the file.

The message window is shown in the following screenshot.

This problem occurs when you perform either of the following operations:

You double-click an .iso file or you use disk image tools to mount an ISO image
from either a local or network source.
You try to mount an ISO image through the shortcut menu in Windows Explorer.

７ Note

Although you receive the error message, the ISO image is mounted successfully in
most cases.
Other reported symptoms
When you click an .iso file in Windows Explorer to try to mount the ISO image, the
operation fails and you receive the following error message:

Sorry there was a problem mounting the file

You receive the following Windows PowerShell error message:

Error:17098 - The component store has been corrupted

When you run the mountdiskimage -imagepath

c:\images\windows8.1_enterprise.iso command in PowerShell, the operation fails

and you receive the following error message:

mount-diskimage: "The version does not support this version of the file
format".
Hresult 0xc03a0005

Cause
This problem may occur for one or more of the following reasons:

A USB media reader device is attached to the computer.

Removable media is mounted in the computer.
The .iso file that you are trying to mount is a sparse file.

To determine whether a file is a sparse file, use one of the following methods.

Method 1: Check the file properties

1. In the C:\images folder, right-click the Windows8.1_Enterprise.iso file.
2. Click Properties.
3. Click Details.
4. Check the Attributes line for the letter "P" to indicate a sparse file.

Method 2: Use PowerShell

1. Run the following Windows PowerShell command:

PowerShell
 (get-item c:\test\mydisk.iso).attributes

2. Check for the word "SparseFile" in the command output to indicate a sparse file.

Resolution
To resolve this problem, use one of the following methods.

Resolution 1
Copy the ISO file to a new file by saving it to a different folder or giving it a different
name.

This process should remove the sparse attribute and enable the file to be mounted.

Resolution 2
If you have a flash media reader or any removable media, try to eject the removable
media. Then, reassign the drive letters in such a manner that you leave a lower drive
letter available to mount the ISO image. The file might not behave correctly if it has an
assigned drive that follows other drives.

For example, consider the following layout.

ﾉ Expand table

Drive Assignment

C Hard disk

D DVD

E USB device

F ISO (auto assigned)

In this layout, the ISO image is auto assigned to drive F when it is mounted. It causes the
error that is mentioned in the "Symptoms" section. However, the drive continues to
function.

After you eject the ISO drive F, reassign the USB drive to drive F. Now when you mount
the ISO image, it will be auto assigned to drive E without generating any errors. The new
layout will be as follows.
 ﾉ Expand table

Drive Assignment

C Hard disk

D DVD

E ISO (auto assigned)

F USB device

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to manually turn disk write caching
on or off
Article • 12/26/2023

This article describes steps to manually turn disk write caching on or off.

Applies to: Windows Server 2012 R2

Original KB number: 324805

Summary
With some third-party programs, disk write caching has to be turned on or off.
Additionally, turning disk write caching on may increase operating system performance;
however, it may also result in the loss of information if a power failure, equipment
failure, or software failure occurs. This article describes how to turn disk write caching on
or off.

Turn disk write caching on or off

1. Right-click My Computer, and then click Properties.
2. Click the Hardware tab, and then click Device Manager.
3. Expand Disk Drives.
4. Right-click the drive on which you want to turn disk write caching on or off, and
then click Properties.
5. Click the Policies tab.
6. Click to select or clear the Enable write caching on the disk check box as
appropriate.
7. Click OK.

For Windows Server 2008

1. Right-click Computer, and then click Properties.
2. Click the Device Manager link under Tasks.
3. Expand Disk Drives.
4. Right-click the drive on which you want to turn disk write caching on or off, and
then click Properties.
5. Click the Policies tab.
 6. Click to select or clear the Enable write caching on the disk check box as
appropriate.
7. Click OK.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Information about Event ID 51
Article • 12/26/2023

Event ID 51 may occur when you write information to the physical disk. This article
describes how to decode the data section of an Event ID 51 event message.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 244780

Summary
When you write information to the physical disk, the following event message may be
logged in the System log:

Output

Event ID: 51
Event Type: Warning
Event Source: Disk
Description: An error was detected on device \Device\Harddisk3\DR3 during a
paging operation.
Data:
0000: 04 00 22 00 01 00 72 00
0008: 00 00 00 00 33 00 04 80
0010: 2d 01 00 00 00 00 00 00
0018: 00 00 00 00 00 00 00 00
0020: 00 52 ea 04 15 00 00 00
0028: 01 00 00 00 04 00 00 00
0030: 03 00 00 00 2a 00 00 00
0038: 02 84 00 00 00 29 06 00
0040: 2a 60 0a 82 75 29 00 00
0048: 80 00

７ Note

The device in the description and the specific hexadecimal data may vary.

More information
If a generic error occurs when your computer pages information to or from the disk, an
Event ID 51 event message is logged. In a paging operation, the operating system either
swaps a page of memory from memory to disk, or retrieves a page of memory from disk
to memory. It's part of the memory management of Windows.
However, the computer may log this event message when it loads images from a
storage device, reads, and writes to locally mapped files or to any file (as long as it's
buffered I/O). The computer doesn't log this event message when it performs
nonbuffered I/O. You can troubleshoot an Event ID 51 event message exactly like you
troubleshoot Event ID 9 or Event ID 11 event messages.

Under certain circumstances, the system logs the following Event ID 51 event message:

Output

An error was detected on device \Device\DeviceName during a paging operation

In this case, no harmful effects are experienced. For example, Event ID 51 is logged
when blank media such as CDR, CDRW, DVDR, is inserted into a writable drive while a
USB device is plugged in. The system logs the event even though the disc is writable,
and the USB device is still usable. In these particular cases, you can safely ignore the log
entries. No action is required.

７ Note

On Windows XP and Windows Server 2003, the DeviceName may be truncated

because of the size limitation of the event log entry. As a result, the displayed hard
disk number, or the device object name itself may be incorrect. Because a large
amount of information is stored in the data section, the space that's available for
the DeviceName is reduced. In this case, you can find the appropriate device by
looking at the destination disk data that's stored in the data section. For more
information, see Decode the data section of an Event ID 51 event message.

On Windows Vista and later versions, the event log entry size has been increased, and
DeviceName isn't truncated.

You can use the binary data associated with any DISK error (Event ID 7, 9, 11, 51, and
other Event IDs) to help you identify the problem by decoding the data section.

An Event ID 51 has an extra Command Descriptor Block (CDB) box. Consider the
following information when you review the data section of an Event ID 51 event
message.

Decode the data section of an Event ID 51

event message
When you decode the data section of the example in the Summary section, you can see
that an attempt to perform a write operation to LUN 3 starting at sector 0x2975820a for
0x0080 sectors fails because the bus was reset but the request will be retried. Later, this
article lists the specific steps to decode this example.

The following tables describe what each offset represents:

ﾉ Expand table

Offset Length Values

0x00 1 Type of operation: 0x03 = Read, 0x04 = Write, 0x0F = IOCTL

0x01 1 Number of retries remaining

0x02 2 Dump Data Size 0x0068

0x04 2 Number of Strings 0x0001

0x06 2 Offset to the device name

0x08 2 Unused

0x0a 2 Padding bytes

0x0c 4 NTSTATUS Error Code

0x10 4 Unique Error Value

0x14 4 NTSTATUS Final Status 0x00000000 = the request will be retried

0x18 4 Sequence Number - Unused

0x1c 4 Io Control Code (doesn't apply to this event)

0x20 8 Byte offset to bad sector, if any

0x28 8 Tick count when the error occurred

0x30 4 Port number - Unused

0x34 1 Error Flags

0x35 3 Unused

0x38 88 SCSI request block structure

0x90 18 Sense data structure

Key sections to decode

Here are key sections to decode.

The error code

In the example that is in the Summary section, the error code is listed in the second line.
That line starts with 0008: and includes the last 4 bytes in the line.

0008: 00 00 00 00 33 00 04 80

ErrorCode = 0x80040033

This code is the code for error 51. This code is the same for all Event ID 51 event
messages:

IO_WARNING_PAGING_FAILURE

７ Note

When you interpret the hexadecimal data in the Event ID to the status code,
remember that the values are represented in the little endian format.

The final status code

In the example in the Summary section, the final status code is listed at 0x14 (in the third
line) that starts with 0010: and includes the last four octets in this line.

0010: 2d 01 00 00 00 00 00 00

FinalStatus = 0x00000000

It maps to STATUS_SUCCESS and implies that the request will be retried.

７ Note

When you interpret the hexadecimal data in the Event ID to the status code,
remember that the values are represented in the little endian format.

The destination disk

You can use this data to help determine on what disk the problem occurred:

0028: 01 00 00 00 04 00 00 00

Path ID = 0x0000001, Target ID = 0x0000004

0030: 03 00 00 00 2a 00 00 00

LUN = 0x0000003

It may be easier to identify the volume by using the symbolic link listed to the drive in
the description of the Event ID. For example, \Device\Harddisk3\DR3 .

７ Note

The destination disk information is how it appears to the operating system. Storage
virtualization and multipath I/O software may mask what is presented to the
operating system. This information may not directly correspond to the physical
mappings.

The SCSI Request Block (SRB) parameters

In the example in the Summary section, the ScsiStatus is 0x02 (first byte in line 0038),
and SrbStatus is 0x84 (second byte in line 0038). It provides the following information:

0038: 02 84 00 00 00 29 06 00

ScsiStatus of 0x02:
SCSISTAT_CHECK_CONDITION

SCSI status codes: (from SCSI.H)

C++

0x00 = SCSISTAT_GOOD
0x02 = SCSISTAT_CHECK_CONDITION
0x04 = SCSISTAT_CONDITION_MET
0x08 = SCSISTAT_BUSY
0x10 = SCSISTAT_INTERMEDIATE
0x14 = SCSISTAT_INTERMEDIATE_COND_MET
0x18 = SCSISTAT_RESERVATION_CONFLICT
0x22 = SCSISTAT_COMMAND_TERMINATED
0x28 = SCSISTAT_QUEUE_FULL
SrbStatus of 0x84:
SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_ERROR

C++

0x00 = SRB_STATUS_PENDING
0x01 = SRB_STATUS_SUCCESS
0x02 = SRB_STATUS_ABORTED
0x03 = SRB_STATUS_ABORT_FAILED
0x04 = SRB_STATUS_ERROR
0x05 = SRB_STATUS_BUSY
0x06 = SRB_STATUS_INVALID_REQUEST
0x07 = SRB_STATUS_INVALID_PATH_ID
0x08 = SRB_STATUS_NO_DEVICE
0x09 = SRB_STATUS_TIMEOUT
0x0A = SRB_STATUS_SELECTION_TIMEOUT
0x0B = SRB_STATUS_COMMAND_TIMEOUT
0x0D = SRB_STATUS_MESSAGE_REJECTED
0x0E = SRB_STATUS_BUS_RESET
0x0F = SRB_STATUS_PARITY_ERROR
0x10 = SRB_STATUS_REQUEST_SENSE_FAILED
0x11 = SRB_STATUS_NO_HBA
0x12 = SRB_STATUS_DATA_OVERRUN
0x13 = SRB_STATUS_UNEXPECTED_BUS_FREE
0x14 = SRB_STATUS_PHASE_SEQUENCE_FAILURE
0x15 = SRB_STATUS_BAD_SRB_BLOCK_LENGTH
0x16 = SRB_STATUS_REQUEST_FLUSHED
0x20 = SRB_STATUS_INVALID_LUN
0x21 = SRB_STATUS_INVALID_TARGET_ID
0x22 = SRB_STATUS_BAD_FUNCTION
0x23 = SRB_STATUS_ERROR_RECOVERY
0x24 = SRB_STATUS_NOT_POWERED
0x30 = SRB_STATUS_INTERNAL_ERROR
(used by the port driver to indicate that a non-scsi-related error occurred)
0x38 - 0x3f = Srb status values reserved for internal port driver use.

SRB status masks:

C++

0x80 = SRB_STATUS_AUTOSENSE_VALID
0x40 = SRB_STATUS_QUEUE_FROZEN

You must break down SRB status masks because they are a substatus. They are
combined with the SRB status codes.

In the earlier 0x84 example, 0x8_ is a status mask. Therefore,

SRB_STATUS_AUTOSENSE_VALID and 0x04 is the SRB status code. It means
SRB_STATUS_ERROR .
The sense code
If the SRB status is that the autosense is valid, the sense codes provide more
information. In the example in the Summary section, the sense code is 0x06 (seventh
byte in line 0038), and the additional sense code is 0x29 (sixth octet in line 0038). It
provides the following information:

0038: 02 84 00 00 00 29 06 00

The sense key of 0x06:

The byte at offset 003e is the sense key. It maps to:

C++

0x06 = SCSI_SENSE_UNIT_ATTENTION

Sense codes: (from SCSI.H)

C++

0x00 = SCSI_SENSE_NO_SENSE
0x01 = SCSI_SENSE_RECOVERED_ERROR
0x02 = SCSI_SENSE_NOT_READY
0x03 = SCSI_SENSE_MEDIUM_ERROR
0x04 = SCSI_SENSE_HARDWARE_ERROR
0x05 = SCSI_SENSE_ILLEGAL_REQUEST
0x06 = SCSI_SENSE_UNIT_ATTENTION
0x07 = SCSI_SENSE_DATA_PROTECT
0x08 = SCSI_SENSE_BLANK_CHECK
0x09 = SCSI_SENSE_UNIQUE
0x0A = SCSI_SENSE_COPY_ABORTED
0x0B = SCSI_SENSE_ABORTED_COMMAND
0x0C = SCSI_SENSE_EQUAL
0x0D = SCSI_SENSE_VOL_OVERFLOW
0x0E = SCSI_SENSE_MISCOMPARE
0x0F = SCSI_SENSE_RESERVED

Additional sense code (ASC) of 0x29:

The ASC is located in the sixth byte in line 0038 at offset 003d, and has a value of 29. For
the specified sense key, it maps to:

C++

0x29 = SCSI_ADSENSE_BUS_RESET
Additional sense codes: (from SCSI.H)

C++

0x00 = SCSI_ADSENSE_NO_SENSE
0x02 = SCSI_ADSENSE_NO_SEEK_COMPLETE
0x04 = SCSI_ADSENSE_LUN_NOT_READY
0x0C = SCSI_ADSENSE_WRITE_ERROR
0x14 = SCSI_ADSENSE_TRACK_ERROR
0x15 = SCSI_ADSENSE_SEEK_ERROR
0x17 = SCSI_ADSENSE_REC_DATA_NOECC
0x18 = SCSI_ADSENSE_REC_DATA_ECC
0x20 = SCSI_ADSENSE_ILLEGAL_COMMAND
0x21 = SCSI_ADSENSE_ILLEGAL_BLOCK
0x24 = SCSI_ADSENSE_INVALID_CDB
0x25 = SCSI_ADSENSE_INVALID_LUN
0x27 = SCSI_ADSENSE_WRITE_PROTECT
0x28 = SCSI_ADSENSE_MEDIUM_CHANGED
0x29 = SCSI_ADSENSE_BUS_RESET
0x2E = SCSI_ADSENSE_INSUFFICIENT_TIME_FOR_OPERATION
0x30 = SCSI_ADSENSE_INVALID_MEDIA
0x3a = SCSI_ADSENSE_NO_MEDIA_IN_DEVICE
0x3b = SCSI_ADSENSE_POSITION_ERROR
0x5a = SCSI_ADSENSE_OPERATOR_REQUEST
0x5d = SCSI_ADSENSE_FAILURE_PREDICTION_THRESHOLD_EXCEEDED
0x64 = SCSI_ADSENSE_ILLEGAL_MODE_FOR_THIS_TRACK
0x6f = SCSI_ADSENSE_COPY_PROTECTION_FAILURE
0x73 = SCSI_ADSENSE_POWER_CALIBRATION_ERROR
0x80 = SCSI_ADSENSE_VENDOR_UNIQUE
0xA0 = SCSI_ADSENSE_MUSIC_AREA
0xA1 = SCSI_ADSENSE_DATA_AREA
0xA7 = SCSI_ADSENSE_VOLUME_OVERFLOW

Additional sense code qualifier (ASCQ) of 0x00:

The ASCQ is located in the fifth byte in line 0038 at offset 003C, and has a value of 00.
It's 00 in this example, so it doesn't apply for the specified ASC. This list of ASCQ for
each sense code is too large to include in this article. View SCSI.H in the DDK for more
information.

７ Note

All ASC and ASCQ values above 0x80 are vendor specific and are not documented
in the SCSI specification or Microsoft DDK. Refer to the hardware vendor.

The Command Descriptor Block (CDB) parameters

The CDB starts at the line with an offset of 0040:
 0040: 2a 60 0a 82 75 29 00 00
0048: 80 00

The bytes at offset 0x40 represent the CDB code. The bytes from offset 0x43 to 0x46
represent the starting sector, and offset 0x47 to 0x49 represent the number of sectors
involved in the operation.

７ Note

The CDB data section isn't in the little-endian format. So the bytes shouldn't be
flipped. Be careful when you decode this section, because the format is different
from earlier sections.

C++

0x2a = Write request

0x0a827529 = The starting sector
0x0080 = The number of sectors

SCSI CDB codes: (from SCSI.H)

C++

0x00 = SCSIOP_TEST_UNIT_READY
0x01 = SCSIOP_REZERO_UNIT
0x01 = SCSIOP_REWIND
0x02 = SCSIOP_REQUEST_BLOCK_ADDR
0x03 = SCSIOP_REQUEST_SENSE
0x04 = SCSIOP_FORMAT_UNIT
0x05 = SCSIOP_READ_BLOCK_LIMITS
0x07 = SCSIOP_REASSIGN_BLOCKS
0x07 = SCSIOP_INIT_ELEMENT_STATUS
0x08 = SCSIOP_READ6
0x08 = SCSIOP_RECEIVE
0x0A = SCSIOP_WRITE6
0x0A = SCSIOP_PRINT
0x0A = SCSIOP_SEND
0x0B = SCSIOP_SEEK6
0x0B = SCSIOP_TRACK_SELECT
0x0B = SCSIOP_SLEW_PRINT
0x0C = SCSIOP_SEEK_BLOCK
0x0D = SCSIOP_PARTITION
0x0F = SCSIOP_READ_REVERSE
0x10 = SCSIOP_WRITE_FILEMARKS
0x10 = SCSIOP_FLUSH_BUFFER
0x11 = SCSIOP_SPACE
0x12 = SCSIOP_INQUIRY
0x13 = SCSIOP_VERIFY6
0x14 = SCSIOP_RECOVER_BUF_DATA
0x15 = SCSIOP_MODE_SELECT
0x16 = SCSIOP_RESERVE_UNIT
0x17 = SCSIOP_RELEASE_UNIT
0x18 = SCSIOP_COPY
0x19 = SCSIOP_ERASE
0x1A = SCSIOP_MODE_SENSE
0x1B = SCSIOP_START_STOP_UNIT
0x1B = SCSIOP_STOP_PRINT
0x1B = SCSIOP_LOAD_UNLOAD
0x1C = SCSIOP_RECEIVE_DIAGNOSTIC
0x1D = SCSIOP_SEND_DIAGNOSTIC
0x1E = SCSIOP_MEDIUM_REMOVAL
0x23 = SCSIOP_READ_FORMATTED_CAPACITY
0x25 = SCSIOP_READ_CAPACITY
0x28 = SCSIOP_READ
0x2A = SCSIOP_WRITE
0x2B = SCSIOP_SEEK
0x2B = SCSIOP_LOCATE
0x2B = SCSIOP_POSITION_TO_ELEMENT
0x2E = SCSIOP_WRITE_VERIFY
0x2F = SCSIOP_VERIFY
0x30 = SCSIOP_SEARCH_DATA_HIGH
0x31 = SCSIOP_SEARCH_DATA_EQUAL
0x32 = SCSIOP_SEARCH_DATA_LOW
0x33 = SCSIOP_SET_LIMITS
0x34 = SCSIOP_READ_POSITION
0x35 = SCSIOP_SYNCHRONIZE_CACHE
0x39 = SCSIOP_COMPARE
0x3A = SCSIOP_COPY_COMPARE
0x3B = SCSIOP_WRITE_DATA_BUFF
0x3C = SCSIOP_READ_DATA_BUFF
0x40 = SCSIOP_CHANGE_DEFINITION
0x42 = SCSIOP_READ_SUB_CHANNEL
0x43 = SCSIOP_READ_TOC
0x44 = SCSIOP_READ_HEADER
0x45 = SCSIOP_PLAY_AUDIO
0x46 = SCSIOP_GET_CONFIGURATION
0x47 = SCSIOP_PLAY_AUDIO_MSF
0x48 = SCSIOP_PLAY_TRACK_INDEX
0x49 = SCSIOP_PLAY_TRACK_RELATIVE
0x4A = SCSIOP_GET_EVENT_STATUS
0x4B = SCSIOP_PAUSE_RESUME
0x4C = SCSIOP_LOG_SELECT
0x4D = SCSIOP_LOG_SENSE
0x4E = SCSIOP_STOP_PLAY_SCAN
0x51 = SCSIOP_READ_DISK_INFORMATION
0x52 = SCSIOP_READ_TRACK_INFORMATION
0x53 = SCSIOP_RESERVE_TRACK_RZONE
0x54 = SCSIOP_SEND_OPC_INFORMATION
0x55 = SCSIOP_MODE_SELECT10
0x5A = SCSIOP_MODE_SENSE10
0x5B = SCSIOP_CLOSE_TRACK_SESSION
0x5C = SCSIOP_READ_BUFFER_CAPACITY
 0x5D = SCSIOP_SEND_CUE_SHEET
0x5E = SCSIOP_PERSISTENT_RESERVE_IN
0x5F = SCSIOP_PERSISTENT_RESERVE_OUT
0xA0 = SCSIOP_REPORT_LUNS
0xA1 = SCSIOP_BLANK
0xA3 = SCSIOP_SEND_KEY
0xA4 = SCSIOP_REPORT_KEY
0xA5 = SCSIOP_MOVE_MEDIUM
0xA6 = SCSIOP_LOAD_UNLOAD_SLOT
0xA6 = SCSIOP_EXCHANGE_MEDIUM
0xA7 = SCSIOP_SET_READ_AHEAD
0xAD = SCSIOP_READ_DVD_STRUCTURE
0xB5 = SCSIOP_REQUEST_VOL_ELEMENT
0xB6 = SCSIOP_SEND_VOLUME_TAG
0xB8 = SCSIOP_READ_ELEMENT_STATUS
0xB9 = SCSIOP_READ_CD_MSF
0xBA = SCSIOP_SCAN_CD
0xBB = SCSIOP_SET_CD_SPEED
0xBC = SCSIOP_PLAY_CD
0xBD = SCSIOP_MECHANISM_STATUS
0xBE = SCSIOP_READ_CD
0xBF = SCSIOP_SEND_DVD_STRUCTURE
0xE7 = SCSIOP_INIT_ELEMENT_RANGE

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Read-only pass-through disk after you
add the disk to a highly available VM in
a Windows Server 2008 R2 SP1 failover
cluster
Article • 12/26/2023

This article provides the steps to add a pass-through disk to a highly available virtual
machine (VM) in a Windows Server 2008 R2 Service Pack 1 (SP1)-based failover cluster,
and helps solve the issue where the added pass-through disk status is displayed as
read-only.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2501763

Add a pass-through disk to a highly available

VM
To add a pass-through disk to a highly available VM in a Windows Server 2008 R2 SP1
failover cluster, follow these steps:

1. Log on as a domain user who is a member of the Local Administrators group on

each cluster node.

2. Configure the pass-through disk on the Storage Area Network (SAN), and map the
disk to each cluster node.

3. Open the Disk Management snap-in, and then verify that each cluster node
detects the disk and that the disk status is Offline.

4. Right-click the name of the disk, and then click Online to bring the disk online.

5. Right-click the name of the disk, and then click Initialize Disk to initialize the disk.

6. Right-click the name of the disk, and then click Offline to take the disk offline.

７ Note

You must take the disk offline before you add the disk to the cluster.
 7. Add the disk to the failover cluster. To do this, follow these steps:
a. Open the Failover Cluster Manager snap-in, right-click Storage in the console
tree, and then click Add disk.
b. In the Add Disks to a Cluster dialog box, click to select the check box for the
disk that you want to add, and then click OK.
c. In the Storage pane, verify that the disk is listed in Available Storage and that
the disk status is Online.

8. Add the disk to an existing highly available VM in the cluster. To do this, follow
these steps:

a. In the Failover Cluster Manager snap-in, right-click the VM listed under Virtual
Machine, and then click Settings.

b. In the Settings dialog box, select a disk controller, and then click Add to add the
disk to the disk controller. For example, click SCSI Controller, and then click Add
to add the disk to the SCSI controller.

c. In the Hard Drive pane, select the disk from the Physical hard disk list, and then
click OK.

７ Note

If you cannot find the disk from the Physical hard disk list, verify that the
disk status is Offline in the Disk Management snap-in.

d. Verify that the disk is displayed under Disk Drivers of the VM. Verify that the
disk is displayed in the Dependencies tab of the properties dialog box for the
VM.

9. In the Failover Cluster Manager snap-in, right-click the VM, and then click
Connect.

10. In the Disk Management snap-in, verify that the disk is added and that the disk
status is Offline.

11. Right-click the name of the disk, and then click Online to bring the disk online.

７ Note

You may find that the disk status is Read Only.

Resolve the issue of the read-only disk status
To resolve the issue of the Read Only disk status in the VM, follow these steps:

1. Open a command prompt on the VM, type the net stop vds command, and then
press ENTER to stop the Virtual Disk Service (VDS).
2. At the command prompt on the VM, type the net start vds command, and then
press ENTER to restart the VDS.
3. Open the Disk Management snap-in, and verify the disk status. If the disk status is
still Read Only, restart the VM.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Replicated Cluster Shared Volumes are
offline after an Azure Stack HCI upgrade
Article • 12/26/2023

This article provides methods to start the StorageReplica service after an Azure Stack
hyperconverged infrastructure (HCI) upgrade.

Summary
After you upgrade a stretched cluster from Azure Stack HCI, version 20H2 to version
21H2, all the replicated Cluster Shared Volumes are offline.

In addition, Event ID 7001 is logged in the Event Viewer.

Output

Event ID: 7001

Event Source: Service Control Manager
Event Details: The StorageReplica service depends on the LanmanWorkstation
service which failed to start because of the following error:
The service cannot be started, either because it is disabled or because it
has no enabled devices associated with it.

The StorageReplica service fails to start

This issue occurs because the StorageReplica service fails to start. The StorageReplica
service depends on the LanmanWorkstation service that doesn't start. After some time,
the LanmanWorkstation service is started and in the running status. However, the
StorageReplica service remains stopped.

Restart the server or manually start the

StorageReplica service
To fix this issue, restart the server again or manually start the StorageReplica service.

７ Note
 These methods are required only once on each server after a Cluster-Aware
Updating (CAU) upgrade.

Create a post-update script to avoid the issue

Upgrading stretched clusters with a CAU post-update script is supported by using
Windows PowerShell. To avoid this issue, run the Invoke-CauRun cmdlet with a post-
update script when you upgrade the cluster.

７ Note

Upgrading stretched clusters by using Windows Admin Center is not supported.

1. Create a PowerShell script (named Post_Update_Script.ps1) as follows:

PowerShell

Get-Service "Storage Replica" | Stop-Service

sleep 20
Get-Service "Storage Replica" | Start-Service
sleep 20

2. Run the Invoke-CauRun cmdlet with the created post-update script:

PowerShell

Invoke-CauRun -ClusterName <ServerName> -CauPluginName

"Microsoft.RollingUpgradePlugin" -CauPluginArguments
@{'WuConnected'='true';} -Verbose -EnableFirewallRules -Force -
PostUpdateScript Post_Update_Script.ps1

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Microsoft support policy for 4K sector
hard drives in Windows
Article • 12/26/2023

This article describes the support information for the large-sector (4K) drives when
they're used with Windows and other Microsoft products.

Applies to: Windows 10, version 1809, and later versions, Windows Server 2019,
Windows 7 Service Pack 1, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2510009

Summary
Over the next few years, the data storage industry will be transitioning the physical
format of hard disk drives from 512-byte sectors to 4,096-byte sectors (also known as
4K, or 4KB sectors). This transition is driven by several factors, including increases in
storage density and reliability. This transition causes incompatibility issues with existing
software (including operating systems and applications).

This article describes the current Microsoft support policy for these new drive types in
Windows. Applications and hardware devices may have reliability and performance
issues when they're connected to these new kinds of drives. Contact your application
and hardware vendors about their support policies for these new drive types.

There are three drive types that we'll discuss here. Because Microsoft support policy
differs for each, you should verify the drive type that you've installed before you read
any further.

ﾉ Expand table

Common Names Reported Reported Windows Version with Support

Logical Sector Physical
Size Sector Size

512-byte Native, 512 bytes 512 bytes All Windows versions

512n

Advanced Format, 512 bytes 4 KB Windows Vista with update KB

512e, AF, 512-byte 2553708 installed
Emulation
Windows Server 2008with update KB
2553708 installed
 Common Names Reported Reported Windows Version with Support
Logical Sector Physical
Size Sector Size

Windows 7 with update KB 982018

installed

Windows Server 2008 R2 with update

KB 982018 installed

All Windows versions from Windows 7

Server Pack 1 and later versions.

All Server versions from Server 2008 R2

Server Pack 1 and later versions.

*Except for Hyper-V. See the

Application support requirements for
large-sector drives section.

Advance Format, 4 KB 4 KB All Windows versions from Windows 8

AF, 4K Native, 4Kn and later versions. All Server versions
from Server 2012 and later versions.

Other Not 4 KB or Not 4 KB or Not Supported

512 bytes 512 bytes

To verify the kind of drive that you have, follow these steps:

1. Install KB 982018 .

2. Run the following command from elevated command prompt:

Console

Fsutil fsinfo ntfsinfo x:

where x: represents the drive that you're checking.

3. Use the following values to determine the kind of drive that you have.

Bytes Per Sector

Bytes per Physical Sector

To do so, use the following table:

ﾉ Expand table
 Bytes Per Sector Bytes per Physical Sector Drive type
value value

4096 4096 4K native

512 4096 Advanced Format (also known as

512E)

512 512 512-byte native

Specific requirements for Microsoft support by

operating system version
Windows 8, Windows Server 2012 and later versions

The below list summarizes the new features delivered as part of Windows 8 and
Windows Server 2012 to help improve customer experience with large sector disks.
For more detailed description for each item, see Advanced format (4K) disk
compatibility update.

Builds upon the Windows 7 SP1 support for 4K disks with emulation (512e). And
it provides full inbox support for disks with 4K sector size without emulation (4K
Native). Some supported apps and scenarios include:
Ability to install Windows to and boot from a 4K sector disk without
emulation (4K Native Disk)
New VHDx file format
Full Hyper-V support
Windows backup
Full support with the NT File System (NTFS)
Full support with the Resilient File System (ReFS)
Full support with Storage Spaces
Full support with Windows Defender
Inbox application support

Windows 7 and Windows Server 2008 R2

Install Service Pack 1 (SP1), or install the update 982018 .

Make sure that the drivers and firmware for your storage controller and other
hardware components are updated. Also, make sure that the drives and
firmware support large-sector drives.
 Use the updated Windows Preinstallation Environment (Windows PE) for SP1
that will be released as part of the updated pieces of the Windows Automated
Installation Kit (AIK) Supplement for Windows® 7 SP1 and of the Windows
OEM Preinstallation Kit (OPK). Or, embed update 982018 into Windows PE.

Application support requirements for large-

sector drives
In addition to Windows operating system support, administrators and users should
make sure that their applications support these large-sector drives. Scenarios and issues
to be aware of include performance, reliability, backup, and recovery. Support
statements for some Microsoft applications and products include:

Hyper-V: Using Hyper-V with large-sector drives in Windows Server 2008 and
Windows Server 2008 R2

SQL Server: SQL Server - New Drives Use 4K Sector Size

Exchange Server: Exchange Server storage configuration options

Third-party applications and hardware: Applications and hardware devices may

have reliability and performance issues when they're connected to these new
drives. Contact your application and hardware vendors about their support policy
for these drives.

Known compatibility issues

The following are known compatibility issues that may occur when you use large-sector
drives:

If your Windows partitions were created using a version of Windows PE (or

Windows Setup) based on a Windows codebase before Windows Vista SP1
(including Windows Vista RTM and all versions of Windows XP), the default
partitions will be unaligned. Therefore, all I/O issued to the volume, even with the
hotfixes (if applicable to your platform), will by nature be unaligned. It's
recommended that you create the partitions using a Windows PE version based on
the Windows Vista SP1 codebase or newer.

On Windows 7 and Windows 2008 R2, installation will fail with an error Windows
Setup could not configure Windows on this computer's hardware. This issue
occurs under the conditions that are outlined in the following article:
"Windows Setup could not configure Windows on this computer's hardware"
installation error on a Windows 7 or Windows Server 2008 R2 computer .

If you're using a logical sector drive of a size other than 512 bytes, Windows
system image backup and restore operations may fail. And you receive the
following error message:

One of the backup files could not be created.

Details: The request could not be performed because of an I/O device error.
Error code: 0x8078002A

If you create a virtual hard disk (VHD) on a native 4K sector drive by using Disk
Management or Hyper-V in Windows Server 2008 R2, the operation fails with an
Incorrect Function error.

In Disk Management, the following error message is generated:

Virtual Disk Manager Incorrect function

In Hyper-V, the following error message is generated when the New Virtual
Hard Disk Wizard is used:

The server encountered an error trying to create the virtual hard disk. The
system failed to create 'I:\Disk0.vhd.' Error Code: Incorrect function.

In Hyper-V, the following error message is generated when the New Virtual
Machine Wizard is used:

The server encountered an error while configuring hard disk on TestVM. The
system failed to create 'I:\TestVM\TestVM.vhd.' Error Code: Incorrect
function.

If fsutil.exe continues to display Bytes Per Physical Sector: <Not Supported> after
you apply the latest storage driver and the required hotfixes, make sure that the
following registry path exists:
Location: HKEY_LOCAL_MACHINE\CurrentControlSet\Services\<miniport's service
name>\Parameters\Device\

Name: EnableQueryAccessAlignment
Type: REG_DWORD
Value: 1: Enable
Unsupported scenarios
If your storage device and operating system are noted as unsupported, Microsoft
Support will offer troubleshooting tips if the customer requests them. Microsoft doesn't
guarantee that a resolution will be found for problems that involve unsupported storage
devices. If no resolution is found, the cost of investigating the incident isn't refunded. If
it's not agreed that a solution isn't guaranteed, Microsoft Support won't troubleshoot
the issue and will refund the cost of investigating the incident.

Microsoft Support will use standard troubleshooting processes to isolate the storage
issue. Some typical troubleshooting methods that Microsoft Support will use include:

Consulting the Microsoft Knowledge Base. The Microsoft Knowledge Base is

available to customers through Microsoft Support .

Determining whether the problem can be replicated on supported storage (when

it's possible).

７ Note

If the storage is unsupported, there's no hotfix support available. Microsoft

Support will be unable to determine whether the problem is caused by a
hardware incompatibility or by unwanted software behavior.

If there's no solution to the problem, Microsoft Support may recommend some

constructive alternatives, including:

Asking the customer to reproduce the problem on a supported storage device

Asking the customer to work with the storage provider for a solution

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"USB Device not recognized" error when
you try to access a USB external hard
drive
Article • 12/26/2023

This article provides methods to solve the USB Device not recognized error that occurs
when you try to access a USB external hard drive.

Symptoms
When you try to access data on an external USB hard drive, you may receive the
following error:

USB Device not recognized: One of the devices attached to this computer has
malfunctioned and windows does not recognize it.

Applies to: Windows 10, version 1709, Windows 7 Service Pack 1

Original KB number: 2654149

Cause
This issue can be caused if any of the following situations exist:

The currently loaded USB driver has become unstable or corrupt.

Your PC requires an update for issues that may conflict with a USB external hard
drive and Windows.
Windows may be missing other important updates hardware or software issues.
Your USB controllers may have become unstable or corrupt.
Your external drive may be entering selective suspend.
Your PC motherboard may need updated drivers.

Resolution 1 - Uninstall and then reconnect the

external hard drive
This method resolves issues where the currently loaded USB driver has become unstable
or corrupt.
 1. Select Start, type Device Manager in the Search box.
2. Select Device Manager from the returned list.
3. Select Disk Drives from the list of hardware.
4. Press and hold (or right-click) the USB external hard drive with the issue, and select
Uninstall.
5. After the hard drive is uninstalled, unplug the USB cable.
6. Wait for 1 minute and then reconnect the USB cable. The driver should
automatically load.
7. Check for the USB drive in Windows Explorer.

７ Note

Connecting your USB external hard drive into a non-powered USB hub can cause a
lack of enough power to operate the external drive. Instead, plug it directly into
your computer.

If this method does not solve your issue, proceed to resolution 2.

Resolution 2 - Install hotfixes that resolve

issues that may exist on Windows 7
The hotfixes in this method can resolve a known conflict with a USB external hard drive
and Windows.

1. Go to KB976972 You encounter problems when you move data over USB from a
Windows 7-based computer that has an NVIDIA USB EHCI chipset and at least 4
GB of RAM .

2. Under Update information, select Download the update package now that
corresponds with your version of Windows 7.
a. If you're unsure of which version of Windows 7 you are running, select the Start
button, press and hold (or right-click) Computer > Properties.

If 64-bit Operating System is listed next to System type, you're running the
64-bit version of Windows 7.
If 32-bit Operating System is listed next to System type, you're running the
32-bit (x86) version of Windows 7.

3. Select Continue. If a User Account Control permission prompt occurs, select Yes.

4. Select Download > Open.

 5. The download should start in 30 seconds. If it does not, select Start Download >
Open.

6. Follow the onscreen instructions to complete the download and installation.

7. Go to KB974476 The computer stops responding when an USB device resumes

from the USB Selective Suspend state in Windows 7 .

8. Select View and request hotfix downloads > Select hotfix.

9. If prompted, review the license agreement. If you agree to the terms, select I
Accept.

10. Check the box next to your version of Windows 7, then enter your email in the
boxes below.

11. Enter the word verification, then select Request hotfix.

12. Check your email. You will soon see an email from Microsoft with a download link
for the hotfix. Select the link and follow the onscreen instructions to download and
install the hotfix.

13. Restart your computer.

If your problem still persists, proceed to resolution 3.

Resolution 3 - Install the latest Windows

Updates
This method will install the latest device drivers for your USB external hard drive.

1. Select the Start button, type Windows Update in the Search box, and then select
Windows Update in the results pane.
2. Select Check for Updates. After the scan is complete, select Review optional
updates.
3. Select the check box next to the updates, then select Install updates.
4. If prompted, review the license agreement, then select I Accept.
5. Follow the onscreen instructions to download and install the updates.
6. If prompted, reboot your computer.

If your problem still exits, proceed to resolution 4.

Resolution 4 - Reinstall USB controllers

This method resolves steps where the currently loaded USB driver has become unstable
or corrupted.

1. Select Start, then type device manager in the Search box, and then select Device
Manager.
2. Expand Universal Serial Bus controllers. Press and hold (or right-click) a device and
select Uninstall. Repeat for each device.
3. Once complete, restart your computer. Your USB controllers will automatically
install.

If your problem still exists, proceed to resolution 5.

Resolution 5 - Disable USB selective suspend

setting
This method prevents your USB external drive from powering down.

1. Select the Start button, type power plan in the Search box, and then select Choose
a power plan.
2. Next to your currently selected plan, select Change Plan Settings.
3. Select Change advanced power settings.
4. Select the box to expand USB Settings > USB selective suspend settings.
5. Select Plugged in, select the drop-down menu, and then select disabled.
6. If you're using a laptop, select Battery, select the drop-down menu, and then
select disabled.
7. Select Apply > OK.

If this doesn't resolve your issue, proceed to resolution 6.

Resolution 6 - Install your motherboard's latest

chipset drivers
This method updates your motherboard's chipset drivers, so your computer will
recognize your USB external hard drive.

1. Review your computer's documentation that should contain the name of the
motherboard manufacturer.
2. Visit your computer manufacturer's support website. For a list of computer
manufacturers' support sites, see Computer manufacturers' contact information .
3. Navigate their website to find the appropriate drivers for your motherboard. For
assistance, contact your computer manufacturer.
If your issue still exists, we recommend contacting Microsoft product support.

More information
For more information, see Windows Update .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to extend stand-alone tiered
storage spaces
Article • 12/26/2023

This article shows how to extend stand-alone tiered storage spaces.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4562879

The following article explains how to expand tiered storage spaces on a stand-alone
server. Here's an example of a tiered space created with a 12.1 TB size in Windows
Server 2016.

Here's how to extend the Tiered Storage Space:

1. Add hard drives to the storage pool.

2. Update the Media Type of the new added disk.

3. Run the get-physicaldisk | fl * cmdlet and copy the UniqueId of the newly
added disk:

4. Run the following cmdlet to change the Media Type of the newly added disk:

PowerShell

Set-PhysicalDisk -UniqueId 6002 -MediaType HDD

Refresh the Server Manager to change the Media Type.

5. Run this cmdlet to expand the disk:

PowerShell

Resize-StorageTier -FriendlyName Vdisk01_Microsoft_HDD_Template -size

16.1TB

6. Resize the disk volume in the Disk Management.

7. The storage has been expanded.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to restore a Windows 7 installation
Article • 12/26/2023

This article describes how to create a system state backup on one computer and how to
restore it to the same computer or to a different physical computer of the same make
and model.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 249694

Summary
One of the following problems may occur with your computer:

Hardware failure
Software failure
Computer theft
Natural disaster
User error

To recover from one of these problems, you can restore the Microsoft Windows
operating system from a system state backup. You can restore a system state backup to
the same physical computer from which the system state backup was created, or to a
different physical computer that has the same make, model, and configuration (identical
hardware).

However, we do not support restoring a system state backup from one computer to a
second computer of a different make, model, or hardware configuration. We only
provide commercially reasonable efforts to support this process. Even if the source and
destination computers seem to be identical makes and models, the source computers
may have different drivers, hardware, or firmware than the destination computers.

The preferred method to restore Windows 7

To restore Windows 7-based computers, the preferred method is a full system restore.
Specifically, without using ASR, you can perform a Bare Metal Restore (BMR) to freshly
formatted boot volumes and system volumes on the same server that the original
backup was taken from. In this case, the volume layouts and identifiers are identical to
those used during the backup of the original computer. Additionally, you can perform a
BMR that uses ASR to a computer that has different hardware than the original
computer.

７ Note

BMRs can be performed only when the system is offline.

Both the Target machine being backed up and the Destination machine receiving
the restore have to be either Unified Extensible Firmware Interface (UEFI) or BIOS
based. You cannot mix the two in a BMR scenario.

Possible recovery scenarios for Windows 7

Server unbootable/Server-migration scenario (planned and unplanned)

In this scenario, you can protect the server by doing a BMR backup of all critical
volumes on the server. You then recover the server by doing a BMR recovery
through Windows Recovery. In this scenario, BMR is supported to different
hardware.

Server malfunction scenario (bootable) or rollback of server roles

In this scenario, you can protect the server by doing a System State Backup or a
BMR backup. You would then recover the server by doing a System State Recovery
from the started operating system.

The following table outlines supported and unsupported system recovery scenarios.

ﾉ Expand table

Scenario Supported

System State Recovery after BMR / Full Server restore to the same hardware Yes

System State Recovery after BMR / Full Server restore to different hardware No

System State Recovery after Full Server restore (without BMR) to the same or No
different hardware

７ Note

Windows Server Backup ensures that the system boots successfully after the BMR
restore process. Applications/Roles that rely on hardware-specific identifiers like
 NIC address, and so on, may require additional reconfiguration or recovery to make
them functional.

Guidelines for restoring the Windows 7

operating system
Follow the guidelines in the following sections to help make sure that the restore
operation succeeds.

Hardware abstraction layer

The source and destination computers must use the same type of Hardware Abstraction
Layer (HAL). There's one exception to this rule. If one of the computers contains the
Advanced Configuration and Power Interface (ACPI) multiprocessor HAL, the other
computer can have the ACPI uniprocessor HAL. The same rule applies to MPS
multiprocessor and MPS uniprocessor HALs.

For example, if the source is using the MPS multiprocessor HAL, you can restore data to
a destination computer that uses the MPS uniprocessor HAL. However, you can't restore
data to a destination computer that uses the ACPI multiprocessor HAL.

７ Note

If the destination computer's HAL is compatible, but not identical, to the source
computer's HAL, you must update the HAL on the destination computer after you
finish the restore. For example, if the source computer has a single processor and is
using the ACPI uniprocessor HAL, you can restore a backup from that computer to
a multiprocessor destination computer. However, the destination computer will not
use more than one processor until you update the HAL to an ACPI multiprocessor
HAL.

To determine the computer HAL type that you're using on each computer, follow these
steps:

1. Select Start, point to Settings, select Control Panel, and then select System.

2. On the Hardware tab, select Device Manager, and then expand the Computer
branch.

ACPI multiprocessor computer = Halmacpi.dll

 ACPI uniprocessor computer = Halaacpi.dll
Advanced Configuration and Power Interface (ACPI) computer = Halacpi.dll
MPS multiprocessor computer = Halmps.dll
MPS uniprocessor computer Halapic.dll standard computer = Hal.dll
Compaq SystemPro multiprocessor or 100% compatible = Halsp.dll

Operating system version

The source and destination computers must use identical operating system versions and
identical Windows stock-keeping units (SKUs). For example, you can't back up Windows
2000 Server and then restore it on a computer that is running Windows 2000 Advanced
Server. Also, the source and destination computers should both use retail versions of
Windows or the same OEM version of Windows. The best practice is to install Windows
on the destination computer by using the same installation media that you used to
install Windows on the source computer.

Filter drivers
Uninstall third-party filter drivers on the source computer before you do the backup.
These kinds of drivers can cause problems when the backup is restored to a different
computer.

Windows folder and disk layout

The destination computer must use the same logical drive letter (%systemdrive%) and
path (%systemroot%) as the source computer. For domain controllers, the locations of
the Active Directory directory service database, Active Directory log files, FRS database,
and FRS log files must also be identical for the source and destination computers. For
example, if the Active Directory database log files on the source computer were installed
on C:\WINNT\NTDS, the destination computer must also use the C:\WINNT\NTDS path.

Hardware
If you remove any hardware on the destination computer that isn't required to complete
the restore process, you increase the probability of a successful restore operation. For
example, physically remove or disable all except one network adapter. Install or enable
the additional adapters after you restart the operating system after the restore
operation.

Hotfix and service pack level

For example, for Windows 2000 computers, hotfix 810161 or Windows 2000 Service
Pack 4 must be installed on the source computer before you back up data. These items
must also be installed on the destination computer before you restore the backup.
Windows Server 2003 and Windows XP have no hotfix or service pack level requirements
for this kind of restore operation. A user doesn't have to bring the destination computer
up to the same service pack and hotfix level for Windows Server 2003 or for Windows
XP. However, restoring a Windows Server 2003 SP1-based computer requires you to
restore the destination computer to Windows Server 2003 SP1.

Possible issues and the steps to troubleshoot

After you restart the destination computer, you may experience the following
symptoms:

You receive one of the following Stop error messages:

Stop 0x0000007B Inaccessible_Boot_Device

STOP: 0x00000079 Hal_Mismatch

The computer stops responding at startup.

The computer spontaneously restarts when you receive the Starting Windows
2000 message on a black screen early in the restart process.
You can't configure your display settings.
The network adapter doesn't function correctly.

To resolve issues with the display settings or with a network adapter, remove the
graphics adapter or the network adapter from Device Manager, and then restart the
computer. Windows will detect again the device and possibly prompt you for drivers.

To resolve the Stop error or the problem where a computer stops responding, do an in-
place upgrade of Windows.

After you finish the in-place upgrade, verify that the ClientProtocols registry subkey
exists and is populated correctly. To do this, follow these steps:

1. Select Start, select Run, type regedit, and then select OK.

2. Locate and then right-click the following registry subkey. Verify that the values in
the following list exist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols

ﾉ Expand table
 Value name Value type Value data

ncacn_ip_tcp REG_SZ rpcrt4.dll

ncacn_ip_udp REG_SZ rpcrt4.dll

ncacn_nb_tcp REG_SZ rpcrt4.dll

ncacn_np REG_SZ rpcrt4.dll

3. If the ClientProtocols subkey is missing, add it under the Rpc subkey.

4. If values are missing in the ClientProtocols subkey, follow these steps:

a. Right-click ClientProtocols, point to New, and then select String Value.
b. Type the value name of the entry that is missing, and then press Enter.
c. Right-click the value name that you typed in step b, and then select Modify.
d. Type the appropriate value data for the value name that you typed in step b,
and then select OK.

5. Repeat step 4 for each missing value in the ClientProtocols subkey.

6. Restart the computer if any registry changes were made.

７ Note

If the source computer was upgraded from Windows NT 4.0, the user profiles may
be stored in the %systemroot%\Profiles folder instead of in the
%systemdrive%\Documents and Settings folder. After an in-place upgrade is
performed, you may have to change the following registry value back to
%systemroot%\Profiles.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

ﾉ Expand table

Value Name Profiles directory

Value Type REG_EXPAND_SZ

Value Data %systemroot%\Profiles

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server backup may fail
because of the SQL Server VSS writer
Article • 12/26/2023

This article provides a solution to an issue where Microsoft Windows Server backup fails
with an error: A Volume Shadow Copy Service Operation failed.

Applies to: Windows Server 2012 R2, Windows Server 2016

Original KB number: 2615182

Symptoms
A backup of the server may fail with the following error message:

A Volume Shadow Copy Service Operation failed. Detailed Error: The volume
shadow copy operation failed with error 0x800423F4. View the event log for more
information.

The following error message will be recorded in the application event log:

Output

Log Name: Application

Source: Microsoft-Windows-Backup
Event ID: 521
Level: Error
Description:
Backup started at '*\<DateTime>*' failed as Volume Shadow copy operation
failed for backup volumes with following error code '2155348129'. Please
rerun backup once issue is resolved.

If you examine the application event log more, you will notice numerous errors from
sources SQLWriter and SQLVDI.

The errors will be similar to the following:

Output

Log Name: Application

Source: SQLWRITER
Event ID: 24583
Level: Error
Description:
 Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr =
0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 3271
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: A nonrecoverable I/O error occurred on file " {DF1DD65F-
F8AD-4946-A764-F62166C541E2}22:" 995(The I/O operation has been aborted
because of either a thread exit or an application request.).

Output

Log Name: Application

Source: SQLVDI
Event ID: 1
Level: Error
Keywords: Classic
User: N/A
Computer: CONTOSOSERVER.contoso.local
Description:
SQLVDI: Loc=TriggerAbort. Desc=invoked. ErrorCode=(0). Process=3720.
Thread=9404. Server. Instance=SBSMonitoring. VD=Global{DF1DD65F-F8AD-4946-
A764-F62166C541E2}10_SQLVDIMemoryName_0.

Cause
When Windows Server backup attempts to back up a disk volume, a Volume Shadow
Copy Snapshot is created for the volume. When the snapshot is created, any Volume
Shadow Copy Service (VSS) writer associated with the volume is called. If any of the VSS
writers encounter an error, the entire backup job will fail. In this example, the SQL VSS
writer is encountering an error and causing the backup job to fail.

Resolution
The error is typically caused by a problem with one of the SQL Server instances. In order
to troubleshoot the problem, you must first figure out which SQL Server instance has
the problem. Usually, the problematic SQL Server instance will be named in the first
recorded SQLVDI error.

For example:

Output
 Log Name: Application
Source: SQLVDI
Event ID: 1
Level: Error
Description:
SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0).
Process=4772. Thread=10300. Client. Instance= SBSMONITORING .
VD=Global{3AB8F080-950C-4EF9-B637-0F37B2428F17}1_SQLVDIMemoryName_0.

In this example, the SQL Server instance named SBSMONITORING is failing the snapshot.

There may also be an error message from source SQLWRITER that occurs at about the
same time as the first SQLVDI error. The SQLWRITER error message may identify the
database name that is having a problem with the snapshot.

For example:

Output

Log Name: Application

Source: SQLWRITER
Event ID: 24583
Description:
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr =
0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 945
Error state: 2, Severity: 14
Source: Microsoft SQL Server Native Client 10.0
Error message: Database 'SBSMonitoring' cannot be opened due to inaccessible
files or insufficient memory or disk space. See the SQL Server errorlog for
details.

In this example, the database named SBSMonitoring is having a problem.

Once you have identified the SQL Server instance that is having a problem, the first step
would be to test the backup with that SQL Server instance stopped. In our example of
the SBSMonitoring instance, you would stop the SQL Server (SBSMonitoring) service
on the server.

You would then run the backup job with the affected SQL Server instance stopped. If the
backup completes, then you know the failure is caused by the SQL Server instance that
is not running. You would then examine the SQL Server error log files and the event logs
to see if we can determine what is wrong with that particular instance of SQL Server.
If you can't determine the problematic SQL Server instance from the event logs, you can
always stop all the SQL Server instances on the server and try to run backup with SQL
stopped. If all the SQL Server instances are stopped, the SQL VSS writer will not be used.

On a default installation of Small Business Server 2008, you would stop the following
services:

SQL Server (SBSMonitoring)

Windows Internal Database

On a default installation of Small Business Server 2011 Standard, you would stop the
following services:

SQL Server (SharePoint)

SQL Server (SBSMonitoring)
Windows Internal Database

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Backup fails with VSS event ID 12292
and 11 on Windows Server
Article • 12/26/2023

This article discusses an issue where backup operation using Windows Server Backup or
a third-party backup application fails.

Applies to: Windows Server 2012 R2

Original KB number: 2009513

Symptoms
A backup operation using Windows Server Backup or a third-party backup application
fails on Windows Server.

In the System event log, the following event is logged:

Log Name: System

Source: Service Control Manager
Event ID: 7023
Level: Error
Description:
The Microsoft Software Shadow Copy Provider service terminated with the following
error:
The system cannot find the file specified.

In the Application event log, the following events are logged:

Log Name: Application

Source: VSS
Event ID: 12292
Level: Error
Description:
Volume Shadow Copy Service error: Error creating the Shadow Copy Provider COM
class with CLSID {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} [0x80080005].
Operation:
Obtain a callable interface for this provider
Obtaining provider management interface
Context:
 Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
Class ID: {00000000-0000-0000-0000-000000000000}
Snapshot Context: -1
Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
Log Name: Application
Source: VSS
Event ID: 11
Level: Error
Description:
Volume Shadow Copy Service information: The COM Server with CLSID {65ee1dba-
8ff4-4a58-ac1c-3470ee2f376a} and name SW_PROV cannot be started. Most likely
the CPU is under heavy load. [0x80080005]
Operation:
Obtain a callable interface for this provider
Obtaining provider management interface
Context:
Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
Class ID: {00000000-0000-0000-0000-000000000000}
Snapshot Context: -1
Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}

On Windows Server 2008, if Windows Server Backup was used to perform the backup,
the backup operation fails with one of the following errors:

Failed to create the shadow copy on the storage location.

ERROR - Volume Shadow Copy Service operation error (0x8004230f)
The shadow copy provider had an unexpected error while trying to process the
specified operation.

Or

The creation of the shadow copy on the backup destination failed.

The volume shadow copy operation failed with error 0x8004230F.
View the event log for more information.

On Windows Server 2008 R2, if Windows Server Backup was used to perform the
backup, the backup operation fails with one of the following errors:

Windows Backup failed to create the shadow copy on the storage location.
Or

The creation of the shadow copy on the backup storage destination failed.

Cause
This issue can occur if the ServiceDll registry value for Swprv is missing or incorrect.

Resolution
To resolve this issue, perform the following steps:

1. Click Start, type regedit in the Start Search box, and hit Enter.

2. Locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv\Parameters

７ Note

If the Parameters registry key is missing, perform the following steps: Right-
click the swprv registry key, select New, select Key, type Parameters and hit
Enter.

3. Once the Parameters registry key is selected, verify that the ServiceDll registry
value has the following value:

%Systemroot%\System32\swprv.dll

７ Note

If the ServiceDll registry value is missing, perform the following steps:

a. Right-click the Parameters registry key, select New, and then select
Expandable String Value.
b. For the value name, type ServiceDll and hit Enter.
c. Double-click the ServiceDll registry value.
d. In the Value Data box, type %Systemroot%\System32\swprv.dll, and then
click OK.

4. Perform a backup operation to verify that the issue is resolved.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x8000FFFF when you run the
vssadmin list writers command on a
Windows Server 2003-based computer
Article • 12/26/2023

This article resolves a problem that occurs when you use the vssadmin list writers
command on a Windows Server 2003-based computer. when the issue occurs, you may
receive an error message, an event, or the list may be blank.

Applies to: Windows Server 2003

Original KB number: 940184

Symptoms
When you run the vssadmin list writers command on a Windows Server 2003-based
computer, you may experience any of the following symptoms.

７ Note

The vssadmin list writers command lists the subscribed volume shadow copy
writers.

You receive the following error message:

Error: 0x8000FFFF

The following event may be logged in the Application log:

Event Type: Error

Event Source: VSS
Event ID: 12302
Description: Volume Shadow Copy Service error: An internal inconsistency was
detected in trying to contact shadow copy service writers. Please check to see
that the Event Service and Volume Shadow Copy Service are operating
properly.

The list is blank.

Cause
This problem may occur if the following registry key is corrupted:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-
00805fc79216}\Subscriptions

Resolution

） Important

This article is not for use with Windows Vista, with Windows Server 2008, or with
later Windows operating systems. Starting with Windows Vista and with Windows
Server 2008, Windows component installation is manifest-based. Trying to manually
register specific components, as described in the following steps, can have
unexpected results that may require you to reinstall Windows to resolve.

To resolve this problem, follow these steps:

1. Click Start > Run, type Regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-
00805fc79216}\Subscriptions

3. On the Edit menu, click Delete, and then click Yes to confirm that you want to
delete the subkey.

4. Exit Registry Editor.

5. Click Start > Run, typeservices.msc, and then click OK.

6. Right-click the following services one at a time. For each service, click Restart:

COM+ Event System

COM+ System Application
Microsoft Software Shadow Copy Provider
Volume Shadow Copy

7. Click Start > Run, type cmd, and then click OK.

8. At the command prompt, type vssadmin list writers, and then press Enter.
 9. If the VSS writers are now listed, close the Command Prompt window. You don't
have to complete the remaining steps.

If the VSS writers aren't listed, type the following commands at the command
prompt. Press Enter after each command.

cd /d %windir%\system32

net stop vss

net stop swprv

regsvr32 ole32.dll
regsvr32 oleaut32.dll

regsvr32 /i eventcls.dll

regsvr32 vss_ps.dll
vssvc /register

regsvr32 /i swprv.dll
regsvr32 es.dll

regsvr32 stdprov.dll

regsvr32 vssui.dll
regsvr32 msxml.dll

regsvr32 msxml3.dll
regsvr32 msxml4.dll

７ Note

The last command may not run successfully.

10. At the command prompt, type vssadmin list writers, and then press Enter.

11. Confirm that the VSS writers are now listed.

Did this fix the problem

Check whether the problem is fixed. If the problem is fixed, you're finished with this
section. If the problem isn't fixed, you can contact support .

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Error message when you perform a
Volume Shadow Copy Service restore
operation: 0x80042409
Article • 12/26/2023

This article describes an issue that occurs when you restore a virtual machine while
another backup that uses the Hyper-V writer is in progress.

Applies to: Windows Server 2012 R2

Original KB number: 978773

Symptoms
You perform a Volume Shadow Copy Service (VSS) backup or a VSS restore operation.
During the backup or restore operation, an event that resembles the following is written
to the Application log:

Event ID: 12289

Volume Shadow Copy Service error: Unexpected error An older writer session state
is being removed. . hr = 0x80042409, Writer status is not available for one or more
writers. A writer may have reached the limit to the number of available backup-
restore session states.

Operation: PreRestore Event

Context:
Old snapshot set: {41379de8-f7e7-4c76-bb47-7f080443e189}
Old operation: 1019
Old state: 5
Old failure: 0x800423f4
Old extended failure hr: 0x1
Old extended failure message: 0
Execution Context: Writer
Writer Class Id: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Writer Name: Microsoft Hyper-V VSS
Writer Writer Instance ID: {7eef8900-84b4-406e-a461-ce19e5e7ae7f}

Cause
This error occurs because a backup or restore session state in the VSS writer isn't
cleaned up correctly. The VSS writer infrastructure creates session-state objects for each
backup and restore session in which a VSS writer participates. Under typical
circumstances, the writer session-state objects are cleaned up when they're not being
used. Normal session state cleanup occurs under the following circumstances:

The backup application sends a BackupComplete response and then checks the
writer status by sending a GatherWriterStatus.

The backup application sends a PostRestore response and then checks the writer
status by sending a GatherWriterStatus query.

The writers receive the OnAbort event callback for the session. The OnAbort event
callback is invoked when the backup session is explicitly failed by the backup
application, by the writer or, by the VSS infrastructure.

The VSS writer infrastructure performs periodic garbage collection of the remaining
session states. The infrastructure then logs the previous event log for each session-state
object that is older than two days. The event log is intended to help identify abandoned
sessions in the writer that may indicate a misbehaving backup application. You can see
several similar events in rapid succession from multiple writers that indicate that there
was a series of incomplete backup or restore sessions. This behavior is most frequently
seen in test environments.

Workaround
Ignore intermittent occurrences of this error. The related event is logged in response to
garbage collection activities that are started by a backup or restore operation. However,
these errors aren't related to the active backup or restore session. If the error is
consistently reproducible, make sure that the backup application vendor is following all
the VSS backup session cleanup guidelines.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 32 occurs, and shadow copies
are unexpectedly deleted
Article • 12/26/2023

This article introduces a workaround for an issue in which shadow copy volume is
delayed in being brought online, and shadow copies are unexpectedly deleted. Event ID
32 is received when the issue occurs.

Symptom
On a server, shadow copies are stored on a different volume. After you restart the
server, you find shadow copies are deleted. Additionally, you receive the following event
log:

Output

Log Name: System

Source: volsnap
Event ID: 32
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The shadow copies of volume X: were aborted because the shadow copy storage
volume was not present.

You may notice delays in bringing the shadow copy volume online.

Cause
This issue occurs because there are multiple phantom shadow copy entries under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE\VolumeSnapshot . It increases

the time for the snapshots to be enumerated on the shadow storage volume when the
parent volume comes online.

If it takes a long time in the enumeration, volsnap will delete these snapshots.

Workaround
To work around this issue, use the devnodeClean.exe tool to clean up the large
buildup of phantom VolumeSnapshots in the registry key under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE\VolumeSnapshot .

７ Note

The devnodeclean.exe tool will only delete phantom shadow copies. Valid shadow
copies will remain intact.

To get the list of entries to be deleted, run the following command:

Console

devnodeclean /n

To delete the phantom shadow copies, run the following command:

Console

devnodeclean

Additionally, we recommend configuring a devnodeclean scheduled task to proactively

remove stale entries.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 513 when running VSS in
Windows Server
Article • 12/25/2023

This article provides a workaround to Event ID 513 when running VSS in Windows
Server.

Applies to: All supported versions of Windows Server

Original KB number: 3209092

Symptoms
In Windows Server, when an application calls the Volume Shadow Copy Service (VSS) to
run a backup, Event 513 may be generated:

Output

Log Name: Application

Source: Microsoft-Windows-CAPI2
Event ID: 513
Task Category: none
Level: Error

Description:
An error occurred in Cryptographic Services while processing the
OnIdentity() call in System Writer Object.

Details:
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer
Discovery Protocol.

System Error:
Access is denied.

Cause
This problem occurs because VSS System Writer does not have permission to read the
NT AUTHORITY\SERVICE (service account). When System Writer runs as a cryptographic
service and tries to read the Mslldp.sys information from a Microsoft Link-Layer
Discovery Protocol driver, the "access denied" error is generated.

Workaround
This event log entry can be safely ignored. To prevent this entry from being logged,
grant the required permission to the Microsoft Link-Layer Discovery Protocol driver
(Mslldp.dll) to process System Writer.

To do this, follow these steps:

1. Open an administrative Command Prompt window, and then run the following
command to check the current permissions:

Console

sc sdshow mslldp

2. Copy the output string from step 1, append it with (A;;CCLCSWLOCRRC;;;SU) , and
then run the following command to add the access permission to Mslldp.dll:

Console

sc sdset mslldp <string>

For example, run the following command:

Console

sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)

(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-
2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

No VSS writers are listed when you run
vssadmin list writers
Article • 12/26/2023

This article provides a resolution for the issue that no VSS writers are listed when you
run vssadmin list writers.

Applies to: Windows Server 2012 R2

Original KB number: 2009533

Symptoms
When you run vssadmin list writers on Windows Server 2008, no VSS writers are listed.
In the Application event log, the following events are logged:

Log Name: Application

Source: VSS
Event ID: 34
Level: Error
Description:
Volume Shadow Copy Service error: The VSS event class is not registered. This will
prevent any VSS writers from receiving events. This may be caused due to a setup
failure or as a result of an application's installer or uninstaller.

Log Name: Application

Source: VSS
Event ID: 8193
Level: Error
Description:
Volume Shadow Copy Service error: Unexpected error calling routine
CoCreateInstance. hr = 0x80040154.

Log Name: Application

Source: VSS
Event ID: 13
Level: Error
Description:
Volume Shadow Copy Service information: The COM Server with CLSID {faf53cc4-
bd73-4e36-83f1-2b23f46e513e} and name
VSSEvent cannot be started. [0x80070057]
 Log Name: Application
Source: VSS
Event ID: 8193
Level: Error
Description:
Volume Shadow Copy Service error: Unexpected error calling routine
CoCreateInstance. hr = 0x80070057.

If you open the Windows Server Backup snap-in, the following error occurs:

A fatal error occurred during a Windows Server Backup snap-in operation.

Error details:
Catastrophic failure.
Close Windows Server Backup and then restart it.

Cause
This issue occurs because the registry path to Eventcls.dll is incorrect or because the
registry data type for the TypeLib setting is incorrect.

Resolution
To resolve this issue, perform the following steps.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

1. Click Start, type regedit in the Start Search box, and then press ENTER.
2. Locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-
 00805fc79216}\EventClasses\{FAF53CC4-BD73-4E36-83F1-2B23F46E513E}-{00000000-
0000-0000-0000-000000000000}-{00000000-0000-0000-0000-000000000000}

3. Locate the TypeLib registry value.

７ Note

The registry type of TypeLib should be shown as REG_EXPAND_SZ. If that is not the
case, you have to delete the key, and then you have to recreate the key. To do this,
follow these two steps:
a. Select the TypeLib registry value, and then delete it.

b. Create a new Expandable String Value, and then name it TypeLib.

4. Double-click the TypeLib registry value. In the Value Data box, type
%systemroot%\system32\EVENTCLS.DLL, and then click OK.
5. Close Regedit.
6. Click Start, type services.msc in the Start Search box, and hit Enter.
7. Right-click the following services one at a time and click Restart:

COM+ Event System

Volume Shadow Copy

8. Close the Services snap-in.

9. Open an elevated command prompt, type vssadmin list writers, and then hit
ENTER.
10. Verify that the VSS writers are now listed.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Shadow copies are deleted on Windows
Server when you try to run an FCI
classification job
Article • 12/26/2023

This article describes an issue in which shadow copies are deleted on Windows Server
when you try to run an FCI classification job. This occurs when there's insufficient space
on the volume for shadow copies.

Applies to: Windows Server 2012 R2

Original KB number: 977521

Symptoms
On a Windows Server computer, you have a volume on which you have enabled shadow
copies through a Volume Shadow Copy (VSS) provider. On this volume, you run a File
Classification Infrastructure (FCI) classification job. However, the classification job
doesn't finish, and older shadow copies are deleted faster than expected from the
shadow copies storage area. This may result in all shadow copies being deleted from the
volume. Additionally, multiple entries that resemble the following may be logged in the
System log:

The oldest shadow copy of volume Volume_Letter : was deleted to keep disk space
usage for shadow copies of volume Volume_Letter : below the user defined limit.

Also, entries that resemble the following are logged in the FSRM log:

Warning DD/MM/YYYY hh :mm:ss AM_PM SRMSVC 12310 None

Shadow copy '\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy_File_Name'

was deleted during storage report generation. Volume 'Volume_Letter :' might be
configured with inadequate shadow copy storage area. Storage reports may be
temporarily unavailable for this volume.

Additionally, if you run an FSRM storage report, you receive the following error
message:

Error: RunFileQueries, 0x8004532c, A volume shadow copy could not be created or

was unexpectedly deleted.
 File Server Resource Manager encountered an unexpected error during volume scan
of volumes mounted at '\\?\Volume{Volume_PID}\' ('Volume_Letter:'). To find out
more information about the root cause for this error please consult the
Application/System event log for other FSRM, VSS or VOLSNAP errors related with
these volumes. Also, you might want to make sure that you can create shadow
copies on these volumes by using the VSSADMIN command like this: VSSADMIN
CREATE SHADOW /For=Volume_Letter :

Error generating report job with the task name 'Task_name'.

After you receive this error message, you find that the following error message is logged
in the System log:

Exception encountered = Catastrophic failure (Exception from HRESULT: 0x8000FFFF

(E_UNEXPECTED))

Cause
This issue occurs because the FCI classification process stores properties in each file that
is classified. This behavior changes the file on the volume that has shadow copies
enabled. These changes are tracked by the VSS provider and are then stored in the
shadow copies storage area. When a property is stored in a text file, only a few kilobytes
(KB) of data is written. However, when properties are stored in an Office file, the whole
Office file is rewritten. This behavior exhausts the VSS storage space much faster.

If the Maximum Shadow Copy Storage Space size allocation is insufficient to store all
these changes, VSS automatically deletes the oldest shadow copies first. If a large block
of files is classified, this process can fail and at the same time delete all the old shadow
copies from the storage area. This is especially true when you perform a full
classification on a volume for the first time. This action is very likely to generate lots of
changes on that volume.

Resolution
To resolve this issue, use one of the following methods:

Increase storage area size

Before you run a full classification of a volume for the first time, increase the maximum
storage area size. To do this, follow these steps:
 1. Click Start, click All Programs, click Accessories, and then right-click Command
Prompt.

2. Click Run as administrator.

If you're prompted for an administrator password, type the password. If you're

prompted for confirmation, click Continue.

3. At the command prompt, type the following command, and then press ENTER:

Console

vssadmin list shadowstorage /for=Volume_Letter:

4. Note the Maximum Shadow Copy Storage Space value.

5. At the command prompt, type the following command, and then press ENTER:

Console

vssadmin resize shadowstorage /for=Volume_Letter: /on=Volume_Letter:

/maxsize=Storage_Size mb

Where the placeholder, Storage_Size, is a value that is at least double the value
that you noted in step 4.

6. Close the Command Prompt window.

Incremental classification
When you perform a classification for the first time, classify only one namespace at a
time. Don't classify all the namespaces in the same classification job.

Disable Shadow Copies

You can disable shadow copies on the volume. We don't recommend that you disable
shadow copies on the volume. Only use this method if you can't allocate more storage
for shadow copies and the incremental classification method still exceeds the storage
area allocation.

To disable shadow copies for a volume, follow these steps:

1. Click Start, point to Administrative Tools, and then click Share and Storage
Management.
 2. In the details pane, click the Volumes tab.

3. Right-click the volume for which you want to disable shadow copies, and then click
Properties.

4. In the Volume_Name Properties dialog box, click the Shadow Copies tab.

5. Click Disable, and then click Yes.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

System state backup by using Windows
Server Backup fails with error: System
writer is not found in the backup
Article • 12/26/2023

This article provides a solution to an issue where you fail to perform a system state
backup by using Windows Server Backup.

Applies to: Windows Server 2012 R2

Original KB number: 2009272

Symptoms
When you perform a system state backup using Windows Server Backup on Windows
Server 2008, the backup fails with the following error:

Backup of system state failed [<DateTime>]

Log of files successfully backed up
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup <DateTime>.log'
Log of files for which backup failed
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup_Error
<DateTime>.log'
System writer is not found in the backup.

In the Application event log, the following events are logged:

Log Name: Application

Source: Microsoft-Windows-Backup
Event ID: 517
Level: Error
Description:
Backup started at '<DateTime>' failed with following error code '2155348226'
(System writer is not found in the backup.). Please rerun backup once issue is
resolved.

Log Name: Application

Source: Microsoft-Windows-CAPI2
Event ID: 513
Level: Error
 Description:
Cryptographic Services failed while processing the OnIdentity() call in the System
Writer Object.
Details:
AddCoreCsiFiles: BeginFileEnumeration() failed.
System Error:
Access is denied.

Cause
The system writer fails because permissions to files in the %windir%\winsxs\filemaps\ or
%windir%\winsxs\temp\PendingRenames directories are incorrect.

Resolution
To resolve this issue, type the following commands from an elevated command prompt:

Console

Takeown /f %windir%\winsxs\temp\PendingRenames /a
icacls %windir%\winsxs\temp\PendingRenames /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\temp\PendingRenames /grant "NT
Service\trustedinstaller:(F)"
icacls %windir%\winsxs\temp\PendingRenames /grant BUILTIN\Users:(RX)
Takeown /f %windir%\winsxs\filemaps\* /a
icacls %windir%\winsxs\filemaps\*.* /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\filemaps\*.* /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\filemaps\*.* /grant BUILTIN\Users:(RX)
net stop cryptsvc
net start cryptsvc

Type the following command to verify that the system writer is now listed:

Console

vssadmin list writers

If the system writer is missing, check the Application event log for the following event:

Log Name: Application

Source: VSS
Event ID: 8213
Level: Error
 Description:
Volume Shadow Copy Service error: The process that hosts the writer with name
System Writer and ID {e8132975-6f93-4464-a53e-1050253ae220} does not run
under a user with sufficient access rights. Consider running this process under a
local account which is either Local System, Administrator, Network Service, or Local
Service.
Operation:
Initializing Writer
Context:
Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Name: System Writer

The Details section of the event (Binary Data\In Bytes) would show up as:

0000: 2D 20 43 6F 64 65 3A 20 - Code:
0008: 57 52 54 57 52 54 49 43 WRTWRTIC
0010: 30 30 30 30 30 37 32 39 00000729
0018: 2D 20 43 61 6C 6C 3A 20 - Call:
0020: 57 52 54 57 52 54 49 43 WRTWRTIC
0028: 30 30 30 30 30 36 34 39 00000649
0030: 2D 20 50 49 44 3A 20 20 - PID:
0038: 30 30 30 30 31 30 38 34 00001084
0040: 2D 20 54 49 44 3A 20 20 - TID:
0048: 30 30 30 31 38 39 37 36 00018976
0050: 2D 20 43 4D 44 3A 20 20 - CMD:
0058: 43 3A 5C 57 69 6E 64 6F C:\Windo
0060: 77 73 5C 73 79 73 74 65 ws\syste
0068: 6D 33 32 5C 73 76 63 68 m32\svch
0070: 6F 73 74 2E 65 78 65 20 ost.exe
0078: 2D 6B 20 4E 65 74 77 6F -k Netwo
0080: 72 6B 53 65 72 76 69 63 rkServic
0088: 65 20 20 20 20 20 20 20 e
0090: 2D 20 55 73 65 72 3A 20 - User:
0098: 4E 54 20 41 55 54 48 4F NT AUTHO
00a0: 52 49 54 59 5C 4E 45 54 RITY\NET
00a8: 57 4F 52 4B 20 53 45 52 WORK SER
00b0: 56 49 43 45 20 20 20 20 VICE
00b8: 2D 20 53 69 64 3A 20 20 - Sid:
00c0: 53 2D 31 2D 35 2D 32 30 S-1-5-20
Open Regedit and navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl .

Change the value of NT AUTHORITY\NETWORK SERVICE (REG_DWORD) to 1.

You may also want to check the entry for other services (LOCAL SERVICE,
NetworkService) as indicated by event 8213.

The System Writer should now show up in the vssadmin list writers command:

Writer name: System Writer

Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Instance Id: {04cf6316-f0c5-4ce7-bbe4-e56e6334124c}
State: [1] Stable
Last error: No error

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Third-party backup warnings after you
install a servicing update in Windows
Server 2016
Article • 12/26/2023

This article provides a solution to the third-party backup warnings that occurs after you
install a servicing update in Windows Server 2016.

Applies to: Windows Server 2016

Original KB number: 4052556

Symptom
Consider the following scenario:

On a computer that is running Windows Server 2016 (Version 1607, build

14393.693), you install a servicing stack update. For example, the March 14, 2017
Servicing Stack Update (KB 4013418 ).
The folder C:\Windows\servicing\Version\10.0.14393.1051 is automatically created,
and the amd64_installed and x86_installed files are saved to this folder
The older-version folder under C:\Windows\servicing is emptied. For example, the
following files are removed:
C:\Windows\servicing\Version\10.0.14393.0\amd64_installed
C:\Windows\servicing\Version\10.0.14393.0\x86_installed
You run diskshadow /l output.txt , and then list writers detailed at the
diskshadow prompt.

In this scenario, when you examine the system writer metadata in output.txt, you find
the amd64_installed and x86_installed files are listed in the old version folder path that
no longer exists.

As a result, third-party backup applications may return warnings like the following:

Date/TimeANS4251W System Writer file '\\?

\globalroot\device\harddiskvolumeshadowcopy3\windows\servicing\version\10.0.14
393.0\amd64_installed': not found. Date/TimeANS4251W System Writer file '\\?
\globalroot\device\harddiskvolumeshadowcopy3\windows\servicing\version\10.0.14
393.0\x86_installed': not found.
This issue does not occur with Windows Server 2016 RTM version.

７ Note

This issue does not affect System State backup with Windows Server backup.

Resolution
To fix the issue, create new placeholder files with the same name for the files that are
reported as not found.
C:\Windows\servicing\Version\10.0.14393.0\amd64_installed
C:\Windows\servicing\Version\10.0.14393.0\x86_installed

More information
The files are no longer needed. However, they are still listed as needing to be backed
up. The content of the file is irrelevant and can be empty.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Disk volumes take longer to go online
when you use the Volume Shadow Copy
Service on computers that run many I/O
operations
Article • 12/26/2023

This article describes a workaround for an issue in which disk volumes take more time to
go online after you enable the Volume Shadow Copy Service on the volumes.

Applies to: Windows Server 2012 R2

Original KB number: 945058

） Important

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, click the following article number to view the
article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

Symptoms
When you use the Volume Shadow Copy Service in Windows Server based computers
that run many I/O operations and that have lots of data, you experience the following
symptoms:

Cluster failover time is longer for the cluster groups that contain disk resources for
which you have enabled the Volume Shadow Copy Service. Also, the disk volumes
of the cluster nodes take longer to go online and offline during a cluster failover.
Taking a disk offline and then online on the same node also has the same delay.

Non-cluster servers take longer to start. When you disable the Volume Shadow
Copy Service on the server volumes, the servers start as expected.

Cause
This issue occurs because of the way the Volume Shadow Copy driver (Volsnap.sys)
manages the shadow copy files. If lots of shadow copy files are created on the disk
volumes, the Volume Shadow Copy driver takes more time to process those shadow
copy files when the system brings the disk volumes online.

Workaround

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft cannot guarantee that these problems can
be solved. Modify the registry at your own risk.

To work around this issue, create a new registry key to restrict the number of shadow
copy files that are created on each disk volume to 20.

７ Note

This value is only a suggested starting value. We recommend that you find a value
that is appropriate for your working environment.

To create the new registry key, follow these steps:

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings

3. Point to New, and then click DWORD Value.

4. Type MaxShadowCopies, and then press ENTER.
5. Double-click MaxShadowCopies, type 20 in the Value data box, and then click OK.
6. Exit Registry Editor.
7. Restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Various issues may occur on a Windows
Server 2003-based computer that's
running the Volume Shadow Copy
Service
Article • 12/26/2023

This article describes issues in which Event ID 8019, 20, 8193, or 12302 is logged in the
Application log. You receive an Error 0x8004230F or 0x80004002 error message.

Applies to: Windows Server 2003

Original KB number: 940032

Symptoms
On a Microsoft Windows Server 2003-based computer that is running the Volume
Shadow Copy Service (VSS), you experience one of the following symptoms:

When you perform a backup operation by using the NTBackup tool, the following
event is logged in the Application log:

Event Type: Error

Event Source: NTBackup
Event ID: 8019
Description: End Operation: Warnings or errors were encountered. Consult the
backup report for more details.

７ Note

If you view the backup log file, the following information is displayed:

Error returned while creating the volume shadow copy:0xffffffff

If you access the properties of a volume and then click Shadow Copies, you receive
one of the following error messages:

Error 0x8004230F: The shadow copy provider had an unexpected error while
trying to process the specified operation.
 Error 0x80004002: No such interface supported

One of the following events is logged in the Application log:

Event Type: Error

Event Source: VSS
Event ID: 20
Description: Volume Shadow Copy Service error: A critical component required
by the Volume Shadow Copy Service is not registered. This might happened if
an error occurred during Windows setup or during installation of a Shadow
Copy provider. The error returned from CoCreateInstance on class with CLSID
{faf53cc4-bd73-4e36-83f1-2b23f46e513e} and Name VSSEvent is
[0x80040154].

Event Type: Error

Event Source: VSS
Event ID: 20
Description: Volume Shadow Copy Service error: A critical component required
by the Volume Shadow Copy Service is not registered. This might happened if
an error occurred during Windows setup or during installation of a Shadow
Copy provider. The error returned from CoCreateInstance on class with CLSID
{faf53cc4-bd73-4e36-83f1-2b23f46e513e} and Name VSSEvent is
[0x80004002].

Event Type: Error

Event Source: VSS
Event ID: 8193
Description: Volume Shadow Copy Service error: Unexpected error calling
routine CoCreateInstance. hr = 0x80040154.

Event Type: Error

Event Source: VSS
Event Category: None
Event ID: 8193
Description: Volume Shadow Copy Service error: Unexpected error calling
routine CoCreateInstance. hr = 0x80004002.

Event Type: Error

Event Source: VSS
Event ID: 12302
Description: Volume Shadow Copy Service error: An internal inconsistency was
detected in trying to contact shadow copy service writers. Please check to see
 that the Event Service and Volume Shadow Copy Service are operating
properly.

Cause
This issue occurs because the VSS system files aren't registered.

Resolution

７ Note

This article isn't for use with Windows Vista, with Windows Server 2008, or with
later operating systems. Starting with Windows Vista and with Windows Server
2008, Windows component installation is manifest based. If you try to manually
register specific components, such as those that are described in this "Resolution"
section, in the operating systems that are mentioned in this note, unexpected
results may occur that may require reinstalling Windows to resolve.

To resolve this issue, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. Type the following commands at a command prompt. Press ENTER after you type
each command.

cd /d %windir%\system32

Net stop vss

Net stop swprv

regsvr32 ole32.dll
regsvr32 oleaut32.dll

regsvr32 vss_ps.dll

vssvc /register
regsvr32 /i swprv.dll

regsvr32 /i eventcls.dll
regsvr32 es.dll

regsvr32 stdprov.dll

regsvr32 vssui.dll
regsvr32 msxml.dll

regsvr32 msxml3.dll
 regsvr32 msxml4.dll

７ Note

The last command may not run successfully.

3. Perform a backup operation to verify that the issue is resolved.

More information

Steps to reproduce this issue

1. Type the following command at a command prompt. Press ENTER after you type
the command.

Console

regsvr32 /u swprv.dll

2. Try to perform a backup operation.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

VSS event ID 8193 is logged when you
restart the Cryptographic Services
service after you install the DHCP role
on a computer
Article • 12/26/2023

This article describes an issue where you receive event ID 8193 when you restart the
Cryptographic Services service if the DHCP role has installed.

Applies to: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Original KB number: 2298620

Symptoms
You install the DHCP role on a computer. When you restart the Cryptographic Services
service, the following event is logged in the Application log:

Log Name: Application

Source: VSS
Date: Date/Time
Event ID: 8193
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
Volume Shadow Copy Service error: Unexpected error calling routine
RegOpenKeyExW(-147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...). hr =
0x80070005, Access is denied.

Operation:
Initializing Writer

Context:
Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Name: System Writer
Writer Instance ID: {7bb41431-3960-44bc-a29c-3b42d2301fc3}
 ７ Note

Although this event is recorded, Volume Shadow Copy and DHCP Server continue
to function as expected. Although this event is logged as an error, the event should
not be considered a critical failure that affects the correct functioning of VSS. The
registry key is mentioned for diagnostic purposes.

Cause
When the DHCP server role is installed, the permissions of the following registry key
(and all subkeys) are overwritten when the DHCP Service account is added:

HKLM\CurrentControlSet\Services\VSS\Diag

When this occurs, the Network Service account is removed.

Every time that the Cryptographic Services service is started, it initializes "System Writer"
under the Network Service account and verifies read/write permission for the following
registry key:

HKLM\CurrentControlSet\Services\VSS\Diag

Because the Network Service account is used to obtain access to this key, there's no
permission for the Network Service. Therefore, VSS logs an "Access denied" event.

Resolution
Volume shadow copy and DHCP server continue to function as expected, so you can
ignore the event.

If you need to avoid the event, do following steps:

1. Run PowerShell as an administrator.

2. Run the following command. Be careful not to include a new line in the middle of

PowerShell

$path = 'HKLM:\System\CurrentControlSet\Services\VSS\Diag\'

$sddl = 'D:PAI(A;;KA;;;BA)(A;;KA;;;SY)(A;;CCDCLCSWRPSDRC;;;BO)
(A;;CCDCLCSWRPSDRC;;;LS)(A;;CCDCLCSWRPSDRC;;;NS)(A;CIIO;RC;;;OW)
(A;;KR;;;BU)(A;CIIO;GR;;;BU)(A;CIIO;GA;;;BA)(A;CIIO;GA;;;BO)
(A;CIIO;GA;;;LS)(A;CIIO;GA;;;NS)(A;CIIO;GA;;;SY)(A;CI;CCDCLCSW;;;S-1-5-
 80-3273805168-4048181553-3172130058-210131473-390205191)(A;ID;KR;;;AC)
(A;CIIOID;GR;;;AC)S:ARAI'

$acl = Get-Acl -Path $Path

$acl.SetSecurityDescriptorSddlForm($sddl)

Set-Acl -Path $Path -AclObject $acl

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You may get VSS warnings in the
Application Event log of SBS 2011
Standard
Article • 12/26/2023

This article provides a workaround for an issue where you get VSS warnings in the
Application Event log of Microsoft Windows Small Business Server 2011 Standard.

Applies to: Windows Server 2012 R2

Original KB number: 2537096

Symptoms
In Small Business Server 2011 Standard, you may see warnings in the application event
log that's similar to the following:

Log Name: Application

Source: VSS
Date: <DateTime>
Event ID: 8230
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: CONTOSOSERVER.contoso.local
Description:
Volume Shadow Copy Service error: Failed resolving account spsearch with status
1376. Check connection to domain controller and VssAccessControl registry key.

The warnings may also reference the spfarm account.

Cause
SBS 2011 Standard Edition installs SharePoint 2010 Foundation in SharePoint farm
mode. The accounts SharePoint farm and SharePoint search are used as service accounts
for some of the SharePoint services. In order to be able to utilize the VSS writers, the
accounts must be granted access to VSS. The accounts are added by SBS to the
VssAccessControl registry key but the VSS service fails to locate the accounts. You can
ignore the warnings. The warnings don't affect the operation of VSS. If you wish to
remove the warnings, you can use the steps in the resolution section.

Workaround
Use the following steps to work around the issue.

1. In Active Directory Users and Computers, create a Domain Local Security Group
named VSSRegistryGroup.

2. Add SPFARM and SPSEARCH accounts to the VSSRegistryGroup Group.

3. Run regedit.

） Important

This article contains information about how to modify the registry. Make sure
that you back up the registry before you modify it. Make sure that you know
how to restore the registry if a problem occurs. For more information about
how to back up, restore, and modify the registry, see How to back up and
restore the registry in Windows .

4. Go to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\VssAccessControl .

5. Add DWORD value of DOMAIN\vssregistrygroup where domain is the netbios

domainname (for example, CONTOSO\vssregistrygroup. The Domain name must
be in all caps) set the value to 1

6. Remove values for domain\spsearch and domain\spfarm.

7. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\diag .

8. Right-click diag and go permissions, click Advanced and add VSSRegistrygroup

group with Full Control.

9. Remove spsearch and spfarm accounts from the list of permissions.

10. Reboot the server.

More information
If the VSSAccessControl registry key does not contain the exact right accounts, the
service Sharepoint 2011 VSS Writer will fail to start and the following error will be
logged in the application event log:

Log Name: Application

Source: VSS
Date: <DateTime>
Event ID: 8213
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CONTOSOSERVER.contoso.local
Description:
Volume Shadow Copy Service error: The process that hosts the writer with name
SharePoint Services Writer and ID {da452614-4858-5e53-a512-38aab25c61ad} does
not run under a user with sufficient access rights. Consider running this process
under a local account which is either Local System, Administrator, Network Service,
or Local Service.

Operation: Initializing Writer

Context:
Writer Class Id: {da452614-4858-5e53-a512-38aab25c61ad}
Writer Name: SharePoint Services Writer

Feedback
Was this page helpful?  Yes  No

Provide product feedback

VSS writers report as failed on a virtual
machine
Article • 12/26/2023

This article provides some information about VSS writers report as failed on a virtual
machine.

Applies to: Windows Server 2012 R2

Original KB number: 2952783

Symptoms
Consider the following scenario:

You have a Windows Server 2012 R2 -based computer with the Hyper-V role.
You run a Windows Server 2003-based or a Windows Server 2008-based virtual
machine.
You try to back up the virtual machine by using a backup application from the
Hyper-V Host.

In this scenario, the Volume Shadow Copy Service (VSS) writers on Windows Server 2003
or Windows Server 2008 report as failed. The output if you run the vssadmin list writers
command is as follows:

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool

(C) Copyright 2001 Microsoft Corp.

Writer name: 'System Writer'

Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Instance Id: {0df8b3f5-59ee-4185-983c-f35f16488e17}
State: [9] Failed
Last error: No error

Writer name: 'COM+ REGDB Writer'

Writer Id: {542da469-d3e1-473c-9f4f-7847f01fc64f}
Writer Instance Id: {4a28f97d-5076-4171-b9ac-a0cabd925645}
State: [9] Failed
Last error: No error
 Writer name: 'MSDEWriter'
Writer Id: {f8544ac1-0611-4fa5-b04b-f7ee00b03277}
Writer Instance Id: {ecabb5e5-6526-42b4-b008-e74a7ce9edaa}
State: [1] Stable
Last error: No error

Writer name: 'Registry Writer'

Writer Id: {afbab4a2-367d-4d15-a586-71dbb18f8485}
Writer Instance Id: {5ee9aebb-1d30-474d-9562-927ba40e2e4e}
State: [9] Failed
Last error: No error

Writer name: 'WMI Writer'

Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {0fe76f97-9185-4bb8-b9da-6ce35be4bc01}
State: [9] Failed
Last error: No error

Writer name: 'Event Log Writer'

Writer Id: {eee8c692-67ed-4250-8d86-390603070d00}
Writer Instance Id: {8a2fd6b9-c349-4d3f-9bc2-046e053bee65}
State: [9] Failed
Last error: No error

７ Note

The Hyper-V writer on the Window Server 2012 R2 host reports the backup as
succeeding.
The VSS infrastructure uses the Microsoft Hyper-V VSS requestor to create a
snapshot in the virtual machine.
The VSS infrastructure uses the Microsoft Hyper-V VSS writer to create a
snapshot on the Hyper-V host.

Cause
This behavior is expected. This behavior exists because of limitations in Windows Server
2003 and Windows Server 2008 that restrict the ability to expose a shadow disk to the
operating system as required for the VSS autorecovery phase to finish.

Because of these limitations, the Hyper-V requester that is running on Windows Server
2003 or Windows Server 2008 stops the VSS backup process following the OnThaw
phase in order to skip the autorecovery portion. This results in the guest writers
reporting failure. Before aborting the backup process the virtual machine's state is
preserved. This is then used to provide constant backup for the application.

More information
The VSS writers on the Windows Server 2003 or Windows Server 2008 guest report as
failed as long as the Hyper-V writer on the Windows Server 2012 R2 host reports that
the backup was successful.

The following will be unaffected by this status:

Restore operations or later backup requests of the virtual machine though the
Hyper-V writer on the host
Back up requests from the virtual machine that use other backup techniques such
as a System State Backup together with Windows Backup

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Certification Authority configuration to
publish certificates in Active Directory
of trusted domain
Article • 03/27/2024

This article solves the issue where the issued certificate isn't published in Active
Directory when users from a child domain as a certification authority (CA) request a
certificate.

Applies to: All supported versions of Windows Server

Original KB number: 281271

Symptoms
In the following scenarios, if a user from the same domain as a CA requests a certificate,
the issued certificate is published in Active Directory. If the user is from a child domain,
this process isn't successful. Also, when users from the same domain as a CA request a
certificate, the issued certificate may not be published in Active Directory.

Scenario 1
In this scenario, the CA doesn't publish issued certificates to the user's DS object in the
child domain when the following conditions are true:

The user is in a two-level domain hierarchy with a parent and a child domain.
The Enterprise CA is located on the parent domain and the user is in the child
domain.
The user in the child domain enrolls in the parent CA.

In a two-level domain hierarchy with a parent and a child domain, the Enterprise CA is
located in the parent domain. And the users are in the child domain. The users in the
child domain enroll in the parent CA, and the CA publishes issued certificates to the
user's DS object in the child domain.

Additionally, the following event is logged on the CA server:

Log Name: Application

Source: Microsoft-Windows-CertificationAuthority
Event ID: 80
 Task Category: None
Level: Warning
Keywords:
User: SYSTEM
Computer: CA.CONTOSO.COM
Description:
Active Directory Certificate Services could not publish a Certificate for request XXX
to the following location on server DC.CHILD.CONTOSO.COM:
CN=CHILDSRV,CN=Computers,DC=CHILD,DC=CONTOSO,DC=COM. Insufficient
access rights to perform the operation. 0x80072098 (WIN32: 8344
ERROR_DS_INSUFF_ACCESS_RIGHTS).
ldap: 0x32: 00002098: SecErr: DSID-XXXXXXXX, problem 4003
(INSUFF_ACCESS_RIGHTS), data 0

Scenario 2
Consider the following scenario:

The user is in a single-level domain or a parent domain.

The Enterprise CA is located on the parent domain.
The domain controllers don't have the hotfix 327825 installed.
The user, either in the single-level or parent domain, enrolls in the single-level
certification authority or the parent certification authority.

In this scenario, the certification authority doesn't publish the issued certificates to the
user's domain server object in the single-level domain or in the parent domain.

Cause
For Scenario 1: two-level domain hierarchy

Users from the child domain don't have appropriate permissions to enroll. Even
when they do, the CA doesn't have the access permissions to publish the certificate
to Active Directory.

By default, only domain users from the same domain as the CA have enroll
permissions.

By default, the CA has the following necessary permissions granted on users within
its domain:

Read userCertificate .
 Write userCertificate .

The CA in the parent domain doesn't have permissions to the userCertificate

property on the users in the child domain.

For Scenario 2: single-level domain or parent domain

By default in Windows, the AdminSDHolder object does not grant the Cert
Publishers group the necessary permissions for user accounts that are covered
under the AdminSDHolder process. The following list contains the protected user
account groups in Windows:

Enterprise Admins

Schema Admins

Domain Admins

Administrators

After you apply the hotfix KB327825 , the following list of user account groups
in Windows are now protected user account groups:

Administrators

Account Operators

Server Operators

Print Operators

Backup Operators

Domain Admins

Schema Admins

Enterprise Admins

Cert Publishers

Resolution
Try the following resolution according to your scenario.

For Scenario 1: two-level domain hierarchy

To enable the child domain users to obtain certificates and have them published to
Active Directory, follow these steps:

1. Set the permissions on the CA's template to allow enrollment requests. Set the
user object permissions to allow the CA to publish the certificate. Alter
AdminSDHolder to push the user object permissions to users who are
administrators.

2. Set the user object permissions to allow the CA to publish the certificate. Alter
AdminSDHolder to push the user object permissions to users who are
administrators.

3. Alter AdminSDHolder to push the user object permissions to users who are
administrators.

７ Note

You must first install Support Tools from the Windows Professional, or Windows
Server CD-ROM.

Enable the child domain users to obtain certificates and have them
published to Active Directory
1. Set permissions on the CA to allow users in the child domain to request a
certificate. By default, it should be in place.
a. Open the Certification Authority snap-in, right-click the CA, and then select
Properties.
b. On the Security tab, make sure that the Authenticated Users group is allowed to
request certificates.

2. Set permissions on the applicable certificate templates to allow users in the child
domain to enroll.

７ Note

You must be logged on to the root domain with domain administrator rights.

a. Open the Active Directory Sites and Services snap-in.

b. Select View, and then select Show Services Node.
c. Expand the Services Node folder, expand Public Key Services, and then select
Certificate Templates.
 d. In the Details pane, select the desired template, or templates. For example,
right-click the User certificate template, and then select Properties.
e. On the Security tab, grant enroll permissions to the desired group, such as
Authenticated Users.

3. Configure the CA Exit Module to publish certificates to Active Directory.

a. In the Certification Authority snap-in, right-click the CA, and then select
Properties.
b. On the Exit Module tab, select Configure.
c. In the properties for the Exit Module, select the Allow certificates to be
published in the Active Directory box.

On the child domain controller:

７ Note

In Windows Server domains, the Cert Publishers group is a Domain Global

group. You must manually add the Cert Publishers group to each child
domain.

You can enable the child domain users to obtain certificates and to have them
published in Windows Server domains. To do so, change the group type to
Domain Local, and include the CA server from the parent domain. This procedure
creates the same configuration that is present in a freshly installed Windows Server
domain. The user interface (UI) does not let you change the group type. However,
you can use the dsmod command to change the Cert Publishers group from a
Domain Global group to a Domain Local group:

Console

dsmod group Group Distinguished Name -scope l

In some cases, you cannot change groupType directly from global to domain local
group. In this case, you have to change the global group into a universal group
and change the universal group into a domain local group. To do so, follow these
steps:

a. Type the following command, and then press ENTER:

Console

dsmod group Group Distinguished Name -scope u

 This command changes the global group into a universal group.

b. Type the following command, and then press ENTER:

Console

dsmod group Group Distinguished Name -scope l

This command changes the universal group into a domain local group.

For Scenario 2: single-level domain or parent domain

On the single-level domain controller or on the parent domain controller, run the
following two commands, keeping the quotation marks:

Console

dsacls "cn=adminsdholder,cn=system, dc=<your domain>,dc=<com>" /G "<CA's

domain> \Cert Publishers:WP;userCertificate"
dsacls "cn=adminsdholder,cn=system, dc=<your domain>,dc=<com>" /G "<CA's
domain> \Cert Publishers:RP;userCertificate"

Where dc=<your domain>,dc=<com> is the distinguished name (DN) of your child

domain. Where <CA's domain> is the domain name that the CA is located.

Status
Microsoft has confirmed that it's a problem in Windows Server.

More information
When a user from a child domain doesn't succeed in enrolling, the following error is
generated in the CA application event log:

Event Type: Warning

Event Source: CertSvc
Event Category: None
Event ID: 53
Date: 08/14/2000
Time: 05:13:00
User: N/A
Computer: <Root CA name>
 Description:
Certificate Services denied request <request #> because Access is denied.
0x80070005 (WIN32: 5). The request was for (Unknown Subject). Additional
information: Denied by Policy Module

If the ACLs are set so that the user can enroll, but the CA doesn't have permissions to
publish to the user's Active Directory, the following error is generated in the CA
application event log:

Event Type: Error

Event Source: CertSvc
Event Category: None
Event ID: 46
Date: 08/14/2000
Time: 05:13:00
User: N/A
Computer: <Root CA name>
Description:
The "Enterprise and Stand-alone Exit Module" Exit Module "Notify" method returned
an error. Access is denied. The returned status code is 0x80070005 (5). The
Certification Authority was unable to publish the certificate for Child\User to the
Directory Service. Access is denied.
(0x80070005)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to decommission a Windows
enterprise certification authority and
remove all related objects
Article • 02/26/2024

This step-by-step article describes how to decommission a Microsoft Windows

enterprise CA, and how to remove all related objects from the Active Directory directory
service.

Applies to: Windows Server

Original KB number: 889250

Summary
When you uninstall a certification authority (CA), the certificates that were issued by the
CA are typically still outstanding. If the outstanding certificates are processed by the
various Public Key Infrastructure client computers, validation will fail, and those
certificates will not be used.

This article describes how to revoke outstanding certificates and how to complete
various other tasks that are required to successfully uninstall a CA. Additionally, this
article describes several utilities that you can use to help you remove CA objects from
your domain.

Step 1 - Revoke all active certificates that are

issued by the enterprise CA
1. Select Start, point to Administrative Tools, and then select Certification Authority.
2. Expand your CA, and then select the Issued Certificates folder.
3. In the right pane, select one of the issued certificates, and then press CTRL+A to
select all issued certificates.
4. Right-click the selected certificates, select All Tasks, and then select Revoke
Certificate.
5. In the Certificate Revocation dialog box, select Cease of Operation as the reason
for revocation, and then select OK.

Step 2 - Increase the CRL publication interval

 1. In the Certification Authority Microsoft Management Console (MMC) snap-in,
right-click the Revoked Certificates folder, and then select Properties.
2. In the CRL Publication Interval box, type a suitably long value, and then select OK.

７ Note

The lifetime of the Certificate Revocation List (CRL) should be longer than the
lifetime that remains for certificates that have been revoked.

Step 3 - Publish a new CRL

1. In the Certification Authority MMC snap-in, right-click the Revoked Certificates
folder.
2. Select All Tasks, and then select Publish.
3. In the Publish CRL dialog box, select New CRL, and then select OK.

Step 4 - Deny any pending requests

By default, an enterprise CA does not store certificate requests. However, an
administrator can change this default behavior. To deny any pending certificate
requests, follow these steps:

1. In the Certification Authority MMC snap-in, select the Pending Requests folder.
2. In the right pane, select one of the pending requests, and then press CTRL+A to
select all pending certificates.
3. Right-click the selected requests, select All Tasks, and then select Deny Request.

Step 5 - Uninstall Certificate Services from the

server
1. To stop Certificate Services, select Start, select Run, type cmd, and then select OK.

2. At the command prompt, type certutil -shutdown, and then press Enter.

3. At the command prompt, type certutil -getreg CA\CSP\Provider, and then press
Enter. Note the Provider value in the output. For example:

Output

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configurat
ion\Fabrikam Root CA1 G2\csp:
 Provider REG_SZ = Microsoft Software Key Storage Provider
CertUtil: -getreg command completed successfully.

If the value is Microsoft Strong Cryptographic Provider, or Microsoft Enhanced

Cryptographic Provider v1.0, type CertUtil -Key and press Enter.
If the value is Microsoft Software Key Storage Provider, type CertUtil -CSP KSP -
Key and press Enter.
If the value is something else, type CertUtil -CSP <PROVIDER NAME> -Key and
press Enter.

This command will display the names of all the installed cryptographic service
providers (CSP) and the key stores that are associated with each provider. Listed
among the listed key stores will be the name of your CA. The name will be listed
several times, as shown in the following example:

(1)Microsoft Base Cryptographic Provider v1.0:

1a3b2f44-2540-408b-8867-51bd6b6ed413
MS IIS DCOM ClientSYSTEMS-1-5-18
MS IIS DCOM Server
Windows2000 Enterprise Root CA
MS IIS DCOM ClientAdministratorS-1-5-21-436374069-839522115-
1060284298-500

afd1bc0a-a93c-4a31-8056-c0b9ca632896
Microsoft Internet Information Server
NetMon
MS IIS DCOM ClientAdministratorS-1-5-21-842925246-1715567821-
839522115-500

(5)Microsoft Enhanced Cryptographic Provider v1.0:

1a3b2f44-2540-408b-8867-51bd6b6ed413
MS IIS DCOM ClientSYSTEMS-1-5-18
MS IIS DCOM Server
Windows2000 Enterprise Root CA
MS IIS DCOM ClientAdministratorS-1-5-21-436374069-839522115-
1060284298-500

afd1bc0a-a93c-4a31-8056-c0b9ca632896
Microsoft Internet Information Server
NetMon
MS IIS DCOM ClientAdministratorS-1-5-21-842925246-1715567821-
839522115-500
4. Delete the private key that is associated with the CA. To do this, at a command
prompt, type the following command, and then press Enter:

Console

certutil -delkey CertificateAuthorityName

７ Note

If your CA name contains spaces, enclose the name in quotation marks.

In this example, the certificate authority name is Windows2000 Enterprise Root

CA. Therefore, the command line in this example is as follows:

Console

certutil -delkey "Windows2000 Enterprise Root CA"

5. List the key stores again to verify that the private key for your CA was deleted.

6. After you delete the private key for your CA, uninstall Certificate Services. To do
this, follow these steps, depending on the version of Windows Server that you are
running.

If you are uninstalling an enterprise CA, membership in Enterprise Admins, or the

equivalent, is the minimum that is required to complete this procedure. For more
information, see Implement Role-Based Administration.

To uninstall a CA, follow these steps:

a. Select Start, point to Administrative Tools, and then select Server Manager.
b. Under Roles Summary, select Remove Roles to start the Remove Roles Wizard,
and then select Next.
c. Select to clear the Active Directory Certificate Services check box, and then
select Next.
d. On the Confirm Removal Options page, review the information, and then select
Remove.
e. If Internet Information Services (IIS) is running and you are prompted to stop
the service before you continue with the uninstall process, select OK.
f. After the Remove Roles Wizard is finished, restart the server. This completes the
uninstall process.
The procedure is slightly different if you have multiple Active Directory Certificate
Services (AD CS) role services installed on a single server. To uninstall a CA but
keep other AD CS role services, follow these steps.

７ Note

You must log on with the same permissions as the user who installed the CA
to complete this procedure. If you are uninstalling an enterprise CA,
membership in Enterprise Admins, or the equivalent, is the minimum that is
required to complete this procedure. For more information, see Implement
Role-Based Administration.

a. Select Start, point to Administrative Tools, and then select Server Manager.
b. Under Roles Summary, select Active Directory Certificate Services.
c. Under Roles Services, select Remove Role Services.
d. Select to clear the Certification Authority check box, and then select Next.
e. On the Confirm Removal Options page, review the information, and then select
Remove.
f. If IIS is running and you are prompted to stop the service before you continue
with the uninstall process, select OK.
g. After the Remove Roles Wizard is finished, you must restart the server. This
completes the uninstall process.

If the remaining role services, such as the Online Responder service, were
configured to use data from the uninstalled CA, you must reconfigure these
services to support a different CA. After a CA is uninstalled, the following
information is left on the server:

The CA database.
The CA public and private keys.
The CA's certificates in the Personal store.
The CA's certificates in the shared folder, if a shared folder was specified
during AD CS setup.
The CA chain's root certificate in the Trusted Root Certification Authorities
store.
The CA chain's intermediate certificates in the Intermediate Certification
Authorities store.
The CA's CRL.

By default, this information is kept on the server in case you are uninstalling and
then reinstalling the CA. For example, you might uninstall and reinstall the CA if
you want to change a stand-alone CA to an enterprise CA.
Step 6 - Remove CA objects from Active
Directory
When Microsoft Certificate Services is installed on a server that is a member of a
domain, several objects are created in the configuration container in Active Directory.

These objects are as follows:

certificateAuthority object
Located in CN=AIA,CN=Public Key
Services,CN=Services,CN=Configuration,DC=ForestRootDomain.
Contains the CA certificate for the CA.
Published Authority Information Access (AIA) location.

crlDistributionPoint object
Located in CN=ServerName,CN=CDP,CN=Public Key
Service,CN=Services,CN=Configuration,DC=ForestRoot,DC=com.
Contains the CRL periodically published by the CA.
Published CRL Distribution Point (CDP) location.

certificationAuthority object
Located in CN=Certification Authorities,CN=Public Key
Services,CN=Services,CN=Configuration,DC=ForestRoot,DC=com.
Contains the CA certificate for the CA.

pKIEnrollmentService object
Located in CN=Enrollment Services,CN=Public Key
Services,CN=Services,CN=Configuration,DC=ForestRoot,DC=com.
Created by the enterprise CA.
Contains information about the types of certificates the CA has been configured
to issue. Permissions on this object can control which security principals can
enroll against this CA.

When the CA is uninstalled, only the pKIEnrollmentService object is removed. This

prevents clients from trying to enroll against the decommissioned CA. The other objects
are retained because certificates that are issued by the CA are probably still outstanding.
These certificates must be revoked by following the procedure in the Step 1 - Revoke all
active certificates that are issued by the enterprise CA section.

For Public Key Infrastructure (PKI) client computers to successfully process these
outstanding certificates, the computers must locate the Authority Information Access
(AIA) and CRL distribution point paths in Active Directory. It is a good idea to revoke all
outstanding certificates, extend the lifetime of the CRL, and publish the CRL in Active
Directory. If the outstanding certificates are processed by the various PKI clients,
validation will fail, and those certificates will not be used.

If it is not a priority to maintain the CRL distribution point and AIA in Active Directory,
you can remove these objects. Do not remove these objects if you expect to process
one or more of the formerly active digital certificates.

Remove all Certification Services objects from Active

Directory

７ Note

You should not remove certificate templates from Active Directory until after you
remove all CA objects in the Active Directory forest.

To remove all Certification Services objects from Active Directory, follow these steps:

1. Determine the CACommonName of the CA. To do this, follow these steps:

a. Select Start, select Run, type cmd in the Open box, and then select OK.
b. Type certutil, and then press ENTER.
c. Make a note of the Name value that belongs to your CA. You will need the
CACommonName for later steps in this procedure.

2. Select Start, point to Administrative Tools, and then select Active Directory Sites
and Services.

3. On the View menu, select Show Services Node.

4. Expand Services, expand Public Key Services, and then select the AIA folder.

5. In the right pane, right-click the CertificationAuthority object for your CA, select
Delete, and then select Yes.

6. In the left pane of the Active Directory Sites and Services MMC snap-in, select the
CDP folder.

7. In the right pane, locate the container object for the server where Certificate
Services is installed. Right-click the container, select Delete, and then select Yes
two times.

8. In the left pane of the Active Directory Sites and Services MMC snap-in, select the
Certification Authorities node.
 9. In the right pane, right-click the CertificationAuthority object for your CA, select
Delete, and then select Yes.

10. In the left pane of the Active Directory Sites and Services MMC snap-in, select the
Enrollment Services node.

11. In the right pane, verify that the pKIEnrollmentService object for your CA was
removed when Certificate Services was uninstalled. If the object is not deleted,
right-click the object, select Delete, and then select Yes.

12. If you did not locate all the objects, some objects may be left in the Active
Directory after you perform these steps. To clean up after a CA that may have left
objects in Active Directory, follow these steps to determine whether any AD
objects remain:

a. Type the following command at a command line, and then press ENTER:

Console

ldifde -r "cn= CACommonName" -d "CN=Public Key

Services,CN=Services,CN=Configuration,DC= ForestRoot,DC=com" -f
output.ldf

In this command, CACommonName represents the Name value that you

determined in step 1. For example, if the Name value is CA1 Contoso, type the
following:

Console

ldifde -r "cn=CA1 Contoso" -d "cn=public key

services,cn=services,cn=configuration,dc=contoso,dc=com" -f
remainingCAobjects.ldf

b. Open the remainingCAobjects.ldf file in Notepad. Replace the term changetype:

add with changetype: delete. Then, verify whether the Active Directory objects
that you will delete are legitimate.

c. At a command prompt, type the following command, and then press ENTER to
delete the remaining CA objects from Active Directory:

Console

ldifde -i -f remainingCAobjects.ldf
 13. Delete the certificate templates if you are sure that all of the certificate authorities
have been deleted. Repeat step 12 to determine whether any AD objects remain.

） Important

You must not delete the certificate templates unless all the certificate
authorities have been deleted. If the templates are accidentally deleted, follow
these steps:

a. Make sure that you are logged on to a server that is running Certificate Services
as Enterprise administrator.

b. At a command prompt, type the following command, and then press ENTER:

Console

cd %windir%\system32

c. Type the following command, and then press ENTER:

Console

regsvr32 /i:i /n /s certcli.dll

This action re-creates the certificate templates in Active Directory.

To delete the certificate templates, follow these steps.

a. In the left pane of the Active Directory Sites and Services MMC snap-in, select
the Certificate Templates folder.
b. In the right pane, select a certificate template, and then press Ctrl+A to select all
templates. Right-click the selected templates, select Delete, and then select Yes.

Step 7 - Delete certificates published to the

NtAuthCertificates object
After you delete the CA objects, you have to delete the CA certificates that are published
to the NtAuthCertificates object. Use either of the following commands to delete
certificates from within the NTAuthCertificates store:

Console
 certutil -viewdelstore " ldap:///CN=NtAuthCertificates,CN=Public Key
Services,...,DC=ForestRoot,DC=com?cACertificate?base?
objectclass=certificationAuthority"

Console

certutil -viewdelstore " ldap:///CN=NtAuthCertificates,CN=Public Key

Services,...,DC=ForestRoot,DC=com?cACertificate?base?
objectclass=pKIEnrollmentService"

７ Note

You must have Enterprise Administrator permissions to perform this task.

The -viewdelstore action invokes the certificate selection UI on the set of certificates in
the specified attribute. You can view the certificate details. You can cancel out of the
selection dialog to make no changes. If you select a certificate, that certificate is deleted
when the UI closes and the command is fully executed.

Use the following command to see the full LDAP path to the NtAuthCertificates object in
your Active Directory:

Console

certutil -viewdelstore -? | findstr "CN=NTAuth"

Step 8 - Delete the CA database

When Certification Services is uninstalled, the CA database is left intact so that the CA
can be re-created on another server.

To remove the CA database, delete the %systemroot%\System32\Certlog folder.

Step 9 - Clean up domain controllers

After the CA is uninstalled, the certificates that were issued to domain controllers must
be removed.

To remove certificates that were issued to the Windows Server 2000 domain controllers,
use the Dsstore.exe utility from the Microsoft Windows 2000 Resource Kit.
To remove certificates that have been issued to the Windows Server 2000 domain
controllers, follow these steps:

1. Select Start, select Run, type cmd, and then press ENTER.

2. On a domain controller, type dsstore -dcmon at the command prompt, and then
press ENTER.

3. Type 3, and then press ENTER. This action deletes all certificates on all domain
controllers.

７ Note

The Dsstore.exe utility will try to validate domain controller certificates that
are issued to each domain controller. Certificates that do not validate are
removed from their respective domain controller.

To remove certificates that were issued to the Windows Server 2003 domain controllers,
follow these steps.

） Important

Do not use this procedure if you are using certificates that are based on version 1
domain controller templates.

1. Select Start, select Run, type cmd, and then press ENTER.

2. At the command prompt on a domain controller, type certutil -dcinfo deleteBad.

Certutil.exe tries to validate all the DC certificates that are issued to the domain
controllers. Certificates that do not validate are removed.

To force application of the security policy, follow these steps:

1. Select Start, select Run, type cmd in the Open box, and then press ENTER.
2. At a command prompt, type the appropriate command for the corresponding
version of the operating system, and then press ENTER:

For Windows Server 2000:

Console

secedit /refreshpolicy machine_policy /enforce

 For Windows Server 2003:

Console

gpupdate /force

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to expand the maximum extension
size limit at AD CS
Article • 03/19/2024

This article helps to resolve the issue in which Active Directory Certificate Services (AD
CS) gives an error when attempting to issue certificates with more than 4 kilobytes (KB)
size extensions.

Original KB number: 5017242

You may also see this error message in the certsrv logging:

Output

CertSrv: Field length is greater than maximum 0xc80005e2 (ESE: -1506

JET_errColumnTooBig)

７ Note

Certsrv logging helps to determine the cause of the error. For more information on
enabling the certsrv logging, see Certificate Enrollment Web Services in Active
Directory Certificate Services .

Data stored in the custom extension has a limit

of 4 KB
The data stored in the custom extension has a limit of 4 KB, which can be confirmed by
running the following command as an administrator:

Console

certutil -schema Ext

You can see the MaxLength property of ExtensionRawValue in the output:

Output

C:\>certutil -schema Ext

Schema:
Column Name Localized Name Type
 MaxLength
---------------------------- ---------------------------- ------ ------
---
ExtensionRequestId Extension Request ID Long 4 --
Indexed
ExtensionName Extension Name String 254
ExtensionFlags Extension Flags Long 4
ExtensionRawValue Extension Raw Value Binary 4096

CertUtil: -schema command completed successfully.

The limit can be expanded to 16 KB after installing one of the following or subsequent
updates:

Windows Server 2019 - July 21, 2022—KB5015880 (OS Build 17763.3232) Preview
Windows Server 20H2 - July 26, 2022—KB5015878 (OS Builds 19042.1865,
19043.1865, and 19044.1865) Preview
Windows Server 2022 - July 19, 2022—KB5015879 (OS Build 20348.859) Preview

） Important

The next two sections contain instructions to modify the registry. Serious problems
might occur if the registry is modified incorrectly. As a precaution, back up the
registry before you modify it. For more information about how to back up, restore,
and modify the registry, see How to back up and restore the registry in
Windows .

Expand the limit by using Registry Editor

In Registry Editor, add the 0x1000 bitmask to the following registry key. Then, restart AD
CS.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBFlags

７ Note

This setting should be done on all AD CS servers where expansion is required.

Expand the limit by using an administrative

command prompt
Run the following commands to add 0x1000 to the DBFlags registry key value and then
restart AD CS:

Console

certutil -setreg DBFlags +0x1000

net stop certsvc && net start certsvc

７ Note

This setting should be done on all AD CS servers where expansion is required.

This setting causes an irreversible database operation to expand the limit

permanently once the service is restarted.

After the expansion is complete and new backups are captured, you may consider
destroying the old backups to prevent an accidental rollback.

Verify the limit settings

To verify the limit settings, run the following command as an administrator and check
the MaxLength property of ExtensionRawValue in the output:

Output

C:\>certutil -schema Ext

Schema:
Column Name Localized Name Type
MaxLength
---------------------------- ---------------------------- ------ ------
---
ExtensionRequestId Extension Request ID Long 4 --
Indexed
ExtensionName Extension Name String 254
ExtensionFlags Extension Flags Long 4
ExtensionRawValue Extension Raw Value Binary 16384

CertUtil: -schema command completed successfully.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to import third-party certification
authority (CA) certificates into the
Enterprise NTAuth store
Article • 02/26/2024

There are two methods you can use to import the certificates of third-party CAs into the
Enterprise NTAuth store. This process is required if you're using a third-party CA to issue
smart card logon or domain controller certificates. By publishing the CA certificate to
the Enterprise NTAuth store, the Administrator indicates that the CA is trusted to issue
certificates of these types. Windows CAs automatically publish their CA certificates to
this store.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 295663

More information
The NTAuth store is an Active Directory directory service object that is located in the
Configuration container of the forest. The Lightweight Directory Access Protocol (LDAP)
distinguished name is similar to the following example:

CN=NTAuthCertificates,CN=Public Key
Services,CN=Services,CN=Configuration,DC=MyDomain,DC=com

Certificates that are published to the NTAuth store are written to the cACertificate
multiple-valued attribute. There are two supported methods to append a certificate to
this attribute.

Method 1 - Import a certificate by using the PKI

Health Tool
PKI Health Tool (PKIView) is an MMC snap-in component. It displays the status of one or
more Microsoft Windows CAs that comprise a PKI. It's available as part of the Windows
Server 2003 Resource Kit Tools.

PKIView gathers information about the CA certificates and certificate revocation lists
(CRLs) from each CA in the enterprise. Then it validates the certificates and CRLs to
ensure that they're working correctly. If they aren't working correctly, or they're about to
fail, PKIView provides a detailed warning or some error information.

PKIView displays the status of Windows Server 2003 CAs that are installed in an Active
Directory forest. You can use PKIView to discover all PKI components, including
subordinate and root CAs that are associated with an enterprise CA. The tool can also
manage important PKI containers, such as root CA trust and NTAuth stores, that are also
contained in the configuration partition of an Active Directory forest. This article
discusses this latter functionality. For more information about PKIView, see the Microsoft
Windows Server 2003 Resource Kit Tools documentation.

７ Note

You can use PKIView to manage both Windows 2000 CAs and Windows Server 2003
CAs. To install the Windows Server 2003 Resource Kit Tools, your computer must be
running Windows XP or later.

To import a CA certificate into the Enterprise NTAuth store, follow these steps:

1. Export the certificate of the CA to a .cer file. The following file formats are
supported:

DER encoded binary X.509 (.cer)

Base-64 encoded X.509 (.cer)

2. Install the Windows Server 2003 Resource Kit Tools. The tools package requires
Windows XP or later.

3. Start Microsoft Management Console (Mmc.exe), and then add the PKI Health
snap-in:
a. On the Console menu, select Add/Remove Snap-in.
b. Select the Standalone tab, and then select the Add button.
c. In the list of snap-ins, select Enterprise PKI.
d. Select Add, and then select Close.
e. Select OK.

4. Right-click Enterprise PKI, and then select Manage AD Containers.

5. Select the NTAuthCertificates tab, and then select Add.

6. On the File menu, select Open.

7. Locate and then select the CA certificate, and then select OK to complete the
import.
Method 2 - Import a certificate by using
Certutil.exe
Certutil.exe is a command-line utility for managing a Windows CA. In Windows Server
2003, you can use Certutil.exe to publish certificates to Active Directory. Certutil.exe is
installed with Windows Server 2003. It is also available as part of the Microsoft Windows
Server 2003 Administration Tools Pack.

To import a CA certificate into the Enterprise NTAuth store, follow these steps:

1. Export the certificate of the CA to a .cer file. The following file formats are
supported:

DER encoded binary X.509 (.cer)

Base-64 encoded X.509 (.cer)

2. At a command prompt, type the following command, and then press ENTER:

Console

certutil -dspublish -f filename NTAuthCA

The contents of the NTAuth store are cached in the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

This registry key should be automatically updated to reflect the certificates that are
published to the NTAuth store in the Active Directory configuration container. This
behavior occurs when Group Policy settings are updated and when the client-side
extension that's responsible for autoenrollment executes. In certain scenarios, such as
Active Directory replication latency or when the Do not enroll certificates automatically
policy setting is enabled, the registry isn't updated. In such scenarios, run the following
command manually to insert the certificate into the registry location:

Console

certutil -enterprise -addstore NTAuth CA_CertFilename.cer

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Superseded Certificate Templates and
impact on user's AD store
Article • 02/26/2024

This article provides a resolution for the issue superseded Certificate Templates and
impact on user's AD store.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 2884551

Symptoms
The deletion of certificates, based on the certificate templates being superseded by
other certificate templates, from user's AD store worked in XP/W2k3 as part of the
autoenrollment.
Repro Steps (Vista and later):

1. Configure user autoenrollment policy (make sure that policy is enabled and both
check boxes are check in the autoenrollement configuration window.
2. Duplicate User certificate template (name it for example TestTemplate1), make sure
that the certificate publishing in AD is activated and assign to the test user read,
enroll, and autoenroll permissions on the template.
3. Publish the TestTemplate1 template on the CA.
4. Log on as test user and make sure that the user gets the certificate based on the
template TestTemplate1 over autoenrollment.
5. Configure new certificate template by duplicating TestTemplate1 (name it for
example TestTemplate2), set in the superseeded tab that TestTemplate2 superseeds
the TestTemplate1, make sure that the certificate publishing in AD is activated and
double check that test user has Read, Enroll, and Autoenroll permissions set for
TestTemplate2.
6. Publish the TestTemplate2 template on the CA.
7. Log on as test user and check that the user gets certificate based on the new
template TestTemplate2 over autoenrollment.
8. On the DC, open dsa.msc, find the test user, open the properties and there will be
two certificates published in AD, one based on TestTemplate1 and the other based
on TestTemplate2 (on XP/W2k3 there would be only one, since the certificate
based on the template being superseded, TestTemplate1, would have been
deleted).
Cause
This feature has been removed in Vista and subsequent Windows versions.

Resolution
Workaround is to delete all certs issued by a specific template: For a V1 template:
certutil -delstore -user ldap: InternalTemplateName For a V2 or later template: certutil -
delstore -user ldap: TemplateOID InternalTemplateName is the non-localized template
name (the CN of the template object in AD). Above command will delete all certs from
DS store, issued using a specific template.

More information
The code change was made during Windows Vista/2008 time frame in order to address
issues raised after certificate roaming feature has been introduced (for example, an end
certificate can be created with an unknown CSP on a different machine and roam using
credential roaming, or the issuing CA of a RSA-based certificate that roamed has an
unknown signature algorithm -> both scenarios will result by the end certificate being
removed from AD, even if it is valid).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Certificate used by Wired or Wireless
Network policies is missing in GPO
settings report
Article • 02/26/2024

This article provides a solution to an issue that certificate used by Wired or Wireless
Network policies is missing in GPO settings report.

Applies to: Windows 10 - all editions, Windows Server 2016, Windows Server 2019,
Windows Server 2012 R2
Original KB number: 4047738

Symptoms
Consider the following scenario:

You configure one of the following policies of a group policy object (GPO) to use
the Microsoft: Smart Card or other certificate authentication method:
Wired Network (IEEE 802.3)
Wireless Network (IEEE 802.11)

You specify a root certification authority (CA) certificate to be used by the

authentication.

The certificate has a single subject name.

In this scenario, the certificate is missing in the GPO settings report.

Example settings and screenshots:

You set the following CA certificates to be used by the authentication:

The first certificate has multiple subject names:

CN = Contoso OneAD Root CA

DC = contoso
DC = com
The second certificate has a single subject name:

CN = Contoso OneAD Root CA2

In this example, the GPO settings report displays only the first certificate. The second
certificate is missing.

Cause
The issue occurs because of a code defect in Windows.
Status
This issue affects only the GPO settings report. The certificate is successfully used by the
authentication.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Certificate validation fails when a
certificate has multiple trusted
certification paths to root CAs
Article • 02/26/2024

This article provides workarounds for an issue where security certificate that's presented
by a website isn't issued when it has multiple trusted certification paths to root CAs.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2831004

Symptoms
When a user tries to access a secured website, the user receives the following warning
message in the web browser:

There is a problem with this website's security certificate.

The security certificate presented by this website was not issued by a trusted
certificate authority.

After the user clicks Continue to this website (not recommended), the user can access
the secured website.

Cause
This issue occurs because the website certificate has multiple trusted certification paths
on the web server.

For example, assume that the client computer that you're using trusts Root certification
authority (CA) certificate (2). And the web server trusts Root CA certificate (1) and Root
CA certificate (2). Additionally, the certificate has the following two certification paths to
the trusted root CAs on the web server:

1. Certification path 1: Website certificate - Intermediate CA certificate - Root CA

certificate (1)
2. Certification path 2: Website certificate - Intermediate CA certificate - Cross root
CA certificate - Root CA certificate (2)
When the computer finds multiple trusted certification paths during the certificate
validation process, Microsoft CryptoAPI selects the best certification path by calculating
the score of each chain. A score is calculated based on the quality and quantity of the
information that a certificate path can provide. If the scores for the multiple certification
paths are the same, the shortest chain is selected.

When Certification path 1 and Certification path 2 have the same quality score,
CryptoAPI selects the shorter path (Certification path 1) and sends the path to the client.
However, the client computer can verify the certificate only by using the longer
certification path that links to Root CA certificate (2). So the certificate validation fails.

Workaround
To work around this issue, delete or disable the certificate from the certification path
that you don't want to use by following these steps:

1. Log on to the web server as a system administrator.

2. Add the Certificate snap-in to Microsoft Management Console by following these

steps:
a. Click Start > Run, type mmc, and then press Enter.
b. On the File menu, click Add/Remove Snap-in.
c. Select Certificates, click Add, select Computer account, and then click Next.
d. Select Local computer (the computer this console is running on), and then
click Finish.
e. Click OK.

3. Expand Certificates (Local Computer) in the management console, and then locate
the certificate on the certificate path that you don't want to use.

７ Note

If the certificate is a root CA certificate, it is contained in Trusted Root

Certification Authorities. If the certificate is an intermediate CA certificate, it is
contained in Intermediate Certification Authorities.

4. Delete or disable the certificate by using one of the following methods:

To delete a certificate, right-click the certificate, and then click Delete.

To disable a certificate, right-click the certificate, click Properties, select
Disable all purposes for this certificate, and then click OK.
 5. Restart the server if the issue is still occurring.

Additionally, if the Turn off Automatic Root Certificates Update Group Policy setting is
disabled or not configured on the server, the certificate from the certification path that
you don't want to use may be enabled or installed when the next chain building occurs.
To change the Group Policy setting, follow these steps:

1. Click Start > Run, type gpedit.msc, and then press Enter.

2. Expand Computer Configuration > Administrative Templates > System > Internet
Communication Management, and then click Internet Communication settings.

3. Double-click Turn off Automatic Root Certificates Update, select Enabled, and
then click OK.

4. Close the Local Group Policy Editor.

Status
This behavior is by design.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

CryptAcquireContext() use and
troubleshooting
Article • 02/26/2024

This article provides information about when to use specific flags when you call
CryptAcquireContext and the reasons for using these flags.

Applies to: Windows Server 2012 R2

Original KB number: 238187

Summary
Calls to the CryptAcquireContext function can include various flags. It is important to
know when to use these flags. This article provides information on when to use specific
flags when you call CryptAcquireContext and the reasons for using these flags.

More information

Private key operations are not performed

When you are not using a persisted private key, the CRYPT_VERIFYCONTEXT
(0xF0000000) flag can be used when CryptAcquireContext is called. This tells CryptoAPI
to create a key container in memory that will be released when CryptReleaseContext is
called. When this flag is used, the pszContainer parameter must be NULL. The
CRYPT_VERIFYCONTEXT flag can be used in the following scenarios:

You are creating a hash.

You are generating a symmetric key to encrypt or decrypt data.

You are deriving a symmetric key from a hash to encrypt or decrypt data.

You are verifying a signature. It is possible to import a public key from a

PUBLICKEYBLOB or from a certificate by using CryptImportKey or
CryptImportPublicKeyInfo.

You plan to export a symmetric key, but not import it within the crypto context's
lifetime.
 ７ Note

A context can be acquired by using the CRYPT_VERIFYCONTEXT flag if you

only plan to import the public key for the last two scenarios.

You are performing private key operations, but you are not using a persisted
private key that is stored in a key container.

Private key operations are performed

If you plan to perform private key operations, there are many issues that you must
consider.

The best way to acquire a context is to try to open the container. If this attempt fails
with "NTE_BAD_KEYSET", then create the container by using the CRYPT_NEWKEYSET flag.

７ Note

Applications must not use the default key container by passing NULL for the
container name to store private keys. When multiple applications use the same
container, one application can change or destroy the keys that another application
needs to have available. If applications use key containers with a unique name, the
risk is reduced of other applications tampering with keys that are necessary for
proper function.

C++

// Acquire Context of container that is unique to each user.

if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
0))
{
if (GetLastError() == NTE_BAD_KEYSET)
{
if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET))
{
// Error ...
}
}
 }

// Or, acquire Context of container that is shared across the machine.

if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
CRYPT_MACHINE_KEYSET))
{
if (GetLastError() == NTE_BAD_KEYSET)
{
if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET|CRYPT_MACHINE_KEYSET)
{
// Error ...
}
}
}

Using the CRYPT_MACHINE_KEYSET flag

If you are not performing private key operations on a per-user basis and you need
global private key operations, then CRYPT_MACHINE_KEYSET should be used. This
method creates the private/public key pair on a per-computer basis. Some specific
scenarios in which CRYPT_MACHINE_KEYSET should be used are:

You are writing a service.

Your component is running under an Active Server Pages (ASP) page.
Your component is a Microsoft Transaction Server (MTS) component. For these
examples, CRYPT_MACHINE_KEYSET is used because the security context in which
the application is running does not have access to a user profile. For example, an
MTS client may impersonate a user but the user's profile is not available because
the user is not logged on. The same is true for a component that is running under
an ASP page.

Providing access to your container

By default, when a key container is created, the local system and the creator are the only
users who have access to the container. The exception to this is when an administrator
creates the key container. The local system and all other administrators will have access
to the key container. Any other security context cannot open the container.
If your code will run under more than one security context, you must give the
appropriate users access to your container.

To set the security on the container, call the CryptSetProvParam function with the
PP_KEYSET_SEC_DESCR flag after the container is created. This method allows you to set
the security descriptor on the container.

The following code demonstrates how to call CryptSetProvParam. This is done

immediately after creation of the key container.

C++

// Acquire Context
if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
0))
{
if (GetLastError() == NTE_BAD_KEYSET)
{
if (!CryptAcquireContext(&hProv,
"Container",
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET))
{
// Error ...
}

// Create Security Descriptor (pSD)...

// Set the Security Descriptor on the container

if (!CryptSetProvParam(hProv,
PP_KEYSET_SEC_DESCR,
pSD,
DACL_SECURITY_INFORMATION))
{
// Error ...
}
}
}

CryptAcquireContext errors
The following are the most common error codes and possible reasons for the error.

NTE_BAD_KEYSET (0x80090016)
 Key container does not exist.
You do not have access to the key container.
The Protected Storage Service is not running.
NTE_EXISTS (0x8009000F)
The key container already exists, but you are attempting to create it. If a
previous attempt to open the key failed with NTE_BAD_KEYSET, it implies that
access to the key container is denied.
NTE_KEYSET_NOT_DEF (0x80090019)
The Crypto Service Provider (CSP) may not be set up correctly. Use of
Regsvr32.exe on CSP DLLs (Rsabase.dll or Rsaenh.dll) may fix the problem,
depending on the provider being used.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Add a subject alternative name to a
secure LDAP certificate
Article • 02/26/2024

This article describes how to add a subject alternative name (SAN) to a secure
Lightweight Directory Access Protocol (LDAP) certificate.

Applies to: Windows Server 2012 R2

Original KB number: 931351

Summary
The LDAP certificate is submitted to a certification authority (CA) that is configured on a
Windows Server 2003-based computer. The SAN lets you connect to a domain
controller by using a Domain Name System (DNS) name other than the computer name.
This article includes information about how to add SAN attributes to a certification
request that's submitted to an enterprise CA, a stand-alone CA, or a third-party CA.

This article also discusses how to do the following actions:

Configure a CA to accept a SAN attribute from a certificate request.

Create and submit a certificate request to an enterprise CA.
Create and submit a certificate request to a stand-alone CA.
Create a certificate request by using the Certreq.exe tool.
Create and submit a certificate request to a third-party CA.

Create and submit a certificate request

When you submit a certificate request to an enterprise CA, the certificate template must
be configured to use the SAN in the request instead of using information from the
Active Directory directory service. The Version 1 Web Server template can be used to
request a certificate that will support LDAP over the Secure Sockets Layer (SSL). Version
2 templates can be configured to retrieve the SAN either from the certificate request or
from Active Directory. To issue certificates that are based on Version 2 templates, the
enterprise CA must be running on a computer that is running Windows Server 2003
Enterprise Edition.

When you submit a request to a stand-alone CA, certificate templates aren't used.
Therefore, the SAN must always be included in the certificate request. SAN attributes
can be added to a request that is created by using the Certreq.exe program. Or, SAN
attributes can be included in requests that are submitted by using the web enrollment
pages.

Use web enrollment pages to submit a certificate request

to an enterprise CA
To submit a certificate request that contains a SAN to an enterprise CA, follow these
steps:

1. Open Internet Explorer.

2. In Internet Explorer, connect to http://<servername>/certsrv .

７ Note

The placeholder <servername> represents the name of the web server that is
running Windows Server 2003 and that has the CA that you want to access.

3. Click Request a Certificate.

4. Click Advanced certificate request.

5. Click Create and submit a request to this CA.

6. In the Certificate Template list, click Web Server.

７ Note

The CA must be configured to issue web server certificates. You may have to
add the Web Server template to the Certificate Templates folder in the
Certification Authority snap-in if the CA is not already configured to issue web
server certificates.

7. Provide identifying information as required.

8. In the Name box, type the fully qualified domain name of the domain controller.

9. Under Key Options, set the following options:

Create a new key set

CSP: Microsoft RSA SChannel Cryptographic Provider
Key Usage: Exchange
Key Size: 1024 - 16384
 Automatic key container name
Store certificate in the local computer certificate store

10. Under Advanced Options, set the request format to CMC.

11. In the Attributes box, type the desired SAN attributes. SAN attributes take the
following form:

san:dns=dns.name[&dns=dns.name]

Multiple DNS names are separated by an ampersand (&). For example, if the name
of the domain controller is corpdc1.fabrikam.com and the alias is
ldap.fabrikam.com , both names must be included in the SAN attributes. The

resulting attribute string is displayed as follows:

san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com

12. Click Submit.

13. If you see the Certificate Issued webpage, click Install this Certificate.

Use web enrollment pages to submit a certificate request

to a stand-alone CA
To submit a certificate request that includes a SAN to a stand-alone CA, follow these
steps:

1. Open Internet Explorer.

2. In Internet Explorer, connect to http://<servername>/certsrv .

７ Note

The placeholder <servername> represents the name of the web server that is
running Windows Server 2012 R2 and that has the CA that you want to access.

3. Click Request a Certificate.

4. Click Advanced certificate request.

5. Click Create and submit a request to this CA.

6. Provide identifying information as required.

 7. In the Name box, type the fully qualified domain name of the domain controller.

8. In the Type of Certificate Needed Server list, click Server Authentication

Certificate.

9. Under Key Options, set the following options:

Create a new key set

CSP: Microsoft RSA SChannel Cryptographic Provider
Key Usage: Exchange
Key Size: 1024 - 16384
Automatic key container name
Store certificate in the local computer certificate store

10. Under Advanced Options, set the request format as CMC.

11. In the Attributes box, type the desired SAN attributes. SAN attributes take the
following form:

san:dns=dns.name[&dns=dns.name]

Multiple DNS names are separated by an ampersand (&). For example, if the name
of the domain controller is corpdc1.fabrikam.com and the alias is
ldap.fabrikam.com, both names must be included in the SAN attributes. The
resulting attribute string is displayed as follows:

san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com

12. Click Submit.

13. If the CA isn't configured to issue certificates automatically, a Certificate Pending

webpage is displayed and requests that you wait for an administrator to issue the
certificate that was requested.

To retrieve a certificate that an administrator has issued, connect to

http://<servername>/certsrv , and then click Check on a Pending Certificate. Click

the requested certificate, and then click Next.

If the certificate was issued, the Certificate Issued webpage is displayed. Click
Install this Certificate to install the certificate.

Use Certreq.exe to create and submit a

certificate request that includes a SAN
To use the Certreq.exe utility to create and submit a certificate request, follow these
steps:

1. Create an .inf file that specifies the settings for the certificate request. To create an
.inf file, you can use the sample code in the Creating a RequestPolicy.inf file
section in How to Request a Certificate With a Custom Subject Alternative Name.

SANs can be included in the [Extensions] section. For examples, see the sample .inf
file.

2. Save the file as Request.inf.

3. Open a command prompt.

4. At the command prompt, type the following command, and then press ENTER:

Console

certreq -new request.inf certnew.req

This command uses the information in the Request.inf file to create a request in
the format that is specified by the RequestType value in the .inf file. When the
request is created, the public and private key pair is automatically generated and
then put in a request object in the enrollment requests store on the local
computer.

5. At the command prompt, type the following command, and then press ENTER:

Console

certreq -submit certnew.req certnew.cer

This command submits the certificate request to the CA. If there's more than one
CA in the environment, the -config switch can be used in the command line to
direct the request to a specific CA. If you don't use the -config switch, you're
prompted to select the CA to which the request should be submitted.

The -config switch uses the following format to refer to a specific CA:

computername\Certification Authority Name

For example, assume that the CA name is Corporate Policy CA1 and that the
domain name is corpca1.fabrikam.com . To use the certreq command together with
the -config switch to specify this CA, type the following command:
 Console

certreq -submit -config "corpca1.fabrikam.com\Corporate Policy CA1"

certnew.req certnew.cer

If this CA is an enterprise CA and if the user who submits the certificate request has
Read and Enroll permissions for the template, the request is submitted. The issued
certificate is saved in the Certnew.cer file. If the CA is a stand-alone CA, the
certificate request will be in a pending state until it's approved by the CA
administrator. The output from the certreq -submit command contains the
Request ID number of the submitted request. As soon as the certificate is
approved, it can be retrieved by using the Request ID number.

6. Use the Request ID number to retrieve the certificate by running the following
command:

Console

certreq -retrieve RequestID certnew.cer

You can also use the -config switch here to retrieve the certificate request from a
specific CA. If the -config switch isn't used, you're prompted to select the CA from
which to retrieve the certificate.

7. At the command prompt, type the following command, and then press ENTER:

Console

certreq -accept certnew.cer

After you retrieve the certificate, you must install it. This command imports the
certificate into the appropriate store and then links the certificate to the private
key that is created in step 4.

Submit a certificate request to a third-party CA

If you want to submit a certificate request to a third-party CA, first use the Certreq.exe
tool to create the certificate request file. You can then submit the request to the third-
party CA by using whatever method is appropriate for that vendor. The third-party CA
must be able to process certificate requests in the CMC format.

７ Note
 Most vendors refer to the certificate request as a Certificate Signing Request (CSR).

References
For more information about how to enable LDAP over SSL together with a third-party
certification authority, see How to enable LDAP over SSL with a third-party certification
authority .

For more information about how to request a certificate that has a custom subject
alternative name, see How to Request a Certificate With a Custom Subject Alternative
Name.

For more information about how to use certutil tasks to manage a certification authority
(CA), go to the following Microsoft Developer Network (MSDN) website: Certutil tasks
for managing a Certification Authority (CA)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Approval required for certificate
renewals when certificate
autoenrollment configured
Article • 02/26/2024

Assume that you're configuring a certificate autoenrollment that has the CA certificate
manager approval and Valid existing certificate options enabled. When setting a
validity period and renewal period for the autoenrollment, the Certificate Authority (CA)
certificate manager approval is required only for the initial certificate autoenrollment.
However, in this scenario, the consequent certificate renewals also require CA certificate
manager approval.

７ Note

To identify the validity period and renewal period, use the certutil -dstemplate
<CertificateTemplateName> cmdlet, and search for pKIExpirationPeriod (the validity

period) and pKIOverlapPeriod (the renewal period).

Certificate autoenrollment runs every eight hours. When unsupported values of validity
and renewal period are configured in a certificate template, the certificate renewal is
skipped and the client triggers new enrollment requests instead of renewals, then
prompting CA certificate manager approval.
Recommended values of validity period and
renewal period
To be renewed, a certificate should have completed 80% of its validity period and be
within the renewal period. For example, a certificate valid for one year reaches the 80%
mark at around 41.5 weeks. If the certificate has a renewal period of six weeks, it will be
renewed during the 46th week period.

For normal renewal behaviors, set the renewal period to more than 8 hours and less
than 20% of the validity period.

７ Note

The execution of the certificate renewal will be skipped during the first 80% of the
certificate validity period and triggered in the last 20%.

This issue might occur with any type of certificate renewals.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't import an AES256-SHA256-
encrypted PFX certificate
Article • 03/23/2024

This article provides a workaround for an issue in which you can't import a certificate
that uses AES256-SHA256 encryption into certain versions of Windows or Windows
Server.

Applies to: Windows Server 2016, Windows Server 2012 R2, and earlier versions;
Windows 10 and earlier versions

Symptoms
On a computer that runs one of the operating systems that's listed in the "Applies to"
section, you use the Certificate Import Wizard to import a PFX file that uses AES256-
SHA256 encryption. The operation fails and generates a message that resembles the
following text:

The password you entered is incorrect.

Cause
The affected versions of Windows and Windows Server don't support AES256-SHA256
encryption for imported PFX files.

Workaround
Use TripleDES-SHA1 encryption for PFX files that you want to import into the affected
versions of Windows or Windows Server. Newer versions of Windows and Windows
Server support both TripleDES-SHA1 and AES256-SHA256 encryption for PFX files.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Certutil -view" command does not
return issued certificates correctly
Article • 02/26/2024

This article provides help to fix an issue where the Certutil -view command doesn't
return issued certificates correctly.

Applies to: Windows Server 2012 R2

Original KB number: 2233022

Symptoms
The Certutil command-line tool can be used to display the certificates that have been
issued by a certification authority using the -view parameter. Under some circumstances,
Certutil may not display all the expected certificates.

For example, the following command would not return the expected number of
certificates:

Console

certutil -view -restrict "RequesterName=contoso\twt"

Output would be similar to the following:

Maximum Row Index: 0

0 Rows
0 Row Properties, Total Size = 0, Max Size = 0, Ave Size = 0
0 Request Attributes, Total Size = 0, Max Size = 0, Ave Size = 0
0 Certificate Extensions, Total Size = 0, Max Size = 0, Ave Size = 0
0 Total Fields, Total Size = 0, Max Size = 0, Ave Size = 0
CertUtil: -view command completed successfully.

Cause
This issue is a result of how Certutil handles parsing for the -view parameter. Specifically,
there is an issue with how it parses the following escape characters: \n, \r, and \t.

Resolution
The workaround is to uppercase all requester name strings passed as restrictions on the
Certutil command line.

For example, instead of using this command:

Console

certutil -view -restrict "RequesterName=contoso\twt"

Use this command:

Console

certutil -view -restrict "RequesterName=contoso\TWT"

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Clients can't authenticate with a server
after you obtain a new certificate to
replace an expired certificate on the
server
Article • 02/26/2024

This article provides a solution to an issue where clients can't authenticate with a server
after you obtain a new certificate to replace an expired certificate on the server.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 822406

Symptoms
After you replace an expired certificate with a new certificate on a server that is running
Microsoft Internet Authentication Service (IAS) or Routing and Remote Access, clients
that have Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)
configured to verify the server's certificate can no longer authenticate with the server.
When you view the System log in Event Viewer on the client computer, the following
event is displayed.

If you enable verbose logging on the server that is running IAS or Routing and Remote
Access (for example, by running the netsh ras set tracing * enable command),
information similar to the following one is displayed in the Rastls.log file that is
generated when a client tries to authenticate.

７ Note

If you're using IAS as your Radius server for authentication, you see this behavior
on the IAS server. If you're using Routing and Remote Access, and Routing and
Remote Access is configured for Windows Authentication (not Radius
authentication), you see this behavior on the Routing and Remote Access server.

[1072] 15:47:57:280: CRYPT_E_NO_REVOCATION_CHECK will not be ignored

[1072] 15:47:57:280: CRYPT_E_REVOCATION_OFFLINE will not be ignored

[1072] 15:47:57:280: The root cert will not be checked for revocation
[1072] 15:47:57:280: The cert will be checked for revocation

[1072] 15:47:57:280:

[1072] 15:47:57:280: EapTlsMakeMessage(Example\client)

[1072] 15:47:57:280: >> Received Response (Code: 2) packet: Id: 11, Length: 25,
Type: 0, TLS blob length: 0. Flags:

[1072] 15:47:57:280: EapTlsSMakeMessage

[1072] 15:47:57:280: EapTlsReset

[1072] 15:47:57:280: State change to Initial

[1072] 15:47:57:280: GetCredentials

[1072] 15:47:57:280: The name in the certificate is: server.example.com

[1072] 15:47:57:312: BuildPacket

[1072] 15:47:57:312: << Sending Request (Code: 1) packet: Id: 12, Length: 6, Type:
13, TLS blob length: 0. Flags: S

[1072] 15:47:57:312: State change to SentStart

[1072] 15:47:57:312:

[1072] 15:47:57:312: EapTlsEnd(Example\client)

[1072] 15:47:57:312:

[1072] 15:47:57:312: EapTlsEnd(Example\client)

[1072] 15:47:57:452:

[1072] 15:47:57:452: EapTlsMakeMessage(Example\client)

[1072] 15:47:57:452: >> Received Response (Code: 2) packet: Id: 12, Length: 80,
Type: 13, TLS blob length: 70. Flags: L

[1072] 15:47:57:452: EapTlsSMakeMessage

[1072] 15:47:57:452: MakeReplyMessage

[1072] 15:47:57:452: Reallocating input TLS blob buffer

[1072] 15:47:57:452: SecurityContextFunction

[1072] 15:47:57:671: State change to SentHello

[1072] 15:47:57:671: BuildPacket

[1072] 15:47:57:671: << Sending Request (Code: 1) packet: Id: 13, Length: 1498,
Type: 13, TLS blob length: 3874. Flags: LM

[1072] 15:47:57:702:

[1072] 15:47:57:702: EapTlsMakeMessage(Example\client)

[1072] 15:47:57:702: >> Received Response (Code: 2) packet: Id: 13, Length: 6, Type:
13, TLS blob length: 0. Flags:

[1072] 15:47:57:702: EapTlsSMakeMessage

[1072] 15:47:57:702: BuildPacket

[1072] 15:47:57:702: << Sending Request (Code: 1) packet: Id: 14, Length: 1498,
Type: 13, TLS blob length: 0. Flags: M

[1072] 15:47:57:718:

[1072] 15:47:57:718: EapTlsMakeMessage(Example\client)

[1072] 15:47:57:718: >> Received Response (Code: 2) packet: Id: 14, Length: 6, Type:
13, TLS blob length: 0. Flags:

[1072] 15:47:57:718: EapTlsSMakeMessage

[1072] 15:47:57:718: BuildPacket

[1072] 15:47:57:718: << Sending Request (Code: 1) packet: Id: 15, Length: 900, Type:
13, TLS blob length: 0. Flags:

[1072] 15:48:12:905:

[1072] 15:48:12:905: EapTlsMakeMessage(Example\client)

[1072] 15:48:12:905: >> Received Response (Code: 2) packet: Id: 15, Length: 6, Type:
13, TLS blob length: 0. Flags:

[1072] 15:48:12:905: EapTlsSMakeMessage

[1072] 15:48:12:905: MakeReplyMessage

[1072] 15:48:12:905: SecurityContextFunction

 [1072] 15:48:12:905: State change to SentFinished. Error: 0x80090318

[1072] 15:48:12:905: Negotiation unsuccessful

[1072] 15:48:12:905: BuildPacket

[1072] 15:48:12:905: << Sending Failure (Code: 4) packet: Id: 15, Length: 4, Type: 0,
TLS blob le

Cause
This issue may occur if all the following conditions are true:

The IAS or Routing and Remote Access server is a domain member, but automatic
certificate requests functionality (autoenrollment) isn't configured in the domain.
Or, the IAS or Routing and Remote Access server isn't a domain member.
You manually request and receive a new certificate for the IAS or Routing and
Remote Access server.
You don't remove the expired certificate from the IAS or Routing and Remote
Access server. If an expired certificate is present on the IAS or Routing and Remote
Access server together with a new valid certificate, client authentication doesn't
succeed. The "Error 0x80090328" result that is displayed in the Event Log on the
client computer corresponds to "Expired Certificate."

Workaround
To work around this issue, remove the expired (archived) certificate. To do it, follow
these steps:

1. Open the Microsoft Management Console (MMC) snap-in where you manage the
certificate store on the IAS server. If you don't already have an MMC snap-in to
view the certificate store from, create one. To do so:

a. Select Start, select Run, type mmc in the Open box, and then select OK.

b. On the Console menu (the File menu in Windows Server 2003), select
Add/Remove Snap-in, and then select Add.

c. In the Available Standalone Snap-ins list, select Certificates, select Add, select
Computer account, select Next, and then select Finish.

７ Note
 You can also add the Certificates snap-in for the user account and for the
service account to this MMC snap-in.

d. Select Close, and then select OK.

2. Under Console Root, select Certificates (Local Computer).
3. On the View menu, select Options.
4. Click to select the Archived certificates check box, and then select OK.
5. Expand Personal, and then select Certificates.
6. Right-click the expired (archived) digital certificate, select Delete, and then select
Yes to confirm the removal of the expired certificate.
7. Quit the MMC snap-in. You don't have to restart the computer or any services to
complete this procedure.

More information
Microsoft recommends that you configure automatic certificate requests to renew
digital certificates in your organization. For more information, see Certificate
Autoenrollment in Windows XP

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to install imported certificates on a
Windows-based Web server
Article • 02/26/2024

This article describes how to import a Web site certificate into the certificate store of the
local computer and assign the certificate to the Web site.

Applies to: Supported versions of Windows Server

Original KB number: 816794

Install the Certificates

The Windows Internet Information Server (IIS)supports Secure Sockets Layer (SSL)
communications. A whole Web site, a folder on the Web site, or a particular file that is
located in a folder on the site can require a secure SSL connection. However, before the
Web server can support SSL sessions, a Web site certificate must be installed.

You can use one of the following methods to install a certificate in IIS:

Make an online request by using the IIS Web Server Certificate Wizard and install
the certificate at the time of the request.
Make an offline request by using the IIS Web Server Certificate Wizard and obtain
and install the certificate later.
Request a certificate without using the IIS Web Server Certificate Wizard.

７ Note

If you use the second or third method, you must install the certificate manually.

To install the Web site certificate, you must complete the following tasks:

Import the certificate into the computer's certificate store.

Assign the installed certificate to the Web site.

Import the certificate into the local computer

store
To import the certificate into the local computer store, follow these steps:
 1. On the Web server, select Start, and then select Run.
2. In the Open box, type mmc, and then select OK.
3. On the File menu, select Add/Remove snap-in.
4. In the Add/Remove Snap-in dialog box, select Add.
5. In the Add Standalone Snap-in dialog box, select Certificates, and then select
Add.
6. In the Certificates snap-in dialog box, select Computer account, and then select
Next.
7. In the Select Computer dialog box, select Local computer: (the computer this
console is running on), and then select Finish.
8. In the Add Standalone Snap-in dialog box, select Close.
9. In the Add/Remove Snap-in dialog box, select OK.
10. In the left pane of the console, double-click Certificates (Local Computer).
11. Right-click Personal, point to All Tasks, and then select Import.
12. On the Welcome to the Certificate Import Wizard page, select Next.
13. On the File to Import page, select Browse, locate your certificate file, and then
select Next.
14. If the certificate has a password, type the password on the Password page, and
then select Next.
15. On the Certificate Store page, select Place all certificates in the following store,
and then select Next.
16. Select Finish, and then select OK to confirm that the import was successful.

Assign the Imported Certificate to the Web Site

1. Select Start, point to Administrative Tools, and then select Internet Information
Services (IIS) Manager.
2. In the left pane, select your server.
3. In the right pane, double-click Web Sites.
4. In the right pane, right-click the Web site you want to assign the certificate to, and
then select Properties.
5. Select Directory Security, and then select Server Certificate.
6. On the Welcome to the Web Certificate Wizard page, select Next.
7. On the Server Certificate page, select Assign an existing certificate, and then
select Next.
8. On the Available Certificates page, select the installed certificate you want to
assign to this Web site, and then select Next.
9. On the SSL Port page, configure the SSL port number. The default port of 443 is
appropriate for most situations.
10. Select Next.
 11. On the Certificate Summary page, review the information about the certificate,
and then select Next.
12. On the Completing the Web Server Certificate Wizard page, select Finish, and
then select OK.

You can now configure Web site elements to use secure communications.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Remote Desktop server certificates are
renewed two times a day despite being
valid for one year
Article • 02/26/2024

This article provides a solution to an issue where the Remote Desktop server certificates
are renewed two times a day despite being valid for one year.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2531138

Symptoms
Consider the following scenario:

You want to enable a Remote Desktop server to provide server authentication by

using a Secure Sockets Layer (SSL) certificate.

You configure a certificate template for Remote Desktop servers. To do this, you
follow the settings that are described in the following link:

Configuring Remote Desktop certificates

In this scenario, you find that the servers are re-requesting and re-enrolling the
certificates two times daily. This occurs even though the certificate template is valid for
one year. Additionally, when the re-enrollment of the certificate occurs, some events are
logged in the System log.

Additionally, if you have these enrolled certificates automatically published to Active

Directory, the size of the Active Directory database will increase significantly because of
the constant re-enrollment of the certificate. And, the Active Directory replication may
pause and report warning events.

Cause
The underlying cause of this behavior is related to the RDS component and to a
mismatch within the certificate template. Specifically, if the template name and template
display name are different, the RDS service does not match the existing certificate to the
template, and the RDS service periodically enrolls a new certificate.
Resolution
To resolve this problem, you must set the certificate template's attribute's template
display name and template name to the same value, such as RemoteDesktopComputer.
This procedure is suggested in Security.

Then, you must update the GPO setting Computer Configuration\Policies\Administrative

Templates\Windows Components\Terminal Services\Terminal Server\Security\Server
Authentication Certificate Template based on the new template name, such as
RemoteDesktopComputer. After the server receives the new GPO setting during the
processing of the background GPO redraw, the certificates are no longer renewed on a
twice-daily basis.

） Important

You must set the certificate template's attributes Template Display Name and
Template Name to the same value.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Crypt32 8 events continuously reported
in Windows
Article • 02/26/2024

This article provides help to solve an issue where Crypt32 event 8 is continuously
reported in the Application log.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2253680

Symptoms
The following event is recorded in the Application log:

Event Type: Error

Event Source: Crypt32
Event Category: None
Event ID: 8
Date: <DateTime>
Time: <DateTime>
User: N/A
Computer: SERVER1
Description:
Failed auto update retrieval of third-party root list sequence number from:
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/a

uthrootseq.txt with error: The server name or address could not be resolved.

The following similar event may also be recorded:

Event Type: Error

Event Source: Crypt32
Event Category: None
Event ID: 8
Date: <DateTime>
Time: <DateTime>
User: N/A
Computer: SERVER1
Description:
Failed auto update retrieval of third-party root list sequence number from:
 http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/a
uthrootseq.txt with error: This network connection does not exist.

These events may be recorded at continuously, at regular intervals (for example, every
10 minutes) or they may only be recorded when you start a particular application.

Also, the computer on which the events are recorded doesn't have connectivity to the
Windows Update web site because of router or proxy configuration.

These events are recorded despite the fact that no applications or services installed on
the computer fail to start, or encounter any operational errors.

Cause
This behavior is expected under the following conditions:

The computer is unable to access the Windows Update web site due to router or
proxy configuration.
An application has been installed that has been designed to interact with the
Windows Security app on Windows Vista or higher. Example applications include
third-party virus software, malware scanners, or firewall products.

Resolution
There are three options for handling these events.

1. Disregard these events. They are benign and can be safely ignored.
2. Modify router or proxy configuration to allow computers recording these events to
connect to Windows Update.
3. Disable Automatic Root Updates on computers recording these events.
a. In Control Panel, double-click Add/Remove Programs.
b. Click Add/Remove Windows Components.
c. Click to clear the Update Root Certificates check box, and then continue with
the Windows Components Wizard.

More information
Microsoft requires that any software registers and interacts with the Windows Security
app that's signed with a digital certificate that chains up to an internal Microsoft code
signing root certification authority (CA). This CA is called the Microsoft Code Verification
Root CA (MSCV). Microsoft has cross-certified the MSCV with multiple third-party code-
signing CAs allowing these vendors to continue issuing valid code-signing certificates to
their customers.

The MSCV certificate is embedded in the kernel, but it is not available as part of the
Automatic Trusted Root Update service. Whenever the digital signature on one of these
applications is checked, the chain of the vendor's code signing certificate is built up to
both the root CA of the third-party that issued the code signing certificate and, by virtue
of the cross-CA certificate issued by Microsoft, also to the MSCV. In short, two chains
are built and the validity of both are verified.

The MSCV certificate is not embedded in the kernel so Windows determines that that
CA is not trusted. If Automatic Trusted Root Updates are enabled, then Windows will
attempt to contact Windows Update to determine if the MSCV certificate is published
by Microsoft as part of the Trusted Root Program. The MSCV is not available through
that program, so this lookup fails.

Windows quickly determines that the MSCV isn't trusted and that chain is eliminated.
This leaves the other chain that leads to a third-party root CA, which is probably valid,
allowing the application's signature to be successfully validated. Thus, there are no
errors or failures associated with the application.

If Windows can successfully contact Windows Update, then no events are recorded in
the Application log. Failure to locate an arbitrary untrusted root CA certificate on
Windows Update is a handled failure and requires no special reporting. If Automatic
Trusted Root Updates are enabled, but Windows is unable to contact the Windows
Update site, then that is an error that requires reporting through the events and errors
documented above.

These events aren't recorded on Windows Vista or higher because the MSCV certificate
is embedded in the Windows kernel. The MSCV is therefore inherently trusted and
there's no need to look for the certificate on Windows Update.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 4107 or Event ID 11 is logged in
the Application log
Article • 02/26/2024

This article provides steps to solve the event 4107 and event 11 that are logged in the
Application log.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1, Windows
7 Service Pack 1
Original KB number: 2328240

Symptoms
The following error messages are logged in the Application log:

Output

Log Name: Application

Source: Microsoft-Windows-CAPI2
Date: DateTime
Event ID: 4107
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
Failed extract of third-party root list from auto update cab at:
<http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/
en/authrootstl.cab> with error: A required certificate is not within its
validity period when verifying against the current system clock or the
timestamp in the signed file.

Output

Log Name: Application

Source: Microsoft-Windows-CAPI2
Date: DateTime
Event ID: 11
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
Failed extract of third-party root list from auto update cab at:
 <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/
en/authrootstl.cab> with error: A required certificate is not within its
validity period when verifying against the current system clock or the
timestamp in the signed file.

Cause
This error occurs because the Microsoft Certificate Trust List Publisher certificate expired.
A copy of the CTL with an expired signing certificate exists in the CryptnetUrlCache
folder.

Resolution
To resolve the problem, follow these steps:

1. Open a command prompt. Select Start, select All Programs, select Accessories,
and then select Command Prompt.

2. At the command prompt, type the following command, and then press ENTER:

Console

certutil -urlcache * delete

７ Note

The certutil command must be run for every user on the workstation. Each
user must log in and follow steps 1 and 2 above.

3. If the expired certificate is cached in one of the local system profiles, you must
delete the contents of some directories by using Windows Explorer. To do it, follow
these steps:

a. Start Windows Explorer. Select Start, select All Programs, select Accessories,
and then select Windows Explorer.

７ Note

You must enable hidden folders to view the directories whose contents you
must delete. To enable hidden files and folders, follow these steps:
i. Select Organize, and then select Folder and search options.
 ii. Select the View tab.
iii. Select the Show hidden files and folders check box.
iv. Clear the Hide extensions for known file types check box.
v. Clear the Hide protected operating system files check box.
vi. Select Yes to dismiss the warning, and then select OK to apply the
changes and to close the dialog box.

b. Delete the contents of the directories that are listed here. (%windir% is the
Windows directory.)

７ Note

You may receive a message that states that you do not have permission to
access the folder. If you receive this message, select Continue.

LocalService :

%windir%\ServiceProfiles\LocalService\AppData\LocalLow\Microsoft\CryptnetUr
lCache\Content
%windir%\ServiceProfiles\LocalService\AppData\LocalLow\Microsoft\CryptnetUr
lCache\MetaData

NetworkService :

%windir%\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\Cryptn
etUrlCache\Content
%windir%\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\Cryptn
etUrlCache\MetaData

LocalSystem :

%windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\Cryptn
etUrlCache\Content
%windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\Cryptn
etUrlCache\MetaData

More information
Event ID 4107 can also be logged with The data is invalid error instead of the following
error:

A required certificate is not within its validity period when verifying against the
current system clock or the timestamp in the signed file
This error Data is invalid indicates the object returned from the network wasn't a valid
cab file. So Windows couldn't parse it correctly. Instances of such an error can occur
when the network retrieval attempt for the cab file fails to go through a proxy. If the
proxy returns some data or message instead of a standard HTTP error code, Windows
will try to parse the message received from the proxy, expecting it to be the cab. This
situation will fail with the data is invalid error.

To address this error, you need to remove the invalid entry in the cache by clearing the
cache following the steps in the Resolution section.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Removal of the U.S. Federal Common
Policy CA certificate from the Microsoft
trusted root
Article • 02/26/2024

This article discusses the removal of the U.S. Federal Common Policy CA root certificate
in the May 24, 2022 Microsoft Root certificate update. This article also provides solutions
to avoid or resolve issues that will occur if enterprises haven't transitioned to the Federal
Common Policy CA G2 root certificate before the removal of the Federal Common Policy
CA root certificate from the Microsoft Certificate Trust List (CTL) by May 24, 2022.

７ Note

The root certificate that's being removed by the Microsoft Root Certificate Update
is named "Federal Common Policy CA" and is commonly referred to as the "G1"
root certificate even though "G1" does not appear in the certificate name.

The root certificate that replaces the "G1" root certificate is named "Federal
Common Policy CA G2" and is commonly referred to as the "G2" root certificate.

Applies to: All versions of Windows

Introduction
The United States Federal PKI (FPKI) team that governs the U.S. Federal Common
Policy CA formally requested the removal of the "G1" root certificate listed below from
the Microsoft Trusted Root Program.

ﾉ Expand table

Certificate name SHA1 thumbprint

Federal Common Policy CA 905F942FD9F28F679B378180FD4F846347F645C1

Applications and operations that depend on the "G1" root certificate will fail one to
seven days after they receive the root certificate update. Administrators should migrate
from the existing "G1" root certificate to the replacement "G2" root certificate listed
below as your agency's federal trust anchor.
 ﾉ Expand table

Certificate name SHA1 thumbprint

Federal Common Policy CA G2 99B4251E2EEE05D8292E8397A90165293D116028

７ Note

The "G2" root certificate can be downloaded directly from "G2" root certificate crt
file download .

Potential issues
After the "G1" root certificate is removed, users in environments that have not
transitioned to the "G2" root certificate may experience issues that affect the following
scenarios:

TLS or SSL connections.

Secure or multipurpose internet Mail Extensions (S/MIME) or secure email.
Signed documents in Microsoft Word. (PDF and Adobe Acrobat files will not be
affected.)
Client authentication, including establishing VPN connections.
Smart card or PIV authenticated access, including badge access that relies
completely on Windows software.

The following error messages may be displayed in pop-up windows and dialog boxes:

The site's security certificate is not trusted.

The security certificate presented by this website was not issued by a trusted
CA.

A certificate chain processed but terminated in a ROOT certificate that is not

trusted by the trust provider.

Certificate Chaining Error.

The certificate chain was issued by an authority that is not trusted.

The certificate or associated chain is invalid.

Steps to avoid these issues
1. Verify changes in the Test configuration setup section to test what occurs with the
removal of the "G1" from the CTL before the release date of the update.
2. After you use the test configuration setup section to verify that all relevant
scenarios work, follow the steps in the "Production configuration setup" section in
your production configuration.

７ Note

Application-as-service scenarios such as Azure SQL or Azure App Service that chain
to the "G1" root certificate will fail after the "G1" root certificate is removed.

Test configuration setup

Before the release of the update, administrators can use the following steps to directly
configure the Windows registry to a prerelease or staged location of the latest certificate
update. You can also configure the settings by using Group Policy. See To configure a
custom administrative template for a GPO.

７ Note

The preview of the May release which includes the removal of the "G1" root
certificate is staged on May 11, 2022.

1. Open regedit, and then navigate to the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate

2. Add or modify the following registry values:

Set RootDirUrl to
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/t

est .

Set SyncFromDirUrl to
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/t

est .

3. Delete the following registry values:

EncodedCtl
LastSyncTime
 4. Delete the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificate

s subkey. This step deletes all stored root certificates.

７ Note

By deleting all stored root certificates from

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certifi
cates , you can make sure that all stored root certificates are removed. This

operation forces Windows to download new root certificates if associated

public key infrastructure (PKI) chains are used that have new properties (if
modified). Because the "G1" root certificate is being removed, this root
certificate will not be downloaded.

5. Verify all scenarios that chain to the "G1" root certificate, including those that are
listed in Potential issues.

７ Note

The link to the test site never changes. However, the changes that are staged on
the test site change from month to month.

Production configuration setup

The following steps directly configure the Windows registry to use the production
version of the CTL if the testing URL from the previous section is used:

1. Open regedit, and then navigate to the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate

2. Add or modify the following registry values:

Set RootDirUrl to
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en .

Set SyncFromDirUrl to
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en .

3. Delete the following registry values:

EncodedCtl
LastSyncTime
 4. Delete the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificate

s registry subkey. This step deletes all stored root certificates.

Configure the "G2" root certificate

Administrators should configure the "G2" root certificate per the following instructions
before the "G1" root certificate is removed by the out-of-band (OOB) root certificate
update.

1. Follow the guidance in Obtain and verify the FCPCA root certificate to download
and install the "G2" root certificate on all Windows workgroup, member, and
domain controller computers.
2. There are multiple ways to deploy the root store to enterprise devices. See the
"Microsoft Solutions" section in Distribute to operating systems .

７ Note

In enterprises that have cross-certification dependencies for smart card logons or

other scenarios on Windows devices but do not have internet access, see the "Do I
Need to Distribute the Intermediate CA Certificates?" and "Certificates Issued by
the Federal Common Policy CA G2" sections of Distribute intermediate
certificates .

Many federal enterprises must have either the U.S. Treasury CA certificates or the
Entrust Managed Services CA certificates. Both CA certificates are documented in
the "Distribute the CA certificates" article, as follows:

Important! To ensure PIV credential certificates issued by the Entrust Federal

SSP before August 13, 2019 validate to the Federal Common Policy CA G2,
you'll need to distribute an additional intermediate CA certificate to systems
that are unable to perform dynamic path validation. Learn more on our
Frequently Asked Questions page.

Manual steps to get the CTL

For disconnected environments in which Windows devices are not allowed to access
Windows Update or the internet, follow these steps to manually get the CTL:

1. Download the CTL:

 a. Run certutil -generateSSTFromWU c:\roots\trustedcerts.sst .
b. When you select the trustedcerts.sst file, this should open the Certificate
Manager snap-in to display the complete CTL.
2. Download Certificate Disallowed List:
a. Run certutil -syncwithwu c:\roots .
b. Run certutil -verifyctl -v c:\roots\disallowedstl.cab
c:\roots\disallowedcert.sst .

c. When you select disallowedcert.sst, this should open the Certificate Manager
snap-in to display all roots in the Disallowed list.
3. To evaluate settings that are not shown in the UI, convert the SST file to a text file.
To do this, run certutil -dump -gmt -v c:\roots\trustedcerts.sst >
c:\roots\trustedcerts.txt .

4. Download the "G2" root certificate from Obtain and verify the FCPCA root
certificate and add it to your personal CTL.

Troubleshoot and analyze root chaining issues

The following data can help you troubleshoot operations that are affected by the
removal of the "G1" root certificate:

1. Enable CAPI2 logging. See Windows PKI Troubleshooting and CAPI2 Diagnostics .

2. Create filters in Event Viewer on the following event logs, event sources, and event
IDs.

Under the Applications and Services Logs\Microsoft\Windows\CAPI2\Operational

log that uses CAPI2 as its source:

Event ID 11: This event shows you chaining failures.

Event ID 30: This event shows you Policy chain failures, such as NTAuth
failures and SSL Policy check.
Event ID 90: This event shows you all certificates that were used to build all
possible certificate chains on the system.
Event ID 40–43: This event series shows all stored CRLs and event certificates
that are accessed through AIA paths.
Event ID 50–53: This event series shows all attempts to access the CRLs from
the network. The event is related to the following error message:

A certificate chain processed, but terminated in a ROOT certificate that is

not trusted by the trust provider
 In the System event log that uses Microsoft-Windows-Kerberos-Key-Distribution-
Center as its source:

Error 19: This event indicates that an attempt was made to use a smart card
logon, but the KDC cannot use the PKINIT protocol because a suitable
certificate is missing.
Event 21: A certificate chain could not be built to a trusted root authority.
Event 29: The Key Distribution Center (KDC) cannot find a suitable certificate
to use for smart card logons, or the KDC certificate could not be verified.
Smart card logon may not function correctly if this problem is not resolved.
To correct this problem, either verify the existing KDC certificate by using
Certutil.exe or enroll for a new KDC certificate.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when a user requests certificate
from CA web enrollment pages: No
certificate templates could be found
Article • 02/26/2024

This article provides help to solve an error "No certificate templates could be found"
that occurs when you request certificates from CA web enrollment pages.

Applies to: Windows Server 2003

Original KB number: 811418

Symptoms
When a user tries to request a certificate from the certification authority (CA) web
enrollment pages, the user may receive the following error message:

No certificate templates could be found. You do not have permission to request a

certificate from this CA, or an error occurred while accessing the Active Directory.

This behavior occurs if the Web enrollment pages are in an Active Directory domain on
an Enterprise CA server. It occurs whether the web enrollment pages are on the same
server or on a different member server.

Cause
The CA Web enrollment pages perform a case-sensitive string comparison of two values.
One value is the sServerConfig value in the Certdat.inc file in the
%systemroot%\System32\Certsrv folder on the certificate server, and the other value is

the dnsHostName attribute on the pkiEnrollmentService object in Active Directory. If

the two strings do not match, including the case match, the enrollment fails.

Resolution
To correct this behavior, follow these steps:

1. View the Active Directory dNSHostName attribute on the pkiEnrollmentService

object. This object is in the following location:
 CN= CertificateServer,CN=Enrollment Services,CN=Public Key
Services,CN=Services,CN=Configuration,DC= MyDomain,DC=com

To view the dNSHostName attribute, use ADSIEdit.msc or LDP.exe.

2. Edit the Certdat.inc file so that the value for sServerConfig is the same as the value
for the dNSHostName attribute followed by the Certificate Authority Name.

７ Note

The sServerConfig value must be in the same exact case as the dNSHostName
attribute. If this is not true, you will continue to get the same error.

3. For example, if the DNS hostname for the Certification Authority is

server1.domain.local and name of the Certification Authority is MYCA, then ensure
the dNSHostName attribute for CN=MYCA,CN=Enrollment Services,CN=Public
Key Services,CN=Services,CN=Configuration,DC= Domain,DC=local object is set
to server1.domain.local and sServerConfig in the certdat.inc file in the
%systemroot%\system32\certsrv folder on the Certification Authority should be set

to server1.domain.local\MYCA.

4. Have the user who wants to request the certificate restart Internet Explorer. This
permits the new credentials to pass to the CA.

７ Note

Also make sure that the user is granted Read and Enroll permissions on the
certificate template which that user is requesting. You can grant these
permissions either by using the ADSIEdit snap-in or the Certificate Templates
snap-in.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Not able to request certificate using
web enrollment
Article • 02/26/2024

This article provides solutions to an issue where you fail to request a certificate by using
web enrollment.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2885758

Symptoms
When you browse the CA website to request a certificate, and click on "Request a
certificate" and then click on "Create and submit a request to this CA", you get the
following message:

In order to complete certificate enrollment, the web site for the CA must be
configured to use HTTPS authentication

You may also see the following message next to address bar:

Internet explorer has blocked this site from using an activeX control in an unsafe
manner. As a result, this page might not display correctly.

To resolve the above errors, if you add the website URL in the trusted site zone and
enable the setting "Initialize and script ActiveX controls not marked as safe for scripting"
and then try to browse the website for certificate request, you'll get the following
message:

This web site is attempting to perform a digital certificate operation on your behalf:
https://CAWebsiteURL

You should only allow known web sites to perform digital certificate operations on
your behalf. Do you want to allow this operation?

If you hit "OK" on the above message, you get a pop-up window with the following
message:

No certificate templates could be found. You do not have permission to request a

certificate from this CA, or an error occurred while accessing the active directory.
Cause
If you're running CA servers on Windows 2008 R2 and above and trying to request a
computer certificate templates V3 using web enrollment (CAWE), it will not work.

This was an enhancement that we introduced in Windows 2008 R2.

Now web enrollment (CAWE) doesn't support V3 templates.

You can use mmc, auto enrollment, and certreq.exe to request a V3 template.

Resolution
Here are some possible solutions of this issue:

Use mmc, auto enrollment, or certreq.exe to request a V3 certificate template.

If you're hosting CA web enrollment (CAWE) on a server other than CA server, then
please ensure that constrained delegation for Kerberos is enabled on the computer
account of the server hosting CAWE role.
Also, make your CA website is using SSL that is, https and not http.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when client computers encrypt a
file in a Windows Server 2003 domain:
Recovery policy configured for this
system contains invalid recovery
certificate
Article • 02/26/2024

This article provides a solution to an error that occurs when client computers encrypt a
file in a Microsoft Windows Server 2003 domain.

Applies to: Windows Server 2003

Original KB number: 937536

Symptoms
When a client computer uses the Encrypting File System (EFS) to encrypt a file that is
stored on a remote computer in a Microsoft Windows Server 2003 domain, you may
receive an error message on the computer that resembles the following:

Recovery policy configured for this system contains invalid recovery certificate.

Cause
This problem occurs if the EFS recovery policy that is implemented on the client
computer contains one or more EFS recovery agent certificates that have expired. Client
computers cannot encrypt any new documents until a valid recovery agent certificate is
available.

Resolution
To resolve this problem, follow these steps:

1. Log on to a domain controller by using the user account under which you want the
EFS recovery agent to run.

2. Use the Windows Server 2003 version of the Cipher tool together with the /r
switch to create a new self-signed file recovery certificate and a private key. The
 Cipher tool generates a new public file recovery certificate (a .cer file) and a .pfx
file. Make copies of these files, and then save them to a safe location. To generate
the new file recovery certificate, follow these steps:

a. Click Start, click Run, type cmd, and then click OK.

b. At the command prompt, type cipher /r: file_name , and then press ENTER.

７ Note

file_name represents the file name that you want to use. Use a file name
that is meaningful to you. Do not add an extension to the file name. Make
sure that the new .cer and .pfx files are created in the same folder.

c. When you are prompted for a password to protect the .pfx file, type a password
that you will easily remember.

3. Export the old EFS recovery agent certificate. To do this, follow these steps:

a. Log on to the domain controller by using an account that has Domain

administrative credentials. Click Start, point to Programs, point to
Administrative Tools, and then click Active Directory Users and Computers.

b. Right-click Domain_name, and then click Properties.

c. Click the Group Policy tab, click the Default Domain Policy Group Policy object
(GPO), and then click Edit.

d. Expand Computer Configuration, expand Windows Settings, Expand Security

Settings, expand Public Key Policies, and then click Encrypting File System.

e. Right-click the current EFS recovery agent certificate, point to All Tasks, and
then click Export.

f. Follow the instructions in the Certificate Export Wizard to export the old EFS
recovery agent certificate.

７ Note

Make sure that you export the old EFS recovery agent certificate together
with the private key to a .cer file. Keep the new EFS recovery agent .pfx file
and the old EFS recovery agent .pfx file in a safe location.
 4. Right-click the old EFS recovery agent certificate, click Delete, and then click Yes.

5. Log on to the domain controller by using an account that has Domain

administrative credentials, and then import the new EFS recovery agent certificate.
To do this, follow these steps:
a. Click Start, point to Programs, point to Administrative Tools, and then click
Active Directory Users and Computers.
b. Right-click Domain_name, and then click Properties.
c. Click the Group Policy tab, click the Default Domain Policy GPO, and then click
Edit.
d. Expand Computer Configuration, expand Windows Settings, expand Security
Settings, expand Public Key Policies, and then click Encrypting File System.
e. Right-click the Encrypting File System folder, and then click Add.
f. Click Next on the Add Recovery Agent Wizard, and then click Browse Folders.
g. Import the new .cer file that you created in step 2b, and then click Open.

７ Note

When you open the .cer file, you see USER_UNKNOWN in the Recovery
Agents field. This message is expected. Also, you receive a warning message
from the Add Recovery Agent Wizard that the certificate is not trusted.

6. Import the new .cer file that you created in step 2b to the folder: Computer
Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted

Root Certification Authorities .

7. If you have multiple domain controllers, type gpupdate /force at a command

prompt to update the Group Policy.

8. Verify that client computers can successfully encrypt files.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Cipher.exe to overwrite deleted
data in Windows Server 2003
Article • 02/26/2024

This article describes how to use Cipher.exe to overwrite deleted data in Windows Server
2003.

Applies to: Windows Server 2003

Original KB number: 814599

Summary
Administrators can use Cipher.exe to encrypt and decrypt data on drives that use the
NTFS file system. They can also use it to view the encryption status of files and folders
from a command prompt. The version of Cipher.exe that's included with Windows
Server 2003 includes the ability to overwrite data that has been deleted so that it can't
be recovered or accessed.

When you delete files or folders, the data isn't initially removed from the hard disk.
Instead, the space on the disk that was occupied by the deleted data is deallocated.
After it's deallocated, the space is available to use when new data is written to the disk.
Until the space is overwritten, you can recover the deleted data by using a low-level disk
editor or data-recovery software.

When you encrypt plain text files, Encrypting File System (EFS) makes a backup copy of
the file. So the data isn't lost if an error occurs during the encryption process. After the
encryption is complete, the backup copy is deleted. As with other deleted files, the data
isn't removed until it has been overwritten. The Windows Server 2003 version of the
Cipher utility is designed to prevent unauthorized recovery of such data.

Use the Cipher security tool to overwrite

deleted data

７ Note

The cipher /w command does not work for files that are smaller than 1 KB.
Therefore, make sure that you check the file size to confirm whether is smaller than
1 KB. This issue is scheduled to be fixed in longhorn.
To overwrite deleted data on a volume by using Cipher.exe, use the /w switch with the
cipher command:

1. Quit all programs.

2. Select Start > Run, type cmd, and then press ENTER.
3. Type cipher /w: folder , and then press ENTER, where folder is any folder in the
volume that you want to clean. For example, the cipher /w:c:\test command
causes all deallocated space on drive C to be overwritten. If C:\folder is a Mount
Point or points to a folder on another volume, all deallocated space on that
volume will be cleaned.

Data that isn't allocated to files or folders is overwritten. The data is permanently
removed. It can take a long time if you overwrite a large amount of space.

References
For more information about related topics, see Cipher.exe Security Tool for the
Encrypting File System .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

KDC_ERR_C_PRINCIPAL_UNKNOWN
Returned in S4U2Self Request
Article • 02/26/2024

This article provides help to solve an issue where S4U2Self requests fail with the error
KDC_ERR_C_PRINCIPAL_UNKNOWN.

Applies to: Windows Server 2012 R2

Original KB number: 2009157

Symptoms
You are running an application server that needs to authorize users that do not have a
logon with the server, for role-based checks using Active Directory security group
memberships. You are using the AuthZ API to do this work. Another scenario where this
problem can happen is a server that accepts user certificates for logon, for example a
web server such as Internet Information Server (IIS). To retrieve information needed for
access checks on local resources, LSASS performs a S4U2Self Kerberos transaction. But
that fails and the user cannot logon or you cannot verify the user's role.

In a network trace, you may see multiple requests with PaData Type PA-PAC-REQUEST
(type 128) which fail with errors KDC_ERR_C_PRINCIPAL_UNKNOWN (error code 6) or
KDC_ERR_PREAUTH_REQUIRED (25). But these are not fatal. Error code 6 for these
means that the domain controller to which the request was made does not host the
account and the client should choose a different domain controller. Error code 25 means
that the client cannot retrieve the user's privilege attribute certificate (PAC) without
proper validation. The client then gets a proper ticket for the user's domain key
distribution center (KDC).

Next, the last request is sent with the PaData type PA-FOR-USER (type 129) with the
application server host service principal name (SPN) as the SName and the user's user
principal name (UPN) in the PaForUser branch of the frame. The client on the request is
the application server.

This request now also fails with error KDC_ERR_C_PRINCIPAL_UNKNOWN (error code
6). This is a fatal error.

７ Note
 It will be helpful to run the network trace through frame reassembly in Network
Monitor 3.x.

Cause
The Kerberos error is actually an Access is Denied error for reading this attribute. The
S4U2Self request is accessing the TokenGroupsGlobalAndUniversal user-constructed
attribute and requires permissions to do so. By default, authenticated users have these
permissions.

Resolution
If these permissions have been changed or otherwise revoked, you need to add the
requesting accounts to the Windows Authorization Access Group. By default, this
group has the required access on all user and computer accounts. If you have also
changed the permissions of Windows Authorization Access Group, you need to
construct the permissions or use a custom group to grant the permissions.

More information
This behavior is independent of how the public key infrastructure (PKI) is set up for the
certificate logon case. It is also independent of whether both the server and user are in
the same forest or in different forests. If they are in different forests, it would work with
or without selective authentication enabled. The user needs "allowed to authenticate"
access for the server if selective authentication is enabled.

In the certificate logon case, the server application would get a handle to an access
token when the Kerberos transaction is successful. This access token is not good for
Kerberos delegation.

You can get KDC warning Event ID 25 when the S4U2Self request fails. You need to set
KdcExtraLogLevel to 0x08. For more information about this registry entry, click the
following article number to view the article in the Microsoft Knowledge Base:
837361 Kerberos protocol registry entries and KDC configuration keys in Windows
Server 2003

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x80090022
NTE_SILENT_CONTEXT when CEP/CES
autoenrollment using KBR fails on non-
domain-joined clients
Article • 02/26/2024

This article helps resolve the issue in which Certificate Enrollment Policy Web Service
(CEP) and Certificate Enrollment Web Service (CES) autoenrollment using key-based
renewal (KBR) fails on non-domain-joined clients, and you receive error "0x80090022
NTE_SILENT_CONTEXT."

You configure the CEP/CES on non-domain-joined clients for Username Password initial
enrollment, and certificate KBR. For more information about the configuration, see
Configuring Certificate Enrollment Web Service for certificate key-based renewal on a
custom port.

Initial certificate enrollment using certlm.msc and authenticating with the username and
password of the AD account works, but the KBR renewal fails. The renewal fails when it's
triggered using autoenrollment and when it's executed manually using the certreq -
machine -q -enroll -cert <thumbprint> renew cmdlet.

During the KBR certificate renewal, you received error "0x80090022 (-2146893790
NTE_SILENT_CONTEXT)" from the CertEnroll.log file:

Output

2032.4155.0:<DateTime>: 0x0 (WIN32: 0):

https://ws2019cepces.contoso.lab/KeyBasedRenewal_ADPolicyProvider_CEP_Certif
icate/service.svc/CEP
…
https://ws2019cepces.contoso.lab/KeyBasedRenewal_ADPolicyProvider_CEP_Userna
mePassword/service.svc/CEP
…
3002.676.0:<DateTime>: 0x803d0013 (-2143485933 WS_E_ENDPOINT_FAULT_RECEIVED)
3002.690.0:<DateTime>: 0x803d0013 (-2143485933
WS_E_ENDPOINT_FAULT_RECEIVED): A message containing a fault was received
from the remote endpoint. 0x803d0013 (-2143485933
WS_E_ENDPOINT_FAULT_RECEIVED)
3002.744.0:<DateTime>: 0x803d0013 (-2143485933
WS_E_ENDPOINT_FAULT_RECEIVED):
https://ws2019cepces.contoso.lab/KeyBasedRenewal_ADPolicyProvider_CEP_Certif
icate/service.svc/CEP
…
 2032.1371.0:<DateTime>: 0x80090022 (-2146893790 NTE_SILENT_CONTEXT)
450.201.0:<DateTime>: 0x1 (WIN32: 1 ERROR_INVALID_FUNCTION): Error
450.202.0:<DateTime>: 0x825a0044 (-2108030908)
450.219.0:<DateTime>: 0x0 (WIN32: 0): Local system
…
450.219.0:<DateTime>: 0x2 (WIN32: 2 ERROR_FILE_NOT_FOUND): Provider could
not perform the action since the context was acquired as silent. 0x80090022
(-2146893790 NTE_SILENT_CONTEXT)

Here are the possible causes of the issue:

Misleading error "0x80090022 NTE_SILENT_CONTEXT" is reported on the client

machine where CEP/CES KBR renewal takes place.
Unsupported validity or renewal period in certificate templates designed for client
certificates.

Misleading error "0x80090022

NTE_SILENT_CONTEXT" is reported on the
client machine where CEP/CES KBR renewal
takes place
The error reported in the certificate enrollment user interface is "0x80090022
NTE_SILENT_CONTEXT." However, the relevant error is "0x803d0013
WS_E_ENDPOINT_FAULT_RECEIVED" that was previously reported in the CertEnroll.log
file.

The confusion is caused by the higher priority of the certificate_CES endpoint. The
certificate_CES endpoint executes first (the certificate_CES endpoint must work in KBR
renewal scenario) and after that the initial username_password_CES takes place as a
fallback. The username_password_CES endpoint requires the user input, which isn't
expected to work. Then the error "0x80090022 NTE_SILENT_CONTEXT" occurs.

It means, the error "0x803d0013 WS_E_ENDPOINT_FAULT_RECEIVED" is the relevant

error that needs to be further investigated.

Here are the possible causes for error "0x803d0013 WS_E_ENDPOINT_FAULT_RECEIVED":

Ports for Remote Procedure Call (RPC) or Distributed Component Object Model
(DCOM) connectivity are blocked between CES and the certification authority (CA)
server.

Ports for RPC or DCOM connectivity are blocked between the CA server and
domain controllers.
 There are configuration issues with CEP/CES applications that are hosted by
Internet Information Services (IIS).

The configuration issues can be resolved by adding <serviceHostingEnvironment

multipleSiteBindingsEnabled="true"/> to the <system.serviceModel> section of the

Web.config file.

Unsupported validity period or renewal period

in the certificate template designed for client
certificates
For the certificate autoenrollment to work properly, make sure to set the certificate
template validity period to at least five days and the renewal period to at least one day.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when generating NDES
enrollment challenge password on an
NDES server that is running Windows
Server 2012: Http error 500.0 - internal
server error
Article • 02/26/2024

This article helps work around an error that occurs when trying to get the NDES
enrollment challenge password.

Applies to: Windows Server 2012 R2

Original KB number: 2800975

Symptoms
Assume that you install the Network Device Enrollment Service (NDES) role service on a
server that is running Windows Server 2012. In this scenario, you receive the following
error when trying to get the NDES enrollment challenge password:

Http error 500.0 - internal server error.

the page cannot be displayed because an internal server error has occurred.

Additionally, an event that resembles the following is logged on the server on which the
NDES role service is installed:

Log Name: Application

Source: Microsoft-Windows-NetworkDeviceEnrollmentService
Date: date time
Event ID: 2
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer name
Description:
The Network Device Enrollment Service cannot be started (0x800700ea). More data
is available.
Workaround
A workaround for this issue is to change the order of the handlers for the Microsoft
Simple Certificate Enrollment Protocol (MSCEP) applications in IIS so that the
ExtensionlessUrlHandler-ISAPI-4.0_64bit handler comes after the StaticFile handler. To
do so, you can follow the steps below:

1. Install and configure NDES (and CEP/CES).

2. Open IIS.
3. Select "Default Web Site".
4. Click "View Applications" in the action panel on the right.
5. Double-click the mscep application.
6. Double-click "Handler Mappings".
7. Click "View Ordered List..." in the action panel.
8. Select ExtensionlessUrlHandler-ISAPI-4.0_64bit and move it down so it is below
StaticFile.
9. Repeat steps 6-8 for the mscep_admin application.
10. Restart IIS.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Renewal of "Enrollment Agent"
certificate used by NDES may fail
Article • 02/26/2024

This article provides a solution to fix an issue where renewing Exchange Enrollment
Agent (Offline request) certificate by using NDES fails.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2712186

Symptoms
You get the error "Status: unavailable" when trying to renew "Exchange Enrollment
Agent (Offline request)" certificate used by NDES, from the computer certificate store
console in MMC.

Cause
Network Device Enrollment Service (NDES) requests two certificates according to the
following two certificate templates configured with the "Intended purpose" (Enhanced
Key Usages) set to "Certificate Request Agent":

CEP Encryption.
Exchange Enrollment Agent (Offline request).

When you install the NDES service on a Windows Server 2008 server, it requires you to
provide a domain user that the NDES will use to authorize certificate requests. So, there
are different security contexts to consider: the installer context (who installs the NDES)
and the service context (the domain user that is provided during installation, and under
which the NDES runs later). The Enrollment Agent certificate is enrolled during the
installation and under the installer context, but will be loaded by the NDES later under
the service context. For the above reason, the Enrollment Agent certificate (and the CEP
Encryption certificate) must be stored in the common store that those context can
access, and the computer certificate store is chosen.

However, since the "Subject Type" of the certificate template "Exchange Enrollment
Agent (Offline request)" is set to "User", we won't be able to renew the certificate
template "Exchange Enrollment Agent (Offline request)" in MMC console (computer
certificate store) due to mismatched type of subject. The error "Status: unavailable"
would be returned in this situation.
Note: This issue doesn't happen when trying to renew "CEP Encryption" certificate
template, because its subject type is set to "Computer or other Device". Therefore,
renewal of this certificate can succeed as long as you have sufficient permission on the
system and certificate template.

Resolution
Use the certreq.exe tool to renew the Exchange Enrollment Agent (Offline request)
certificate with the following steps:

1. Create a file named Request.inf with the following contents:

[Version]
Signature="$Windows NT$"
[NewRequest]
RenewalCert="<Certificate Hash>"
MachineKeySet=TRUE

７ Note

The INF file contains input options that define the certificate request
parameters. In the above INF file, it tells the command-line tool certreq.exe to
renew the certificate with the specified Certificate Hash. You can get the
Exchange Enrollment Agent (Offline request) certificate's certificate hash by
copying the value of the certificate's "t h umbprint " extension retrieved from
certificate's "Details tab". For example, if the certificate's Thumbprint is "5 3 60
8f 10 49 1d 50 bf a2 9f 06 17 96 8a 93 05 13 cc b9 55", we will need to edit the
contents to the lines below:

[Version]
Signature="$Windows NT$"
[NewRequest]
RenewalCert="53 60 8f 10 49 1d 50 bf a2 9f 06 17 96 8a 93 05 13 cc b9 55"
MachineKeySet=TRUE

７ Note

MachineKeySet set to "True" so the certificate and its private key will be stored
in computer certificate store.
 ７ Note

To open the computer certificate store, please refer to the following technet
article: Add the Certificates Snap-in to an MMC Add the Certificates Snap-in
to an MMC

2. Run the following three commands to renew that old Enrollment Agent certificate:

Console

CertReq.exe -New Request.inf Certnew.req

CertReq.exe -Submit Certnew.req Certnew.cer
CertReq.exe -Accept Certnew.cer

７ Note

You will need administrative permissions and certificate enrollment

permission to perform the actions above. If your enrollment request
needs to wait for CA manager's approval, please contact your CA
manager to approve the request. Or, provide the request file generated
in first command to your CA manager, and ask for a certificate so we can
use the third command to install the certificate.
The steps above apply to the situation where the default certificate
template is used for NDES. In the case that NDES is configured to use
specific template, please change the inf file contents accordingly. For
more Information about the syntax of the request file, please refer to the
following article:
Appendix 3: Certreq.exe Syntax
When running first command above, a dialog box will pop up to let us
confirm the certificate that needs be renewed. Ensure the old Enrollment
Agent certificate is selected, and click OK.
At the second command, another dialog box will pop up to let us
choose the CA server for issuing the renewed Enrollment Agent
certificate. Please select the proper CA, and click OK.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A Certification Authority can't use a
certificate template
Article • 02/26/2024

This article provides a solution to an issue where a certificate template is unable to load
and certificate requests are unsuccessful using the same template.

Applies to: Windows Server 2012 R2

Original KB number: 283218

Summary
When Certificate Services starts on a Certification Authority (CA), a certificate template is
unable to load and certificate requests are unsuccessful using the same template.

More information
The behavior occurs because the Authenticated Users group is removed from the
template's access control list (ACL). The Authenticated Users group is on a template ACL,
by default. (The CA itself is included in this group.) If the Authenticated Users group is
removed, the (enterprise) CA itself can no longer read the template in the Active
Directory, and that's why certificate requests can be unsuccessful.

If an administrator wants to remove the Authenticated Users group, each and every CA's
computer account must be added to the template ACLs and set to Read.

If authenticated users have been removed from the ACLs of a template, the following
errors may be observed when the CA starts and when a certificate is requested against
the template.

Errors observed when enrollment is

unsuccessful
For the client:

Enrollment by means of a Web page:

Certificate Request Denied

Your certificate request was denied.
 Contact your administrator for further information. Enrollment by means of the
Microsoft Management Console (MMC): Certificate Request Wizard: The
certification authority denied the request. Unspecified error.

For the CA:

Event Type:Warning
Event Source:CertSvc
Event Category:None
Event ID: 53
Date: <DateTime>
Time: <DateTime>
User:N/A
Computer: MUSGRAVE
Description:
Certificate Services denied request 9 because the requested certificate
template is not supported by this CA. 0x80094800 (-2146875392). The request
was for TED\administrator. Additional information: Denied by Policy Module.
The request was for certificate template (<template name>) that is not
supported by the Certificate Services policy.

Error on CA When Certificate Services starts

Event Type:Error
Event Source:CertSvc
Event Category:None
Event ID: 78
Date: <DateTime>
Time: <DateTime>
User:N/A
Computer: MUSGRAVE
Description:
The "Enterprise and Stand-alone Policy Module" Policy Module logged the following
error: The <template name> Certificate Template could not be loaded. Element not
found. 0x80070490 (WIN32: 1168).

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Back up the recovery agent Encrypting
File System (EFS) private key in Windows
Article • 02/26/2024

This article describes how to back up the recovery agent Encrypting File System (EFS)
private key on a computer.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 241201

Summary
Use the recovery agent's private key to recover data in situations when the copy of the
EFS private key that is located on the local computer is lost. This article contains
information about how to use the Certificate Export Wizard to export the recover
agent's private key from a computer that is a member of a workgroup, and from a
Windows Server 2003-based, Windows 2000-based, Windows Server 2008-based or
Windows Server 2008 R2-based domain controller.

Introduction
This article describes how to back up the recovery agent Encrypting File System (EFS)
private key in Windows Server 2003, in Windows 2000, in Windows XP, in Windows
Vista, in Windows 7, in Windows Server 2008, and in Windows Server 2008 R2. You can
use the recovery agent's private key to recover data in situations when the copy of the
EFS private key that is located on the local computer is lost.

You can use EFS to encrypt data files to prevent unauthorized access. EFS uses an
encryption key that is dynamically generated to encrypt the file. The File Encryption Key
(FEK) is encrypted with the EFS public key and is added to the file as an EFS attribute
that is named Data Decryption Field (DDF). To decrypt the FEK, you must have the
corresponding EFS private key from the public-private key pair. After you decrypt the
FEK, you can use the FEK to decrypt the file.

If your EFS private key is lost, you can use a recovery agent to recover encrypted files.
Every time that a file is encrypted, the FEK is also encrypted with the Recovery Agent's
public key. The encrypted FEK is attached to the file with the copy that is encrypted with
your EFS public key in the Data Recovery Field (DRF). If you use the recovery agent's
private key, you can decrypt the FEK, and then decrypt the file.
By default, if a computer that is running Microsoft Windows 2000 Professional is a
member of a workgroup or is a member of a Microsoft Windows NT 4.0 domain, the
local administrator who first logs on to the computer is designated as the default
recovery agent. By default, if a computer that is running Windows XP or Windows 2000
is a member of a Windows Server 2003 domain or a Windows 2000 domain, the built-in
Administrator account on the first domain controller in the domain is designated as the
default recovery agent.

A computer that is running Windows XP and that is a member of a workgroup does not
have a default recovery agent. You have to manually create a local recovery agent.

） Important

After you export the private key to a floppy disk or other removable media , store
the floppy disk or media in a secure location. If someone gains access to your EFS
private key, that person can gain access to your encrypted data.

Export the recovery agent's private key from a computer

that is a member of a workgroup
To export the recovery agent's private key from a computer that is a member of a
workgroup, follow these steps:

1. Log on to the computer by using the recovery agent's local user account.

2. Click Start, click Run, type mmc, and then click OK.

3. On the File menu, click Add/Remove Snap-in. Then click Add in Windows Server
2003, in Windows XP or in Windows 2000. Or click OK in Windows Vista, in
Windows 7, in Windows Server 2008 or in Windows Server 2008 R2.

4. Under Available Standalone Snap-ins, click Certificates, and then click Add.

5. Click My user account, and then click Finish.

6. Click Close, and then click OK in Windows Server 2003, in Windows XP or in

Windows 2000. Or click OK in Windows Vista, in Windows 7, in Windows Server
2008 or in Windows Server 2008 R2.

7. Double-click Certificates - Current User, double-click Personal, and then double-

click Certificates.
 8. Locate the certificate that displays the words "File Recovery" (without the
quotation marks) in the Intended Purposes column.

9. Right-click the certificate that you located in step 8, point to All Tasks, and then
click Export. The Certificate Export Wizard starts.

10. Click Next.

11. Click Yes, export the private key, and then click Next.

12. Click Personal Information Exchange - PKCS #12 (.PFX).

７ Note

We strongly recommend that you also click to select the Enable strong
protection (requires IE 5.0, NT 4.0 SP4 or above check box to protect your
private key from unauthorized access.

If you click to select the Delete the private key if the export is successful check
box, the private key is removed from the computer and you will not be able to
decrypt any encrypted files.

13. Click Next.

14. Specify a password, and then click Next.

15. Specify a file name and location where you want to export the certificate and the
private key, and then click Next.

７ Note

We recommend that you back up the file to a disk or to a removable media

device, and then store the backup in a location where you can confirm the
physical security of the backup.

16. Verify the settings that are displayed on the Completing the Certificate Export
Wizard page, and then click Finish.

Export the domain recovery agent's private key

The first domain controller in a domain contains the built-in Administrator profile that
contains the public certificate and the private key for the default recovery agent of the
domain. The public certificate is imported to the Default Domain Policy and is applied to
domain clients by using Group Policy. If the Administrator profile or if the first domain
controller is no longer available, the private key that is used to decrypt the encrypted
files is lost, and files cannot be recovered through that recovery agent.

To locate the Encrypted Data Recovery policy, open the Default Domain Policy in the
Group Policy Object Editor snap-in, expand Computer Configuration, expand Windows
Settings, expand Security Settings, and then expand Public Key Policies.

To export the domain recovery agent's private key, follow these steps:

1. Locate the first domain controller that was promoted in the domain.

2. Log on to the domain controller by using the built-in Administrator account.

3. Click Start, click Run, type mmc, and then click OK.

4. On the File menu, click Add/Remove Snap-in. Then click Add in Windows Server
2003 or in Windows 2000. Or click OK in Windows Server 2008 or in Windows
Server 2008 R2.

5. Under Available Standalone Snap-ins, click Certificates, and then click Add.

6. Click My user account, and then click Finish.

7. Click Close, and then click OK in Windows Server 2003 or in Windows 2000. Or
click OK in Windows Server 2008 or in Windows Server 2008 R2.

8. Double-click Certificates - Current User, double-click Personal, and then double-

click Certificates.

9. Locate the certificate that displays the words "File Recovery" (without the
quotation marks) in the Intended Purposes column.

10. Right-click the certificate that you located in step 9, point to All Tasks, and then
click Export. The Certificate Export Wizard starts.

11. Click Next.

12. Click Yes, export the private key, and then click Next.

13. Click Personal Information Exchange - PKCS #12 (.PFX).

７ Note

We strongly recommend that you click to select the Enable strong protection
(requires IE 5.0, NT 4.0 SP4 or above check box to protect your private key
 from unauthorized access.

If you click to select the Delete the private key if the export is successful check
box, the private key is removed from the domain controller. As a best practice, we
recommend that you use this option. Install the recovery agent's private key only
in situations when you need it to recover files. At all other times, export, and then
store the recovery agent's private key offline to help maintain its security.

14. Click Next.

15. Specify a password, and then click Next.

16. Specify a file name and location where you want to export the certificate and the
private key, and then click Next.

７ Note

We recommend that you back up the file to a disk or to a removable media

device, and then store the backup in a location where you can confirm the
physical security of the backup.

17. Verify the settings that are displayed on the Completing the Certificate Export
Wizard page, and then click Finish.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cannot select Windows Server 2016 CA-
compatible certificate templates from
Windows Server 2016 or later-based CAs
or CEP servers
Article • 02/26/2024

This article provides a workaround for the issue Windows Server 2016 CA-compatible
certificate templates cannot be selected from Windows Server 2016 or later-based CAs
or CEP servers.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4508802

Symptoms
Consider either of the following scenarios:

You configure a Windows Server 2016-based certificate enrollment policy (CEP)

server or certificate enrollment server (CES).

You install a new Windows Server 2016 Certification Authority (CA).

You configure the compatibility settings of a certificate template by setting

Certification Authority to Windows Server 2016 and Certificate recipient to
Windows 10 / Windows Server 2016.
When Windows 10 users try to request certificates by using the CA Web enrollment
page (the CEP URL), the certificate template that you configured as described here is not
listed as an available template.

Cause
This is a known issue in Windows Server 2016 and later versions. The CEP or CES server
provides certificate templates only to clients that have the following compatibility
settings:

Certification Authority: Windows Server 2012 R2 or an earlier version

Certificate recipient: Windows 8.1 (or an earlier version) and Windows Server 2012
R2 (or an earlier version)

Workaround
To work around this issue, follow these steps:

1. Configure the compatibility settings of the certificate template as follows:

 Certificate Authority: Windows Server 2012 R2

Certificate recipient: Windows 8.1 / Windows Server 2012 R2

2. Wait 30 minutes for the CEP server to receive the updated template information (or
use the IISReset tool to restart the server).

3. On the client computer, clear the client-side Enrollment Policy Cache by using the
following command in a Command Prompt window:

Console

certutil -f -policyserver * -policycache delete

4. On the client computer, try to enroll the certificate again. The template should now
be available.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You can't share files that have multiple
EFS certificates
Article • 02/26/2024

This article describes an issue where you can't share files that are encrypted by using
multiple EFS certificates.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows 10 - all editions
Original KB number: 3118620

Symptoms
Consider the following scenario:

You would like users to share files that were encrypted by using multiple
Encrypting File System (EFS) certificates.

Users U1 and U2 have valid EFS certificates.

File F1 exists on a computer on which EFS is enabled, and users U1 and U2 have
read and write permissions on the file.

User U1 follows these steps to encrypt file F1:

1. Locate file F1 on disk.

2. Right-click on file F1.
3. Click Properties.
4. Click Advanced.
5. Select Encrypt contents to secure data.
6. Click OK.
7. Click Apply.

User U1 creates file sharing for file F1 by adding the appropriate EFS certificate for
user U2 to file F1.

Users U1 and U2 follow these steps to access file F1:

1. Locate file F1 on disk.

2. Right-click file F1.
3. Click Properties.
4. Click Advanced.
 5. Click Details.
6. Click Add.
7. Select the user whom you want to add.
8. Click OK.

User U1 or user U2 changes file F1.

In this scenario, EFS metadata is not maintained, and only the current user can decrypt
the file. However, you expect that EFS metadata will be maintained and that the user
whom you added in step 7 is still there.

Cause
If an application opens and saves a file by using the replacefile() API, and if that file
was encrypted by using EFS when more than one certificate was present, the resulting
file will contain only the certificate of the user who saved the file. This behavior is by
design.

Status
This method of sharing encrypted files is unsupported at this time.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Certificate Services (certsvc) doesn't
start after upgrade to Windows Server
2016
Article • 02/26/2024

This article provides a solution to an issue where Certificate Services (certsvc) doesn't
start after upgrade to Microsoft Windows Server 2016.

Applies to: Windows Server 2016

Original KB number: 3205641

Symptoms
After you perform an in-place upgrade of Windows Server 2012 or Windows Server
2012 R2 to Windows Server 2016, Active Directory Certificate Services (certsvc) may not
start. If you try to manually start the service from Services Management Console
(services.msc), the attempt may fail with the following error message:

Windows could not start the Active Directory Certificate Services service on Local
Computer. Error 1058: The service cannot be started, either because it is disabled or
because it has not enabled devices associated with it.

Additionally, when you try to start Active Directory Certificate Services from the
Certificate Services snap-in, it may fail, and then you receive the following error
message:

Title: Microsoft Active Directory Certificate Services

The service cannot be started, either because it is disabled or because it has not
enabled devices associated with it.
0x422 (WIN32: 1058 ERROR_SERVICE_DISABLED)

７ Note

No event is recorded in the System or Application logs when the service fails
to start.
 This issue may occur on different configurations. For example: Domain joined,
Non-Domain joined, Enterprise Certificate Authority, and Standalone
Certificate Authority

Workaround
To recover from this issue, restart the computer. Active Directory Certificate Services is
automatically started after the computer reboots.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Certificate Services may not start on a
computer that is running Windows
Server 2003 or Windows 2000
Article • 02/26/2024

This article provides a solution to an issue where Certificate Services(CS) may not start
on a computer that is running Windows Server 2003 or Windows 2000.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 842210

Symptoms
On a computer that is running Microsoft Windows Server 2003 or Microsoft Windows
2000 Server, Certificate Services may not start.

Additionally, the following error message may be logged in the Application log in Event
Viewer.

Cause
Before Certificate Services starts, it enumerates all the keys and certificates that have
been issued to the certification authority (CA), even if the keys and the certificates have
expired. Certificate Services won't start if any one of these certificates has been removed
from the local computer Personal certificate store.

Resolution
To resolve this issue, verify that the number of certificate thumbprints in the registry is
equal to the number of certificates that have been issued to the CA. If any certificates
are missing, import the missing certificates into the local computer Personal certificate
store. After you've imported the missing certificates, use the certutil -repairstore
command to repair the link between the imported certificates and the associated private
key store.

To do it, use one of the following methods, depending on which version of the
operating system your computer is running.
Method 1: Windows Server 2003
To resolve this issue on a Windows Server 2003-based computer, follow these steps.

Step 1: Look for missing certificates

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

The certificate thumbprints indicate all the certificates that have been issued to this CA.
Every time that a certificate is renewed, a new certificate thumbprint is added to the
CaCertHash list in the registry. The number of entries in this list must equal the number
of certificates that are issued to the CA and that are listed in the local computer Personal
certificate store.

To look for missing certificates, follow these steps:

1. Select Start, select Run, type regedit, and then select OK.

2. Locate and then select the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\**Y
our_Certificate_Authority_Name *

3. In the right pane, double-click CaCertHash.

4. Make a note of the number of certificate thumbprints that the Value data list
contains.

5. Start Command Prompt.

6. Type the following command, and then press ENTER: certutil -store

Compare the number of certificates that are listed in the local computer Personal
certificate store to the number of certificate thumbprints that are listed in the
CaCertHash registry entry. If the numbers are different, go to Step 2: Import the
 missing certificates. If the numbers are the same, go to Step 3: Install the Windows
Server 2003 Administration Tools Pack.

Step 2: Import the missing certificates

1. Select Start, point to All Programs, point to Administrative Tools, and then select
Certificates.

If Certificates doesn't appear in the list, follow these steps:

a. Select Start, select Run, type mmc, and then select OK.

b. On the File menu, select Add/Remove Snap-in.

c. Select Add.

d. In the Snap-in list, select Certificates, and then select Add.

If the Certificates snap-in dialog box appears, select My user account, and then
select Finish.

e. Select Close, and then select OK.

The Certificates directory is now added to Microsoft Management Console

(MMC).

f. On the File menu, select Save as, type Certificates in the File name box, and
then select Save.

To open Certificates in the future, select Start, point to All Programs, point to
Administrative Tools, and then select Certificates.

2. Expand Certificates, expand Personal, right-click Certificates, point to All Tasks,

and then select Import.

3. On the Welcome page, select Next.

4. On the File to Import page, type the full path of the certificate file that you want to
import in the File name box, and then select Next. Instead, select Browse, search
for the file, and then select Next.

5. If the file that you want to import is a Personal Information Exchange - PKCS #12
(*.PFX) file, you'll be prompted for the password. Type the password, and then
select Next.

6. On the Certificate Store page, select Next.

 7. On the Completing the Certificate Import Wizard page, select Finish.

７ Note

The CA always publishes its CA certificates to the

%systemroot%\System32\CertSvc\CertEnroll folder. You may find the missing

certificates in that folder.

Step 3: Install the Windows Server 2003 Administration

Tools Pack
After you import the certificates, you must use the Certutil tool to repair the link
between the imported certificates and the associated private key store. The Certutil tool
is included in the CA Certificate Tools. The Windows Server 2003 CA Certificate Tools are
located in the Windows Server 2003 Administration Tools Pack. If the CA Certificate Tools
aren't installed on your computer, install them now.

Step 4: Repair the links

After you install the Windows Server 2003 Administration Tools Pack, follow these steps:

1. Start Command Prompt.

2. Type the following, and then press ENTER:

cd %systemroot%\system32\certsrv\certenroll

3. Make a note of the certificate in the Certenroll folder that looks similar to the
following: Your_Server. Your_Domain.com_rootca.crt

4. Type the following commands, and then press ENTER after each command:
%systemroot%\system32\certutil -addstore my

%systemroot%\system32\certsrv\certenroll\Your_Server.Your_Domain.com_rootca.cr

t %systemroot%\System32\certutil -dump
%systemroot%\system32\certsrv\certenroll\Your_Server.Your_Domain.com_rootca.cr

t Your_Server.Your_Domain.com_rootca.crt is the name of the certificate in the

Certenroll folder that you noted in step 3.

5. In the output from the last command, near the end, you'll see a line that is similar
to the following:
Key Id Hash(sha1): ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32 1b
The Key Id Hash data is specific to your computer. Make a note of this line.
 6. Type the following command including the quotation marks, and then press
ENTER:
%systemroot%\system32\certutil -repairstore my "Key_Id_Hash_Data"

In this command, Key_Id_Hash_Data is the line that you noted in step 4. For
example, type the following:
%systemroot%\system32\certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa
71 6d f4 b7 e5 09 d9 b6 32 1b"

You'll then receive the following output:

CertUtil: -repairstore command completed successfully.

7. To verify the certificates, type the following, and then press ENTER:
%systemroot%\system32\certutil -verifykeys After this command runs, you'll

receive the following output:

CertUtil: -verifykeys command completed successfully.

Step 5: Start the Certificate Services service

1. Select Start, point to Administrative Tools, and then select Services.
2. Right-click Certificate Services, and then select Start.

Method 2: Windows 2000

To resolve this issue on a Windows 2000-based computer, follow these steps.

Step 1: Looking for missing certificates

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .
The certificate thumbprints indicate all the certificates that have been issued to this CA.
Every time that a certificate is renewed, a new certificate thumbprint is added to the
CaCertHash list in the registry. The number of entries in this list must equal the number
of certificates that are issued to the CA and that are listed in the local computer Personal
certificate store.

To look for missing certificates, follow these steps:

1. Select Start, select Run, type regedit, and then select OK.

2. Locate and then select the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\**Y

our_Certificate_Authority_Name *

3. In the right pane, double-click CaCertHash.

4. Make a note of the number of certificate thumbprints that the Value data list
contains.

5. Start Command Prompt.

6. Type the following, and then press ENTER: certutil -store

Compare the number of certificates that are listed in the local computer Personal
certificate store to the number of certificate thumbprints that are listed in the
CaCertHash registry entry. If the numbers are different, go to Step 2: Import the missing
certificates. If the numbers are the same, go to Step 3: Install the Windows Server 2003
Administration Tools Pack.

Step 2: Importing the missing certificates

1. Select Start, point to Programs, point to Administrative Tools, and then select
Certificates.

If Certificates doesn't appear in the list, follow these steps:

a. Select Start, select Run, type mmc, and then select OK.
b. On the Console menu, select Add/Remove Snap-in.
c. Select Add
d. In the Snap-in list, select Certificates, and then select Add.

If the Certificates snap-in dialog box appears, select My user account, and then
select Finish. 5. Select Close. 6. Select OK. 7. The Certificates directory is now
added to Microsoft Management Console (MMC). 8. On the Console menu, select
Save as, type Certificates as the file name, and then select Save.
 To open Certificates in the future, select Start, point to Programs, point to
Administrative Tools, and then select Certificates.

2. Expand Certificates, expand Personal, right-click Certificates, point to All Tasks,

and then select Import.

3. On the Welcome page, select Next.

4. On the File to Import page, type the full path of the certificate file that you want to
import in the File name box, and then select Next. Instead, select Browse, search
for the file, and then select Next.

5. If the file that you want to import is a Personal Information Exchange - PKCS #12
(*.PFX), you'll be prompted for the password. Type the password, and then select
Next.

6. On the Certificate Store page, select Next.

7. On the Completing the Certificate Import Wizard page, select Finish.

７ Note

The CA always publishes its CA certificates to the

%systemroot%\System32\CertSvc\CertEnroll folder. You may find the missing

certificates in that folder.

Step 3: Install the Windows Server 2003 Certutil tools

After you import the certificates, you must use the Windows Server 2003 CA Certificate
Tools to repair the link between the imported certificates and the associated private key
store.

The Windows Server 2003 versions of Certutil.exe and Certreq.exe are included in the
Windows Server 2003 Administration Tools Pack. To install the tools on a Windows 2000-
based computer, you must first install the Windows Server 2003 Administration Tools
Pack on a computer that is running Windows Server 2003 or Microsoft Windows XP with
Service Pack 1 (SP1) or with a later service pack. The Windows Server 2003
Administration Tools Pack cannot be installed directly on a Windows 2000-based
computer.

） Important
 After you copy the Windows Server 2003 CA Certificate Tools to the Windows 2000-
based computer, two versions of the Certutil tool will reside on the Windows 2000-
based computer. Don't remove the Windows 2000 Certutil tool. Other programs
depend on the Windows 2000 version of this tool. For example, the Certificates
MMC snap-in requires the Windows 2000 Certutil tool. Additionally, don't register
the Windows Server 2003 Certcli.dll and Certadm.dll files on the Windows 2000-
based computer.

To use the Windows Server 2003 CA Certificate Tools on a Windows 2000-based

computer, follow these steps:

1. Download the Windows Server 2003 Administration Tools Pack

2. Sign in to a computer that is running Windows Server 2003 or Windows XP with

SP1 or with a later service pack.

3. Install the Windows Server 2003 Administration Tools Pack.

4. In the Windows Server 2003 Administration Tools Pack, locate the following files,
and then copy them to a removable storage medium, such as a 3.5-inch disk:
Certreq.exe
Certutil.exe
Certcli.dll
Certadm.dll

5. Sign in to the Windows 2000-based computer as an administrator.

6. Insert the removable storage medium that you used in step 4 into the appropriate
drive of the Windows 2000-based computer.

7. Start Command Prompt.

8. Make a new folder, and then copy the files on the removable storage medium to
the new folder. To do it, type the following commands, and then press ENTER after
each command:
cd\
md W2k3tool
cd w2k3tool
copy Removable_Media_Drive_Letter:\cert*

７ Note
 To avoid conflicts with the Windows 2000 versions of the Certutil tool that is
already on the computer, do not include the W2k3tool folder in your system
search path.

Step 4: Repairing the links

After you've copied the Windows Server 2003 CA Certificate Tools files to the Windows
2000-based computer, follow these steps:

1. Start Command Prompt.

2. Type the following, and then press ENTER:

cd %systemroot\system32\certsrv\certenroll

3. Make a note of the certificate in the Certenroll folder that looks similar to the
following:
Your_Server.Your_Domain.com_rootca.crt

4. Type the following commands, and then press ENTER after each command:
Root_Drive_Letter:\w2k3tool\certutil -addstore my
%systemroot%\system32\certsrv\certenroll\
Your_Server.Your_Domain.com_rootca.crt
Root_Drive_Letter:\w2k3tool\certutil -dump
%systemroot%\system32\certsrv\certenroll\
Your_Server.Your_Domain.com_rootca.crt

Root_Drive_Letter is the letter of the root directory.

Your_Server.Your_Domain.com_rootca.crt is the name of the certificate in the

Certenroll folder that you noted in step 3.

5. In the output from the last command, near the end, you'll see a line that is similar
to the following: Key Id Hash(sha1): ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5
09 d9 b6 32 1b
The Key Id Hash data is specific to your computer. Make a note of this line.

6. Type the following command, including the quotation marks, and then press
ENTER:
Root_Drive_Letter:\w2k3tool\certutil -repairstore my "Key_Id_Hash_Data"
In this command, Key_Id_Hash_Data is the line that you noted in step 5. For
example, type the following:
c:\w2k3tool\certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5
09 d9 b6 32 1b"
 After you've completed this command, you'll receive the following output:

CertUtil: -repairstore command completed successfully.

7. To verify the certificates, type the following command, and then press ENTER:
Root_Drive_Letter:\w2k3tool\certutil -verifykeys

After this command runs, you'll receive the following output:

CertUtil: -verifykeys command completed successfully.

Step 5: Starting the Certificate Services service

1. Select Start, point to Administrative Tools, and then select Services.
2. Right-click Certificate Services, and then select Start.

More information
You must decommission and replace the CA if one of the following conditions is true:

You can't locate the missing certificates.

The certificates can't be reinstalled.

The certutil -repairstore command can't be completed because the private keys
have been removed. To decommission and to replace the CA, follow these steps:

1. Revoke the certificates for the CA that has stopped working correctly. To do
it, follow these steps:
a. Sign in as an administrator to the computer that issued the certificates that
you want to revoke.
b. Select Start, point to Programs, point to Administrative Tools, and then
select Certification Authority.
c. Expand CA_Name, and then select Issued Certificates.
d. In the right-pane, select the certificate that you want to revoke.
e. On the Action menu, point to All Tasks, and then select Revoke
Certificate.
f. In the Reason code list, select the reason for revoking the certificate, and
then select Yes.

This will revoke all the certificates that were issued by the CA that has
stopped working correctly.
 2. Publish the certificate revocation list (CRL) on the next-highest CA. To do it,
follow these steps:
a. Sign in as an administrator to the computer that is running the next
highest CA.
b. Select Start, point to Programs, point to Administrative Tools, and then
select Certification Authority.
c. Expand CA_Name, and then select Revoked Certificates.
d. On the Action menu, point to All Tasks, and then select Publish.
e. Select Yes to overwrite the previously published CRL.

3. If the CA that has stopped working correctly has been published to Active
Directory directory services, remove it. To remove the CA from Active
Directory, follow these steps:
a. Start Command Prompt.
b. Type the following, and then press ENTER:
certutil -dsdel CA_Name

4. Remove Certificate Services from the server where the CA has stopped
working correctly. To do it, follow these steps:
a. Select Start, point to Settings, and then select Control Panel.
b. Double-click Add/Remove Programs, and then select Add/Remove
Windows Components.
c. In the Components list, click to clear the Certificate Services check box,
select Next, and then select Finish.

5. Install Certificate Services. To do it, follow these steps:

a. Select Add/Remove Windows Components.
b. In the Components list, select to select the Certificate Services check box,
select Next, and then select Finish.

6. All the users, the computers, or the services with certificates that were issued
by the CA that has stopped working correctly must enroll for certificates from
the new CA.

７ Note

If this issue occurs on the Root CA of the public key infrastructure (PKI) hierarchy
and if the issue cannot be repaired, you will have to replace the whole PKI
hierarchy. For more information about how to remove the PKI hierarchy, see How
to decommission a Windows enterprise certification authority and remove all
related objects.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Change the expiration date of
certificates that are issued by Certificate
Authority
Article • 02/26/2024

This article describes how to change the validity period of a certificate that is issued by
Certificate Authority (CA).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 254632

Summary
By default, the lifetime of a certificate that is issued by a Stand-alone Certificate
Authority CA is one year. After one year, the certificate expires and is not trusted for use.
There may be situations when you have to override the default expiration date for
certificates that are issued by an intermediate or an issuing CA.

The validity period that is defined in the registry affects all certificates that are issued by
Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two
years. For Stand-alone CAs, the default registry setting is one year. For certificates that
are issued by Stand-alone CAs, the validity period is determined by the registry entry
that is described later in this article. This value applies to all certificates that are issued
by the CA.

For certificates that are issued by Enterprise CAs, the validity period is defined in the
template that is used to create the certificate. Windows 2000 and Windows Server 2003
Standard Edition do not support modification of these templates. Windows Server 2003
Enterprise Edition supports Version 2 certificate templates that can be modified. The
validity period defined in the template applies to all certificates issued by any Enterprise
CA in the Active Directory forest. A certificate that is issued by a CA is valid for the
minimum of the following periods of time:

The registry validity period that is noted earlier in this article.

This applies to the stand-alone CA, and Subordinate CA certificates issued by the
Enterprise CA.

The template validity period.

This applies to the Enterprise CA. Templates supported by Windows 2000 and Windows
Server 2003 Standard Edition cannot be modified. Templates supported by Windows
Server Enterprise Edition (Version 2 templates) do support modification.

For an Enterprise CA, the validity period of an issued certificate is set to the minimum of
all the following:

The registry validity period of the CA (for example: ValidityPeriod == Years,

ValidityPeriodUnits == 1)
The template validity period
The remaining validity period of the signing certificate of the CA
If the EDITF_ATTRIBUTEENDDATE bit is enabled in the policy module's EditFlags
registry value, the validity period specified through the request attributes
(ExpirationDate:Date or ValidityPeriod:Years\nValidityPeriodUnits:1)

７ Note

The ExpirationDate:Date syntax was not supported until Windows Server 2008.
For a stand-alone CA, no templates are processed. Therefore, the template
validity period does not apply.

The expiration date of the CA certificate

A CA cannot issue a certificate with a longer validity period than its own CA certificate.

７ Note

The Request Attribute name is made up of value string pairs that accompany the
request and that specify the validity period. By default, this is enabled by a registry
setting on a Standalone CA only.

Change expiration date of certificates issued by

CA
To change the validity period settings for a CA, follow these steps.

） Important
This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

1. Click Start, and then click Run.

2. In the Open box, type regedit, and then click OK.

3. Locate, and then click the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\

<CAName>

4. In the right pane, double-click ValidityPeriod.

5. In the Value data box, type one of the following, and then click OK:

Days
Weeks
Months
Years

6. In the right pane, double-click ValidityPeriodUnits.

7. In the Value data box, type the numeric value that you want, and then click OK. For
example, type 2.

8. Stop, and then restart the Certificate Services service. To do so:

a. Click Start, and then click Run.

b. In the Open box, type cmd, and then click OK.

c. At the command prompt, type the following lines. Press ENTER after each line.

Console

net stop certsvc

net start certsvc

d. Type exit to quit Command Prompt.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Steps to disable TLS 1.0 and 1.1 on
MBAM servers and force the use of TLS
1.2
Article • 02/26/2024

This article describes the steps to disable the Transport Layer Security (TLS) 1.0 and 1.1
on the Microsoft BitLocker Administration and Monitoring (MBAM) servers and force the
use of TLS 1.2.

Applies to: Windows 10 – all editions, Windows Server 2012 R2

Original KB number: 4558055

Symptoms
Microsoft is planning to disable older TLS protocols, in preparation for disabling TLS 1.0
and TLS 1.1 by default. See Plan for change: TLS 1.0 and TLS 1.1 soon to be disabled by
default .

For enterprise customers, it may require disabling TLS 1.0 and 1.1 in their environment
for Microsoft BitLocker Administration and Monitoring (MBAM) Infrastructure.

Resolution
Follow these steps to disable TLS 1.0 and 1.1 on MBAM servers, and force the use of TLS
1.2.

1. Download and install the latest available version of Microsoft .NET Framework on
all MBAM servers that are：

Web Servers running IIS roles

SQL Servers running SQL Server database Engine, and SQL Server Reporting
Services

Refer to: Microsoft .NET Framework 4.8 offline installer for Windows

2. Execute the PowerShell scripts below. They're used to disable TLS 1.0 and 1.1, and
force the use only TLS 1.2.

3. Reboot the servers, then test the MBAM web applications. Confirm that the MBAM
clients can communicate with the server to back up recovery information.
<Tighten_DotNet.PS1>

PowerShell

#Tighten up the .NET Framework

$NetRegistryPath = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value
"1" -PropertyType DWORD -Force | Out-Null
$NetRegistryPath =
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value
"1" -PropertyType DWORD -Force | Out-Null

<Force_TLS1.2.PS1>

PowerShell

$ProtocolList = @("SSL 2.0","SSL 3.0","TLS 1.0", "TLS 1.1", "TLS 1.2")

$ProtocolSubKeyList = @("Client", "Server")
$DisabledByDefault = "DisabledByDefault"
$Enabled = "Enabled"
$registryPath =
"HKLM:\\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocol
s\"

foreach($Protocol in $ProtocolList)
{
Write-Host " In 1st For loop"
foreach($key in $ProtocolSubKeyList)
{
$currentRegPath = $registryPath + $Protocol + "\" + $key
Write-Host " Current Registry Path $currentRegPath"

if(!(Test-Path $currentRegPath))
{
Write-Host "creating the registry"
New-Item -Path $currentRegPath -Force | out-Null

}
if($Protocol -eq "TLS 1.2")
{
Write-Host "Working for TLS 1.2"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "0" -
PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "1" -
PropertyType DWORD -Force | Out-Null

}
else
{
Write-Host "Working for other protocol"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "1" -
 PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "0" -
PropertyType DWORD -Force | Out-Null
}
}
}
Exit 0

More information
Transport Layer Security (TLS) registry settings

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DPAPI MasterKey backup failures when
RWDC isn't available
Article • 02/26/2024

This article provides a solution to solve DPAPI MasterKey backup failures that occur when
RWDC isn't available.

Applies to: Windows 10, version 1809, Windows Server 2012 R2, Windows Server 2016,
Windows Server 2019
Original KB number: 3205778

Symptoms
The following behavior occurs in Windows 8.1 and Windows Server 2012 R2 after you
install MS14-066, KB2992611, KB3000850, or newer updates that include these fixes.
The same behavior also occurs in all versions of Windows 10 and later versions of
Windows. Domain users who log on for the first time to a new computer in a site that's
serviced by a read-only domain controller (RODC) experience the following errors and
problems.

Generic problems
1. Opening Credential Manager fails with a 0x80090345 error, which maps to the following:

ﾉ Expand table

Hex Decimal Symbolic Friendly

0x80090345 -2146892987 SEC_E_DELEGATION_REQUIRED The requested operation cannot be

completed. The computer must be
trusted for delegation and the
current user account must be
configured to allow delegation.

2. Saving an RDP password fails with no apparent error.

3. Password changes take longer than expected to complete.

4. Explorer hangs when you're encrypting a file.

5. In Office and Office 365, adding a new account in Windows Live Mail 2012 fails with error
0x80090345.

6. Outlook profile creation fails with the following error:

 An encrypted connection to your mail server is not available.

7. Signing into Lync and Skype hangs or experiences a long delay during the "Contacting
server and signing in" stage.

8. SQL service fails to start under a domain account and triggers the following error:

Unable to initialize SSL encryption because a valid certificate could not be found, and
it is not possible to create a self-signed certificate.

9. SQL Server installation fails with the following error:

Error(s): SQL server setup has encountered the following error: "generating the XML
document error code 0x8410001.

10. Domain users can't manage SQL databases from SMSS. (SQL Server Management Studio).
This issue occurs when the database is navigated from via SSMS DataBases ->
CustomerDatabase -> Tables -> Table name.

If you right-click the table and then select Design, the following error occurs:

The requested operation cannot be completed. The computer must be trusted for
delegation and the current user account must be configured to allow delegation. This
exception originated from
System_Security_ni!System.Security.Cryptography.ProtectedData.Protect(Byte[], Byte[],
System.Security.Cryptography.DataProtectionScope)."

11. ADFS WAP installation fails to create a self-signed certificate and triggers the following
error:

Exception: An error occurred when attempting to create the proxy trust certificate.

12. ADLDS installation in an RODC-only covered site fails with the following error:

Type a valid user and password for selected service account

a. In this situation, the AdamInstall.log shows the following:

adamsetup D20.10F8 0255 15:30:22.002 Enter GetServiceAccountError

adamsetup D20.10F8 0256 15:30:22.002 Type a valid user name and password for
the selected service account.
adamsetup D20.10F8 0257 15:30:22.002 ADAMERR_SERVICE_INVALID_CREDS
b. A sample network trace taken during the failure shows that ADLDS is sending an
incorrect password and Kerberos TGT request fails with KDC_ERR_PREAUTH_FAILED:

ﾉ Expand table

Source Destination Protocol Description

ADLDS RODC KerberosV5 AS Request Cname: ADLDSSvc Realm: CONTOSO Sname:

krbtgt/contoso {TCP:375, IPv4:7}

RODC ADLDS KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_FAILED

(24) {TCP:376, IPv4:7}

c. Event ID 4625 is logged in the Security log of the ADLDS server, as follows:

Event ID: 4625

Keywords: Audit Failure
Description: An account failed to log on.
..
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC000006A
..
Process Information:
Caller Process Name: C:\Windows\ADAM\adaminstall.exe

Where the Status and Sub status translates to:

ﾉ Expand table

Hex Decimal Symbolic Friendly

0xc000006a -1073741718 STATUS_WRONG_PASSWORD When trying to update a

password, this return status
indicates that the value
provided as the current
password is not correct.

0xc000006d -1073741715 STATUS_LOGON_FAILURE The attempted logon is invalid.

This is either due to a bad user
name or authentication
information.

In all cases, the NETLOGON.LOG shows DsGetDcName request making calls for
writable domain controllers:

[MISC] [3736] DsGetDcName function called: client PID=568, Dom:VS Acct:(null)

Flags: DS WRITABLE NETBIOS RET_DNS
 [CRITICAL] [3736] NetpDcMatchResponse: CON-DC4: CONTOSO.COM .: Responder is
not a writable server.

[MISC] [2600] DsGetDcName function returns 1355 (client PID=564): Dom:VS

Acct:(null) Flags: FORCE DS WRITABLE NETBIOS RET_DNS

Where:

ﾉ Expand table

Hex Decimal Symbolic Friendly

0x54b 1355 ERROR_NO_SUCH_DOMAIN The specified domain either does not exist
or could not be contacted.

Cause
When a user logs on to a computer for the first time and tries to encrypt data for the first time,
the operating system must create a preferred DPAPI MasterKey, which is based on the user's
current password. During the creation of the DPAPI MasterKey, An attempt is made to back up
this master key by contacting an RWDC. If the backup fails, the MasterKey cannot be created
and a 0x80090345 error is returned.

This failure is new behavior, which was introduced by KB2992611 . In older operating systems
and on systems that don't have KB2992611 installed, if the client fails to contact an RWDC
during backup of the MasterKey, the creation of the master key is still allowed, and a local
backup is created.

That is, the legacy behavior performs a local backup of the master key if no RWDC is available.

Consistent with the design brief that RODCs don't store secrets, RODCs do not store or handle
the backup of the MasterKey. Therefore, in sites where no RWDC is available, the issues that are
described in the "Symptoms" section may occur.

７ Note

When a preferred master key exists but has expired (expired password case), an attempt
to generate a new master key is made. If it's not possible to create a domain backup of
the new master key, the client falls back to the old one, and the behavior that's described
in the "Symptoms" section does not occur.

The problem occurs only if there's no MasterKey present and when the user has not logged on
to the computer before.
Resolution
1. Verify that domain-joined workstations and servers where the issue occurs have access to
RWDCs.

Run the following command line to verify that an RWDC exists and is in a healthy state:

Console

nltest /dsgetdc:<domain> /writable [/force]

Use NETLOGON.LOG and a network trace with the provided log examples in this article to
verify name resolution and connectivity to an RWDC.
To determine whether you're experiencing this issue, try opening CREDMAN in Control
Panel. If the attempt fails with a 0x80090345 error, you have verified this.

2. If possible, take the computer to a site where an RWDC exists and then log on there for
the first time. After this, the DPAPI MasterKey will be created, and the issue will be
resolved.

3. If you have no access to an RWDC and if the user will not be roaming between machines,
the following registry entry can be used to resolve the issue.

Setting this value to 1 causes DPAPI master keys to be backed up locally instead of using
a domain backup. Additionally, any previously created keys do not trigger calls for a
writable domain controller except in limited cases as explained below. This registry setting
applies only to domain accounts. Local accounts always use local backups.

ﾉ Expand table

Path HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-
1501-11d1-8c7a-00c04fc297eb

Setting ProtectionPolicy

Data DWORD
Type

Value 1

OS Yes
restart
requested

Notes OS

２ Warning
 Don't use this registry key if domain users log on to more than one computer! Because
the keys are backed up locally, any non-local password change may trigger a situation in
which all DPAPI master keys are wrapped using the old password, and then domain
recovery is not possible. This registry key should be set only in an environment in which
data loss is acceptable.

More information
ﾉ Expand table

Topic Details

Windows Data Windows Data Protection

Protection
Key backup and restoration in DPAPI
When a computer is a member of a domain, DPAPI has a backup mechanism to allow
unprotection of the data. When a MasterKey is generated, DPAPI talks to a Domain
Controller. Domain Controllers have a domain-wide public/private key pair, associated
solely with DPAPI. The local DPAPI client gets the domain controller public key from a
domain controller by using a mutually authenticated and privacy protected RPC call.
The client encrypts the MasterKey with the domain controller public key. It then stores
this backup MasterKey along with the MasterKey protected by the user's password.
While unprotecting data, if DPAPI cannot use the MasterKey protected by the user's
password, it sends the backup MasterKey to a Domain Controller by using a mutually
authenticated and privacy protected RPC call. The domain controller then decrypts the
MasterKey with its private key and sends it back to the client by using the same
protected RPC call. This protected RPC call is used to ensure that no one listening on
the network can get the MasterKey.

RODC RODC Placement Considerations

Placement
Considerations

Linked KB that November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server
changes the 2012 R2 (KB3000850)
behavior/starts
this issue.

Backup Key Appendix B: Product Behavior

Remote Performing Client-Side Wrapping of Secrets
Protocol doc
A BackupKey Remote Protocol server does not actually perform remote backup of
secrets. Instead, the server wraps each secret and returns it to the client. The client is
responsible for storing the secret until it is needed again, at which point the client can
request the server to unwrap the secret

See 3.1.4.1.3 BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Guidelines for enabling smart card
logon with third-party certification
authorities
Article • 02/26/2024

This article provides some guidelines for enabling smart card logon with third-party
certification authorities.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 281245

Summary
You can enable a smart card logon process with Microsoft Windows 2000 and a non-
Microsoft certification authority (CA) by following the guidelines in this article. Limited
support for this configuration is described later in this article.

More information

Requirements
Smart Card Authentication to Active Directory requires that Smartcard workstations,
Active Directory, and Active Directory domain controllers be configured properly. Active
Directory must trust a certification authority to authenticate users based on certificates
from that CA. Both Smartcard workstations and domain controllers must be configured
with correctly configured certificates.

As with any PKI implementation, all parties must trust the Root CA to which the issuing
CA chains. Both the domain controllers and the smartcard workstations trust this root.

Active Directory and domain controller configuration

Required: Active Directory must have the third-party issuing CA in the NTAuth
store to authenticate users to active directory.
Required: Domain controllers must be configured with a domain controller
certificate to authenticate smartcard users.
Optional: Active Directory can be configured to distribute the third-party root CA
to the trusted root CA store of all domain members using the Group Policy.
Smartcard certificate and workstation requirements
Required: All of the smartcard requirements outlined in the "Configuration
Instructions" section must be met, including the text formatting of the fields.
Smartcard authentication fails if they are not met.
Required: The smartcard and private key must be installed on the smartcard.

Configuration instructions
1. Export or download the third-party root certificate. How to obtaining the party
root certificate varies by vendor. The certificate must be in Base64 Encoded X.509
format.

2. Add the third-party root CA to the trusted roots in an Active Directory Group
Policy object. To configure Group Policy in the Windows 2000 domain to distribute
the third-party CA to the trusted root store of all domain computers:
a. Click Start, point to Programs, point to Administrative Tools, and then click
Active Directory Users and Computers.
b. In the left pane, locate the domain in which the policy you want to edit is
applied.
c. Right-click the domain, and then click Properties.
d. Click the Group Policy tab.
e. Click the Default Domain Policy Group Policy object, and then click Edit. A new
window opens.
f. In the left pane, expand the following items:

Computer Configuration
Windows Settings
Security Settings
Public Key Policy

g. Right-click Trusted Root Certification Authorities.

h. Select All Tasks, and then click Import.
i. Follow the instructions in the wizard to import the certificate.
j. Click OK.
k. Close the Group Policy window.

3. Add the third party issuing the CA to the NTAuth store in Active Directory.

The smart card logon certificate must be issued from a CA that is in the NTAuth
store. By default, Microsoft Enterprise CAs are added to the NTAuth store.
 If the CA that issued the smart card logon certificate or the domain controller
certificates is not properly posted in the NTAuth store, the smart card logon
process does not work. The corresponding answer is "Unable to verify the
credentials".

The NTAuth store is located in the Configuration container for the forest. For
example, a sample location is as follows:
LDAP://server1.name.com/CN=NTAuthCertificates,CN=Public Key
Services,CN=Services,CN=Configuration,DC=name,DC=com

By default, this store is created when you install a Microsoft Enterprise CA.
The object can also be created manually by using ADSIedit.msc in the
Windows 2000 Support tools or by using LDIFDE. For more information, click
the following article number to view the article in the Microsoft Knowledge
Base:

295663 How to import third-party certification authority (CA) certificates

into the Enterprise NTAuth store

The relevant attribute is cACertificate, which is an octet String, multiple-

valued list of ASN-encoded certificates.

After you put the third-party CA in the NTAuth store, Domain-based Group
Policy places a registry key (a thumbprint of the certificate) in the following
location on all computers in the domain:

HKEY_LOCAL_MACHINE\Software\Microsoft\EnterpriseCertificates\NTAuth\Ce
rtificates

It is refreshed every eight hours on workstations (the typical Group Policy

pulse interval).

4. Request and install a domain controller certificate on the domain controller(s).

Each domain controller that is going to authenticate smartcard users must have a
domain controller certificate.

If you install a Microsoft Enterprise CA in an Active Directory forest, all domain

controllers automatically enroll for a domain controller certificate. For more
information about requirements for domain controller certificates from a third-
party CA, click the following article number to view the article in the Microsoft
Knowledge Base:

291010 Requirements for domain controller certificates from a third-party CA

 ７ Note

The domain controller certificate is used for Secure Sockets Layer (SSL)
authentication, Simple Mail Transfer Protocol (SMTP) encryption, Remote
Procedure Call (RPC) signing, and the smart card logon process. Using a non-
Microsoft CA to issue a certificate to a domain controller may cause
unexpected behavior or unsupported results. An improperly formatted
certificate or a certificate with the subject name absent may cause these or
other capabilities to stop responding.

5. Request a smart card certificate from the third-party CA.

Enroll for a certificate from the third-party CA that meets the stated requirements.
The method for enrollment varies by the CA vendor.

The smart card certificate has specific format requirements:

The CRL Distribution Point (CDP) location (where CRL is the Certification
Revocation List) must be populated, online, and available. For example:

Output

[1]CRL Distribution Point

Distribution Point Name:
Full Name:
URL=http://server1.name.com/CertEnroll/caname.crl

Key Usage = Digital Signature

Basic Constraints [Subject Type=End Entity, Path Length Constraint=None]

(Optional)

Enhanced Key Usage =

Client Authentication (1.3.6.1.5.5.7.3.2)
(The client authentication OID) is only required if a certificate is used for
SSL authentication.)
Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Subject Alternative Name = Other Name: Principal Name= (UPN). For

example:
UPN = [email protected]
The UPN OtherName OID is: "1.3.6.1.4.1.311.20.2.3"
The UPN OtherName value: Must be ASN1-encoded UTF8 string
 Subject = Distinguished name of user. This field is a mandatory extension, but
the population of this field is optional.

6. There are two predefined types of private keys. These keys are Signature
Only(AT_SIGNATURE) and Key Exchange(AT_KEYEXCHANGE). Smartcard logon
certificates must have a Key Exchange(AT_KEYEXCHANGE) private key type in
order for smartcard logon to function correctly.

7. Install smartcard drivers and software to the smartcard workstation.

Make sure that the appropriate smartcard reader device and driver software are
installed on the smartcard workstation. It varies by smartcard reader vendor.

8. Install the third-party smartcard certificate to the smartcard workstation.

If the smartcard was not already put into the smartcard user's personal store in the
enrollment process in step 4, then you must import the certificate into the user's
personal store. To do so:

a. Open the Microsoft Management Console (MMC) that contains the Certificates
snap-in.

b. In the console tree, under Personal, click Certificates.

c. On the All Tasks menu, click Import to start the Certificate Import Wizard.

d. Click the file that contains the certificates that you are importing.

７ Note

If the file that contains the certificates is a Personal Information Exchange

(PKCS #12) file, type the password that you used to encrypt the private key,
click to select the appropriate check box if you want the private key to be
exportable, and then turn on strong private key protection (if you want to
use this feature).

７ Note

To turn on strong private key protection, you must use the Logical
Certificate Stores view mode.

e. Select the option to automatically put the certificate in a certificate store based
on the type of certificate.
 9. Install the third-party smartcard certificate onto the smartcard. This installation
varies according to Cryptographic Service Provider (CSP) and by smartcard vendor.
See the vendor's documentations for instructions.

10. Log on to the workstation with the smartcard.

Possible issues
During smartcard logon, the most common error message seen is:

The system could not log you on. Your credentials could not be verified.

This message is a generic error and can be the result of one or more of below issues.

Certificate and configuration problems

The domain controller has no domain controller certificate.

The SubjAltName field of the smartcard certificate is badly formatted. If the

information in the SubjAltName field appears as Hexadecimal / ASCII raw data, the
text formatting is not ASN1 / UTF-8.

The domain controller has an otherwise malformed or incomplete certificate.

For each of the following conditions, you must request a new valid domain
controller certificate. If your valid domain controller certificate has expired, you
may renew the domain controller certificate, but this process is more complex and
typically more difficult than if you request a new domain controller certificate.
The domain controller certificate has expired.
The domain controller has an untrusted certificate. If the NTAuth store does not
contain the certification authority (CA) certificate of the domain controller
certificate's issuing CA, you must add it to the NTAuth store or obtain a DC
certificate from an issuing CA whose certificate resides in the NTAuth store.

If the domain controllers or smartcard workstations do not trust the Root CA to

which the domain controller's certificate chains, then you must configure those
computers to trust that Root CA.

The smartcard has an untrusted certificate. If the NTAuth store does not contain
the CA certificate of the smartcard certificate's issuing CA, you must add it to the
NTAuth store or obtain a smartcard certificate from an issuing CA whose certificate
resides in the NTAuth store.
If the domain controllers or smartcard workstations do not trust the Root CA to
which the user's smartcard certificate chains, then you must configure those
computers to trust that Root CA.

The certificate of the smart card is not installed in the user's store on the
workstation. The certificate that is stored on the smartcard must reside on the
smartcard workstation in the profile of the user who is logging on with the smart
card.

７ Note

You do not have to store the private key in the user's profile on the
workstation. It is only required to be stored on the smartcard.

The correct smartcard certificate or private key is not installed on the smartcard.
The valid smartcard certificate must be installed on the smartcard with the private
key and the certificate must match a certificate stored in the smartcard user's
profile on the smartcard workstation.

The certificate of the smart card cannot be retrieved from the smartcard reader. It
can be a problem with the smartcard reader hardware or the smartcard reader's
driver software. Verify that you can use the smartcard reader vendor's software to
view the certificate and the private key on the smartcard.

The smartcard certificate has expired.

No User Principal Name (UPN) is available in the SubjAltName extension of the

smartcard certificate.

The UPN in SubjAltName field of the smartcard certificate is badly formatted. If the
information in the SubjAltName appears as Hexadecimal / ASCII raw data, the text
formatting is not ASN1 / UTF-8.

The smartcard has an otherwise malformed or incomplete certificate. For each of

these conditions, you must request a new valid smartcard certificate and install it
onto the smartcard and into the profile of the user on the smartcard workstation.
The smartcard certificate must meet the requirements described earlier in this
article, which include a correctly formatted UPN field in the SubjAltName field.

If your valid smartcard certificate has expired, you may also renew the smartcard
certificate, which is more complex and difficult than requesting a new smartcard
certificate.
 The user does not have a UPN defined in their Active Directory user account. The
user's account in the Active Directory must have a valid UPN in the
userPrincipalName property of the smartcard user's Active Directory user account.

The UPN in the certificate does not match the UPN defined in the user's Active
Directory user account. Correct the UPN in the smartcard user's Active Directory
user account or reissue the smartcard certificate so that the UPN value in the
SubjAltName field the matches the UPN in smartcard users' Active Directory user
account. We recommend that the smart card UPN matches the userPrincipalName
user account attribute for third-party CAs. However, if the UPN in the certificate is
the "implicit UPN" of the account (format samAccountName@domain_FQDN), the
UPN does not have to match the userPrincipalName property explicitly.

Revocation checking problems

If the revocation checking fails when the domain controller validates the smart card
logon certificate, the domain controller denies the logon. The domain controller may
return the error message mentioned earlier or the following error message:

The system could not log you on. The smartcard certificate used for authentication
was not trusted.

７ Note

Failing to find and download the Certificate Revocation List (CRL), an invalid CRL, a
revoked certificate, and a revocation status of "unknown" are all considered
revocation failures.

The revocation check must succeed from both the client and the domain controller.
Make sure the following are true:

Revocation checking is not turned off.

Revocation check for the built-in revocation providers cannot be turned off. If a
custom installable revocation provider is installed, it must be turned on.

Every CA Certificate except the root CA in the certificate chain contains a valid CDP
extension in the certificate.

The CRL has a Next Update field and the CRL is up to date. You can check that the
CRL is online at the CDP and valid by downloading it from Internet Explorer. You
should be able to download and view the CRL from any of the HyperText Transport
 Protocol (HTTP) or File Transfer Protocol (FTP) CDPs in Internet Explorer from both
the smartcard workstation(s) and the domain controller(s).

Verify that each unique HTTP and FTP CDP that is used by a certificate in your enterprise
is online and available.

To verify that a CRL is online and available from an FTP or HTTP CDP:

1. To open the Certificate in question, double-click on the .cer file or double-click the
certificate in the store.
2. Click the Details tab, and select the CRL Distribution Point field.
3. In the bottom pane, highlight the full FTP or HTTP Uniform Resource Locator (URL)
and copy it.
4. Open Internet Explorer and paste the URL into the Address bar.
5. When you receive the prompt, select the option to Open the CRL.
6. Make sure that there is a Next Update field in the CRL and the time in the Next
Update field has not passed.

To download or verify that a Lightweight Directory Access Protocol (LDAP) CDP is valid,
you must write a script or an application to download the CRL. After you download and
open the CRL, make sure that there is a Next Update field in the CRL and the time in the
Next Update field has not passed.

Support
Microsoft Product Support Services does not support the third-party CA smart card
logon process if it is determined that one or more of the following items contributes to
the problem:

Improper certificate format.

Certificate status or revocation status not available from the third-party CA.
Certificate enrollment issues from a third-party CA.
The third-party CA cannot publish to Active Directory.
A third-party CSP.

Additional information
The client computer checks the domain controller's certificate. The local computer
therefore downloads a CRL for the domain controller certificate into the CRL cache.

The offline logon process does not involve certificates, only cached credentials.
To force the NTAuth store to be immediately populated on a local computer instead of
waiting for the next Group Policy propagation, run the following command to initiate a
Group Policy update:

Console

dsstore.exe -pulse

You can also dump out the smart card information in Windows Server 2003 and in
Windows XP by using the Certutil.exe -scinfo command.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Applications experience forcibly closed
TLS connection errors when connecting
SQL Servers in Windows
Article • 02/26/2024

This article helps fix an issue that occurs when an application tries to open a connection
to a SQL Server.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4557473

Symptoms
When an application tries to open a connection to a SQL Server, one of the following
error messages is displayed:

A connection was successfully established with the server, but then an error
occurred during the login process. (provider: SSL Provider, error: 0 - An existing
connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An
existing connection was forcibly closed by the remote host.)

If you enabled SChannel logging on the Server, you'll receive Event ID 36888 (A Fatal
Alert was generated) when the issue occurs.

７ Note

Depending on the provider or driver that you're using, the error message may
slightly vary.
This issue also occurs when an application running on Windows Server 2012
R2 tries to connect to SQL Server running on Windows Server 2019.
Other client-server applications may encounter a similar issue.

Cause
Windows 10, version 1511 and later versions of Windows, including Window Server 2016
or Windows 10, version 1607 that has updates released on Feb 25thor later updates
installed, contains a leading zero update. Meanwhile, all Windows versions that released
before that don't contain the leading zero updates.

The TLS client and server need to calculate keys exactly the same way otherwise they get
different results. TLS connections randomly fail if leading zeros are computed differently
by the TLS client and TLS Servers.

When a Diffie-Hellman key exchange group has leading zeros, unpatched computers
may incorrectly compute the mac by not accounting for the padded zeros. This issue is
typically seen when interacting with non-Windows-based crypto implementations and
can cause intermittent negotiation failures.

The error messages are returned when the secure TLS handshake is negotiated between
the client and the server by using TLS_DHE cipher suite. The use of one of the affected
cipher suites can be identified in the "Server Hello" packet. For more information, see
the network snippet in the "More information" section.

Resolution
To fix this issue, make sure that both the client and server involved in a connection are
running Windows that have the leading zero fixes for TLS_DHE installed. It's
recommended to install the updates since they enhance the conformance to TLS_DHE
specifications.

The following list the operating system version according to the updates that are
installed.

Windows versions that contain the leading zero fixes for

TLS_DHE
Windows Server 2016, version 1607
KB 4537806: February 25, 2020-KB4537806 (OS Build 14393.3542)
KB 4540670: March 10, 2020-KB4540670 (OS Build 14393.3564)
Updates that supersede KB4537806 and KB4540670 for the respective OS
versions
Windows Server 2019 RTM and later versions.
Windows 10, version 1511, and later versions of Windows 10 (see release history )
Windows versions that don't contain the leading zero
fixes for TLS_DHE
Windows Server 2016, version 1607 servers that don't have the patches KB
4537806 and KB 4540670 applied.
Windows 10, version 1507
Windows 8.1
Windows 7
Windows Server 2012 R2 and earlier versions of Windows Server

Workaround
If you can't update Windows, as a workaround, you can disable the TLS_DHE ciphers by
using one of the two methods.

Using Group Policy

TLS_DHE_* ciphers can be disabled by using Group Policy. Refer to Prioritizing Schannel
Cipher Suites to configure the "SSL Cipher Suite Order" group policy.

Policy URL: Computer Configuration -> Administrative Templates -> Network -> SSL
Configuration Settings
Policy Setting: SSL Cipher Suite Order setting.​

Using a PowerShell script

PowerShell

foreach ($CipherSuite in $(Get-TlsCipherSuite).Name)

{
if ( $CipherSuite.substring(0,7) -eq "TLS_DHE" )
{
"Disabling cipher suite: " + $CipherSuite
Disable-TlsCipherSuite -Name $CipherSuite
}
else
{
"Existing enabled cipher suite will remain enabled: " + $CipherSuite
}
}

More information
You can confirm that you're encountering this issue during the connection
establishment. When the issue occurs, you can see the following sequence in the
network trace on the server.

Output

1103479 <DateTime> 382.4104867 <Application IP> <Server IP>

TCP:Flags=CE....S., SrcPort=62702, DstPort=1433, PayloadLen=0,
Seq=829174047, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
1103486 <DateTime> 382.4105589 <Server IP> <Application IP> TCP: [Bad
CheckSum]Flags=...A..S., SrcPort=1433, DstPort=62702, PayloadLen=0,
Seq=267349053, Ack=829174048, Win=65535 ( Negotiated scale factor 0x8 ) =
16776960
1103493 <DateTime> 382.4113628 <Application IP> <Server IP>
TCP:Flags=...A...., SrcPort=62702, DstPort=1433, PayloadLen=0,
Seq=829174048, Ack=267349054, Win=513 (scale factor 0x8) = 131328
1103515 <DateTime> 382.4117349 <Application IP> <Server IP> TDS:Prelogin,
Version = 7.300000(No version information available, using the default
version), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=62702,
DstPort=1433, PayloadLen=88, Seq=829174048 - 829174136, Ack=267349054,
Win=131328
1103525 <DateTime> 382.4118186 <Server IP> <Application IP> TDS:Response,
Version = 7.300000(No version information available, using the default
version), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=1433,
DstPort=62702, PayloadLen=48, Seq=267349054 - 267349102, Ack=829174136,
Win=2102272
1103547 <DateTime> 382.4128101 <Application IP> <Server IP> TLS:TLS Rec
Layer-1 HandShake: Client Hello.
1103584 <DateTime> 382.4151314 <Server IP> <Application IP> TLS:TLS Rec
Layer-1 HandShake: Server Hello. Certificate. Server Key Exchange. Server
Hello Done.
1103595 <DateTime> 382.4161185 <Application IP> <Server IP>
TCP:Flags=...A...., SrcPort=62702, DstPort=1433, PayloadLen=0,
Seq=829174322, Ack=267351024, Win=513 (scale factor 0x8) = 131328
1103676 <DateTime> 382.4782629 <Application IP> <Server IP> TLS:TLS Rec
Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec;
TLS Rec Layer-3 HandShake: Encrypted Handshake Message.
1103692 <DateTime> 382.4901904 <Server IP> <Application IP> TCP:[Segment
Lost] [Bad CheckSum]Flags=...A...F, SrcPort=1433, DstPort=62702,
PayloadLen=0, Seq=267351024, Ack=829174648, Win=8210 (scale factor 0x8) =
2101760
1103696 <DateTime> 382.4918048 <Application IP> <Server IP>
TCP:Flags=...A...., SrcPort=62702, DstPort=1433, PayloadLen=0,
Seq=829174648, Ack=267351025, Win=513 (scale factor 0x8) = 131328
1103718 <DateTime> 382.4931068 <Application IP> <Server IP>
TCP:Flags=...A...F, SrcPort=62702, DstPort=1433, PayloadLen=0,
Seq=829174648, Ack=267351025, Win=513 (scale factor 0x8) = 131328
1103723 <DateTime> 382.4931475 <Server IP> <Application IP> TCP: [Bad
CheckSum]Flags=...A...., SrcPort=1433, DstPort=62702, PayloadLen=0,
Seq=267351025, Ack=829174649, Win=8210 (scale factor 0x8) = 2101760

Examining the Server Hello packet to see the cipher suite being used:
 Output

Frame: Number = 1103584, Captured Frame Length = 2093, MediaType = NetEvent

+NetEvent:
+MicrosoftWindowsNDISPacketCapture: Packet Fragment (1976 (0x7B8) bytes)
+Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-00-0C-9F-F4-
5C],SourceAddress:[00-1D-D8-B8-3A-7B]
+Ipv4: Src = <Server IP>, Dest = <Application IP>, Next Protocol = TCP,
Packet ID = 16076, Total IP Length = 0
+Tcp: [Bad CheckSum]Flags=...AP..., SrcPort=1433, DstPort=62702,
PayloadLen=1938, Seq=267349102 - 267351040, Ack=829174322, Win=8211 (scale
factor 0x8) = 2102016
+Tds: Prelogin, Version = 7.300000(No version information available, using
the default version), SPID = 0, PacketID = 0, Flags=...AP..., SrcPort=1433,
DstPort=62702, PayloadLen=1938, Seq=267349102 - 267351040, Ack=829174322,
Win=2102016
TLSSSLData: Transport Layer Security (TLS) Payload Data
-TLS: TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Key
Exchange. Server Hello Done.
-TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
+Version: TLS 1.2
Length: 1909 (0x775)
-SSLHandshake: SSL HandShake Server Hello Done(0x0E)
HandShakeType: ServerHello(0x02)
Length: 81 (0x51)
-ServerHello: 0x1
+Version: TLS 1.2
+RandomBytes:
SessionIDLength: 32 (0x20)
SessionID: Binary Large Object (32 Bytes)
TLSCipherSuite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 { 0x00, 0x9F }
CompressionMethods: 0 (0x0)
ExtensionsLength: 9 (0x9)
+ServerHelloExtension: Unknown Extension Type
+ServerHelloExtension: Renegotiation Info(0xFF01)
HandShakeType: Certificate(0x0B)
Length: 778 (0x30A)
+Cert: 0x1
HandShakeType: Server Key Exchange(0x0C)
Length: 1034 (0x40A)
ServerKeyExchange: Binary Large Object (1034 Bytes)
HandShakeType: Server Hello Done(0x0E)
Length: 0 (0x0)
+Tds: Prelogin, Version = 7.300000(No version information available, using
the default version), Reassembled Packet

Reference
For more information, see the following articles:
 Manage Transport Layer Security (TLS)
TLS

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x800706ba "The RPC Server is
unavailable" when you enroll a
certificate
Article • 02/26/2024

When you try to enroll a certificate on a Windows Server, it fails with the error
0x800706ba, "The RPC Server is unavailable." This article introduces steps to resolve this
issue.

Applies to: Supported versions of Windows Server

Original KB number: 4042719, 4516764, 5021150

Identify the issue

When you encounter this issue, you may see one or more of the following symptoms.

７ Note

When the issue occurs, if we add the user account that's used to request the
certificate to the local administrators group on the certificate authority (CA), the
enrollment succeeds for a user-based template. However, enrollment against a
machine-based template still returns the same error.

Error messages
You receive error messages that resemble the following during certificate enrollment.

Error 1

An error occurred whilst enrolling for a certificate. The certificate request could not
be submitted to the certification authority.
Url: <certificate server FQDN>\MyPKI
Error: The RPC server is unavailable. 0x800706ba (WIN32: 1322
RPC_S_SERVER_UNAVAILABLE)

Error 2
Error 3

Network capture
The network trace shows the successful Lightweight Directory Access Protocol (LDAP)
queries to the configuration partition in Active Directory; the templates available are
revealed in the trace.

Then, the requesting server tries to do a remote procedure call (RPC) to the CA and gets
the response "ACCESS DENIED."

For example:

Output

10167 <time> <requesting server IP address> <CA IP address> ISystemActivator

918 RemoteCreateInstance request
10174 <time> <CA IP address> <requesting server IP address> DCERPC 86 Fault:
call_id: 3, Fragment: Single, Ctx: 1, status: nca_s_fault_access_denied
Additionally, you can find the Microsoft Remote Procedure Call (MSRPC) bind attempt
and error:

Output

1093 <time> 92.5590216 (0) SourceIP 52237 (0xCC0D) DestIP

135 (0x87) MSRPC MSRPC:c/o Bind: IRemoteSCMActivator(DCOM)
UUID{000001A0-0000-0000-C000-000000000046} Call=0x3 Assoc Grp=0x8A9E
Xmit=0x16D0 Recv=0x16D0
1097 <time> 92.5940283 (652) SourceIP 135 (0x87) DestIP
52237 (0xCC0D) MSRPC MSRPC:c/o Bind Nack: Call=0x3 Reject Reason:
invalid_checksum

In a network trace, you find the following error:

Status : MSRPC:c/o Fault: Call=0x3 Context=0x1 Status=0x5 (Access is denied)

For example:

Output

<Certificate_Server> <Client> DCOM DCOM:RemoteCreateInstance Request, DCOM

Version=5.7 Causality Id={7CFF2CD3-3165-4098-93D6-4077D1DF7351}
<Client> <Certificate_Server> MSRPC MSRPC:c/o Fault: Call=0x3 Context=0x1
Status=0x5 Cancels=0x0

Event log
If auditing is enabled, a Distributed Component Object Model (DCOM) error can be
observed on the CA server detailing an ANONYMOUS LOGON attempt:

Output

Log Name: System

Source: Microsoft-Windows-DistributedCOM
Date: <date>
Event ID: 10027
Task Category: None
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <CA FQDN>

Description:
The machine wide limit settings do not grant Remote Activation permission
for COM Server applications to the user NT AUTHORITY\ANONYMOUS LOGON SID (S-
1-5-7) from address <IP address> running in the application container
 Unavailable SID (Unavailable). This security permission can be modified
using the Component Services administrative tool.

７ Note

Event ID 82 is logged in Application logs if auto-enrollment is failing with the same

error.

Other symptoms and logs

The call should be made with dce_c_authn_level_pkt_integrity RPC Integrity level
that enforces Kerberos or New Technology LAN Manager (NTLM) as an
authentication mechanism. This behavior is enforced by default starting 6B.22
KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass
(CVE-2021-26414) .
When the client sends a KRB_AP_REQ request, it's rejected by the server side.
The server tries to procure an access token for the user who presented the
Kerberos Ticket Granting Service (TGS) and fails with error 0xc000015b,
"STATUS_LOGON_TYPE_NOT_GRANTED."

Cause 1: Incorrect group policy configurations

This issue can occur because of one of the following reasons:

1. The group policy Access this computer from the network is set, and the user
account used to enroll the certificate isn't added. By default, the policy is
populated by the groups: Administrators, Backup Operators, Everyone, and Users.
2. The group policy Deny access to this computer from the network is set, and
Everyone, Users or a security group the user belongs to is added.

These group policies locate at Computer Configuration\Windows Settings\Security

Settings\Local Policies\User Rights Assignment.

７ Note

You can run whoami /groups to identify the groups of the user account or use
Active Directory Users and computers to identify the groups belonging to the user
or the computer account.
Because the user account used for certificate enrollment fails authentication by using
Kerberos, the authentication mechanism is downgraded to "anonymous logon." The
logon fails on the DCOM level.

How to identify
1. Open an elevated command prompt on the certificate server.

2. Run the gpresult /h command. For example, gpresult /h appliedgpo.html .

3. Open the .html file that's generated, and review the section:
Settings \ Policies \ Windows Settings \ Local Policies \ User Rights Assignment

Access this computer from the network

Deny access to this computer from the network

4. Note the Winning GPO name.

To resolve this issue, edit the Winning GPO.

７ Note

The settings configured on the Group Policy Objects (GPOs) are for a reason, so
you should talk to your security team before making any changes.

Add the appropriate user groups to the Access this computer from the network group
policy. For example:
Then, remove the group that the user account or the computer account belongs to from
the Deny access to this computer from the network group policy.

For more information, see Access this computer from the network - security policy
setting.

Cause 2: Missing "NT Authority\Authenticated

Users" in the "Users" group of the certificate
server or any other default permissions
Here are the default permissions:

Contoso\Domain Users
NT AUTHORITY\Authenticated Users
NT AUTHORITY\INTERACTIVE

To resolve this issue, open Local Users and Groups on the certificate server, locate the
Users group, and add the missing groups.
Cause 3: Missing "NT
AUTHORITY\Authenticated Users" from the
"Certificate Service DCOM Access" local group
of the certificate server
To resolve this issue, follow these steps:

1. Open Local Users and Groups on the certificate server.

2. Locate the Certificate Service DCOM Access group.
3. Add NT AUTHORITY\Authenticated users.

Cause 4: EnableDCOM isn't set to Y on the

Client and CA Server
To resolve this issue, follow these steps:

1. Locate this registry key HKEY_LOCAL_MACHINE\Software\Microsoft\OLE .

2. Verify if the data of the EnableDCOM registry value is set to Y.
3. If it's N, change it to Y, and then restart the computer.

Cause 5: Remote Procedure Call restrictions

aren't applied on the Certificate server
To identify the issue, verify that the GPO is applied to the certificate server. Follow these
steps:

1. Open an elevated command prompt on the certificate server.

2. Run the gpresult /h command. For example, gpresult /h appliedgpo.html .

3. Open the .html file, and identify the winning GPO where the Restrictions for
Unauthenticated RPC Client group policy is configured to Not Configured.

The group policy locates at Administrative Templates \ System \ Remote Procedure

Call \ Restrictions for Unauthenticated RPC Client.

Cause 6: Missing "Certificate Service DCOM

Access" from COM Security Access Permissions
or Launch and Activation Permissions
When the Active Directory Certificate Services role is installed on a server, the local
Certificate Service DCOM Access group is automatically granted rights to the
Component Services administrative tool. If these default permissions have been
removed, you may experience the symptoms described in this article. To verify that the
correct permissions are in place, follow these steps:

1. Open the Component Services Microsoft Management Console (MMC) snap-in

under Windows Administrative Tools.
2. In the left pane, expand Component Services > Computers.
3. Right-click My Computer, select Properties, and then select the COM Security tab.
4. Under Access Permissions, select Edit Limits.
5. Verify that the local Certificate Service DCOM Access group appears in the Group
or user names list and is granted both Local Access and Remote Access
permissions. If not, add it and grant the appropriate permissions. Select OK to
close the Access Permission dialog.
6. Under Launch and Activation Permissions, select Edit Limits.
7. Verify that the local Certificate Service DCOM Access group appears in the Group
or user names list and is granted both Local Activation and Remote Activation
permissions. If not, add it and grant the appropriate permissions. Select OK to
close the Launch and Activation Permissions dialog.

Reference
For more information, see Restrictions for Unauthenticated RPC Clients: The group
policy that punches your domain in the face .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to export Root Certification
Authority Certificate
Article • 02/26/2024

This article describes how to export Root Certification Authority Certificate.

Applies to: Windows Server 2003

Original KB number: 555252

Tips
1. Requesting the Root Certification Authority Certificate by using command line:

a. Log into the Root Certification Authority server with Administrator Account.

b. Go to Start > Run. Enter the text Cmd and then select Enter.

c. To export the Root Certification Authority server to a new file name

ca_name.cer, type:

Console

certutil -ca.cert ca_name.cer

2. Requesting the Root Certification Authority Certificate from the Web Enrollment
Site:

a. Log on to Root Certification Authority Web Enrollment Site.

Usually the Web Enrollment Site resides in the following links:

http://<ip_address>/certsrv

or

http://<fqdn>/certsrv

ip_address = Root Certification Authority Server IP.

fqdn = Fully qualified domain name of the Root Certification Authority Server.

b. Select Download a CA certificate, certificate chain, or CRL.

c. Select Download CA certificate.

 d. Save the file "certnew.cer" in local disk store.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to find the name of the Enterprise
Root Certificate Authority server
Article • 02/26/2024

This article helps you to find name of the Enterprise Root Certificate Authority (CA)
server.

Applies to: Windows Server 2003

Original KB number: 555529

Summary
The following content describes two options to find the name of the Enterprise Root
Certificate Authority server.

Option 1
1. Sign in by using domain administrator to computer that connects to the domain.

2. Go to Start -> Run -> Write cmd and press on Enter button.

3. Write "certutil.exe" command and press on Enter button.

Option 2
1. Sign in by using domain administrator to computer that connects to the domain.

2. Install Windows Support Tools.

3. Go to Start -> Run -> Write adsiedit.msc and press on Enter button.

4. Navigate to:

CN=Certification Authorities,CN=Public Key

Services,CN=Services,CN=Configuration,DC=ntdomain,DC=com

Under Certification Authorities, you'll find your Enterprise Root Certificate

Authority server.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Reinstall the CA role in Windows Server
2012 Essentials
Article • 02/26/2024

This article describes how to uninstall and then reinstall the Certificate Authority (CA)
role in Windows Server 2012 Essentials.

Applies to: Windows Server 2012 R2

Original KB number: 2795825

Uninstall the CA server role

1. In Server Manager, click Manage, and then click Remove Roles and Features.

2. On the Before You Begin page, click Next.

3. On the Select destination server page, select the server in the server pool, and
then click Next.

4. On the Remove server roles page, expand Active Directory Certificate Services,
clear the Certification Authority Web Enrollment check box, and then click Next.

5. On the Remove features page, click Next.

6. On the Confirm removal selections page, verify the information, and then click
Remove.

7. Click Close after the removal is complete.

8. Repeat steps 1 through 3.

9. On the Remove server roles page, click to clear the Active Directory Certificate
Services check box.

７ Note

When you are prompted to remove Remote Server Administration Tools,

click Remove Features, and then click Next.

10. On the Remove features page, click Next.

 11. On the Confirm removal selections page, verify the information, and then click
Remove.

12. After the removal is complete, click Close, and then restart the server.

Reinstall the CA server role

1. In Server Manager, click Manage, and then click Add Roles and Features.

2. On the Before you begin page, click Next.

3. On the Select installation type page, click Role-based or feature-based

installation, and then click Next.

4. On the Select destination server page, select the server in the server pool, and
then click Next.

5. On the Select server roles page, click the Active Directory Certificate Services
role.

6. When you are prompted to install Remote Server Administration Tools, click Add
Features, and then click Next.

7. On the Select features page, click Next.

8. On the Active Directory Certificate Services page, click Next.

9. On the Select role services page, select Certification Authority and Certification
Authority Web Enrollment, and then click Next.

10. On the Confirm installation selections page, verify the information, and then click
Install.

11. Wait for the installation to finish. After the installation is complete, click the
Configure Active Directory Certificate Services on the destination server link.

12. On the Credentials page, click Next.

７ Note

You can change the credentials if it is necessary.

13. On the Role Services page, select Certification Authority and Certification
Authority Web Enrollment, and then click Next.
 14. On the Setup Type page, click Enterprise CA, and then click Next.

15. On the CA Type page, click Root CA, and then click Next.

16. On the Private Key page, click Use existing private key, click Select a certificate
and use its associated private key, and then click Next.

17. On the Existing Certificate page, select the <Server_Name>-CA certificate, and
then click Next.

７ Note

<Server_Name> is the name of the destination server.

18. On the CA Database page, accept the default locations, and then click Next.

19. On the Confirmation page, confirm your selections, and then click Configure.

20. When configuration is complete, click Close.

Verify the installation

1. In Server Manager, click Tools, and then click Certification Authority.
2. Right-click the name of the CA, and then click Properties.
3. In the Properties dialog box, click the Extensions tab.
4. In the list that is displayed, click http://<ServerDNSName>/CertEnroll/<CaName>
<CRLNameSuffix><DeltaCRLAllowed>.crl .

5. Make sure that the following options are selected:

Include in CRLs. Clients use this to find Delta CRL locations.

Include in the CDP extension of issued certificates.

6. Click OK to save your changes.

7. When you are prompted to restart Active Directory Certificate Services, click Yes.
8. Close the Certification Authority console.

Add a certificate template to the CA

1. In Server Manager, click Tools, and then click Certification Authority.
2. Double-click the name of the CA to expand the item.
3. Right-Click Certificate Templates, click New, and then click Certificate Template to
Issue.
 4. In the list, click Windows Server Solutions Computer Certificate Template, and
then click OK.
5. Close the Certification Authority console.

Add the server and clients to the Dashboard

1. Open a Command Prompt window as an administrator.
2. Type cd "\Program Files\Windows Server\Bin", and press the Enter key.
3. Type WssPowerShell.exe, and then press the Enter key.
4. Type Add-WssLocalMachineCert, and then press the Enter key.
5. Reboot the server.
6. Re-run the connector installation on all client computers.

Bind the certificate to the Internet Information Services

(IIS) websites
1. Open IIS Manager.
2. Choose all the websites that use the old machine certificates, and then replace
them by using the new certificates.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to remove manually Enterprise
Windows Certificate Authority from a
Windows 2000/2003 domain
Article • 02/26/2024

This article was written by Yuval Sinay , Microsoft MVP.

Applies to: Windows Server 2003

Original KB number: 555151

Symptoms
In some organizations, there are regular backup procedures for Enterprise Windows
Certificate Authority. If there's a server problem (software/hardware), you may need to
reinstall the Enterprise Windows Certificate Authority. Before you can reinstall the
Enterprise Windows Certificate Authority, you may need to manually delete objects and
data that belong to the original Enterprise Windows and reside in the Windows Active
Directory.

Cause
Enterprise Windows Certificate Authority saves the configurations settings and data in
the Windows Active Directory.

Resolution
A. Backup:

You're recommended to back up all the nodes that contain Active Directory-related data
before and after you follow this procedure, including:

Windows Domain Controllers

Exchange Servers
Active Directory Connector
Windows Server with Services for Unix
ISA Server Enterprise
Enterprise Windows Certificate Authority
Use the following procedure as last resort. It may affect your production environment,
and may require to restart some nodes/services.

B. Active Directory Clean:

７ Note

Log on into the system with an account that has the permissions bellow:

1. Enterprise Administrator
2. Domain Administrator
3. Certificate Authority Administrator
4. Schema Administrator (The server that function as Schema Master FSMO
should be online during the process).

To remove all Certification Services objects from Active Directory:

1. Start "Active Directory Sites and Services".

2. Select the "View" menu option, and select "Show Services" Node.

3. Expand the "Services", and then expand "Public Key Services".

4. Select the "AIA" node.

5. In the right-hand pane, locate the "certificateAuthority" object for your

Certification Authority. Delete the object.

6. Select the "CDP" node.

7. In the right-hand pane, locate the Container object for the server where
Certification Services is installed. Delete the container and the objects it contains.

8. Select the "Certification Authorities" node.

9. In the right-hand pane, locate the "certificateAuthority" object for your

Certification Authority. Delete the object.

10. Select the "Enrollment Services" node.

11. In the right-hand pane, verify that the "pKIEnrollmentService" object for your
Certification Authority, delete it.

12. Select the "Certificate Templates" node.

 13. In the right-hand pane, delete all the Certificate Templates.

７ Note

Delete all the Certificate Templates only if no other Enterprise CAs are
installed in the forest. If the templates are inadvertently deleted, restore the
templates from backup.

14. Select the "Public key Services" node and locate the "NTAuthCertificates" object.

15. If there are no other Enterprise or Stand-alone CAs installed in the forest, delete
the object, otherwise leave it alone.

16. Use "Active Directory Sites and Services" or " Repadmin " command from the
Windows resource kit to force replication to the other domain controllers in the
domain/forest.

Domain Controller Cleanup

Once the CA has been taken down, the certificates that have been issued to all the
domain controllers need to be removed. It can be done easily by using DSSTORE.EXE
from the Resource Kit:

You can also remove old domain controller certificates by using certutil command:

1. At the command prompt on a domain controller, type: certutil -dcinfo

deleteBad .

2. Certutil.exe will attempt to validate all the DC certificates issued to the domain
controllers. Certificates that fail to validate will be removed. At this point, you can
reinstall Certificate Services. After the installation is finished, the new root
certificate will be published to Active Directory. When the domain
clients refresh their security policy, they'll automatically download the new root
certificate into their trusted root stores. o force application of the security policy.

3. At the command prompt, type gpupdate /target: computer .

７ Note

If the Enterprise Windows Certificate Authority published computer/user

certificate or other types of certificates (Web Server Certificate, and so on), it's
 recommended that you remove the old certificates before you reinstall the
Enterprise Windows Certificate.

More information
Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to move a certification authority to
another server
Article • 02/26/2024

This article describes how to move a certification authority (CA) to a different server.

Applies to: Windows Server 2000, Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows
Server 2016, Windows Server 2019, Windows Server 2022
Original KB number: 298138

７ Note

This article applies to Windows 2000, Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2,
Windows Server 2016, Windows Server 2019, Windows Server 2022. Support for
Windows 2000 ended on July 13, 2010. The Windows 2000 End-of-Support
Solution Center is a starting point for planning your migration strategy from
Windows 2000. Support for Windows 2008 and 2008 R2 ended on January 14,
2020. For more information, see the Microsoft Support Lifecycle Policy.

Summary
Certification authorities (CAs) are the central component of the public key infrastructure
(PKI) of an organization. The CAs are configured to exist for many years or decades,
during which time the hardware that hosts the CA is probably upgraded.

７ Note

To move a CA from a server that is running Windows 2000 Server to a server that is
running Windows Server 2003, you must first upgrade the CA server that is running
Windows 2000 Server to Windows Server 2003. Then you can follow the steps that
are outlined in this article.

Make sure that the %Systemroot% of the target server matches the %Systemroot% of the
server from which the system state backup is taken.
You must change the path of the CA files when you install the CA server components so
that they match the location of the backup. For example, if you back up from the
D:\Winnt\System32\Certlog folder, you must restore the backup to the
D:\Winnt\System32\Certlog folder. You cannot restore the backup to the
C:\Winnt\System32\Certlog folder. After you restore the backup, you can move the CA
database files to the default location.

If you try to restore the backup, and the %Systemroot% of the backup and the target
server do not match, you may receive the following error message:

Restore of an incremental image cannot be performed before you perform restore

from a full image. The directory name is invalid. 0x8007010b (WIN32/HTTP:267)

Moving Certificate Services from a 32-bit operating system to a 64-bit operating system
or vice-versa may fail with one of the following error messages:

The expected data does not exist in this directory.

Restore of incremental image cannot be performed before performing restore from

a full image 0x8007010b (WIN32/HTTP:267)

Database format changes from the 32-bit version to the 64-bit version cause
incompatibilities, and the restore is blocked. This resembles the move from Windows
2000 to Windows Server 2003 CA. However, there is no upgrade path from a 32-bit
version of Windows Server 2003 to a 64-bit version. Therefore, you cannot move an
existing 32-bit database to a 64-bit database on a Windows Server 2003-based
computer. However, you can upgrade from Windows Server 2003 CA (running on
Windows Server 2003 x86) to Windows Server 2008 R2 CA (running on Windows Server
2008 R2 x64). This upgrade is supported.

An x64-based version of Windows Server 2003 R2 CD2 only updates 64-bit versions of
Windows Server 2003 that are based on the EM64T architecture or on the AMD64
architecture.

Back up and restore the certification authority

keys and database

） Important
This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

1. Note the certificate templates that are configured in the Certificate Templates
folder in the Certification Authority snap-in. The Certificate Templates settings are
stored in Active Directory. They are not automatically backed up. You must
manually configure the Certificate Templates settings on the new CA to maintain
the same set of templates.

７ Note

The Certificate Templates folder exists only on an enterprise CA. Stand-alone

CAs do not use certificate templates. Therefore, this step does not apply to a
stand-alone CA.

2. Use the Certification Authority snap-in to back up the CA database and private key.
To do this, follow these steps:
a. In the Certification Authority snap-in, right-click the CA name, click All Tasks,
and then click Back up CA to start the Certification Authority Backup Wizard.
b. Click Next, and then click Private key and CA certificate.
c. Click Certificate database and certificate database log.
d. Use an empty folder as the backup location. Make sure that the backup folder
can be accessed by the new server.
e. Click Next. If the specified backup folder does not exist, the Certification
Authority Backup Wizard creates it.
f. Type and then confirm a password for the CA private key backup file.
g. Click Next, and then verify the backup settings. The following settings should be
displayed:

Private Key and CA Certificate

Issued Log and Pending Requests

h. Click Finish.

3. Save the registry settings for this CA. To do this, follow these steps:
a. Click Start, click Run, type regedit in the Open box, and then click OK.
 b. Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

c. Click Export.
d. Save the registry file in the CA backup folder that you defined in step 2d.

７ Note

By default, Active Directory Certificate Services (AD CS) is configured with

certificate revocation list (CRL) Distribution Point extensions that include the
CA computer host name in the path. This means that any certificates issued by
the CA before the migration may contain certificate validation paths with the
old host name. These paths may no longer be valid after the migration. To
avoid revocation checking errors, the new CA must be configured to publish
CRLs to the old (pre-migration) paths and the new paths. If you have to delete
the old CA permanently, you can add a second computer name to the new
CA. Before you can do that, the old computer name needs to be available in
Active Directory. At this point, you can add the CRL Distribution Points to the
new CA.

4. Check the CRL Distribution Point on the old CA. These settings have to be
configured in the new CA.
a. Open cmd.exe in the old CA.
b. Enter pkiview .
c. Export the configuration.

5. Remove Certificate Services from the old server.

７ Note

This step removes objects from Active Directory. Do not perform this step out
of order. If removal of the source CA is performed after installation of the
target CA (step 7 in this section), the target CA will become unusable.

6. Rename the old server, or permanently disconnect it from the network.

7. Install Certificate Services on the new server. To do this, follow these steps.

７ Note

The new server must have the same computer name as the old server.
 a. In Control Panel, double-click Add or Remove Programs.
b. Click Add/Remove Windows Components, click Certificate Services in the
Windows Components Wizard, and then click Next.
c. In the CA Type dialog box, click the appropriate CA type.
d. Click Use custom settings to generate the key pair and CA certificate, and then
click Next.
e. Click Import, type the path of the .P12 file in the backup folder, type the
password that you chose in step 2f, and then click OK.
f. In the Public and Private Key Pair dialog box, verify that Use existing keys is
checked.
g. Click Next two times.
h. Accept the Certificate Database Settings default settings, click Next, and then
click Finish to complete the Certificate Services installation.

） Important

If the new server has a different computer name, then follow these steps:

a. In Control Panel, double-click Add or Remove Programs.

b. Click Add/Remove Windows Components, click Certificate Services in the
Windows Components Wizard, and then click Next.
c. In the CA Type dialog box, click the appropriate CA type.
d. Click Use custom settings to generate the key pair and CA certificate, and then
click Next.
e. Click Import, type the path of the .P12 file in the backup folder, type the
password that you chose in step 2f, and then click OK.
f. In the Public and Private Key Pair dialog box, verify that Use existing keys is
checked.
g. Click Next two times.
h. Accept the Certificate Database Settings default settings, click Next, and then
click Finish to complete the Certificate Services installation.
i. Modify the previously exported Registry Key in step 3 like so:
i. Right-click on the exported key.
ii. Edit.
iii. Replace the CAServerName value with the new Server name.
iv. Save and Close.

8. Stop the Certificate Services service.

9. Locate the registry file that you saved in step 3, and then double-click it to import
the registry settings. If the path that is shown in the registry export from the old
 CA differs from the new path, you must adjust your registry export accordingly. By
default, the new path is C:\Windows in Windows Server 2003.

10. Use the Certification Authority snap-in to restore the CA database. To do this,
follow these steps:

a. In the Certification Authority snap-in, right-click the CA name, click All Tasks,
and then click Restore CA.

The Certification Authority Restore Wizard starts.

b. Click Next, and then click Private key and CA certificate.

c. Click Certificate database and certificate database log.

d. Type the backup folder location, and then click Next.

e. Verify the backup settings. The Issued Log and Pending Requests settings
should be displayed.

f. Click Finish, and then click Yes to restart Certificate Services when the CA
database is restored.

You may receive the following error during the restore CA process if the CA backup
folder is not in the correct folder structure format:

---------------------------
Microsoft Certificate Services
---------------------------

The expected data does not exist in this directory.

Please choose a different directory. The directory name is invalid. 0x8007010b
(WIN32/HTTP: 267)

The correct folder structure is as follows:

C:\Ca_Backup\CA_NAME.p12
C:\Ca_Backup\Database\certbkxp.dat
C:\Ca_Backup\Database\edb#####.log
C:\Ca_Backup\Database\CA_NAME.edb

Where C:\Ca_Backup is the folder you chose during the Backup CA phase in step 2.

11. In the Certification Authority snap-in, manually add or remove certificate templates
to duplicate the Certificate Templates settings that you noted in step 1.
 ７ Note

If you encounter problems publishing new Templates or your Custom ones, follow
the steps below.

1. From a Domain Controller within the forest where you migrated the CA role start
ADSI Edit.
2. Right click on ADSI Edit -> Connect to -> In Select a well known Naming Context
choose Configuration -> Ok.
3. Navigate to CN=Configuration | CN=Services | CN=Public Key Services |
CN=Enrollment Services.
4. Right click the CA in the right pane that you want to enroll from and click
Properties. Find the flags attribute; and verify that it is set to 10.
5. If it is not, then set it to 10 and wait or manually force Active Directory replication.
6. Close ADSI Edit and from your CA Server make sure you can now publish your new
Templates.

Back up and restore the certification authority

keys and database in Windows 2000 Server

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

1. Note the certificate templates that are configured in the Certificate Templates
folder in the Certification Authority snap-in. The Certificate Templates settings are
stored in Active Directory. They are not automatically backed up. You must
manually configure the Certificate Templates settings on the new CA to maintain
the same set of templates.

７ Note

The Certificate Templates folder exists only on an enterprise CA. Stand-alone

CAs do not use certificate templates. Therefore, this step does not apply to a
 stand-alone CA.

2. Use the Certification Authority snap-in to back up the CA database and private key.
To do this, follow these steps:
a. In the Certification Authority snap-in, right-click the CA name, click All Tasks,
and then click Back up CA to start the Certification Authority Backup Wizard.
b. Click Next, and then click Private key and CA certificate.
c. Click Issued certificate log and pending certificate request queue.
d. Use an empty folder as the backup location. Make sure that the backup folder
can be accessed by the new server.
e. Click Next. If the specified backup folder does not exist, the Certification
Authority Backup Wizard creates it.
f. Type and then confirm a password for the CA private key backup file.
g. Click Next two times, and then verify the backup settings. The following settings
should be displayed:

Private Key and CA Certificate

Issued Log and Pending Requests

h. Click Finish.

3. Save the registry settings for this CA. To do this, follow these steps:
a. Click Start, click Run, type regedit in the Open box, and then click OK.
b. Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
c. Click Configuration, and then click Export Registry File on the Registry menu.
d. Save the registry file in the CA backup folder that you defined in step 2d.

4. Check the CRL Distribution Point on the old CA. These settings have to be
configured in the new CA.
a. Open cmd.exe in the old CA.
b. Enter pkiview .
c. Export the configuration.

5. Remove Certificate Services from the old server.

７ Note

This step removes objects from Active Directory. Do not perform this step out
of order. If removal of the source CA is performed after installation of the
target CA (step 7 in this section), the target CA will become unusable.
 6. Rename the old server, or permanently disconnect it from the network.

7. Install Certificate Services on the new server. To do this, follow these steps.

７ Note

The new server must have the same computer name as the old server.

a. In Control Panel, double-click Add/Remove Programs.

b. Click Add/Remove Windows Components, click Certificate Services in the
Windows Components Wizard, and then click Next.
c. In the Certification Authority Type dialog box, click the appropriate CA type.
d. Click Advanced Options, and then click Next.
e. In the Public and Private Key Pair dialog box, click Use existing keys, and then
click Import.
f. Type the path of the .P12 file in the backup folder, type the password that you
chose in step 2f, and then click OK.
g. Click Next, type a CA description if appropriate, and then click Next.
h. Accept the Data Storage Location default settings, click Next, and then click
Finish to complete the Certificate Services installation.

8. Stop the Certificate Services service.

9. Locate the registry file that you saved in step 3, and then double-click it to import
the registry settings.

10. Use the Certification Authority snap-in to restore the CA database. To do this,
follow these steps:

a. In the Certification Authority snap-in, right-click the CA name, click All Tasks,
and then click Restore CA.

The Certification Authority Restore Wizard starts.

b. Click Next, and then click Issued certificate log and pending certificate request
queue.

c. Type the backup folder location, and then click Next.

d. Verify the backup settings. The following settings should be displayed:

Issued Log
Pending Requests
 e. Click Finish, and then click Yes to restart Certificate Services when the CA
database is restored.

11. In the Certification Authority snap-in, manually add or remove certificate templates
to duplicate the Certificate Templates settings that you noted in step 1.

More information
For more information about upgrade and migration scenarios for Windows Server 2003
and Windows Server 2008, see the "Active Directory Certificate Services Upgrade and
Migration Guide" white paper. To see the white paper, see Active Directory Certificate
Services Upgrade and Migration Guide.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Move the Certificate Server database
and log files
Article • 02/26/2024

This article describes how to move a certificate server's database and log files.

Applies to: Windows Server 2012 R2

Original KB number: 283193

） Important

This article contains information about modifying the registry. Before you modify
the registry, make sure to back it up and make sure that you understand how to
restore the registry if a problem occurs. For information about how to back up,
restore, and edit the registry, click the following article number to view the article in
the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry

Move the Certificate Server Database and Log

Files

２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.

Use these steps to change the location of the certificate server database and log files:

1. Stop the Certificate Services service.

2. Copy the database files and log files to new location. The default database path is:
%SystemRoot%\System32\CertLog

3. Modify the database paths in the following registry entries to reflect the new path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBD

irectory
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBL
ogDirectory

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBS
ystemDirectory

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBT

empDirectory

4. Start the Certificate Services service.

5. Check the Application event log for CertSvc event 26 to verify that the Certificate
Services service started successfully. A warning message is displayed if the service
does not start successfully. If this occurs, check the syntax of the paths in the
registry.

You may need to edit the NTFS permissions to grant Full Control permissions to the
System account. By default, the System account and the Administrators and Enterprise
Administrators groups have Full Control access for the CertLog folder.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Required trusted root certificates
Article • 02/26/2024

This article lists the trusted root certificates that are required by Windows operating systems. These trusted root
certificates are required for the operating system to run correctly.

Applies to: Supported versions of Windows Server and Windows Client

Original KB number: 293781

Summary
As part of a public key infrastructure (PKI) trust management procedure, some administrators may decide to
remove trusted root certificates from a Windows-based domain, server, or client. However, the root certificates
that are listed in the Necessary and trusted root certificates section in this article are required for the operating
system to operate correctly. Removal of the following certificates may limit functionality of the operating system,
or may cause the computer to fail. Don't remove them.

Necessary and trusted root certificates

The following certificates are necessary and trusted in:

Windows 7
Windows Vista
Windows Server 2008 R2
Windows Server 2008

ﾉ Expand table

Issued to Issued by Serial number Expiration Intended Friendly Status

date purposes name

Microsoft Root Microsoft Root 00c1008b3c3c8811d13ef663ecdf40 12/31/2020 All Microsoft Root R

Authority Authority Authority

Thawte Thawte 00 12/31/2020 Time Thawte R

Timestamping Timestamping Stamping Timestamping
CA CA CA

Microsoft Root Microsoft Root 79ad16a14aa0a5ad4c7358f407132e65 5/9/2021 All Microsoft Root R

Certificate Certificate Certificate
Authority Authority Authority

The follow certificates are necessary and trusted in Windows XP and in Windows Server 2003:

ﾉ Expand table

Issued to Issued by Serial number Expiration Intended Friendly name Status

date purposes

Copyright (c) Copyright (c) 01 12/30/1999 Time Microsoft R

1997 Microsoft 1997 Microsoft Stamping Timestamp Root
Corp. Corp.

Microsoft Microsoft 01 12/31/1999 Secure E- Microsoft R

Authenticode(tm) Authenticode(tm) mail, Authenticode(tm)
 Issued to Issued by Serial number Expiration Intended Friendly name Status
date purposes

Root Authority Root Authority Code Root

Signing

Microsoft Root Microsoft Root 00c1008b3c3c8811d13ef663ecdf40 12/31/2020 All Microsoft Root R

Authority Authority Authority

NO LIABILITY NO LIABILITY 4a19d2388c82591ca55d735f155ddca3 1/7/2004 Time VeriSign Time R

ACCEPTED, (c)97 ACCEPTED, (c)97 Stamping Stamping CA
VeriSign, Inc. VeriSign, Inc.

VeriSign VeriSign 03c78f37db9228df3cbb1aad82fa6710 1/7/2004 Secure E- VeriSign R

Commercial Commercial mail, Commercial
Software Software Code Software
Publishers CA Publishers CA Signing Publishers CA

Thawte Thawte 00 12/31/2020 Time Thawte R

Timestamping Timestamping Stamping Timestamping
CA CA CA

Microsoft Root Microsoft Root 79ad16a14aa0a5ad4c7358f407132e65 5/9/2021 All Microsoft Root R

Certificate Certificate Certificate
Authority Authority Authority

The follow certificates are necessary and trusted in Microsoft Windows 2000:

ﾉ Expand table

Issued to Issued by Serial number Expiration Intended Friendly name Status

date purposes

Copyright (c) Copyright (c) 01 12/30/1999 Time Microsoft R

1997 Microsoft 1997 Microsoft Stamping Timestamp Root
Corp. Corp.

Microsoft Microsoft 01 12/31/1999 Secure E- Microsoft R

Authenticode(tm) Authenticode(tm) mail, Authenticode(tm)
Root Authority Root Authority Code Root
Signing

Microsoft Root Microsoft Root 00c1008b3c3c8811d13ef663ecdf40 12/31/2020 All Microsoft Root R

Authority Authority Authority

NO LIABILITY NO LIABILITY 4a19d2388c82591ca55d735f155ddca3 1/7/2004 Time VeriSign Time R

ACCEPTED, (c)97 ACCEPTED, (c)97 Stamping Stamping CA
VeriSign, Inc. VeriSign, Inc.

VeriSign VeriSign 03c78f37db9228df3cbb1aad82fa6710 1/7/2004 Secure E- VeriSign R

Commercial Commercial mail, Commercial
Software Software Code Software
Publishers CA Publishers CA Signing Publishers CA

Thawte Thawte 00 12/31/2020 Time Thawte R

Timestamping Timestamping Stamping Timestamping
CA CA CA

Some certificates that are listed in the previous tables have expired. However, these certificates are necessary for
backward compatibility. Even if there's an expired trusted root certificate, anything that was signed by using that
certificate before the expiration date requires that the trusted root certificate is validated. As long as expired
certificates aren't revoked, they can be used to validate anything that was signed before their expiration.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to Set an Enterprise Subordinate
CA to Have a Different Certificate
Validity Period than the Parent CA
Article • 02/26/2024

This article describes how to set an enterprise subordinate certification authority (CA) to
have a different certificate validity period than that of the parent CA.

Applies to: Windows Server 2012 R2

Original KB number: 281557

Summary
You can use the following steps to give a subordinate CA a different certificate validation
period than that of the parent CA. This process is divided into the following three steps:

Step 1: Set the validation period on the parent CA. Step 2: Install the subordinate CA.
Step 3: Set the validation time back on the parent CA.

1. Set the validation period on the parent CA. To do this, use the following
commands to set the desired validation period on the parent CA that will issue the
certificate of the subordinate CA:

Console

certutil -setreg ca\ValidityPeriod "Weeks"

certutil -setreg ca\ValidityPeriodUnits "3"

2. Install the subordinate CA. Make sure that you use the parent CA that you used in
step 1.

3. Reset the validation period on the parent CA that issued the certificate of the
subordinate CA (for example, "2 years", which is the default value). To do this, use
the following commands:

Console

certutil -setreg ca\ValidityPeriod "Years"

certutil -setreg ca\ValidityPeriodUnits "2"
 ７ Note

If you run certutil -getreg ca\val* on the subordinate CA, both the
ValidityPeriod property and the ValidityPeriodUnits property are still
synchronized with the parent CA, even though the subordinate CA certificate
is only valid for three weeks.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set up certificate-based
authentication across forests without
trust for a web server
Article • 02/26/2024

This article describes how to set up a web server to use smart cards for cross-forest
certificate-based authentication when the user forests and the resource forest do not
trust one another.

Applies to: Windows Server 2016

Original KB number: 4509680

Environment configuration
Consider an environment that uses the following configuration:

A user forest that is named Contoso.com .

A resource forest that is named Fabrikam.com . The forest has Tailspintoys.com
added as an alternate User Principal Name (UPN).
There is no trust between the two forests.
User smart cards use certificates that have Subject Alternative Name (SAN) entries
of the format [email protected] .
An IIS web server that is configured for Active Directory Certificate Based
Authentication.

Configure Active Directory and the web server as described in the following procedures.

Configure Active Directory

To configure the resource forest to authenticate smart cards, follow these steps:

1. Make sure that a Kerberos Authentication Certificate that has a KDC Authentication
extended key usage (EKU) has been issued to the domain controllers.

2. Make sure that the Issuing CA certificate of the user's certificate is installed in the
Enterprise NTAUTH store.

To publish the Issuing CA certificate in the domain, run the following command at
a command prompt:
 Console

certutil -dspublish -f <filename> NTAUTHCA

In this command, <filename> represents the name of the CA certificate file, which
has a .cer extension.

3. Users must have accounts that use the alternate UPN of the resource forest.

To configure the user forest, follow these steps:

1. Make sure that you have Smart Card Logon and Client Authentication EKU defined
in the certificate.

2. Make sure that the SAN of the certificate uses the UPN of the user.

3. Make sure that you install the Issuing CA Certificate of the user certificate in the
Enterprise NTAUTH store.

７ Note

If you want to set up delegation on the front end server or want to skip using
the UPN in the SAN attribute of the certificate (AltSecID route), see the More
information section.
Configure the web server
To configure the IIS Web server in the resource forest, follow these steps:

1. Install the IIS Web server role, and select the Client Certificate Mapping
Authentication Security feature.

2. On the IIS Web server, enable Active Directory Client Certificate Authentication.

3. On your website, configure SSL Settings to Require SSL and then under Client
certificates, select Require.
 Make sure that no other authentication type is enabled on the website. We don't
recommend enabling Certificate Based Authentication with any other
authentication type because the DS Mapper service, which is responsible for
mapping the user's presented certificate to the user account in Active Directory, is
designed to only work with the Active Directory Client Certificate Authentication
type. If you enable Anonymous Authentication, you may experience unexpected
outcomes.

More information
If you want to set up delegation on this resource web server to query a backend server,
such as a database server or a CA, you may also configure constrained delegation by
using a custom service account. Additionally, you must set up the web server for
constrained delegation (S4U2Self) or protocol transition. For more information, see How
to configure Kerberos Constrained Delegation for Web Enrollment proxy pages.

If you want to skip the UPN in the SAN attribute of the user smart card certificate, you
have to either explicitly map by using AltSecID attributes, or use name hints.

７ Note
 We do not recommend this approach to configuring smart card certificates.

If you publish the SAN attribute as the intended UPN in the user's certificate, you should
not enable AltSecID.

To check the NTAuth store on the web server, open a Command Prompt window and
run the following command:

Console

Certutil -viewstore -enterprise NTAUTH

References
Prepare a non-routable domain for directory synchronization

How to import Third Party CA Certificates

Complete list of changes to make to activate Client Certificate Mapping on IIS

using Active Directory

How Smart Card Sign-in Works in Windows

User Security Attributes

HowTo: Map a user to a certificate via all the methods available in the
altSecurityIdentities attribute

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory replication
troubleshooting guidance
Article • 02/26/2024

Try our Virtual Agent - It can help you quickly identify and fix common Active

Directory replication issues

This article is designed to help get you started troubleshooting Active Directory
replication issues.

Troubleshooting checklist
Use the following checklist to troubleshoot these replication issues:

The error and warning events in the Directory Service event log indicate the
specific constraint that's causing replication failure on the source or destination
domain controller. If the event message suggests steps for a solution, try the steps
that are described in the event.

Diagnostic tools such as Repadmin also provide information that can help you
resolve replication failures. To help monitor replication and diagnose errors,
download and run the Microsoft Support and Recovery Assistant tool .

Rule out intentional disruptions or hardware failures.

In a scenario: A domain controller is built in a staging site. The domain controller is

currently offline, and is waiting for its deployment in the final production site, a
remote site such as a branch office.

When another domain controller is trying to replica with the domain controller, it
reports replication errors. You can account for such replication errors.

Replication problems might be caused by hardware failure.

Active Directory replication remote procedure calls (RPCs) occur dynamically over
an available port through the RPC Endpoint Mapper (RPCSS) on port 135. Make
sure that Windows Defender Firewall with Advanced Security and other firewalls
are configured correctly to enable replication.
After you rule out intentional disconnections and hardware failures, the replication
issues might have one of the following causes:

Network connectivity: The network connection might be unavailable, or network

settings might not configured correctly.
Name resolution: DNS misconfigurations are a common cause of replication
failures.
Replication engine: If intersite replication schedules are too short, replication
queues might be too large to process in the time that is required by the outbound
replication schedule. In this case, replication of some changes might be stalled
indefinitely, or long enough to exceed the tombstone lifetime.
Replication topology: Domain controllers must have intersite links in Active
Directory Domain Services (AD DS) that map to real wide area network (WAN) or
virtual private network (VPN) connections. If you create objects in AD DS for the
replication topology that aren't supported by the actual site topology of your
network, replication that requires the misconfigured topology fails.
Authentication and authorization: Authentication and authorization problems
cause "access denied" errors when a domain controller tries to connect to its
replication partner.
Directory database store: The directory database might not be able to process
transactions fast enough to keep up with replication time-outs.

Common solutions for Active Directory

replication issues
Monitor replication health daily, or use Repadmin to retrieve replication status daily.
Try to resolve any reported failure in a timely manner by using the methods that
are described in the event messages and this guide. If software is causing the
problem, uninstall the software before you continue to try other solutions.
If the problem that is causing replication to fail can’t be resolved by any known
methods, remove AD DS from the server, and then reinstall it. For more
information about reinstalling AD DS, see Decommissioning a Domain Controller.
If AD DS can't be removed in a typical manner while the server is connected to the
network, use one of the following methods to resolve the problem:
Force AD DS removal in Directory Services Restore Mode (DSRM), clean up
server metadata, and then reinstall AD DS.
Reinstall the operating system, and rebuild the domain controller.

Common issues and solutions

Most replication problems are identified in the event messages that are logged in the
Directory Service event log. Replication problems might also be identified in the form of
error messages in the output of the repadmin /showrepl command.

Event ID 2042
Repadmin message:

The time since last replication with this server has exceeded the tombstone lifetime.

A domain controller has failed inbound replication with the named source domain
controller long enough for a deletion to have been tombstoned, replicated, and
garbage-collected from AD DS. See Active Directory replication Event ID 2042.

Event ID 1925
Repadmin message:

No inbound neighbors

If no items appear in the "Inbound Neighbors" section of the output that is generated
by repadmin /showrepl , the domain controller wasn't able to establish replication links
with another domain controller. See Active Directory replication Event ID 1925.

Error code 5
Repadmin message:

Access is denied.

A replication link exists between two domain controllers, but replication can’t be done
correctly because of an authentication failure. See Active Directory replication fails with
error 5: Access is denied.

Error code 49
Repadmin message:

LDAP Error 49.

The domain controller computer account might not be synchronized with the Key
Distribution Center (KDC). Fix replication security issues.

Event ID 1925 and event ID 2087

Repadmin message:

Cannot open LDAP connection to local host.

The administration tool couldn't contact AD DS. See the following articles:

Active Directory replication Event ID 1925

Active Directory replication Event ID 2087

Event ID 1925, event ID 2087 and event ID 2088

Repadmin message:

Last attempt at <date - time> failed with the "Target account name is incorrect."

This problem can be related to connectivity, DNS, or authentication issues. If this error is
a DNS error, the local domain controller couldn't resolve the globally unique identifier
(GUID)-based DNS name of its replication partner. See the following articles:

Active Directory replication Event ID 1925

Active Directory replication Event ID 2087

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Active Directory replication issues.

Reference
Troubleshoot common Active Directory replication errors
Monitoring and Troubleshooting Active Directory Replication Using Repadmin

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Valid root CA certificates distributed
using GPO might intermittently appear
as untrusted
Article • 02/26/2024

This article provides a workaround for an issue where valid root CA certificates that are
distributed by using GPO appear as untrusted.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 4560600

Symptoms

） Important

Untrusted root Certificate Authority (CA) certificate problems can be caused by

numerous PKI configuration issues. This article illustrates only one of the possible
causes of untrusted root CA certificate.

Various applications that use certificates and Public Key Infrastructure (PKI) might
experience intermittent problems, such as connectivity errors, once or twice per
day/week. These problems occur because of failed verification of end entity certificate.
Affected applications might return different connectivity errors, but they will all have
untrusted root certificate errors in common. Below is an example of such an error:

ﾉ Expand table

Hex Decimal Symbolic Text version

0x800b0109 -2146762487 (CERT_E_UNTRUSTEDROOT) A certificate chain processed, but

terminated in a root certificate

Any PKI-enabled application that uses CryptoAPI System Architecture can be affected
with an intermittent loss of connectivity, or a failure in PKI/Certificate dependent
functionality. As of April 2020, the list of applications known to be affected by this issue
includes, but aren't likely limited to:

Citrix
Remote Desktop Service (RDS)
 Skype
Web browsers

Administrators can identify and troubleshoot untrusted root CA certificate problems by

inspecting the CAPI2 Log.

Focus your troubleshooting efforts on Build Chain/Verify Chain Policy errors within the
CAPI2 log containing the following signatures. For example:

Error <DateTime> CAPI2 11 Build Chain

Error <DateTime> CAPI2 30 Verify Chain Policy

Result A certificate chain processed, but terminated in a root certificate which is not
trusted by the trust provider.
[value] 800b0109

Cause
Untrusted root CA certificate problems might occur if the root CA certificate is
distributed using the following Group Policy (GP):

Computer Configuration > Windows Settings > Security Settings > Public Key Policies
> Trusted Root Certification Authorities

Root cause details

When distributing the root CA certificate using GPO, the contents of
HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates will be

deleted and written again. This deletion is by design, as it's how the GP applies registry
changes.

Changes in the area of the Windows registry that's reserved for root CA certificates will
notify the Crypto API component of the client application. And the application will start
synchronizing with the registry changes. The synchronization is how the applications are
kept up-to-date and made aware of the most current list of valid root CA certificates.

In some scenarios, Group Policy processing will take longer. For example, many root CA
certificates are distributed via GPO (similar with many Firewall or Applocker policies). In
these scenarios, the application might not receive the complete list of trusted root CA
certificates.

Because of this reason, end entity certificates that chain to those missing root CA
certificates will be rendered as untrusted. And various certificate-related problems will
start to occur. This problem is intermittent, and can be temporarily resolved by
reenforcing GPO processing or reboot.

If the root CA certificate is published using alternative methods, the problems might not
occur, due to the afore-mentioned situation.

Workaround
Microsoft is aware of this issue and is working to improve the certificate and Crypto API
experience in a future version of Windows.

To address this issue, avoid distributing the root CA certificate using GPO. It might
include targeting the registry location (such as
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificate

s ) to deliver the root CA certificate to the client.

When storing root CA certificate in a different, physical, root CA certificate store, the
problem should be resolved.

Examples of alternative methods for publishing root CA

certificates
Method 1: Use the command-line tool certutil and root the CA certificate stored in the
file rootca.cer:

Console

certutil -addstore root c:\tmp\rootca.cer

７ Note

This command can be executed only by local admins, and it will affect only single
machine.

Method 2: Start certlm.msc (the certificates management console for local machine) and
import the root CA certificate in the Registry physical store.
 ７ Note

The certlm.msc console can be started only by local administrators. Also, the import
will affect only single machine.

Method 3: Use GPO preferences to publish the root CA certificate as described in Group
Policy Preferences

To publish the root CA certificate, follow these steps:

1. Manually import the root certificate on a machine by using the certutil -addstore
root c:\tmp\rootca.cer command (see Method 1).

2. Open GPMC.msc on the machine that you've imported the root certificate.

3. Edit the GPO that you would like to use to deploy the registry settings in the
following way:
a. Edit the Computer Configuration > Group Policy Preferences > Windows
Settings > Registry > path to the root certificate.
b. Add the root certificate to the GPO as presented in the following screenshot.

4. Deploy the new GPO to the machines where the root certificate needs to be
published.
Any other method, tool, or client management solution that distributes root CA
certificates by writing them into the location
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates will

work.

References
Certutil tool
Certificate Stores
System Store Locations
Group Policy Preferences
CertControlStore Crypto API

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Version 3 (CNG) templates won't appear
in Windows Server 2008 or Windows
Server 2008 R2 certificate web
enrollment
Article • 02/26/2024

This article helps fix an issue where the CNG or 2008 templates don't appear in the
Advanced Certificate Request template pulldown menu.

Applies to: Windows Server 2012 R2

Original KB number: 2015796

Symptoms
When using the certificate web enrollment page on a Windows Server 2008 or Windows
Server 2008 R2 server, the new Version 3, also known as CNG or 2008 templates, don't
appear in the Advanced Certificate Request template pulldown menu. As a result, web
enrollment using a CNG template can't take place via the web enrollment method.

When this occurs, certificates can be requested and enrolled in successfully using the
same templates but other enrollment methods. In other words, you can successfully
request a certificate from that template using the certificates MMC snap-in, script,
autoenrollment, or exported request. The issue only occurs with web enrollment not
allowing the Version 3 template from being available to select.

Frequent other causes of not being able to blanket request a certificate may be that the
server isn't an Enterprise server, or the requestor doesn't have Read Allow and Request
Allow permissions on the template in Active Directory.

Cause
This behavior is by design. Version 3 templates may have additional request
requirements that the web enrollment method may not fulfill.

Resolution
Use a different request method for these certificates. Aside from web enrollment, all
other request methods work in this scenario.

More information
An alternative, which shouldn't be attempted in production for customers without
extensive testing in a test environment, is available that will allow the version 3
templates to appear in the web enrollment default pages. The reason it's not
recommended is that the web enrollment pages, again, may not contain the code
necessary for the certificate to populate all needed data, and so the result may be a
problematic certificate. Make sure to keep that in mind when considering doing the
steps below. This option is to alter the msPKI-Template-Schema-Version from 3 to 2.

In addition, altering the msPKI-Template-Schema-Version attribute results in a reload of

the template cache and CSP cache available.

1. On your domain controller go to Start, Run, type AdsiEdit.msc and press Enter.

2. In AdsiEdit.msc right-click on the ADSIEDIT node in the left-hand pane and select
Connect To in the menu that appears.

3. In the Connection Settings dialog, select Configuration in the Connection Point

section and click OK.

4. Expand the nodes in the left-hand pane until you've drilled down to your
Templates store (CN=Certificate Templates,CN=Public Key
Services,CN=Services,CN=Configuration,DC=,DC=).

5. Double-click the Version 3 template you would like to have appear in the web
enrollment page.

6. Scroll down and select the msPKI-Template-Schema-Version attribute.

7. Double-click the msPKI-Template-Schema-Version attribute and change the value

from 3 to 2 and click OK.

8. Click Apply. This updates the template and CSP list. Keep this in mind if you use
3rd-party CSPs in your environment.

9. Go to your web enrollment page (if ran from your CA server) and attempt to enroll
the certificate using an advanced request.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Restrict the use of certain cryptographic
algorithms and protocols in Schannel.dll
Article • 02/26/2024

This article describes how to restrict the use of certain cryptographic algorithms and
protocols in the Schannel.dll file. This information also applies to independent software
vendor (ISV) applications that are written for the Microsoft Cryptographic API (CAPI).

Applies to: Windows Server 2003

Original KB number: 245030

７ Note

This article applies to Windows Server 2003 and earlier versions of Windows. For
registry keys that apply to Windows Server 2008 and later versions of Windows, see
the TLS Registry Settings.

Summary
The following cryptographic service providers (CSPs) that are included with Windows NT
4.0 Service Pack 6 were awarded the certificates for FIPS-140-1 crypto validation.

Microsoft Base Cryptographic Provider (Rsabase.dll)

Microsoft Enhanced Cryptographic Provider (Rsaenh.dll) (non-export version)

Microsoft TLS/SSL Security Provider, the Schannel.dll file, uses the CSPs that are listed
here to conduct secure communications over SSL or TLS in its support for Internet
Explorer and Internet Information Services (IIS).

You can change the Schannel.dll file to support Cipher Suite 1 and 2. However, the
program must also support Cipher Suite 1 and 2. Cipher Suites 1 and 2 are not
supported in IIS 4.0 and 5.0.

This article contains the necessary information to configure the TLS/SSL Security
Provider for Windows NT 4.0 Service Pack 6 and later versions. You can use the Windows
registry to control the use of specific SSL 3.0 or TLS 1.0 cipher suites with respect to the
cryptographic algorithms that are supported by the Base Cryptographic Provider or the
Enhanced Cryptographic Provider.
 ７ Note

In Windows NT 4.0 Service Pack 6, the Schannel.dll file does not use the Microsoft
Base DSS Cryptographic Provider (Dssbase.dll) or the Microsoft DS/Diffie-Hellman
Enhanced Cryptographic Provider (Dssenh.dll).

Cipher suites
Both SSL 3.0 and TLS 1.0 (RFC2246) with INTERNET-DRAFT 56-bit Export Cipher Suites
For TLS draft-ietf-tls-56-bit-ciphersuites-00.txt provide options to use different cipher
suites. Each cipher suite determines the key exchange, authentication, encryption, and
MAC algorithms that are used in an SSL/TLS session. When you use RSA as both key
exchange and authentication algorithms, the term RSA appears only one time in the
corresponding cipher suite definitions.

The Windows NT 4.0 Service Pack 6 Microsoft TLS/SSL Security Provider supports the
following SSL 3.0-defined CipherSuite when you use the Base Cryptographic Provider or
the Enhanced Cryptographic Provider:

ﾉ Expand table

SSL 3.0 Cipher suite

SSL_RSA_EXPORT_WITH_RC4_40_MD5 { 0x00,0x03 }

SSL_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }

SSL_RSA_WITH_RC4_128_SHA { 0x00,0x05 }

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 { 0x00,0x06 }

SSL_RSA_WITH_DES_CBC_SHA { 0x00,0x09 }

SSL_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }

SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA { 0x00,0x62 }

SSL_RSA_EXPORT1024_WITH_RC4_56_SHA { 0x00,0x64 }

７ Note
 Neither SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA nor
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA is defined in SSL 3.0 text. However,
several SSL 3.0 vendors support them. This includes Microsoft.

Windows NT 4.0 Service Pack 6 Microsoft TLS/SSL Security Provider also supports the
following TLS 1.0-defined CipherSuite when you use the Base Cryptographic Provider or
Enhanced Cryptographic Provider:

ﾉ Expand table

TLS 1.0 Cipher suite

TLS_RSA_EXPORT_WITH_RC4_40_MD5 { 0x00,0x03 }

TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }

TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 { 0x00,0x06 }

TLS_RSA_WITH_DES_CBC_SHA { 0x00,0x09 }

TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA { 0x00,0x62 }

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA { 0x00,0x64 }

７ Note

A cipher suite that is defined by using the first byte 0x00 is non-private and is used
for open interoperable communications. Therefore, the Windows NT 4.0 Service
Pack 6 Microsoft TLS/SSL Security Provider follows the procedures for using these
cipher suites as specified in SSL 3.0 and TLS 1.0 to make sure of interoperability.

Schannel-specific registry keys

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
 problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

７ Note

Any changes to the contents of the CIPHERS key or the HASHES key take effect
immediately, without a system restart.

SCHANNEL key
Start Registry Editor (Regedt32.exe), and then locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

SCHANNEL\Protocols subkey
To enable the system to use the protocols that will not be negotiated by default (such as
TLS 1.1 and TLS 1.2), change the DWORD value data of the DisabledByDefault value to
0x0 in the following registry keys under the Protocols key:

SCHANNEL\Protocols\TLS 1.1\Client

SCHANNEL\Protocols\TLS 1.1\Server

SCHANNEL\Protocols\TLS 1.2\Client
SCHANNEL\Protocols\TLS 1.2\Server

２ Warning

The DisabledByDefault value in the registry keys under the Protocols key does not
take precedence over the grbitEnabledProtocols value that is defined in the
SCHANNEL_CRED structure that contains the data for an Schannel credential.

SCHANNEL\Ciphers subkey
The Ciphers registry key under the SCHANNEL key is used to control the use of
symmetric algorithms such as DES and RC4. The following are valid registry keys under
the Ciphers key.

Create the SCHANNEL Ciphers subkey in the format: SCHANNEL\(VALUE)\(VALUE/VALUE)

RC4 128/128
Ciphers subkey: SCHANNEL\Ciphers\RC4 128/128

This subkey refers to 128-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Or, change the DWORD value data to 0x0. If you do not configure the Enabled
value, the default is enabled. This registry key does not apply to an exportable server
that does not have an SGC certificate.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Triple DES 168

Ciphers subkey: SCHANNEL\Ciphers\Triple DES 168

This registry key refers to 168-bit Triple DES as specified in ANSI X9.52 and Draft FIPS
46-3. This registry key does not apply to the export version.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Or, change the DWORD data to 0x0. If you do not configure the Enabled
value, the default is enabled.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_WITH_3DES_EDE_CBC_SHA

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

７ Note

For the versions of Windows that releases before Windows Vista, the key
should be Triple DES 168/168.

RC2 128/128

Ciphers subkey: SCHANNEL\Ciphers\RC2 128/128

This registry key refers to 128-bit RC2. It does not apply to the export version.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

RC4 64/128

Ciphers subkey: SCHANNEL\Ciphers\RC4 64/128

This registry key refers to 64-bit RC4. It does not apply to the export version (but is used
in Microsoft Money).

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

RC4 56/128

Ciphers subkey: SCHANNEL\Ciphers\RC4 56/128

This registry key refers to 56-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

Disabling this algorithm effectively disallows the following value:

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

RC2 56/128

Ciphers subkey: SCHANNEL\Ciphers\RC2 56/128

This registry key refers to 56-bit RC2.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

DES 56

Ciphers subkey: SCHANNEL\Ciphers\DES 56/56

This registry key refers to 56-bit DES as specified in FIPS 46-2. Its implementation in the
Rsabase.dll and Rsaenh.dll files is validated under the FIPS 140-1 Cryptographic Module
Validation Program.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA

RC4 40/128

Ciphers subkey: SCHANNEL\Ciphers\RC4 40/128

This registry key refers to 40-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5

RC2 40/128

Ciphers subkey: SCHANNEL\Ciphers\RC2 40/128

This registry key refers to 40-bit RC2.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to
0xffffffff. Otherwise, change the DWORD value data to 0x0. If you do not configure the
Enabled value, the default is enabled.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

NULL

Ciphers subkey: SCHANNEL\Ciphers\NULL

This registry key means no encryption. By default, it is turned off.

To turn off encryption (disallow all cipher algorithms), change the DWORD value data of
the Enabled value to 0xffffffff. Otherwise, change the DWORD value data to 0x0.

Hashes

Ciphers subkey: SCHANNEL/Hashes

The Hashes registry key under the SCHANNEL key is used to control the use of hashing
algorithms such as SHA-1 and MD5. The following are valid registry keys under the
Hashes key.

MD5

Ciphers subkey: SCHANNEL\Hashes\MD5

To allow this hashing algorithm, change the DWORD value data of the Enabled value to
the default value 0xffffffff. Otherwise, change the DWORD value data to 0x0.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

SHA

Ciphers subkey: SCHANNEL\Hashes\SHA

This registry key refers to Secure Hash Algorithm (SHA-1), as specified in FIPS 180-1. Its
implementation in the Rsabase.dll and Rsaenh.dll files is validated under the FIPS 140-1
Cryptographic Module Validation Program.

To allow this hashing algorithm, change the DWORD value data of the Enabled value to
the default value 0xffffffff. Otherwise, change the DWORD value data to 0x0.

Disabling this algorithm effectively disallows the following values:

SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_WITH_RC4_128_SHA
 TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

KeyExchangeAlgorithms

Ciphers subkey: SCHANNEL/KeyExchangeAlgorithms

The KeyExchangeAlgorithms registry key under the SCHANNEL key is used to control
the use of key exchange algorithms such as RSA. The following are valid registry keys
under the KeyExchangeAlgorithms key.

PKCS

Ciphers subkey: SCHANNEL\KeyExchangeAlgorithms\PKCS

This registry key refers to the RSA as the key exchange and authentication algorithms.

To allow RSA, change the DWORD value data of the Enabled value to the default value
0xffffffff. Otherwise, change the DWORD data to 0x0.

Disabling RSA effectively disallows all RSA-based SSL and TLS cipher suites supported by
the Windows NT4 SP6 Microsoft TLS/SSL Security Provider.

FIPS 140-1 cipher suites

You may want to use only those SSL 3.0 or TLS 1.0 cipher suites that correspond to FIPS
46-3 or FIPS 46-2 and FIPS 180-1 algorithms provided by the Microsoft Base or
Enhanced Cryptographic Provider.

In this article, we refer to them as FIPS 140-1 cipher suites. Specifically, they are as
follows:

SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

To use only FIPS 140-1 cipher suites as defined here and supported by Windows NT 4.0
Service Pack 6 Microsoft TLS/SSL Security Provider with the Base Cryptographic Provider
or the Enhanced Cryptographic Provider, configure the DWORD value data of the
Enabled value in the following registry keys to 0x0:

SCHANNEL\Ciphers\RC4 128/128
SCHANNEL\Ciphers\RC2 128/128

SCHANNEL\Ciphers\RC4 64/128

SCHANNEL\Ciphers\RC4 56/128
SCHANNEL\Ciphers\RC2 56/128

SCHANNEL\Ciphers\RC4 40/128
SCHANNEL\Ciphers\RC2 40/128

SCHANNEL\Ciphers\NULL

SCHANNEL\Hashes\MD5

And configure the DWORD value data of the Enabled value in the following registry keys
to 0xffffffff:

SCHANNEL\Ciphers\DES 56/56

SCHANNEL\Ciphers\Triple DES 168/168 (not applicable in export version)

SCHANNEL\Hashes\SHA
SCHANNEL\KeyExchangeAlgorithms\PKCS

Master secret computation by using FIPS 140-1 cipher

suites
The procedures for using the FIPS 140-1 cipher suites in SSL 3.0 differ from the
procedures for using the FIPS 140-1 cipher suites in TLS 1.0.

In SSL 3.0, the following is the definition master_secret computation:

In TLS 1.0, the following is the definition master_secret computation:

where:

Selecting the option to use only FIPS 140-1 cipher suites in TLS 1.0:

Because of this difference, customers may want to prohibit the use of SSL 3.0 even
though the allowed set of cipher suites is limited to only the subset of FIPS 140-1 cipher
suites. In that case, change the DWORD value data of the Enabled value to 0x0 in the
following registry keys under the Protocols key:

SCHANNEL\Protocols\SSL 3.0\Client

SCHANNEL\Protocols\SSL 3.0\Server
 ２ Warning

The Enabled value data in these registry keys under the Protocols key takes
precedence over the grbitEnabledProtocols value that is defined in the
SCHANNEL_CRED structure that contains the data for a Schannel credential. The

default Enabled value data is 0xffffffff.

Examples of registry files

Two examples of registry file content for configuration are provided in this section of the
article. They are Export.reg and Non-export.reg.

In a computer that is running Windows NT 4.0 Service Pack 6 with the exportable
Rasbase.dll and Schannel.dll files, run Export.reg to make sure that only TLS 1.0 FIPS
cipher suites are used by the computer.

In a computer that is running Windows NT 4.0 Service Pack 6 that includes the non-
exportable Rasenh.dll and Schannel.dll files, run Non-export.reg to make sure that only
TLS 1.0 FIPS cipher suites are used by the computer.

For the Schannel.dll file to recognize any changes under the SCHANNEL registry key,
you must restart the computer.

To return the registry settings to default, delete the SCHANNEL registry key and
everything under it. If these registry keys are not present, the Schannel.dll rebuilds the
keys when you restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Support policy for Windows Server
containers in on-premises scenarios
Article • 12/26/2023

This article outlines Microsoft's support policy concerning Windows Server containers
for on-premises implementations.

Applies to: Windows Server 2019, Windows Server 2016, Windows 10 - all editions, and
Windows 11 - all editions
Original KB number: 4489234

Microsoft supports Windows Server containers for the following Windows versions and
releases:

Windows Server 2022 Standard or Datacenter editions

Windows Server 2019 Standard or Datacenter editions
Windows Server 2016 Standard or Datacenter editions
Windows 10 and Windows 11 Professional and Enterprise with Docker Desktop
installed
Azure Stack HCI (when hosting Azure Kubernetes Service on Azure Stack HCI)
Windows IoT Core
Windows Server Container hosts must have Windows installed to C:. This restriction
doesn't apply if only Hyper-V isolated containers are deployed.

Refer to Overview - Product end of support public doc for more information on the end
of support.

７ Note

For similar information about Microsoft's support policy for containers in Azure, see
Support policy for containers and related services on Azure.

Supported configurations for container hosts

Microsoft defines the supported host configurations in the following terms:

Host operating system: Windows Server, Windows 10 or Windows 11. For more
information, see Windows containers requirements.
Hypervisor: Windows 10 or Windows 11 must run Hyper-V to support containers;
Windows Server, as shown in the table, has more flexibility.
 Mirantis Container Runtime (MCR): Mirantis Container Runtime is a third-party
application used to create and manage containers that run on Windows Server. For
more information, see Windows containers requirements.
ContainerD: Used AKS Hybrid and AKS deployments.
Docker Desktop for Windows runs on Windows 10.
Container type: Microsoft supports Windows Server containers with Hyper-V
isolation. However, not all host configurations can support any container type. For
general information about Windows Server containers and container types, see
Container base images and Windows container version compatibility.

７ Note

The Linux Containers on Windows (LCOW) feature on Windows Server has been
deprecated.

Host component support

Windows Server containers on supported Windows Server versions running on physical
hardware or virtual machines (VM) on Hyper-V receive full support for issues that are
related to the operating system, base container images and/or container feature.
Running Windows Server containers on a Windows Server 2016 and higher VM hosted
on a SVVP validated hypervisor receive full support for issues that are related to the
operating system, base container images and/or container feature.

Supported configurations for Windows Server

container hosts
To deploy Windows Server containers and Hyper-V container with isolation, the Mirantis
Container Runtime must be installed (see Get started: Prep Windows for containers).

Supported container types on physical

container host
ﾉ Expand table

Hypervisor Support container types

None Windows Server containers

 Hypervisor Support container types

Hyper-V Hyper-V isolation and Windows Server containers

Supported container types on a virtual machine

container host
ﾉ Expand table

VM Host Guests OS Guest Hypervisor Supported Container

Hypervisor Types

Hyper-V Windows Server None Windows Server containers

(full or core)

Hyper-V Windows Server Hyper-V (must be running Windows Server containers

(full or core) in nested virtualization and Hyper-V isolated
mode) containers

SVVP validated Windows Server None (Hyper-V not Windows Server containers
hypervisor (full or core) supported on VMware ESX)

For more information on SVVP validated hypervisors, see Welcome to the Windows
Server Virtualization Validation Program .

Supported configurations for Windows 10 and

Windows 11 container hosts
Microsoft supports containers on Windows 10 or Windows 11 Professional or Enterprise
under the following conditions:

A physical computer operating system of Windows 1011 Professional or Enterprise

with Anniversary Update (version 1607) or later.
Hyper-V is installed.
The container type is Hyper-V with isolation (default).
Docker Desktop for Windows is installed (see Install Docker Desktop for
Windows on Docker's website). Docker Desktop for Windows is the Community
Edition (CE) and is ideal for developers and small teams looking to get started with
Docker and experimenting with container-based apps.
Starting with the Windows 10 and Windows 11 October Update 2018, we no
longer disallow users from running Windows Server containers in process isolation
 mode on Windows 10 and Windows 11 Enterprise or Professional for develop or
test purposes. See the FAQ to learn more.

７ Note

Users are no longer disallowed from running Windows Server containers in process
isolation mode on Windows 10 Enterprise or Professional for dev/test purposes
since Windows 10 October 2018 update. See the FAQ to learn more.

Microsoft doesn't provide support for the following configurations on Windows 10 and
Windows 11 Professional or Enterprise:

Docker Desktop. You can get support from the Docker Community Forums or
from Docker support. For more information, see Docker Desktop for Windows
FAQ .
Windows Server containers or Hyper-V containers with isolation on virtual
machines that are hosted on a Windows 10 or Windows 11 Professional or
Enterprise system. To use containers on a virtual machine, use Windows Server as
the host.
Windows Server containers do work on Windows 10 or Windows 11 now but aren't
fully supported.

Requirement for container hosts

For information about requirements for containers hosts, see:

Windows container requirements

System requirements for Hyper-V on Windows Server
Run Hyper-V in a Virtual Machine with Nested Virtualization
Windows Containers on Windows 10
Docker Engine on Windows
Windows Container Version Compatibility
Linux containers on Windows 10

For more information about requirements and compatibility issues for virtualization, see
Windows Server Catalog: Server Virtualization Validation Program .

Hyper-V isolated container requirements

To run Hyper-V containers, the container host must meet the requirements for running
Hyper-V itself. To summarize Hyper-V requirements for Windows Server:
 64-bit processor, with the following capabilities
Second-level address translation (SLAT): The Windows hypervisor functionality
requires SLAT (the Hyper-V management tools don't).
Hardware-assisted virtualization: This is available in processors that include a
virtualization option – specifically processors with Intel Virtualization Technology
(Intel VT) or AMD Virtualization (AMD-V) technology.
Hardware-enforced Data Execution Prevention (DEP) must be available and
enabled. For Intel systems, this is the XD bit (execute disable bit). For AMD
systems, this is the NX bit (no execute bit).
VM Monitor Mode extensions.
At least 4 GB of RAM. More memory is better. You need enough memory for the
host and all virtual machines that you want to run at the same time.
Virtualization support turned on in the BIOS or UEFI.

For more information on system requirements:

System requirements for Hyper-V on Windows Server

Windows 10 Hyper-V System Requirements
How to enable nested virtualization in an Azure VM

Supported container images

Microsoft offers four container base images that users can build from. Each base image
is a different type of Windows operating system, has a different on-disk footprint, and
has a different set of Windows API. See Container Base Images for more information.

Windows Server core: supports traditional .NET framework applications

Nano Server: built for .NET Core applications
Windows Server: provides additional Windows API set
Windows IoT Core: purpose-built for IoT applications

Container base OS images that are supported

on Windows container hosts
As outlined in Supported container hosts, not all host operating systems support both
Windows Server containers and Hyper-V isolated containers. Similarly, not all the base
images support both container types. The following table outlines which container types
you can create using each base image on each of the host operating systems.

ﾉ Expand table
 Container host Windows Server Nano Server Windows Windows IoT
OS Core container container base container base Core
base image image image container
base image

Windows Server Windows Server Windows Server Windows Server Not

2016 or 2019 containers and containers and containers and supported
Standard or Hyper-V Hyper-V Hyper-V
Datacenter containers with containers with containers with
isolation isolation isolation

Windows 10 Hyper-V Hyper-V Hyper-V Not

Professional or containers with containers with containers with supported
Enterprise isolation and isolation and isolation and
Windows Server Windows Server Windows Server
containers for containers for containers for
dev/test dev/test dev/test

Windows IoT Not supported Not supported Not supported Windows

Core Server
containers

If you plan to use container hosts that run different versions and releases of Windows,
you also need to consider the versions and releases of the container images. Some
container features aren't backward compatible, so some newer container base images
may not run on container hosts with old Operation System (OS) versions. See Windows
Container Version Compatibility for more information.

Support for container workloads

Microsoft fully supports the container base images, as described in the "Supported
container images" section.

For support of Microsoft applications like IIS, SQL and .NET running in containers, see
Microsoft repository on DockerHub for the respective container image support
guidance.

７ Note

If you are trying to move a custom application or a third-party application to

Windows Server containers running the Windows Server Core image and have
issues with missing .DLLs or other components in the Windows Server core base
image, try using the Windows Server container image as it has additional Windows
API set.
Avoid copying .DLLs from the container host to the Windows Server Core base image as
it may cause the application to misbehave. Microsoft provides some component .DLLs in
Redistributable package form. Download Redistributable packages from official
Microsoft Download Center and install it in the container image using a Dockerfile.

There isn't a “single source of truth” in terms of which .DLLs are offered in a
Redistributable form or not.

For guidance on moving legacy apps, see Lift and shift to containers.

Supported network configurations

Microsoft supports the Windows container networking functionality. This functionality
includes the Host Networking Service (HNS) and Host Compute Service (HCS). HNS and
HCS work together to create containers (HCS) and attach endpoints to a network (HNS).
Additionally, it includes the following container network drivers (for full descriptions of
these drivers, see Windows Container Network Drivers):

See this article for Unsupported features and network options.

Supported service accounts for containers

Microsoft supports Active Directory group Managed Service Accounts (gMSA) for
containers.

Containers can't be domain-joined but gMSA supports non-domain-joined and domain

joined container hosts. By using gMSA, Windows Server containers themselves and the
service they host can be configured to use a specific gMSA as their domain identity. Any
service running with the Local System or Network Service use the Windows Server
containers' identity just like they use the domain-joined host's identity. See Create
gMSAs for Windows containers for more information.

Supported endpoint security options for

containers and container hosts
Windows Defender has been optimized to protect container hosts and is fully
supported. However, Microsoft doesn't support Windows Defender running in Windows
Server containers.

When using a third-party endpoint security/anti-virus software, verify with the vendor
that Windows Server containers are supported and refer to the vendor's public docs for
recommendations and exclusions. See Anti-virus optimization for Windows Containers
for more information.

Supported Container Runtime on Windows

Server
Mirantis Container Runtime (MCR) is a recommended and supported container runtime
interface used to create, manage, and run Windows Server containers on Windows
Server. For more information, see Mirantis .

See Get Started: Prep Windows for containers for the recommended and supported
installation method on Windows Server.

After April 30, 2023, Microsoft will no longer be the first point of contact for customers
running the Mirantis Container Runtime on Windows Server. Customers need to engage
Mirantis first.

For more information, See the Message from Mirantis .

1. Microsoft will provide support for Mirantis Container Runtime until April 30, 2023.
2. Customers are licensed to run, in perpetuity, only the number of copies of Mirantis
Container Runtime obtained before April 30, 2023, and no more.
3. After April 30, 2023, customers won't be able to get support, updates, or patches
for the Mirantis container runtime from either Microsoft or Mirantis.
4. Customers can purchase a license to use a fully supported version of Mirantis
Container Runtime from Mirantis at any time.

ContainerD is an open-source industry-standard container runtime that is supported by

the community. For more information, see ContainerD project . ContainerD running on
Windows Server can create, manage, and run Windows Server Containers but Microsoft
doesn't provide any support for it. For any issues or questions related to ContainerD, ask
the GitHub community . For more information, see the GitHub ContainerD project .

Supported Container Orchestrators

Several container orchestrators support Windows Server containers. Address any issues
or questions with the vendor before engaging Microsoft support.

Azure Kubernetes Service on Azure Stack HCI (AKS-HCI) or Windows Server is an on-
premises implementation of Azure’s flag ship container service, which automates
running containerized applications at scale. AKS makes it quicker to get started hosting
Linux and Windows containers in your datacenter.
Microsoft provides end-to-end support for Azure Kubernetes Service on Azure Stack HCI
or Windows Server, including a single node without high availability.

Microsoft won't provide support for the following.

Custom application code

Any non-in-box system services or drivers in the container or container host
Container base images that aren't supported by Microsoft (such as Nginx) or
container base images that aren't listed in the supported add-ons list

For more information on support policies, see Support policies for AKS hybrid - AKS
hybrid | Microsoft Learn.

Azure Kubernetes Service Edge Essentials (AKS EE) is an on-premises Kubernetes

implementation of Azure Kubernetes Service (AKS) that automates running
containerized applications at scale. AKS Edge Essentials includes a Microsoft-supported
Kubernetes platform that includes a lightweight Kubernetes distribution with a small
footprint and simple installation experience, making it easy for you to deploy
Kubernetes on PC-class or "light" edge hardware.

Microsoft provides end-to-end support for Azure Kubernetes Service Edge Essentials
except for the following.

Custom application code

Any non-in-box system services or drivers in the container or container host
Container base images not supported by Microsoft like; Nginx or versions or base
images that aren't listed in the supported add-ons list

For more information on support policies, see Support policies for AKS hybrid - AKS
hybrid | Microsoft Learn.

Azure Kubernetes Service (AKS) is Azure’s flag ship container service; customers can
create Windows Server based node pools within an AKS cluster to run their Windows
containers. This is a fully supported service; Any issues or questions should be opened
using the Help + Support in the Azure portal.

Kubernetes is an open-source project that supports Windows Server containers on

Windows Server 2019 and higher starting with Kubernetes 1.14. For more information,
see Intro to Windows support in Kubernetes and Support Functionality and
Limitations . For more information, see Kubernetes on Windows.

For any issues and questions related to Kubernetes, see Reporting Issues and Feature
Requests .
Microsoft only provides support for Windows nodes participating in an on-premises
Kubernetes cluster.

Microsoft doesn't provide support for the following items:

Setting up and configuring Linux nodes

Kubernetes binaries
Linux containers
Kubernetes plug-ins

Any question or issue related to nonsupported items should be addressed to relevant

GitHub communities.

Azure Service Fabric is fully supported and all issues or questions should be directed to
Azure support using the Help + Support in the Azure portal. For more information, see
Introducing Service Fabric cluster resource manager and Service Fabric and containers.

Docker swarm is a feature of the Mirantis Container Runtime that creates, manages, and
runs Windows Server containers in a mixed node environment of Linux and Windows
hosts. Docker swarm is fully supported by Mirantis. Mirantis support advises customers
on whether Microsoft support should be engaged regarding issues or questions related
to Windows Server. For more information about using Docker swarm with Windows
Server containers, see Getting started with swarm mode and Swarm mode overview
on Mirantis website.

Moby is an open-source project intended for engineers, integrators and enthusiasts

looking to modify, hack, fix, experiment, invent, and build systems based on containers.
For more information, see the Moby project on GitHub.

Microsoft doesn't provide support for Moby in a stand-a-lone environment (a single-

node container host running Windows Server). All questions and issues should be raised
in the Moby project on GitHub.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy troubleshooting
documentation for Windows Server
Article • 12/26/2023

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Group Policy-related issues. The topics are divided into
subcategories. Browse the content or use the search feature to find relevant content.

Group Policy sub categories

AppLocker or software restriction policies
Deploying software through Group Policy
Group Policy management - GPMC or AGPM
Managing drive mappings through Group Policy
Managing Internet Explorer settings through Group Policy
Managing printers through Group Policy
Managing removable devices through Group Policy
Problems applying Group Policy objects to users or computers
Security filtering and item-level targeting
Sysvol access or replication issues

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to apply Group Policy objects to
Terminal Services servers
Article • 12/26/2023

This article describes how to apply Group Policy objects to Terminal Services servers.

Applies to: Windows Server 2012 R2

Original KB number: 260370

Summary
Microsoft Windows Server 2003 Terminal Services servers and Microsoft Windows 2000
Terminal Services servers are installed for users in Application Server mode. When the
Terminal Services servers are in an Active Directory domain, the domain administrator
implements Group Policy objects (GPOs) to the Terminal Services server to control the
user environment. This article describes the recommended process of applying GPOs to
Terminal Services without adversely affecting other servers on the network.

More information
There are two methods for applying GPOs to Terminal Services without adversely
affecting other servers on the network.

Method 1
Put the Terminal Server computers into their own organizational unit (OU). This
configuration permits relevant computer configuration settings to be put in GPOs that
apply only to Terminal Server computers. This configuration does not affect the user
experience on workstations or on other servers and lets you create a tightly controlled
Terminal Server experience for users. This OU should not contain users or other
computers so that domain administrators can fine-tune the Terminal Services
experience. The OU can also be delegated for control to subordinate groups such as
server operators or individual users.

To create a new OU for the Terminal Services servers, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Active
Directory Users and Computers.

2. Expand the left pane.

 3. Click domainname.xxx .

4. On the Action menu, click New, and then click Organizational Unit.

5. In the Name box, type a name for the Terminal Services server.

6. Click OK.

The new Terminal Services OU now appears in the list in the left pane and contains
no default objects. The Terminal Services servers reside in either the Computers OU
or the Domain Controllers OU.

7. Locate and then click the Terminal Services server or servers, click Action, and then
click Move.

8. In the Move dialog box, click the new Terminal Services server or servers, and then
click OK.

9. Click the new Terminal Services OU to verify that the move has successfully
occurred.

To create a Terminal Services Group Policy object, follow these steps:

1. Click the new Terminal Services OU.

2. On the Action menu, click Properties.

3. Click the Group Policy tab.

4. Click New to create the New Group Policy object.

5. Click Edit to modify the Group Policy.

７ Note

Most of the relevant settings are under Computer Configuration , Security

Settings , or Local Policies . For example, under User Rights Assignment in the
list on the right, you find Log on Locally. This setting is required for logging
on to a session on Terminal Services. You also find Access this computer from
the network. This setting is required to connect to the server outside a
Terminal Services session. This is also where you can prevent users from being
able to shut down the system. The Security Options folder is where many of
the restrictions should be made and where there are similar settings to the
NTConfig.pol file in Windows NT 4.0 Server and Terminal Server Edition.
Settings for the user part of the policy should not be applied here because the
 users have not been put into this OU with the Terminal Services server. This
article is written for computer policy implementation.

6. When modifications are completed, close the Group Policy editor, and then click
Close to close OU Properties.

Method 2
Use the Group Policy loopback feature to apply User Configuration GPO settings to
users only when they log on to the Terminal Servers. When GPO Loopback processing is
enabled for the computers in an OU that contains only Terminal Servers, those
computers apply the User Configuration settings from the set of GPOs that apply to that
OU. Additionally, those computers apply the User Configuration settings from GPOs that
are linked to or inherited by the OU that contains the user's account.

This implementation is described in the following Knowledge Base article:

231287 Loopback processing of Group Policy

When it is possible, Terminal Services should be installed on member servers instead of

on domain controllers because the users need Log on Locally user rights. When the
Logon Locally right is assigned to domain controllers, it is assigned to every domain
controller in the domain because of the shared Active Directory database. By default,
member servers are granted Log on Locally user rights in the Local Security Policy when
Terminal Services is installed in Application Server mode.

For additional information, click the following article number to view the article in the
Microsoft Knowledge Base:

186529 Local policy does not permit you to log on interactively

The computer account of the terminal server should be added to the security properties
of the GPO being created for the loopback. To do it, follow these steps:

1. Select the GPO that is created for the loopback, and then click Properties.
2. Click the Security tab, and then click Add.
3. In the Select Users, Computers, or Groups box, select the computer account, and
then click OK.
4. Click the computer account from the Group or user names box.
5. In the Permissions for computer name box, click to select the Read and Apply
Group Policy check boxes in the Allow column.
6. Click OK two times to close and save the policy settings.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot software restriction
policies
Article • 12/26/2023

This article describes common problems and solutions when troubleshooting Software
Restriction Policies (SRP) beginning with Windows Server 2008 and Windows Vista.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012

Introduction
Software Restriction Policies (SRP) is Group Policy-based feature that identifies software
programs running on computers in a domain and controls the ability of those programs
to run. You use software restriction policies to create a highly restricted configuration for
computers, in which you allow only identified applications to run. These applications are
integrated with Microsoft Active Directory Domain Services and Group Policy but can
also be configured on stand-alone computers. For more information about SRP, see
Software Restriction Policies.

Beginning in Windows Server 2008 R2 and Windows 7, Windows AppLocker can be used
instead of or in concert with SRP for a portion of your application control strategy.

Windows cannot open a program

Users receive a message stating, "Windows cannot open this program because it has
been prevented by a software restriction policy. For more information, open Event
Viewer or contact your system administrator." Or, on the command line a message
appears stating, "The system cannot execute the specified program."

Cause: The default security level (or a rule) was created so that the software program is
set as Disallowed and as a result it doesn't start.

Solution: Look in the event log for an in-depth description of the message. The event
log message indicates what software program is set as Disallowed and what rule is
applied to the program.

Modified software restriction policies aren't taking effect

Cause 1: Software restriction policies specified in a domain through Group Policy
override any policy settings configured locally. When policies aren't taking effect, it
might imply that there's a policy setting from the domain that's overriding your policy
setting.

Cause 2: Group Policy might not have refreshed its policy settings. Group Policy applies
changes to policy settings periodically; therefore, it's likely that the policy changes made
in the directory haven't yet been refreshed.

Solutions:

The computer on which you modify software restriction policies for the network
must be able to contact a domain controller. Ensure the computer can contact a
domain controller.
Refresh policy by logging off of the network and then logging on to the network
again. If any policy is applied through Group Policy, logging back in refreshes
those policies.
You can refresh policy settings with the command-line utility gpupdate or by
logging off from and then logging back on to your computer. For best results, run
gpupdate , and then sign out from and log back on to your computer. Generally,

the security settings are refreshed every 90 minutes on a workstation or server and
every 5 minutes on a domain controller. The settings are also refreshed every 16
hours, whether or not there are any changes. These settings are configurable, so
refresh intervals can be different in each domain.
Check which policies apply. Check domain level policies for No Override settings.
Software restriction policies specified in a domain through Group Policy override
any policies configured locally. Use Gpresult command-line tool to determine
what the net effect of the policy is. When policies aren't taking effect, it might
imply that there's a policy from the domain that's overriding your local setting.
If SRP and AppLocker policy settings are in the same GPO, AppLocker settings take
precedence on Windows 7, Windows Server 2008 R2, and later versions. It's
recommended to put SRP and AppLocker policy settings in different GPOs.

After adding a rule through SRP, you can't sign-in to your

computer
Cause: Your computer accesses many programs and files when it starts. You might have
inadvertently set one of these programs or files to Disallowed. Because the computer
can't access the program or file, it can't start properly.
Solution: Start the computer in Safe Mode, sign-in as a local administrator, and then
change software restriction policies to allow the program or file to run.

A new policy setting isn't applying to a specific file name

extension
Cause: The filename extension isn't in the list of supported file types.

Solution: Add the filename extension to the list of file types supported by SRP.

Software restriction policies address the problem of regulating unknown or untrusted

code. Software restriction policies are security settings to identify software and control
its ability to run on a local computer, in a site, domain, or OU. You can implement these
settings through a GPO.

A default rule isn't restricting as expected

Cause: Rules applied in a particular sequence can cause specific rules to override default
rules. SRP applies rules in the following sequence (from most specific to most general):

1. Hash rules
2. Certificate rules
3. Path rules
4. Internet Zone rules
5. Default rules

Solution: Evaluate the rules restricting the application and, if appropriate, remove all but
the Default rule.

Unable to discover which restrictions are applied

Cause: There's no apparent cause for the unexpected behavior. GPO refresh hasn't
solved the issue; further investigation is needed.

Solutions:

Investigate the System Event Log, filtering on source of "Software Restriction

Policy." The entries explicitly state which rule is implemented for each application.
Enable advanced logging.
For more information about Software Restriction Policies, see Determine Allow-
Deny List and Application Inventory for Software Restriction Policies.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to change the MSI file location in
the Software Deployment GPO (Multiple
UNC paths for same package)
Article • 04/09/2024

This article describes how to change the MSI file location in the Software Deployment
GPO and set the multiple UNC paths for the same MSI package.

Applies to: Windows Server (All supported versions)

Original KB number: 2395088

Summary
Scenario: 1

You create a GPO for deploying an MSI Package, and need to change the location of the
MSI package (UNC path). You need to create a new GPO for the package and this new
GPO would be applied to all the machines in the OU, which will further end up
redeploying the same package on the machines already having the software (installed
from the previous GPO).

Scenario: 2

You want to provide multiple paths for the same installation package and push it
through via GPO, but the GUI only gives you one option to select the package location.

More information
You can work around this using the following methods:

1. Open the GPO the Package Object it is defined in and right-click the Package
Object and select Properties.

2. Click the Deployment tab, then click the Advanced button. Note the Script Name
location. You will need the CLSID (long alphanumeric number) directly after the
\Policies notation.

3. Open the ADSI editor, connect to your domain and navigate to the System\Policies
tree on the left side of the window. Locate the CLSID you noted above.
 4. Expand this CLSID tree and then expand the following trees to get to the actual
defined Package Object: CN=Machine \ CN=Class Store \ CN=Packages.

5. Right click on the Package Object and select Properties. Navigate to the Optional
property ' msiFileList '. This property contains the UNC path of the location of the
MSI Installer file. Edit this value to represent the new UNC path.

７ Note

It is possible to have multiple UNC paths defined for a Package Object,

starting with 0:, then 1: and so on. If you are changing the UNC path, type in
the new UNC path, prefixed with 0: and click the Add button. Select the old
UNC path and click the Remove button.

6. The UNC path for the Package Object has now been updated to reflect the new
UNC path.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot software
installations by using Windows
application management debug logging
Article • 04/09/2024

This article describes how you can troubleshoot software installations by using Windows
application management debug logging.

） Important

This article contains information about how to modify the registry. Make sure to
back up the registry before you modify it. Make sure that you know how to restore
the registry if a problem occurs. For more information about how to back up,
restore, and modify the registry, click the following article number to view the
article in the Microsoft Knowledge Base: 256986 Description of the Microsoft
Windows registry

Applies to: Windows Server (All supported versions), Windows client (All supported
versions)
Original KB number: 249621

Summary
When a problem occurs with a program that is deployed on a client computer by using
Group Policy, a log file (Appmgmt.log) can be generated. This log file records
information that is related to the advertisement, publishing, or assignment of Windows
Installer applications by using Group Policy. This information, in conjunction with
logging from the Windows Installer service, can help determine the cause of a software
installation problem.

For more information about how to enable Windows Installer Logging, click the
following article number to view the article in the Microsoft Knowledge Base:

223300 How to enable Windows Installer Logging

More information
To enable diagnostic logging of Group Policy Software Installation processing, modify
the registry on the computer where the program will be installed.

To enable diagnostic logging of Group Policy Software Installation processing, follow

these steps:

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall your operating system. Microsoft cannot guarantee that these problems
can be solved. Modify the registry at your own risk.

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. In the left pane, locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics

７ Note

You may have to create the Diagnostics registry subkey.

3. On the Edit menu, point to New, and then click DWORD Value.
4. Type AppMgmtDebugLevel, and then press Enter.
5. Double-click AppMgmtDebugLevel, type 4b in the Value data box, and then click
OK.
6. Quit Registry Editor.

After you make this registry modification, a log file named Appmgmt.log is created
when Group Policy processing occurs. The Appmgmt.log file is located in the
%SystemRoot%\Debug\UserMode folder on the computer where the
AppMgmtDebugLevel registry value is enabled.

７ Note

After you troubleshoot software installations by using Windows application

management debug logging, we recommend that you delete the
AppMgmtDebugLevel registry value to avoid performance degradation.
Because of code changes in application management in Windows 8, debug
logging isn't working in Windows 8 or Windows Server 2012.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Group Policy to configure
automatic logon in Windows Server
2003 Terminal Services
Article • 12/26/2023

This step-by-step article describes how to use Group Policy to configure automatic
logon in Microsoft Windows Server 2003 Terminal Services.

Applies to: Windows Server 2003

Original KB number: 324807

Summary
When you use Remote Desktop Connection to connect to a Windows Server 2003-
based computer running Terminal Services, you can provide your logon information
before you make the connection. In this way, you automatically pass these credentials to
the server.

You specify your user name, password, and logon domain on the General tab in the
Remote Desktop Connection dialog box (in the Remote Desktop Connection client
window, click Options, and then click the General tab). When you click Connect, the
logon information that you typed becomes the default setting for all Remote Desktop
connections and is saved in the Default.rdp file.

Steps to use Group Policy to configure

automatic logon in Windows Server 2003
Terminal Services
To fully implement an automatic logon in which the user isn't prompted to supply a
password upon connection, the Always prompt client for password upon connection
policy setting must be turned off on the server. By doing so, users can automatically log
on to Terminal Services by supplying their passwords in the Remote Desktop Connection
client.

1. Click Start, click Run, type mmc in the Open box, and then click OK.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Group Policy Object Editor, and then click Add.
 5. Click the target Group Policy object (GPO). The default GPO is Local Computer.
Click Browse to select the GPO that you want, and then click Finish.
6. Click Close, and then click OK.
7. Expand the Group Policy object, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, expand Terminal
Services, and then click Encryption and Security.
8. In the right pane, double-click Always prompt client for password upon
connection.
9. Click Disabled.
10. Click OK, and then quit the Group Policy Object Editor snap-in.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Group Policy to deploy a
Known Issue Rollback
Article • 04/09/2024

This article describes how to configure Group Policy to use a Known Issue Rollback (KIR)
policy definition that activates a KIR on managed devices.

Applies to: Windows Server (All supported versions), Windows client (All supported
versions)

Summary
Microsoft has developed a new Windows servicing technology that's named KIR for
Windows Server 2019 and Windows 10, versions 1809 and later versions. For the
supported versions of Windows, a KIR rolls back a specific change that was applied as
part of a nonsecurity Windows Update release. All other changes that were made as a
part of that release remain intact. By using this technology, if a Windows update causes
a regression or other problem, you don't have to uninstall the entire update and return
the system to the last known good configuration. You roll back only the change that
caused the problem. This rollback is temporary. After Microsoft releases a new update
that fixes the problem, the rollback is no longer necessary.

） Important

KIRs apply to only nonsecurity updates. This is because rolling back a fix for a
nonsecurity update doesn't create a potential security vulnerability.

Microsoft manages the KIR deployment process for non-enterprise devices. For
enterprise devices, Microsoft provides KIR policy definition MSI files. Enterprises can
then use Group Policy to deploy KIRs in hybrid Microsoft Entra ID or Active Directory
Domain Services (AD DS) domains.

７ Note

You have to restart the affected computers in order to apply this Group Policy
change.
The KIR process
If Microsoft determines that a nonsecurity update has a critical regression or similar
issue, Microsoft generates a KIR. Microsoft announces the KIR in the Windows Health
Dashboard, and adds the information to the following locations:

The Known Issues section of the applicable Windows Update KB article

The Known Issues list on the Windows Health Release Dashboard at
https://aka.ms/windowsreleasehealth for the affected versions of Windows (for
example, Windows 10, version 20H2 and Windows Server, version 20H2)

For non-enterprise customers, the Windows Update process applies the KIR
automatically. No user action is required.

For enterprise customers, Microsoft provides a policy definition MSI file. Enterprise
customers can propagate the KIR to managed systems by using the enterprise Group
Policy infrastructure.

To see an example of a KIR MSI file, download Windows 10 (2004 & 20H2) Known Issue
Rollback 031321 01.msi .

A KIR policy definition has a limited lifespan (a few months, at most). After Microsoft
publishes an amended update to address the original issue, the KIR is no longer
necessary. The policy definition can then be removed from the Group Policy
infrastructure.

Apply KIR to a single device using Group Policy

To use Group Policy to apply a KIR to a single device, follow these steps:

1. Download the KIR policy definition MSI file to the device.

） Important

Make sure that the operating system that is listed in the .msi file name
matches the operating system of the device that you want to update.

2. Run the .msi file on the device. This action installs the KIR policy definition in the
Administrative Template.
3. Open the Local Group Policy Editor. To do this, select Start, and then enter
gpedit.msc.
4. Select Local Computer Policy > Computer Configuration > Administrative
Templates > KB ####### Issue XXX Rollback > Windows 10, version YYMM.
 ７ Note

In this step, ####### is the KB article number of the update that caused the
problem. XXX is the issue number, and YYMM is the Windows 10 version
number.

5. Right-click the policy, and then select Edit > Disabled > OK.
6. Restart the device.

For more information about how to use the Local Group Policy Editor, see Working with
the Administrative Template policy settings using the Local Group Policy Editor.

Apply a KIR to devices in a hybrid Microsoft

Entra ID or AD DS domain using Group Policy
To apply a KIR policy definition to devices that belong to a hybrid Microsoft Entra ID or
AD DS domain, follow these steps:

1. Download and install the KIR MSI files

2. Create a Group Policy Object (GPO).
3. Create and configure a WMI filter that applies the GPO.
4. Link the GPO and the WMI filter.
5. Configure the GPO.
6. Monitor the GPO results.

1. Download and install the KIR MSI files

1. Check the KIR release information or the known issues lists to identify which
operating system versions you have to update.
2. Download the KIR policy definition .msi files that you require to update to the
computer that you use to manage Group Policy for your domain.
3. Run the .msi files. This action installs the KIR policy definition in the Administrative
Template.

７ Note

Policy definitions are installed in the C:\Windows\PolicyDefinitions folder. If

you have implemented the Group Policy Central Store, you must copy the
.admx and .adml files to the Central Store.
2. Create a GPO
1. Open Group Policy Management Console, and then select Forest: DomainName >
Domains.
2. Right-click your domain name, and then select Create a GPO in this domain, and
link it here.
3. Enter the name of the new GPO (for example, KIR Issue XXX), and then select OK.

For more information about how to create GPOs, see Create a Group Policy Object.

3. Create and configure a WMI filter that applies the GPO

1. Right-click WMI Filters, and then select New.

2. Enter a name for your new WMI filter.

3. Enter a description of your WMI filter, such as Filter to all Windows 10, version
2004 devices.

4. Select Add.

5. In Query, enter the following query string:

SQL

SELECT version, producttype from Win32_OperatingSystem WHERE Version =

<VersionNumber>

） Important

In this string, <VersionNumber> represents the Windows version that you

want the GPO to apply to. The version number must use the following format
(exclude the brackets when you use the number in the string):

10.0.xxxxx

where xxxxx is a five digit number. Currently, KIRs support the following
versions:

ﾉ Expand table
 Version Build number

Windows 10, version 20H2 10.0.19042

Windows 10, version 2004 10.0.19041

Windows 10, version 1909 10.0.18363

Windows 10, version 1903 10.0.18362

Windows 10, version 1809 10.0.17763

For an up-to-date list of Windows releases and build numbers, see Windows 10 -
release information.

） Important

The build numbers that are listed on the Windows 10 release information
page don't include the 10.0 prefix. To use a build number in the query, you
must add the 10.0 prefix.

For more information about how to create WMI filters, see Create WMI Filters for the
GPO.

4. Link the GPO and the WMI filter

1. Select the GPO that you created previously, open the WMI Filtering menu, and
then select the WMI filter that you just created.
2. Select Yes to accept the filter.

5. Configure the GPO

Edit your GPO to use the KIR activation policy:

1. Right-click the GPO that you created previously, and then select Edit.
2. In the Group Policy Editor, select GPOName > Computer Configuration >
Administrative Templates > KB ####### Issue XXX Rollback > Windows 10,
version YYMM.
3. Right-click the policy, and then select Edit > Disabled > OK.

For more information about how to edit GPOs, see Edit a Group Policy object from
GPMC.
6. Monitor the GPO results
In the default configuration of Group Policy, managed devices should apply the new
policy within 90 to 120 minutes. To speed up this process, you can run gpupdate on
affected devices to manually check for updated policies.

Make sure that each affected device restarts after it applies the policy.

） Important

The fix that introduced the issue is disabled after the device applies the policy and
then restarts.

Deploy a KIR activation using Microsoft Intune

ADMX policy ingestion to the managed devices

７ Note

To use the solutions in this section, you must install the cumulative update that is
released on July 26, 2022 or a later one on the computer.

Group Policies and GPOs aren't compatible with mobile device management (MDM)
based solutions, such as Microsoft Intune. These instructions will guide you through how
to use Intune custom settings for ADMX ingestion and configure ADMX backed MDM
policies to perform a KIR activation without requiring a GPO.

To perform a KIR activation on Intune managed devices, follow these steps:

1. Download and install the KIR MSI file to get ADMX files.
2. Create a custom configuration profile in Microsoft Intune.
3. Monitor KIR activation.

1. Download and install the KIR MSI file to get ADMX files
1. Check the KIR release information or the known issues lists to identify which
operating system (OS) versions you must update.

2. Download the required KIR policy definition .msi files on the machine you use to
sign in to Microsoft Intune.
 ７ Note

You will need access to the contents of a KIR activation ADMX file.

3. Run the .msi files. This action installs the KIR policy definition in the Administrative
Template.

７ Note

Policy definitions are installed in the C:\Windows\PolicyDefinitions folder.

If you want to extract the ADMX files to another location, use the msiexec
command with the TARGETDIR property. For example:

Console

msiexec /i c:\admx_file.msi /qb TARGETDIR=c:\temp\admx

2. Create a custom configuration profile in Microsoft

Intune
To configure devices to perform a KIR activation, you need to create a custom
configuration profile for each OS of your managed devices. To create a custom profile,
follow these steps:

1. Select properties and add basic information of the profile.

2. Add custom configuration setting to ingest ADMX files for KIR activation.
3. Add custom configuration setting to set new KIR activation policy.
4. Assign devices to the KIR activation custom configuration profile.
5. Use applicability rules to target devices to receive KIR custom configuration
settings by OS.
6. Review and create KIR activation custom configuration profile.

A. Select properties and add basic information about the profile

1. Sign in to the Microsoft Intune admin center .

2. Select Devices > Configuration profiles > Create profile.

3. Select the following properties:

 Platform: Windows 10 and later
Profile: Templates > Custom

4. Select Create.

5. In Basics, enter the following properties:

Name: Enter a descriptive name for the policy. Name your policies so you can
easily identify them later. For example, a good policy name is "04/30 KIR
Activation – Windows 10 21H2".
Description: Enter a description for the policy. This setting is optional but
recommended.

７ Note

Platform and Profile type should already have values selected.

6. Select Next.

７ Note

For more information about creating custom configuration profiles and

configuration settings, see Use custom device settings in Microsoft Intune.

Before proceeding to the next two steps, open the ADMX file in a text editor (for
example, Notepad) where the file was extracted. The ADMX file should be in the path
C:\Windows\PolicyDefinitions if you installed it as an MSI file.

Here's an example of the ADMX file:

XML

<policies>
<policy name="KB5011563_220428_2000_1_KnownIssueRollback" … >
<parentCategory ref="KnownIssueRollback_Win_11" />
<supportedOn ref="SUPPORTED_Windows_11_0_Only" />
<enabledList…> … </enabledList>
<disabledList…>…</disabledList>
</policy>
</policies>

Record the values for policy name and parentCategory . This information is in the
"policies" node at the end of the file.
B. Add custom configuration setting to ingest ADMX files for KIR
activation

This configuration setting is used to install the KIR activation policy on target devices.
Follow these steps to add the ADMX ingestion settings:

1. In Configuration settings, select Add.

2. Enter the following properties:

Name: Enter a descriptive name for the configuration setting. Name your
settings so you can easily identify them later. For example, a good setting
name is "ADMX Ingestion: 04/30 KIR Activation – Windows 10 21H2".

Description: Enter a description for the setting. This setting is optional but
recommended.

OMA-URI: Enter the string

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/KIR/Policy/<AD
MX Policy Name>.

７ Note

Replace <ADMX Policy Name> with the value of the recorded policy
name from the ADMX file. For example,
"KB5011563_220428_2000_1_KnownIssueRollback".

Data type: Select String.

Value: Open the ADMX file with a text editor (for example, Notepad). Copy
and paste the entire contents of the ADMX file you intend to ingest into this
field.

3. Select Save.

C. Add custom configuration setting to set new KIR activation

policy
This configuration setting is used to configure the KIR activation policy, which is defined
in the previous step.

Follow these steps to add the KIR activation configuration settings:

1. In Configuration settings, select Add.

 2. Enter the following properties:

Name: Enter a descriptive name for the configuration setting. Name your
settings so you can easily identify them later. For example, a good setting
name is "KIR Activation: 04/30 KIR Activation – Windows 10 21H2".

Description: Enter a description for the setting. This setting is optional but
recommended.

OMA-URI: Enter the string

./Device/Vendor/MSFT/Policy/Config/KIR~Policy~KnownIssueRollback~
<Parent Category>/<ADMX Policy Name>.

７ Note

Replace <Parent Category> with the parent category string recorded in

the previous step. For example, "KnownIssueRollback_Win_11". Replace
<ADMX Policy Name> with the same policy name used in the previous
step.

Data type: Select String.

Value: Enter <disabled/>.

3. Select Save.

4. Select Next.

D. Assign devices to the KIR activation custom configuration profile

After you've defined what the custom configuration profile does, follow these steps to
identify which devices you'll configure:

1. In Assignments, select Add all devices.

2. Select Next.

E. Use applicability rules to target devices to receive KIR custom

configuration settings by OS

To target the devices by OS that are applicable to the GP, add an applicability rule to
check the device OS Version (Build) before applying this configuration. You can look up
the build numbers for the supported OS on the following pages:
 Windows 11 release information
Windows 10 release information
Windows Server release information

The build numbers shown in the pages are formatted as MMMMM.mmmm (M= major
version and m= minor version). The OS Version properties use the major version digits.
The OS Version values entered into the Applicability Rules should be formatted as
"10.0.MMMMM". For example, "10.0.22000".

Follow these instructions to set the correct Applicability Rules for your KIR activation:

1. In Applicability Rules, create an applicability rule by entering the following

properties on the blank rule already on the page:

Rule: Select Assign profile if from the dropdown list.

Property: Select OS Version from the dropdown list.
Value: Enter the Min and the Max OS version numbers formatted as
"10.0.MMMMM".

2. Select Next.

７ Note

The OS version of a device can be found by running the winver command from the
Start menu. It will show a two-part version number separated by a ".". For example,
"22000.613". You can append the left number to "10.0." for the Min OS version.
Obtain the Max OS version number by adding 1 to the last digit of the Min OS
version number. For this example, you can use these values:
Min OS version: "10.0.22000"
Max OS version: "10.0.22001"

F. Review and create KIR activation custom configuration profile

Review your settings of the custom configuration profile and select Create.

3. Monitor KIR activation

Your KIR activation should be in progress now. Follow these steps to monitor the
configuration profile progress:

1. Go to Devices > Configuration profiles, and select an existing profile. For example,
select a macOS profile.
 2. Select the Overview tab. In this view, the Profile assignment status includes the
following statuses:

Succeeded: Policy is applied successfully.

Error: The policy failed to apply. The message typically displays an error code
that links to an explanation.
Conflict: Two settings are applied to the same device, and Intune can't sort
out the conflict. An administrator should review the conflict.
Pending: The device hasn't checked in with Intune to receive the policy yet.
Not applicable: The device can't receive the policy. For example, the policy
updates a setting specific to iOS 11.1, but the device is using iOS 10.

For more information, see Monitor device configuration profiles in Microsoft Intune.

More information
Local Group Policy Editor
Working with the Administrative Template policy settings using the Local Group
Policy Editor
Group Policy Overview
GPMC How To
Create WMI Filters for the GPO (Windows 10) - Windows security
Edit a Group Policy object from GPMC
Create and manage group policy in Microsoft Entra Domain Services
Use Windows 10/11 templates to configure group policy settings in Microsoft
Intune

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Group Policy to remotely install
software
Article • 04/09/2024

This article describes how to use Group Policy to automatically distribute programs to
client computers or users.

Applies to: Windows Server (All supported versions)

Original KB number: 816102

Summary
You can use Group Policy to distribute computer programs by using the following
methods:

Assigning software

You can assign a program distribution to users or computers. If you assign the
program to a user, it's installed when the user logs on to the computer. When the
user first runs the program, the installation is completed. If you assign the program
to a computer, it's installed when the computer starts, and it's available to all users
who log on to the computer. When a user first runs the program, the installation is
completed.

Publishing software

You can publish a program distribution to users. When the user logs on to the
computer, the published program is displayed in the Add or Remove Programs
dialog box, and it can be installed from there.

７ Note

Windows Server 2003 Group Policy automated-program installation requires client

computers that are running Microsoft Windows 2000 or a later version.

Create a distribution point

To publish or assign a computer program, create a distribution point on the publishing
server by following these steps:
 1. Log on to the server as an administrator.
2. Create a shared network folder where you'll put the Windows Installer package
(.msi file) that you want to distribute.
3. Set permissions on the share to allow access to the distribution package.
4. Copy or install the package to the distribution point. For example, to distribute a
.msi file, run the administrative installation ( setup.exe /a ) to copy the files to the
distribution point.

Create a Group Policy Object

To create a Group Policy Object (GPO) to use to distribute the software package, follow
these steps:

1. Start the Active Directory Users and Computers snap-in by clicking Start, pointing
to Administrative Tools, and then clicking Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, and then click New.
4. Type a name for this new policy, and then press Enter.
5. Click Properties, and then click the Security tab.
6. Clear the Apply Group Policy check box for the security groups that you don't
want this policy to apply to.
7. Select the Apply Group Policy check box for the groups that you want this policy
to apply to.
8. When you're finished, click OK.

Assign a package
To assign a program to computers that are running Windows Server 2003, Windows
2000, or Windows XP Professional, or to users who are logging on to one of these
workstations, follow these steps:

1. Start the Active Directory Users and Computers snap-in by clicking Start, pointing
to Administrative Tools, and then clicking Active Directory Users and Computers.

2. In the console tree, right-click your domain, and then click Properties.

3. Click the Group Policy tab, select the policy that you want, and then click Edit.

4. Under Computer Configuration, expand Software Settings.

5. Right-click Software installation, point to New, and then click Package.

 6. In the Open dialog box, type the full Universal Naming Convention (UNC) path of
the shared installer package that you want. For example, \\<file server>\<share>\
<file name>.msi .

） Important

Don't use the Browse button to access the location. Make sure that you use
the UNC path of the shared installer package.

7. Click Open.

8. Click Assigned, and then click OK. The package is listed in the right-pane of the
Group Policy window.

9. Close the Group Policy snap-in, click OK, and then close the Active Directory Users
and Computers snap-in.

10. When the client computer starts, the managed software package is automatically
installed.

Publish a package
To publish a package to computer users and make it available for installation from the
Add or Remove Programs list in Control Panel, follow these steps:

1. Start the Active Directory Users and Computers snap-in by clicking Start, pointing
to Administrative Tools, and then clicking Active Directory Users and Computers.

2. In the console tree, right-click your domain, and then click Properties.

3. Click the Group Policy tab, click the policy that you want, and then click Edit.

4. Under User Configuration, expand Software Settings.

5. Right-click Software installation, point to New, and then click Package.

6. In the Open dialog box, type the full UNC path of the shared installer package that
you want. For example, \\file server\share\file name.msi .

） Important

Don't use the Browse button to access the location. Make sure that you use
the UNC path of the shared installer package.
 7. Click Open.

8. Click Publish, and then click OK.

9. The package is listed in the right-pane of the Group Policy window.

10. Close the Group Policy snap-in, click OK, and then close the Active Directory Users
and Computers snap-in.

11. Test the package.

７ Note

Because there are several versions of Windows, the following steps may be
different on your computer. If they are, see your product documentation to
complete these steps.

a. Log on to a workstation that is running Windows 2000 Professional or Windows

XP Professional by using an account that you published the package to.
b. In Windows XP, click Start, and then click Control Panel.
c. Double-click Add or Remove Programs, and then click Add New Programs.
d. In the Add programs from your network list, click the program that you
published, and then click Add. The program is installed.
e. Click OK, and then click Close.

Redeploy a package
In some cases, you may want to redeploy a software package (for example, if you
upgrade or change the package). To redeploy a package, follow these steps:

1. Start the Active Directory Users and Computers snap-in by clicking Start, pointing
to Administrative Tools, and then clicking Active Directory Users and Computers.

2. In the console tree, right-click your domain, and then click Properties.

3. Click the Group Policy tab, click the Group Policy Object that you used to deploy
the package, and then click Edit.

4. Expand the Software Settings container that contains the software installation
item that you used to deploy the package.

5. Click the software installation container that contains the package.

 6. In the right-pane of the Group Policy window, right-click the program, point to All
Tasks, and then click Redeploy application. You will receive the following message:

Redeploying this application will reinstall the application everywhere it is

already installed. Do you want to continue?

7. Click Yes.

8. Quit the Group Policy snap-in, click OK, and then close the Active Directory Users
and Computers snap-in.

Remove a package
To remove a published or assigned package, follow these steps:

1. Start the Active Directory Users and Computers snap-in by clicking Start, pointing
to Administrative Tools, and then clicking Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, click the Group Policy Object that you used to deploy
the package, and then click Edit.
4. Expand the Software Settings container that contains the software installation
item that you used to deploy the package.
5. Click the software installation container that contains the package.
6. In the right-pane of the Group Policy window, right-click the program, point to All
Tasks, and then click Remove.
7. Perform one of the following actions:

Click Immediately uninstall the software from users and computers, and
then click OK.
Click Allow users to continue to use the software but prevent new
installations, and then click OK.

8. Close the Group Policy snap-in, click OK, and then closet the Active Directory Users
and Computers snap-in.

Troubleshoot
Published packages are displayed on a client computer after you use a Group Policy to
remove them.

This situation can occur when a user has installed the program but hasn't used it. When
the user first starts the published program, the installation is finished. Group Policy then
removes the program.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

AGPM and GPRESULT not working in
Windows Server Core
Article • 04/09/2024

This article provides a solution to an error that occurs where AGPM and GPRESULT do
not work on a Windows Server Core installation.

Applies to: Windows Server (All supported versions)

Original KB number: 2987708

Symptoms

Microsoft Advanced Group Policy Management (AGPM)

Scenario
Assume that AGPM Server is installed on a computer that is running Windows Server
Core (Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2). AGPM
is installed on a client computer that is running Windows Server or a Windows client
operating system that has Remote Server Administration Tools installed. In this situation,
the following error occurs whenever an administrator tries to take control of an
unmanaged Group Policy Object (GPO):

Control GPO: < GPO Name > ...Failed

The overall error was: The data is invalid. (Exception from HRESULT: 0x8007000D)
Additional details follow.
[Error] Unable to cast object of type 'System.DBNull' to type
'Microsoft.Agpm.GroupPolicy.Interop.GPMBackup'

GPRESULT Scenario
On a Windows Server Core computer, when an administrator runs the gpresult /h
<filename.htm> command to retrieve the GPO settings for this computer or user,
GPRESULT returns the following error message:

ERROR: The Parameter is incorrect.

Cause
These issues occur because the AGPM Server component and the GPRESULT /h
command require the Group Policy Management Console (GPMC) to be installed on the
Local System. Several GPMC Interfaces will be installed on the system only when GPMC
is installed.

GPMC Interfaces

Because Windows Server Core doesn't have the GPMC Interfaces installed, applications
that use this interface will fail.

Resolution
Resolution for AGPM

Install the AGPM Server component on a Windows Server-based computer that has the
GUI installed.

Resolution for GPRESULT

Run the GPRESULT report from a remote computer against the Windows Server Core
computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Changes to Group Policy object
permissions through AGPM are ignored
Article • 04/09/2024

This article provides a workaround for an issue where changes to Group Policy object
permissions that's controlled in Advanced Group Policy Management (AGPM) aren't
saved as expected.

Applies to: Windows Server (All supported versions), Windows client (All supported
versions)
Original KB number: 3174540

Symptoms
To change permissions on a Group Policy object that's controlled in AGPM, you first
check out the policy in AGPM, and then you edit the permissions on the Security tab of
the policy object. For example, you add the Read only permission to Authenticated
Users. However, after you check in the policy to save your changes, and then you view
the Security tab on the policy, you see that your changes are not saved as expected.

Cause
This behavior is by design in AGPM 4.0 Service Pack 3 (SP3) and earlier versions. To add
permissions to newly created Group Policy objects, we recommend to that you use the
Production Delegation tab in AGPM.

Workaround
To work around this issue, follow these steps:

1. Install the Microsoft Desktop Optimization Pack March 2017 Servicing Release
on the AGPM server.

2. Set the following registry key and values on the AGPM server.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Agpm
Value name: OverrideRemovePermissionsWithoutReadAndApply
Value type: String REG_SZ
Value data: 1
 3. Restart the AGPM server.

If OverrideRemovePermissionsWithoutReadandApply is set to 1, read permissions are

saved after the policy is checked in to AGPM, but write permissions are removed.

If OverrideRemovePermissionsWithoutReadAndApply is not set or is set to any value

other than 1, AGPM behaves in the way that's described in the Symptoms section.

References
Step-by-Step Guide for Microsoft Advanced Group Policy Management 4.0
Overview Series: Advanced Group Policy Management
Operations guide for Microsoft AGPM 4.0

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to create the Central Store for
Group Policy Administrative Template
files in Windows Vista
Article • 12/26/2023

This article describes how to use the new .admx and .adml files to create and to
administer registry-based policy settings in Windows Vista, and how the Central Store is
used to store and to replicate Windows Vista policy files in a domain environment.

Applies to: Windows Vista

Original KB number: 929841

Overview
Windows Vista uses a new format to display registry-based policy settings. These
registry-based policy settings appear under Administrative Templates in the Group
Policy Object Editor. In Windows Vista, these registry-based policy settings are defined
by standards-based XML files that have an .admx file name extension. The .admx file
format replaces the legacy .adm file format. The .adm file format uses a proprietary
markup language.

In Windows Vista, Administrative Template files are divided into .admx files and
language-specific .adml files that are available to Group Policy administrators. The
changes that are implemented in Windows Vista let administrators configure the same
set of policies by using two different languages. Administrators can configure policies by
using the language-specific .adml files and the language-neutral .admx files.

Administrative Template file storage

In earlier operating systems, all the default Administrative Template files are added to
the ADM folder of a Group Policy object (GPO) on a domain controller. The GPOs are
stored in the SYSVOL folder. The SYSVOL folder is automatically replicated to other
domain controllers in the same domain. A policy file uses approximately 2 megabytes
(MB) of hard disk space. Because each domain controller stores a distinct version of a
policy, replication traffic is increased.

Windows Vista uses a Central Store to store Administrative Template files. In Windows
Vista, the ADM folder isn't created in a GPO as in earlier versions of Windows. So
domain controllers don't store or replicate redundant copies of .adm files.
 ７ Note

If you use a client that is running an earlier version of Windows to modify a policy
that is created or administered on a Windows Vista-based computer, the client
creates the ADM folder and replicates the files.

For more information, see Recommendations for managing Group Policy administrative
template (.adm) files .

The Central Store

To take advantage of the benefits of .admx files, you must create a Central Store in the
SYSVOL folder on a domain controller. The Central Store is a file location that is checked
by the Group Policy tools. The Group Policy tools use any .admx files that are in the
Central Store. The files that are in the Central Store are later replicated to all domain
controllers in the domain.

To create a Central Store for .admx and .adml files, create a folder that is named
PolicyDefinitions in the following location: \\FQDN\SYSVOL\FQDN\policies

７ Note

FQDN is a fully qualified domain name.

For example, to create a Central Store for the Test.Microsoft.com domain, create a
PolicyDefinitions folder in the following location:
\\Test.Microsoft.Com\SYSVOL\Test.Microsoft.Com\Policies

Copy all files from the PolicyDefinitions folder on a Windows Vista-based client
computer to the PolicyDefinitions folder on the domain controller. The PolicyDefinitions
folder on a Windows Vista-based computer stays in the same folder as Windows Vista.
The PolicyDefinitions folder on the Windows Vista-based computer stores all .admx files
and .adml files for all languages that are enabled on the client computer.

The .adml files on the Windows Vista-based computer are stored in a language-specific
folder. For example, English (United States).adml files are stored in a folder that is
named "en-US." Korean .adml files are stored in a folder that is named "ko_KR." If .adml
files for additional languages are required, you must copy the folder that contains the
.adml files for that language to the Central Store. When you've copied all .admx and
.adml files, the PolicyDefinitions folder on the domain controller should contain the
.admx files and one or more folders that contain language-specific .adml files.

７ Note

When you copy the .admx and .adml files from a Windows Vista-based computer,
verify that the most recent updates to these files and to Windows Vista are
installed. Also, make sure that the most recent Administrative Template files are
replicated. This advice also applies to service packs if applicable.

Group Policy administration

Windows Vista doesn't include Administrative Templates that have an .adm extension.
Additionally, earlier versions of Windows can't use the new administrative format. So
client computers that are running earlier versions of Windows can't administer new
policies that are included with Windows Vista. We recommend that you use computers
that are running Windows Vista or later versions of Windows to do Group Policy
administration.

Updating Administrative Template Files

In Group Policy for versions of Windows earlier than Windows Vista, if you change
Administrative template policy settings on local computers, the Sysvol share on a
domain controller within your domain is automatically updated with the new .ADM files.
In turn, those changes are replicated to all other domain controllers in the domain. It
might result in increased network load and storage requirements. In Group Policy for
Windows Server 2008 and Windows Vista, if you change Administrative template policy
settings on local computers, Sysvol won't be automatically updated with the new .ADMX
or .ADML files. This change in behavior is implemented to reduce network load and disk
storage requirements, and to prevent conflicts between .ADMX files and .ADML files
when edits to Administrative template policy settings are made across different locales.
To make sure that any local updates are reflected in Sysvol, you must manually copy the
updated .ADMX or .ADML files from the PolicyDefinitions file on the local computer to
the Sysvol\PolicyDefinitions folder on the appropriate domain controller.

To download the Administrative template files for Windows Server 2008, see
Administrative Templates (ADMX) for Windows Server 2008 .
Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Dcgpofix tool doesn't restore
security settings in the Default Domain
Controller Policy to their original state
Article • 12/26/2023

This article explains that the Dcgpofix tool doesn't restore security settings in the
Default Domain Controller Policy to the same state that they were in after successfully
completing Dcpromo and that it's best to use this tool only in disaster recovery scenario.

Applies to: Windows Server 2012 R2

Original KB number: 833783

Symptoms
The documentation for the Dcgpofix.exe tool incorrectly indicates that the Dcgpofix tool
will restore security settings in the Default Domain Controller Policy to the same state
that they were in immediately after Dcpromo successfully completed. This isn't the case.

It's best to use the Dcgpofix tool only in disaster recovery scenarios. The Dcpromo
operation modifies the security of the domain in an incremental manner, based on the
existing security settings on that server. Therefore, after you run Dcpromo, the final set
of security settings in the Default Domain Controller Policy depends on both the
Dcpromo operation and the security state of the system that existed before you ran
Dcpromo. Before you run Dcpromo, the security state of the system can be modified by
a number of mechanisms. For example, when you install some server applications,
changes may be made to user rights that are granted to local user accounts, such as the
SUPPORT_388945a0 account.

Cause
The Dcgpofix tool can't know what state the security settings were in before you run
Dcpromo. Therefore, the Dcgpofix tool can't return the security settings to precisely the
original state. Instead, the Dcgpofix tool recreates the two default Group Policy objects
(GPOs) and creates the settings based on the operations that are performed only during
Dcpromo.

If you have a new installation of Windows Server and no security changes are made to
the operating system before you run Dcpromo, the recreated Default Domain Controller
Policy that is created by Dcgpofix will be almost the same as the Default Domain
Controller Policy just after you run Dcpromo. However, there will be some differences in
the settings in the Default Domain Controller Policy in this case.

Resolution
For general backup and restore of the Default Domain Policy and Default Domain
Controller Policy, and also for other GPOs, Microsoft recommends that you use the
Group Policy Management Console (GPMC) to create regular backups of these GPOs.
You can then use GPMC in conjunction with these backups to restore the exact security
settings that are contained in these GPOs.

If you're in a disaster recovery scenario and you don't have any backed-up versions of
the Default Domain Policy or the Default Domain Controller Policy, you may consider
using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as
soon as you run it, you review the security settings in these GPOs and manually adjust
the security settings to suit your requirements. A fix isn't scheduled to be released
because Microsoft recommends you use GPMC to back up and restore all GPOs in your
environment. The Dcgpofix tool is a disaster-recovery tool that will restore your
environment to a functional state only. It is best not to use it as a replacement for a
backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO
backup for the Default Domain Policy and Default Domain Controller Policy doesn't
exist.

More information
The following table lists differences in security settings in the Default Domain Controller
Policy after you run the Dcgpofix tool and the settings on a new installation of Windows
Server after you run Dcpromo. Microsoft recommends that you adjust these security
settings to match the requirements in your environment after you run the Dcgpofix tool.

ﾉ Expand table

Setting in Default Value after running DCPromo Value after running DCGPOFIX
Domain Controller on cleanly installed Windows
Policy Server

Audit Settings

Audit Account Success No Auditing

Management

Audit Directory Service Success No Auditing

 Setting in Default Value after running DCPromo Value after running DCGPOFIX
Domain Controller on cleanly installed Windows
Policy Server

Access

Audit Policy Change Success No Auditing

Audit System Events Success No Auditing

User Rights

Create Global Objects Not defined SERVICE, Administrators

Deny access to SUPPORT_388945a0 (Empty)

computer from
network

Deny logon locally SUPPORT_388945a0 (Empty)

Impersonate a client Not defined SERVICE, Administrators

after authentication

Load and unload Administrators, Print Operators Administrators

device drivers

Log on as a batch job LOCAL SERVICE, (Empty)

SUPPORT_388945a0

Log on as a service NETWORK SERVICE (Empty)

Shut down the system Administrators, Backup Operators, Account Operators, Administrators,
Server Operators, Print Operators Backup Operators, Server
Operators, Print Operators

The following settings will change after you run the Dcgpofix tool:

AuditAccountManage
AuditDSAccess
AuditPolicyChange
AuditSystemEvents
SeCreateGlobalPrivilege
SeImpersonatePrivilege
SeLoadDriverPrivilege
SeShutdownPrivilege

Based on configuration options, the following settings may also change the following:

SeBatchLogonRight (only LOCAL SERVICE, not the SUPPORT_388945a0 account)

SeServiceLogonRight
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of group policy restricted
groups
Article • 01/22/2024

This article provides a description of group policy restricted groups in Windows Server
2016, Windows Server 2012 R2, and Windows Server 2008 R2 Service Pack 1.

Applies to: Windows Server 2016, Windows Server 2012 R2, Windows Server 2008 R2
Service Pack 1
Original KB number: 279301

Restricted groups allow an administrator to define the following two properties for
security-sensitive (restricted) groups:

Members
Member Of

The Members list defines who should and shouldn't belong to the restricted group. The
Member Of list specifies which other groups the restricted group should belong to.

Use the Members restricted group portion of

policy
When a restricted group policy is enforced, any current member of a restricted group
that isn't on the Members list is removed, except for administrator in the Administrators
group. Any user on the Members list that isn't currently a member of the restricted
group is added.

Use the Member Of restricted group portion of

policy
Only inclusion is enforced in this portion of a restricted group policy. The restricted
group isn't removed from other groups. It makes sure that the restricted group is a
member of groups that are listed in the Member Of dialog box.

Manage membership of domain groups by

using restricted groups
Microsoft doesn't support using restricted groups in this scenario. Restricted Groups is a
client configuration means, and can't be used with domain groups. Restricted Groups is
designed specifically to work with local groups. Domain objects must be managed
within traditional AD tools. We don't plan currently to add or support using restricted
groups as a way to manage domain groups.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x8007000D when running the
Backup-GPO PowerShell CmdLet in
Windows Server Core edition
Article • 04/09/2024

On a computer that is running Windows Server 2016 or Windows Server 2019 Core
edition and has the Group Policy Management Console (GPMC) feature installed, you
can't use the Backup-GPO PowerShell CmdLet to back up a group policy that contains
folder redirection settings.

Applies to: Windows Server (All supported versions)

PowerShell output example

This result appears in the PowerShell window:

PowerShell

PS C:\> Backup-GPO -Name FolderRedirection -Path <path>

Backup-GPO : The data is invalid. (Exception from HRESULT: 0x8007000D)

At line:1 char:1
+ Backup-GPO -Name FolderRedirection -Path <path>
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Backup-GPO], COMException
+ FullyQualifiedErrorId :
System.Runtime.InteropServices.COMException,Microsoft.GroupPolicy.Commands.B
ackupGpoComm
and

７ Note

The error code 0x8007000D stands for ERROR_INVALID_DATA.

The issue doesn't occurs when you run this command on a Windows Server
2016 or Windows Server 2019 Desktop version.

Cause
This issue is a known issue. Some modules aren't present by default in Windows Server
Core editions.

During the backup process, the system checks settings related to the type of policy
found. On Windows Server Core version, a Client-Side Extension (CSE) related library
used for Folder Redirection policies isn't present. This causes a COM Exception.

How to work around this issue

Here are three workarounds:

Run group policy backups on Desktop version of Windows Server 2016 or

Windows Server 2019.
Run group policy backups remotely from Windows 10 workstation with Remote
Service Administration Tools (RSAT) installed for GPMC.
Run the wbadmin application with the systemstatebackup option instead. This
backup includes both Active Directory database and sysvol folder content.

Reference
For more information on wbadmin syntax, see wbadmin start systemstatebackup.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

GPMC or Import-GPO cmdlet fails to
restore a GPO from backup
Article • 01/09/2024

This article helps fix an issue in which you fail to restore a Group Policy Object (GPO)
from the backup by using the Group Policy Management Console (GPMC) or the
Import-GPO cmdlet.

When you try to import or restore a GPO with one of the following options:

The wizard by selecting Restore from Backup in GPMC

The wizard by selecting Import Settings in GPMC
The Import-GPO cmdlet from the backup

You may receive the following error message:

The process cannot access the file because it is being used by another process.

The GPO file is being accessed by another

process
This issue occurs when the wizard in GPMC or the Import-GPO cmdlet tries to acquire an
exclusive handle to some file of the GPO in the SYSVOL share, but that file is being
accessed by another process. For example, a remote user is refreshing group policies.

The Process Monitor log shows that the caller (mmc.exe or powershell.exe) receives the
SHARING VIOLATION result when trying to get a handle to some file of that GPO in the
SYSVOL share.

Here's an example of a Registry.pol file:

In this request, ShareMode is None, indicating this handle should be exclusive. That
means the handle can't coexist with any existing handle to the same file, and no other
handle to the same file is allowed before this exclusive handle is closed.

The exclusive handle is necessary in this scenario because each file of the GPO in the
SYSVOL share will be replaced by the corresponding file from the backup. Failure of any
file will cause the restore operation to fail.

For more information about the share mode, see:

CreateFileA function (fileapi.h)

Creating and Opening Files

Specify a different target domain controller

(DC)
By default, the target DC used by GPMC or the Import-GPO cmdlet is the primary
domain controller (PDC) Flexible Single Master Operation (FSMO) role of the domain.
This behavior is by design.

To work around this issue, specify a different DC with no or little user access.

In GPMC, expand Domains in the console tree, right-click the domain, and select
Change Domain Controller.

For the Import-GPO cmdlet, use the -Server parameter. For example:

Powershell

Import-GPO -BackupGpoName TestGPO1 -TargetName TestGPO1 -Path C:\GOPBackup\

 -Server ContosoDC2

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Loopback processing of Group Policy
Article • 12/26/2023

This article helps you resolve the problem of applying the Group Policy loopback
function when a user signs in to a computer in a specific organizational unit.

Applies to: Windows Server 2012 R2

Original KB number: 231287

Summary
Group Policy applies to the user or computer in a manner that depends on where both
the user and the computer objects are located in Active Directory. In some cases, users
may need policy applied to them based on the location of the computer object alone.
You can use the Group Policy loopback feature to apply Group Policy Objects (GPOs)
that depend only on which computer the user signs in to.

More information
To set user configuration per computer, follow these steps:

1. In the Group Policy Microsoft Management Console (MMC), select Computer

Configuration.
2. Locate Administrative Templates, select System, select Group Policy, and then
enable the Loopback Policy option.

This policy directs the system to apply the set of GPOs for the computer to any user who
logs on to a computer affected by this policy. This policy is intended for special-use
computers where you must modify the user policy based on the computer that's being
used. For example, computers in public areas, in laboratories, and in classrooms.

７ Note

Loopback is supported only in an Active Directory environment. Both the computer

account and the user account must be in Active Directory. If a Microsoft Windows
NT 4.0 based domain controller manages either account, the loopback does not
function. The client computer must be a running one of the following operating
systems:

Windows XP Professional
 Windows 2000 Professional
Windows 2000 Server
Windows 2000 Advanced Server
Windows Server 2003

When users work on their own workstations, you may want Group Policy settings
applied based on the location of the user object. So we recommend you to configure
policy settings based on the organizational unit in which the user account resides. When
a computer object resides in a specific organizational unit, the user settings of a policy
should be applied based on the location of the computer object instead of the user
object.

７ Note

You cannot filter the user settings that are applied by denying or removing the AGP
and Read rights from the computer object specified for the loopback policy.

Normal user Group Policy processing specifies that computers located in their
organizational unit have the GPOs applied in order during computer startup. Users in
their organizational unit have GPOs applied in order during logon, regardless of which
computer they log on to.

This processing order may not be appropriate in some cases. For example, when you
don't want applications that have been assigned or published to the users in their
organizational unit to be installed when the user is logged on to a computer in a specific
organizational unit. With the Group Policy loopback support feature, you can specify
two other ways to retrieve the list of GPOs for any user of the computers in this specific
organizational unit:

Merge Mode

In this mode, when the user logs on, the user's list of GPOs is typically gathered by
using the GetGPOList function. The GetGPOList function is then called again by
using the computer's location in Active Directory. The list of GPOs for the
computer is then added to the end of the GPOs for the user. It causes the
computer's GPOs to have higher precedence than the user's GPOs. In this example,
the list of GPOs for the computer is added to the user's list.

Replace Mode
 In this mode, the user's list of GPOs isn't gathered. Only the list of GPOs based on
the computer object is used.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to give users access to Group
Policy Objects
Article • 12/26/2023

This article describes how to give users permission to access the Group Policy object if
the Access Control List (ACL) has been modified so that Read and Apply permissions are
restricted.

Applies to: Windows Server 2012 R2

Original KB number: 273857

Summary
You may not be able to apply a Group Policy object if the Access Control List (ACL) has
been configured to restrict Read and Apply permissions for the Group Policy object.

More information
By default, if you're a member of the Authenticated Users group, you have access to
Group Policy objects. The Authenticated Users group has Read and Apply Group Policy
permissions on Group Policy objects. If the Authenticated Users group is removed from
the ACL on the Group Policy object, then you don't have Read and Apply permissions for
that Group Policy object.

As an administrator, you can give users access to the Group Policy object by using either
of the following methods:

Add the user to the ACL on the Group Policy object explicitly, and then give this
user Read and Apply Group Policy permissions.
Give the Authenticated Users group Read and Apply Group Policy permissions.
Create a security group, add the necessary users to this group, and then give this
group Read and Apply Group Policy permissions on the ACL of the Group Policy
object.

７ Note

You must also ensure that the user, or the group that the user belongs to, isn't
explicitly denied access to the Group Policy object. An explicit Deny permission
always overrides an Allow permission.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set event log security locally or
by using Group Policy
Article • 12/26/2023

You can customize security access rights to their event logs in Windows Server 2012.
These settings can be configured locally or through Group Policy. This article describes
how to use both of these methods.

Applies to: Windows Server 2012 Standard, Windows Server 2012 Datacenter
Original KB number: 323076

Summary
You can grant users one or more of the following access rights to event logs:

Read
Write
Clear

） Important

You can configure the security log in the same way. However, you can change only
Read and Clear access permissions. Write access to the security log is reserved only
for the Windows Local Security Authority (LSA).

You can use an Administrative Template Policy for the purpose. The path for the System
Eventlog, for example, is:

Computer Configuration\Administrative Templates\Windows Components\Event log

Service\System

The setting is configure log access and it takes the same Security Descriptor Definition
Language (SDDL) string.

Microsoft suggests moving to this method once you are on Windows Server 2012.

Configure event log security locally

 ） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

The security of each log is configured locally through the values in the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog .

For example, the Application log Security Descriptor is configured through the following
registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

And the System log Security Descriptor is configured through

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD .

The Security Descriptor for each log is specified by using SDDL syntax. For more
information about SDDL syntax, see the Platform SDK, or see the article mentioned in
the References section of this article.

To construct an SDDL string, note that there are three distinct rights that pertain to
event logs: Read, Write, and Clear. These rights correspond to the following bits in the
access rights field of the ACE string:

1= Read
2 = Write
4 = Clear

The following is a sample SDDL that shows the default SDDL string for the Application
log. The access rights (in hexadecimal) are bold-faced for illustration:

O:BAG:SYD:(D;; 0xf0007 ;;;AN)(D;; 0xf0007 ;;;BG)(A;; 0xf0007 ;;;SY)(A;; 0x5 ;;;BA)(A;; 0x7
;;;SO)(A;; 0x3 ;;;IU)(A;; 0x2 ;;;BA)(A;; 0x2 ;;;LS)(A;; 0x2 ;;;NS)

For example, the first ACE denies Anonymous Users read, write, and clear access to the
log. The sixth ACE permits Interactive Users to read and write to the log.
Modify your local policy to permit
customization of the security of your event logs
1. Back up the %WinDir%\Inf\Sceregvl.inf file to a known location.

2. Open %WinDir%\Inf\Sceregvl.inf in Notepad.

3. Scroll to the middle of file, and then put the pointer immediately before [Strings].

4. Insert the following lines:

MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD
,1,%AppLogSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%
SysLogSD%,2

5. Scroll to the end of the file, and then insert the following lines:

AppLogSD="Event log: Specify the security of the application log in Security

Descriptor Definition Language (SDDL) syntax"
SysLogSD="Event log: Specify the security of the System log in Security
Descriptor Definition Language (SDDL) syntax"

6. Save and then close the file.

7. Select Start, select Run, type regsvr32 scecli.dll in the Open box, and then press
ENTER.

8. In the DllRegisterServer in scecli.dll succeeded dialog box, select OK.

Use the computer's local group policy to set

your application and system log security
1. Select Start, select Run, type gpedit.msc, and then select OK.
2. In the Group Policy editor, expand Windows Setting, expand Security Settings,
expand Local Policies, and then expand Security Options.
3. Double-click Event log: Application log SDDL, type the SDDL string that you want
for the log security, and then select OK.
4. Double-click Event log: System log SDDL, type the SDDL string that you want for
the log security, and then select OK.
Use group policy to set your application and
system log security for a domain, site, or
organizational unit in Active Directory

） Important

To view the group policy settings that are described in this article in the Group
Policy editor, first complete the following steps, and then continue to the Use
group policy to set your application and system log security section:

1. Use a text editor such as Notepad to open the Sceregvl.inf in the %Windir%\Inf
folder.

2. Add the following lines to the [Register Registry Values] section:

MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD
,1,%AppCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD,1,
%SecCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%
SysCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Directory
Service\CustomSD,1,%DSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\DNS
Server\CustomSD,1,%DNSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication
Service\CustomSD,1,%FRSCustomSD%,2

3. Add the following lines to the [Strings] section:

AppCustomSD="Eventlog: Security descriptor for Application event log"

SecCustomSD="Eventlog: Security descriptor for Security event log"
SysCustomSD="Eventlog: Security descriptor for System event log"
DSCustomSD="Eventlog: Security descriptor for Directory Service event log"
DNSCustomSD="Eventlog: Security descriptor for DNS Server event log"
FRSCustomSD="Eventlog: Security descriptor for File Replication Service event
log"
 4. Save the changes you made to the Sceregvl.inf file, and then run the regsvr32
scecli.dll command.

5. Start Gpedit.msc, and then double-click the following branches to expand them:

Computer Configuration
Windows Settings
Security Settings
Local Policies
Security Options

6. View the right panel to find the new Eventlog settings.

Use group policy to set your application and system log

security
1. In the Active Directory Sites and Services snap-in or the Active Directory Users and
Computers snap-in, right-click the object for which you want to set the policy, and
then select Properties.

2. Select the Group Policy tab.

3. If you must create a new policy, select New, and then define the policy's name.
Otherwise, go to step 5.

4. Select the policy that you want, and then select Edit.

The Local Group Policy MMC snap-in appears.

5. Expand Computer Configuration, expand Windows Settings, expand Security

Settings, expand Local Policies, and then select Security Options.

6. Double-click Event log: Application log SDDL, type the SDDL string that you want
for the log security, and then select OK.

7. Double-click Event log: System log SDDL, type the SDDL string that you want for
the log security, and then select OK.

References
For more information about SDDL syntax and about how to construct an SDDL string,
see Security Descriptor String Format.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommendations for managing Group
Policy administrative template (.adm)
files
Article • 12/26/2023

This article describes how ADM files work, the policy settings that are available to
manage their operation, and recommendations about how to handle common ADM file
management scenarios.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 816662

７ Note

We recommend that you use Windows Vista to manage the Group Policy
infrastructure by using a central store. This recommendation holds true even when
the environment has a mix of down-level clients and servers, such as computers
that are running Windows XP or Windows Server 2003. Windows Vista uses a new
model that employs ADMX and ADML files to manage Group Policy templates.

For more information, visit the following Web sites:

Deploying Group Policy Using Windows Vista

How to create the Central Store for Group Policy Administrative Template
files in Windows Vista

If you must use Windows XP-based or Windows Server 2003-based computers to

manage the Group Policy infrastructure, see the recommendations in this article.

Introduction to ADM files

ADM files are template files that are used by Group Policies to describe where registry-
based policy settings are stored in the registry. ADM files also describe the user
interface that administrators see in the Group Policy Object Editor snap-in. Group Policy
Object Editor is used by administrators when they create or modify Group Policy objects
(GPOs).

ADM file storage and defaults

In the Sysvol folder of each domain controller, each domain GPO maintains a single
folder, and this folder is named the Group Policy Template (GPT). The GPT stores all the
ADM files that were used in Group Policy Object Editor when the GPOs were last created
or edited.

Each operating system includes a standard set of ADM files. These standard files are the
default files that are loaded by Group Policy Object Editor. For example, Windows Server
2003 includes the following ADM files:

System.adm
Inetres.adm
Conf.adm
Wmplayer.adm
Wuau.adm

Custom ADM files

Custom ADM files can be created by program developers or IT professionals to extend
the use of registry-based policy settings to new programs and components.

７ Note

Programs and components must be designed and coded to recognize and respond
to the policy settings that are described in the ADM file.

To load ADM files in Group Policy Object Editor, follow these steps:

1. Start the Group Policy Object Editor.

2. Right-click Administrative Templates, and then click Add/Remove Templates.

７ Note

Administrative Templates are available under either Computer or User

Configuration. Select the configuration that is correct for your custom
template.

3. Click Add.

4. Click an ADM file, and then click Open.

5. Click Close.
 6. The custom ADM file policy settings are now available in Group Policy Object
Editor.

Update ADM files and timestamps

Each administrative workstation that is used to run Group Policy Object Editor stores
ADM files in the %windir%\Inf folder. When GPOs are created and first edited, the ADM
files from this folder are copied to the Adm subfolder in the GPT. This includes the
standard ADM files and any custom ADM files that are added by the administrator.

７ Note

Creating a GPO without later editing that GPO creates a GPT without any ADM files.

By default, when GPOs are edited, Group Policy Object Editor compares the timestamps
of the ADM files in the workstation's %windir%\Inf folder with those that are stored in
the GPTs Adm folder. If the workstation's files are newer, Group Policy Object Editor
copies these files to the GPT Adm folder, overwriting any existing files of the same
name. This comparison occurs when the Administrative Templates node (computer or
user configuration) is selected in Group Policy Object Editor, regardless of whether the
administrator actually edits the GPO.

７ Note

The ADM files stored in the GPT can be updated by viewing a GPO in Group Policy
Object Editor.

Because of the importance of timestamps on ADM file management, editing of system-

supplied ADM files is not recommended. If a new policy setting is required, Microsoft
recommends that you create a custom ADM file. This prevents the replacement of
system-supplied ADM files when service packs are released.

Group Policy Management Console

By default, the Group Policy Management Console (GPMC) always uses local ADM files,
regardless of their time stamp, and never copies the ADM files to the Sysvol. If an ADM
file is not found, GPMC looks for the ADM file in the GPT. Also, the GPMC user can
specify an alternative location for ADM files. If an alternative location is specified, this
alternative location takes precedence.
GPO replication
The File Replication Service (FRS) replicates the GPTs for GPOs throughout the domain.
As part of the GPT, the Adm subfolder is replicated to all domain controllers in the
domain. Because each GPO stores multiple ADM files, and some can be quite large, you
must understand how ADM files that are added or updated when you use Group Policy
Object Editor can affect replication traffic.

Use policy settings to control ADM file updates

Two policy settings area available to help with management of ADM files. These settings
make it possible for the administrator to tune the use of ADM files for a specific
environment. These are the "Turn off automatic updates of ADM files" and the "Always
use local ADM files for Group Policy Editor" settings.

Turn off automatic updates of ADM files

This policy setting is available under User Configuration\Administrative
Templates\System\Group Policy in Windows Server 2003, in Windows XP, and in
Windows 2000. This setting may be applied to any Group Policy-enabled client.

Always use local ADM files for Group Policy editor

This policy setting is available under Computer Configuration\Administrative
Templates\System\Group Policy. This is a new policy setting. It may be successfully
applied only to Windows Server 2003 clients. The setting may be deployed to older
clients, but it will have no effect on their behavior. If this setting is enabled, Group Policy
Object Editor always uses local ADM files in the local system %windir%\Inf folder when
you edit a Group Policy object.

７ Note

If this policy setting is enabled, the Turn off automatic updates of ADM files policy
setting is implied.

Common scenarios and recommendations for

multilanguage administration issues
In some environments, policy settings may have to be presented to the user interface in
different languages. For example, an administrator in the United States may want to
view policy settings for a specific GPO in English, and an administrator in France may
want to view the same GPO by using French as their preferred language. Because the
GPT can store only one set of ADM files, you cannot use the GPT to store ADM files for
both languages.

For Windows 2000, the use of local ADM files by Group Policy Object Editor is not
supported. To work around this, use the "Turn off automatic updates of ADM files"
policy setting. Because this policy setting has no effect on the creation of new GPOs, the
local ADM files will be uploaded to the GPT in Windows 2000, and creating a GPO in
Windows 2000 effectively defines "the language of the GPO". If the "Turn off automatic
updates of ADM files" policy setting is in effect at all Windows 2000 workstations, the
language of the ADM files in the GPT will be defined by the language of the computer
that is used to create the GPO.

For administrators that are using Windows XP and Windows Server 2003, the "Always
use local ADM files for Group Policy editor" policy setting can be used. This makes it
possible for the French administrator to view policy settings by using the ADM files that
are installed locally on his or her workstation (French), regardless of the ADM file that is
stored in the GPT. When you use this policy setting, it is implied that the "Turn off
automatic updates of ADM files" policy setting is enabled to avoid unnecessary updates
of the ADM files to the GPT.

Also, consider standardizing on the latest operating system from Microsoft for
administrative workstations in a multi-language administrative environment. Then
configure both the "Always use local ADM files for Group Policy editor" and "Turn off
automatic updates of ADM files" policy settings.

If Windows 2000 workstations are being used, use the "Turn off automatic updates of
ADM files" policy setting for administrators and consider the ADM files in the GPT to be
the effective language for all Windows 2000 workstations.

７ Note

Windows XP workstations may still use their local, language specific versions.

Common scenarios and recommendations for

operating system and service pack release
issues
Each operating system or service pack release includes a superset of the ADM files
provided by earlier releases, including policy settings that are specific to operating
systems that are different to those of the new release. For example, the ADM files that
are provided with Windows Server 2003 include all policy settings for all operating
systems, including those that are only relevant to Windows 2000 or Windows XP
Professional. This means that only viewing a GPO from a computer with the new release
of an operating system or service pack effectively upgrades the ADM files. As later
releases are typically a superset of previous ADM files, this will not typically create
problems, assuming that the ADM files that are being used have not been edited.

In some situations, an operating system or service pack release may include a subset of
the ADM files that was provided with earlier releases. This has the potential to present
an earlier subset of the ADM files, resulting in policy settings no longer being visible to
administrators when they use Group Policy Object Editor. However, the policy settings
will remain active in the GPO. Only the visibility of the policy settings in Group Policy
Object Editor is affected. Any active (either Enabled or Disabled) policy settings are not
visible in Group Policy Object Editor, but remain active. Because the settings are not
visible, it is not possible for the administrator to view or edit these policy settings. To
work around this issue, administrators must become familiar with the ADM files that are
included with each operating system or service pack release before using Group Policy
Object Editor on that operating system, keeping in mind that the act of viewing a GPO is
enough to update the ADM files in the GPT, when the timestamp comparison
determines an update is appropriate.

To plan for this in your environment, Microsoft recommends that you either:

Define a standard operating system/service pack from which all viewing and
editing of GPOs occurs, making sure that the ADM files that are being used include
the policy settings for all platforms.

Use the "Turn off automatic updates of ADM files" policy setting for all Group
Policy administrators to make sure that ADM files are not overwritten in the GPT by
any Group Policy Object Editor session, and make sure that you are using the latest
ADM files that are available from Microsoft.

７ Note

The "Always use local ADM files for Group Policy editor" policy is typically used with
this policy, when it is supported by the operating system from which Group Policy
Object Editor is run.
Remove ADM files from the Sysvol folder
By default, ADM files are stored in the GPT, and this can significantly increase the Sysvol
folder size. Also, frequent editing of GPOs can result in a significant amount of
replication traffic. Using a combination of the "Turn off automatic updates of ADM files"
and "Always use local ADM files for Group Policy editor" policy settings can greatly
reduce the size of Sysvol folder and reduce policy-related replication traffic where a
significant number of policy edits occur.

If the size of the Sysvol volume or Group Policy-related replication traffic becomes
problematic, consider implementing an environment where the Sysvol does not store
any ADM files. Or consider maintaining ADM files on administrative workstations. This
process is described in the following section.

To clear the Sysvol folder of ADM files, follow these steps:

1. Enable the "Turn off automatic update of ADM files" policy setting for all Group
Policy administrators who will be editing GPOs.
2. Make sure that this policy has been applied.
3. Copy any custom ADM templates to the %windir%\Inf folder.
4. Edit existing GPOs, and then remove all ADM files from the GPT. To do this, right-
click Administrative Templates, and then click Add/Remove Template.
5. Enable the "Always use local ADM files for Group Policy Object Edit" policy setting
for administrative workstations.

Maintain ADM files on administrative

workstations
When you use the "Always use local ADM files for Group Policy editor" policy setting,
make sure that each workstation has the latest version of the default and custom ADM
files. If all ADM files are not available locally, some policy settings that are contained in a
GPO will not be visible to the administrator. Avoid this by implementing a standard
operating system and service pack version for all administrators. If you cannot use a
standard operating system and service pack, implement a process to distribute the latest
ADM files to all administrative workstations.

７ Note

Because the workstation ADM files are stored in the %windir%\Inf folder, any
process that is used to distribute these files must run in the context of an
 account that has administrative credentials on the workstation.
Windows XP does not support editing GPOs when there are no ADM files in
the Sysvol folder. In a live environment, you must consider this design
limitation.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Permissions for this GPO in the SYSVOL
folder are inconsistent with those in
Active Directory" message when you
run GPMC
Article • 12/26/2023

This article provides a solution to a permissions issue that occurs when you run Group
Policy Management Console in a Windows 2008 or Windows Server 2003 domain.

Applies to: Windows Server 2012 R2

Original KB number: 2838154

Symptoms
When you run Group Policy Management Console (GPMC) in a Windows Server 2008 or
Windows Server 2003 domain, and then you select either Default Domain Policy or
Default Domain Controllers Policy, you receive one of the following messages:

The permissions for this GPO in the SYSVOL folder are inconsistent with those
in Active Directory. It is recommended that these permissions be consistent. To
change the permissions in SYSVOL to those in Active Directory, click OK.

You receive this message if you have the permissions to modify security on the
Group Policy Objects (GPOs).

The permissions for this GPO in the SYSVOL folder are inconsistent with those
in Active Directory. It is recommended that these permissions be consistent.
Contact an administrator who has rights to modify security on this GPO.

You receive this message if you don't have the permissions to modify security on
the Group Policy Objects (GPOs).

Cause
This issue occurs for one of the following reasons:
 The access control list (ACL) on the Sysvol part of the Group Policy Object is set to
inherit permissions from the parent folder.
The Special permission (List object) is set for the Authenticated Users group.
However, the Authenticated Users group is missing from the Delegation tab of the
Group Policy Object.

Resolution
If you have permissions to modify security on the default GPOs, select OK in response to
the message that is mentioned in the Symptoms section. This action modifies the ACLs
on the Sysvol part of the Group Policy Object and makes them consistent with the ACLs
on the Active Directory component. In this situation, Group Policy removes the
inheritance attribute in the Sysvol folder.

If you still receive the message, follow these steps:

1. Make sure that you're running the latest service pack for the system. For more
information, see:

How to obtain the latest service pack for Windows Server 2008

2. Check whether the List object permission is set for the Authenticated Users group
and whether the Authenticated Users group is missing from the Delegation tab of
the Group Policy Object.
If these conditions are true, take one of the following actions:

1. Select Restore defaults to reset the permissions to defaults.

2. Remove the Authenticated Users group that has the List object permission (not
recommended).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Remove this item if it is no longer
applied" option behavior in Group
Policy preferences
Article • 12/26/2023

This article describes the behavior of the Remove this item if it is no longer applied
option in Group Policy preferences.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 3060859

Summary
Windows Server 2008 and later versions of Windows use the Group Policy preferences
feature. On the Common tab in Group Policy preferences, there's a Remove this Item
when it is no longer applied option. This option removes a preferences item if it was
applied before. There is a local database on the computer that stores this information.

Because the Remove this item when it is no longer applied option is considered on a
per-machine basis, this database is not roamed under Roaming User Profiles. Therefore,
if a change is made by Group Policy preferences to portions of the user profile that
roam between computers (for example, the user registry), the Remove this item if it is
no longer applied option should not be used. This option does not work in a roaming
scenario.

More information
For a computer policy setting, the database is stored in the following location:

C:\ProgramData\Microsoft\Group Policy\History
For a user policy setting, the database is stored in the following location:

C:\Users%username%\AppData\Local\Microsoft\Group Policy\History

Feedback
Was this page helpful?  Yes  No
Provide product feedback
How to reset user rights in the default
domain group policy in Windows Server
2003
Article • 12/26/2023

This article describes how to reset user rights in the default domain Group Policy object
(GPO) in Windows Server 2003.

Applies to: Windows Server 2003

Original KB number: 324800

Summary
The default domain GPO contains many default user-rights settings. Sometimes, if you
change the default settings, unexpected restrictions may be put on user rights. If the
changes are unexpected or if the changes were not recorded so that you do not know
which changes were made, you may have to reset the user-rights settings to their
default values.

Reset User Rights for the Default Domain GPO

To restore user rights to use the default settings for the default domain GPO, follow the
procedures that are described in this section in the order that they are presented.

２ Warning

Make sure that you use caution when you perform the following procedures. If you
configure the GPO template incorrectly, you may cause your domain controllers to
be inoperable.

Edit the Gpttmpl.inf File

To edit the Gpttmpl.inf file, follow these steps.

） Important

Back up the Gpttmpl.inf file before you perform this procedure.

1. Start Windows Explorer and open the following folder, where Sysvol_path is the
path of the Sysvol folder:

Sysvol_path\Sysvol\DomainName\Policies\{31B2F340-016D-11D2-945F-
00C04FB984F9}\Machine\Microsoft\Windows NT\SecEdit

７ Note

The default path of the Sysvol folder is %SystemRoot%\Sysvol.

2. Right-click Gpttmpl.inf, and then click Open.

3. To completely reset the user rights to the default settings, replace the existing
information in the Gpttmpl.inf file with the following default user-rights
information. To do so, paste the following text in the appropriate section of your
current Gpttmpl.inf file:

INF

Unicode=yes
[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 1
LockoutBadCount = 0
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
ClearTextPassword = 0
[Kerberos Policy]
MaxTicketAge = 10
MaxRenewAge = 7
MaxServiceAge = 600
MaxClockSkew = 5
TicketValidateClient = 1
[Version]
signature="$CHICAGO$"
Revision=1

4. On the File menu, click Save, and then click Exit.

７ Note

The permissions settings that result from this procedure are the same as the
permissions that are compatible with pre-Microsoft Windows 2000 users and
 permissions that are compatible only with Windows 2000 users.

Edit the Gpt.ini File

The Gpt.ini file controls the GPO template version numbers. You must edit the Gpt.ini file
to increase the GPO template version number. To do so:

1. Start Windows Explorer and open the following folder, where Sysvol_path is the
path of the Sysvol folder: Sysvol_path\Sysvol\Domain\Policies\{31B2F340-016D-
11D2-945F-00C04FB984F9}

７ Note

The default path of the Sysvol folder is %SystemRoot%\Sysvol.

2. Right-click Gpt.ini, and then click Open.

3. Increase the version number to a number that is sufficient to guarantee that typical
replication does not outdate the new version number before the policy is reset.
Increment the number either by adding the number "0" to the end of the version
number or the number "1" to the beginning of the version number.

4. On the File menu, click Save, and then click Exit.

Use GPUpdate to Refresh the Group Policy

Apply the new GPO by using the GPUpdate tool to manually reapply all policy settings.
To do so:

1. Click Start, and then click Run.

2. In the Open box, type cmd, and then click OK.

3. At the command prompt, type the following line, and then press ENTER: GPUpdate
/Force

4. Type exit and then press ENTER to quit the command prompt.

７ Note

To look for errors in policy processing, review the event log.

Use Event Viewer to verify that the GPO was successfully applied. To do so:

1. Click Start, point to Administrative Tools, and then click Event Viewer.
2. Click Application.

Look for Event ID 1704 to verify that the GPO was successfully applied.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Importing a GPO using GPMC fails with
"The Directory is not empty"
Article • 12/26/2023

This article provides solutions to an issue where importing a saved GPO using Group
Policy Management Console (GPMC) fails.

Applies to: Windows Server 2012 R2

Original KB number: 2667462

Symptoms
Importing a saved GPO using Group Policy Management Console (GPMC) sporadically
fails with an error dialog "The Directory is not empty".

Cause
During Import of the Policy settings, GPMC creates several temporary directories
(staging) and backups the old settings in separate folders.

As the Import is done on the SysVol share, DFSR replication might interfere with the
import sequence and therefore show the above error.

Resolution 1
To prevent the conflicting operations from occurring, use DFSRDIAG.EXE to suspend
replication on the DC the GPMC import is happening on. The command requires the
user to specify the Replication Group name, the Partner name (in this case the DC used
for the import is the partner) and the amount of time in minutes to suspend replication.
DFSR will automatically resume replication once the number of minutes specified has
elapsed.

1. Open an administrative Command Prompt window.

2. Run this command: DFSRDIAG StopNow /rgname:"Domain System Volume" /partner:

<DcName> /time:<number of minutes to suspend replication> .

７ Note
 In this command, <DcName> represents the domain controller name, and
<number of minutes to suspend replication> represents how long replication is
suspended.

3. Import the Group Policy.

７ Note

DFSR will log event 5106 when replication is stopped and again when it resumes.
You can use these events to monitor the service state.

Event 5106 when replication is paused:

Log Name: DFS Replication

Source: DFSR
Event ID: 5106
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Description:
The replication mode on the connection to partner <Dc Name> has changed.

Additional Information:
Previous Replication Mode: Obey Configured Schedule
Current Replication Mode: Stop Replication
Current Bandwidth Usage: Full
Duration, in minutes, for current mode: 5
Connection ID: 79E6D60D-6044-4775-A9BE-D98DAF557BD6
Replication Group ID: Domain System Volume

Event 5106 when replication is Resumed:

Log Name: DFS Replication

Source: DFSR
Event ID: 5106
Task Category: None
Level: Information
Keywords: Classic
User: N/A
 Description:
The replication mode on the connection to partner <DC Name> has changed.

Additional Information:
Previous Replication Mode: Stop Replication
Current Replication Mode: Obey Configured Schedule
Current Bandwidth Usage: Obey Configured Schedule
Duration, in minutes, for current mode:
Connection ID: 79E6D60D-6044-4775-A9BE-D98DAF557BD6
Replication Group ID: Domain System Volume

Resolution 2
To resolve the issue, in case the import needs to happen more often, add a filter for
DFSR to exclude the temporary directories from replication. These temporary directories
are:

MachineOld
UserOld
MachineStaging
UserStaging
AdmOld

To modify the DFSR filter, edit this object in AD as mentioned as follows:

CN=SYSVOL Share,CN=Content,CN=Domain System Volume,CN=DFSR-

GlobalSettings,CN=System,DC=Contoso,DC=Com

and modify the msdfsr-directoryfilter attribute.

Append the five directories to the end of the already existing exclusions, it should look
like this:

DO_NOT_REMOVE_NtFrs_PreInstall_Directory,NtFrs_PreExisting___See_EventLog,Machine
Old,UserOld,MachineStaging,UserStaging,AdmOld

To make DFSR read the new settings from AD, run dfsrdiag PollAD .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Adprep /gpprep error (The system
cannot find the file specified), or tool
crashes
Article • 12/26/2023

This article provides a solution to errors that occur when you use the Adprep tool
together with the /gpprep argument.

Applies to: Windows Server 2012 R2

Original KB number: 2743345

Symptoms
You use the Adprep tool together with the /gpprep argument in Windows Server 2012
R2. For example, you run the following arguments:

adprep.exe /domainprep /gpprep

When you do this, you receive the following error:

Domain-wide information has already been updated.

[Status/Consequence]
Adprep did not attempt to rerun this operation.

Adprep is about to upgrade the Group Policy Object (GPO) information on the
Infrastructure Master FSMO dc1.corp.contoso.com .

Gpprep operation 3 failed.

[Status/Consequence]
Upgrade of domain Group Policy Objects failed.
[User Action]
Check the log file ADPrep.log and gpprep.log in the
C:\Windows\debug\adprep\logs\20120809082547 directory for possible cause of
failure.

Adprep encountered a Win32 error.

Error code: 0x2 Error message: The system cannot find the file specified.

Group policy upgrade failed.

[Status/Consequence]
 Upgrade of domain Group Policy Objects failed.
[User Action]
Check the log file ADPrep.log in the
C:\Windows\debug\adprep\logs\20120809082547 directory for possible cause of
failure.

Adprep encountered a Win32 error.

Error code: 0x2 Error message: The system cannot find the file specified.

If you use the Adprep.exe that is included with Windows Server 2012 R2, Adprep.exe
crashes, and you receive an error that resembles the following:

Nt5DS has stopped working

Problem signature:
Problem Event Name: APPCRASH
Application Name: adprep.exe
Application Version: 6.1.7601.17514
Application Timestamp: 4ce7a045
Fault Module Name: StackHash_9a46
Fault Module Version: 6.1.7601.17725
Fault Module Timestamp: 4ec4aa8e
Exception Code: c0000374
Exception Offset: 00000000000c40f2
OS Version: 6.1.7601.2.1.0.274.10
Locale ID: 1033
Additional Information 1: 9a46
Additional Information 2: 9a46fc9b92ce31eadc29a5f5673559ea
Additional Information 3: ec6e
Additional Information 4: ec6ee41ac19ad12f608f0599c2c1bb6f

Cause
The infrastructure operations master role holder in this domain implements a disjoint
namespace. Adprep.exe assumes that computer names will match their domain names
because this match is the default behavior in all versions of Windows.

Resolution

７ Note
 All steps require membership in the Domain Admins group. Also, run commands at
an elevated command prompt.

1. Locate the infrastructure master role holder in the domain. To do this, run the
command: netdom.exe query fsmo .

2. Disable incoming and outgoing (also known as inbound and outbound) replication
on server with the Infrastructure Master role. To do this, run the following
command:

Console

repadmin.exe /options <infrastructure_master_name>

+DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL

3. Log on to server with the Infrastructure Master role, and modify its Domain Name
System (DNS) suffix. To do this, follow these steps:
a. Start SYSDM.CPL, select OK, select Change, and then select More
b. Set the suffix in the Primary DNS suffix of this computer box to match the
Active Directory Domain Services (AD DS) domain name instead of the current
disjointed name.

4. Restart and log on to server with the Infrastructure Master role, and then run the
command: adprep.exe /domainprep /gpprep .

5. Use SYSDM.CPL, and then follow the steps in step 3, except this time in step 3B,
you must set the suffix in the Primary DNS suffix of this computer box to match
the original disjoint name on server with the Infrastructure Master role.

6. Restart and then log on to server with the Infrastructure Master role, and enable
inbound and outbound replication. To do this, use the following command:

Console

repadmin.exe /options <infrastructure_master_name> -

DISABLE_OUTBOUND_REPL -DISABLE_INBOUND_REPL

More information
Gpprep adds cross-domain planning functionality for Group Policy and Resultant Set of
Policy (RSOP) Planning Mode. Adding this functionality requires updating the file system
in SYSVOL and AD DS permissions for existing group policies. The environment may
already contain custom or delegated permissions that were manually implemented by
administrators. In this case, gpprep triggers replication of all Group Policy files in
SYSVOL and may deny RSOP functionality to delegated users until their permissions are
recreated by administrators. So Administrators should run gpprep only one time in the
history of a domain. Gpprep shouldn't be run with every upgrade.

Notes

Gpprep was introduced in Windows Server 2003.

Disjoint namespaces aren't a Microsoft best practice.

For more information about Disjoint Namespace support and limitations in AD DS, go to
the following Microsoft TechNet website:
https://technet.microsoft.com/library/cc731125(v=WS.10).aspx

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot SCECLI 1202 events
Article • 12/26/2023

This article describes ways to troubleshoot and to resolve SCECLI 1202 events.

Applies to: Windows Server 2012 R2

Original KB number: 324383

Summary
The first step in troubleshooting these events is to identify the Win32 error code. This
error code distinguishes the type of failure that causes the SCECLI 1202 event. Below is
an example of a SCECLI 1202 event. The error code is shown in the Description field. In
this example, the error code is 0x534. The text after the error code is the error
description. After you determine the error code, find that error code section in this
article, and then follow the troubleshooting steps in that section.

0x534: No mapping between account names and security IDs was done.

or

0x6fc: The trust relationship between the primary domain and the trusted domain
failed.

Error code 0x534: No mapping between

account names and security IDs was done
These error codes mean that there was a failure to resolve a security account to a
security identifier (SID). The error typically occurs either because an account name was
mistyped, or because the account was deleted after it was added to the security policy
setting. It typically occurs in the User Rights section or the Restricted Groups section of
the security policy setting. It may also occur if the account exists across a trust and then
the trust relationship is broken.

To troubleshoot this issue, follow these steps:

1. Determine the account that is causing the failure. To do so, enable debug logging
for the Security Configuration client-side extension:

a. Start Registry Editor.

 b. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows

NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F7
9F83A}

c. On the Edit menu, select Add Value, and then add the following registry value:

Value name: ExtensionDebugLevel

Data type: DWORD
Value data: 2

d. Exit Registry Editor.

2. Refresh the policy settings to reproduce the failure. To refresh the policy settings,
type the following command at the command prompt, and then press ENTER:

Console

secedit /refreshpolicy machine_policy /enforce

This command creates a file that is named Winlogon.log in the

%SYSTEMROOT%\Security\Logs folder.

3. Find the problem account. To do so, type the following command at the command
prompt, and then press ENTER:

Console

find /i "cannot find" %SYSTEMROOT%\security\logs\winlogon.log

The Find output identifies the problem account names, for example, Cannot find
MichaelPeltier. In this example, the user account MichaelPeltier doesn't exist in the
domain. Or it has a different spelling, such as MichellePeltier.

Determine why this account can't be resolved. For example, look for typographical
errors, a deleted account, the wrong policy that applies to this computer, or a trust
problem.

4. If you determine that the account must be removed from the policy, find the
problem policy and the problem setting. To determine which setting contains the
unresolved account, type the following command at the command prompt on the
computer that's producing the SCECLI 1202 event, and then press ENTER:
 Console

c:\>find /i "account name"

%SYSTEMROOT%\security\templates\policies\gpt*.*

For this example, the syntax and the results are:

Console

c:\>find /i "MichaelPeltier"
%SYSTEMROOT%\security\templates\policies\gpt*.*
---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00000.DOM

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00001.INF

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00002.INF
SeInteractiveLogonRight = TsInternetUser,*S-1-5-32-549,*S-1-5-32-
550,MichaelPeltier,*S-1-5-32-551,*S-1-5-32-544,*S-1-5-32-548

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00003.DOM

It identifies GPT00002.inf as the cached security template from the problem Group
Policy object (GPO) that contains the problem setting. It also identifies the problem
setting as SeInteractiveLogonRight. The display name for SeInteractiveLogonRight
is Logon locally.

For a map of the constants (for example, SeInteractiveLogonRight) to their display

names (for example, Logon locally), see the Microsoft Windows 2000 Server
Resource Kit, Distributed Systems Guide. The map is in the User Rights section of
the Appendix.

5. Determine which GPO contains the problem setting. Search the cached security
template that you identified in step 4 for the text GPOPath= . In this example, you
would see:

GPOPath={6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE

{6AC1786C-016F-11D2-945F-00C04FB984F9} is the GUID of the GPO.

6. To find the friendly name of the GPO, use the Resource Kit utility Gpotool.exe. Type
the following command at the command prompt, and then press ENTER:

Console

gpotool /verbose
 Search the output for the GUID that you identified in step 5. The four lines that
follow the GUID contain the friendly name of the policy. For example:

Output

Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Policy OK
Details:
------------------------------------------------------------
DC: domcntlr1.wingtiptoys.com
Friendly name: Default Domain Controllers Policy

Now you've identified the problem account, the problem setting, and the problem GPO.
To resolve the problem, remove or replace the problem entry.

Error code 0x2: The system cannot find the file

specified
This error is similar to 0x534 and to 0x6fc. It's caused by an irresolvable account name.
When the 0x2 error occurs, it typically indicates that the irresolvable account name is
specified in a Restricted Groups policy setting.

To troubleshoot this issue, follow these steps:

1. Determine which service or which object is having the failure. To do so, enable
debug logging for the Security Configuration client-side extension:

a. Start Registry Editor.

b. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F7

9F83A}

c. On the Edit menu, select Add Value, and then add the following registry value:

Value name: ExtensionDebugLevel

Data type: DWORD
Value data: 2

d. Exit Registry Editor.

2. Refresh the policy settings to reproduce the failure. To refresh the policy settings,
type the following command at the command prompt, and then press ENTER:
 Console

secedit /refreshpolicy machine_policy /enforce

This command creates a file that's named Winlogon.log in the

%SYSTEMROOT%\Security\Logs folder.

3. At the command prompt, type the following command, and then press ENTER:

Console

find /i "cannot find" %SYSTEMROOT%\security\logs\winlogon.log

The Find output identifies the problem account names, for example, Cannot find
MichaelPeltier. In this example, the user account MichaelPeltier doesn't exist in the
domain. Or it has a different spelling--for example, MichellePeltier.

Determine why this account can't be resolved. For example, look for typographical
errors, a deleted account, the wrong policy applying to this computer, or a trust
problem.

4. If you determine that the account has to be removed from the policy, find the
problem policy and the problem setting. To find what setting contains the
unresolved account, type the following command at the command prompt on the
computer that's producing the SCECLI 1202 event, and then press ENTER:

Console

c:\>find /i "account name"

%SYSTEMROOT%\security\templates\policies\gpt*.*

For this example, the syntax and the results are:

Console

c:\>find /i "MichaelPeltier"
%SYSTEMROOT%\security\templates\policies\gpt*.*
---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00000.DOM

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00001.INF

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00002.INF
SeInteractiveLogonRight = TsInternetUser,*S-1-5-32-549,*S-1-5-32-
550,JohnDough,*S-1-5-32-551,*S-1-5-32-544,*S-1-5-32-548
 ---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00003.DOM

It identifies GPT00002.inf as the cached security template from the problem GPO
that contains the problem setting. It also identifies the problem setting as
SeInteractiveLogonRight. The display name for SeInteractiveLogonRight is Logon
locally.

For a map of the constants (for example, SeInteractiveLogonRight) to their display

names (for example, Logon locally), see the Windows 2000 Server Resource Kit,
Distributed Systems Guide. The map is in the User Rights section of the Appendix.

5. Determine which GPO contains the problem setting. Search the cached security
template that you identified in step 4 for the text GPOPath= . In this example, you
would see:

GPOPath={6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE

{6AC1786C-016F-11D2-945F-00C04FB984F9} is the GUID of the GPO.

6. To find the friendly name of the GPO, use the Resource Kit utility Gpotool.exe. Type
the following command at the command prompt, and then press ENTER:

Console

gpotool /verbose

Search the output for the GUID you identified in step 5. The four lines that follow
the GUID contain the friendly name of the policy. For example:

Output

Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Policy OK
Details:
------------------------------------------------------------
DC: domcntlr1.wingtiptoys.com
Friendly name: Default Domain Controllers Policy

You have now identified the problem account, the problem setting, and the problem
GPO. To resolve the problem, search the Restricted Groups section of the security policy
for instances of the problem account (in this example, MichaelPeltier), and then remove
or replace the problem entry.
Error code 0x5: Access denied
This error typically occurs when the system hasn't been granted the correct permissions
to update the access control list of a service. It may occur if the Administrator defines
permissions for a service in a policy but doesn't grant the System account Full Control
permissions.

To troubleshoot this issue, follow these steps:

1. Determine which service or which object is having the failure. To do so, enable
debug logging for the Security Configuration client-side extension:

a. Start Registry Editor.

b. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F7

9F83A}

c. On the Edit menu, select Add Value, and then add the following registry value:

Value name: ExtensionDebugLevel

Data type: DWORD
Value data: 2

d. Exit Registry Editor.

2. Refresh the policy settings to reproduce the failure. To refresh the policy settings,
type the following command at the command prompt, and then press ENTER:

Console

secedit /refreshpolicy machine_policy /enforce

This command creates a file that is named Winlogon.log in the

%SYSTEMROOT%\Security\Logs folder.

3. At the command prompt, type the following, and then press ENTER:

Console

find /i "error opening" %SYSTEMROOT%\security\logs\winlogon.log

 The Find output identifies the service with the misconfigured permissions, for
example, Error opening Dnscache. Dnscache is the short name for the DNS Client
service.

4. Find out which policy or which policies are trying to modify the service
permissions. To do so, type the following command at the command prompt, and
then press ENTER:

Console

find /i "service" %SYSTEMROOT%\security\templates\policies\gpt*.*".

Below is a sample command and its output:

Console

d:\>find /i "dnscache" %windir%\security\templates\policies\gpt*.*

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00000.DOM

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00001.INF

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00002.INF
Dnscache,3,"D:AR(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;LA)"

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00003.DOM

5. Determine which GPO contains the problem setting. Search the cached security
template that you identified in step 4 for the text GPOPath= . In this example, you
would see:

GPOPath={6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE

{6AC1786C-016F-11D2-945F-00C04FB984F9} is the GUID of the GPO.

6. To find the friendly name of the GPO, use the Resource Kit utility Gpotool.exe. Type
the following command at the command prompt, and then press ENTER:

Console

gpotool /verbose

Search the output for the GUID that you identified in step 5. The four lines that
follow the GUID contain the friendly name of the policy. For example:

Output
 Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Policy OK
Details:
------------------------------------------------------------
DC: domcntlr1.wingtiptoys.com
Friendly name: Default Domain Controllers Policy

Now you have identified the service with the misconfigured permissions and the
problem GPO. To resolve the problem, search the System Services section of the security
policy for instances of the service with the misconfigured permissions. And then take
corrective action to grant the System account Full Control permissions to the service.

Error code 0x4b8: An extended error has

occurred
The 0x4b8 error is generic and can be caused by many different problems. To
troubleshoot these errors, follow these steps:

1. Enable debug logging for the Security Configuration client-side extension:

a. Start Registry Editor.

b. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows

NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F7
9F83A}

c. On the Edit menu, select Add Value, and then add the following registry value:

Value name: ExtensionDebugLevel

Data type: DWORD
Value data: 2

d. Exit Registry Editor.

2. Refresh the policy settings to reproduce the failure. To refresh the policy settings,
type the following command at the command prompt, and then press ENTER:

Console

secedit /refreshpolicy machine_policy /enforce

 This command creates a file that is named Winlogon.log in the
%SYSTEMROOT%\Security\Logs folder.

3. See ESENT event IDs 1000, 1202, 412, and 454 are logged repeatedly in the
Application log . This article describes known issues that cause the 0x4b8 error.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use GPOs to change default logon
domain name in the logon screen
Article • 12/26/2023

This article describes how to use Group Policy Objects (GPOs) to change default logon
domain name.

Applies to: Windows 10 - all editions

Original KB number: 2908796

Symptoms
In multi domain environment, there are scenarios where users consistently login to
workstations that are joined to a different domain than that of the logged in user. By
default the domain that the workstation is joined to is listed as the default domain name
and other domain users have to always provide the user name as domain\username to
login correctly. Also there are scenarios where the machine is domain joined but the
logins are almost always happening with local user accounts (using .\username).

Cause
Its a common mistake that users make to skip the domain name and unknowingly
attempt to login to a different domain than theirs and result in failures. To avoid these
problems and improve user experience, you may decide to choose a default logon
domain name that is different from workstation domain name.

Resolution
The following group policy setting is available in Windows Vista or later operating
systems:

Assign a default domain for logon

To enable default domain for logon, follow these steps:

1. Click Start, and then click Run.

2. In the Open box, type gpedit.msc, and then click OK.
3. Under Computer Configuration, expand Administrative Settings, expand System,
and then click Logon.
 4. In the right pane, double click the setting Assign a default domain for logon and
choose Enabled.
5. Under Options, you may provide the name of the domain you want to be set as
default

７ Note

Use Group Policy Management console(GPMC.msc) to create a GPO and configure

the settings at domain or OU level.

The Assign a default domain for logon group policy specifies a default logon domain
that may be different domain than the machine joined domain. You can enable this
policy setting and add the preferred domain name so that the default logon domain
name will be set to the specified domain that may not be the machine joined domain. If
you enable this policy and set the domain name as a period (.), once the policy is
applied to the machine, users will see a period (.) as their default domain and unless
users specify a domainname\username to login, all users will be treated as local users.
(.\username)

７ Note

Requirements: This policy is applicable to Windows Vista or later.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Resultant Set of Policy logging to
gather computer policy information
Article • 12/26/2023

This article describes how to use the Resultant Set of Policy utility (Rsop.msc) to gather
only computer-specific policy information.

Applies to: Windows Server 2012 R2

Original KB number: 312321

Use Rsop.msc
When using the Resultant Set of Policy utility, you can gather only computer-specific
policy information:

1. Click Start, click Run, type mmc in the Open box, and then click OK.
2. Click File, click Add/Remove Snapin, and then click Add in the Add/Remove
dialog box.
3. Click Resultant Set of Policy, click Add, and then click Close in the Add/Remove
Standalone Snapin dialog box.
4. Click OK in the Add/Remove dialog box. The Resultant Set of Policy snapin is
displayed in the MMC.
5. Click Generate RSOP data on the Action menu.
6. Click Next, click Logging Mode, and then click Next.
7. Click either This Computer or Another Computer, and then type the computer
name.
8. Click Select a specific user, and then click the blank space that is below the listed
users. This has the same effect as clicking Do not display user policy settings in
the results.
9. Click Next, and then click Next. Only computer-specific settings are displayed.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

WinStoreUI.admx conflict when Central
Store is updated with Windows 10
Version 1511 ADMX files
Article • 12/26/2023

This article provides help to solve a WinStoreUI.admx conflict that occurs when Central
Store is updated by using Windows 10 Version 1511 ADMX files.

Applies to: Windows Server 2012 R2

Original KB number: 3190327

Symptoms
The WinStoreUI.admx file is available in Windows Server 2012 R2 but is not included in
the initial release of Windows 10. However, after you update the Central Store by using
the .admx files from Windows 10 Version 1511, the following error is displayed as soon
as you start editing a Group Policy object (GPO):

Namespace 'Microsoft.Policies.WindowsStore' is already defined as the target

namespace for another file in the store.

Comparing the .admx files of Windows Server 2012 R2 and Windows 10 Version 1511
shows that WindowsStore.admx contains the same information as WinStoreUI.admx,
plus a few additional policy settings. After you delete WinStoreUI.admx, this error no
longer occurs. However, the Resultant Set of Policies on a 2012 R2-based computer
contains the following error:
An error has occurred while collecting data for Administrative Templates. The following
errors were encountered

An appropriate resource file could not be found for \\<domain>\sysvol\

<domain.dns>policies\PolicyDefinitions\WinStoreUI.admx(error = 2): The system
cannot find the file specified.

Cause
In Windows 10 Version 1507, the Store .admx file was removed. A fix restored the .admx
file. However, this file now has a new name. After Version 1511 is installed, when
customers update their Central Store, they now have two .admx files that have identical
settings. Because this is not allowed, the error that's described in the "Symptoms"
section occurs.

The .admx files are the following:

Original Store Group Policy file name: winstoreui.admx

New Store Group Policy file name: windowsstore.admx

Resolution
This problem is fixed in Windows 10 Version 1511 and by the most recent cumulative
update. Affected customers should upgrade to that release if possible. To prevent the
error from occurring when you open Gpedit.msc and when you run Gpresult.exe, follow
these steps:

1. Verify that you have both winstoreui.admx and windowsstore.admx in the Central
Store.
2. Delete the winstoreui.admx and winstoreui.adml files from the Central Store.
3. Verify that both opening Gpedit.msc and running Gpresults.exe work without error.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Wrong error message for missing .adml
files
Article • 12/26/2023

This article provides a solution to an issue where wrong error messages are returned
when .adml files are missing.

Applies to: Windows Server 2012 R2

Original KB number: 2688272

Symptoms
SR symptoms:

EN-US Domain Controller tries to create a settings report for a GPO. The report is
created with the message:

An appropriate resource file could not be found for file

\\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx

(error = 2): The system cannot find the file specified.

The .admx Files reported as missing are present in the specified folder.

Repro symptoms:

Renaming the folder that contains the appropriate .adml files returns the error:

An appropriate resource file could not be found for file

\\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx

(error = 3): The system cannot find the path specified.

This error also happens when the EN-US folder does not exist and is missing.

Editing the affected GPOs becomes impossible, reports are inaccurate. The problem
does not happen in the same way when other language files and folders are missing as
EN-US is the fallback language and it will be loaded instead when another language is
missing.

Cause
In order to generate reports or edit the GPO, the .admx file needs to be loaded as well
as the appropriate .adml language file. Depending on the native language user
requesting the edit / reporting operation the .adml file is searched for in the appropriate
language folder (en for en, de for de, an so on). If, for example, the querying user wants
english and the GPO central store only has the german .adml files installed such an error
would occur.

The error reporting is incorrect since it is referring to the .admx file as missing, while this
file is present at the specified location.

Resolution
Making the .adml files available for the language queried for in the correct folder solves
the problem. See How to create the Central Store for Group Policy Administrative
Template files in Windows Vista .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy Preferences removes
manual drive mappings if the use first
available setting is enabled
Article • 12/26/2023

This article provides a solution to an issue where manual drive mappings are removed
after drive maps are deployed through Group Policy Preferences.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 3091116

Symptoms
After drive maps are deployed through Group Policy Preferences (GPP), users observe
that previously mapped drives are no longer available after a new logon. Additionally,
only a subset of mapped drives that are configured through GPP are present if more
than one policy is configured through drive map items.

Cause
Within a drive map item, there's a Drive Letter option to enable the Use first available,
starting at setting. This setting (denoted as the useLetter element in the drive map
XML) is defined as follows at Element-Specific Attributes:

useLetter - If 1, then letter refers to a single drive letter on which the action should
operate. If 0, then letter is the alphabetic beginning of a range of drive letters to which
the action may apply. When the preference item is configured with Use first available,
starting at: (or useLetter=0 in the XML), the Preference client-side extension will clear all
mapped drives starting with that drive latter through the letter Z. If multiple GPP policies
are being applied, the order of how the drive maps are processed may lead to
seemingly random removal of GPP-mapped drives.

Resolution
By design, drive maps are cleared when the Use first available, starting at setting is
enabled.
If the Use first available, starting at setting is required, make sure that the following
conditions are met:

Manually mapped drives are configured to use drive letters from earlier in the
alphabet than those that are configured by GPP drive maps.
Only a single GPP drive map policy is applied to the user.

You can also assign specific drive letters to each drive map and not use the Use first
available, starting at option on any drive map. Then, any number of GPP drive map
policies may be applied to the user without the loss of manually mapped drives or of
GPP drive maps that are configured in multiple policies that apply to the user.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Allow active content to run files on My
Computer" Group Policy setting does
not work as expected
Article • 12/26/2023

This article provides help to solve an issue where the Allow active content to run files
on My Computer Group Policy setting doesn't work.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2002093

Symptoms
If you use Windows or the Remote Server Administration Tools (RSAT) for Windows to
enable he Group Policy Preference setting Allow active content to run files on My
Computer remain disabled when the policy is applied on the client computers. If you
disable the policy setting, you will find that it gets enabled on the client computers after
the next Group Policy refresh.

The Allow active content to run files on My Computer is configured in the Group Policy
Management Editor by navigating to User Configuration\Preferences\Control Panel
Settings\Internet Settings and selecting New, then Internet Explorer 7. On the
Advanced tab, scroll down to the Security section to view the Allow active content to
run files on My Computer setting.

Cause
To enable Allow active content to run files on My Computer, the following registry
value must be set to 0:

HKEY_CURRENT_USER\Software\Microsoft\Internet

Explorer\Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN

Value Name: iexplore.exe

Value Type: REG_DWORD
Value Data: 0

When you configure this setting, the value will be written as

"iexplore.exe"=dword:00000001 and therefore the setting will be disabled.
The wrong value is written from the Group Policy Preferences XML setting file:

XML

<Reg id="LocalMachineFilesUnlock" type="REG_DWORD" hive="HKEY_CURRENT_USER"

key="SOFTWARE\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN"
name="iexplore.exe" value="00000001"/>

The default location of the Group Policy Preferences XML setting file is:

%windir%\SYSVOL\sysvol\domain\Policies\{GUID}\
<user/computer>\Preferences\InternetSettings\InternetSettings.xml

Resolution
As a workaround you can disable the Allow active content to run files on My Computer
policy setting and the setting will be enabled when the policy is applied to the client
computers.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Group Policy to control
access to web sites
Article • 12/26/2023

This article helps you to use Windows Group Policy to control access to web sites.

Applies to: Windows Server 2003

Original KB number: 556044

Tips

７ Note

Using the instructions bellow don't provide a full management solutions.

For large company/company with special security requirements, consider to use
central management solution, like Microsoft ISA Server.

1. Create new GPO (Group Policy Object).

2. Under the new GPO, navigate to: User Configuration\Windows Settings\Internet

Explorer Maintenance\Connection\Connection.

3. Double-click on Proxy Settings.

4. Mark the checkbox Enable proxy settings.

5. Under Address of proxy, write the host name of the local proxy (In case that you
don't have a proxy server, write a 0.0.0.0 as the Server IP).

6. Under Exceptions, write the web site that you allow access to (To use multiple web
site names, add ; between each web site name.

7. Press on Ok button, and close the MMC.

8. Apply the new GPO to the required OU/Domain.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy Printer Preferences fails to
set the default printer when new user
profile is created
Article • 12/26/2023

This article provides a workaround for an issue where Group Policy Printer Preferences
fails to set the default printer.

Applies to: Windows Server 2012 R2

Original KB number: 2787598

Symptoms
Using Group Policy Preferences to create a new printer mapping and set that printer as
the default printer fails on Windows Vista and higher clients when the user is logging on
for the first time. The printer mapping is successfully created, but is not set as the
default printer in the registry. A printer preferences trace shows the following error:

<VALUE>The printer name is invalid.</VALUE></PROPERTY>-</INSTANCE>

Event ID 4098 is logged in the Application Log:
Log Name: Application
Source: Group Policy Printers
Date: <DateTime>
Event ID: 4098
Task Category: (2)
Level: Warning
Keywords: Classic
User: SYSTEM
Computer: server.fabrikam.com
Description:
The user 'HP Printer' preference item in the 'Define Printers {XXX-XXXX-XXXX-XXXX-
XXXXXXXXXXXX}' Group Policy object did not apply because it failed with error code
'0x80070709 The printer name is invalid.' This error was suppressed.

Cause
Group Policy Preferences creates the network printer mapping and calls the
SetDefaultPrinterW() API before the user logon completes. At this point, the network
connection under Software\Microsoft\Windows NT\CurrentVersion\Devices is not
created yet. So when it calls the SetDefaultPrinterW() API, it fails with the error code
0x80070709 "The printer name is invalid."

The printer connection registry values will only be created by the Spooler Service when
it receives the SERVICE_CONTROL_SESSIONCHANGE notification. This notification
message will only be sent AFTER the user logon completes. So when Group Policy
Preferences calls SetDefaultPrinterW() the first time, the default printer will not be set.

Resolution
There is currently no hotfix available for this issue. Possible work-arounds include:

1. Force a group policy update after logon using the GPUPDATE /FORCE command
2. Restart the Print Spooler (spooler) service after user logon
3. Use a Scheduled Task to run a script after logon to define the default printer
4. Use Registry Preferences to configure the default printer

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
User Experience issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Group Policy to disable USB, CD-
ROM, Floppy Disk, and LS-120 drivers
Article • 12/26/2023

This article describes an ADM template that allows an Administrator to disable the
respective drivers of these devices.

Applies to: Windows Server 2003

Original KB number: 555324

Symptoms
By default, Group Policy doesn't offer a facility to easily disable drives containing
removable media, such as USB ports, CD-ROM drives, Floppy Disk drives, and high
capacity LS-120 floppy drives. But Group Policy can be extended to use customized
settings by applying an ADM template. The ADM template in this article allows an
Administrator to disable the respective drivers of these devices, ensuring that they can't
be used.

Resolution
Import this administrative template into Group Policy as an .adm file. See the link in the
"More information" section if you're unsure how to do this.

CLASS MACHINE
CATEGORY !!category
CATEGORY !!categoryname
POLICY !!policynameusb
KEYNAME "SYSTEM\CurrentControlSet\Services\USBSTOR"
EXPLAIN !!explaintextusb
PART !!labeltextusb DROPDOWNLIST REQUIRED

VALUENAME "Start"
ITEMLIST
NAME !!Disabled VALUE NUMERIC 3 DEFAULT
NAME !!Enabled VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
POLICY !!policynamecd
KEYNAME "SYSTEM\CurrentControlSet\Services\Cdrom"
EXPLAIN !!explaintextcd
PART !!labeltextcd DROPDOWNLIST REQUIRED

VALUENAME "Start"
ITEMLIST
NAME !!Disabled VALUE NUMERIC 1 DEFAULT
NAME !!Enabled VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
POLICY !!policynameflpy
KEYNAME "SYSTEM\CurrentControlSet\Services\Flpydisk"
EXPLAIN !!explaintextflpy
PART !!labeltextflpy DROPDOWNLIST REQUIRED

VALUENAME "Start"
ITEMLIST
NAME !!Disabled VALUE NUMERIC 3 DEFAULT
NAME !!Enabled VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
POLICY !!policynamels120
KEYNAME "SYSTEM\CurrentControlSet\Services\Sfloppy"
EXPLAIN !!explaintextls120
PART !!labeltextls120 DROPDOWNLIST REQUIRED

VALUENAME "Start"
ITEMLIST
NAME !!Disabled VALUE NUMERIC 3 DEFAULT
NAME !!Enabled VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
END CATEGORY
END CATEGORY

[strings]
category="Custom Policy Settings"
categoryname="Restrict Drives"
 policynameusb="Disable USB"
policynamecd="Disable CD-ROM"
policynameflpy="Disable Floppy"
policynamels120="Disable High Capacity Floppy"
explaintextusb="Disables the computers USB ports by disabling the usbstor.sys
driver"
explaintextcd="Disables the computers CD-ROM Drive by disabling the cdrom.sys
driver"
explaintextflpy="Disables the computers Floppy Drive by disabling the flpydisk.sys
driver"
explaintextls120="Disables the computers High Capacity Floppy Drive by disabling
the sfloppy.sys driver"
labeltextusb="Disable USB Ports"
labeltextcd="Disable CD-ROM Drive"
labeltextflpy="Disable Floppy Drive"
labeltextls120="Disable High Capacity Floppy Drive"
Enabled="Enabled"
Disabled="Disabled"

More information
For more information about applying Administrative Template files, including
instructions on how to use the above template, download the Microsoft White Paper
'Using Administrative Template Files with Registry-Based Group Policy' from here.

This template is considered a preference rather than a true policy and will tattoo the
registry of client computers with its settings. If this template is moved out of scope of
the Group Policy that applies it, the registry changes that it makes will remain. If you
wish to reverse the settings made by this template, reverse the options to re-enable the
drivers.

Preference settings are hidden by default in the Group Policy template editor. When
applying this template, follow these instructions to change the view settings that allow
preferences to be viewed.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A Group Policy setting isn't available in
the security policy settings list
Article • 12/26/2023

This article describes a problem in which the "System objects: Default owner for objects
created by members of the Administrators group" Group Policy setting isn't available in
the security policy settings list.

Applies to: Windows Server 2012 R2

Original KB number: 947721

Symptoms
When you try to access the "System objects: Default owner for objects created by
members of the Administrators group" Group Policy setting on a computer that is
running Windows Vista or newer, this setting isn't available in the security policy settings
list.

When the setting is present in your security group policy, it will be ignored by Windows
Vista and newer domain members.

Cause
Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 don't
support this setting any longer. When enabled, User Account Control (UAC) will ensure
the user account is being used as owner for all objects created locally. For remote
access, the administrators' group will be used there's no restricted token for network
sessions.

Since the support for the setting was removed, the system security policy "System
objects: Default owner for objects created by members of the Administrators group"
setting isn't available in the Security Templates user interface anymore.

Resolution
You can add the "System objects: Default owner for objects created by members of the
Administrators group" Group Policy setting to the Security Templates user interface.
Hint: This procedure will NOT make Windows Vista and newer honor the setting as
Windows XP and Windows Server 2003 do.

To be able to create this Group Policy setting for some computers that are running
Windows XP or Windows Server 2003, follow these steps on a computer that is running
Windows Server 2008:

1. Log on to as a local administrator to configure the Group Policy setting.

2. Make a backup copy of the c:\windows\inf\Sceregvl.inf file.

3. Take ownership of this file and give the Administrators group full access user
rights. To do this, follow these steps:

７ Note

This file is owned by the TrustedInstaller group. Therefore, the Administrators

have only read-only access user rights.

a. Right-click the c:\windows\inf\Sceregvl.inf file, and then click Properties.

b. Click the Security tab.
c. Click Advanced.
d. Click the Owner tab.
e. Click Edit.
f. Under Change Owner to, click the Administrators group, and then click OK.
g. Click OK three times.

4. To give the Administrators group full access user rights to the file, follow these
steps.

７ Note

After you give the Administrators group full access user rights, you can edit
and save changes to the file.

a. Right-click the c:\windows\inf\Sceregvl.inf file, and then click Properties.

b. Click the Security tab.
c. Click Edit.
d. Under Group or User names, click the Administrators group.
e. Under Permissions for Administrators, click to select the Allow check box for
Full control, and then click OK.
f. Click OK to close the Sceregvl.inf Properties dialog box.

5. Open and edit the c:\windows\inf\Sceregvl.inf file by using Notepad.

 6. Copy the following text that should all be in one line:

MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\nodefaultadminowner,3,"Syste
m objects: Default owner for objects created by members of the Administrators
group",3,0|Administrators group,1|Object Creator

7. Paste the text just after the following line in the file:
(MACHINE\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy,
4,%SCENoAp plyLegacyAuditPolicy%,0)

8. Save the changes to the file, and then exit Notepad.

9. Reset the file ownership and permissions for the c:\windows\inf\Sceregvl.inf file
back to the default settings. To do this, follow these steps:
a. Right-click the c:\windows\inf\Sceregvl.inf file, and then click Properties.
b. Click the Security tab.
c. Click Advanced.
d. Click the Owner tab.
e. Click Edit.
f. Click Other users or groups.
g. Click Locations.
h. Under Locations, click your local computer name, and then click OK.
i. In the Select Users or Group window, type NT SERVICE\TrustedInstaller under
Enter the object name to select, and then click OK.
j. In the Advanced Security Settings for Sceregvl.inf window, click the
TrustedInstaller account under Change Owner to, and then click OK.
k. Click OK three times.

10. Reset the Administrators group access permissions for the

c:\windows\inf\Sceregvl.inf file back to only Read & execute and Read. To do this,
follow these steps:
a. Right-click the c:\windows\inf\Sceregvl.inf file, and then click Properties.
b. Click the Security tab.
c. Click Edit.
d. Under Group or User names, click the Administrators group.
e. Under Permissions for Administrators, click to clear all the check boxes except
the Read & execute check box and the Read check box, and then click OK.
f. Click OK to close the Sceregvl.inf Properties dialog box.

11. Reregister the client-side extension for the Group Policy Scecli.dll file. To do this,
open an elevated command prompt, type the following command, and then press
ENTER:REGSVR32 scecli.dll Click OK.
 12. To apply the "System objects: Default owner for objects created by members of the
Administrators group" Group Policy setting in the Local Security Policy settings,
follow these steps.

７ Note

If the computer is a domain controller, use the "Domain Controller security Policy"
snap-in.

1. Click Start, click Control Panel, click Administrative Tools, and then click Local
Security Policy.
2. Move to the Security Settings\Local Policies\Security Options location.
3. In the right pane of the window, right-click the "System objects: Default owner for
objects created by members of the Administrators group" Group Policy setting,
and then click Properties.
4. In the drop-down box, click Object Creator, and then click OK.
5. You may receive a warning in a Windows Security message box. Read the warning,
and then click Yes.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

AuthZ fails with an Access Denied error
when an application does access checks
in Windows Server
Article • 12/26/2023

This article provides a solution to an issue in which AuthZ fails with an Access Denied
error when an application does access checks in Windows Server.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4055652

Symptoms
Consider the following scenario:

You're working in an Active Directory environment that's based on Windows Server

2008 R2 or a later version.
You run an application that uses the Authorization (AuthZ) interface. Such
applications include Microsoft Exchange 2016 and Microsoft Exchange 2013.

In this scenario, when the application tries to do an access check, AuthZ fails and returns
an Access Denied error message.

Cause
This issue occurs because the Network access: Restrict clients allowed to make remote
calls to SAM policy is enabled. The policy controls which users can enumerate users and
groups in the local Security Accounts Manager (SAM) database and in Active Directory.

This policy is introduced after the following versions of Windows or Windows updates
are installed:

Windows 10 Version 1607 and later versions

Windows 10 Version 1511 with KB 4103198 installed
Windows 10 Version 1507 with KB 4012606 installed
Windows 8.1 with KB 4102219 installed
Windows 7 with KB 4012218 installed
Windows Server 2016 RS1 and later versions
Windows Server 2012 R2 with KB 4012219 installed
 Windows Server 2012 with KB 4012220 installed
Windows Server 2008 R2 with KB 4012218 installed

Policy and registry names

ﾉ Expand table

Name Description

Policy Network access: Restrict clients allowed to make remote calls to SAM
name

Location Computer Configuration\Windows Settings\Security Settings\Local

Policies\Security Options

Registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam
subkey

Registry REG_SZ
type

Registry A string that contains the SDDL of the security descriptor to be deployed.
value
When you define the policy by using the Windows Server 2016 Admin Tools, the default
is to allow only administrators access to this interface.

The error that's mentioned in the "Symptoms" section occurs if the following conditions
are true:

The policy is enabled on the domain controllers.

The account for the server that is running Exchange Server is not allowed to use
the interface.

Resolution
To fix this issue, use one of the following methods.

Method 1: Update the policy to allow access

In the group, the servers that have to access the interface are added as members.

For example, the "Exchange Servers" universal group requires this access.

If the application does not have a group that contain the required accounts, you may
have to create and maintain such a group. This is the recommended solution because it
provides access to a group that's specific to the task.

Method 2: Disable the policy

Clear the RestrictRemoteSAM registry entry or remove the policy.

７ Note

On domain controllers, you can define per-object permissions to control the

visibility of the accounts. These permissions are honored by the remote SAM RPC
calls. You cannot do this for the accounts of members or standalone computers.

More Information
For more information, see the following article:
Network access: Restrict clients allowed to make remote calls to SAM

Issue example in Exchange Server

Consider the following scenario:

You're running Active Directory together with Windows Server 2008 R2 or a later
version.
You're running Microsoft Exchange 2016 or Microsoft Exchange 2013 as an email
collaboration platform.

７ Note

Although this example specifies Exchange Server, this issue applies similarly to
other applications that use AuthZ in this manner.

In this scenario, offline address book (OAB) generation on the server that's running
Exchange Server 2016 fails.

Also, you see an entry for Event 17004 (source: MSExchange Mailbox Assistants
Provider) that resembles the following. This entry is logged in the Application log on the
server on which the "SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}"
arbitration mailbox that's used for generating the OAB is mounted.

Generation of OAB "\Default Offline Address Book" failed.

Dn: CN=Default Offline Address Book,CN=Offline Address Lists,CN=Address Lists
Container,CN=Companyname,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=company,DC=com ObjectGuid:
543b7f18-2750-4969-9afd-e333a0542406
Stats:
S:Exp=Microsoft.Exchange.Security.Authorization.AuthzException:
AuthzInitializeContextFromSid failed for User SID: S-1-5-21-.... --->
System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace ---
at
Microsoft.Exchange.Security.Authorization.ClientSecurityContext.InitializeContextFro
mSecurityAccessToken(AuthzFlags flags)
at
Microsoft.Exchange.Security.Authorization.ClientSecurityContext..ctor(ISecurityAcces
sToken securityAccessToken, AuthzFlags flags)
at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.PropertyManager..ct
or(OfflineAddressBook offlineAddressBook, SecurityIdentifier userSid, String
userDomain, Boolean habEnabled, Boolean ordinalSortedMultivaluedProperties,
Int32 httpHomeMdbFixRate, IOABLogger logger)
 at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.OABGenerator.Initial
ize()
at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssist
ant. BeginProcessingOAB(AssistantTaskContext assistantTaskContext)
at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssist
ant.<>c__DisplayClass12.<SafeExecuteOabTask>b__e()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2
filterDelegate, Action`1 catchDelegate)
at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssist
ant.SafeExecuteOabTask(OABGeneratorTaskContext context)
at
Microsoft.Exchange.MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssist
ant.<>c__DisplayClassc.<ProcessAssistantStep>b__9()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2
filterDelegate, Action`1 catchDelegate)

When the offline address book is generated, Exchange verifies whether the Mailbox-
Assistant is allowed to run the task. The SystemMailbox{bb558c35-97f1-4cb9-8ff7-
d53741dc928c} system mailbox is a disabled user account in the users container of the
forest root domain. Exchange uses the AuthZ engine of Windows for this task.

When you examine the network trace of what the server that's running Exchange Server
is doing, you notice a failed Kerberos S4U request that resembles the following:

KerberosV5 10.10.10.11 16268 10.10.10.10 Kerberos(88) KRB_TGS_REQ, Realm:

AND.CORP, Sname: XXXXX

PADataType PA-FOR-USER (129) 12408 48 Int64

UserRealm AND 296 56 String

UserName SM_0ddc5cc213b943a5b 16 280 KerberosV5.PrincipalName

-> This tells you AuthZ is trying Kerberos S4U.

2017-10-27T16:34:52.1334577 0,0041316 10772 15016 KerberosV5 10.10.10.10

Kerberos(88) 10.10.10.11 16268 KRB_ERROR, KDC_ERR_CLIENT_REVOKED: Clients
credentials have been revoked, status:
STATUS_ACCOUNT_DISABLED
 -> This is excpected as the System Mailbox account is disabled.

AuthZ tries to recover from this failure by querying the

tokenGroupsGlobalAndUniversal attribute of the system mailbox, and then continuing
to enumerate the Domain-Local groups. The LDAP session is encrypted. Therefore, you
can't see the result in a network trace.

The next step is to retrieve the Domain-Local groups. AuthZ uses SAM RPC to retrieve
these group memberships. When the program connects to the domain controller, you
receive a failure notice that resembles the following:

12035 SAMR 10.10.10.11 6457 10.10.10.16 SMB(445)

_SamrConnect5Request{ServerName=\\ Cont-
DC1.company.com ,DesiredAccess=32,InVersion=1,InRevisionInfo=SAMPR_REVISION_I

NFO{V1=SAMPR_REVISION_INFO_V1{Revision=3,SupportedFeatures=0}}}
FileId Persistent = 0x0000002800008761, Volatile = 0x0000002800000005 576 128
SMB2.SMB2Fileid

This fails and returns the following message:

12036 MSRPCE 0 10.10.10.16 SMB(445) 10.10.10.11 6457 RpcconnFaultHdrT, Call:

0x00000002, Context:
0x0001, Status: ERROR_ACCESS_DENIED, Cancels: 0x00
SMB2 0 10.10.10.16 SMB(445) 10.10.10.11 6457 IoctlResponse, Status: Success,
FileName:
samr@# 0x0000002800008761, CtlCode: FSCTL_PIPE_TRANSCEIVE

In the system event log of the domain controller, Event 16969 is logged, as follows:

Log Name: System

Source: Microsoft-Windows-Directory-Services-SAM
Event ID: 16969
Level: Warning
Description:
8 remote calls to the SAM database have been denied in the past 900 seconds
throttling window.
For more information please see https://go.microsoft.com/fwlink/?LinkId=787651.

If you have the throttling disabled, you will see one 16965 event for each access denial
incident together with the client information.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unable to create DSN using Group
Policy Preferences, unspecified error
0x80004005
Article • 12/26/2023

This article provides help to fix the error 0x80004005 that occurs when you configure a
Data Source Name (DSN) using Group Policy Preferences (GPP).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2001454

Symptoms
Attempts to configure a DSN using GPP may result in error events similar to the
following:

Event ID: 4098

Source: Group Policy DataSources
Description: The computer <Preference Name> preference item in the <GPO
Name>. Group Policy object did not apply because it failed with error code
0x80004005 unspecified error. This error was suppressed.

If client-side debug logging is enabled, the following error messages may be recorded
in the debug log:

<DateTime> [pid=0x70,tid=0x91c] Invalid keyword-value pairs [ hr = 0x80004005

"Unspecified error" ]
<DateTime> [pid=0x70,tid=0x91c] createDsn [ hr = 0x80004005 "Unspecified error"
]
<DateTime> [pid=0x70,tid=0x91c] Properties handled. [ hr = 0x80004005
"Unspecified error" ]

To enable GPP debug logging, enable the relevant policy setting below:

Windows Server 2008

Computer Configuration\Policies\Administrative Templates\System\Group

Policy\Logging and Tracing\Data Source Policy processing
Windows Server 2008 R2, Windows 7

Computer Configuration\Policies\Administrative Templates\System\Group

Policy\Logging and Tracing\Configure Data Sources preference logging and tracing

In the Event Logging section, select Informational, Warnings, and Errors. Tracing
should be set to On.

The default locations for the log file are listed below. Both the location and name of the
log file are configurable.

Windows Server 2003, Windows XP

%SystemDrive%\Documents and Settings\All Users\Application

Data\GroupPolicy\Preference\Trace\Computer.log

Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista

%SystemDrive%\ProgramData\GroupPolicy\Preference\Trace\Computer.log

Cause
The error condition occurs if you attempt to configure username and password for the
DSN policy using GPP. Username and password are not valid keywords when
configuring a SQL Server DSN. For more information about the valid SQL Server-specific
keyword/value pairs for data source configuration attribute strings, visit this Microsoft
Web site .

Resolution
When configuring SQL connections, the only way to make the connection transparent
for the user is to set Trusted_Connection to Yes. Otherwise, the user will be prompted
for credentials when trying to connect. You must also ensure that attributes not listed in
the above MSDN link, including username and password, are left blank (not configured)
within the policy when configuring SQL connections.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 1053 is logged when you use
the Gpupdate /force command, or you
restart a domain controller
Article • 12/26/2023

This article provides a resolution for the issue that Event ID 1053 is logged when you use
the Gpupdate /force command, or you restart a domain controller.

Applies to: Windows Server 2003

Original KB number: 937535

Symptoms
When you use the Gpupdate /force command on a Microsoft Windows Server 2003-
based domain controller, or you restart a Windows Server 2003-based domain
controller, the following error message may be logged in the Application log:

Event Type: Error

Event Source: Userenv
Event Category: None
Event ID: 1053
Date: Date
Time: Time
User: NT AUTHORITY\SYSTEM
Computer: Computername
Description:
Windows cannot determine the user or computer name. (Not enough storage is
available to complete this operation. ). Group Policy processing aborted. For more
information, see Help and Support Center .

Additionally, if you enable USERENV logging, the following entries may be logged in the
Userenv.log file:

USERENV(1b4.eb4) <DateTime> MyGetUserName: GetUserNameEx failed with 14.

USERENV(1b4.eb4) <DateTime> MyGetUserName: Retrying call to GetUserNameEx
in 1/2 second.
Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base: 322756 How to back up and restore the registry in Windows

To resolve this problem, add the MaxTokenSize registry entry and the MaxUserPort
registry entry on the affected domain controllers. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then right-click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

７ Note

If the Parameters key is not available, you must create it. To create the
Parameters key, follow these steps:
a. Click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos

b. On the Edit menu, click New, and then click Key.

c. Type Parameters, and then press ENTER.

3. Click the Parameters key, click New on the Edit Menu, and then click DWORD
Value.

4. Type MaxTokenSize, and then press ENTER.

5. Right-click MaxTokenSize, and then click Modify.

6. In the Value data box, type 65535, click Decimal, and then click OK.

7. Locate and then right-click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
 8. On the Edit menu, click New, click DWORD Value, type MaxUserPort, and then
press ENTER.

9. In the Value data box, type a value between 5000 and 65534, click Decimal, and
then click OK.

７ Note

The default value for the MaxUserPort registry entry is 5000.

10. Exit Registry Editor.

11. Restart the computer.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Events 1101 and 1030 are logged in the
Application log when applying Group
Policy
Article • 12/26/2023

This article provides a resolution for the issue that Events 1101 and 1030 are logged in
the Application log when applying Group Policy.

Applies to: Windows Server 2012 R2, Windows 10 - all editions, Windows 7 Service Pack
1
Original KB number: 909260

Symptoms
On a computer that is running Microsoft Windows XP or newer you may experience the
following Error event entries in the Application log: If you enable user environment or
GPSVC debug logging, the following entries are logged:

ProcessGPOs: User name is: UserOrComputerDN , Domain name is: DomainName

ProcessGPOs: Domain controller is: \\ DC FQDN Domain DN is DomainName
...
EvaluateDeferredOUs: Object OUName cannot be accessed
GetGPOInfo: EvaluateDeferredOUs failed. Exiting

７ Note

In these entries, OUName is the parent organizational unit (OU) of the user account
or of a computer object.

Cause
This problem occurs because the Group Policy engine in Windows XP Professional and
newer does not have read permissions to the following attributes of the parent OUs:

distinguishedNanme (used in the search filter)

gPLink (requested as data)
gPOptions (requested as data)
If the Group Policy engine does not have these permissions, the Group Policy engine
cannot apply Group Policy settings.

In Microsoft Windows 2000 Server, the events that are described in the "Symptoms"
section are not logged. The Group Policy engine in Windows 2000 Server then ignores
the Group Policy settings that are linked to the OU. Windows XP was changed to not
ignore this error.

By default, access to all OUs is granted according to an access control entry in the
default security descriptor. This security descriptor is part of the schema that enables the
Authenticated Users group to read all the properties.

Resolution
To resolve this problem, grant sufficient permissions to access the parent OUs to all the
user accounts and to all the computers that apply Group Policy settings through the
OUs.

Granting permissions on the "distinguishedName" attribute through ACL Editor requires

you to change the attribute visibility in DSSEC.DAT in the "[organizationalUnit]" section.
You need to change the line "distinguishedname=7" to "distinguishedname=0".

When you then restart the application showing ACL Editor, the attribute should be
visible.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event 1202 with status 0x534 logged on
Windows Server 2008 R2 domain
controllers after modifying security
policy
Article • 12/26/2023

This article provides a solution to an event logged on domain controllers after

modifying security policy.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2000705

Symptoms
The Application log on Windows Server 2008 R2 domain controllers contains Event ID
1202 with status code "0x534: No mapping between account names and security IDs
was done" every time security policy is applied. The relevant part of the Event ID 1202 is
shown below:

Log Name: Application

Source: SceCli
Date: MM/DD/YYYY HH:MM:SS AM | PM
Event ID: 1202
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: <computer name>
Description:
Security policies were propagated with warning. 0x534 : No mapping between
account names and security IDs was done.

Advanced help for this problem is available on https://support.microsoft.com .

Query for "troubleshooting 1202 events".

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs)
could not be resolved to a SID. This error is possibly caused by a mistyped or
deleted user account referenced in either the User Rights or Restricted Groups
 branch of a GPO. To resolve this event, contact an administrator in the domain to
perform the following actions:

The WINLOGON.LOG contains the following text:

...
Configure S-1-1-0.
Configure S-1-5-11.
Configure S-1-5-32-554.
Configure S-1-5-32-548.
Configure S-1-5-32-550.
Configure S-1-5-9.
Configure WdiServiceHost.
Error 1332: No mapping between account names and security IDs was done.
Cannot find WdiServiceHost.
Configure S-1-5-21-2125830507-553053660-2246957542-519.
add SeTimeZonePrivilege.
User Rights configuration was completed with one or more errors. ...

By default, the GPTMPL.INF policy in the Default Domain Controllers Policy looks like
this:

SeSystemProfilePrivilege = *S-1-5-80-3139157870-2983391045-3678747466-
658725712-1809340420,*S-1-5-32-544

Once an unrelated security setting is modified in the Default Domain Controllers Policy,
the SeSystemProfilePrivilege entry in Default Domain Controllers Policy appears as
below:

SeSystemProfilePrivilege = *S-1-5-32-544,WdiServiceHost

For more information, see SceCli 1202 events are logged every time Computer Group
Policy settings are refreshed on a computer that is running Windows Server 2008 R2 or
Windows 7 .

Cause
When modifying any security setting in the Default Domain Controllers Policy using the
Group Policy Management Console (GPMC) from the console of a Windows Server 2008
R2 domain controller, GPMC incorrectly translates the SID for the Wdiservice account in
the policy to a user name that isn't recognized by the local machines where the policy is
enforced. This issue also occurs when a Windows 7 or Windows Server 2008 R2 member
computer modifies any security setting in the Default Domain Controllers Policy on a
Windows Server 2008 R2 domain controller.

Workaround
As a temporary workaround, manually edit the GPTMPL.INF file by adding the NT
Service\ prefix in front of the wdiservicehost account name for the Profile System
Performance user right in the Default Domain Controllers Policy. Which has to be done
every time any security setting in the Default Domain Controllers Policy is administered
with GPMC.

This step will prevent the 1202 event from being logged until the next time security
policy is modified in the Default Domain Controllers Policy by the relevant operating
system versions.

1. Open the GPTTMPL.INF file for the Default Domain Controllers Policy of a domain
controller logging the Event ID 1202. The path to the GPTTMPL.INF file when
SYSVOL is located below %SystemRoot% is:
%SystemRoot%\Sysvol\domain\Policies\{6AC1786C-016F-11D2-945F-

00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GPTTMPL.INF

2. Locate the SeSystemProfilePrivilege entry in the GPTTMPL.INF and modify it as

follows:

Before: SeSystemProfilePrivilege = *S-1-5-32-544,WdiServiceHost

After: SeSystemProfilePrivilege = *S-1-5-32-544,nt service\WdiServiceHost

７ Note

NT Service\ should appear after the "," delimiter. Don't prefix NT Service\
with the "*" character.

3. Save the changes to GPTTMPL.INF.

4. From a command prompt on the console of the domain controller whose

GPTTMPL.INF file was modified in Step 1, type Gpupdate /force.

5. View the Application log to see if an Event ID 1202 with status code 0x534 was
logged. If so, review the WINLOGON.LOG to see if the event was caused by the
 WdiServiceHost security principal.

More information
In the Default Domain Controllers Policy on a Windows Server 2008 R2 domain
controller, the SID for the Diagnostics Service Host (wdiservicehost) account is granted
the SeSystemProfilePrivilege where it's added to the local SAM of the machine, picked
up by SCE, then added to the GPTTMPL.INF.

When any security setting is modified in the Default Domain Controllers Policy on a
Windows Server 2008 domain controller, a code defect causes the SID for the
Wdiservicehost account to be replaced with its SAM account but fails to add the NT
Service\ prefix required by SCECLI to resolve the account's name. (that is, NT
Service\Wdiservicehost).

1. The issue described in this policy occurs when the Group Policy Management
Editor on Windows 7 or Windows Server 2008 R2 computers is used to modify
security settings in Default Domain Controllers Policy on a Windows Server 2008
domain controller.

2. This issue doesn't occur when security policy is modified in policies other than
Default Domain Controllers Policy.

3. Despite the logging of the Event ID 1202 with status code 0x534, this issue doesn't
prevent Windows computers from applying security policy contained in the Default
Domain Controllers Policy. However, there's no way to distinguish a false positive
event caused by this issue from a legitimate misconfiguration that will prevent
security policy from applying, identified by the same Event ID 1202 and 0x534
status code.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Group Policy error: "The given Key was
not present in the dictionary"
Article • 12/26/2023

This article provides a solution to a Group Policy error (The given Key was not present in
the dictionary) that occurs when you run the Group Policy Modeling Wizard against a
new Group Policy setting.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 2692409

Symptoms
Consider the following scenario:

You create a new Group Policy setting and configure some registry items under
Preferences (user or Computer). To do this, you use the registry wizard to add
keys or values to the registry. For example, under Computer
configuration\Preferences\Registry , you right-click and then select New ->

Registry Wizard. This opens a user interface that enables you to manipulate
registry items.

On Windows Server 2008 R2 and Windows Server 2008, you run the Group Policy
Modeling Wizard against the new Group Policy setting. In this scenario, you
experience one of the following symptoms, depending on your version of Internet
Explorer:

In Internet Explorer 8, you receive the following error message and error code
80131577: An error occurred while generating report. The given Key was not
present in the dictionary

In Internet Explorer 9, the wizard runs but does not report any registry settings.
Additionally, the Registry Preferences section is empty.

Cause
There is a faulty registry item in the XML file that is associated with the Group Policy
registry settings.
Resolution
To fix this issue, re-create the Group Policy and registry settings. However, while you are
using the registry browser to select values in a registry key, do not select the parent key
together with the values in it. The parent key is autoselected. This is, when you select a
value in a key, a red tick appears automatically on the parent key folder. It is not
necessary also to select the parent key.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

User Profiles and Folder Redirection
group policies aren't applied
Article • 12/26/2023

This article helps fix an issue that prevents User Profiles and folder redirection policies
from working in Microsoft System Center Configuration Manager (SCCM).

Applies to: Windows 10

Original KB number: 3060058

Symptoms
Computers running Windows 8 and later versions may not apply User Profiles and
Folder Redirection Group Policy objects (GPOs) as expected. This issue can occur if the
computers are domain clients and are managed by System Center 2012 Configuration
Manager Service Pack 1 (ConfigMgr 2012 SP1) or later.

Resolution
To work around this issue, disable the Enable User Data and Profiles device setting in
the System Center 2012 Configuration Manager console.

For more information, see Create user data and profiles configuration items in
Configuration Manager.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy error events logged when
unknown environment variable is used
Article • 12/26/2023

This article helps avoid Group Policy error events that are logged when unknown
environment variable is used.

Applies to: Windows Server 2012 R2

Original KB number: 2003730

Symptoms
If you are running an Active Directory forest and using a file system security policy, you
may see the following events logged:

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2
will log this event to the Group Policy operational log:

Log Name: Microsoft-Windows-GroupPolicy/Operational

Source: Microsoft-Windows-GroupPolicy
Event ID: 7016
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Description:
Completed Security Extension Processing in 20984 milliseconds.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
...
<EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">20984</Data>
<Data Name="ErrorCode">1252</Data>
<Data Name="CSEExtensionName">Security</Data>
<Data Name="CSEExtensionId">{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
</Data>
</EventData>
</Event>
 Windows XP and Windows Server 2003 will log this event in the Application log:

Event ID: 1091

Category: None
Source: Userenv
Type: Error
Message: The Group Policy client-side extension Security failed to log RSOP
(Resultant Set of Policy) data. Look for any errors reported earlier by that
extension.

All Windows version will log this event in the Application log:

Event ID: 1202

Category: None
Source: SceCli
Type: Warning
Message: Security policies were propagated with warning. 0xd: The data is
invalid.
Depending on the actual policy configuration, the settings in the security
policies may or may not be present. The More Information section explains
the conditions for policy failure or success (despite the errors).

Cause
The events are logged because the file system security settings of one policy contain an
environment variable that is unknown on the client computer. To find out more about
the problem, enable logging of the security configuration client-side extension:

Troubleshoot SCECLI 1202 events.

In the %windir%\security\logs\winlogon.log file, you will see an entry such as:

Process GP template gpt0000x.inf.

Error 13: The data is invalid.

Error converting %PROGRAMFILES(X86)%\MyApplication.

%PROGRAMFILES(X86)% is only an example. It is used when the policy is edited on a 64-

bit version of Windows and security settings are made for the folder C:\PROGRAM FILES
(X86) or one of its subfolders.
The gpt0000x.inf file, a text file containing the policy settings, can be found in the
%windir%\security\templates\policies folder. It also contains the location of the policy in
Active Directory in the line starting with GPOPath, allowing you to identify which policy
has the unknown environment variable.

Resolution
To avoid the problem, create a new policy at the same level that receives the settings
referencing the missing environment variable. Then use a WMI filter to allow the policy
to only apply to machines that have the environment variable defined.

For example, the WMI filter for %PROGRAMFILES(X86)% would be:

Select * from Win32_Envrionment where Name = 'PROGRAMFILES(X86)'

More information
This section explains why in some cases the policy settings apply successfully, but in
other cases they do not.

Security group policy is driven by the Userenv.dll library running within the
Winlogon.exe process, or on Windows Vista and later, the Group Policy Service (GPSvc).
This is the component that gets the list of policies that are assigned to the machine, and
filters out the ones that do not apply. They may be filtered based on the permissions on
the policy or a WMI filter.

Userenv/GPSvc then sorts the policies based on their priority. The first policy applied is
the one with the lowest priority, the last one is the one with the highest priority. For
security policy, Userenv/GPSvc calls the security policy client-side extension (SCECLI)
with the policy settings file downloaded from SYSVOL.

SCECLI has two phases. In the first phase, it takes the settings passed to it and feeds
them into the security database. The second phase is applying these settings to the
system, for example, set user rights, security options or set security descriptors on the
registry and files.

The first phase is active until the last policy is being processed. The call from
Userenv/GPSvc to SCECLI for the last policy is a special case. When the call is made, the
first phase is still active and the settings from the last policy are read into the security
database as with all other policies. But before the call returns, SCECLI sees that this is the
last policy and, within the same call, executes the second phase.
The settings for registry and file system policy are deemed to be expensive to commit,
SCECLI does not execute them in the calling thread in foreground mode. For these
settings, Userenv/GPSvc would create an additional thread so processing can complete
while the user can already logon. Domain controllers are an exception to this rule. They
would always first complete all security policy application before the user can logon.

With regard to missing environment variables, SCECLI reads the settings in the first
phase and encounters an error when it resolves the environment variable to the actual
path. SCECLI will skip the entry and continue adding settings to the security database
and later return an error to Userenv/GPSVC.

When the problem happens in any policy except the last policy, Userenv/GPSVC treats
the error as a fatal problem and aborts security group policy. Therefore the second
phase is never happening. When the problem happens in the last policy, SCECLI ignores
the error and executes the second phase. Userenv/GPSVC still aborts policy application
with an error, but actually policy processing has been completed by this point.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group Policy fails to apply if default
value of "Specify startup policy
processing wait time" isn't honored
Article • 12/26/2023

This article helps fix an issue in which Group Policy fails to apply because the Specify
startup policy processing wait time group policy value isn't honored.

Group Policy fails to apply during system startup because the default value of the
Specify startup policy processing wait time group policy isn't honored.

This issue occurs because the Specify startup policy processing wait time group policy
isn't configured. If the group policy isn't configured, the Group Policy Service will
retrieve the wait time-out from the following registry values:

HKLM\Software\Microsoft\Windows\CurrentVersion\Group
Policy\History\AvgWaitTimeoutAtStartup

HKLM\Software\Microsoft\Windows\CurrentVersion\Group

Policy\History\CurrentWaitAtStartup

In this case, the time-out is miscalculated, and the Group Policy Service doesn't wait for
the default 30 seconds for the network to be available.

To work around this issue, configure the Specify startup policy processing wait time
group policy in Computer Configuration\Administrative Templates\System\Group policy\
with the desired value.

Install Windows updates

To fix this issue, install Windows updates released on or after the following:

ﾉ Expand table

Products Updates

Windows 11, version 22H2 August 22, 2023—KB5029351 (OS Build 22621.2215)

Windows 11, version 21H2 August 22, 2023—KB5029332 (OS Build 22000.2360)

Windows Server 2022 September 12, 2023—KB5030216 (OS Build 20348.1970)

 Products Updates

Windows 10, version 22H2 August 22, 2023—KB5029331 (OS Build 19045.3393)

Windows 10 Enterprise LTSC 2019 September 12, 2023—KB5030214 (OS Build 17763.4851)
Windows 10 IoT Enterprise LTSC
2019
Windows 10 IoT Core 2019
Windows Server 2019

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Group policy with WMI filters can be
denied or cause slow logon/boot
Article • 12/26/2023

This article provides a resolution to an issue where Group policy with WMI filters can be
denied or cause slow logon/boot.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2663850

Symptoms
Group policy with WMI filter fails to apply. The WMI query (WMI filter linked to a GPO)
times out due to which the GPO does not apply to the computers, intermittently.

GPSVC logs show the following:

GPSVC(320.af8) <DateTime> FilterCheck: Evaluate returned error. hr=0x80041069

GPSVC(320.af8) <DateTime> ProcessGPO: The GPO does not pass the filter check
and so will not be applied.

ERR for 0x80041069 gives the following result:

# for hex 0x80041069 / decimal -2147217303

WBEM_E_TIMED_OUT wbemcli.h
# as an HRESULT: Severity: FAILURE (1), FACILITY_ITF (0x4), Code 0x1069
# for hex 0x1069 / decimal 4201
ERROR_WMI_INSTANCE_NOT_FOUND winerror.h
# The instance name passed was not recognized as valid by a # WMI data provider
# 2 matches found for "0x80041069"

Cause
WMI filtering was taking time while being processed. It was trying to enumerate all the
domain names as query used was:

SQL

Select * from Win32_NTDomain where ClientSiteName = "XYZ"

Resolution
Add domain name component to the WMI query to resolve the issue (along with the
AND operator):

SQL

Select * from Win32_NTDomain where DomainName = "Domain_name" AND

ClientSiteName = "XYZ"

Make sure the below hotfix is already installed:

After you apply a WMI filter, the GPO does not take effect on a client computer that is
running Windows 7 or Windows Server 2008 R2

More information
Timeout for WMI queries:

Per-Vista = None
Vista onwards = 30 seconds (hardcoded)

In one of the cases, it was informed that removing customized security filtering from the
GPO (that has WMI filter configured) resolved the issue, however, it has not been tested
or verified.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
User Experience issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"LDAP Bind function call failed" error
when updating Group Policy settings
Article • 12/26/2023

This article helps resolve the error "LDAP Bind function call failed" that occurs when
updating Group Policy settings.

When you use the gpupdate command to update Group Policy settings, you receive the
following error:

Output

C:\Windows\system32>gpupdate
Updating policy...
Computer policy could not be updated successfully. The following errors were
encountered:
The processing of Group Policy failed because of lack of network
connectivity to a domain controller. This may be a transient condition. A
success message would be generated once the machine gets connected to the
domain controller and Group Policy has successfully processed. If you do not
see a success message for several hours, then contact your administrator.
User Policy could not be updated successfully. The following errors were
encountered: The processing of Group Policy failed. Windows could not
authenticate the Active Directory service on a domain controller. (LDAP Bind
function call failed). Look in the details tab for error code and
description.

To diagnose the failure, review the event log or run GPRESULT /H

GPReport.html from the command line to access information about Group Policy
results.

On the domain controller, the default principles are missing for the SeNetworkLogonRight
user right associated with the Access this computer from the network Group Policy
setting. That policy is under Computer Configuration > Windows Settings > Security
Settings > Local Policies > User Rights Assignment in the Local Group Policy Editor.

In this scenario, the default domain policy is enforced over the default domain controller
policy. Then, the default domain policy shows an incorrect user right assignment for the
Access this computer from the network Group Policy setting.

To resolve this issue, make sure that the appropriate principles are added and that the
settings are effective on the domain controller, as described in Access this computer
from the network - security policy setting. Then, restart the domain controller.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you edit a policy in
Windows:
Microsoft.Policies.Sensors.WindowsLoca
tionProvided is already defined
Article • 12/26/2023

This article helps fix an issue that triggers an error when the central store contains the
.admx files from Windows 10.

Applies to: Windows 10 - all editions, Windows Server 2012 R2, Windows Server 2016,
Windows Server 2019
Original KB number: 3077013

Symptoms
Consider the following scenarios.

Scenario 1:

You have a domain controller that's running Windows Server.

You create a central store for Group Policy Administrative Template files (.admx
files) on the computer. For more information, see How to create the Central Store
for Group Policy Administrative Template files in Windows Vista.
You join a Windows 10-based computer to the domain.
On the Windows 10-based computer, you copy the files under the
%systemroot%\PolicyDefinitions directory, paste them to the ADMX central store,
and overwrite all existing *.admx and *.adml files. Then, you open the Group Policy
Management Console (GPMC) to edit a policy.
You click the Policies node under Computer Configuration or User Configuration.

Scenario 2:

You have a computer that's running Windows 10 RTM (Build 10240).

You upgrade the computer to later builds of Windows 10.

In these scenarios, you receive the following error message:

Administrative Templates
 Dialog Message text Namespace
'Microsoft.Policies.Sensors.WindowsLocationProvider' is already defined as the
target namespace for another file in the store.

File
\\<forest.root>\SysVol\<forest.root>\Policies\PolicyDefinitions\Microsoft-Windows-
Geolocation-WLPAdm.admx, line 5, column 110

７ Note

The <forest.root> placeholder represents the domain name.

For example, the error message resembles the message in the following screenshot:

７ Note

You may not notice this issue if you are upgrading from Windows 7 or Windows 8.1
to Windows 10 version 1511 (skipping Windows 10 RTM).

Cause
This issue occurs because the LocationProviderADM.admx file was renamed as
Microsoft-Windows-Geolocation-WLPAdm.admx in Windows 10 RTM.

Scenario 1

After you copy the .admx files from Windows 10 to a central store that contains a
LocationProviderADM.ADMX file that's from an earlier release of Windows, there
are two .admx files that contain the same settings but that have different names.
This triggers the "namespace is already defined" error.
 Scenario 2

When you upgrade from Windows 10 RTM to Windows 10 version 1511, the new
LocationProviderAdm.admx file is copied to the folder while still keeping the old
Microsoft-Windows-Geolocation-WLPAdm.admx file. Therefore, there are two
ADMX files that address the same policy namespace.

Workaround
Method 1

Click OK to ignore the error message. The error message is informational, and the
Group Policy setting works as expected.

Method 2

Delete the LocationProviderADM.admx and LocationProviderADM.adml files, and

change Microsoft-Windows-Geolocation-WLPAdm.admx and Microsoft-Windows-
Geolocation-WLPAdm.adml to the correct names.

Scenario 1:

1. Delete the LocationProviderADM.admx and LocationProviderADM.adml files from

the central store.
2. Rename Microsoft-Windows-Geolocation-WLPAdm.admx as
LocationProviderADM.admx.
3. Rename Microsoft-Windows-Geolocation-WLPAdm.adml as
LocationProviderADM.adml.

Scenario 2:

Delete the Microsoft-Windows-Geolocation-WLPAdm.admx file from the local

store. The path to the local policy store is C:\Windows\PolicyDefinitions.

DMX and ADML files are system-protected. To rename or delete these files, you must
add NTFS permissions to the files. To do this, use the following commands:

1. Open an elevated command prompt, and then use takeown.exe to grant

ownership to local administrators:

takeown /F " C:\Windows\PolicyDefinitions\Microsoft-Windows-Geolocation-

WLPAdm.admx" /A
 takeown /F " C:\Windows\PolicyDefinitions\en-US\Microsoft-Windows-Geolocation-
WLPAdm.adml" /A

2. Grant administrators Full Control permissions to both files.

3. Rename both files with an extension of .old, and you'll no longer receive the
Geolocation pop-ups when you open GPEDIT.MSC.

More information
There's only a single line of difference between the contents of the pre-Windows 10
LocationProviderADM.admx file and the Windows 10 Microsoft-Windows-Geolocation-
WLPAdm.admx file.

In the pre-Windows 10 LocationProviderADM.admx file, the <supportedOn> line

appears as follows:

XML

<supportedOn ref="windows:SUPPORTED_Windows8"/>

In the Windows 10 LocationProviderADM.admx, the <supportedOn> line appears as

follows:

XML

<supportedOn ref="windows:SUPPORTED_Windows8_Or_Windows_6_3_Only"/>

This error occurs when you click the Policy node under Computer Configuration or User
Configuration.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

Netlogon event ID 5719 or Group Policy
event 1129 is logged when you start a
domain member
Article • 12/26/2023

This article solves the Netlogon event ID 5719 or Group Policy event 1129 that's logged
when you start a domain member.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 938449

Symptoms

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

Consider this scenario:

You have a computer that's running Windows 10 or Windows Server 2012 R2.
The computer is joined to a domain.
One of these conditions is true:
The computer has a Gigabit network adapter installed.
You secure the network access by using Network Access Protection (NAP),
network authentication (by using 802.1x), or another method.

In this scenario, the following event is logged in the System log when you start the
computer in Windows 8.1 and earlier versions. In Windows 10 and later versions, event
5719 is no longer logged in this situation. The following lines are recorded in
Netlogon.log instead:

Output

[CRITICAL] [960] CONTOSO: NlSessionSetup: Session setup: cannot pick trusted

DC
[SESSION] [960] No IP addresses present, skipping No DC event log
After this issue occurs, the computer is assigned an IP address:

Output

[SESSION] [960] V6 Winsock Addrs: fe80::5faf:632a:f22c:644a%2 (1)

V6WinsockPnpAddresses List used to be empty.
[SESSION] [960] Winsock Addrs: 10.1.1.80 (1) List used to be empty.

On Windows 10 and later versions, you'll see only events by components, depending on
the Domain Controller connectivity (such as Group Policy). The following entries are
recorded in the group policy debug log:

Output

CGPApplicationService::MachinePolicyStartedWaitingOnNetwork.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Average is
388.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Current is
-1.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Taking min
of 776 and 30000.
Waiting for SamSs with timeout 776

NlaQueryNetSignatures returned 1 networks

NSI Information (Network GUID) : {395DB3C8-CE45-11E5-9739-806E6F6E6963}
NSI Information (CompartmentId) : 1
NSI Information (SiteId) : 134217728
NSI Information (Network Name) :
NlaGetIntranetCapability failed with 0x15
There is no domain compartment
ProcessGPOs(Machine): MyGetUserName failed with 1355.
Opened query for NLA successfully
NlaGetIntranetCapability returned Not Ready error. Consider it as NOT
intranet capable.

GPSVC(530.ae0) <DateTime> There is no connectivity

GPSVC(530.8e0) <DateTime> ApplyGroupPolicy: Getting ready to create
background thread GPOThread.

The first section shows the calculation for the time-out to use to bring up the network. It
can be based on previous fast startups.

The second section shows that Network Location Awareness (NLA) fails to report a
working network within the wait interval that's allowed, and group policy startup
processing fails. The third section shows that the Group Policy engine starts a
background procedure, and then waits for one minute after a network becomes
available.
Cause
This issue may occur for any of these reasons:

The Netlogon service starts before the network is ready. The network stack and
adapter initialization often start at about the same time. Some network adapters
and switches have link arbitration and MAC address uniqueness checks that take
longer to complete than the wait time that is set for Netlogon to detect network
connectivity.
Solutions that verify the health of the new network member delay the network
connection and your ability to access domain controllers. If you have an automatic
Direct Access channel connection enabled, it may also require more time to do
than Netlogon allows.
The 802.1X authentication process delays connections to the domain controllers.
The client experiences a delay to retrieve an IP address from the DHCP server. It
delays the display of the network interface.

Group Policy in Windows Vista and later versions is written to negotiate the network
status that has NLA enabled. And it waits for a network that has DC connectivity.
However, Group Policy may start prematurely because of a policy application. This
situation is especially true when the delay in finding a network alternates between
startups.

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft cannot guarantee that these problems can
be solved. Modify the registry at your own risk.

Resolution 1
To resolve this issue, install the most current driver for the Gigabit network adapter. Or,
enable the PortFast option on the network switches.

Resolution 2
To resolve this issue, use the registry to change the related settings that affect DC
connectivity. To do it, use the following methods.
Method 1
Adjust the firewall settings or IPSEC policies that are changed to allow DC connectivity.
These changes are made when the client receives an IP address but requires more time
to access a domain controller, for example, after a successful verification through Cisco
NAC or Microsoft NPS Services.

Method 2
Configure the Netlogon registry setting to a value that is safely beyond the time that is
required allow DC connectivity.

７ Note

This is only effective if the machine already has an IP address. This applies to
scenarios where a NAP solution puts the machine into a quarantine network. Use
the following settings as guidelines.

Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Value Name: ExpectedDialupDelay
Data Type: REG_DWORD
Data Value is in seconds (default= 0 )
Data Range is between 0 and 600 seconds (10 minutes)

For more information, see Settings for minimizing periodic WAN traffic .

Method 3
The IP stack tries to verify the IP address using an ARP broadcast. It delays the time that
the IP takes to come online. You can set the ArpRetryCount registry entry to one (1), so
the wait for uniqueness is shortened. To do it, follow these steps:

1. Start Registry Editor.

2. Locate and select the following subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TcpIp\Parameters\

3. On the Edit menu, point to New, and then select DWORD Value.

4. Type ArpRetryCount.
 5. Right-click the ArpRetryCount registry entry, and then select Modify.

6. In the Value data box, type 1, and then select OK.

７ Note

The Data Range is between 0 and 3 (3 is default).

7. Exit Registry Editor.

Method 4
Reduce the Netlogon negative cache period by changing the NegativeCachePeriod
registry entry in the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\NegativeCa
chePeriod

After you make this change, the Netlogon service doesn't behave as if the domain
controllers are offline for 45 seconds. The event 5719 is still logged. However, the event
doesn't cause any other significant problems. This setting allows member to try domain
controllers earlier if the process failed previously.

Suggestion: Try to set a low value, such as three seconds. In LAN environments, you can
use a value of 0 to turn off the negative cache.

For more information about this setting, see Settings for minimizing periodic WAN
traffic .

Method 5
Configure the Kerberos registry setting to a value that is safely beyond the time that is
required allow DC connectivity. Use the following settings as guidelines.

７ Note

This setting applies only to Windows XP and Windows Server 2003 or earlier
versions of these systems. Windows Vista and Windows Server 2008 and later
versions use a default value of 0. This value turns off User Datagram Protocol (UDP)
functionality for the Kerberos client.
 Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameter
s
Value name: MaxPacketSize
Data Type: REG_DWORD
Value Data: 1
Default: (depends on the system version)

For more information, see How to force Kerberos to use TCP instead of UDP in
Windows .

Method 6
Disable media sense for TCP/IP by adding the following value to the Tcpip registry
subkey:

Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD
Value Data: 1
Value Range: Boolean ( 0 =False, 1 =True)
Default: 0 (False)

For more information, see How to disable the Media Sensing feature for TCP/IP in
Windows .

Method 7
Group Policy has policy settings to control the wait time for startup policy processing:

1. Corporate LAN or WLAN:

Policy Folder: "Computer Configuration\Administrative

Templates\System\Group Policy"
Policy Name: "Specify startup policy processing wait time"

2. External LAN or WLAN:

Policy Folder: "Computer Configuration\Administrative

Templates\System\Group Policy"
 Policy Name: "Specify workplace connectivity wait time for policy processing"

The time it takes Netlogon to acquire a working IP can be the basis for the setting. For
Direct Access scenarios, you can measure the typical delay your user base has until the
connection is established.

Method 8
If DisabledComponents registry setting is in place and has an incorrect value of 0xfffffff,
either delete the key or change it to the intended value of 0xff.

） Important

Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and later
versions of Windows. We do not recommend that you disable IPv6 or its
components. If you do, some Windows components may not function. Additionally,
system startup will be delayed for five seconds if IPv6 is disabled incorrectly by
setting the DisabledComponents registry setting to a value of 0xfffffff. The correct
value is 0xff.

Method 9
The behavior may be caused by a race condition between network initialization, locating
a Domain Controller and processing Group Policy. If the network isn't available, a
Domain Controller won't be located, and Group Policy processing will fail. Once the
operating system has loaded and a network link is negotiated and established,
background refresh of Group Policy will succeed.

You can set a registry value to delay the application of Group Policy:

1. Start Registry Editor.

2. Locate and select the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

3. On the Edit menu, point to New, and then select DWORD Value.

4. Type GpNetworkStartTimeoutPolicyValue.

5. Right-click the GpNetworkStartTimeoutPolicyValue registry entry, and then select

Modify.
 6. Under Base, select Decimal.

7. In the Value data box, type 60, and then select OK.

8. Exit Registry Editor, and then restart the computer.

9. If the Group Policy startup script doesn't run, increase the value of the
GpNetworkStartTimeoutPolicyValue registry entry.

More information
If you can log on to the domain without a problem, you can safely ignore event ID 5719.
Because the Netlogon service may start before the network is ready, the computer may
be unable to locate the logon domain controller. Therefore, event ID 5719 is logged.
After the network is ready, the computer will try again to locate the logon domain
controller. In this situation, the operation should be successful.

In a Netogon.log, entries that resemble the following example may be logged:

Output

DateTime [CRITICAL] <domain>: NlDiscoverDc: Cannot find DC. DateTime

[CRITICAL] <domain>: NlSessionSetup: Session setup: cannot pick trusted DC
DateTime [MISC] Eventlog: 5719 (1)"<domain>" 0xc000005e ... DateTime
[SESSION] WPNG: NlSetStatusClientSession: Set connection status to c000005e
... DateTime [SESSION] \Device\NetBT_Tcpip_{4A47AF53-40D3-4F92-ACDF-
9B5E82A50E32}: Transport Added (10.0.64.232) -> Getting a proper IP address
takes >15 seconds.

Similar errors might be reported by other components that require Domain Controller
connectivity to function correctly. For example, the Group Policy may not be applied at
system startup. In this case, startup scripts don't run. The Group Policy failures may be
related to the failure of Netlogon to locate a domain controller. You can set Group
Policy to be more responsive to late network connectivity arrival.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Network disconnection after
configuring the LLTDIO and RSPNDR
group policy objects
Article • 12/26/2023

This article helps resolve the issue in which the network disconnects after configuring
the LLTDIO and RSPNDR group policy objects.

Applies to: Windows Server

Original KB number: 4645933

After you configure the LLTDIO and RSPNDR group policy objects (GPOs) and set the
NoGPOListChanges subkey value to apply group policies even if the objects haven't

changed, your network is disconnected. This issue typically occurs after a group policy
update. The disconnection may also cause the following issues:

Virtual private network (VPN) dropping the connection

Remote Desktop Protocol (RDP) session temporary disconnection
File transfer disruption
Windows Firewall dropping packets with un-quarantine filters enabled

This is a design limitation. The LLTDIO and RSPNDR-related policies are changed in the
registry. To reapply the policies, the two protocols (the Mapper I/O network protocol
and the Responder network protocol) need to re-bind on the network interface card
(NIC). This action requires an automatic restart of the NIC, which leads to the disruption
of the network connectivity.

Modify and remove related policy settings

To resolve this issue, use one of the following two methods:

In the Local Group Policy Editor, go to Computer Configuration > Administrative

Templates > System > Group Policy, double-click the policy setting Configure
registry policy processing, and uncheck the option Process even if the Group
Policy objects have not changed.

Go to Computer Configuration > Administrative Templates > Network > Link-

Layer Topology Discovery, and set the state of the following policy settings to Not
configured:
Turn on Mapper I/O (LLTDIO) driver
 Turn on Responder (RSPNDR) driver

Feedback
Was this page helpful?  Yes  No

Provide product feedback

User profiles older than a specified
number of days aren't deleted as
expected on system restart
Article • 12/26/2023

This article helps resolve an issue in which the Delete user profiles older than a
specified number of days on system restart Group Policy is applied but doesn't take
effect.

The Delete user profiles older than a specified number of days on system restart
Group Policy is under Computer Configuration > Administrative Templates > System >
User Profiles in either the Local Group Policy Editor or some Group Policy Objects
(GPOs). After it's applied, it fails to delete user profiles older than the number of days
specified in the GPO.

This issue occurs because the related settings configured in Windows Management
Instrumentation (WMI) take precedence over the GPO settings. The settings in WMI can
come from either Microsoft System Center Configuration Manager (SCCM) compliance
settings or third-party applications.

To determine if user profile settings are controlled by SCCM or some third-party

application, check the following registry settings. If they're set to 1, it means that the
settings are managed by either SCCM or some third-party application, and therefore the
GPO settings are ignored.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UserState\UserStateTec

hnologies\ConfigurationControls

ﾉ Expand table

Value name Value type Value data

RoamingUserProfile DWORD 00000001

FolderRedirection DWORD 00000001

OfflineFiles DWORD 00000001

Disable the "Enable User Data and Profile"

compliance setting pushed through SCCM
To resolve the issue, follow these steps:

1. In the Configuration Manager console, go to Administration > Client Settings >

Default Settings.
2. On the Home tab of the ribbon, in the Properties group, select Properties.
3. In the Default Settings dialog box, select Compliance Settings.
4. From the Enable User Data and Profiles drop-down list, select No.
5. Select OK to close the Default Settings dialog box.

If they aren't controlled by SCCM but by some third-party application, contact the
vendor for how to disable the settings.

For more information, see Create user data and profiles configuration items in
Configuration Manager.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Changes are not applied when you
change the password policy
Article • 12/26/2023

This article helps solve an issue where the changes aren't applied as expected when you
change the password policy.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 269236

Symptoms
When you change the password policy, the changes are not applied as expected.

Cause
This issue can occur in either of the following scenarios:

The Block Policy Inheritance option is enabled on the Domain Controllers

organizational unit.
The password policy is not set in the Default Domain policy.

Resolution
To resolve this issue, disable the Block Policy Inheritance option on the Domain
Controllers organizational unit:

1. Start the Active Directory Users and Computers snap-in.

2. Right-click the Domain Controllers organizational unit, click Properties, and then
click to clear the Block Policy Inheritance check box.
3. On the domain controllers, run the following command: secedit/refreshpolicy
machine_policy/enforce
If this issue occurs because you did not set password policy in the Default Domain
policy, set all password policies in the Default Domain policy.

Status
This behavior is by design.
More information
In Windows 2000, password policies are read-only at the domain level. The policy must
be applied to the domain controllers for the policy to be applied. If you initiate a
password change for a domain password from anywhere in the domain, the change
actually occurs on a domain controller.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Set roaming profile path for all
users logging onto this computer Group
Policy setting also applies to local user
accounts
Article • 12/26/2023

This article describes the behavior where the Set roaming profile path for all users
logging onto this computer Group Policy setting applies to all user accounts including
local user accounts because Group Policy will override the local computer policy.

Applies to: Windows Server 2012 R2

Original KB number: 958736

Symptoms
You apply the Set roaming profile path for all users logging onto this computer Group
Policy setting in a domain for member servers. In this case, the Group Policy setting
applies to all user accounts, and this includes the local user accounts.

Cause
This behavior is expected because the Set roaming profile path for all users logging
onto this computer Group Policy setting is present under the Computer Configuration
node in Group Policy. Even if you specify a local computer policy, Group Policy overrides
the local computer policy. So the Group Policy setting applies to all users, and this
includes the local users.

More information

） Important

Consider the following scenario. You set up a profile on a member server. The
profile includes some important settings. In this scenario, if you apply the Set
roaming profile path for all users logging onto this computer Group Policy setting,
you lose your current profile. Additionally, you are assigned a default temporary
profile.
This behavior occurs because the Group Policy setting sets a roaming profile for all users
even though the users are local to the member server. In the Windows registry, a
registry value that is named CentralProfile in the following registry subkey is used to set
the share path of the roaming profile that is mentioned in the Group Policy for local
users:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\
<userSID>\CentralProfile

７ Note

The <userSID> placeholder specifies the security identifier (SID) of the user.

So you're assigned a default temporary profile because you don't have access to the
remote share.

The following roaming profile policy settings are currently available in Windows Server:

Set path for Remote Desktop Services Roaming User Profile

Set roaming profile path for all users logging onto this computer

Set path for Remote Desktop Services Roaming User

Profile
The Set path for Remote Desktop Services Roaming User Profile Group Policy setting
lets you specify the network path that Remote Desktop Services (RDS) uses for roaming
user profiles.

By default, RDS stores all user profiles locally on the RDS server. You can use the Set
path for Remote Desktop Services Roaming User Profile Group Policy setting to specify
a network share where user profiles can be centrally stored. When profiles are centrally
stored, users can access the same profile for sessions on all RDS servers that are
configured to use the network share for user profiles.

７ Note

The roaming user profiles that are enabled by the Set path for Remote
Desktop Services Roaming User Profile Group Policy setting apply only to
RDS connections. You may also have a Windows roaming user profile that is
configured. The RDS roaming user profile always takes precedence in a RDS
session.
 If you configure the Set path for Remote Desktop Services Roaming User
Profile Group Policy setting, each user who logs on by using a RDS session
uses the path that is specified as the roaming profile location.

Set roaming profile path for all users logging onto this
computer
To use the Set roaming profile path for all users logging onto this computer Group
Policy setting, type the path of the network share in the following form:

\\Computername\Sharename\

If you enable the Set roaming profile path for all users logging onto this computer
Group Policy setting, all users who log on to the computer use the roaming profile path
that is specified in the Group Policy setting. This behavior is by design.

７ Note

You have to make sure that you have set the appropriate security on the
folder to let all users access the profile.

If you use a local user account, the profile path may fail because of lack of
permissions.

There are four ways to configure a roaming profile for a user. Windows reads
profile configuration in the following order, and Windows uses the first
configured setting that it reads:
The RDS roaming profile path that is specified by RDS policy
The RDS roaming profile path that is specified by the user object
A per-computer roaming profile path that is specified in the Set roaming
profile path for all users logging onto this computer Group Policy setting
A per-user roaming profile path that is specified in the user object

If you configure the Set roaming profile path for all users logging onto this
computer Group Policy setting, each user who logs on to the member server
uses the path that is specified as the roaming profile location.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Folder redirection settings are still
applied from Group Policy settings even
though you turn on loopback
processing in Group Policy
Article • 12/26/2023

This article provides a solution to an issue that folder redirection settings are being
applied from the Group Policy settings that are deployed to the user's computer even
though you turn on loopback processing in Group Policy.

Applies to: Windows Server 2012 R2

Original KB number: 328008

Symptoms
When you turn on loopback processing in Group Policy, you may notice that folder
redirection settings are being applied from the Group Policy settings that are deployed
to the user's computer. All the settings that are configured by the loopback policy take
effect except the folder redirection settings.

You notice this problem only when a user already has a Group Policy setting for folder
redirection, and you try to turn on loopback processing on his or her computer. You do
not notice this problem when users have a Group Policy setting applied for folder
redirection, they have loopback processing turned on at the same time, and that
loopback processing is being turned on for the first time.

Cause
This problem occurs when you turn on loopback processing with Replace mode in
Group Policy, but you do not configure any folder redirection settings for that policy.

When you do not configure any folder redirection settings, the default setting for folder
redirection folders, such as the My Documents folder, is No Administrative policy
specified. This setting does not remove or turn off the folder redirection feature if it is
turned on for the user by another Group Policy setting.

Resolution
To resolve this problem, configure the folder redirection settings for the Group Policy
setting.

For example, to redirect the My Documents folder, follow these steps:

1. Change the My Documents folder setting in the loopback policy to Redirect

everyone's folder to the same location.
2. Set the destination folder location as %LOCALPROFILE%\My Documents.

This points the My Documents folder to the user local profile My Documents folder
path. You can turn on or turn off the Move the contents of My Documents to new
location setting, depending on whether you want to move the copy of the My
Documents folder from the server share.

７ Note

When the Move the contents of My Documents to new location setting is turned
on, the contents of the My Documents folder are redirected every time the user
switches from the computer that is affected by the loopback policy to another
computer. By turning off this setting, you avoid this.

More information
Organizations that use software distribution and folder redirection Group Policy settings
may not want to use those settings for users who have slow Internet connections. Such
organizations can turn on loopback processing so that users have two different Group
Policy settings applied, based on the computer that they use to log on to the network.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Some Group Policy areas are missing
from the Group Policy Editor
Article • 12/26/2023

This article provides a solution to an issue where some Group Policy areas are missing
from the Group Policy Editor.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 555218

Symptoms
When you open the Group Policy Editor MMC snap-in tool, and focus on a local GPO or
Active Directory-based one, some Group Policy areas that are expected to appear may
not be found. These missing policy areas are different than the ones that are normally
missing when you're focused on a local GPO.

Cause
Each area of policy functionality is implemented by an MMC snap-in DLL that is
registered by default on a standard Windows 2000, 2003 or XP installation. Occasionally
those DLLs can be un-registered or removed and when that happens, the underlying
group policy editing functionality they implement will not appear in the Group Policy
editor UI.

Resolution
To resolve this issue, re-register the appropriate MMC snap-in DLL that implements the
missing functionality by issuing the following command at a Windows command
prompt

Console

regsvr32 <snap-in DLL name>

By default, all of the Group Policy related MMC snap-in DLLs can be found in
%systemroot%\system32.

The following lists the default Group Policy snap-in DLLs that you can re-register:
 Administrative Templates and Scripts: gptext.dll
Folder Redirection: fde.dll
Internet Explorer Maintenance: ieaksie.dll
IP Security: ipsecsnp.dll
Public Key and Software Restriction: certmgr.dll
Remote Installation Services: rigpsnap.dll
Security: wsecedit.dll
Software Installation: appmgr.dll

More information
When you focus on the local GPO with the MMC Group Policy Editor snap-in, it is
normal that some policy areas that you would normally see when editing an Active
Directory-based GPO are not present. This is expected behavior because the local GPO
only supports a subset of the features in an Active Directory-based GPO. However,
sometimes even when focused on Active Directory-based GPOs, some policy areas that
should be present are missing. In that case, the most likely cause is missing registrations
for the MMC snap-in DLLs that implement that functionality, and by re-registering the
missing DLL and restarting the Group Policy Editor, the problem can be resolved.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Applying Group Policy troubleshooting
guidance
Article • 12/26/2023

Try our Virtual Agent - It can help you quickly identify and fix common Active

Directory replication issues

This guide provides you with the fundamental concepts used to troubleshoot Group
Policy. You'll learn:

How to locate new troubleshooting information.

How to use the Event Viewer to filter specific Group Policy information.
How to read and interpret event data.
Correct methods for locating the point of failure.

Troubleshooting checklist
1. Start by reading Group Policy events recorded in the system event log.

Warning events provide further information for you to follow to ensure the
Group Policy service remains healthy.
Error events provide you with information that describes the failure and
probable causes.
Use the More Information link included in the event message.
Use the Details tab to view error codes and descriptions.

2. Use the Group Policy operational log.

Identify the activity ID of the instance of Group Policy processing you're

troubleshooting.
Create a custom view of the operational log.
Divide the log into phases: pre-processing, processing, and post-processing.
Consolidate each starting event with its corresponding ending event.
Investigate all warning and error events.
Isolate and troubleshoot the dependent component.
Use the Group Policy update command (GPUPDATE) to refresh Group Policy.
Repeat these steps to determine if the warning or error still exists.
 ） Important

Refreshing Group Policy changes the Activity ID in your custom view. Make sure to
update your custom view with the most current Activity ID when troubleshooting.

Determine the instance of Group Policy processing

Before you view the Group Policy operational log, you must first determine the instance
of Group Policy processing that failed.

To determine an instance of Group Policy processing, follow these steps:

1. Open the Event Viewer.

2. Under Event Viewer (Local), select Windows Logs > System.
3. Double-click the Group Policy warning or error event you want to troubleshoot.
4. Select the Details tab, and then check Friendly view. Select System to expand the
System node.
5. Find the ActivityID in the System node details. You use this value (without the
opening and closing braces) in your query. Copy this value to Notepad so it's
available to you later, and select Close.

Create a custom view of a Group Policy instance

A computer often has more than one instance of Group Policy processing. Computers
dedicated to running Terminal Services usually have more than one instance of Group
Policy processing and operate simultaneously. Therefore, it's important to filter the
Group Policy operational event log to show only events for the instance you're
troubleshooting.

Use the following procedure to create a custom view of a Group Policy instance. You do
this by using an Event Viewer query. This query creates a filtered view of the Group
Policy operational log for a specific instance of Group Policy processing.

To create a custom view of a Group Policy instance, follow these steps:

1. Open the Event Viewer.

2. Right-click Custom Views, and then select Create Custom View.

3. Select the XML tab, and then check the Edit query manually check box. The Event
Viewer displays a dialog box explaining that manually editing a query prevents you
from modifying the query using the Filter tab. Select Yes.
 4. Copy the Event Viewer query (provided at the end of this step) to the clipboard.
Paste the query into the Query box.

<QueryList><Query Id="0" Path="Application"><Select Path="Microsoft-Windows-

GroupPolicy/Operational">*[System/Correlation/@ActivityID='{INSERT ACTIVITY ID

HERE}']</Select></Query></QueryList>

5. Copy the ActivityID you previously saved from the Determine the instance of
Group Policy processing section to the clipboard. In the Query box, highlight
"INSERT ACTIVITY ID HERE" and then press Ctrl+V to paste the ActivityID over the
text.

７ Note

Be sure not to paste over the leading and trailing braces ({ }). You must
include these braces for your query to work properly.

6. In the Save Filter to Custom View dialog box, type a name and description
meaningful to the view you created. Select OK.

7. The name of the saved view appears under Custom Views. Select the name of the
saved view to display its events in the Event Viewer.

） Important

The Group Policy service assigns a unique ActivityID for each instance of policy
processing. For example, the Group Policy service assigns a unique ActivityID when
user policy processing occurs during user logon. When Group Policy refreshes, the
Group Policy service assigns another unique ActivityID to the instance of Group
Policy responsible for refreshing user policy.

Make sure the group policy has all the settings you're looking for and it's correctly
linked. Below are the tabs that you have to go through. If all of them look good, go to
the problematic client machine.

1. Open an elevated command prompt and run the following command.

Console

gpresult /h gp.html
 2. Verify the gpresult output you have captured and look for the GPO you're having
issues with. It will give an error about why the GPO isn't getting applied.

3. If you have an error in the gpresult output, we can troubleshoot the issue based
on it. Otherwise, go to the next step.

4. Open the Event Viewer and browse to application and system event logs. The
application event log will give you the details on why the group policy update fails
positively.

5. Open the operational event log for more detailed information. There are events
with the list of applied GPOs and a list of denied GPOs with the reason.

Most of the GPO issues can be resolved by using these basic logs.

Group Policy log files

You can enable verbose logging and examine the resulting log files. Verbose logging
can reduce performance and consume significant disk space, so as a best practice,
enable verbose logging only when necessary.

Enable Group Policy Service (GPSvc) logging

On the client where the GPO problem occurs, follow these steps to enable Group Policy
Service debug logging.

1. Open Registry Editor.

2. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

3. On the Edit menu, select New > Key.

4. Type Diagnostics, and then press Enter.

5. Right-click the Diagnostics subkey, select New > DWORD (32-bit) Value.

6. Type GPSvcDebugLevel, and then press Enter.

7. Right-click GPSvcDebugLevel, and then select Modify.

8. In the Value data box, type 30002 (Hexadecimal), and then select OK.

9. Exit Registry Editor.

 10. In a command prompt window, run the gpupdate /force command, and then press
Enter.

Then, view the Gpsvc.log file in the following folder: %windir%\debug\usermode

７ Note

If the usermode folder does not exist, create it under %windir%\debug. If the
usermode folder does not exist under %WINDIR%\debug\, the gpsvc.log file will not
be created.

Common issues and solutions

Event ID 1129
Event ID 1129 is logged when the Group Policy fails to apply due to network
connectivity issues.

In this case, the connectivity to Lightweight Directory Access Protocol (LDAP) port 389 is
blocked on DC. The gpupdate command fails with the following error:

When checking the event log, you may find the following event description:

Output

The processing of Group Policy failed because of lack of network

connectivity to a domain controller. This may be a transient condition. A
success message would be generated once the machine gets connected to the
domain controller and Group Policy has successfully processed. If you do not
see a success Message for several hours, then contact your administrator.

In this case, enable the gpsvc debug log. In the gpsvc log, you may find the output
"GetLdapHandle: Failed to connect <DC> with 81".

Enable a network trace to verify:

There's a ldap query done at the site level.

The query returns two entries for that site that hold the ldap service role.
For one of them, we can see a name resolution is being done.
Because the name resolution is successful, it tries to do an ldap bind but fails at
TCP handshake as port 389 is blocked.
 If there's no answer from the DC for our TCP handshake on port 389, the next steps
are to involve the customer network team and provide them with this information.
Make sure that in such scenarios, you make use of all the logs specified in the
action plan mentioned above, correlate them, and they'll lead you to the root
cause or at least narrow down the issue.

Event ID 1002
Here's the description of Event ID 1002:

Output

The processing of Group Policy failed because of a system allocation

failure. Please ensure the computer is not running low on resources (memory,
available disk space). Group Policy processing will be attempted at the next
refresh cycle.

This error event is usually resolved when the computer returns from a low-resource
state. Possible resolutions include:

1. Ensure the computer isn't low on memory or available disk space.

2. Restart the computer if it has been operating for an extended period.

Event ID 1006
Here's the description of Event ID 1006:

Output

The processing of Group Policy failed. Windows could not authenticate to the
Active Directory service on a domain controller. (LDAP Bind function call
failed). Look in the Details tab for error code and description.

This error event is usually resolved after correcting binding to the directory. The Group
Policy service logs an error code, which appears on the Details tab of the error message
in Event Viewer. The error code (displayed as a decimal) and error description fields
further identify the reason for the failure. Evaluate the error code with the list below:

Error code 5 (Access is denied)

This error code might indicate that the user doesn't have permission to access
Active Directory.

Error code 49 (Invalid credentials)

 This error code might indicate that the user's password has expired while the user
is still logged on the computer. To correct credentials that aren't valid:

1. Change the user's password.

2. Lock/unlock the workstation.
3. Check if there are any system services running as the user account.
4. Verify the password in the service configuration is correct for the user
account.

Error code is 258 (Timeout)

This error code might indicate that the DNS configuration is incorrect. To correct
timeout issues, use the nslookup tool to confirm _ldap._tcp.<domain-dns-name>
records are registered and point to correct servers (where <domain-dns-name> is
the fully qualified domain name of your Active Directory domain).

７ Note

These steps may have varying results if your network constrains or blocks
Internet Control Message Protocol (ICMP) packets.

Event ID 1030
Here's the description of Event ID 1030:

Output

The processing of Group Policy failed. Windows attempted to retrieve new

Group Policy settings for this user or computer. Look in the Details tab for
error code and description. Windows will automatically retry this operation
at the next refresh cycle. Computers joined to the domain must have proper
name resolution and network connectivity to a domain controller for
discovery of new Group Policy objects and settings. An event will be logged
when Group Policy is successful.

Check if the LDAP ports are open. If not, then make sure the ports are open on the
firewall and locally on the client and the domain controller.

How to determine port block

Use portqueryUI tool to determine which ports are blocked. For more information,
see How to use PortQry to troubleshoot Active Directory connectivity issues.
Use telnet for port 389 to check connectivity on the ldap port.
 How to configure domain and trust ports.
Configuring the default outbound firewall behavior.
Configure firewall port requirements for Group Policy.

Make sure DNS name resolution where the client is unable to

resolve a host name

If a client can't resolve a host name, then it's best to verify the Host name
resolution sequence listed above that the client should be using. If the name
doesn't exist in any of the resources that the client uses, then you must decide
which resource to add it. If the name exists in one of the resources, such as a DNS
server or a Windows Internet Name Service (WINS) server, and the client isn't
resolving the name correctly, focus your attention on troubleshooting that specific
resource.
Also, confirm that the client is trying to resolve a host name and not a NetBIOS
name. Many applications have multiple methods that they can utilize to resolve
names. This is especially true of mail and database applications. The application
may be configured to connect to resources using NetBIOS. Depending on the
client configuration, the client may bypass host name resolution. From there, it will
be necessary to either change the connection type to TCP/IP sockets or
troubleshoot the problem as a NetBIOS issue.

Group Policy Container permission

Use the following Get-GPPermission PowerShell cmdlet to get the permission level for
all security principals on the specified GPO:

PowerShell

Get-GPPermission -Name "TestGPO" -All

Event ID 1058
Here's the description of Event ID 1058:

Output

The processing of Group Policy failed. Windows attempted to read the file %9
from a domain controller and was not successful. Group Policy settings may
not be applied until this event is resolved. This issue may be transient and
could be caused by one or more of the following:
1. Name Resolution/Network Connectivity to the current domain controller.
 2. File Replication Service Latency (a file created on another domain
controller has not replicated to the current domain controller).
3. The Distributed File System (DFS) client has been disabled.

Correct connectivity to the Group Policy template. The Group Policy service logs the
name of the domain controller and the error code, which appears on the Details tab of
the error message in Event Viewer. The error code (displayed as a decimal) and error
description fields further identify the reason for the failure. Evaluate the error code with
the list below:

Error code 3 (The system cannot find the path specified)

This error code usually indicates that the client computer cannot find the path
specified in the event. To test client connectivity to the domain controller's sysvol:

1. Identify the domain controller used by the computer. The domain controller
name is logged in the details of the error event.

2. Identify if the failure happens during the user or computer processing. For
user policy processing, the User field of the event will show a valid user
name; for computer policy processing, the User field will show "SYSTEM".

3. Compose full network path to the gpt.ini as \\<dcName>\SYSVOL\

<domain>\Policies\<guid>\gpt.ini where <dcName> is the name of the
domain controller, <domain> is the name of the domain, and <guid> is the
GUID of the policy folder. All the information appears in the event.

4. Verify that you can read gpt.ini by using the full network path obtained in the
previous step. To do this, open a command prompt window and type
<file_path>, where <file_path> is the path constructed in the previous step,
and press Enter.

７ Note

You must run this command as the user or computer whose credentials
previously failed.

Error code 5 (Access is denied)

This error code usually indicates that the user or computer doesn't have the
appropriate permissions to access the path specified in the event. On the domain
controller, ensure the user and computer have appropriate permission to read the
path specified in the event. To test computer and user credentials:
 1. Log off and restart the computer.
2. Log on the computer with the domain credentials previously used.

Error code 53 (The network path wasn't found)

This error code usually indicates that the computer cannot resolve the name in the
provided network path. To test network path name resolution:

1. Identify the domain controller used by the computer. The name of the
domain controller is logged in the details of the error event.
2. Try to connect to the netlogon share on the domain controller using the path
\\<dcName>\netlogon where <dcName> is the name of the domain
controller in the error event.

Event ID 1053
Here's the description of Event ID 1053:

Output

The processing of Group Policy failed. Windows could not resolve the user
name. This could be caused by one or more of the following:
1. Name Resolution failure on the current domain controller.
2. Active Directory Replication Latency (an account created on another
domain controller has not replicated to the current domain controller).

The Group Policy service logs the name of the domain controller and the error code.
This information appears on the Details tab of the error message in Event Viewer. The
error code (displayed as a decimal) and error description fields further identify the
reason for the failure. Evaluate the error code with the list below:

Error code 5 (Access is denied): This error code might indicate that the user's
password expired while the user was still logged on the computer. If the user
recently changed their password, the issue might disappear after allowing time for
Active Directory replication to succeed.

1. Change the user password.

2. Lock/unlock the workstation.
3. Check if there are any system services running as the user account.
4. Verify that the password in the service configuration is correct for the user
account.

Error code 14 (Not enough storage is available to complete this operation)

 This error code might indicate that Windows doesn't have enough memory to
complete the task. Investigate the system event log for any other memory-specific
issues.

Error code 525 (The specified user doesn't exist)

This error code might indicate incorrect permissions on the organizational unit.
The user requires read access to the organizational unit that contains the user
object. Similarly, computers require read access to the organizational unit that
contains the computer object.

Error code 1355 (The specified domain either doesn't exist or couldn't be
contacted)

This error code might indicate a fault or improper configuration with name
resolution (DNS). Use nslookup to confirm you can resolve the addresses of the
domain controllers in the user domain.

Error code 1727 (The remote procedure call failed and didn't execute)

This error code might indicate that firewall rules are preventing communication
with a domain controller. If you have third-party firewall software installed, check
the configuration of the firewall or try temporarily disabling it and verifying that
Group Policy processes successfully.

Event ID 1097
Here's the description of Event ID 1097:

Output

The processing of Group Policy failed. Windows could not determine the
computer account to enforce Group Policy settings. This may be transient.
Group Policy settings, including computer configuration, will not be
enforced for this computer.

Domain computers authenticate to the domain, as do domain users. Windows requires

the computer to log on before it can apply Group Policy to the computer. Possible
resolutions include:

Verify that the time on the computer is synchronized with the time on the domain
controller.
Account for time zone misconfigurations if the computer is configured in a time
zone different from the domain controller.
 A time difference greater than five minutes between the computer and the domain
controller may lead to the computer failing to authenticate with the domain. Force
time synchronization against time service using the w32tm /resync command.
Restart the computer.

Event ID 4016 and Event ID 5016

During the periodic Group Policy refresh, the service uses the information it collected in
the pre-processing phase to apply each policy setting. The service accomplishes this by
passing the previously collected information to each of the system and nonsystem
client-side extensions. This phase begins by recording a client-side extension (CSE)
processing event.

ﾉ Expand table

Event Event type Explanation

ID

4016 Informational The Group Policy service logs this event each time a Group Policy client-
side extension begins its processing.

5016 Success The Group Policy service logs this event when a Group Policy client-side
extension completes its processing successfully.

When you go to the Details tab under Event ID 5016, you may find the following return
status:

Output

ErrorCode 2147483658 <-> 0x8000000a -2147483638

E_PENDING "The data necessary to complete this operation
is not yet available"

７ Note

The return value "-2147483638 (E_PENDING)" is expected and by design during

audit client-side extension processing. It indicates that an asynchronous thread was
started successfully by the Group Policy engine to process the audit extension
information. It also means that the return value will be logged even if the new audit
settings are effective or applied on the clients.
Determine the advanced Audit client side extension (AuditCSE)
processing

After you receive the return value 2147483658 from Event ID 5016, you can examine the
verbose level events of AuditCSE processing under the Security-Audit-Configuration-
Client > Operational event log. This information is useful to observe the processing of
Advanced Audit group policy settings and thus detect any failures/errors.

1. Audit Client Side Extension (Auditcse.dll) will process the Audit client side
extensions.
2. It has its own logging under Security-Audit-Configuration-Client > Operational
log.

Follow these steps to review the Security-Audit-Configuration-Client > Operational

event log for troubleshooting Audit group policy settings:

1. Open Event viewer.

2. Under Event Viewer (local), select Applications and Services Logs > Microsoft >
Windows > Security-Audit-Configuration-Client > Operational.
3. Double-click the Warning or Error events to troubleshoot. Also review the Details
tab for these events for any Error value.
4. Else, review the Informational event to capture the complete processing of Audit
extension.

Gather key information before you contact

Microsoft Support
Before you complete your support request, we recommend that you use the Windows
Live Dump feature to save a snapshot of kernel memory on the affected computer. To
do this, follow these steps:

1. Capture Group Policy Service verbose logging by running the following

commands:

Console

md %windir%\debug\usermode

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"

/v GPSvcDebugLevel /t REG_DWORD /d "0x00030002"

2. Refresh local and AD-based Group Policy settings by using the gpupdate /force
command.
  Tip

Use one of the below commands if you troubleshoot a particular user or

computer missing settings:

Gpupdate /force /target:computer

Gpupdate /force /target:user

3. Save the Resultant Set of Policy (RSoP) report to an HTML file by running the
following command:

Console

gpresult /h %Temp%\GPResult.htm

4. Save the RSoP summary data to a txt file by running the following command:

Console

gpresult /r >%Temp%\GPResult.txt

5. Export the GPExtensions registry keys by running the following command:

Console

reg export "HKLM\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Winlogon\GPExtensions" %Temp%\GPExtensions.reg

6. Export the system, application, and Group Policy operational event viewer logs by
running the following commands:

Console

wevtutil.exe export-log Application %Temp%\Application.evtx

/overwrite:true

wevtutil.exe export-log System %Temp%\System.evtx /overwrite:true

wevtutil.exe export-log Microsoft-Windows-GroupPolicy/Operational

%Temp%\GroupPolicy.evtx /overwrite:true

7. Capture the following files:

%Temp%\Application.evtx
 %Temp%\System.evtx
%Temp%\GroupPolicy.evtx
%Temp%\GPExtensions.reg
%Temp%\GPResult.txt
%Temp%\GPResult.html
%windir%\debug\usermode\gpsvc.log

8. When finished, you can stop Group Policy Service logging by running the following
command:

Console

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"

/v GPSvcDebugLevel /t REG_DWORD /d "0x00000000" /f

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Group Policy to add the
MaxTokenSize registry entry to multiple
computers
Article • 12/26/2023

This article describes how to use Group Policy to add the MaxTokenSize registry entry to
multiple computers.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 938118

Introduction
On a domain controller that is running Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2, or Windows Server 2012, you can use Group Policy to add the
following registry entry to multiple computers:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entry: MaxTokenSize
Data type: REG_DWORD
Value: 48000

This article describes how to do it, so that you can push this setting to all members of
your domains easily. The process is different, depending on the version of Windows
Server that the domain controller is running.

７ Note

The maximum allowed value of MaxTokenSize is 65535 bytes. However, because of

HTTP's base64 encoding of authentication context tokens, we do not recommend
that you set the maxTokenSize registry entry to a value larger than 48000 bytes.
Starting with Windows Server 2012, the default value of the MaxTokenSize registry
entry is 48000 bytes.

More information
How to configure MaxTokenSize by using Group Policy
Object (GPO) in Windows Server 2003
To add the registry entry to multiple computers in a domain that does not have a
Windows Server 2012-based domain controller, follow these steps:

1. Create an Administrative Template (ADM) file for the MaxTokenSize registry entry.
To do it, follow these steps:

a. Start Notepad.

b. Copy the following text, and then paste the text into Notepad:

CLASS MACHINE

CATEGORY !!KERB

KEYNAME "SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters"
POLICY !!MaxToken
VALUENAME "MaxTokenSize"
VALUEON NUMERIC 48000
VALUEOFF NUMERIC 0
END POLICY

END CATEGORY

[strings]
KERB="Kerberos Maximum Token Size"
MaxToken="Kerberos MaxTokenSize"

７ Note

The value of the MaxTokenSize registry entry is set to 48000. This is the
suggested value.

c. Save the Notepad document as MaxTokenSize.adm in the %windir%\Inf\ folder

on the domain controller that you will use to configure the GPO to deploy the
setting.

d. Exit Notepad.

2. Import the ADM into a GPO and set the MaxTokenSize registry entry to the desired
value. To do it, follow these steps:
 a. Create a new Group Policy Object (GPO) that is linked at the domain level or
that is linked to the organizational unit (OU) that contains your computer
accounts. Or, select a GPO that is already deployed.

b. Open the Group Policy Object Editor. To do it, click Start, click Run, type
gpedit.msc, and then click OK.

c. In the console tree, expand Computer Configuration, expand Administrative

Templates, and then click Administrative Templates.

d. On the Action menu, point to All Tasks, and then click Add/Remove Templates.

e. Click Add.

f. Click to select the MaxTokenSize.adm file that you created in step 1, and then
click Open.

g. Click Close.

h. On the View Menu, click Filtering.

i. Click to clear the Only show policy settings that can be fully managed check
box, and then click OK.

j. Expand Administrative Templates, and then click Kerberos Maximum Token Size.

k. Right-click Kerberos MaxTokenSize in the right-side pane, then click Properties

to open the Properties dialog box.

l. Click Enabled, and then click OK.

７ Note

For the GPO take effect, the GPO change must be replicated to all domain
controllers in the domain, and affected computers must be restarted after
the policy is applied to them.

How to configure the MaxTokenSize registry entry by

using GPO in Windows Server 2008 and in Windows
Server 2008 R2
In Windows Server 2008 domains and in Windows Server 2008 R2 domains, you can use
the Registry Client-Side Extension to deploy the MaxTokenSize registry value to multiple
computers in a domain. To create the MaxTokenSize value setting in a GPO, follow these
steps:

1. Click Start, click Run, type gpmc.msc, and then click OK to open the Group Policy
Management Console.
2. In the Group Policy Management Console, create a new GPO that is linked at the
domain level or that is linked to the OU that contains your computer accounts. Or
you can select a GPO that is already deployed.
3. Right-click the GPO, and then click Edit to open the Group Policy Management
Editor window.
4. Expand Computer Configuration, expand Preferences, and then expand Windows
Settings.
5. Right-click Registry, point to New, and then click Registry Item. The New Registry
Properties dialog box appears.
6. In the Action list, click Create.
7. In the Hive list, click HKEY_LOCAL_MACHINE.
8. In the Key Path list, click
SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
9. In the Value name box, type MaxTokenSize.
10. In the Value type box, click to select the REG_DWORD check box.
11. In the Value data box, type 48000.
12. Next to Base, click to select the Decimal check box.
13. Click OK.

７ Note

For the GPO take effect, the GPO change must be replicated to all domain
controllers in the domain, and affected computers must be restarted after they
apply the policy.

How to configure the MaxTokenSize registry entry by

using GPO in Windows Server 2012
To deploy the value of the MaxTokenSize registry entry in a domain that has Windows
Server 2012-based domain controllers, follow these steps:

1. Open Server Manager, click Tools, and then click Group Policy Management to
open the Group Policy Management console.
2. In the Group Policy Management Console, create a new GPO that is linked at the
domain level or that is linked to the OU that contains your computer accounts. Or,
 select a GPO that is already deployed.
3. Right-click the GPO, and then click Edit to open the Group Policy Management
Editor window.
4. Expand Computer Configuration, expand Policies, and then expand Administrative
Templates.
5. Expand System, and then click Kerberos.
6. Right-click Set maximum Kerberos SSPI context token buffer size on the right side
pane, and then click Edit.
7. Click Enabled, and then type 48000 in the Maximum size box.
8. Click OK.

７ Note

For the GPO take effect, the GPO change must be replicated to all domain
controllers in the domain, and affected computers must be restarted after
they apply the policy.

The Set maximum Kerberos SSPI context token buffer size policy setting is
added in Windows Server 2012 and in Windows 8. The policy setting is
supported in Windows XP, in Windows Server 2003, in Windows Vista, in
Windows Server 2008, in Windows 7, and in Windows Server 2008 R2. To use
this Group Policy setting, you must edit the GPO in a version of Windows
Server 2012 or in Windows 8 that has the RSAT tools installed.

References
For more information about the MaxTokenSize registry entry, click the following article
number to view the article in the Microsoft Knowledge Base:
327825 New resolution for problems with Kerberos authentication when users belong
to many groups

Feedback
Was this page helpful?  Yes  No

Provide product feedback

User-based GPO settings aren't applied
when signing in with shadow principals
Article • 12/26/2023

This article helps resolve an issue in which user-based Group Policy Object (GPO)
settings don't work when signing in using shadow principals.

You have two forests, contoso.net and pam.contoso.com . Pam.contoso.com is an admin

forest that has shadow principals. Selective authentication is configured for the forest
trust. Then, you create a group named ShadowPrincipalGroup that includes all shadow
principals.

When you sign in to domain-joined ( contoso.net ) devices by using shadow principals,

user-based GPOs aren't applied.

This issue occurs because selective authentication is configured as the scope of

authentication for users in the forest trust. When this option is used, Windows doesn't
automatically authenticate users in the trusted forest, and shadow principals aren't part
of the group that is allowed to authenticate. You can remove selective authentication to
work around this issue.

To resolve this issue, add the shadow principal account or the ShadowPrincipalGroup
group to the "Allowed to authenticate" permission on the krbtgt account in the target
user's domain.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Userenv errors occur and events are
logged after you apply Group Policy to
computers that are running Windows
Server 2003, Windows XP, or Windows
2000
Article • 12/26/2023

This article provides a solution to issues where computers on your network can't
connect to the Group Policy objects (GPO) in the Sysvol folders on your network domain
controllers.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 887303

Summary
You may experience one or many errors and events if Group Policy is applied to the
computers on your network. To determine the cause of the issue, you must troubleshoot
the configuration of the computers on your network. Follow these steps to troubleshoot
the cause of the issue:

1. Examine the DNS settings and network properties on the servers and client
computers.
2. Examine the Server Message Block signing settings on the client computers.
3. Make sure that the TCP/IP NetBIOS Helper service, the Net Logon service, and the
Remote Procedure Call (RPC) service are started on all computers.
4. Make sure that Distributed File System (DFS) is enabled on all computers.
5. Examine the contents and the permissions of the Sysvol folder.
6. Make sure that the Bypass traverse checking right is granted to the required
groups.
7. Make sure that the domain controllers aren't in a journal wrap state.
8. Run the dfsutil /purgemupcache command.

Symptoms
You experience one or more of the following symptoms on a computer that is running
Microsoft Windows Server 2003, Microsoft Windows XP, or Microsoft Windows 2000:
Group Policy settings aren't applied to the computers.

Group Policy replication isn't completed between the domain controllers on the
network.

You can't open Group Policy snap-ins. For example, you can't open the Domain
Controller Security Policy snap-in, or the Domain Security Policy snap-in.

If you try to open a Group Policy snap-in, you receive one of the following error
messages:

Failed to open the Group Policy Object. You may not have the appropriate
rights.
Details: The account is not authorized to log in from this station.

You do not have permission to perform this operation.

Details: Access is denied.

Failed to open the Group Policy Object. You may not have the appropriate
rights.
Details: The system cannot find the path specified.

If you try to access shared files on any domain controller, you receive an error
message. This symptom occurs even if you are logged on to the server, and you try
to access a local share. Specifically, this symptom may affect access to a domain
controller's Sysvol share.

If you try to access a file share, you're repeatedly prompted for a password.

If you try to access a file share, you receive an error message that is similar to one
of the following error messages:

\\Server_Name\Share_Name is not accessible. You might not have permission

to use this network resource. Contact the administrator of this server to find
out if you have access permissions.
The account is not authorized to log in from this station.

\\Server_Name\Share_Name is not accessible.

The account is not authorized to log in from this station.

The network path was not found.

If you view the Application log in Event Viewer on Windows XP or Windows Server 2003,
you see events that are similar to the following events:

Event Type: Error

Event Source: Userenv

Event Category: None
Event ID: 1058

Date: Date
Time:
Time
User:
User_Name
Computer:
Computer_Name
Description: Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-
11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC= domainname,DC=com .
The file must be present at the location
<\\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-
945F-00C04FB984 F9}\gpt.ini>. (Error_Message). Group Policy processing aborted.
For more information, see Help and Support Center at
https://support.microsoft.com .

The error message that appears in the Error_Message placeholder in Event ID 1058 may
be any of the following error messages:

The network path was not found.

Access is denied.

Configuration information could not be read from the domain controller,

either because the machine is unavailable, or access has been denied.

Event Type: Error

Event Source: Userenv
Event Category: None
Event ID: 1030
Date:
Date
Time:
 Time
User:
User_Name
Computer:
Computer_Name
Description: Windows cannot query for the list of Group Policy objects. A message
that describes the reason for this was previously logged by the policy engine. For
more information, see Help and Support Center at https://support.microsoft.com .

Typically, if Event ID 1058 and Event ID 1030 occur, they are logged by client computers
and member servers when the computer starts. Domain controllers log these events
every five minutes.

If you view the Application log in Event Viewer on a Windows 2000-based computer,
you see events that are similar to the following events:

Event Type: Error

Event Source: Userenv

Event Category: None

Event ID: 1000
Date:
Date
Time:
Time
User: NT AUTHORITY\SYSTEM
Computer:
Computer_Name
Description: Windows cannot access the registry information at \\
domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-945F-
00C04FB984F 9}\Machine\registry.pol with (Error_Code).

The error code that appears in the Error_Code placeholder in Event ID 1000 may be any
of the following error codes:

5
51
53
1231
1240
1722
Cause
These issues occur if the computers that are on your network can't connect to certain
Group Policy objects. Specifically, these objects are in the Sysvol folders on your
network's domain controllers.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly. So
make sure that you follow these steps carefully. For added protection, back up the
registry before you modify it. Then, you can restore the registry if a problem occurs.
For more information about how to back up and restore the registry, see How to
back up and restore the registry in Windows .

To resolve this issue, you must troubleshoot the configuration of your network to narrow
the cause of the issue, and then correct the configuration. To troubleshoot the possible
cause of this issue, follow these steps:

Step 1: Examine the DNS settings and network properties

on the servers and client computers
In the local area connection properties, Client for Microsoft Networks must be enabled
on all servers and client computers. The File and Printer Sharing for Microsoft Networks
component must be enabled on all domain controllers.

Additionally, every computer on the network must use DNS servers that can resolve SRV
records and host names for the Active Directory forest where the computer is a member.
Typically, a common configuration error is for the client computers to use the DNS
servers that belong to your Internet service provider (ISP).

On all the computers that have logged the Userenv errors, examine the DNS settings
and network properties. Additionally, check these settings on all domain controllers,
whether or not they log Userenv errors.

To verify DNS settings and network properties on Windows XP-based computers in your
network, follow these steps:

1. Select Start, and then select Control Panel.

 2. If Control Panel is set to Category View, select Switch to Classic View.
3. Double-click Network Connections, right-click Local Area Connection, and then
select Properties.
4. On the General tab, click to select the Client for Microsoft Networks check box.
5. Select Internet Protocol (TCP/IP), and then select Properties.
6. If Use the following DNS server addresses is selected, make sure that the IP
addresses for the preferred and alternate DNS servers are the IP addresses of DNS
servers that can resolve SRV records and host names in Active Directory.
Specifically, the computer mustn't use the DNS servers that belong to your ISP. If
the DNS server addresses aren't correct, type the IP addresses of the correct DNS
servers in the Preferred DNS server and Alternate DNS server boxes.
7. Select Advanced, and then select the DNS tab.
8. Click to select the Register this connection's addresses in DNS check box, and
then select OK three times.
9. Start a command prompt. To do it, select Start, select Run, type cmd, and then
select OK.
10. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and
then press ENTER.
11. Restart the computer for your changes to take effect.

To verify DNS settings and network properties on Windows 2000-based computers in

your network, follow these steps:

1. Select Start, point to Settings, and then select Control Panel.

2. Double-click Network and Dial-up Connections.

3. Right-click Local area connection, and then select Properties.

4. On the General tab, click to select the Client for Microsoft Networks check box.

5. If the computer is a domain controller, click to select the File and Printer Sharing
for Microsoft Networks check box.

７ Note

On multi-homed Remote Access servers and Microsoft Internet Security and

Acceleration (ISA) Server-based servers, you can disable the File and Printer
Sharing for Microsoft Networks component for the network adaptor that is
connected to the Internet. However, the Client for Microsoft Networks
component must be enabled for all the server's network adaptors.

6. Select Internet Protocol (TCP/IP), and then click Properties.

 7. If Use the following DNS server addresses is selected, make sure that the IP
addresses for the preferred and alternate DNS servers are the IP addresses of DNS
servers that can resolve SRV records and host names in Active Directory.
Specifically, the computer must not use the DNS servers that belong to your ISP. If
the DNS server addresses aren't correct, type the IP addresses of the correct DNS
servers in the Preferred DNS server and Alternate DNS server boxes.

8. Select Advanced, and then select the DNS tab.

9. Click to select the Register this connection's addresses in DNS check box, and
then select OK three times.

10. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.

11. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and
then press ENTER.

12. Restart the computer.

To verify DNS settings and network properties on Windows Server 2003-based

computers in your network, follow these steps:

1. Select Start, point to Control Panel, and then double-click Network Connections.

2. Right-click the local area connection, and then select Properties.

3. On the General tab, click to select the Client for Microsoft Networks check box.

4. If the computer is a domain controller, click to select the File and Printer Sharing
for Microsoft Networks check box.

７ Note

On multi-homed Remote Access servers and ISA Server-based servers, you

can disable the File and Printer Sharing for Microsoft Networks component for
the network adaptor that is connected to the Internet. However, the Client for
Microsoft Networks component must be enabled for all the server's network
adaptors.

5. Select Internet Protocol (TCP/IP), and then select Properties.

6. If Use the following DNS server addresses is selected, make sure that the IP
addresses for the preferred and alternate DNS servers are the IP addresses of DNS
 servers that can resolve SRV records and host names in Active Directory.
Specifically, the computer mustn't use the DNS servers that belong to your ISP. If
the DNS server addresses aren't correct, type the IP addresses of the correct DNS
servers in the Preferred DNS server and Alternate DNS server boxes.

7. Select Advanced, and then select the DNS tab.

8. Click to select the Register this connection's addresses in DNS check box, and
then select OK three times.

9. Start a command prompt. To do it, select Start, select Run, type cmd, and then
select OK.

10. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and
then press ENTER.

11. Restart the computer for your changes to take effect.

If the client computers in your network are configured to obtain their IP addresses
automatically, make sure that the computer that is running the DHCP service assigns the
IP addresses of DNS servers that can resolve SRV records and host names in the Active
Directory.

To determine what IP addresses a computer is using for DNS, follow these steps:

1. Start a command prompt. To do this, select Start, select Run, type cmd in the Open
box, and then select OK.
2. Type ipconfig /all, and then press ENTER.
3. Note the DNS entries that are listed on the screen.

If computers that are configured to obtain IP addresses automatically aren't using the
correct DNS servers, view the documentation for your DHCP server for information
about how to configure the DNS servers option. Additionally, make sure that each
computer can resolve the IP address of the domain. To do it, type ping
Your_Domain_Name.Your_Domain_Root at a command prompt, and then press ENTER.
Instead, type nslookup Your_Domain_Name.Your_Domain_Root, and then press ENTER.

７ Note

It's expected that this host name will resolve to the IP address of one of the domain
controllers on the network. If the computer can't resolve this name, or if the name
resolves to the wrong IP address, make sure that the forward lookup zone for the
domain contains valid (same as parent folder) Host (A) records.
To make sure that the forward lookup zone for the domain contains valid (same as
parent folder) Host (A) records on a Windows 2000-based computer, follow these steps:

1. On a domain controller that is running DNS, select Start, point to Programs, point
to Administrative Tools, and then select DNS.

2. Expand Your_Server_Name, expand Forward Lookup Zones, and then select the
forward lookup zone for your domain.

3. Look for (same as parent folder) Host (A) records.

4. If a (same as parent folder) Host (A) record doesn't exist, follow these steps to
create one:
a. On the Action menu, select New Host.
b. In the IP address box, type the IP address of the domain controller's local
network adaptor.
c. Click to select the Create associated pointer (PTR) record check box, and then
select Add Host.
d. When you receive the following message, select Yes:

(same as parent folder) is not a valid host name. Are you sure you want to
add this record?

5. Double-click the (same as parent folder) Host (A) record.

6. Verify that the correct IP address is listed in the IP address box.

7. If the IP address in the IP address box isn't valid, type the correct IP address in the
IP address box, and then select OK.

8. Instead, you can delete the (same as parent folder) Host (A) record that contains
an IP address that isn't valid. To delete the (same as parent folder) Host (A) record,
right-click it, and then select Delete.

9. If the DNS server is a domain controller that is also a Routing and Remote Access
server, see Name resolution and connectivity issues on a Routing and Remote
Access Server that also runs DNS or WINS .

10. On all computers where you add, delete, or modify DNS records, type ipconfig
/flushdns at a command prompt, and then press ENTER.

To make sure that the forward lookup zone for the domain contains valid (same as
parent folder) Host (A) records on a Windows Server 2003-based computer, follow
these steps:
 1. On a domain controller that is running DNS, select Start, point to Administrative
Tools, and then select DNS.

2. Expand Your_Server_Name, expand Forward Lookup Zones, and then select the
forward lookup zone for your domain.

3. Look for the (same as parent folder) Host (A) record.

4. If the (same as parent folder) Host (A) record doesn't exist, follow these steps to
create one:
a. On the Action menu, select New Host (A).
b. In the IP address box, type the IP address of the domain controller's local
network adaptor.
c. Click to select the Create associated pointer (PTR) record check box, and then
select Add Host.
d. When you receive the following message, select Yes:

(same as parent folder) is not a valid host name. Are you sure you want to
add this record?

5. Double-click the (same as parent folder) Host (A) record.

6. Verify that the correct IP address is listed in the IP address box.

7. If the IP address is in the IP address box isn't valid, type the correct IP address in
the IP address box, and then select OK.

8. Instead, you can delete the (same as parent folder) Host (A) record that contains
the IP address that isn't valid. To delete the Host (A) record, right-click (same as
parent folder), and then select Delete.

9. If the DNS server is a domain controller that is also a Routing and Remote Access
server, see Name resolution and connectivity issues on a Routing and Remote
Access Server that also runs DNS or WINS .

10. On all computers where you add, delete, or modify DNS records, type ipconfig
/flushdns at a command prompt, and then press ENTER.

Step 2: Examine the Server Message Block signing

settings on the client computers and member servers
The Server Message Block (SMB) signing settings define whether the computers on the
network digitally sign communications. If the SMB signing settings aren't configured
correctly, the client computers, or the member servers, may not be able to connect to
the domain controllers.

For example, SMB signing may be required by the domain controllers, but SMB signing
may be disabled on the client computers. If this issue occurs, Group Policy can't be
applied correctly. So the client computers log user environment (Userenv) errors in the
Application log. Sometimes, the SMB signing settings for the Server service and the
Workstation service on a domain controller may conflict with each other.

For example, SMB signing may be disabled for the domain controller's Workstation
service, but SMB signing is required for the domain controller's Server service. In this
scenario, you can't open one or more of the domain controller's local file shares if you're
logged on to the server. Additionally, you can't open Group Policy snap-ins if you're
logged on to the server.
For more information about how to troubleshoot this problem on a domain controller,
see You cannot open file shares or Group Policy snap-ins on a domain controller.

If Group Policy errors only occur on client computers and member servers, or if you
determine that You cannot open file shares or Group Policy snap-ins on a domain
controller doesn't apply to your situation, continue to troubleshoot the issue.

By default, SMB signing is enabled but isn't required for client communication on client
computers and member servers that are running Windows XP, Windows 2000, or
Windows Server 2003. We recommend that you use the default configuration because
the client computers can use SMB signing when it's possible, but will still communicate
with servers that have SMB signing disabled.

To configure the client computers and member servers so that SMB signing is enabled
but not required, you must change the values for some registry entries. To make the
registry changes on the client computers, follow these steps:

1. Select Start, select Run, type regedit in the Open box, and then select OK.
2. Expand the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

3. In the right pane, right-click enablesecuritysignature, and then select Modify.

4. In the Value data box, type 0, and then select OK.
5. Right-click requiresecuritysignature, and then select Modify.
6. In the Value data box, type 0, and then select OK.
7. Expand the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\paramet

ers

8. In the right pane, right-click enablesecuritysignature, and then select Modify.

9. In the Value data box, type 1, and then select OK.
 10. Right-click requiresecuritysignature, and then select Modify.
11. In the Value data box, type 0, and then select OK.

After you change the registry values, restart the Server and Workstation services. Don't
restart the computers because it may cause group policies to be applied, and the Group
Policy settings may configure conflicting values again.

After you change the registry values and restart the Server and Workstation services on
the affected computers, follow these steps:

1. View the Group Policy settings for the GPO or GPOs that apply to the affected
computer accounts.
2. Make sure that the group policies don't conflict with the required registry settings.
3. Use the Group Policy Object Editor to view the policy settings in the following
folder: Computer Configuration/Windows Settings/Security Settings/Local
Policies/Security Options

On a computer that is running Windows Server 2003, the SMB signing Group Policy
settings have the following names:

Microsoft network server: Digitally sign communications (always)

Microsoft network server: Digitally sign communications (if client agrees)
Microsoft network client: Digitally sign communications (always)
Microsoft network client: Digitally sign communications (if server agrees)

On a computer that is running Windows 2000 Server, the SMB signing Group Policy
settings have the following names:

Digitally sign server communication (always)

Digitally sign server communication (when possible)
Digitally sign client communications (always)
Digitally sign client communications (when possible)

Typically, the SMB signing Group Policy settings are configured as "Not Defined". If you
define the SMB signing Group Policy settings, make sure that you understand how the
settings may affect network connectivity.
For more information about the SMB signing settings, see Client, service, and program
issues can occur if you change security settings and user rights assignments .

If you change the GPO settings on a domain controller that is running Windows 2000
Server, follow these steps:

1. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.
 2. Type secedit /refreshpolicy machine_policy /enforce, and then press ENTER.
3. Restart the affected client computers.
4. Recheck the SMB signing values in the registry on the client computers to make
sure that they didn't change unexpectedly.

If you change the GPO settings on a domain controller that is running Windows Server
2003, follow these steps:

1. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.
2. Type gpupdate /force, and then press ENTER.
3. Restart the affected client computers.
4. Recheck the SMB signing values in the registry on the client computers to make
sure that they did not change unexpectedly.

If the SMB signing values in the registry change unexpectedly after you restart the client
computers, use one of the following methods to view the applied policy settings that
are applied to a client computer:

On a Windows XP-based computer, use the Resultant Set of Policy MMC snap-in
(Rsop.msc). For more information about Resultant Set of Policy, see Resultant Set
of Policy.

On Windows 2000, use the Gpresult.exe command-line tool to examine the Group
Policy results. To do it, follow these steps:

1. Install Gpresult.exe from the Windows 2000 Resource Kit.

2. At a command prompt, type gpresult /scope computer, and then press

ENTER.

3. In the Applied Group Policy Objects section of the output, note the Group
Policy objects that are applied to the computer account.

4. Compare the Group Policy objects that are applied to the computer account
that has the SMB signing policy settings on the domain controller for these
Group Policy objects.

Step 3: Make sure that the TCP/IP NetBIOS Helper service

is started on all computers
All computers on the network must run the TCP/IP NetBIOS Helper service.
To verify that the TCP/IP NetBIOS Helper service is running on a Windows XP-based
computer, follow these steps:

1. Select Start, and then select Control Panel.

2. If Control Panel is in Category View, select Switch to Classic View.
3. Double-click Administrative Tools.
4. Double-click Services.
5. In the Services list, select TCP/IP NetBIOS Helper. Verify that the value under the
Status column is Started. Verify that the value under the Startup Type column is
Automatic. If the Status or the Startup Type values aren't correct, follow these
steps:
a. Right-click TCP/IP NetBIOS Helper, and then select Properties.
b. In the Startup type list, select Automatic.
c. In the Service status area, if the service isn't started, select Start.
d. Select OK.

To verify that the TCP/IP NetBIOS Helper service is running on a Windows Server 2003-
based computer, follow these steps:

1. Select Start, point to Administrative Tools, and then select Services.

2. In the Services list, select TCP/IP NetBIOS Helper. Verify that the value under the
Status column is Started. Verify that the value under the Startup Type column is
Automatic. If the Status or the Startup Type values aren't correct, follow these
steps:
a. Right-click TCP/IP NetBIOS Helper, and then select Properties.
b. In the Startup type list, select Automatic.
c. In the Service status area, if the service isn't started, select Start.
d. Select OK.

To verify that the TCP/IP NetBIOS Helper service is running on a Windows 2000-based
computer, follow these steps:

1. Select Start, point to Programs, point to Administrative Tools, and then select
Services.
2. In the Services list, select TCP/IP NetBIOS Helper Service. Verify that the value
under the Status column is Started. Verify that the value under the Startup Type
column is Automatic. If the Status or the Startup Type values aren't correct, follow
these steps:
a. Right-click TCP/IP NetBIOS Helper Service, and then select Properties.
b. In the Startup type list, select Automatic.
c. In the Service status area, if the service isn't started, select Start.
d. Select OK.
Additionally, make sure that you haven't disabled one or more of the required system
services by using Group Policy objects. View these policy settings by using the Group
Policy Object Editor in the Computer Configuration/Windows Settings/Security
Settings/System Services folder.

On Windows Server 2003 and Windows XP, you can use the Resultant Set of Policy MMC
snap-in (Rsop.msc) to check all applied policy settings that are applied to a computer. To
do it, select Start, select Run, type rsop.msc in the Open box, and then select OK.

On Windows 2000, use the Gpresult.exe command-line tool to examine the Group Policy
results. To do it, follow these steps:

1. Install Gpresult.exe from the Windows 2000 Resource Kit.

2. At a command prompt, type gpresult /scope computer, and then press ENTER.
3. In the Applied Group Policy Objects section of the output, note the Group Policy
objects that are applied to the computer account.
4. Compare the Group Policy objects that are applied to the computer account with
the SMB signing policy settings on the domain controller for these Group Policy
objects.

７ Note

If the TCP/IP NetBIOS Helper service is disabled on many desktops, you can use the
following sample Microsoft Visual Basic script to start the TCP/IP NetBIOS Helper
service on all computers in an organizational unit (OU) at the same time.

Microsoft provides programming examples for illustration only, without warranty either
expressed or implied. This includes, but isn't limited to, the implied warranties of
merchantability or fitness for a particular purpose. This article assumes that you're
familiar with the programming language that is being demonstrated and with the tools
that are used to create and to debug procedures. Microsoft support engineers can help
explain the functionality of a particular procedure, but they won't modify these
examples to provide added functionality or construct procedures to meet your specific
requirements.

VB

Set objDictionary = CreateObject("Scripting.Dictionary")

i = 0
Set objOU = GetObject("LDAP://OU=Computers, OU=OUName, OU=OUName, DC=OUName,
DC=OUName,DC=CompanyName,
DC=com")
objOU.Filter = Array("Computer")
For Each objComputer In objOU
 objDictionary.Add i, objComputer.CN
i = i + 1
Next
For Each objItem In objDictionary
strComputer = objDictionary.Item(objItem)
Set objWMIService =
GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer &
"\root\cimv2")

Set colServices = objWMIService.ExecQuery _

("Select * from Win32_Service where Name = 'LmHosts'")
For Each objService In colServices
If objService.StartMode = "Disabled" Then
objService.Change( , , , , "Automatic")
End If
Next
Next

Step 4: Make sure that Distributed File System (DFS) is

enabled on all computers
All domain controllers must run the Distributed File System service because the Sysvol
share is a DFS volume. Additionally, the DFS client must be enabled in the registry on all
computers.

To make sure that the Distributed File System service is running on Windows Server
2003-based domain controllers, follow these steps:

1. Select Start, point to Administrative Tools, and then select Services.

2. In the Services list, select Distributed File System service. Verify that the value
under the Status column is Started. Verify that the value under the Startup Type
column is Automatic. If the Status or the Startup Type values aren't correct, follow
these steps:
a. Right-click Distributed File System, and then select Properties.
b. In the Startup type list, select Automatic.
c. In the Service status area, if the service isn't started, select Start.
d. Select OK.

To make sure that the Distributed File System service is running on Windows 2000
Server-based domain controllers, follow these steps:

1. Select Start, point to Programs, point to Administrative Tools, and then select
Services.
2. In the Services list, select Distributed File System service. Verify that the value
under the Status column is Started. Verify that the value under the Startup Type
 column is Automatic. If the Status or the Startup Type values aren't correct, follow
these steps:
a. Right-click Distributed File System, and then select Properties.
b. In the Startup type list, select Automatic.
c. In the Service status area, if the service isn't started, select Start.
d. Select OK.

To make sure that the Distributed File System client is enabled on all client computers,
follow these steps:

1. Select Start, select Run, type regedit in the Open box, and then select OK.
2. Expand the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup

3. Select Mup, and then in the right pane, search for a DWORD value entry that is
named DisableDFS.
4. If the DisableDFS entry exists and the value data is 1, double-click DisableDFS. In
the Value data box, type 0, and then select OK. If the DisableDFS value data is
already 0, or if the DisableDFS entry doesn't exist, don't make any change.
5. Quit Registry Editor.
6. If you changed the DisableDFS value data, restart the computer.

Step 5: Examine the contents and the permissions of the

Sysvol folder
By default, the Sysvol folder is located in the %systemroot% folder. The Sysvol folder
contains the domain's Group Policy objects, the Sysvol and Netlogon shares, and the File
Replication service (FRS) staging folder.

If the permissions on the Sysvol folder or the Sysvol share are too restrictive, group
policies can't be applied correctly, and cause user environment (Userenv) errors.
Additionally, Userenv errors may occur if the Sysvol share or Group Policy objects are
missing.
To make sure that the Sysvol share is available, run the net share command at a
command prompt on each domain controller. To do it, follow these steps:

1. Select Start, select Run, type cmd in the Open box, and then select OK.
2. Type net share, and then press ENTER.
3. Locate SYSVOL and NETLOGON in the list of folders.

If the Sysvol or Netlogon shares are missing from one or more domain controllers, you
must troubleshoot the cause of the problem.
For more information about how to troubleshoot the missing Sysvol and Netlogon
shares in Windows 2000 Server, see Troubleshooting missing SYSVOL and NETLOGON
shares on Windows domain controllers .

For more information about how to rebuild the Sysvol share in Windows Server 2003,
see How to rebuild the SYSVOL tree and its content in a domain .

After you make sure that the Sysvol share is available, make sure that the Sysvol folder,
the Sysvol share, and the root folder of the volume that contains the Sysvol folder are
configured with the correct permissions.

Additionally, on Windows 2000 Server, the Everyone group must be granted Full Control
permission on the root folder of the volume that contains the Sysvol folder. On
Windows Server 2003, the Everyone group must be granted the Read & Execute special
permission to "This folder only," and the domain\Users group must be granted the
following standard permissions:

Read & Execute

List Folder Contents
Read

Additionally, on Windows Server 2003, the domain\Users group must have the following
special permissions:

Read & Execute permission to "This folder, subfolders and files."

Create Folder / Append Data permission to "This folder and subfolders."
Create Files / Write Data permission to "Subfolders only."

After you verify the Sysvol permissions, make sure that the Sysvol folder contains the
required Group Policy objects. To look for the required Group Policy objects, use the
Gpotool.exe program from the Windows 2000 or the Windows Server 2003 Resource Kit.

If you run the Gpotool.exe program without any options, it scans for all the Group Policy
objects on all domain controllers in the domain. If you include the /checkacl switch, the
tool also scans the Sysvol access control list (ACL). For detailed output when you run the
Gpotool.exe program, use the /verbose switch.

Instead, you can manually verify the individual GPO in the SYSVOL folder. For example, if
the description in the Userenv 1058 event lists the name of a GPO, you can manually
verify the individual GPO in the SYSVOL folder. You can do this to make sure that it
contains a USER folder, a MACHINE folder, and a Gpt.ini file. To manually verify the
individual GPO in the SYSVOL folder, follow these steps:

1. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.
 2. Type at Time/interactive/next: cmd.exe, and then press ENTER, where Time is 1 or
2 minutes later than the present time, and is written in 24-hour time format. For
example, 3 minutes after 1:00 p.m. would be 13:03 in 24-hour time format.
3. At the time that you specify in the previous command, a new Command Prompt
window opens. Type net use
j:\\domainname.com\sysvol\domainname.com\Policies\{GUID}, and then press
ENTER, where GUID is the GUID of the GPO that is in the Userenv event
description. For example, if the Userenv 1058 event description says, "The file must
be present at the location
<\\Domain_Name.com\sysvol\Domain_Name.com\Policies\{31B2F340-016D-
11D2-945F-00C04FB984 F9}\gpt.ini>," the GUID that you would use in the
command is 31B2F340-016D-11D2-945F-00C04FB984F9.
4. Type dir j:\*.*, and then press ENTER.
5. Verify that a USER folder, a MACHINE folder, and a Gpt.ini file are listed in the
folder listing for the I drive. If any one of these folders and files are missing, the
computers on the network are likely to log Userenv errors in the Application log.

If one or more Group Policy objects are missing from the Sysvol folder, run the Windows
Server 2003 Default Group Policy Restore Utility (Dcgpofix.exe), or the Windows 2000
Default Group Policy Restore Tool (Recreatedefpol.exe), to re-create the default Group
Policy objects.

The Dcgpofix.exe program is included with Windows Server 2003. For additional
information about the Dcgpofix.exe program, run the dcgpofix /? command at a
command prompt.

Make sure to set the recommended exclusions when you're scanning the Sysvol drive
with antivirus software. Scanning with antivirus software can block access to the
required files, such as the Gpt.ini file. You must configure these exclusions for all real-
time, scheduled, and manual antivirus scans.

Step 6: Make sure that the Bypass traverse checking right

is granted to the required groups
The Bypass traverse checking right must be granted to the following groups on the
domain controllers:

Administrators
Authenticated Users
Everyone
Pre-Windows 2000 Compatible Access
To verify that the Bypass traverse checking right has been granted on a Windows Server
2003-based domain controller, follow these steps:

1. Select Start, point to Administrative Tools, and then select Domain Controller
Security Policy.
2. Expand Local Policies, and then select User Rights Assignment.
3. Double-click Bypass traverse checking.
4. Click to select the Define these policy settings check box.
5. Verify that the Administrators, Authenticated Users, Everyone, and Pre-Windows
2000 Compatible Access groups are listed for this policy setting. If any of these
groups are missing, follow these steps:
a. Select Add User or Group.
b. In the User and group names box, type the name of the missing group, and
then select OK.
6. Select OK to close the policy setting.
7. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.
8. Type gpupdate /force, and then press ENTER.

To verify that the Bypass traverse checking right has been granted on a Windows 2000
Server-based domain controller, follow these steps:

1. Select Start, point to Programs, point to Administrative Tools, and then select
Domain Controller Security Policy.
2. Expand Security Settings, expand Local Policies, and then select User Rights
Assignment.
3. Double-click Bypass traverse checking.
4. Click to select the Define these policy settings check box.
5. Verify that the Administrators, Authenticated Users, Everyone, and Pre-Windows
2000 Compatible Access groups are listed for this policy setting. If any one of these
groups are missing, follow these steps:
a. Select Add.
b. In the User and group names box, type the name of the missing group, and
then select OK.
6. Select OK to close the policy setting.
7. Start a command prompt. To do it, select Start, select Run, type cmd in the Open
box, and then select OK.
8. Type secedit /refreshpolicy machine_policy /enforce, and then press select.

Step 7: Make sure that the domain controllers aren't in a

journal wrap state
To see if a domain controller is in a journal wrap state, view the File Replication service
log in Event Viewer, and search for NTFRS event ID 13568. Event ID 13568 is similar to
the following Event ID:
If NTFRS event ID 13568 is logged on a domain controller, for more information about
how to troubleshoot journal wrap errors, see How to troubleshoot journal_wrap errors
on Sysvol and DFS replica sets.

Step 8: Run the Dfsutil /PurgeMupCache command

Run the Dfsutil.exe program with the /PurgeMupCache switch to flush the local DFS/MUP
cached information. The Dfsutil.exe program is included in the Windows 2000 Server
Support Tools and the Windows Server 2003 Support Tools.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

User GPP Scheduled Task item fails to
apply and logs event ID: 4098 with
0x80070005 Access is denied
Article • 12/26/2023

This article provides a solution to an issue where User Group Policy Preference (GPP)
Scheduled Task item fails to apply.

Applies to: Windows Server 2012 R2

Original KB number: 2447414

Symptoms
You configure the following User Group Policy Preference (GPP) item in a Windows
2008/2008 R2 based Active Directory Domain.

User Configuration\Preferences\Control Panel Settings\Scheduled

Tasks\New\"Scheduled Task (Windows Vista and later)"

Under the Common Settings tab, select option Run in logged-on user's security
context (user policy option). After the Group Policy is applied to a user, you find
that the preference item doesn't take effect.

Additionally, you see the following event log in the Application log:

Additionally if you enable Group Policy tracing for GPP Scheduled Tasks Client Side
Extension, you'll see the following messages logged in the GPP User log file:

<DateTime> [pid=0x3a0,tid=0x8c8] Starting class <TaskV2> - <GPP item name>.

<DateTime> [pid=0x3a0,tid=0x8c8] Set user security context.
<DateTime> [pid=0x3a0,tid=0x8c8] Adding child elements to RSOP.
<DateTime> [pid=0x3a0,tid=0x8c8] WorkItem.Init [hr = 0x80070005 "Access is
denied."]
<DateTime> [pid=0x3a0,tid=0x8c8] Properties handled. [hr = 0x80070005 "Access is
denied."] <DateTime> [pid=0x3a0,tid=0x8c8] Set system security context.
<DateTime> [pid=0x3a0,tid=0x8c8] EVENT : The user '<GPP item name>'
preference item in the '<GPO name> {GPO GUID}' Group Policy object did not apply
because it failed with error code '0x80070005 Access is denied.'%100790273
<DateTime> [pid=0x3a0,tid=0x8c8] Error suppressed. [hr = 0x80070005 "Access is
denied."]
 <DateTime> [pid=0x3a0,tid=0x8c8] Completed class <TaskV2> - <GPP item name>.
<DateTime> [pid=0x3a0,tid=0x8c8] Completed class <ScheduledTasks>.

You can enable GPP tracing through group policy:

Computer Configuration\Policies\Administrative Templates\System\Group

Policy\Logging and Tracing\Configure Schedulled Tasks preference logging and

tracing

When configured, the log file will be created in:

%SystemDrive%\ProgramData\GroupPolicy\Preference\Trace\User.log

Cause
The User GPP Scheduled Tasks item wasn't designed to run under the currently logged
on users security context AND must be applied in the default system security context.

Resolution
To avoid this issue, don't enable the Run in logged-on user's security context (user
policy option) Common option when configuring user GPP Scheduled Tasks items.

The security context under which the Scheduled Task will run once it has been deployed
can be specified in the General settings tab when creating the User GPP Scheduled Task
item:

User Configuration\Preferences\Control Panel Settings\Scheduled

Tasks\New\"Scheduled Task (Windows Vista and later)"

General:
Security Options -> "When running the task, use the following user account:"

By default, it's set to: %LogonDomain%\%LogonUser%

It's where the security context under which the scheduled task will run should be
configured.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server stops responding on
startup when applying Group Policy
Article • 12/26/2023

This article helps resolve an issue in which Windows Server stops responding on startup
when applying Group Policy if System Monitor (Sysmon) is installed.

Sysmon driver (SysmonDrv.sys) intercepts the transition from user mode to kernel and
then sends work to its user mode process Sysmon64.exe. Most Sysmon64.exe threads are
stuck waiting on a critical section. The critical section owner is waiting on a Local
Security Authority Subsystem Service (LSASS) thread. However, the LSASS owner thread
is trying to acquire a different critical section. Many other LSASS threads are blocked
waiting on this critical section.

The critical section owning thread is blocked in SysmonDrv's kernel to the user mode
communication to process Sysmon64.exe, which is observed to be stuck waiting on the
LSASS thread. This results in a deadlock.

You can resolve this issue by upgrading Sysmon to the latest version, or work around
this issue by disabling FileBlockShredding .

Disable FileBlockShredding
To work around this issue, follow these steps:

1. Find the XML config file by running the following cmdlet:

PowerShell

PS C:\Sysmon> .\Sysmon64.exe -c

Sysmon (internal) v15.00 - Monitors system events

By Mark Russinovich and Thomas Garnier
Copyright (C) 2014-2023 Microsoft Corporation
Using libxml2. libxml2 is Copyright (C) 1998-2012 Daniel Veillard. All
Rights Reserved.
Sysinternals - www.sysinternals.com (http://www.sysinternals.com/)

Current configuration:
- Service name: Sysmon64
- Driver name: SysmonDrv
- Config file: .\file-delete.xml
 2. Eliminate the following condition:

XML

<FileBlockShredding onmatch="...">
...
</FileBlockShredding>

Feedback
Was this page helpful?  Yes  No

Provide product feedback

WMI Group Policy filters that compare
Win32_OperatingSystem BuildNumber
don't work as expected
Article • 12/26/2023

This article provides a solution to an issue where Windows Management

Instrumentation (WMI) Group Policy filters that compare Win32_OperatingSystem
BuildNumber don't work as expected in Windows 10.

Applies to: Windows 10 - all editions

Original KB number: 3119213

Symptoms
Consider the following scenario:

You want Group Policy to apply to Windows 8.1 and later versions of Windows.

You want to use Win32_OperatingSystem BuildNumber to do this.

You create the following WMI filter, based on known build numbers of Windows
versions:

Console

"Select BuildNumber from Win32_OperatingSystem WHERE BuildNumber >=

9200 "

ﾉ Expand table

Build number Windows version

9200 Windows 8

9600 Windows 8.1

10240 Windows 10

10586 Windows 10, version 1511

14393 Windows 10, version 1607

15063 Windows 10, version 1703

 Build number Windows version

16299 Windows 10, version 1709

17134 Windows 10, version 1803

17763 Windows 10, version 1809

18362 Windows 10, version 1903

In this scenario, although you would expect the WMI filter to cause the Group Policy
setting to apply to build number 9200 and later builds, Windows 10 builds are excluded.

Cause
This issue occurs because the data type for BuildNumber is String and not Integer.
Therefore, 10*** < 9600.

Resolution
To fix this issue, use a filter that resembles the following example.

７ Note

There are several ways to force the string compare to return the result that you
want. You can use any method that you prefer. The example is fully functional.

Console

Select BuildNumber from Win32_OperatingSystem WHERE BuildNumber >= 10000 AND

BuildNumber LIKE "%[123456789][0123456789][0123456789][0123456789]
[0123456789]%" OR BuildNumber >= 9200 AND BuildNumber LIKE "%[123456789]
[0123456789][0123456789][0123456789]%"

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
User Experience issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

How To Configure Group Policies to Set
Security for System Services
Article • 12/26/2023

This article describes how to configure Group Policies to Set Security for System
Services.

Applies to: Windows Server 2003

Original KB number: 324802

Summary
This article describes how to use Group Policy to set security for system services for an
organizational unit in Windows Server 2003.

When you implement security on system services, you can control who can manage
services on a workstation, member server, or domain controller. Currently, the only way
to change a system service is through a Group Policy computer setting.

If you implement Group Policy as the Default Domain Policy, the policy is applied to all
computers in the domain. If you implement Group Policy as the Default Domain
Controllers policy, the policy applies only to the servers in the domain controller's
organizational unit. You can create organizational units that contain workstation
computers to which policies can be applied. This article describes the steps to
implementing a Group Policy on an organizational unit to change permissions on
system services.

How to Assign System Service Permissions

1. Click Start, point to Administrative Tools, and then click Active Directory Users and
Computers.

2. Right-click the domain to which you want to add the organizational unit, point to
New, and then click Organizational Unit.

3. Type a name for the organizational unit in the Name box, and then click OK.

The new organizational unit is listed in the console tree.

4. Right-click the new organizational unit that you created, and then click Properties.
 5. Click the Group Policy tab, and then click New. Type a name for the new Group
Policy object (for example, use the name of the organizational unit for which it is
implemented), and then press ENTER.

6. Click the new Group Policy object in the Group Policy Objects Links list (if it is not
already selected), and then click Edit.

7. Expand Computer Configuration, expand Windows Settings, expand Security

Settings, and then click System Services.

8. In the right pane, double-click the service to which you want to apply permissions.

The security policy setting for that specific service is displayed.

9. Click to select the Define this policy setting check box.

10. Click Edit Security.

11. Grant the appropriate permissions to the user accounts and groups that you want,
and then click OK.

12. Under Select service startup mode, click the startup mode option that you want,
and then click OK.

13. Close the Group Policy Object Editor, click OK, and then close the Active Directory
Users and Computers tool.

７ Note

You must move the computer accounts that you want to manage into the
organizational unit. After the computer accounts are contained in the
organizational unit, the authorized user or groups can manage the service.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Information about Group Policy
Preferences events
Article • 12/26/2023

This article provides some information about Group Policy Preferences Events.

Applies to: Windows Server 2012 R2

Original KB number: 2002507

Summary
Group Policy Preferences (GPP) allow you to specify computer and user configuration
settings. These settings allow granular configuration not available using regular Group
Policy. GPP also provides filtering of settings using item-level targeting that allows for
granular application of settings to a subset of users or computers.

You may want to know about the possible events that can be logged by a component, in
order to categorize them properly in system management solutions. Below you will find
the list of events for Group Policy Preferences.

More information
Group Policy Preferences events are written to the Application log. Informational events
are only logged when the relevant Group Policy settings are enabled. The path to the
settings per preference area is:

Computer Configuration\Policies\Administrative Templates\System\Group

Policy\Logging and tracing

The possible event sources of these events are:

Group Policy Environment

Group Policy Local Users and Groups
Group Policy Device Settings
Group Policy Network Options
Group Policy Drive Maps
Group Policy Folders
Group Policy Network Shares
Group Policy Files
Group Policy Data Sources
 Group Policy Ini Files
Group Policy Services
Group Policy Folder Options
Group Policy Scheduled Tasks
Group Policy Registry
Group Policy Applications
Group Policy Printers
Group Policy Shortcuts
Group Policy Internet Settings
Group Policy Start Menu Settings
Group Policy Regional Options
Group Policy Power Options

Group Policy Preferences events

ﾉ Expand table

Events Severity Message

MessageId=0x1000 Success The %1 '%2' preference item in the '%3' Group Policy object
(4096) applied successfully.

MessageId=0x1002 Warning The %1 '%2' preference item in the '%3' Group Policy object
(4098) did not apply because it failed with error code
'%4'%%100790273

MessageId=0x1003 Warning The client-side extension could not log RSoP data because it
(4099) failed with error code '%1'.

MessageId=0x1004 Success Service stopped.

(4100)

MessageId=0x1005 Success The %1 '%2' preference item in the '%3' Group Policy object
(4101) was successfully removed.

MessageId=0x1006 Warning ODBC diagnostic (%1), %2

(4102)

MessageId=0x1007 Warning The client-side extension could not %1 %2 preference items

(4103) for the '%3' Group Policy object because Windows is shutting
down or the user is logging out.

MessageId=0x1009 Warning The %1 '%2' preference item in the '%3' Group Policy object
(4105) did not apply because a targeting item failed with error code
'%4'%%100790273.
Events Severity Message

MessageId=0x100A Warning The %1 '%2' preference item in the '%3' Group Policy object
(4106) did not apply because its targeting item failed with error code
'%4'%%100790273.

MessageId=0x1013 Success Service started.

(4115)

MessageId=0x2000 Warning The %1 '%2' preference item in the '%3' Group Policy object
(8192) did not apply because it failed with error code
'%4'%%100790275.

MessageId=0x2001 Warning The %1 '%2' preference item in the '%3' Group Policy object
(8193) did not apply because its targeting item failed with error code
'%4'%%100790275.

MessageId=0x2002 Warning The client-side extension could not %1 %2 policy settings for
(8194) '%3' because it failed with error code '%4'%%100790275 .

In Windows XP and Windows Server 2003 versions of Group

Policy Preferences, Event ID 8194 has a Severity of Error
instead of Warning.

MessageId=0x2004 Warning The client-side extension caught the unhandled exception

(8196) '%1' inside: '%2'%%100790275 .

MessageId=0x2006 Warning The %1 '%2' preference item in the '%3' Group Policy object
(8198) was not removed because it failed with error code
'%4'%%100790275 .

MessageId=0x2014 Warning The %1 '%2' preference item in '%3' Group Policy object did
(8212) not apply because a targeting item failed with error code
'%4'%%100790275 .

MessageId=0x201D Warning An error occured while writing to the trace file. Error %1.
(8221)

MessageId=0x2023 Warning The process threw exception %1 inside %2.

(8227)

MessageId=0x2024 Warning Error %1 obtaining ODBC diagnostic message.

(8228)

MessageId=0x2025 Warning ODBC error %1, %2.

(8229)

MessageId=0x1A00 Success A hidden filter did not pass.

(6656)

MessageId=0xF001 Success This error was suppressed.%0

 Events Severity Message

(61441)

MessageId=0xF003 Success See trace file for more details.%0

(61441)

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
Group Policy issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DFSR SYSVOL fails to migrate or
replicate, SYSVOL not shared, Event IDs
8028 or 6016
Article • 12/26/2023

This article provides a solution to issues where Distributed File System Replication
(DFSR) SYSVOL fails to migrate or replicate, or SYSVOL isn't shared.

Applies to: Windows Server 2012 R2

Original KB number: 2567421

Symptoms
Scenario 1: After starting a SYSVOL migration from File Replication Service (FRS) to DFSR,
no domain controllers enter the Prepared phase, and remain stuck at Preparing. This
issue continues even after you verify that Active Directory (AD) replication has
converged on all domain controllers. The issue continues even on DCs in the same AD
site as the PDCE, where AD replication occurs every 15 seconds and where you have run
DFSRDIAG.EXE POLLAD on all the DCs. Running the /GETMIGRATIONSTATE reporting
command shows:

DFSRMIG.EXE /GETMIGRATIONSTATE

Domain Controller (Local Migration State) - DC Type

===================================================
2008R2-MIG-01 ('Preparing') - Primary DC
2008R2-MIG-02 ('Preparing') - Writable DC
Migration has not yet reached a consistent state on all Domain Controllers.
State information might be stale due to AD latency.

Examining the DFS Replication event sign in the Primary Domain Controller (PDC)
Emulator shows:

Output

Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 8028
 Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: 2008r2-mig-01.cohowinery.com
Description:
DFSR Migration was unable to transition to the 'PREPARED' state for Domain
Controller 2008R2-MIG-01. DFSR will retry the next time it polls the Active
Directory. To force an immediate retry, execute the command 'dfsrdiag
/pollad'.
Additional Information:
Domain Controller: 2008R2-MIG-01
Error: 5 (Access is denied.)

Examining the DFSR Debug sign in the PDCE shows:

Output

<DateTime> 1524 CFAD 2836 Config::AdObjectEditor::AddObject Add cn=DFSR-

LocalSettings,CN=2008R2-MIG-01,OU=Domain
Controllers,DC=cohowinery,DC=com
<DateTime> 1524 ADWR 633
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Local settings
object already exists.
<DateTime> 1524 ADWR 655
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Got Local
Setting's SD for adding ACE
<DateTime> 1524 ADWR 678
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Going to set
new SD
<DateTime> 1524 CFAD 2570 [ERROR] Config::AdAttrEditor::ModifyValue Failed
to ldap_modify_s(). dn:cn=DFSR-LocalSettings,CN=2008R2-MIG-01,OU=Domain
Controllers,DC=cohowinery,DC=com Error:Insufficient Rights
<DateTime> 1524 SYSM 586 [ERROR] Migration::SysvolMigrationTask::Step
[MIG] Failed Migration task.Error:
+ [Error:5(0x5) Migration::SysVolMigration::Migrate migrationserver.cpp:1200
1524 W Access is denied.]
+ [Error:5(0x5) Migration::SysVolMigration::StepToNextStableState
migrationserver.cpp:1271 1524 W Access is denied.]
+ [Error:5(0x5) Migration::SysVolMigration::Prepare migrationserver.cpp:1431
1524 W Access is denied.]
+ [Error:5(0x5) Migration::SysVolMigration::CreateLocalAdObjects
migrationserver.cpp:2694 1524 W Access is denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolMigrationLocalObjects
adwriterserver.cpp:1965 1524 W Access is denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc
adwriterserver.cpp:726 1524 W Access is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ReplaceValue ad.cpp:2702 1524 W Access
is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1524 W Access
is denied.]
 + [Error:50(0x32) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1524 U
Insufficient Rights]

Scenario 2: A domain already replicates SYSVOL using DFSR. When a new DC is

promoted, it fails to replicate SYSVOL , and the SYSVOL and NETLOGON shares aren't
created.

Examining the DFS Replication event sign in that new DC shows:

Output

Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 6016
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: 2008-R2-TSPDC2.tailspintoys.com
Description:
The DFS Replication service failed to update configuration in Active
Directory Domain Services. The service will retry this operation
periodically.

Additional Information:
Object Category: msDFSR-LocalSettings
Object DN: CN=DFSR-LocalSettings,CN=2008-R2-TSPDC2,OU=Domain
Controllers,DC=tailspintoys,DC=com**
Error: 5 (Access is denied.)
Domain Controller: 2008-R2-TSPDC1.tailspintoys.com
Polling Cycle: 60

Examining the DFSR Debug sign in that DC shows:

Output

<DateTime> 1712 CFAD 2836 Config::AdObjectEditor::AddObject Add cn=DFSR-

LocalSettings,CN=2008-R2-TSPDC2,OU=Domain Controllers,DC=tailspintoys,DC=com
<DateTime> 1712 ADWR 633
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Local
settings object already exists.
<DateTime> 1712 ADWR 655
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Got Local
Setting's SD for adding ACE
<DateTime> 1712 ADWR 678
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Going to set
new SD
<DateTime> 1712 CFAD 2570 [ERROR] Config::AdAttrEditor::ModifyValue Failed
to ldap_modify_s(). dn:cn=DFSR-LocalSettings,CN=2008-R2-TSPDC2,OU=Domain
Controllers,DC=tailspintoys,DC=com Error:Insufficient Rights
 <DateTime> 1712 CFAD 11508 [ERROR] Config::AdReader::Read [SYSVOL] (Ignored)
Failed to create SysVol objects, Error:
+ [Error:5(0x5) Config::AdWriter::CreateSysVolObjects
adwriterserver.cpp:1360 1712 W Access is denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolObjectsWithParams
adwriterserver.cpp:1457 1712 W Access is denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc
adwriterserver.cpp:726 1712 W Access is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ReplaceValue ad.cpp:2702 1712 W Access
is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1712 W Access
is denied.]
+ [Error:50(0x32) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1712 U
Insufficient Rights]

Examining the DFSR debug sign in the PDCE shows:

Output

<DateTime> 1792 CFAD 6160 [ERROR]

Config::AdSnapshot::BuildPartnersSubTree Failed to create computer tree for
partner:CN=2008-R2-TSPDC2,CN=Topology,CN=Domain System Volume,CN=DFSR-
GlobalSettings,CN=System,DC=tailspintoys,DC=com, Error:
+ [Error:1168(0x490) Config::AdSnapshot::BuildPartnerComputerSubTree
ad.cpp:6018 1792 W Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::BuildLocalSettingsTree ad.cpp:6408
1792 W Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::GetSubscriber ad.cpp:4112 1792 W
Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::GetSubscriber ad.cpp:4108 1792 W
Element not found.]

Cause
The default user rights assignment "Manage Auditing and Security Log"
(SeSecurityPrivilege) has been removed from the built-in Administrators group. Removal
of this user right from Administrators on domain controllers isn't supported. It will cause
DFSR SYSVOL migration to fail. DFSR migration and must be run by a user who is a
member of the built-in Administrators group in that domain. All DCs are automatically
members of the built-in Administrators group.

Resolution
To resolve the issue, follow all steps in the order, using an elevated CMD prompt while
running as a Domain Admin:
Scenario 1:

1. Determine which security group policy is applying this setting to the DCs by
running on the PDCE:

Console

GPRESULT.EXE /H secpol.htm

2. Open secpol.htm in a web browser then select Show All. Search for the entry
Manage Auditing and Security Log. It will list the group policy that is applying this
setting.

3. Using GPMC.MSC, edit that group policy to include the group Administrators.

4. Allow AD and SYSVOL replication to converge on all DCs. On the PDCE, run:

Console

GPUPDATE /FORCE

5. Sign out the PDCE and log back on, to update your security token with the user
right assignment.

6. Run:

Console

DFSRMIG.EXE /CREATEGLOBALOBJECTS

7. Allow AD and SYSVOL replication to converge on all DCs. On the PDCE, run:

Console

DFSRDIAG.EXE POLLAD
DFSRMIG.EXE /GETMIGRATIONSTATE

8. Validate that some or all of the DCs have reached the Prepared state and are ready
to redirect. At this point, you can proceed with your migration normally. See the
More information section below.

Scenario 2:
 1. Determine which security group policy is applying this setting to the DCs by
running on the PDCE:

Console

GPRESULT.EXE /H secpol.htm

2. Open secpol.htm in a web browser, then select Show All. Search for the entry
Manage Auditing and Security Log. It will list the group policy that is applying this
setting.

3. Using GPMC.MSC, edit that group policy to include the group Administrators.

4. Allow AD and SYSVOL replication to converge on all DCs. On the affected DC, run:

Console

GPUPDATE /FORCE

5. Restart the DFSR service on that DC.

6. Validate that the DC now shares SYSVOL and NETLOGON, and replicates SYSVOL
inbound.

The sysvol may not be shared on any of the DCs. Which will prevent you from editing
or applying Group Policy. As a workaround you can manually share the sysvol , edit the
User Right "Manage Auditing and Security Log" and force a GP update.

Steps:

1. Manually share the sysvol - Edit this registry value Key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\parameters
Value SysvolReady = 1
run net share to make sure the sysvol is shared out.

2. Open the policy and add the user or group to the "manage auditing and security
log" user right.

3. Run:

Console

gpupdate force.
 ７ Note

You may have to share the sysvol again at step 3 as a background process
from SYSVOL migration may unshared it before you're done editing the policy

4. Continue with scenario 1 or 2 as noted above.

It's possible for DFSRMIG to successfully update AD but fail to update the Registry. If the
AD updates are done successfully to create the sysvol replication group but the registry
changes the DFSR service aren't made because of missing user rights, you'll only see
events 8010 that the migration is underway.

More information
It's normal for DCs to remain the Preparing state for an extended period of time during
a migration, especially in larger environments where AD replication may take several
hours or days to converge. It isn't normal for them to remain in that state even after AD
replication has reached those DCs and 15 minutes has passed for DFSR AD Polling.

Don't share SYSVOL and NETLOGON manually to work around this issue. Don't set
SYSVOLREADY=1 to work around this issue. Doing so will cause the DC to contact itself for

group policy. Since it can't populate its SYSVOL , any changes to fix the user rights won't
be applied.

For more information on lowering the AD Replication convergence time using Inter-site
Change Notification, see Appendix B - Procedures Reference.

For more information on SYSVOL migration from FRS to DFSR, see Migrate SYSVOL
replication to DFS Replication .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"The Permissions for This GPO in the
sysvol folder Are Inconsistent with
Those in Active Directory" Message
When You Run GPMC
Article • 12/26/2023

This article provides help to fix errors that occur when you run Group Policy
Management Console (GPMC).

Applies to: Windows Server 2012 R2

Original KB number: 828760

Symptoms
When you run GPMC in a Microsoft Windows Server domain, and then you click either
Default Domain Policy or Default Domain Controllers Policy, you receive one of the
following messages:

If you have permissions to modify security on the Group Policy objects (GPOs), you
receive the following message:

The permissions for this GPO in the sysvol folder are inconsistent with those in
Active Directory. It is recommended that these permissions be consistent. To
change the permissions in SYSVOL to those in Active Directory, click OK

If you do not have permission to modify security on the Group Policy objects
(GPOs), you receive the following message:

The permissions for this GPO in the sysvol folder are inconsistent with those in
Active Directory. It is recommended that these permissions be consistent.
Contact an administrator who has rights to modify security on this GPO.

Cause
This issue occurs because the access control list (ACL) on the Sysvol portion of the
Group Policy object is set to inherit permissions from the parent folder.
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section of this article.

Workaround
If you have permissions to modify security on the default GPOs, click OK in response to
the message that is described in the "Symptoms" section. This action modifies the ACLs
on the Sysvol portion of the Group Policy object and makes them consistent with the
ACLs on the Active Directory component. In this case, Group Policy will remove the
inheritance attribute in the Sysvol folder

More information
Each Group Policy object (GPO) is stored partly in the Sysvol folder on the domain
controller and partly in the Active Directory directory service. GPMC, Group Policy Object
Editor, and the old Group Policy user interface that is provided in the Active Directory
snap-ins present and manage a GPO as a single unit. For example, when you set
permissions on a GPO in GPMC, GPMC sets permissions on objects both in Active
Directory and in the Sysvol folder. For each GPO, the permissions in Active Directory
must be consistent with the permissions in the Sysvol folder. You must not change these
separate objects outside GPMC and Group Policy Object Editor. If you do so, this may
cause Group Policy processing on the client to fail, or certain users who generally have
access may no longer be able to edit a GPO.

Additionally, file system objects and directory service objects do not have the same
available permissions because they are different types of objects. When permissions
mismatch, it may not be easy to make them consistent. To help you make sure that the
security for the Active Directory and for the Sysvol components of a GPO is consistent,
GPMC automatically checks the consistency of the permissions of any GPO when you
click the GPO in GPMC. If GPMC detects a problem with a GPO, you receive one of the
messages that is described in the "Symptoms" section, depending on whether or not
you have permissions to modify security on that GPO.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
How to force authoritative and non-
authoritative synchronization for DFSR-
replicated sysvol replication
Article • 12/26/2023

This article introduces how to force an authoritative and non-authoritative

synchronization for DFSR-replicated sysvol replication.

Applies to: Windows Server 2012 R2

Original KB number: 2218556

Summary
Consider the following scenario:

You want to force the non-authoritative synchronization of sysvol replication on a

domain controller (DC). In the File Replication Service (FRS), it was controlled through
the D2 and D4 data values for the Bur Flags registry values, but these values don't exist
for the Distributed File System Replication (DFSR) service. You can't use the DFS
Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to
achieve this. Unlike custom DFSR replicated folders, sysvol replication is intentionally
protected from any editing through its management interfaces to prevent accidents.

How to perform a non-authoritative

synchronization of DFSR-replicated sysvol
replication (like D2 for FRS)
1. In the ADSIEDIT.MSC tool, modify the following distinguished name (DN) value
and attribute on each of the domain controllers (DCs) that you want to make non-
authoritative:

Console

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-

LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE
 2. Force Active Directory replication throughout the domain.

3. Run the following command from an elevated command prompt on the same
servers that you set as non-authoritative:

Console

DFSRDIAG POLLAD

4. You'll see Event ID 4114 in the DFSR event log indicating sysvol replication is no
longer being replicated.

5. On the same DN from Step 1, set msDFSR-Enabled=TRUE.

6. Force Active Directory replication throughout the domain.

7. Run the following command from an elevated command prompt on the same
servers that you set as non-authoritative:

Console

DFSRDIAG POLLAD

8. You'll see Event ID 4614 and 4604 in the DFSR event log indicating sysvol
replication has been initialized. That domain controller has now done a D2 of
sysvol replication.

How to perform an authoritative

synchronization of DFSR-replicated sysvol
replication (like D4 for FRS)
1. Set the DFS Replication service Startup Type to Manual, and stop the service on all
domain controllers in the domain.

2. In the ADSIEDIT.MSC tool, modify the following DN and two attributes on the
domain controller you want to make authoritative (preferably the PDC Emulator,
which is usually the most up-to-date for sysvol replication contents):

Console

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-

LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
 msDFSR-Enabled=FALSE
msDFSR-options=1

3. Modify the following DN and single attribute on all other domain controllers in
that domain:

Console

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-

LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=
<domain>

msDFSR-Enabled=FALSE

4. Force Active Directory replication throughout the domain and validate its success
on all DCs.

5. Start the DFSR service on the domain controller that was set as authoritative in
Step 2.

6. You'll see Event ID 4114 in the DFSR event log indicating sysvol replication is no
longer being replicated.

7. On the same DN from Step 2, set msDFSR-Enabled=TRUE.

8. Force Active Directory replication throughout the domain and validate its success
on all DCs.

9. Run the following command from an elevated command prompt on the same
server that you set as authoritative:

Console

DFSRDIAG POLLAD

10. You'll see Event ID 4602 in the DFSR event log indicating sysvol replication has
been initialized. That domain controller has now done a D4 of sysvol replication.

11. Start the DFSR service on the other non-authoritative DCs. You'll see Event ID 4114
in the DFSR event log indicating sysvol replication is no longer being replicated on
each of them.

12. Modify the following DN and single attribute on all other domain controllers in
that domain:
 Console

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-

LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=
<domain>

msDFSR-Enabled=TRUE

13. Run the following command from an elevated command prompt on all non-
authoritative DCs (that is, all but the formerly authoritative one):

Console

DFSRDIAG POLLAD

14. Return the DFSR service to its original Startup Type (Automatic) on all DCs.

More information
If setting the authoritative flag on one DC, you must non-authoritatively synchronize all
other DCs in the domain. Otherwise you'll see conflicts on DCs, originating from any DCs
where you did not set auth/non-auth and restarted the DFSR service. For example, if all
logon scripts were accidentally deleted and a manual copy of them was placed back on
the PDC Emulator role holder, making that server authoritative and all other servers
non-authoritative would guarantee success and prevent conflicts.

If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its
sysvol replication contents are most up to date.

The use of the authoritative flag is only necessary if you need to force synchronization of
all DCs. If only repairing one DC, make it non-authoritative and don't touch other
servers.

This article is designed with a 2-DC environment in mind, for simplicity of description. If
you had more than one affected DC, expand the steps to include ALL of them as well. It
also assumes you have the ability to restore data that was deleted, overwritten,
damaged, and so on. previously if it's a disaster recovery scenario on all DCs in the
domain.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to minimize SYSVOL size by
removing administrative templates
(.adm files)
Article • 12/26/2023

This article describes how to minimize SYSVOL size by removing administrative

templates (.adm files).

Applies to: Windows Server 2012 R2

Original KB number: 813338

Summary
For domains with many policies, and domain controllers with slow wide area network
(WAN) lines, replicating the SYSVOL share can take a long time. It's most noticeable
when you promote a new domain controller at a location with slow connectivity or when
you run a non-authoritative restore of SYSVOL. To speed up the process, reduce the
number of files and amount of data that must be replicated in the SYSVOL share.

Because Administrative Templates (that is, .adm files) take up the most space in policies,
remove them to significantly reduce the size of SYSVOL. For example, with the default
Administrative Templates, each policy takes up 870 kilobytes (KB) of disk space. If you
have 1,300 policies, you can reduce the size of SYSVOL from 1,100 megabytes (MB) to
35 MB (or 27 KB per policy).

You can use Group Policy settings to change the behavior of Group Policy Editor about
.adm files in Microsoft Windows Server 2003. For more information, see
Recommendations for managing Group Policy administrative template (.adm) files .

More information
Only the computer that you target with Group Policy Object Editor has to have the
Administrative Templates. By default, it's the Primary Domain Controller (PDC) emulator.

Removing the ADM files from the SYSVOL replication is a three-step process.

1. The ADM files must be removed from the policies.

2. A filter is set in FRS or DFSR for SYSVOL so that ADM files are no longer replicated.
3. The ADM files are copied back to the SYSVOL on the PDC Emulator.
Step 1: Remove the ADM files
An easy way to remove Administrative Templates if you haven't added any special or
custom ones is to search in Explorer on the PDC emulator for *.adm files. Sort the results
by name, and then delete all the Administrative Template folders. After you make these
changes, wait until the replication process has successfully replicated the changes to the
other domain controllers. To complete the process, set the filter for Administrative
Templates.

If you have custom Administrative Templates, copy these to a different directory

structure. For best results, use the Robust File Copy utility (Robocopy.exe) from the
Resource Kit. The command syntax is:
robocopy PDC sysvol backup_directory *.adm /s /mov

An example of the command to copy custom Administrative Templates to a different

directory structure is the following one:
robocopy \\mydom-pdc\sysvol\mydom.com\policies c:\sysvol-adm-backup\ *.adm /s /mov

After running this command to remove ADM file from the policies in the SYSVOL, the
change will be replicated to all other DCs in the domain. Wait for file replication to
complete before proceeding to step 2.

７ Note

Backup your Sysvol before making any changes to the file structure

Step 2: Set Replication Filter for ADM files

The File Replication System (FRS) or the Distributed File System Replication (DFSR) can
be used to replicate the SYSVOL. Use the correct method for the target domain.

Steps for FRS

You can specify a file filter in the FRS object for the replica set (after you remove the
Administrative Templates). For best results, use Adsiedit.msc from the Support Tools. The
Attribute is fRSFileFilter. By default, its content is *.tmp, *.bak, ~*.

To edit this attribute:

1. In ADSIEDIT, locate the following object:

 CN=Domain System Volume (SYSVOL share),CN=File Replication
Service,CN=System,DC= your_domain

2. In the properties for the object, select fRSFileFilter in Select a property to view.
The value appears in the Value line.

3. Select Clear to bring the attribute to the Edit Attribute line.

4. Change this line to *.tmp, *.bak, *.adm, ~*.

5. Select Set.

6. Select OK.

Steps for DFSR

1. Open ADSIEDIT.MSC.
2. Browse to DC=<DominanName>,CN=System,CN=DFSR GlobalSettings,
CN=Domain System Volume,CN=Content.
3. Right click CN=Sysvol Share and select Properties. Locate the msDFSR-FileFiler
attribute.
4. Edit the msDFSR-FileFiler attribute and add ,*.ADM.
5. Select Apply and then select OK.

Step 3: Copy the ADM files back to the PDC's SYSVOL

You can then use the Robust File Copy utility to copy the Administrative Template
folders back to the guid folders if you want. The command syntax is:
robocopy backup_directory PDC sysvol /s

An example of the command to copy the Administrative Template folders back to the
guid folders is the following one:
robocopy c:\sysvol-adm-backup\\mydom-pdc\sysvol\mydom.com\policies /s

Technically, if you don't have any custom Administrative Templates, you don't have to
add the Administrative Template folders back to the PDC emulator. The folders will be
automatically regenerated by using the local Administrative Templates whenever
someone edits the Group Policy object (GPO).

If you move the PDC emulator role, you may also want to move the Administrative
Templates. For best results, use the Robust File Copy utility. The command syntax is:
robocopy old_PDC_SYSVOL PDC_SYSVOL *.adm /s /mov
An example of the command to move the Administrative Templates is the following one:
robocopy \\mydom-pdc\sysvol\mydom.com\policies \\mydom-res-

pdc\sysvol\mydom.com\policies *.adm /s /mov

If you have custom Administrative Templates, make sure they have unique file names
across policies. You can then distribute these Administrative Templates to all the
computers that run Group Policy Object Editor. Copy the Administrative Template files to
the NT\Inf folder.

Unless you have specific Administrative Template requirements (for example, you use
certain Administrative Templates only for certain policies), a good idea is to combine
these approaches to have a complete set of Administrative Templates for editing a GPO.

Windows 2000, Windows 2003, Windows 2003 R2, and Windows XP use ADM files.
Windows 2008 and later OSs use ADMX files and can also use custom ADM files. For
more information on ADMX files, see Managing Group Policy ADMX Files Step-by-Step
Guide.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to rebuild the SYSVOL tree and its
content in a domain
Article • 12/26/2023

The article describes how to use the Burflags registry entry to rebuild each domain
controller's copy of the system volume (SYSVOL) tree on all domain controllers in a
common Active Directory directory service domain.

Applies to: Windows Server 2012 R2

Original KB number: 315457

Introduction
The term SYSVOL refers to a set of files and folders that reside on the local hard disk of
each domain controller in a domain and that are replicated by the File Replication
service (FRS). Network clients access the contents of the SYSVOL tree by using the
following shared folders:

NETLOGON
SYSVOL

We recommend the procedure that is described in this article as a last resort to restore a
domain's SYSVOL tree and its contents. Use this procedure only if you can't make the
FRS functional on individual domain controllers in the domain. Use this procedure only if
the bulk restart can be performed more quickly than troubleshooting and resolving
replication inconsistencies, and time to resolution is a critical factor.

） Important

Domain controllers will not service authentication request during the procedure.
Only when the SYSVOL and NETLOGON folders are shared again will the domain
controller authenticate requests. This procedure should not be performed during
peak hours.

７ Note

See the How to temporarily stabilize the domain SYSVOL tree section of this
article for information about how to temporarily stabilize the domain SYSVOL tree
 until you can complete all the steps in the How to rebuild the domain SYSVOL
replica set across enterprise environments section.

We strongly recommend that you monitor FRS performance and health by using
monitoring tools. By using monitoring tools, you may prevent the need for replica set
authoritative and non-authoritative restores. Also, by using monitoring tools, you may
provide insight into the root cause of FRS failures.

The monitoring tool Ultrasound is available for download.

Ultrasound is a powerful tool that measures the functioning of FRS replica sets by
providing health ratings and historical information of these sets. The Ultrasound tool is a
sophisticated monitoring system that uses Windows Management Instrumentation
(WMI) providers, a data collection service, a Microsoft SQL Server Desktop Engine
(MSDE) database, and a powerful user interface.

Guidelines

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

Use the following guidelines to configure the Burflags registry entry:

If you start the FRS with the Burflags registry entry set to D4, the FRS initially treats
the files and folders on its local copy of the SYSVOL tree as authoritative for the
replica set. Only one member of an FRS replica set should be initialized with the D4
setting.

If you start the FRS with the Burflags registry entry set to D2, the FRS performs a
full synchronization of files and folders from a direct or transitive replication
partner that is hosting the authoritative copy of files and folders in the replica set.

When you start the FRS with the Burflags registry entry set to D4, the configuration
is referred to as an "authoritative restore" for the contents of an FRS replica set,
 even though no actual restore of the system state occurred. Think of the D4 setting
as rebuilding the FRS part of the first domain controller in a new domain.

When you start the FRS with the Burflags registry entry set to D2, the configuration
is referred to as a non-authoritative restore, even though no restore of the system
state occurred. Think of the D2 setting as rebuilding the FRS part of the replica
domain controller as if the domain controller were new.

After each of the authoritative or non-authoritative restored computers has

completed initialization, the FRS becomes multi-master aware.

If you set Burflags to D4 on a single domain controller and set Burflags to D2 on all
other domain controllers in that domain, you can rebuild the SYSVOL tree in that
domain. This bulk rebuild process is known as a hub, branch, or bulk FRS restart.

The following section lists the valid uses of a bulk restart of the SYSVOL replica set:

The members of an FRS replica set that are currently inconsistent can perform a
full synchronization of all files and folders in the SYSVOL tree faster than the
members can process the backlog of changes that reside in the outgoing logs of
upstream replication partners.

Most of the members in an FRS replica set have errors, such as journal_wrap errors.
For more information about journal_wrap errors, see How to troubleshoot
journal_wrap errors on Sysvol and DFS replica sets.

The ID table on most of the members of the replica set contains an incomplete
description of the files that should be hosted in the replica set.

The FRS database files are compromised because of accidental deletion, file system
errors, or database file errors, including corruption that is identified by JET
Database validation tools.

Most of the members in an FRS replica set cannot replicate files and folders, and a
bulk D4 or D2 configuration is a way to reinitialize all members as new members.

７ Note

If the FRS is in an error state on a single member, you can set BurFlags to D2
only on that single member.
If you rebuild the SYSVOL tree because of environmental problems, or if a
problematic topology has affected the consistency of files and folders in an
FRS replica set, you may see only temporary benefits. For example, this
 scenario occurs when too many downstream partners exist or excessive
changes have occurred on the replicated content. In this case, we recommend
that you address the root cause of any underlying problem. Otherwise,
problems that first caused you to rebuild the SYSVOL tree may happen again.
To rebuild the SYSVOL tree, we recommend that all Windows 2000-based
domain controllers in the domain have Windows 2000 Service Pack 3 (SP3) or
a later version of the NTFRS.exe file installed. If your version of the NTFRS.exe
file is older than Windows 2000 Service Pack 3, install the latest Windows 2000
service pack.

How to rebuild the domain SYSVOL replica set

across enterprise environments
This section describes how to rebuild the domain SYSVOL replica set across enterprise
environments.

Summary of the steps

The following list summarizes the steps that are performed in a hub or branch restart:

1. Stop the FRS on all domain controllers in the domain.

2. Move all files and folders that should reside in the SYSVOL tree to a temporary
folder on the reference domain controller. The temporary folder should be located
on the same partition the SYSVOL tree is located.

When you move files within a partition, the files are not altered. Therefore, they
retain their original security settings. Files or Folders that are moved partitions or
copied within or between partitions inherit the security of the destination parent
directory. Therefore, any custom delegations of GPO management may be lost as a
result. Additionally, the access control list (ACL) on the SYSVOL part of the Group
Policy object is set to inherit permissions from the parent folder. Therefore, you
may receive the following error message when you open a GPO by using GPMC:

The Permissions for This GPO in the SYSVOL Folder Are Inconsistent with Those
in Active Directory

If you have permissions to modify security on the GPO, select OK when you receive
this error message. This action modifies the ACLs on the Sysvol part of the Group
 Policy object and makes them consistent with the ACLs on the Active Directory
component. In this case, Group Policy removes the inheritance attribute in the
Sysvol folder.

3. Verify junction points and required folders on each domain controller in the
domain.

4. Restart the FRS on the reference domain controller with the D4 registry entry set.

5. Restart the FRS on all other domain controllers in the domain with the D2 registry
entry set.

6. On the reference domain controller, move all files and folders to the root folder of
the replica set. By default, this folder is the C:\Windows\Sysvol\Domain folder.

7. Monitor the consistency of files and folders for all domain controllers in the
domain.

７ Note

If a member of any replica set has been restarted with the Burflags registry entry
set to D4, restart the FRS on all other members of the replica set with the Burflags
registry entry set to D2. This configuration prevents morphed folders.

When the Burflags registry entry is set to D2 or to D4, and the FRS is restarted, the
originator GUID (OrigGUID) changes. If you want to track the source of a specific
activity, you can run the File Replication Service Diagnostics Tool (FRSDiag) to obtain
GUID2Name before you set the Burflags registry entry.

Detailed list of the steps

The following list shows the detailed steps that are performed in a hub or branch restart:

1. On all domain controllers in the domain, stop the FRS, and then set the service
startup type value for the FRS to Disabled.

2. On a single domain controller, configure the SYSVOL replica set to be authoritative.

This reference domain controller will contain the authoritative copy of the SYSVOL
tree for all other members of the replica set. For example, other domain controllers
in the domain will directly or transitively replicate from this reference domain
controller.
 Choose the reference domain controller based on connectivity and physical server
resources. This domain controller will be known as the "reference domain
controller" in all subsequent steps.

To configure the SYSVOL replica set to be authoritative, follow these steps:

a. Go to Start, select Run, type regedit, and then select OK.

b. Locate and then select the BurFlags entry under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumul

ative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in the
following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Repli
ca Sets\GUID

c. Right-click BurFlags, and then select Modify.

d. Type D4 in the Value Data field (HexaDecimal), and then select OK.

3. On all domain controllers in the domain, verify that the file structure and junction
points are correct. You can follow these steps:

a. Verify that the following folders exist in the SYSVOL tree:

\SYSVOL
\SYSVOL\domain
\SYSVOL\staging\domain
\SYSVOL\staging areas
\SYSVOL\domain\Policies
\SYSVOL\domain\scripts
\SYSVOL\SYSVOL

b. Verify that the following reparse points exist:

\SYSVOL\SYSVOL\DNS Domain Name

This reparse point must be linked to the \SYSVOL\domain folder.

\SYSVOL\staging areas\DNS Domain Name

This reparse point must be linked to the \SYSVOL\staging\domain folder.

The default path for the SYSVOL tree is under the \WINDOWS or \WINNT folder
on the partition where the operating system is installed. However, the SYSVOL
 tree may be installed on any partition that is formatted by using the NTFS file
system.

Verify that each domain controller in the domain has all the required folders and
that the reparse points exists. Re-create any missing folders as needed. Don't
use Windows Explorer to move or copy contents of the SYSVOL tree, or the
reparse points may be damaged.

The SYSVOL tree contains reparse points to other folders in the SYSVOL tree. These
reparse points are in the NTFS file system. Think of a reparse point as a source folder
that maps or points to a destination folder when the source folder is accessed. The
contents of the reparsed folders appear as mirror images of each other.

The following two reparse points for a SYSVOL tree are installed in the
C:\WINNT\SYSVOL folder:

C:\WINNT\SYSVOL\SYSVOL\DNS Domain Name.

This reparse point is linked to the C:\WINNT\SYSVOL\domain folder.

C:\WINNT\SYSVOL\staging areas\DNS Domain Name

This reparse point is linked to C:\WINNT\SYSVOL\staging\domain folder.

On each domain controller in the domain, follow these steps:

1. Go to Start, select Run, type cmd, and then select OK.

2. Type net start ntfrs to start the File Replication service.

3. Type ntfrsutl ds |findstr /i "root stage" , and then press ENTER. The
NTFRSUTIL command returns the current root directory for the SYSVOL replica set
that is referred to as the "replica set root" and the staging folder. For example, this
command returns:

Output

Root: C:\WINNT\SYSVOL\domain
Stage: C:\WINNT\SYSVOL\staging\domain

4. Type Linkd %systemroot%\SYSVOL\SYSVOL\DNS Domain name , and then press ENTER.

The LINKD command returns the following information:

Output
 Source DNS Domain Name is linked to %systemroot%\SYSVOL\domain

5. Type linkd "%systemroot%\SYSVOL\staging areas\DNS Domain Name" , and then press

ENTER. This command returns the following information:

Output

Source DNS Domain Name is linked to %systemroot%\SYSVOL\Staging\domain

７ Note

The path that is reported by the LINKD command varies depending on the
location of the SYSVOL\SYSVOL\DNS Domain Name folder. If the SYSVOL
folder is in the default location in the %systemroot%\SYSVOL folder, use the
commands that are listed. Otherwise, type the actual path of the SYSVOL
folders.

For example, if the NTFRSUTL and LINKD commands are run on a domain
controller in the contoso.com domain, and the SYSVOL folder is in the
C:\Windows\SYSVOL folder, the command syntax and results for the SYSVOL and
Staging folders will appear similar to the following output:

Console

C:\>ntfrsutl ds |findstr /i "root stage"

Output:

Output

Root: C:\windows\sysvol\domain
Stage: C:\windows\\sysvol\staging\domain

Console

C:\>Linkd %systemroot%\SYSVOL\SYSVOL\Contoso.com

Output:

Output
 Source domain.com is linked to C:\WINDOWS\SYSVOL\domain

Console

C:\>linkd "%systemroot%\SYSVOL\<staging areas>\Contoso.com

Output:

Output

Source domain.com is linked to C:\WINDOWS\SYSVOL\staging\domain

To re-create the junction points if the LINKD command reports missing or invalid
junction points, follow these steps:
a. Type linkd C:\WINNT\SYSVOL\sysvol\DNS_Domain_Name Source , where Source is
the root path that is determined by using the NTFRSUTL command.
b. Type C:\linkd "C:\WINNT\SYSVOL\staging areas\DNS_Domain_Name" Source , where
Source is the stage path that is determined by using the NTFRSUTL command.

6. On all domain controllers in the domain, verify that enough staging space is
available. The ratio of staging area size to data set size depends upon a range of
factors.

To determine the size of the replica set root, right-click the replica set root that
uses the Winnt\SYSVOL\domain folder in Windows Explorer, and then select
Properties.

To adjust the staging folder size, follow these steps:

a. Go to Start, select Run, type regedit, and then select OK.
b. Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

c. Right-click Staging Space Limit in KB, and then select Modify.

d. Select decimal, type the size of the staging folder in kilobytes, and then select
OK.
e. Quit Registry Editor.

7. On the reference domain controller, build a good set of policies and scripts, and
then put them in a temporary folder outside the SYSVOL replica set folders on the
FRS reference domain controller.

To complete this step, examine Active Directory to determine the group policies
that are still used and that contain orphaned data. Policy information is located in
the Group Policies container. To view this container, follow these steps:

a. Start Active Directory Users and Computers.

b. On the View menu, select Advanced Features if it is not already selected.

c. Expand the domain container, expand the System container, and then expand
the Policies container.

In the right pane of Active Directory Users and Computers, all the Group Policy
objects (GPOs) in Active Directory are listed. There should be a one-to-one
mapping between valid GPOs in Active Directory with Group Policy folders in
the SYSVOL tree.

If the SYSVOL folder contains a folder name that has a GUID that is not
listed in Active Directory, the file system contains an orphaned GPO, and
you can safely delete the folder from the file system.
If Active Directory contains a Group Policy GUID that does not map to a
GUID in the SYSVOL\domain\policies folder on any domain controller in
the domain, you can safely delete that policy setting from Active Directory.

７ Note

If any domain controller that is participating in the domain has a newer

version of a Group Policy in its local SYSVOL tree, make sure that it is
copied to a temporary location on the reference domain controller.

d. On the reference domain controller, delete any files or folders that are in the
FRS replica set root or in the replica set stage folders.

For default SYSVOL replica sets, delete files and folders under the following two
folders:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain

７ Note

Do not delete the folders themselves.

e. On the reference domain controller, move the policies and scripts folders and
the folder contents from the temporary location that you used in step c to the
 FRS replica set root folder. For the SYSVOL folder, the default location for the
replica set root is the folder: C:\WINNT\SYSVOL\domain.

f. On all domain controllers except the reference domain controller, configure the
FRS to be non-authoritative. You can follow these steps:

i. Go to Start, select Run, type regedit, and then select OK.

ii. Locate and then select the BurFlags entry under the following registry
subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cu
mulative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in
the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Re

plica Sets\GUID

iii. On the Edit menu, point to New, and then select DWORD Value.

iv. Type D2 for the name of the DWORD, and then press ENTER.

７ Note

For domain controllers that are not participating in Distributed File System
(DFS) replication, set the DWORD to D2 in the registry subkey for bulk
modifications:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\

Backup/Restore\Process atStartup\BurFlags .

g. Quit Registry Editor.

The FRS is instructed to reinitialize its database and to overwrite the contents of
the SYSVOL tree with data from an upstream partner.

In large sites, we recommend that you use a staggered approach to rebuilding the
SYSVOL tree. This approach helps avoid overloading a single domain controller or
causing the FRS to source its contents from a domain controller that has not
completed its own re-sourcing of the system volume. This process involves setting
the Burflags registry entry to D2 on all hub site domain controllers before
proceeding to branch office or to satellite sites.
 Use the Replica Set Parent registry entry to specify a source domain controller for
the D2 setting:

Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\SY

SVOL Seeding\DOMAIN SYSTEM VOLUME (SYSVOL SHARE)

Value name: Replica Set Parent

Value type: REG_SZ
Value data: The source domain controller

７ Note

If this registry entry does not exist, you must create it.

We don't recommend that a single domain controller becomes the source for
more than 10 to 15 domain controllers at the same time. If you must source more
than 15 domain controllers off a single source, start the FRS on only 15
downstream partners of any particular source domain controller, and then wait for
them to complete sourcing the SYSVOL tree before the FRS service is started on
the next group of 15 computers.

７ Note

We do not recommend that more than 15 domain controllers source

their contents off of a single domain controller at the same time.
Incoming replication depends on a schedule that is defined on the
relevant site link or on the connection object that is used by the
destination domain controller that allows replication. If the replication
schedule is disabled, incoming replication will be delayed.
If the "Replica set parent" registry entry is used, the FRS will source data
upon restart of the service, independent of the whether replication is
enabled or disabled on the day or the hour that the service restart
occurred. After the initial source is complete, all additional replication
will be based on connection schedules. If the registry entry is not used,
the FRS will initiate replication based on the schedule that is defined on
the relevant site link or connection object.

8. On all domain controllers in the domain except the reference domain controller,
delete any files or folders under the FRS replica set root and the replica set stage
 directories. For example, for default SYSVOL replica sets, delete files and folders in
the following two locations:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain

７ Note

Do not delete the folders themselves.

This step enables faster replication of the SYSVOL tree for the given source. This
step eliminates the need for the FRS server to move the existing contents before
replicating the new data. This step is not required but it is recommended.

9. On all domain controllers in the hub site, except the reference domain controller,
restart FRS, and then verify that SYSVOL and NETLOGON are shared.

７ Note

The service startup type for the FRS should be set to Automatic.

10. On all non-reference domain controllers in the branch sites, start the FRS service
and verify that SYSVOL and NETLOGON are shared.

How to temporarily stabilize the domain

SYSVOL tree
1. Stop FRS on all domain controllers in the domain and set the service to Disabled.

2. Manually copy the full set of policies to the following folder on each domain
controller:

\SYSVOL\SYSVOL\dns domain name\policies

Typically, the following two policies are required for authentication:

Default Domain Controllers Policy{6AC1786C-016F-11D2-945F-

00C04fB984F9}
Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}

７ Note
 You may have to copy additional policies depending on Group Policy
requirements for the environment.

3. Manually copy all necessary scripts to the following folder:

\SYSVOL\SYSVOL\DNS Domain name\scripts

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Events 6804 and 2843 are logged and
RODCs do not replicate SYSVOL
Article • 12/26/2023

This article provides a solution to an issue where events 6804 and 2843 are logged when
read-only domain controllers (RODC) don't replicate inbound the system volume
(SYSVOL) shared directory.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows Server 2008 R2 Service Pack 1
Original KB number: 3212965

Symptoms
One or more read-only domain controllers (RODC) do not replicate inbound the system
volume (SYSVOL) shared directory. This issue occurs even though multiple inbound
Active Directory connections are listed when Active Directory Sites and Services
(Dssite.msc) is pointed at an affected RODC.

When this issue occurs, the following entry is logged in the DFSR event log:

Log Name: DFS Replication

Source: DFSR
Event ID: 6804
Level: Warning
Keywords: Classic
Description:
The DFS Replication service has detected that no connections are configured for
replication group Domain System Volume. No data is being replicated for this
replication group.

Additionally, the following entry is logged in the Directory Service event log:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2843
Task Category: Knowledge Consistency Checker
Level: Error
Description:
 The Knowledge Consistency Checker was unable to locate a replication connection
for the read-only local directory service. A replication connection with the following
option must exist in the forest for correct FRS system behavior.

Additional Data
Option: 64
User Action
Restore the original replication connection for the local directory service instance on
a writable directory service instance.

When this issue occurs, new RODCs that are promoted work correctly. Also, demoting
and promoting an affected RODC fixes the issue.

７ Note

Outbound replication also does not occur. However, this behavior is by design on
an RODC.

Cause
This issue occurs because an administrator has deleted the automatically generated
"RODC Connection (FRS)" objects for these affected RODCs. This action may have been
done for one of the following reasons:

A customer notices that the connections are named "FRS" and, therefore, believes
that the connections are no longer required because DFSR is replicating SYSVOL.
The administrator created manual connection objects per local processes.RODCs
require a special flag on their connection objects in order for SYSVOL replication to
work. If the flag is not present, SYSVOL does not work for FRS or DFSR.

Resolution
To resolve this issue, follow these steps:

1. Log on to a writeable DC in the affected forest as an enterprise administrator.

2. Start Dssite.msc.

3. Navigate to an affected RODC within its site, and scroll down to the NTDS Settings
object.
 ７ Note

There may be no connections listed here, or there may be manually created

connections.

4. Create a connection object, and give it the same name as the default object. For
example, name the object RODC Connection (FRS).

5. Edit the new connection in Adsiedit .msc or by using the Dssite.msc Attribute
Editor tab. Navigate to the options attribute, and then enter 0x40 in the Value
field.
6. Repeat steps 4 and 5 to create more connections, as necessary.
 7. Force Active Directory replication outbound from this DC to the RODCs, or wait for
convergence to occur. When the DFSR service on the RODC sees these
connections, SYSVOL begins to replicate again.

About RT (NTDSCONN_OPT_RODC_TOPOLOGY,
0x00000040)
The NTDSCONN_OPT_RODC_TOPOLOGY bit in the options attribute indicates whether
the connection can be used for DRS replication (MS-DRDM). When the connection is set,
it should be ignored by DRS replication and used only by FRS replication.

７ Note

The 0x40 value is required for both DFSR and FRS. Other connections for Active
Directory replication are still required separately, and they exist on the RODC
locally.

References
7.1.1.2.2.1.2.1.3 RODC NTFRS Connection Object

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot missing SYSVOL and
NETLOGON shares on Windows domain
controllers
Article • 12/26/2023

This article describes troubleshooting steps to use on Windows 2000 domain controllers
that are missing netlogon and sysvol shares.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 257338

７ Note

This article applies to Windows 2000. Support for Windows 2000 ends on July 13,
2010. The Windows 2000 End-of-Support Solution Center is a starting point for
planning your migration strategy from Windows 2000. For more information, see
the Microsoft Support Lifecycle Policy.

Summary
The File Replication Service (FRS) is a multi-threaded, multi-master replication engine
that replaces the LMREPL service in Windows NT 3.x and 4.0. Windows 2000 domain
controllers and servers use FRS to replicate system policy and login scripts for Windows
2000 and down-level clients.

FRS can also replicate content between Windows 2000 servers hosting the same fault-
tolerant DFS roots or child node replicas.

More information
Missing netlogon and sysvol shares typically occur on replica domain controllers in an
existing domain, but may also occur on the first domain controller in a new domain. The
following steps are directed more at the replica domain controller scenario, but can be
applied to the first domain controller in the domain by ignoring the replication-specific
steps.

1. NTDS Connection objects exist in the DS of each replication partner.

 NTDS Connections are one-way connections that are used by the Directory Service
to replicate the Active Directory, and the File Replication Service (FRS) to replicate
the file system portion of system policy in the SYSVOL folder. The Knowledge
Consistency Checker (KCC) is responsible for building NTDS connection objects to
form a well-connected topology between domain controllers in the domain and
forest. In lieu of automatic connections, administrators may also create manual
connection objects.

Use the "Sites and Services" (Dssite.msc) snap-in to examine the connection
objects that exist between the problem computer and existing domain controllers.
For replication to occur between computer \\M1 and \\M2, \\M1 should have an
inbound connection object from \\M2, and \\M2 an inbound connection object
from \\M1. Use the "Connect to Domain Controller..." command in Dssite.msc to
view and compare each domain controllers perspective of the intra-domain
connection objects.

If no connection objects exist for the new replica member, use the Check
Replication Topology command in Dssite.msc to force KCC to build the necessary
automatic connection objects (press F5 to refresh the view afterwards).

If KCC is unable to build automatic connections, administrators should intervene by

building manual connection objects for domain controllers that have no inbound
or outbound connections to or from other domain controllers in the domain.
Often, building a single working manual connection object permits KCC to build
the desired automatic connection objects. Duplicate manual and/or automatic
connections from the same domain controller in the domain should be deleted to
avoid a replication-blocking configuration.

2. Active Directory replication is taking place between the new and existing domain
controllers in the domain.

Use Repadmin.exe to confirm Active Directory replication is taking place between

the source and destination domain controllers in the same domain in the
scheduled replication interval. Default replication intervals are five minutes
between domain controllers in the same site, and once every three hours between
domain controllers in different sites (minimum 15 minutes).

Console

REPADMIN /SHOWREPS %UPSTREAMCOMPUTER%

REPADMIN /SHOWREPS %DOWNSTREAMCOMPUTER%
 FRS replication is dependent on the Active Directory to replicate the necessary
configuration information between domain controllers in the domain. If replication
is suspect, examine replication events in Event Viewer after setting the "replication
events" entry in HKEY_LOCAL_MACHINE\system\ccs\services\ntds\diagnostics\ to 5
on potential source computers (\\M1) and the destination computer (\\M2), then
forcing replication from \\M1 to \\M2 and \\M2 to \\M1 using the "replicate now"
command in Dssite.msc or its equivalent in REPLMON.

3. The server used to source the Active Directory and SYSVOL folder should have
created NETLOGON and SYSVOL shares itself.

After the Dcpromo.exe program has restarted the computer, FRS first attempts to
source the SYSVOL from the computer identified in the "Replica Set Parent"
registry key under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\SysVol\D
omainName

７ Note

This key is temporary and is deleted once SYSVOL is sourced, or the

information under SYSVOL has been successfully replicated.

The 2195 release of Ntfrs.exe prevents replication from this initial source server,
delaying SYSVOL replication until FRS can attempt replication from an inbound
replication partner in the domain over an automatic or manual NTDS connection
object.

All potential source domain controllers in the domain should themselves have
shared the NETLOGON and SYSVOL shares and applied default domain and
domain controllers policy.

SYSVOL directory structure:

domain
DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Policies
{GUID}
Adm
MACHINE
USER
{GUID}
 Adm
MACHINE
USER
{etc.,}
scripts
staging
staging areas
MyDomainName.com

scripts
sysvol(sysvol share)
MyDomainName.com

DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Policies
{GUID}
Adm
MACHINE
USER
{GUID}
Adm
MACHINE
USER
{etc.,}
scripts(NETLOGON share)

4. The "Enterprise Domain Controllers" group should be granted the "access this
computer from network" right in the default domain controllers policy on the
domain controllers OU.

Replication of the Active Directory during the use of the Dcpromo.exe program
uses the credentials that are specified in the Active Directory Installation Wizard.
Upon restart, replication occurs in the context of the domain controller's computer
account. All source domain controllers in the domain must successfully replicate
and apply the policy granting the "Enterprise Domain Controllers" group "Access
this computer from network" right. For quick verification, look for event 1704s in
the application log of potential source domain controllers. For detailed verification,
run security configuration analysis against the Basicdc.inf template (requires
defining environment variables for SYSVOL, DSLOG, and DSIT, and examine the
resulting log output.

The "access this computer from network" right is often missing on Windows NT 4.0
domains that are upgraded to Windows 2000. This issue causes active directory
 and FRS replication to be unsuccessful with "access denied" error messages.

5. Each domain controller must be able to resolve (ping) the fully qualified computer
names (%computer name%.<domain name>) of computers participating in the
replica set.

For SYSVOL, this step means pinging the FQ computer name of all domain
controllers in the domain. Confirm the address returned by the ping command
matches the IP address returned by IPCONFIG at the console of each replica set
partner.

6. The FRS service must have created an NTFRS jet database.

Run DIR \\<computername>\admin$\ntfrs\jet against each domain controller in the

domain to confirm the presence of the NTfrs.jdb file. The date and size of the jet
database may be incorrect while the NTFRS service is running (by design).

7. Each domain controller must be a member of the SYSVOL replica set.

Run NTFRSUTL DS [COMPUTERNAME] on all replica set members. Confirm that all
domain controllers in the domain show up under the "SET: DOMAIN
SYSTEMVOLUME (SYSVOL SHARE)" portion of the NTFRSUTL output. The SYSVOL
Replica set and its members can also be displayed under cn="domain system
volume",cn=file replication service,cn=system,dc=<FQDN> in the User and
Computers (Dsa.msc) snap-in when "Advanced Features" is enabled under the
View menu.

8. Each domain controller must be a subscriber of the replica set.

Run NTFRSUTL DS [COMPUTERNAME] on all replica set members. Subscriber object

appears in cn=domain system volume (SYSVOL share),cn=NTFRS
Subscriptions,CN=%DCNAME%,OU=Domain Controllers,DC=<FQDN>. Running
this command requires that the machine object exists and has replicated in.
NTFRSUTL reports the following when the subscriber object is missing:

Output

SUBSCRIPTION: NTFRS SUBSCRIPTIONS DN: cn=ntfrs

subscriptions,cn=W2KPDC,ou=domain controllers,dc=d... Guid:
5c44b60b-8f01-48c6-8604c630a695dcdd
Working: f:\winnt\ntfrs
Actual Working: f:\winnt\ntfrs
WIN2K-PDC IS NOT A MEMBER OF A REPLICA SET!

9. The Replication Schedule must be enabled.

 10. The logical drive hosting the SYSVOL share and staging folder has plenty of
available disk space on upstream and downstream partners. For example, 50
percent of the amount of content you're trying to replicate and three times the
largest file size being replicated.

11. Check the destination folder and the staging folder (displayed in "NTFRSUTL DS")
of the new replica to see if files are replicating. Files in the staging folder should be
in the process of being moved to the final location. That the number of files in the
staging or destination folder is constantly changing is a good sign as either files
are being replicated in, or transitioned to the destination folder.

７ Note

Ntfrsutl.exe is a utility included in the Windows 2000 Resource Kit.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

High Availability troubleshooting
documentation for Windows Server
Article • 03/18/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve High Availability-related issues. The topics are divided into
subcategories. Browse the content or use the search feature to find relevant content.

High Availability sub categories

Cannot bring a resource online
Cannot failover a group
Cluster node is hanging
Cluster service fails to start
Cluster Shared Volume (CSV)
Cluster-Aware Updating (CAU)
Errors when running the Validation Wizard
Initial Cluster Creation or Adding node
Node removed from the cluster
Print clusters and High Availability Printing
Replacing hardware and updating the operating system
Root cause of an unexpected failover
Setup and configuration of clustered services and applications

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Route removed on Windows
Server Failover Cluster
Article • 12/26/2023

This article provides a solution to an issue that the Active route is removed when you
add a static persistent route to a network adapter.

Applies to: Windows Server 2012 R2

Original KB number: 2161341

Symptoms
When you add a static persistent route to a network adapter that is on a Windows
Server 2008 Failover Cluster and take a clustered IP Address offline (or move it to
another node), the "Active" route is removed and no connections can be made using
this route even though it still shows as persistent when running the ROUTE PRINT
command. Once you bring the Clustered IP Address back online, the active route is
returned.

Cause
When a clustered IP Address goes offline, it takes down the "active" route that was
added as a persistent route as well. This will only occur when both of the following are
true:

1. Windows Server 2008 or Server 2008 R2 Failover Clustering is configured

2. Static Routes are being added with ROUTE.EXE

Resolution
When using the ROUTE.EXE command, the most common command to add a persistent
would be this:

route -p add 10.51.0.0 mask 255.255.0.0 10.44.60.1

This command does not specify the specific interface to bind to. Because it is not bound
to a specific interface, it is removed as an active route. In the example above, the route
being specified to the gateway is the same card (network) that a Clustered IP Address is
on.
To keep the "active" route, you must also specify the interface as part of the command.
For example, if the network card interface is 18, the command would be: route -p add
10.51.0.0 mask 255.255.0.010.44.60.1 if 18*

More information
In Windows 2008 and above, the supported method for adding a persistent route is to
also include the network card interface. There are two methods to determine the
interface number of the network card. When executing the ROUTE PRINT or NETSH
command, it will give you the interfaces at the top first. Something similar to this:

Console

C:\>route print
IPv4 Route Table
========================================
Interface List
23 ...00 15 5d 4a ac 06 ...... Local Gigabit Controller
19 ...00 15 5d 4a ac 01 ...... Local Gigabit Controller #2
18 ...00 15 5d 4a ac 00 ...... Local Gigabit Controller #3
========================================

-or-

Console

C:\>netsh int ipv4 show int

Idx Met MTU State Name
--- --- ----- ----------- -------------------
18 50 4294967295 connected Local Gigabit Controller #3
19 5 1500 connected Local Gigabit Controller #2
23 5 1500 connected Local Gigabit Controller

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't bring a network name online in a
failover cluster
Article • 12/26/2023

Troubleshooting checklist
1. Review the system and the cluster log to find the exact errors or warnings that
prevent the network name from coming online. Usually, in addition to Event ID
1069, Event ID 1207 is also logged:

Event ID 1069

Error 1069 Microsoft-Windows-FailoverClustering Cluster resource

'<Name of the Resource>' of type '<Resource Type>' in clustered role
'<Available Storage>' failed.

Event ID 1207

Cluster network name resource 'Cluster Name' cannot be brought online.

The computer object associated with the resource could not be updated
in domain 'domainname.com' for the following reason.

2. Ensure that the Virtual Computer Object (VCO) or Cluster Name Object (CNO) has
appropriate permissions in Active Directory. For more information, see Prestage
Cluster Computer Objects in Active Directory Domain Services.

3. If CNO is affected, after adjusting the permissions, you can run the Repair option
to sync the AD password for the CNO again. For more information, see
Understanding the Repair Active Directory Object Recovery Action .

4. You can run a cluster validation (without the storage section) to check the
supportability of the cluster and see if there are any misconfigurations.

5. The CNO or VCO might not be able to come online because of DNS issues. The
permissions for the CNO or VCO records need to be checked as well. Network
traces will show the cause of the issue.

Common issues and solutions

For the following Event IDs, review the logs to find more information about the issue.

Event ID 1050
Cluster network name resource '%1' cannot be brought online because name '%2'
matches this cluster node name. Ensure that network names are unique.

Event ID 1051
Cluster network name resource '%1' cannot be brought online.

In a cluster, a Network Name resource can be important because other resources

depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

Event ID 1052
Cluster Network Name resource '%1' cannot be brought online because the name
could not be added to the system.

In a cluster, a Network Name resource can be important because other resources

depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

Event ID: 1211

Cluster network name resource '%1' cannot be brought online.

In a cluster, a Network Name resource can be important because other resources

depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

This event indicates that the cluster couldn't locate a writeable domain controller.

Event ID 1212
Cluster network name resource '%1' cannot be brought online.
 In a cluster, a Network Name resource can be important because other resources
depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

This event indicates that the cluster couldn't locate a writeable domain controller.

Event ID 1218
Cluster network name resource '%1' failed to perform a name change operation
(attempting to change original name '%3' to name '%4')

In a cluster, a Network Name resource can be important because other resources

depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

This event indicates that the cluster couldn't find the CNO in Active Directory. The next
time you try to bring the cluster online, it will try to recreate the CNO.

Event ID 1219
Cluster network name resource '%1' failed to perform a name change operation

In a cluster, a Network Name resource can be important because other resources

depend on it. A Network Name resource can come online only if it is configured
correctly, and is supported correctly by available networks and network
configurations.

This event indicates that the cluster couldn't contact a domain controller.

Review the logs to find more information about the issue

For Event ID 1050, 1051, 1052, 1211, 1212, 1218, and 1219, follow these steps:

1. Use Event Viewer to review the application and system logs.

７ Note

In particular, search for any events related to domain controller functionality.

 2. To search for information about an error code, use one of the following methods:

See system error codes.

At a command prompt, run the following command:

Console

NET HELPMSG <Code>

７ Note

The placeholder <Code> represents the error code.

3. Generate a fresh cluster log and review it. To generate a fresh cluster log,
reproduce the issue and open an elevated PowerShell prompt. At the elevated
PowerShell prompt, run the following cmdlet:

Get-ClusterLog -Destination C:\temp\ -TimeSpan 5 -UseLocalTime

If you identify an issue that you can fix, fix it and try to start the affected clustered
resource again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't bring an IP address online in a
failover cluster
Article • 12/26/2023

Troubleshooting checklist
1. Review the system and the cluster log to find the exact errors or warnings that
prevent the IP address from coming online.

2. Check the IP address for this resource and ensure that the status of the
corresponding cluster network is UP under Networks in Failover Cluster Manager.

3. If you create a new IP address within an empty group from the same cluster
network, does it come online?

4. Check the output of the ipconfig /all command and compare the information of
the affected network with a working one.

5. Disable or enable the Network Interface Card (NIC) that's corresponding to the
cluster network for the affected IP address.

6. Update the driver for the NIC or teaming.

Common issues and solutions

Try one of the following solutions according to the Event ID:

For Event ID 1046, 1047, 1048, 1049, 1078, and 1223, check the role that is
configured for a cluster network.

For Event ID 1360, 1361, and 1362, review the logs to find more information about
the issue.

Event ID 1046
Cluster IP address resource '%1' cannot be brought online because the subnet mask
value is invalid.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
 can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Event ID 1047
Cluster IP address resource '%1' cannot be brought online because the address
value is invalid.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Event ID 1048
Cluster IP address resource '%1' failed to come online.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Event ID 1049
Cluster IP address resource '%1' cannot be brought online because a duplicate IP
address '%2' was detected on the network.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Event ID 1078
Cluster IP address resource '%1' cannot be brought online because WINS
registration failed on interface '%2' with error '%3'.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.
This event indicates that there's a problem with the Windows Internet Name Service
(WINS) configuration.

Event ID 1223
Cluster IP address resource '%1' cannot be brought online because the cluster
network '%2' is not configured to allow client access.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Cluster networks are automatically created for all logical subnets connected to all
nodes in the Cluster. Each network adapter card connected to a common subnet will
be listed in Failover Cluster Manager. Cluster networks can be configured for
different uses.

Check the role that is configured for a cluster network

For Event ID 1046, 1047, 1048, 1049, 1078, and 1223, follow these steps:

1. In Failover Cluster Manager, if the cluster you want to configure isn't displayed, in
the console tree, right-click Failover Cluster Manager, select Manage a Cluster,
and then select or specify the cluster that you want.

2. If the console tree is collapsed, expand the tree under the cluster that you want to
configure.

3. Expand Networks.

4. Right-click the network that you want to check settings for and select Properties.

5. If you want to use this network for the cluster, make sure that the Allow the cluster
to use this network option is selected. If you select this option and want the
network to be used by clients (not just the nodes), make sure that the Allow clients
to connect through this network option is selected.

If you change any of the settings, try to bring the resource online again before you
proceed.

Event ID 1360
 Cluster IP address resource '%1' failed to come online.

A failover cluster requires network connectivity among nodes and between clients
and nodes. Problems with a network adapter or other network device (either
physical problems or configuration problems) can interfere with connectivity.

Event ID 1361
IPv6 Tunnel address resource '%1' failed to come online because it does not depend
on an IP Address (IPv4) resource.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

This event indicates that the correct dependencies aren't configured for the IPv6 Tunnel
Address resource.

Event ID 1362
Cluster IP address resource '%1' failed to come online because the '%2' property
could not be read.

In a cluster, an IP Address resource is important because in most cases, other

resources (such as a Network Name resource) depend on it. An IP Address resource
can come online only if it is configured correctly, and is supported correctly by
available networks and network configurations.

Review the logs to find more information about the issue

For Event ID 1360, 1361, and 1362, follow these steps:

1. Use Event Viewer to review the application and system logs.

７ Note

In particular, search for any events related to domain controller functionality.

2. To search for information about an error code, use one of the following methods:
 See system error codes.

At a command prompt, run the following command:

Console

NET HELPMSG <Code>

７ Note

The placeholder <Code> represents the error code.

3. Generate a fresh cluster log and review it. To generate a fresh cluster log,
reproduce the issue and open an elevated PowerShell prompt. At the elevated
PowerShell prompt, run the following cmdlet:

Get-ClusterLog -Destination C:\temp\ -TimeSpan 5 -UseLocalTime

If you identify an issue that you can fix, fix it and try to start the affected clustered
resource again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't bring a physical disk online in a
failover cluster
Article • 12/26/2023

Troubleshooting checklist
1. Review the system and the cluster log to find the exact errors or warnings that
prevent the physical disk from coming online.

2. Set the cluster log to a detail level of 5 to have verbose information from the
online attempt:

Set-ClusterLog -Level 5

3. Capture a performance monitor log or a Storport trace to check for poor disk
performance, which might delay the online process.

4. Cluster validation is useful in this scenario also. You can create a new cluster disk
from the same SAN and point the cluster validation to that disk.

5. If the cluster Resource Hosting Subsystem (Rhs.exe) process crashes during the
failed online attempt, then you need to configure the server to generate a full
memory dump and set the following registry keys:

For Windows Server 2012:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Failover
Clusters\DebugBreakOnDeadlock to DWORD 3.

For Windows Server 2012 R2:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\
DebugBreakOnDeadlock to DWORD 3.

７ Note

After the registry key is configured, the server on which the RHS deadlock
occurs displays a blue screen and generates a stop 0x9E memory dump. You
can then analyze it and address the cause.
Possible solutions
If disks read or write response times are slow (slow disk performance), contact the
storage vendor.

If the antivirus interferes with the online attempt, uninstall and reboot the server to
remove the filter drivers.

HBA or RAID controller drivers need to be updated.

Permissions on the root disks are missing.

If there are persistent reservation issues, the recommendation is to contact the

storage vendor to diagnose the issues.

Alternatively, you can run the Clear-ClusterDiskReservation -Disk <Number>

cmdlet to clear the persistent reservation.

７ Note

The placeholder <Number> represents the disk number.

Common issues and solutions

Event ID 1035
While disk resource '%1' was being brought online, access to one or more volumes
failed with error '%2'.

In a failover cluster, most clustered services or applications use at least one disk,
also called a disk resource, that you assign when you configure the clustered service
or application. Clients can use the clustered service or application only when the
disk is functioning correctly.

Review the logs to find more information about the issue

1. Use Event Viewer to review the application and system logs.

７ Note

In particular, search for any events related to domain controller functionality.

 2. To search for information about an error code, use one of the following methods:

See system error codes.

At a command prompt, run the following command:

Console

NET HELPMSG <Code>

７ Note

The placeholder <Code> represents the error code.

3. Generate a fresh cluster log and review it. To generate a fresh cluster log,
reproduce the issue and open an elevated PowerShell prompt. At the elevated
PowerShell prompt, run the following cmdlet:

Get-ClusterLog -Destination C:\temp\ -TimeSpan 5 -UseLocalTime

If you identify an issue that you can fix, fix it and try to bring the cluster resource online
again before you proceed.

７ Note

If you change the storage configuration, we recommend that you use the Validate a
Configuration wizard to validate the storage configuration.

Event ID 1183
Cluster disk resource '%1' contains an invalid mount point.

In a failover cluster, most clustered services or applications use at least one disk,
also called a disk resource, that you assign when you configure the clustered service
or application. Clients can use the clustered service or application only when the
disk is functioning correctly.

Check the disk configuration

Confirm that the mounted disk is configured according to the following guidelines:

Clustered disks can only be mounted onto clustered disks (not local disks).
 The mounted disk and the disk it's mounted onto must be part of the same
clustered service or application. The disks can't be in two different clustered
services or applications, and they can't be in the general pool of available storage
in the cluster.

For more information, see Use Cluster Shared Volumes in a failover cluster.

Generate a fresh cluster log that records the issue

To generate a fresh cluster log, reproduce the issue and open an elevated PowerShell
prompt. At the elevated PowerShell prompt, run the following cmdlet:

Get-ClusterLog -Destination C:\temp\ -TimeSpan 5 -UseLocalTime

If you identify an issue that you can fix, fix it and try to bring the resource online again
before you proceed.

Event ID 5394
The Cluster service encountered some storage errors while trying to bring storage
pool online.

Check the status of the disks

1. In Disk Management (available on the Storage menu in Server Manager), make
sure that the disks are healthy and connected.

2. In Computer Management (available on the Tools menu in Server Manager), select

Device Manager and make sure that the disks are online with the latest drivers and
firmware installed.

Use the Validate a Configuration wizard to review the storage

configuration

） Important

Be aware that the clustered service or application remains offline for the duration of
the storage validation testing.

1. In the Failover Cluster Manager snap-in, select Failover Cluster Management >
Management > Validate a Configuration.
 2. Follow the instructions in the wizard to specify the cluster you want to test.

3. On the Testing Options page, select Run only tests I select.

4. On the Test Selection page, clear all check boxes except those for the Storage and
Inventory tests that appear to be relevant to your situation.

5. Follow the instructions in the wizard to run the tests.

6. On the Summary page, select View Report.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A cluster disk resource may fail to come
online and run chkdsk when an invalid
character is used in the resource name
Article • 12/26/2023

This article provides help to solve an issue where the disk resource fails to come online
when the name of the cluster disk resource has an invalid character.

Applies to: Windows Server 2012 R2

Original KB number: 2590305

Symptoms
If the name of a Cluster disk resource has an invalid character in it from an NTFS
perspective '\' '/' character and there is some file on the root of the drive where the
cluster doesn't have READ permission or if the file is in use, then the disk resource fails
to come online.

Cause
The name of the 'Physical Disk' resource has a backslash or forward slash character in
the resource name. Example: "Disk G:\" and 'Local System' cannot open a handle to a file
at root of drive (whether because it's in use or permissions).

Resolution
To fix this issue, install hotfix 3033918 .

Workaround
To work around this issue, either remove the invalid character(s) in resource names for
'Physical Disk' resource types OR have 'Local System' account at least Read permission
to files at the root of the drive. After making the changes, you should be able to bring
the disk resource online.

７ Note
 It is not recommended to store files at the root of a clustered disk as the cluster
needs to open handles to files and folders as part of the health detection
mechanism used to determine possible access issues to storage. Since the cluster
service runs in the context of the 'Local System' account, if that account does not
have permission to files at the root of a drive, the health check may fail.

More information
Cluster tries to enumerate files on the disk during an Online event and if it is not able to
enumerate files on the root of the cluster disk, it would fail the disk.

A snippet from the cluster logs:

00001668.00001f88::<DateTime> WARN [RES] Physical Disk <G:\>: OnlineThread:

Failed to get volume guid for device \\?
\GLOBALROOT\Device\Harddisk2\Partition1\. Error 3
00001668.00001f88::<DateTime> WARN [RES] Physical Disk <G:\>: OnlineThread:
Failed to set volguid \??\Volume{aaeb0322-6921-11e0-a955-00155d50c903}. Error:
183.
00001668.00001f88::<DateTime> INFO [RES] Physical Disk <G:\>: Found 2 mount
points for device \Device\Harddisk2\Partition1
00001668.00001f88::<DateTime> INFO [RES] Physical Disk <G:\>: VolumeIsNtfs:
Volume \\?\GLOBALROOT\Device\Harddisk2\Partition1\ has FS type NTFS

00001668.00001f88::<DateTime> ERR [RES] Physical Disk <G:\>: VerifyFS: Failed to

open file \\?\GLOBALROOT\Device\Harddisk2\Partition1\kilo.docx Error: 5.
00001668.00001f88::<DateTime> ERR [RES] Physical Disk <G:\>: VerifyFS: Failed to
open file \\?\GLOBALROOT\Device\Harddisk2\Partition1\kilo.docx Error: 5.

00001668.00001f88::<DateTime> ERR [RES] Physical Disk <G:\>: OnlineThread: Error

123 bringing resource online.
00001668.00001e3c::<DateTime> ERR [RES] Physical Disk: Failed to get partition
size, status 3
00001668.00001e3c::<DateTime> ERR [RHS] Error 5023 from ResourceControl for
resource G:\.
00001920.00000808::<DateTime> WARN [RCM]
ResourceControl(STORAGE_GET_DIRTY) to G:\ returned 5023.

The disk gets marked as dirty as the name had an invalid character and would run
chkdsk before the disk is brought online successfully next time. Following events may be
noted in the system event log after you correct the problem and online the disk for the
first time.

Log Name: System

Source: Microsoft-Windows-FailoverClustering
Date: <DateTime>
Event ID: 1066
Task Category: Physical Disk Resource
Level: Warning
Keywords:
User: SYSTEM
Computer: XXXXXXXXXXX.com
Description: Cluster disk resource 'Cluster Disk 1' indicates corruption for volume
'\\?\Volume{aaeb0322-6921-11e0-a955-00155d50c903}'. Chkdsk is being run to
repair problems. The disk will be unavailable until Chkdsk completes. Chkdsk output
will be logged to file 'C:\Windows\Cluster\Reports\ChkDsk_ResCluster Disk
1_Disk2Part1.log'. Chkdsk may also write information to the Application Event Log.

Log Name: Application

Source: Chkdsk
Date: <DateTime>
Event ID: 26214
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: XXXXXXXXXXXXXXX.com
Description: Chkdsk was executed in read/write mode.

This does not indicate actual corruption on the disk. What happened is that cluster set
the dirty bit on the disk so chkdsk is run to verify an intact file system.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster fileshare resource fails on a
failover cluster node and the cluster log
contains "status 5. Tolerating..."
Article • 12/26/2023

This article provides a solution to an issue where cluster fileshare resource fails on a
failover cluster node.

Applies to: Windows Server 2012 R2

Original KB number: 2867302

Symptoms
Consider the following scenario:

In Windows Server 2008, 2008 R2 or 2012 you set up a Windows failover cluster
with a highly available file server.
The cluster nodes are configured with a disjointed namespace in which the
computer's primary DNS suffice does not match the DNS domain of which it is a
member.

In this scenario, you may notice that the highly available file server works fine on some
of the cluster nodes but consistently fails on others. In examining the cluster log, you
see something similar to the following entries with the first entry referring to "status 5.
Tolerating...":

00001b6c.000008c8::<DateTime> WARN [RES] File Server <FileServer-(yoel-cluster)

(Cluster Disk 6)>: Failed in NetShareGetInfo(yoel-cluster, share2), status 5.
Tolerating...
00001b6c.000008c8::<DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)
(Cluster Disk 6)>: Not a single share among 1 configured shares is online
00001b6c.000008c8::<DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)
(Cluster Disk 6)>: File system check failed, number of shares verified: 1, last share
status: 5.
00001b6c.000008c8::<DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)
(Cluster Disk 6)>: Fileshares failed health check during online, status 5.

Cause
One or more nodes of the failover cluster may contain mismatched entries in the DNS
suffix search list.

Resolution
To resolve the issue, verify all cluster nodes are configured with the same DNS suffix
search list and the entries are listed in the same order. The DNS suffix search list can be
modified using the following steps:

1. Open the properties page for the network adapter.

2. Open the properties page for Internet Protocol Version 4 (TCP/IPv4).
3. Select the Advanced button under the General tab.
4. Select the DNS tab.

More information
For additional information on the setup and use of a disjointed namespace, refer to the
following link:

Create a Disjoint Namespace

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Clustering Information on IP Address
Failover
Article • 12/26/2023

This article describes the clustering information on IP address failover.

Applies to: Windows Server 2012 R2

Original KB number: 168567

Summary
Microsoft Cluster Server (MSCS) provides the ability to define an IP address resource
within a cluster, and for it to failover from one node to another.

IP address failover ability depends on two things:

Support for dynamic registration and deregistration of IP addresses.

Ability to update the network address translation caches of other systems attached
to the subnet on which an address is registered.

Dynamic address registration and deregistration are already implemented within the
Microsoft Windows NT operating system to support the lease of IP addresses using the
Dynamic Host Configuration Protocol (DHCP).

Microsoft Cluster Server uses existing features within Windows NT for IP address
registration and deregistration. When the cluster component attempts to bring an IP
Address resource online, the software sends a command to the TCP/IP driver to register
the specified address. A similar command exists to unregister an address when the
corresponding resource is taken offline.

The cluster software updates the translation caches of other systems on the LAN
through the Address Resolution Protocol (ARP) specification (RFC 826), which is
implemented by Windows NT. The specification states that all systems receiving an ARP
request must update their IP Address to physical address mapping for the source of the
request (the source IP and physical network addresses are contained within the request).

Further, as part of the IP address registration process, the Windows NT TCP/IP driver
broadcasts an ARP request on the appropriate LAN several times. The request asks the
owner of the specified IP address to respond with its physical network address. By
sending these requests for the IP address being registered, Windows NT may detect IP
address conflicts; if a response is received, the address cannot be safely used.

When the driver sends these requests, Windows NT specifies the IP address being
registered as the source of the request. Thus, all systems on the network will update
their ARP cache entries for the specified address. Therefore, the registering system
becomes the new owner of the address.

７ Note

If an address conflict occurs, the responding system may send out another ARP
request for the same address, forcing the other systems on the subnet to update
their caches again. Windows NT does this when it detects a conflict with an address
that it has successfully registered.

More information
For additional information about related information, click the article number below to
view the article in the Microsoft Knowledge Base:

MAC Address Changes for Virtual Server During a Failover with Clustering

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster validation account causes events
or messages
Article • 12/26/2023

Applies to: Windows Server 2016, all editions, Windows Server 2012 R2 Datacenter

Symptoms
In a failover clustering environment, when you run the cluster validation process,
Windows creates a new user account. After this occurs, you might notice security events
or messages that describe this account. The account is temporary. Windows removes
the account when the cluster validation process ends.

More information
During the cluster validation process, Windows creates a user account that has the
following properties:

User name: CliTest2

Password: 12 characters
Group memberships: None

The cluster validation process uses this account to connect to clustered shares across
cluster nodes. When the cluster validation process ends, Windows deletes the account.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error messages occur if you try to bring
a cluster group online after a cluster
stops
Article • 12/26/2023

This article describes how to resolve the error messages when you try to bring a cluster
group online after a cluster stops.

Applies to: Windows Server 2012 R2

Original KB number: 313882

Symptoms
After you manually turn off a cluster, or after a cluster fails, a group and all of its
resources may fail over if the cluster suffers a loss of a node. However, the group may
also go into an offline state. If you try to bring either the group or the resource online,
you may receive the following error message:

An error occurred attempting to bring the 'GroupName' group online:

The cluster node is not the owner of the resource.

Error ID: 5015 (00001397).

If you try to bring an individual resource in the group online, you may receive either of
the following error messages:

An error occurred attempting to bring the 'ResourceName' resource online:

The cluster resource cannot be brought online. The owner node cannot run this
resource.

Error ID: 5071 (000013df).

-or-

No possible owners are specified for this resource. This means that this resource
cannot be brought online on any node in the cluster.
Cause
If you use the Move Group functionality to manually move a group from one node to
another, or if the cluster fails, a Possible Owners list is built for the entire group and for
all of the resources in the group. The behavior that is described in the "Summary"
section of this article can occur if one of the resources in the group that does not come
online does not have an online node listed in the Possible Owners list.

Resolution
To work around this behavior, bring the node that was taken offline back online. Move
the group back to the node that you just brought online, and then check the Possible
Owners list of each resource to verify that the node on which the group did not come
online is listed.

If you can't bring the node online because the node truly failed, add the proper node to
the Possible Owners list:

1. In Cluster Administrator, open the General properties of each resource and review
the Possible Owners list.

After you find the resource that has a blank Possible Owners list and a dimmed
Modify button, note the name of this resource

2. Open a command prompt, and type the following command. name of resource is
the name of the resource that you noted in step 1:

cluster res name of resource /listowners

A list of possible owners of the resource is displayed. This list indicates that the
only possible owner is the node that is down.

3. From the command prompt, run the following command to add the other node to
the Possible Owners list, where missing node is the node that is down:
cluster res name of resource /addowner: missing node

4. In Cluster Administrator, bring the group that was previously in the offline state
online again.

７ Note

After the group comes online, if you have problems reviewing the resources in
Cluster Administrator, quit Cluster Administrator, and then reconnect to the cluster.
Status
This behavior is by design.

More information
The Possible Owners list isn't useful on a cluster that has fewer than three nodes. The
Cluster service builds a list of possible owners for a group. The location on which the
group that contains that resource is hosted is affected if you change the Possible
Owners list for a resource. Internally, an ordered list is maintained for the location on
which the group is hosted. If you remove a possible owner for a resource, you remove
that node from the Possible Owners list.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Error 0x8000ffff: Catastrophic failure"
when you try to change Shadow Copy
settings for a drive in Windows Server
2008
Article • 12/26/2023

This article provides a solution to an error (Error 0x8000ffff: Catastrophic failure) that
occurs when you change Shadow Copy settings for a drive.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2973100

Symptoms
Consider the following scenario:

In Windows Server 2008, you open Windows Explorer, you right-click a drive, and
then you click Properties.
On the Shadow Copies tab, you select a drive letter and then click the Settings
button.

In this scenario, you receive the following error message:

Failed to initialize the Settings dialog for volume O:\

Error 0x8000ffff: Catastrophic failure

Additionally, the following event is logged in the Application log:

Log Name: Application Source: VSS Event ID: 12311 Task Category: None Level: Error
Description: Volume Shadow Copy Service error: Unexpected error pResource-
>get_Disk(&pDisk): hr = 0x80070490.

Cause
This problem occurs if there are disk resources in the failover cluster that don't have a
physical disk resource associated with them. This behavior may occur if you take a disk
resource offline and remove the associated disk from the server, but you don't delete
the disk resource in the failover cluster.
Resolution
In the failover cluster, delete the disk resource that no longer has a physical disk
associated with it.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Failover Clustering system log events
Article • 12/26/2023

This article lists the Failover Clustering events from the Windows Server System log (viewable in
Event Viewer). These events all share the event source of FailoverClustering and can be helpful when
troubleshooting a cluster.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI,
versions 21H2 and 20H2

Critical events

Event 1000: UNEXPECTED_FATAL_ERROR

Output

Cluster service suffered an unexpected fatal error at line %1 of source module

%2. The error code was %3.

Event 1001: ASSERTION_FAILURE

Output

Cluster service failed a validity check on line %1 of source module %2. '%3'

Event 1006: NM_EVENT_MEMBERSHIP_HALT

Output

Cluster service was halted due to incomplete connectivity with other cluster
nodes.

Event 1057: DM_DATABASE_CORRUPT_OR_MISSING

Output

The cluster database could not be loaded. The file may be missing or corrupt.
Automatic repair might be attempted.

Event 1070: NM_EVENT_BEGIN_JOIN_FAILED

Output
 The node failed to join failover cluster '%1' due to error code '%2'.

Event 1073: CS_EVENT_INCONSISTENCY_HALT

Output

The Cluster service was halted to prevent an inconsistency within the failover
cluster. The error code was '%1'.

Event 1080: CS_DISKWRITE_FAILURE

Output

The Cluster service failed to update the cluster database (error code '%1').
Possible causes are insufficient disk space or file system corruption.

Event 1090: CS_EVENT_REG_OPERATION_FAILED

Output

The Cluster service cannot be started. An attempt to read configuration data

from the Windows registry failed with error '%1'. Please use the Failover
Cluster Management snap-in to ensure that this machine is a member of a cluster.
If you intend to add this machine to an existing cluster use the Add Node
Wizard. Alternatively, if this machine has been configured as a member of a
cluster, it will be necessary to restore the missing configuration data that is
necessary for the Cluster Service to identify that it is a member of a cluster.
Perform a System State Restore of this machine in order to restore the
configuration data.

Event 1092: NM_EVENT_MM_FORM_FAILED

Output

Failed to form cluster '%1' with error code '%2'. Failover cluster will not be
available.

Event 1093: NM_EVENT_NODE_NOT_MEMBER

Output

The Cluster service cannot identify node '%1' as a member of failover cluster
'%2'. If the computer name for this node was recently changed, consider
reverting to the previous name. Alternatively, add the node to the failover
cluster and if necessary, reinstall clustered applications.
Event 1105: CS_EVENT_RPC_INIT_FAILED
Output

The Cluster service failed to start because it was unable to register

interface(s) with the RPC service. The error code was '%1'.

Event 1135: EVENT_NODE_DOWN

Output

Cluster node '%1' was removed from the active failover cluster membership. The
Cluster service on this node may have stopped. This could also be due to the
node having lost communication with other active nodes in the failover cluster.
Run the Validate a Configuration wizard to check your network configuration. If
the condition persists, check for hardware or software errors related to the
network adapters on this node. Also check for failures in any other network
components to which the node is connected such as hubs, switches, or bridges.

Event 1146: RCM_EVENT_RESMON_DIED

Output

The cluster Resource Hosting Subsystem (RHS) process was terminated and will be
restarted. This is typically associated with cluster health detection and
recovery of a resource. Refer to the System event log to determine which
resource and resource DLL is causing the issue.

Event 1177: MM_EVENT_ARBITRATION_FAILED

Output

The Cluster service is shutting down because quorum was lost. This could be due
to the loss of network connectivity between some or all nodes in the cluster, or
a failover of the witness disk.

Run the Validate a Configuration wizard to check your network configuration. If

the condition persists, check for hardware or software errors related to the
network adapter. Also check for failures in any other network components to
which the node is connected such as hubs, switches, or bridges.

Event 1181: NETRES_RESOURCE_START_ERROR

Output

Cluster resource '%1' cannot be brought online because the associated service
failed to start. The service return code is '%2'. Please check for additional
events associated with the service and ensure the service starts correctly.
Event 1247: CLUSTER_EVENT_INVALID_SERVICE_SID_TYPE
Output

The Security Identifier (SID) type for the cluster service is configured as '%1'
but the expected SID type is 'Unrestricted'. The cluster service is
automatically modifying its SID type configuration with the Service Control
Manager (SCM) and will restart in order for this change to take effect.

Event 1248: CLUSTER_EVENT_SERVICE_SID_MISSING

Output

The Security Identifier (SID) '%1' associated with the cluster service is not
present in the process token. The cluster service will automatically correct
this problem and restart.

Event 1282: SM_EVENT_HANDSHAKE_TIMEOUT

Output

Security Handshake between local and remote endpoints '%2' did not complete in
'%1' seconds, node terminating the connection

Event 1542: SERVICE_PRERESTORE_FAILED

Output

The restore request for the cluster configuration data has failed. This restore
failed during the 'pre-restore' stage usually indicating that some nodes
comprising the cluster are not currently operational. Ensure that the cluster
service is running successfully on all nodes comprising this cluster.

Event 1543: SERVICE_POSTRESTORE_FAILED

Output

The restore operation of the cluster configuration data has failed. This restore
failed during the 'post-restore' stage usually indicating that some nodes
comprising the cluster are not currently operational. It is recommended that you
replace the current cluster configuration data file (ClusDB) with '%1'.

Event 1546: SERVICE_FORM_VERSION_INCOMPATIBLE

Output
 Node '%1' failed to form a failover cluster. This was due to one or more nodes
executing incompatible versions of the cluster service software. If node '%1' or
a different node in the cluster has been recently upgraded, please re-verify
that all nodes are executing compatible versions of the cluster service
software.

Event 1547: SERVICE_CONNECT_VERSION_INCOMPATIBLE

Output

Node '%1' attempted to join a failover cluster but failed due to incompatibility
between versions of the cluster service software. If node '%1' or a different
node in the cluster has been recently upgraded, please verify that the changed
cluster deployment with different versions of the cluster service software is
supported.

Event 1553: SERVICE_NO_NETWORK_CONNECTIVITY

Output

This cluster node has no network connectivity. It cannot participate in the

cluster until connectivity is restored. Run the Validate a Configuration wizard
to check your network configuration. If the condition persists, check for
hardware or software errors related to the network adapter. Also check for
failures in any other network components to which the node is connected such as
hubs, switches, or bridges.

Event 1554: SERVICE_NETWORK_CONNECTIVITY_LOST

Output

This cluster node has lost all network connectivity. It cannot participate in the
cluster until connectivity is restored. The cluster service on this node
will be terminated.

Event 1556:
SERVICE_UNHANDLED_EXCEPTION_IN_WORKER_THREAD
Output

The cluster service encountered an unexpected problem and will be shut down. The error
code was '%2'.

Event 1561: SERVICE_NONSTORAGE_WITNESS_BETTER_TAG

Output
 Cluster service failed to start because this node detected that it does not have
the latest copy of cluster configuration data. Changes to the cluster occurred
while this node was not in membership and as a result was not able to receive
configuration data updates.

Guidance
Attempt to start the cluster service on all nodes in the cluster so that nodes with the latest copy of
the cluster configuration data can first form the cluster. This node will then be able join the cluster
and will automatically obtain the updated cluster configuration data. If there are no nodes available
with the latest copy of the cluster configuration data, run the Start-ClusterNode -FQ Windows
PowerShell cmdlet. Using the ForceQuorum (FQ) parameter will start the cluster service and mark this
node's copy of the cluster configuration data to be authoritative. Forcing quorum on a node with an
outdated copy of the cluster database may result in cluster configuration changes that occurred
while the node was not participating in the cluster to be lost.

Event 1564: RES_FSW_ARBITRATEFAILURE

Output

File share witness resource '%1' failed to arbitrate for the file share '%2'.
Please ensure that file share '%2' exists and is accessible by the cluster.

Event 1570: SERVICE_CONNECT_AUTHENTICATION_FAILURE

Output

Node '%1' failed to establish a communication session while joining the cluster.
This was due to an authentication failure. Please verify that the nodes are
running compatible versions of the cluster service software.

Event 1571: SERVICE_CONNECT_AUTHORIZAION_FAILURE

Output

Node '%1' failed to establish a communication session while joining the cluster.
This was due to an authorization failure. Please verify that the nodes are
running compatible versions of the cluster service software.

Event 1572: SERVICE_NETFT_ROUTE_INITIAL_FAILURE

Output

Node '%1' failed to join the cluster because it could not send and receive
failure detection network messages with other cluster nodes. Please run the
 Validate a Configuration wizard to ensure network settings. Also verify the
Windows Firewall 'Failover Clusters' rules.

Event 1574: DM_DATABASE_UNLOAD_FAILED

Output

The failover cluster database could not be unloaded. If restarting the cluster
service does not fix the problem, please restart the machine.

Event 1575: DM_DATABASE_CORRUPT_OR_MISSING_FIXQUORUM

Output

An attempt to forcibly start the cluster service has failed because the cluster
configuration data on this node is either missing or corrupt. Please first start
the cluster service on another node that has an intact and valid copy of the
cluster configuration data. Then, reattempt the start operation on this node
(which will attempt to obtain updated valid configuration information
automatically). If no other node is available, please use WBAdmin.msc to perform
a System State Restore of this node in order to restore the configuration data.

Event 1593: DM_COULD_NOT_DISCARD_CHANGES

Output

The failover cluster database could not be unloaded and any potentially
incorrect changes in memory could not be discarded. The cluster service will
attempt to repair the database by retrieving it from another cluster node. If
the cluster service does not come online, restart the cluster service on this
node. If restarting the cluster service does not fix the problem, please restart
the machine. If the cluster service fails to come online after a reboot, please
restore the cluster database from the last backup. The current database was
copied to '%1'. If no backups are available, please copy '%1' to '%2' and
attempt to start the cluster service. If the cluster service then comes online
on this node, some cluster configuration changes may be lost and the cluster may
not function properly. Run the Validate a Configuration wizard to check your
cluster configuration and verify that the hosted Services and Applications are
online and functioning correctly.

Event 1672: EVENT_NODE_QUARANTINED

Output

Cluster node '%1' has been quarantined. The node experienced '%2' consecutive
failures within a short amount of time and has been removed from the cluster to
avoid further disruptions. The node will be quarantined until '%3' and then the
node will automatically attempt to re-join the cluster.

Refer to the System and Application event logs to determine the issues on this
node. When the issue is resolved, quarantine can be manually cleared to allow
 the node to rejoin with the 'Start-ClusterNode -ClearQuarantine' Windows
PowerShell cmdlet.

Node Name : %1

Number of consecutive cluster membership loses: %2

Time quarantine will be automatically cleared: %3

Error events

Event 1024: CP_REG_CKPT_RESTORE_FAILED

Output

The registry checkpoint for cluster resource '%1' could not be restored to
registry key HKEY_LOCAL_MACHINE\%2. The resource may not function correctly.
Make sure that no other processes have open handles to registry keys in this
registry subtree.

Event 1034: RES_DISK_MISSING

Output

Cluster physical disk resource '%1' cannot be brought online because the
associated disk could not be found. The expected signature of the disk was '%2'.
If the disk was replaced or restored, in the Failover Cluster Manager snap-in,
you can use the Repair function (in the properties sheet for the disk) to repair
the new or restored disk. If the disk will not be replaced, delete the
associated disk resource.

Event 1035: RES_DISK_MOUNT_FAILED

Output

While disk resource '%1' was being brought online, access to one or more volumes
failed with error '%2'. Run the Validate a Configuration wizard to check your
storage configuration. Optionally you may want to run Chkdsk to verify the
integrity of all volumes on this disk.

Event 1037: RES_DISK_FILESYSTEM_FAILED

Output

The file system for one or more partitions on the disk for resource '%1' may be
corrupt. Run the Validate a Configuration wizard to check your storage
configuration. Optionally, you may want to run Chkdsk to verify the integrity of
all volumes on this disk.
Event 1038: RES_DISK_RESERVATION_LOST
Output

Ownership of cluster disk '%1' has been unexpectedly lost by this node. Run the
Validate a Configuration wizard to check your storage configuration.

Event 1039: RES_GENAPP_CREATE_FAILED

Output

Generic application '%1' could not be brought online (with error '%2') during an
attempt to create the process. Possible causes include: the application may not
be present on this node, the path name may have been specified incorrectly, the
binary name may have been specified incorrectly.

Event 1040: RES_GENSVC_OPEN_FAILED

Output

Generic service '%1' could not be brought online (with error '%2') during an
attempt to open the service. Possible causes include: the service is either not
installed or the specified service name is invalid.

Event 1041: RES_GENSVC_START_FAILED

Output

Generic service '%1' could not be brought online (with error '%2') during an
attempt to start the service. Possible cause: the specified service parameters
might be invalid.

Event 1042: RES_GENSVC_FAILED_AFTER_START

Output

Generic service '%1' failed with error '%2'. Please examine the application
event log.

Event 1044: RES_IPADDR_NBT_INTERFACE_CREATE_FAILED

Output

Encountered a failure when attempting to create a new NetBIOS interface while

bringing resource '%1' online (error code '%2'). The maximum number of NetBIOS
names may have been exceeded.
Event 1046: RES_IPADDR_INVALID_SUBNET
Output

Cluster IP address resource '%1' cannot be brought online because the subnet
mask value is invalid. Please check your IP address resource properties.

Event 1047: RES_IPADDR_INVALID_ADDRESS

Output

Cluster IP address resource '%1' cannot be brought online because the address
value is invalid. Please check your IP address resource properties.

Event 1048: RES_IPADDR_INVALID_ADAPTER

Output

Cluster IP address resource '%1' failed to come online. Configuration data for
the network adapter corresponding to cluster network interface '%2' could not be
determined (error code was '%3'). Please check that the IP address resource is
configured with the correct address and network properties.

Event 1049: RES_IPADDR_IN_USE

Output

Cluster IP address resource '%1' cannot be brought online because a duplicate IP

address '%2' was detected on the network. Please ensure all IP addresses are
unique.

Event 1050: RES_NETNAME_DUPLICATE

Output

Cluster network name resource '%1' cannot be brought online because name '%2'
matches this cluster node name. Ensure that network names are unique.

Event 1051: RES_NETNAME_NO_IP_ADDRESS

Output

Cluster network name resource '%1' cannot be brought online. Ensure that the
network adapters for dependent IP address resources have access to at least one
DNS server. Alternatively, enable NetBIOS for dependent IP addresses.
Event 1052: RES_NETNAME_CANT_ADD_NAME_STATUS
Output

Cluster Network Name resource '%1' cannot be brought online because the name
could not be added to the system. The associated error code is stored in the
data section.

Event 1053: RES_SMB_CANT_CREATE_SHARE

Output

Cluster File Share '%1' cannot be brought online because the share could not be
created.

Event 1054: RES_SMB_SHARE_NOT_FOUND

Output

Health check for file share resource '%1' failed. Retrieving information for
share '%2' (scoped to network name %3) returned error code '%4'. Ensure the
share exists and is accessible.

Event 1055: RES_SMB_SHARE_FAILED

Output

Health check for file share resource '%1' failed. Retrieving information for
share '%2' (scoped to network name %3) indicated that the share does not exist
(error code '%4'). Please ensure the share exists and is accessible.

Event 1069: RCM_RESOURCE_FAILURE

Output

Cluster resource '%1' in clustered role '%2' failed.

Event 1069: RCM_RESOURCE_FAILURE_WITH_TYPENAME

Output

Cluster resource '%1' of type '%3' in clustered role '%2' failed.

Based on the failure policies for the resource and role, the cluster service may try to
bring the resource online on this node or move the group to another node of the
 cluster and then restart it. Check the resource and group state using Failover
Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

Event 1069: RCM_RESOURCE_FAILURE_WITH_CAUSE

Output

Cluster resource '%1' of type '%3' in clustered role '%2' failed. The error code
was '%5' ('%4').

Based on the failure policies for the resource and role, the
cluster service may try to bring the resource online on this node or move the
group to another node of the cluster and then restart it. Check the resource and
group state using Failover Cluster Manager or the Get-ClusterResource Windows
PowerShell cmdlet.

Event 1069: RCM_RESOURCE_FAILURE_WITH_ERROR_CODE

Output

Cluster resource '%1' of type '%3' in clustered role '%2' failed. The error code
was '%4'.

Based on the failure policies for the resource and role, the
cluster service may try to bring the resource online on this node or move the
group to another node of the cluster and then restart it. Check the resource and
group state using Failover Cluster Manager or the Get-ClusterResource Windows
PowerShell cmdlet.

Event 1069: RCM_RESOURCE_FAILURE_DUE_TO_VETO

Output

Cluster resource '%1' of type '%3' in clustered role '%2' failed due to an
attempt to block a required state change in that cluster resource.

Event 1077: RES_IPADDR_IPV4_ADDRESS_INTERFACE_FAILED

Output

Health check for IP interface '%1' (address '%2') failed (status is '%3'). Run
the Validate a Configuration wizard to ensure that the network adapter is
functioning properly.

Event 1078: RES_IPADDR_WINS_ADDRESS_FAILED

Output
 Cluster IP address resource '%1' cannot be brought online because WINS
registration failed on interface '%2' with error '%3'. Ensure that a valid,
accessible WINS server has been specified.

Event 1121: CP_CRYPTO_CKPT_RESTORE_FAILED

Output

Encrypted settings for cluster resource '%1' could not be successfully applied
to the container name '%2' on this node.

Event 1127: TM_EVENT_CLUSTER_NETINTERFACE_FAILED

Output

Cluster network interface '%1' for cluster node '%2' on network '%3' failed. Run
the Validate a Configuration wizard to check your network configuration. If the
condition persists, check for hardware or software errors related to the network
adapter. Also check for failures in any other network components to which the
node is connected such as hubs, switches, or bridges.

Event 1129: TM_EVENT_CLUSTER_NETWORK_PARTITIONED

Output

Cluster network '%1' is partitioned. Some attached failover cluster nodes cannot
communicate with each other over the network. The failover cluster was not able
to determine the location of the failure. Run the Validate a Configuration
wizard to check your network configuration. If the condition persists, check for
hardware or software errors related to the network adapter. Also check for
failures in any other network components to which the node is connected such as
hubs, switches, or bridges.

Event 1130: TM_EVENT_CLUSTER_NETWORK_DOWN

Output

Cluster network '%1' is down. None of the available nodes can communicate using
this network. Run the Validate a Configuration wizard to check your network
configuration. If the condition persists, check for hardware or software errors
related to the network adapter. Also check for failures in any other network
components to which the node is connected such as hubs, switches, or bridges.

Event 1137: RCM_DRAIN_MOVE_FAILED

Output
 Move of cluster role '%1' for drain could not be completed. The operation failed
with error code %2.

Event 1138: RES_SMB_CANT_CREATE_DFS_ROOT

Output

Cluster file share resource '%1' cannot be brought online. Creation of DFS
namespace root failed with error '%3'. This may be due to failure to start the
'DFS Namespace' service or failure to create the DFS-N root for share '%2'.

Event 1141: RES_SMB_CANT_INIT_DFS_SVC

Output

Cluster file share resource '%1' cannot be brought online. Resynchronization of

DFS root target '%2' failed with error '%3'.

Event 1142: RES_SMB_CANT_ONLINE_DFS_ROOT

Output

Cluster file share resource '%1' for DFS Namespace cannot be brought online due
to error '%2'.

Event 1182: NETRES_RESOURCE_STOP_ERROR

Output

Cluster resource '%1' cannot be brought online because the associated service
failed an attempted restart. The error code is '%2'. The service required a
restart in order to update parameters. However, the service failed before it
could be stopped and restarted. Please check for additional events associated
with the service and ensure the service is functioning correctly.

Event 1183: RES_DISK_INVALID_MP_SOURCE_NOT_CLUSTERED

Output

Cluster disk resource '%1' contains an invalid mount point. Both the source and
target disks associated with the mount point must be clustered disks, and must
be members of the same group.

Mount point '%2' for volume '%3' references an

invalid source disk. Please ensure that the source disk is also a clustered disk
and in the same group as the target disk (hosting the mount point).
Event 1191:
RES_NETNAME_DELETE_COMPUTER_ACCOUNT_FAILED_STATUS
Output

Cluster network name resource '%1' failed to delete its associated computer
object in domain '%2'. The error code was '%3'.

Please have a domain administrator manually delete the computer object from the Active
Directory domain.

Event 1192:
RES_NETNAME_DELETE_COMPUTER_ACCOUNT_FAILED
Output

Cluster network name resource '%1' failed to delete its associated computer
object in domain '%2' for the following reason: %3.

Please have a domain administrator manually delete the computer object from the Active
Directory domain.

Event 1193:
RES_NETNAME_ADD_COMPUTER_ACCOUNT_FAILED_STATUS
Output

Cluster network name resource '%1' failed to create its associated computer
object in domain '%2' for the following reason: %3.

The associated error code is: %5

Please work with your domain administrator to ensure that:

- The cluster identity '%4' can create computer objects. By default all computer
objects are created in the 'Computers' container; consult the domain
administrator if this location has been changed.
- The quota for computer objects has not been reached.
- If there is an existing computer object, verify
the Cluster Identity '%4' has 'Full Control' permission to that computer object
using the Active Directory Users and Computers tool.

Event 1194: RES_NETNAME_ADD_COMPUTER_ACCOUNT_FAILED

Output

Cluster network name resource '%1' failed to create its associated computer
object in domain '%2' during: %3.

The text for the associated error code is: %4

 Please work with your domain administrator to ensure that:

- The cluster identity '%5' has Create Computer Objects permissions. By default all
computer
objects are created in the same container as the cluster identity '%5'.
- The quota for computer objects has not been reached.
- If there is an existing computer object, verify the Cluster Identity '%5' has 'Full
Control' permission
to that computer object using the Active Directory Users and Computers tool.

Event 1195: RES_NETNAME_DNS_REGISTRATION_FAILED_STATUS

Output

Cluster network name resource '%1' failed registration of one or more associated
DNS name(s). The error code was '%2'. Ensure that the network adapters
associated with dependent IP address resources are configured with access to at
least one DNS server.

Event 1196: RES_NETNAME_DNS_REGISTRATION_FAILED

Output

Cluster network name resource '%1' failed registration of one or more associated
DNS name(s) for the following reason: %2.

Ensure that the network adapters associated with dependent IP address resources are
configured with at least one accessible DNS server.

Event 1205: RCM_EVENT_GROUP_FAILED_ONLINE_OFFLINE

Output

The Cluster service failed to bring clustered role '%1' completely online or
offline. One or more resources may be in a failed state. This may impact the
availability of the clustered role.

Event 1206:
RES_NETNAME_UPDATE_COMPUTER_ACCOUNT_FAILED_STATUS
Output

The computer object associated with the cluster network name resource '%1' could not be
updated in domain '%2'. The error code was '%3'. The cluster identity '%4' may lack
permissions required to update the object. Please work with your domain administrator
to ensure that the cluster identity can update computer objects in the domain.
Event 1207:
RES_NETNAME_UPDATE_COMPUTER_ACCOUNT_FAILED
Output

The computer object associated with the cluster network name resource '%1' could
not be updated in domain '%2' during the %3 operation.

The text for the associated error code is: %4

The cluster identity '%5' may lack permissions required to update the object. Please
work with your domain administrator to ensure that the cluster identity can update
computer objects in the domain.

Event 1208: RES_DISK_INVALID_MP_TARGET_NOT_CLUSTERED

Output

Cluster disk resource '%1' contains an invalid mount point. Both the source and
target disks associated with the mount point must be clustered disks, and must
be members of the same group.

Mount point '%2' for volume '%3' references an invalid target disk. Please ensure that
the target disk is also a clustered disk and in the same group as the source disk
(hosting the mount point).

Event 1211: RES_NETNAME_NO_WRITEABLE_DC_STATUS

Output

Cluster network name resource '%1' cannot be brought online. Attempt to locate a
writeable domain controller (in domain %2) in order to create or update a
computer object associated with the resource failed. The error code was '%3'.
Ensure that a writeable domain controller is accessible to this node within the
configured domain. Also ensure that the DNS server is running in order to
resolve the name of the domain controller.

Event 1212: RES_NETNAME_NO_WRITEABLE_DC

Output

Cluster network name resource '%1' cannot be brought online. Attempt to locate a
writeable domain controller (in domain %2) in order to create or update a
computer object associated with the resource failed for the following
reason: %3.

The error code was '%4'. Ensure that a writeable domain

controller is accessible to this node within the configured domain. Also ensure
that the DNS server is running in order to resolve the name of the domain
controller.
Event 1213: RES_NETNAME_RENAME_RESTORE_FAILED
Output

Cluster network name resource '%1' could not completely rename the associated
computer object on domain controller '%2'. Attempting to rename the computer
object from new name '%3' back to its original name '%4' has also failed. The
error code was '%5'. This may affect client connectivity until the network name
and its associated computer object name are consistent. Contact your domain
administrator to manually rename the computer object.

Event 1214: RES_NETNAME_CANT_ADD_NAME2

Output

Cluster Network Name resource cannot be registered with Netbios.

Network Name: '%3'

Reason for failure: %2
Resource name:'%1'

Run nbtstat for the network name to ensure that the name is not already registered with
Netbios.

Event 1215: RES_NETNAME_NOT_REGISTERED_WITH_RDR

Output

Cluster network name resource '%1' failed a health check. Network name '%2' is
no longer registered on this node. The error code was '%3'. Check for hardware
or software errors related to the network adapter. Also, you can run the
Validate a Configuration wizard to check your network configuration.

Event 1218:
RES_NETNAME_ONLINE_RENAME_RECOVERY_MISSING_ACCOUNT
Output

Cluster network name resource '%1' failed to perform a name change operation
(attempting to change original name '%3' to name '%4'). The computer object
could not be found on the domain controller '%2' (where it was created). An
attempt will be made to recreate the computer object the next time the resource
is brought online. Additionally, please work with your domain administrator to
ensure that the computer object exists in the domain.

Event 1219: RES_NETNAME_ONLINE_RENAME_DC_NOT_FOUND

Output
 Cluster network name resource '%1' failed to perform a name change operation.
The domain controller '%2' where computer object '%3' was being renamed, could
not be contacted. The error code was '%4'. Ensure a writeable domain controller
is accessible and check for any connectivity issue.

Event 1220: RES_NETNAME_ONLINE_RENAME_RECOVERY_FAILED

Output

The computer account for resource '%1' failed to be renamed from %2 to %3 using
Domain Controller %4. The associated error code is stored in the data section.

The computer account for this resource was in the process of being renamed and
did not complete. This was detected during the online process for this resource.
In order to recover, the computer account must be renamed to the current value
of the Name property, i.e., the name presented on the network.

The Domain Controller where the renamed was attempted might not be available; if this
is
the case, wait for the Domain Controller to be available again. The Domain
Controller could be denying access to the account; after resolving access, try
to bring the name online again.

If this is not possible, disable and re-enable Kerberos Authentication and an attempt
will be made to find the computer account on a different DC. You need to change the
Name property to %2
in order to use the existing computer account.

Event 1223: RES_IPADDR_INVALID_NETWORK_ROLE

Output

Cluster IP address resource '%1' cannot be brought online because the cluster
network '%2' is not configured to allow client access. Please use the Failover
Cluster Manager snap-in to check the configured properties of the cluster
network.

Event 1226: RES_NETNAME_TCB_NOT_HELD

Output

Network Name resource '%1' (with associated network name '%2') has Kerberos
Authentication support enabled. Failed to add required credentials to the LSA -
the associated error code '%3' indicates insufficient privileges normally
required for this operation. The required privilege is 'Trusted Computing Base'
and must be locally enabled on each node comprising the cluster.

Event 1227: RES_NETNAME_LSA_ERROR

Output
 Network Name resource '%1' (with associated network name '%2') has Kerberos
Authentication support enabled. Failed to add required credentials to the LSA -
the associated error code is '%3'.

Event 1228: RES_NETNAME_CLONE_FAILURE

Output

Cluster network name resource '%1' encountered an error enabling the network
name on this node. The reason for the failure was: '%2'.

The error code was '%3'.

You may take the network name resource offline and online again to retry.

Event 1229: RES_NETNAME_NO_IPS_FOR_DNS

Output

Cluster network name resource '%1' was unable to identify any IP addresses to
register with a DNS server. Ensure that there is one or more networks that are
enabled for cluster use with the 'Allow clients to connect through this network'
setting, and that each node has a valid IP address configured for the networks.

Event 1230: RCM_DEADLOCK_OR_CRASH_DETECTED

Output

A component on the server did not respond in a timely fashion. This caused the
cluster resource '%1' (resource type '%2', DLL '%3') to exceed its time-out
threshold. As part of cluster health detection, recovery actions will be taken.
The cluster will try to automatically recover by terminating and restarting the
Resource Hosting Subsystem (RHS) process that is running this resource. Verify
that the underlying infrastructure (such as storage, networking, or services)
that are associated with the resource are functioning correctly.

Event 1230: RCM_RESOURCE_CONTROL_DEADLOCK_DETECTED

Output

A component on the server did not respond in a timely fashion. This caused the
cluster resource '%1' (resource type '%2', DLL '%3') to exceed its time-out
threshold while processing control code '%4;'. As part of cluster health
detection, recovery actions will be taken. The cluster will try to automatically
recover by terminating and restarting the Resource Hosting Subsystem (RHS)
process that is running this resource. Verify that the underlying infrastructure
(such as storage, networking, or services) that are associated with the resource
are functioning correctly.
Event 1231: RES_NETNAME_LOGON_FAILURE
Output

Cluster network name resource '%1' encountered an error logging on to the

domain. The reason for the failure was: '%2'.

The error code was '%3'.

Ensure that a domain controller is accessible to this node within the

configured domain.

Event 1232: RES_GENSCRIPT_TIMEOUT

Output

Entry point '%2' in cluster generic script resource '%1' did not complete
execution in a timely manner. This could be due to an infinite loop or other
issues possibly resulting in an infinite wait. Alternatively, the specified
pending timeout value may be too short for this resource. Please review the '%2'
script entry point to ensure all possible infinite waits in the script code have
been corrected. Then, consider increasing the pending timeout value if deemed
necessary.

Event 1233: RES_GENSCRIPT_HANGMODE

Output

Cluster generic script resource '%1': request to perform the '%2' operation will
not be processed. This is due to a previously failed attempt to execute the '%3'
entry point in a timely fashion. Please review the script code for this entry
point to ensure there does not exist any infinite loop or other issues possibly
resulting in an infinite wait. Then, consider increasing the resource pending
timeout value if deemed necessary.

Event 1234: CLUSTER_EVENT_ACCOUNT_MISSING_PRIVS

Output

The Cluster service has detected that its service account is missing one or more
of the required privileges. The missing privilege list is: '%1' and is not
currently granted to the service account. Use the 'sc.exe qprivs clussvc' to
verify the privileges of the Cluster service (ClusSvc). Additionally check for
any security policies or group policies in Active Directory Domain Services that
may have altered the default privileges. Type the following command to grant the
Cluster service the necessary privileges to function correctly:

sc.exe privs
clussvc
SeBackupPrivilege/SeRestorePrivilege/SeIncreaseQuotaPrivilege/SeIncreaseBasePriorityPri
vilege/SeTcbPrivilege/SeDebugPrivilege/SeSecurityPrivilege/SeAuditPrivilege/SeImpersona
 tePrivilege/SeChangeNotifyPrivilege/SeIncreaseWorkingSetPrivilege/SeManageVolumePrivile
ge/SeCreateSymbolicLinkPrivilege/SeLoadDriverPrivilege

Event 1242: RES_IPADDR_LEASE_EXPIRED

Output

Lease of IP address '%2' associated with cluster IP address resource '%1' has
expired or is about to expire, and currently cannot be renewed. Ensure that the
associated DHCP server is accessible and properly configured to renew the lease
on this IP address.

Event 1245: RES_IPADDR_LEASE_RENEWAL_FAILED

Output

Cluster IP address resource '%1' failed to renew the lease for IP address '%2'.
Ensure that the DHCP server is accessible and properly configured to renew the
lease on this IP address.

Event 1250: RCM_RESOURCE_EMBEDDED_FAILURE

Output

Cluster resource '%1' in clustered role '%2' has received a critical state
notification. For a virtual machine this indicates that an application or
service inside the virtual machine is in an unhealthy state. Verify the
functionality of the service or application being monitored within the virtual
machine.

Event 1254: RCM_GROUP_TERMINAL_FAILURE

Output

Clustered role '%1' has exceeded its failover threshold. It has exhausted the
configured number of failover attempts within the failover period of time
allotted to it and will be left in a failed state. No additional attempts will
be made to bring the role online or fail it over to another node in the cluster.
Please check the events associated with the failure. After the issues causing
the failure are resolved the role can be brought online manually or the cluster
may attempt to bring it online again after the restart delay period.

Event 1255: RCM_RESOURCE_NETWORK_FAILURE

Output

Cluster resource '%1' in clustered role '%2' has received a critical state
notification. For a virtual machine this indicates that a critical network of
 the virtual machine is in an unhealthy state. Verify the network connectivity of
the virtual machine and the virtual networks that the virtual machine is
configured to use.

Event 1256:
RES_NETNAME_DNS_REGISTRATION_FAILED_DYNAMIC_DNS_ZONE
Output

Cluster network name resource failed registration of one or more associated DNS
names(s) because the corresponding DNS Zone does not accept dynamic
updates.

Cluster Network name: '%1'

DNS Zone: '%2'

Guidance
Ensure that the DNS is configured as a Dynamic DNS zone. If the DNS server does not accept
dynamic updates uncheck the 'Register this connection's' addresses in DNS' in the properties of the
network adapter.

Event 1257:
RES_NETNAME_DNS_REGISTRATION_FAILED_SECURE_DNS_ZONE
Output

Cluster network name resource failed registration of one or more associated DNS
names(s) because the access to update the secure DNS Zone was denied.

Cluster Network name: '%1'

DNS Zone: '%2'

Ensure that cluster name object (CNO) is

granted permissions to the Secure DNS Zone.

Event 1258:
RES_NETNAME_DNS_REGISTRATION_FAILED_TIMEOUT
Output

Cluster network name resource failed registration of one or more associated DNS
name(s) because the a DNS server could not be reached.

Cluster Network name: '%1'

DNS Zone: '%2'
DNS Server: '%3'

Ensure that the network adapters

 associated with dependent IP address resources are configured with at least one
accessible DNS server.

Event 1259:
RES_NETNAME_DNS_REGISTRATION_FAILED_CLEANUP
Output

Cluster network name resource failed registration of one or more associated DNS
name(s) because the cluster service failed clean up the existing records
corresponding to the network name.

Cluster Network name: '%1'

DNS Zone: '%2'

Ensure that cluster name object (CNO) is granted permissions to the

Secure DNS Zone.

Event 1260: RES_NETNAME_DNS_REGISTRATION_MODIFY_FAILED

Output

Cluster network name resource failed to modify the DNS registration.

Cluster Network name: '%1'

Error code: '%2'

Guidance

Ensure that the network adapters associated with dependent IP address resources are configured
with access to at least one DNS server.

Event 1261:
RES_NETNAME_DNS_REGISTRATION_MODIFY_FAILED_STATUS
Output

Cluster network name resource failed to modify the DNS registration.

Cluster Network name: '%1'

Reason: '%2'

Guidance
Ensure that the network adapters associated with dependent IP address resources are configured
with access to at least one DNS server.
Event 1262:
RES_NETNAME_DNS_REGISTRATION_PUBLISH_PTR_FAILED
Output

Cluster network name resource failed to publish the PTR record in the DNS
reverse lookup zone.

Cluster Network name: '%1'

Error Code: '%2'

Guidance
Ensure that the network adapters associated with dependent IP address resources are configured
with access to at least one DNS server and that the DNS reverse lookup zone exists.

Event 1264:
RES_NETNAME_DNS_REGISTRATION_PUBLISH_PTR_FAILED_STATUS
Output

Cluster network name resource failed to publish the PTR record in the DNS
reverse lookup zone.

Cluster Network name: '%1'

Reason: '%2'

Guidance

Ensure that the network adapters associated with dependent IP address resources are configured
with access to at least one DNS server and that the DNS reverse lookup zone exists.

Event 1265: RES_TYPE_CONTROL_TIMED_OUT

Output

Cluster resource type '%1' timed out while processing the control code %2. The
cluster will try to automatically recover by terminating and restarting the
Resource Hosting Subsystem (RHS) process that was processing the call.

Event 1289: NETFT_ADAPTER_NOT_FOUND

Output

The Cluster Service was unable to access network adapter '%1'. Verify that other
network adapters are functioning properly and check the device manager for
errors associated with adapter '%1'. If the configuration for adapter '%1' has
 been changed, it may become necessary to reinstall the failover clustering
feature on this computer.

Event 1360: RES_IPADDR_INVALID_NETWORK

Output

Cluster IP address resource '%1' failed to come online. Ensure the network
property '%2' matches a cluster network name or the address property '%3'
matches one of the subnets on a cluster network. If this is an IPv6 Address
type, please verify that the cluster network matching this resource has at least
one IPv6 prefix that is not link-local or tunnel.

Event 1361: RES_IPADDR_MISSING_DEPENDANT

Output

IPv6 Tunnel address resource '%1' failed to come online because it does not
depend on an IP Address (IPv4) resource. Dependency on at least one IP Address
(IPv4) resource is required.

Event 1362: RES_IPADDR_MISSING_DATA

Output

Cluster IP address resource '%1' failed to come online because the '%2' property
could not be read. Please ensure that the resource is correctly configured.

Event 1363: RES_IPADDR_NO_ISATAP_SUPPORT

Output

IPv6 tunnel address resource '%1' failed to come online. Cluster network '%2'
associated with dependent IP address (IPv4) resource '%3' does not support
ISATAP tunneling. Please ensure that the cluster network supports ISATAP
tunneling.

Event 1540: SERVICE_BACKUP_NOQUORUM

Output

The backup operation for the cluster configuration data has been aborted because
quorum for the cluster has not yet been achieved. Please retry this backup
operation after the cluster achieves quorum.

Event 1554: SERVICE_RESTORE_INVALIDUSER

 Output

The restore operation for the cluster configuration data has failed. This was
due to insufficient privileges associated with the user account performing the
restore. Please ensure that the user account has local administrator privileges.

Event 1557: SERVICE_WITNESS_ATTACH_FAILED

Output

Cluster service failed to update the cluster configuration data on the witness
resource. Please ensure that the witness resource is online and accessible.

Event 1559: RES_WITNESS_NEW_NODE_CONFLICT

Output

File share '%1' associated with the file share witness resource is currently
hosted by server '%2'. This server '%2' has just been added as a new node within
the failover cluster. Hosting of the file share witness by any node comprising
the same cluster is not recommended. Please choose a file share witness that is
not hosted by any node within the same cluster and modify settings of the file
share witness resource accordingly.

Event 1560: RES_SMB_SHARE_CONFLICT

Output

Cluster file share resource '%1' has detected shared folder conflicts. As a
result, some of these shared folders may not be accessible. To rectify this
situation, ensure multiple shared folders do not have the same share name.

Event 1563: RES_FSW_ONLINEFAILURE

Output

File share witness resource '%1' failed to come online. Please ensure that file
share '%2' exists and is accessible by the cluster.

Event 1566: RES_NETNAME_TIMEDOUT

Output

Cluster network name resource '%1' cannot be brought online. The network name
resource was terminated by the resource host subsystem because it did not
complete an operation in an acceptable time. The operation timed out while
performing: '%2'
Event 1567: SERVICE_FAILED_TO_CHANGE_LOG_SIZE
Output

Cluster service failed to change the trace log size. Please verify the
ClusterLogSize setting with the 'Get-Cluster \| Format-List \*' PowerShell
cmdlet. Also, use the Performance Monitor snap-in to verify the event trace
session settings for FailoverClustering.

Event 1567: RES_VIPADDR_ADDRESS_INTERFACE_FAILED

Output

Health check for IP interface '%1'(address '%2') failed (status is '%3'). Check
for hardware or software errors related to the physical or virtual network
adapters.

Event 1568:
RES_CLOUD_WITNESS_CANT_COMMUNICATE_TO_AZURE
Output

Cloud witness resource could not reach Microsoft Azure storage

services.

Cluster resource: %1
Cluster node: %2

Guidance

This could be due to network communication between the cluster node and the Microsoft Azure
service being blocked. Verify the node's internet connectivity to Microsoft Azure. Connect to the
Microsoft Azure portal and verify that the storage account exists.

Event 1569: SERVICE_USING_RESTRICTED_NETWORK

Output

Network '%1' which has been disabled for failover cluster use, was found to be
the only currently possible network that node '%2' can use to communicate with
other nodes in the cluster. This may impact the node's ability to participate in
the cluster. Please verify network connectivity of node '%2' and enable at least
one network for cluster communication. Run the Validate a Configuration wizard
to check your network configuration.

Event 1569: RES_CLOUD_WITNESS_TOKEN_EXPIRED

 Output

Cloud witness resource failed to authenticate with Microsoft Azure storage

services. An access denied error was returned while attempting to contact the
Microsoft Azure storage account.

Cluster resource: %1

Guidance
The storage account's access key may no longer be valid. Use the Configure Cluster Quorum Wizard
in the Failover Cluster Manager or the Set-ClusterQuorum Windows PowerShell cmdlet, to configure
the Cloud witness resource with the updated storage account access key.

Event 1573: SERVICE_FORM_WITNESS_FAILED

Output

Node '%1' failed to form a cluster. This was because the witness was not
accessible. Please ensure that the witness resource is online and available.

Event 1580:
RES_NETNAME_DNS_REGISTRATION_SECURE_ZONE_FAILED
Output

Cluster network name resource '%1' failed to register the name '%2' over adapter
'%4' in a secure DNS zone. This was due to an existing record with this name and
the cluster identity does not have the sufficient privileges to update that
record. The error code was '%3'. Please contact your DNS server administrator to
verify the cluster identity has permissions on DNS record '%2'.

Event 1585: RES_FILESERVER_FSCHECK_SRVSVC_STOPPED

Output

Cluster file server resource '%1' failed a health check. This was due to the
Server service not being started. Please use Server Manager to confirm the state
of the Server service on this cluster node.

Event 1586:
RES_FILESERVER_FSCHECK_SCOPED_NAME_NOT_REGISTERED
Output

Cluster file server resource '%1' failed a health check. This was because some
of its shared folders were inaccessible. Verify that the folders are accessible
 from clients. Additionally, confirm the state of the Server service on this
cluster node using Server Manager and look for other events related to the
Server service on this cluster node. It may be necessary to restart the network
name resource '%2' in this clustered role.

Event 1587: RES_FILESERVER_FSCHECK_FAILED

Output

Cluster file server resource '%1' failed a health check. This was because some
of its shared folders were inaccessible. Verify that the folders are accessible
from clients. Additionally, confirm the state of the Server service on this
cluster node using Server Manager and look for other events related to the
Server service on this cluster node.

Event 1588: RES_FILESERVER_SHARE_CANT_ADD

Output

Cluster file server resource '%1' cannot be brought online. The resource failed
to create file share '%2' associated with network name '%3'. The error code was
'%4'. Verify that the folders exist and are accessible. Additionally, confirm
the state of the Server service on this cluster node using Server Manager and
look for other related events on this cluster node. It may be necessary to
restart the network name resource '%3' in this clustered role.

Event 1600: CLUSAPI_CREATE_CANNOT_SET_AD_DACL

Output

Cluster service failed to set the permissions on the cluster computer object
'%1'. Please contact your network administrator to check the cluster security
descriptor of the computer object in Active Directory, verify that the DACL is
not too big, and remove any unnecessary extra ACE(s) on the object if necessary.

Event 1603: RES_FILESERVER_CLONE_FAILED

Output

File Server could not start because expected dependency on 'Network Name'
resource was not found or it was not configured properly. Error=0x%2.

Event 1606: RES_DISK_CNO_CHECK_FAILED

Output

Cluster disk resource '%1' contains a BitLocker-protected volume, '%2', but for
this volume, the Active Directory cluster name account (also called the cluster
 name object or CNO) is not a BitLocker protector for the volume. This is
required for BitLocker-protected volumes. To correct this, first remove the disk
from the cluster. Next, use the Manage-bde.exe command-line tool to add the
cluster name as an ADAccountOrGroup protector, using the format
domain\ClusterName$ for the cluster name. Then add the disk back to the
cluster. For more information, see the documentation for Manage-bde.exe

Event 1607: RES_DISK_CNO_UNLOCK_FAILED

Output

Cluster disk resource '%1' was unable to unlock the BitLocker-protected volume
'%2'. The cluster name object (CNO) is not set to be a valid BitLocker protector
for this volume. To correct this, remove the disk from the cluster. Then use the
Manage-bde.exe command-line tool to add the cluster name as an ADAccountOrGroup
protector, using the format domain\ClusterName$, and add the disk back to the
cluster. For more information, see the documentation for Manage-bde.exe.

Event 1608: RES_FILESERVER_LEADER_FAILED

Output

File Server could not start because expected dependency on 'Network Name'
resource was not found or it was not configured properly. Error=0x%2.

Event 1609: RES_SODA_FILESERVER_LEADER_FAILED

Output

Scale Out File Server could not start because expected dependency on
'Distributed Network Name' resource was not found or it was not configured
properly. Error=0x%2.

Event 1632: CLUSAPI_CREATE_MISMATCHED_OU

Output

The creation of the cluster failed. Unable to create the cluster name object
'%1' in active directory organizational unit '%2'. The object already exists in
organizational unit '%3'. Verify that the specified distinguished name path and
the cluster name object are correct. If the distinguished name path is not
specified, the existing computer object '%1' will be used.

Event 1652: SERVICE_TCP_CONNECTION_FAILURE

Output
 Cluster node '%1' failed to join the cluster. A TCP connection could not be
established to node(s) '%2'. Verify network connectivity and configuration of
any network firewalls.

Event 1652: SERVICE_UDP_CONNECTION_FAILURE

Output

Cluster node '%1' failed to join the cluster. A UDP connection could not be
established to node(s) '%2'. Verify network connectivity and configuration of
any network firewalls.

Event 1652: SERVICE_VIRTUAL_TCP_CONNECTION_FAILURE

Output

Cluster node '%1' failed to join the cluster. A TCP connection using the
Microsoft Failover Cluster Virtual Adapter could not be established to node(s)
'%2'. Verify network connectivity and configuration of any network firewalls.

Event 1653: SERVICE_NO_CONNECTIVITY

Output

Cluster node '%1' failed to join the cluster because it could not communicate
over the network with any other node in the cluster. Verify network connectivity
and configuration of any network firewalls.

Event 1654: RES_VIPADDR_INVALID_ADAPTERNAME

Output

Cluster Disjoint IP address resource '%1' failed to come online. Configuration

data for the network adapter corresponding to network adapter '%2' could not be
determined (error code was '%3'). Check that the IP address resource is
configured with the correct address and network properties.

Event 1655: RES_VIPADDR_INVALID_VSID

Output

Cluster Disjoint IP address resource '%1' failed to come online. Configuration

data for the network adapter corresponding to Virtual Subnet Id '%2' and Routing
Domain Id '%3' could not be determined (error code was '%4'). Check that the IP
address resource is configured with the correct address and network properties.
Event 1656: RES_VIPADDR_ADDRESS_CREATE_FAILED
Output

Failed to add the IP Address '%2' for Disjoint IP address resource '%1' (error
code was '%3'). Check for hardware or software errors related to the physical or
virtual network adapters.

Event 1664: CLUSTER_UPGRADE_INCOMPLETE

Output

Upgrading the functional level of the cluster failed. Check that all nodes of
the cluster are currently running and are the same version of Windows Server,
then run the Update-ClusterFunctionalLevel Windows PowerShell cmdlet again.

Event 1676: EVENT_LOCAL_NODE_QUARANTINED

Output

Local cluster node has been quarantined by '%1'. The node will be quarantined
until '%2' and then the node will automatically attempt to re-join the cluster.

Refer to the System and Application event logs to determine the issues on
this node. When the issue is resolved, quarantine can be manually cleared to
allow the node to rejoin with the 'Start-ClusterNode -ClearQuarantine' Windows
PowerShell cmdlet.

QuarantineType : Quarantined by %1
Time quarantine will be automatically cleared: %2

Event 1677: EVENT_NODE_DRAIN_FAILED

Output

Node drain failed on Cluster node %1.

Reference the node's System and

Application event logs and cluster logs to investigate the cause of the drain
failure. When the problem is resolved, you can retry the drain operation.

Event 1683: RES_NETNAME_COMPUTER_ACCOUNT_NO_DC

Output

The cluster service was unable to reach any available domain controller on the
domain. This may impact functionality that is dependent on Cluster network name
authentication.
 DC Server: %1

Guidance
Verify that domain controllers are accessible on the network to the cluster nodes.

Event 1684:
RES_NETNAME_COMPUTER_OBJECT_VCO_NOT_FOUND
Output

Cluster network name resource failed to find the associated computer object in
Active Directory. This may impact functionality that is dependent on Cluster
network name authentication.

Network Name: %1
Organizational Unit: %2

Guidance
Restore the computer object for the network name from the Active Directory recycle bin. Alternately,
offline the cluster network name resource and run the Repair action to recreate the computer object
in Active Directory.

Event 1685:
RES_NETNAME_COMPUTER_OBJECT_CNO_NOT_FOUND
Output

Cluster network name resource failed to find the associated computer object in
Active Directory. This may impact functionality that is dependent on Cluster
network name authentication.

Network Name: %1
Organizational Unit: %2

Guidance
Restore the computer object for the network name from the Active Directory recycle bin.

Event 1686: RES_NETNAME_COMPUTER_OBJECT_VCO_DISABLED

Output

Cluster network name resource found the associated computer object in Active
Directory to be disabled. This may impact functionality that is dependent on
 Cluster network name authentication.

Network Name: %1
Organizational Unit: %2

Guidance
Enable the computer object for the network name in Active Directory.

Event 1687: RES_NETNAME_COMPUTER_OBJECT_CNO_DISABLED

Output

Cluster network name resource found the associated computer object in Active
Directory to be disabled. This may impact functionality that is dependent on
Cluster network name authentication.

Network Name: %1
Organizational Unit: %2

Guidance
Enable the computer object for the network name in Active Directory. Alternately, offline the cluster
network name resource and run the Repair action to enable the computer object in Active Directory.

Event 1688: RES_NETNAME_COMPUTER_OBJECT_FAILED

Output

Cluster network name resource detected that the associated computer object in
Active Directory was disabled and failed in its attempt to enable it. This may
impact functionality that is dependent on Cluster network name
authentication.

Network Name: %1
Organizational Unit: %2

Guidance

Enable the computer object for the network name in Active Directory.

Event 4608: NODECLEANUP_GET_CLUSTERED_DISKS_FAILED

Output

Cluster service failed to retrieve the list of clustered disks while destroying
the cluster. The error code was '%1'. If these disks are not accessible, execute
the 'Clear-ClusterDiskReservation' PowerShell cmdlet.
Event 4611:
NODECLEANUP_RELEASE_CLUSTERED_DISKS_FROM_PARTMGR_FAILED
Output

Clustered disk with ID '%2' was not released by the Partition Manager while
destroying the cluster. The error code was '%1'. Restarting the machine will
ensure the disk is released by the Partition Manager.

Event 4613: NODECLEANUP_CLEAR_CLUSDISK_DATABASE_FAILED

Output

The cluster service failed to properly cleanup a clustered disk with ID '%2'
while destroying the cluster. The error code was '%1'. You may unable to access
this disk until cleanup has been successfully completed. For manual cleanup,
delete the 'AttachedDisks' value of the
'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters'
key in the Windows registry.

Event 4615: NODECLEANUP_DISABLE_CLUSTER_SERVICE_FAILED

Output

The cluster service has been stopped and set as disabled as part of cluster node
cleanup.

Event 4616:
NODECLEANUP_DISABLE_CLUSTER_SERVICE_TIMEOUT
Output

Termination of the cluster service during cluster node cleanup has not completed
within the expected time period. Please restart this machine to ensure the
cluster service is no longer running.

Event 4618:
NODECLEANUP_RESET_CLUSTER_REGISTRY_ENTRIES_FAILED
Output

Resetting cluster service registry entries during cluster node cleanup failed.
The error code was '%1'. You may be unable to create or join a cluster with this
machine until cleanup has been successfully completed. For manual cleanup,
execute the 'Clear-ClusterNode' PowerShell cmdlet on this machine.
Event 4620: NODECLEANUP_UNLOAD_CLUSTER_HIVE_FAILED
Output

Unloading the cluster service registry hive during cluster node cleanup failed.
The error code was '%1'. You may be unable to create or join a cluster with this
machine until cleanup has been successfully completed. For manual cleanup,
execute the 'Clear-ClusterNode' PowerShell cmdlet on this machine.

Event 4622: NODECLEANUP_ERRORS

Output

The Cluster service encountered an error during node cleanup. You may be unable
to create or join a cluster with this machine until cleanup has been
successfully completed. Use the 'Clear-ClusterNode' PowerShell cmdlet on this
node.

Event 4624: NODECLEANUP_RESET_NLBSFLAGS_FAILED

Output

Resetting the IPSec security association timeout registry value failed during
cluster node cleanup. The error code was '%1'. For manual cleanup, execute the
'Clear-ClusterNode' PowerShell cmdlet on this machine. Alternatively, you may
reset the IPSec security association timeout by deleting the '%2' value and the
'%3' value from HKEY_LOCAL_MACHINE in the Windows registry.

Event 4627: NODECLEANUP_DELETE_CLUSTER_TASKS_FAILED

Output

Deletion of clustered tasks during node cleanup failed. The error code was '%1'.
Use Windows Task Scheduler to delete any remaining clustered tasks.

Event 4629: NODECLEANUP_DELETE_LOCAL_ACCOUNT_FAILED

Output

During node cleanup, the local user account that is managed by the cluster was
not deleted. The error code was '%1'. Open Local Users and Groups (lusrmgr.msc)
to delete the account.

Event 4864: RES_VSSTASK_OPEN_FAILED

Output
 Volume shadow copy service task resource '%1' creation failed. The error code
was '%2'.

Event 4865: RES_VSSTASK_TERMINATE_TASK_FAILED

Output

Volume shadow copy service task resource '%1' failed. The error code was '%2'.
This is because the associated task could not be stopped as part of an offline
operation. You may need to stop it manually using the Task Scheduler snap-in.

Event 4866: RES_VSSTASK_DELETE_TASK_FAILED

Output

Volume shadow copy service task resource '%1' failed. The error code was '%2'.
This is because the associated task could not be deleted as part of an offline
operation. You may need to delete it manually using the Task Scheduler snap-in.

Event 4867: RES_VSSTASK_ONLINE_FAILED

Output

Volume shadow copy service task resource '%1' failed. The error code was '%2'.
This is because the associated task could not be added as part of an online
operation. Please use the Task Scheduler snap-in to ensure your tasks are
properly configured.

Event 4868: UNABLE_TO_START_AUTOLOGGER

Output

Cluster service failed to start the cluster log trace session. The error code
was '%2'. The cluster will function properly, but supplemental logging
information will be missing. Use the Performance Monitor snap-in to verify the
event channel settings for '%1'.

Event 4869: NETFT_WATCHDOG_PROCESS_HUNG

Output

User mode health monitoring has detected that the system is not being
responsive. The Failover cluster virtual adapter has lost contact with the '%1'
process with a process ID '%2', for '%3' seconds. Please use Performance Monitor
to evaluate the health of the system and determine which process may be
negatively impacting the system.
Event 4870: NETFT_WATCHDOG_PROCESS_TERMINATED
Output

User mode health monitoring has detected that the system is not being
responsive. The Failover cluster virtual adapter has lost contact with the '%1'
process with a process ID '%2', for '%3' seconds. Recovery action will be taken.

Event 4871: NETFT_MINIPORT_INITIALIZATION_FAILURE

Output

The cluster service failed to start. This was because the failover cluster
virtual adapter failed to initialize the miniport adapter. The error code was
'%1'. Verify that other network adapters are functioning properly and check the
device manager for errors. If the configuration was changed, it may be necessary
to reinstall the failover clustering feature on this computer.

Event 4872: NETFT_MISSING_DATALINK_ADDRESS

Output

The failover cluster virtual adapter failed to generate a unique MAC address.
Either it was unable to find a physical Ethernet adapter from which to generate
a unique address or the generated address conflicts with another adapter on this
machine. Please run the Validate a Configuration wizard to check your network
configuration.

Event 5122: DCM_EVENT_ROOT_CREATION_FAILED

Output

Cluster service failed to create the Cluster Shared Volumes root directory '%2'.
The error message was '%1'.

Event 5142: DCM_VOLUME_NO_ACCESS

Output

Cluster Shared Volume '%1' ('%2') is no longer accessible from this cluster node

because of error '%3'. Please troubleshoot this node's connectivity to the

storage device and network connectivity.

Event 5143: DCM_VETO_RESOURCE_MOVE_DUE_TO_CC

Output
 Move of the disk ('%2') is vetoed based on the current state of the Cache
Manager on the node '%1' to prevent a potential deadlock. 'Cache Manager Dirty
Pages Threshold' is %3, and 'Cache Manager Dirty Pages' is %4. Move is allowed if
'Cache Manager Dirty Pages' is less than 70% of 'Cache Manager Dirty Pages
Threshold' or if 'Cache Manager Dirty Pages Threshold' minus 'Cache Manager Dirty
Pages' is greater than 128000 pages (about 500MB if a page size is 4096 bytes).
Cluster vetoed resource move to prevent potential deadlock due to Cache Manager
throttling buffered writes while Cluster Shared Volumes on this disk are being
paused.

Event 5144: DCM_SNAPSHOT_DIFF_AREA_FAILURE

Output

While adding the disk ('%1') to Cluster Shared Volumes, setting explicit
snapshot diff area association for volume ('%2') failed with error '%3'. The
only supported software snapshot diff area association for Cluster Shared
Volumes is to self.

Event 5145: DCM_SNAPSHOT_DIFF_AREA_DELETE_FAILURE

Output

Cluster disk resource '%1' failed to delete a software snapshot. The diff area
on volume '%3' could not be dissociated from volume '%2'. This may be caused by
active snapshots. Cluster Shared Volumes requires that the software snapshot be
located on the same disk.

Event 5146: DCM_VETO_RESOURCE_MOVE_DUE_TO_DISMOUNT

Output

Move of the Cluster Shared Volume resource '%1' is vetoed because one
of the volumes belonging to the resource is in dismounted state. Please retry
the action after the dismount operation is completed.

Event 5147: DCM_VETO_RESOURCE_MOVE_DUE_TO_SNAPSHOT

Output

Move of the Cluster Shared Volume resource '%1' is vetoed because one of the
volumes belonging to the resource is in dismounted state. Please retry the
action after the dismount operation is completed.

Event 5148:
DCM_VETO_RESOURCE_MOVE_DUE_TO_IO_MODE_CHANGE
 Output

Move of the Cluster Shared Volume resource '%1' is vetoed because an IO mode
change operation (Direct IO to Redirected IO or vice versa) is in progress on
one of the volumes belonging to the resource. Please retry the action after the
operation is completed.

Event 5150: DCM_SET_RESOURCE_IN_FAILED_STATE

Output

Cluster physical disk resource '%1' failed. The Cluster Shared Volume was put in
failed state with the following error: '%2'

Event 5200: CAM_CANNOT_CREATE_CNO_TOKEN

Output

Cluster service failed to create a cluster identity token for Cluster Shared
Volumes. The error code was '%1'. Ensure the domain controller is accessible and
check for connectivity issues. Until connection to the domain controller is
recovered, some operations on this node against the Cluster Shared Volumes might
fail.

Event 5216: CSV_SW_SNAPSHOT_FAILED

Output

Software snapshot creation on Cluster Shared Volume '%1' ('%2') failed with
error %3. The resource must be online to support snapshot creation. Please check
the state of the resource.

Event 5217: CSV_SW_SNAPSHOT_SET_FAILED

Output

Software snapshot creation on Cluster Shared Volume(s) ('%1') with snapshot set
id '%2' failed with error '%3'. Please check the state of the CSV resources and
the system events of the resource owner nodes.

Event 5219: CSV_REGISTER_SNAPSHOT_PROV_WITH_VSS_FAILED

Output

Cluster service failed to register the Cluster Shared Volumes snapshot provider
with the Volume Shadow Service (VSS). This may be due to the VSS service
shutting down or may be a problem with the VSS service having a problem that
causes it to not accept incoming requests.
 Error: %1

Event 5377: OPERATION_EXCEEDED_TIMEOUT

Output

An internal Cluster service operation exceeded the defined threshold of '%2'

seconds. The Cluster service has been terminated to recover. Service Control
Manager will restart the Cluster service and the node will rejoin the cluster.

Event 5396: TWO_PARTITIONS_HAVE_QUORUM

Output

The Cluster service on this node is shutting down because it has detected that
there are other cluster nodes that have quorum. This occurs when the Cluster
service detects another node that was started with the Force Quorum switch
(/fq). The node which was started with the Force Quorum Switch will remain
running. Use Failover Cluster Manager to verify that this node automatically
joined the cluster when the cluster service restarted.

Event 5397: RLUA_ACCOUNT_FAILED

Output

The cluster resource '%1' could not create or modify the replicated local user
account '%2' on this node. Check the cluster logs for more information.

Event 5398: NM_EVENT_CLUSTER_FAILED_TO_FORM

Output

Cluster failed to start. The latest copy of cluster configuration data was not
available within the set of nodes attempting to start the cluster. Changes to
the cluster occurred while the set of nodes were not in membership and as a
result were not able to receive configuration data updates.

Votes required to start cluster: %1

Votes available: %2
Nodes with votes: %3

Guidance

Attempt to start the cluster service on all nodes in the cluster so that nodes with the latest copy of
the cluster configuration data can first form the cluster. The cluster will be able to start and the
nodes will automatically obtain the updated cluster configuration data. If there are no nodes
available with the latest copy of the cluster configuration data, run the Start-ClusterNode -FQ
Windows PowerShell cmdlet. Using the ForceQuorum (FQ) parameter will start the cluster service and
mark this node's copy of the cluster configuration data to be authoritative. Forcing quorum on a
node with an outdated copy of the cluster database may result in cluster configuration changes that
occurred while the node was not participating in the cluster to be lost.

Warning events

Event 1011: NM_NODE_EVICTED

Output

Cluster node %1 has been evicted from the failover cluster.

Event 1045: RES_IPADDR_IPV4_ADDRESS_CREATE_FAILED

Output

No matching network interface found for resource '%1' IP address '%2' (return
code was '%3'). If your cluster nodes span different subnets, this may be
normal.

Event 1066: RES_DISK_CORRUPT_DISK

Output

Cluster disk resource '%1' indicates corruption for volume '%2'. Chkdsk is being
run to repair problems. The disk will be unavailable until Chkdsk completes.
Chkdsk output will be logged to file '%3'.

Chkdsk may also write information to the Application Event Log.

Event 1068: RES_SMB_SHARE_CANT_ADD

Output

Cluster file share resource '%1' cannot be brought online. Creation of file
share '%2' (scoped to network name %3) failed due to error '%4'. This operation
will be automatically retried.

Event 1071:
RCM_RESOURCE_ONLINE_BLOCKED_BY_LOCKED_MODE
Output
 The operation attempted on cluster resource '%1' of type '%3' in clustered role
'%2' could not be completed because the resource or one of its providers has
locked status.

Event 1071:
RCM_RESOURCE_OFFLINE_BLOCKED_BY_LOCKED_MODE
Output

The operation attempted on cluster resource '%1' of type '%3' in clustered role
'%2' could not be completed because the resource or one of its dependents has
locked status.

Event 1094: SM_INVALID_SECURITY_LEVEL

Output

The cluster common property SecurityLevel cannot be changed on this cluster. The
cluster security level cannot be changed because the cluster is currently
configured for no authentication mode.

Event 1119: RES_NETNAME_DNS_REGISTRATION_MISSING

Output

Cluster network name resource '%1' failed to register DNS name '%2' over adapter
'%4' for the following reason: '%3'

Event 1125: TM_EVENT_CLUSTER_NETINTERFACE_UNREACHABLE

Output

Cluster network interface '%1' for cluster node '%2' on network '%3' is
unreachable by at least one other cluster node attached to the network. The
failover cluster was not able to determine the location of the failure. Run the
Validate a Configuration wizard to check your network configuration. If the
condition persists, check for hardware or software errors related to the network
adapter. Also check for failures in any other network components to which the
node is connected such as hubs, switches, or bridges.

Event 1149: RES_NETNAME_CANT_DELETE_DNS_RECORDS

Output

The DNS Host (A) and Pointer (PTR) records associated with Cluster resource '%1'
were not removed from the resource's associated DNS server. If necessary, they
 can be deleted manually. Contact your DNS administrator to assist with this
effort.

Event 1150: RES_NETNAME_DNS_PTR_RECORD_DELETE_FAILED

Output

The removal of the DNS Pointer (PTR) record '%2' for host '%3' which is
associated with the cluster network name resource '%1' failed with error '%4'.
If necessary, the record can be deleted manually. Contact your DNS administrator
for assistance.

Event 1151: RES_NETNAME_DNS_A_RECORD_DELETE_FAILED

Output

The removal of the DNS Host (A) record '%2' associated with the cluster network
name resource '%1' failed with error '%3'. If necessary, the record can be
deleted manually. Contact your DNS administrator for assistance.

Event 1155: RCM_EVENT_EXITED_QUEUING

Output

The pending move for the role '%1' did not complete.

Event 1197: RES_NETNAME_DELETE_DISABLE_FAILED

Output

Cluster network name resource '%1' failed to delete or disable its associated
computer object '%2' during resource deletion. The error code was '%3'.

Please check if the site is Read-Only. Ensure that the cluster name object has the
appropriate permissions on the '%2' object in Active Directory.

Event 1198: RES_NETNAME_DELETE_VCO_GUID_FAILED

Output

Cluster network name resource '%1' failed to delete computer object with guid
'%2'. The error code was '%3'.

Please check if the site is Read-Only. Ensure that the cluster name object has the
appropriate permissions on the '%2' object in Active Directory.
Event 1216: SERVICE_NETNAME_CHANGE_WARNING
Output

A name change operation on the cluster core netname resource has failed.
Attempting to revert the name change operation back to the original name has
also failed. The error code was '%1'. You may not be able to remotely manage the
cluster using the cluster name until this situation has been manually corrected.

Event 1221:
RES_NETNAME_RENAME_OUT_OF_SYNCH_WITH_COMPOBJ
Output

Cluster network name resource '%1' has a name '%2' which does not match the
corresponding computer object name '%3'. It is likely that a previous name
change of the computer object has not replicated to all domain controllers in
the domain. You will be unable to rename the network name resource until the
names become consistent. If the computer object has not been recently changed,
please contact your domain administrator to rename the computer object and
thereby make it consistent. Also, ensure that replication across domain
controllers has been successfully completed.

Event 1222: RES_NETNAME_SET_PERMISSIONS_FAILED

Output

The computer object associated with cluster network name resource '%1' could not
be updated.

The text for the associated error code is: %2

The cluster identity '%3' may lack permissions required to update the object. Please
work
with your domain administrator to ensure that the cluster identity can update
computer objects in the domain.

Event 1240: RES_IPADDR_OBTAIN_LEASE_FAILED

Output

Cluster IP address resource '%1' failed to obtain a leased IP address.

Event 1243: RES_IPADDR_RELEASE_LEASE_FAILED

Output

Cluster IP address resource '%1' failed to release the lease for IP address
 '%2'.

Event 1251: RCM_GROUP_PREEMPTED

Output

Clustered role '%2' was taken offline. This role was preempted by the higher
priority clustered role '%1'. The cluster service will attempt to bring
clustered role '%2' online later when system resources are available.

Event 1544: SERVICE_VSS_ONABORT

Output

The backup operation for the cluster configuration data has been canceled. The
cluster Volume Shadow Copy Service (VSS) writer received an abort request.

Event 1548: SERVICE_CONNECT_VERSION_COMPATIBLE

Output

Node '%1' established communication with node '%2' and detected that it is
running a different, but compatible, version of the operating system. We
recommend that all nodes run the same version of the operating system. After all
nodes have been upgraded, run the Update-ClusterFunctionalLevel Windows
PowerShell cmdlet to complete upgrading the cluster.

Event 1550: SERVICE_CONNECT_NOVERCHECK

Output

Node '%1' established a communication session with node '%2' without performing
a version compatibility check because version compatibility checking is
disabled. Disabling version compatibility checking is not supported.

Event 1551: SERVICE_FORM_NOVERCHECK

Output

Node '%1' formed a failover cluster without performing a version compatibility

check because version compatibility checking is disabled. Disabling version
compatibility checking is not supported.

Event 1555: SERVICE_NETFT_DISABLE_AUTOCONFIG_FAILED

 Output

Attempting to use IPv4 for '%1' network adapter failed. This was due to a
failure to disable IPv4 auto-configuration and DHCP. This may be expected if the
DHCP Client service is already disabled. IPv6 will be used if enabled, otherwise
this node may not be able to participate in a failover cluster.

Event 1558: SERVICE_WITNESS_FAILOVER_ATTEMPT

Output

The cluster service detected a problem with the witness resource. The witness
resource will be failed over to another node within the cluster in an attempt to
reestablish access to cluster configuration data.

Event 1562: RES_FSW_ALIVEFAILURE

Output

File share witness resource '%1' failed a periodic health check on file share
'%2'. Please ensure that file share '%2' exists and is accessible by the
cluster.

Event 1576:
RES_NETNAME_DNS_REGISTRATION_SECURE_ZONE_REFUSED
Output

Cluster network name resource '%1' failed to register the name '%2' over adapter
'%4' in a secure DNS zone. This was due to an existing record with this name and
the cluster identity does not have the sufficient privileges to update that
record. The error code was '%3'. Please contact your DNS server administrator to
verify the cluster identity has permissions on DNS record '%2'.

Event 1577:
RES_NETNAME_DNS_SERVER_COULD_NOT_BE_CONTACTED
Output

Cluster network name resource '%1' failed to register the name '%2' over adapter
'%4'. The DNS server could not be contacted. The error code was '%3.' Ensure
that a DNS server is accessible from this cluster node. The DNS registration
will be retried later.

Event 1578:
RES_NETNAME_DNS_TEST_FOR_DYNAMIC_UPDATE_FAILED
 Output

Cluster network name resource '%1' failed to register dynamic updates for name
'%2' over adapter '%4'. The DNS server may not be configured to accept dynamic
updates. The error code was '%3'. Please contact your DNS server administrator
to verify that the DNS server is available and configured for dynamic
updates.

Alternatively, you can disable dynamic DNS updates by unchecking the

'Register this connection's addresses in DNS' setting in the advanced TCP/IP
settings for adapter '%4' under the DNS tab.

Event 1579: RES_NETNAME_DNS_RECORD_UPDATE_FAILED

Output

Cluster network name resource '%1' failed to update the DNS record for name '%2'
over adapter '%4'. The error code was '%3'. Ensure that a DNS server is
accessible from this cluster node and contact your DNS server administrator to
verify the cluster identity can update the DNS record '%2'.

Event 1581: CLUSSVC_UNABLE_TO_MOVE_HIVE_TO_SAFE_FILE

Output

The restore request for the cluster configuration data failed to make a copy of
the existing cluster configuration data file (ClusDB). While attempting to
preserve the existing configuration, the restore operation was unable to create
a copy at location '%1'. This might be expected if the existing configuration
data file was corrupt. The restore operation has continued but attempts to
revert to the existing cluster configuration may not be possible.

Event 1582:
CLUSSVC_UNABLE_TO_MOVE_RESTORED_HIVE_TO_CURRENT
Output

Cluster Service failed to move the restored cluster hive at '%1' to '%2'. This
may prevent the restore operation from succeeding successfully. If the cluster
configuration was not properly restored, please retry the restore action.

Event 1583:
CLUSSVC_NETFT_DISABLE_CONNECTIONSECURITY_FAILED
Output

Cluster service failed to disable Internet Protocol security (IPsec) on the

Failover cluster virtual adapter '%1'. This could have a negative impact on
cluster communication performance. If this problem persists, please verify your
 local and domain connection security policies applying to IPSec and the Windows
Firewall. Additionally, please check for events related to the Base Filtering
Engine service.

Event 1584: SHARED_VOLUME_NOT_READY_FOR_SNAPSHOT

Output

A backup application initiated a VSS snapshot on Cluster Shared Volume '%1'

('%3') without properly preparing the volume for snapshot. This snapshot may be
invalid and the backup may not be usable for restore operations. Please contact
your backup application vendor to verify compatibility with Cluster Shared
Volumes.

Event 1589:
RES_NETNAME_DNS_RETURNING_IP_THAT_IS_NOT_PROVIDER
Output

Cluster network name resource '%1' found one or more IP addresses associated
with DNS name '%2' that are not dependent IP address resources. The additional
addresses found were '%3'. This may affect client connectivity until the network
name and its associated DNS records are consistent. Please contact your DNS
server administrator to verify the records associated with name '%2'.

Event 1604: RES_DISK_CHKDSK_SPOTFIX_NEEDED

Output

Cluster disk resource '%1' detected corruption for volume '%2'. Spotfix Chkdsk
is required to repair problems.

Event 1605: RES_DISK_SPOTFIX_PERFORMED

Output

Cluster disk resource '%1' completed running ChkDsk.exe /spotfix on volume '%2'.
The return code was '%4'. Output from the ChkDsk has been logged to file '%3'.

Check the application event log for additional information from ChkDsk.

Event 1671:
RES_DISK_ONLINE_SET_ATTRIBUTES_COMPLETED_FAILURE
Output
 Cluster physical disk resource cannot be brought online.

Physical Disk resource name: %1

Error Code: %2
Time Elapsed (seconds): %3

Guidance
Run the Validate a Configuration wizard to check your storage configuration. If the error code was
ERROR_CLUSTER_SHUTDOWN then the Online Pending state was canceled by an administrator. If
this is a replicated volume, then this could be the result of a failure to set the disk attributes. Review
the Storage Replication events for additional information.

Event 1673: CLUSTER_NODE_ENTERED_ISOLATED_STATE

Output

Cluster node '%1' has entered the isolated state.

Event 1675: EVENT_JOINING_NODE_QUARANTINED

Output

Cluster node '%1' has been quarantined by '%2' and cannot join the cluster. The
node will be quarantined until '%3' and then the node will automatically attempt
to re-join the cluster.

Refer to the System and Application event logs to

determine the issues on this node. When the issue is resolved, quarantine can be
manually cleared to allow the node to rejoin with the 'Start-ClusterNode
-ClearQuarantine' Windows PowerShell cmdlet.

Node Name: %1
QuarantineType: Quarantine by %2
Time quarantine will be automatically cleared: %3

Event 1681: CLUSTER_GROUPS_UNMONITORED_ON_NODE

Output

Virtual machines on node '%1' have entered an unmonitored state. The virtual
machines health will be monitored again once the node returns from an isolated
state or may failover if the node does not return. The virtual machine no longer
being monitored are: %2.

Event 1689: EVENT_DISABLE_AND_STOP_OTHER_SERVICE

 Output

The cluster service detected a service which is not compatible with Failover
Clustering. The service has been disabled to avoid possible problems with the
Failover Cluster.

Service name: '%1'

Event 4625: NODECLEANUP_RESET_NLBSFLAGS_PRESERVED

Output

Resetting the IPSec security association timeout registry value failed during
cluster node cleanup. This is because the IPSec security association timeout was
modified after this machine was configured to be a member of a cluster. For
manual cleanup, execute the 'Clear-ClusterNode' PowerShell cmdlet on this
machine. Alternatively, you may reset the IPSec security association timeout by
deleting the '%1' value and the '%2' value from HKEY_LOCAL_MACHINE in the
Windows registry.

Event 4873:
NETFT_CLUSSVC_TERMINATE_BECAUSE_OF_WATCHDOG
Output

The cluster service has detected that the failover cluster virtual adapter has
stopped. This is expected when hot replace CPU is performed on this node.
Cluster service will stop and should automatically restart after the operation
is complete. Please check for additional events associated with the service and
ensure that the cluster service has been restarted on this node.

Event 5120: DCM_VOLUME_AUTO_PAUSE_AFTER_FAILURE

Output

Cluster Shared Volume '%1' ('%2') has entered a paused state because of '%3'.
All I/O will temporarily be queued until a path to the volume is reestablished.

Event 5123: DCM_EVENT_ROOT_RENAME_SUCCESS

Output

Cluster Shared Volumes root directory '%1' already exists. The directory '%1'
was renamed to '%2'. Please verify that applications accessing data in this
location have been updated as necessary.

Event 5124: DCM_UNSAFE_FILTERS_FOUND

 Output

Cluster Shared Volume '%1' ('%3') has identified one or more active filter
drivers on this device stack that could interfere with CSV operations. I/O
access will be redirected to the storage device over the network through another
Cluster node. This may result in degraded performance. Please contact the filter
driver vendor to verify interoperability with Cluster Shared Volumes.

Active filter drivers found: %2

Event 5125: DCM_UNSAFE_VOLFILTER_FOUND

Output

Cluster Shared Volume '%1' ('%3') has identified one or more active volume
drivers on this device stack that could interfere with CSV operations. I/O
access will be redirected to the storage device over the network through another
Cluster node. This may result in degraded performance. Please contact the volume
driver vendor to verify interoperability with Cluster Shared Volumes.

Active volume drivers found: %2

Event 5126: DCM_EVENT_CANNOT_DISABLE_SHORT_NAMES

Output

Physical disk resource '%1' does not allow disabling short name generation. This
may cause application compatibility issues. Please use 'fsutil 8dot3name set 2'
to allow disabling short name generation and then offline/online the resource.

Event 5128: DCM_EVENT_CANNOT_DISABLE_SHORT_NAMES

Output

Physical disk resource '%1' does not allow disabling short name generation. This
may cause application compatibility issues. Please use 'fsutil 8dot3name set 2'
to allow disabling short name generation and then offline/online the resource.

Event 5133: DCM_CANNOT_RESTORE_DRIVE_LETTERS

Output

Cluster Disk '%1' has been removed and placed back in the 'Available Storage'
cluster group. During this process an attempt to restore the original drive
letter(s) has taken longer than expected, possibly due to those drive letters
being already in use.

Event 5134: DCM_CANNOT_SET_ACL_ON_ROOT

 Output

Cluster service failed to set the permissions (ACL) on the Cluster Shared
Volumes root directory '%1'. The error was '%2'.

Event 5135: DCM_CANNOT_SET_ACL_ON_VOLUME_FOLDER

Cluster service failed to set the permissions on the Cluster Shared Volume directory '%1' ('%2'). The
error was '%3'.

Event 5136: DCM_CSV_INTO_REDIRECTED_MODE

Output

Cluster Shared Volume '%1' ('%2') redirected access was turned on. Access to the
storage device will be redirected over the network from all cluster nodes that
are accessing this volume. This may result in degraded performance. Turn off
redirected access for this volume to resume normal operations.

Event 5149: DCM_CSV_BLOCK_CACHE_RESIZED

Output

Cache size resized to '%1' based on populated memory, user setsize is too high.

Event 5156:
DCM_VOLUME_AUTO_PAUSE_AFTER_SNAPSHOT_FAILURE
Output

Cluster Shared Volume '%1' ('%2') has entered a paused state because of '%3'.
This error is encountered when the volsnap snapshots underlying the CSV volume
are deleted outside of a user request. Possible causes of the snapshots getting
deleted are lack of space in the volume for the snapshots to grow, or IO failure
while trying to update the snapshot data. All I/O will temporarily be queued
until the snapshot state is synchronized with volsnap.

Event 5157:
DCM_VOLUME_AUTO_PAUSE_AFTER_FAILURE_EXPECTED
Output

Cluster Shared Volume '%1' ('%2') has entered a paused state because of '%3'.
All I/O will temporarily be queued until a path to the volume is reestablished.
This error is usually caused by an infrastructure failure. For example, losing
 connectivity to storage or the node owning the Cluster Shared Volume being
removed from active cluster membership.

Event 5394: POOL_ONLINE_WARNINGS

Output

The Cluster service encountered some storage errors while trying to bring
storage pool online. Run cluster storage validation to troubleshoot the issue.

Event 5395: RCM_GROUP_AUTO_MOVE_STORAGE_POOL

Output

Cluster is moving the group for storage pool '%1' because current node '%3' does
not have optimal connectivity to the storage pool physical disks.

Informational events

Event 1592:
CLUSSVC_TCP_RECONNECT_CONNECTION_REESTABLISHED
Output

Cluster node '%1' lost communication with cluster node '%2'. Network
communication was reestablished. This could be due to communication temporarily
being blocked by a firewall or connection security policy update. If the problem
persists and network communication are not reestablished, the cluster service on
one or more nodes will stop. If that happens, run the Validate a Configuration
wizard to check your network configuration. Additionally, check for hardware or
software errors related to the network adapters on this node, and check for
failures in any other network components to which the node is connected such as
hubs, switches, or bridges.

Event 1594: CLUSTER_FUNCTIONAL_LEVEL_UPGRADE_COMPLETE

Output

Cluster service successfully upgraded the cluster functional level.

Functional Level: %1
Upgrade Version: %2

Event 1635: RCM_RESOURCE_FAILURE_INFO_WITH_TYPENAME

Output
 Cluster resource '%1' of type '%3' in clustered role '%2' failed.

Event 1636: CLUSSVC_PASSWORD_CHANGED

Output

The Cluster service has changed the password of account '%1' on node '%2'.

Event 1680: CLUSTER_NODE_EXITED_ISOLATED_STATE

Output

Cluster node '%1' has exited the isolated state.

Event 1682:
CLUSTER_GROUP_MOVED_NO_LONGER_UNMONITORED
Output

Virtual machine '%2' which was unmonitored on the isolated node '%1' has been
failed over to another node. The health of the virtual machine is once again
being monitored.

Event 1682:
CLUSTER_MULTIPLE_GROUPS_NO_LONGER_UNMONITORED
Output

Node '%1' has rejoined the cluster and the following virtual machines running on
that node are once again having their health state monitored: %2.

Event 4621: NODECLEANUP_SUCCESS

Output

This node was successfully removed from the cluster.

Event 5121: DCM_VOLUME_NO_DIRECT_IO_DUE_TO_FAILURE

Output

Cluster Shared Volume '%1' ('%2') is no longer directly accessible from this
cluster node. I/O access will be redirected to the storage device over the
 network to the node that owns the volume. If this results in degraded
performance, please troubleshoot this node's connectivity to the storage device
and I/O will resume to a healthy state once connectivity to the storage device
is reestablished.

Event 5218: CSV_OLD_SW_SNAPSHOT_DELETED

Output

Cluster physical disk resource '%1' deleted a software snapshot. The software
snapshot on Cluster Shared Volume '%2' was deleted because it was older than
'%3' day(s). The snapshot ID was '%4' and it was created from node '%5' at '%6'.
It is expected that snapshots are deleted by a backup application after a backup
job is completed. This snapshot exceeded the time that is expected for a
snapshot to exist. Verify with the backup application that backup jobs are
completing successfully.

Reference
Detailed event info for Failover Clustering components in Windows Server 2008

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You may receive error messages when
you share a folder in a Windows Server
2008 failover cluster
Article • 12/26/2023

This article provides a solution to an error that occurs when you provision a shared
folder on a cluster physical disk resource.

Applies to: Windows Server 2012 R2

Original KB number: 947051

Beta Information
This article discusses a beta release of a Microsoft product. The information in this
article is provided as-is and is subject to change without notice.

No formal product support is available from Microsoft for this beta product. For
information about how to obtain support for a beta release, see the documentation that
is included with the beta product files, or check the Web location where you
downloaded the release.

Symptoms
In Windows Server 2008, you can use the following tools to provision a shared folder on
a cluster physical disk resource:

Use the Failover Cluster Management snap-in.

Use the Share and Storage Management snap-in.
Use Windows Explorer.

However, when you use these tools to share a folder in a Windows Server 2008 failover
cluster, you may experience the following symptoms.

Symptom 1
When you right-click a folder in Windows Explorer, and then you click Share, you may
receive the following warning message:

Your folder could not be shared

Symptom 2
You right-click a folder in Windows Explorer, and then you click Properties. If you then
click Share this folder under Advanced Sharing on the Sharing tab, you may receive the
following error message:

An error occurred which trying to share folder_name. The cluster resource could not
be found. The shared resource was not created at this time.

Symptom 3
When you try to use the Provision a Shared Folder Wizard in the Failover Cluster
Management snap-in or in the Share and Storage Management snap-in to share a
folder, you may receive the following warning message:

The shared folder resides on a highly available volume, but no highly available
network server name is associated with the volume. A cluster resource can be
created for the shared folder, but clients can only access the shared folder through
the local server name server_name. Are you sure you want to use this specified
located?

If you click Yes, you receive the following error message:

Share over SMB

If you click the Details tab that is associated with this error message, you receive the
following error message:

\\ server_name\folder_name: New SMB shared folder cannot be created. The cluster

resource could not be found.

７ Note

Both the Failover Cluster Management snap-in and the Share and Storage
Management snap-in use the Provision a Shared Folder Wizard to provision a
shared folder. Therefore, provisioning a shared folder in the Failover Cluster
Management snap-in is basically the same as provisioning a shared folder in the
Share and Storage Management snap-in.
Cause
These problems occur because you are trying to provision a shared folder on a cluster
physical disk resource that is not a member of the Highly Available Application or
Service group. Cluster physical disk resources are listed in the Available Storage group.
To view this group, click Storage in the Failover Cluster Management snap-in.

Resolution
To resolve this issue, make sure that the physical disk resource is a member of the
Highly Available Application or Services group in the cluster that already has a Client
Access Point (CAP) configured. Also, make sure that the status of the physical disk
resource is "Online."

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Local SAS Disks Getting Added in
Windows Server Failover Cluster
Article • 12/26/2023

This article provides a workaround for the issue that Local SAS Disks getting added in
Windows Server Failover Cluster.

Applies to: Windows Server 2012 R2

Original KB number: 2813005

Symptoms
On a Windows Server 2012 or Windows Server 2012 R2 Failover Cluster, local SAS drives
may be clustered. After adding the Physical Disk resource, they may fail to come online.
Additionally, you may receive the following error message:

Error Code: 0x80070001

Incorrect function

Looking at the event logs you may notice the following event getting logged in the
system event log:

Cause
A local SAS drive may be clustered due to changes in the default behavior of cluster-
able disk criteria introduced in Windows Server 2012.

Workaround
To work around this problem, remove the disk resource from Failover Cluster Manager
(FCM) if you do not want them to be part of Cluster. Additionally, you need to bring
these drives online in Disk Management once you remove them from Failover Cluster
Manager.

Identify non-shared disk signature on Cluster Nodes (For example use f6f6806f Disk
Signature that is highlighted by validation report in the More information section).

Method 1
 1. Open an elevated PowerShell prompt (right-click the tile or the icon and it's an
option at the bottom bar).
2. Copy and paste below command to identify only the SAS drives

$signature = @{Label="Signature";Expression={[System.Convert]::ToString($.signature,
16) }} Get-Disk |?{$.bustype -eq "SAS"} | ft Number, $signature, Bustype -a

Sample out-put of the above PowerShell command:

Number Signature BusType

--------- ----------- ----------
0 daf34ee4 SAS
1 f6f6806f SAS

Method 2
1. Open the Windows run box using keyboard, press Windows logo key‌ +R

2. Type Regedit and press enter

3. Locate and navigate to HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

4. Reading Disk Signature from above registry is little tricky, you need to read key in
reverse order

6f 80 f6 f6 would be read as F6F6806F

5. Repeat same steps on all the nodes of the cluster.Note: If you are not aware of the
drive letter, then you may need to compare all volume GUIDs and read data in the
reverse order as mentioned in step 4 above.

More information
A new feature enhancement in Failover Clustering for Windows Server 2012 and
Windows Server 2012 R2 is that it supports an Asymmetric Storage Configuration. In
Windows Server 2012 a disk is considered clusterable if it is presented to one or more
nodes, and is not the boot / system disk, or contain a page file. In previous releases a
disk had to be presented to all nodes in the cluster. This type of configuration is more
common in multi-site clusters. Failover Cluster Manager (FCM) would automatically add
these SAS drives that are exposed to one or more nodes during Adding Node in Cluster.

For more explicit control of which disks are clustered users can disable clustering from
automatically clustering disks by unchecking "Add all eligible Storage to the Cluster"
during creating wizard or Add desired disk later by using "Add Disk" in FCM.

Use Cluster Validation to determine if Disk can be used in Cluster. In below example,
validation clearly depicts that disk is only visible on one node that usually can happen if
the disks are local SAS to the node.

List Potential Cluster Disks

Physical disk f6f6806f is visible from only one node and will not be tested. Validation
requires that the disk be visible from at least two nodes. The disk is reported as visible at
node:<Node Name>

Under the possible causes section you will find the following warning message: *The
cluster does not use shared storage. A cluster must use a hardware solution based either
on shared storage or on replication between nodes. If your solution is based on
replication between nodes, you do not need to rerun Storage tests. Instead, work with
the provider of your replication solution to ensure that replicated copies of the cluster
configuration database can be maintained across the nodes.

Failover Cluster would not add SAS drives if they contain the following information:

Boot Files
System File or Page file
Pass through for Hyper-V

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Network Name resource fails to come
online in a Windows Server 2008 R2
Service Pack 1 failover cluster
Article • 12/26/2023

This article provides a solution to an issue where Network Name resource fails to come
online in a Windows Server 2008 R2-based failover cluster.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2797272

Symptoms
In a Windows Server 2008 R2 Service Pack 1-based cluster, when you attempt to bring
Network Name resources for the Services and Applications online, the Network Name
go into the failed state. However, the Cluster Network Name is online. Checking the
event logs, you may see some events logged.

Additionally, when you generate the cluster log on the failure node, you may see the
following entries:

INFO [RES] Network Name <VCO>: GetCoreNetnameObject_VSToken returning

status 0
INFO [RES] Network Name <VCO>: Obtained the security token for cluster name
account.
INFO [RES] Network Name <VCO>: Logon failed so priming local KDC cache to \\
<Member DC Name> for domain <DC Name>, status = 0 .
INFO [RES] Network Name <VCO>: Logon failed so priming local KDC cache to \\
<Member DC Name> for domain <DC Name>, status = 0 .
ERR [RES] Network Name <VCO>: Unable to Logon. winError 1326
WARN [RES] Network Name <VCO>: Unable to enumerate server tranports, error 5.
.
.
INFO [RES] Network Name <VCO>: adapter Local Area Connection 2 (1)
ERR [RES] Network Name <VCO>: The specified network name is currently hosted
by some other system in the network, So no attempt will be made to reset the
computer object's password associated with <VCO>.
Cause
The password for the VCO (Virtual Computer Object) is out of sync with Active Directory.
The CNO (Cluster Name Object) attempts to reset it, however, before it can do so, it
checks if there is another computer with the same name on the network, so as to not
reset that computer's Active Directory object password erroneously. It fails because this
check will return true if the C:\Windows\System32\drivers\etc\hosts file contains an
entry for the Cluster node's NetBIOS name.

Resolution
Edit the C:\Windows\System32\drivers\etc\hosts file and remove the entry for the
Cluster node.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A physical disk resource may not come
online on a cluster node
Article • 12/26/2023

This article helps solve an issue where a physical disk resource doesn't come online on a
cluster node.

Applies to: Windows Server 2012 R2

Original KB number: 981475

Symptoms
On a cluster node that is running Windows Server, a physical disk resource may enter
the Failed state when you try to move a group that contains the physical disk resource.
If you restart the cluster node that has the physical disk resource that did not come
online, the problem is temporarily resolved.

When this problem occurs, the following entries are logged in the Cluster log for the
physical disk resource that entered the failed state:

000020cc.000014d0::<DateTime> ERR Physical Disk <Disk Q:>:

DiskspCheckPath: GetFileAttrs(Q:) returned status of 87.
000020cc.000014d0::<DateTime> WARN Physical Disk <Disk Q:>:
DiskspCheckDriveLetter: Checking drive name (Q:) returns 87

Additionally, the following events are logged in the System Event log:

Event Type: Error

Event Source: ClusSvc
Event Category: Physical Disk Resource
Event ID: 1066
Date: <date>
Time: <time>
User: N/A
Computer: <node name>
Description: Cluster disk resource "Disk Q:" is corrupt. Run 'ChkDsk /F' to repair
problems. The volume name for this resource is "<\?\Volume{4323d41e-1379-11dd-
9538-001e0b20dfe6}>". If available, ChkDsk output will be in the file
 "C:\WINDOWS\Cluster\ChkDsk_Disk2_SigB05E593B.log". ChkDsk may write
information to the Application Event Log with Event ID 26180.

Event Type: Error

Event Source: ClusSvc
Event Category: Physical Disk Resource
Event ID: 1035
Date: <date>
Time: <time>
User: N/A
Computer: <node name>
Description: Cluster disk resource 'Disk Q:' could not be mounted.

Similarly, on a Windows Server cluster node you may see following entries are logged in
the Cluster log:

00000db0.00000868::<DateTime> WARN [RES] Physical Disk <Cluster Disk 1>:

OnlineThread: Failed to get volume guid for device \?
\GLOBALROOT\Device\Harddisk15\Partition1. Error 3
00000db0.00000868::<DateTime> WARN [RES] Physical Disk <Cluster Disk 1>:
OnlineThread: Failed to set volguid ??\Volume{3cb36133-0d0b-11df-afcf-
005056ab58b9}. Error: 183.
00000db0.00000868::<DateTime> INFO [RES] Physical Disk <Cluster Disk 1>:
VolumeIsNtfs: Volume \?\GLOBALROOT\Device\Harddisk15\Partition1\ has FS type
NTFS

Cause
This problem is known to occur when antivirus software that is not cluster-aware is
installed, upgraded, or reconfigured. For example, this problem is known to occur after
you install or migrate to Symantec Endpoint Protection 11.0 Release Update 5 (RU5) on
the cluster nodes.

Resolution
To resolve this problem, follow these steps:

1. Verify that this problem is caused by Symantec Endpoint Protection (SEP) 11.0
Release Update 5 (RU5). To do this, run the Handle.exe utility immediately after the
issue occurs on the cluster node where the physical disk resource did not come
online.
 At an elevated command prompt, type the following command, and then press
ENTER: Handle.exe -a -u drive_letter .

７ Note

The drive_letter placeholder is the drive designation for the cluster drive that
did not come online.

For example, assume that the drive designation for the cluster drive that did not
come online is drive Q. To run the Handle.exe utility in this scenario, type the
following command, and then press ENTER: Handle.exe -a -u Q: .

The problem is caused by the Symantec application if you receive the following
message that identifies the Smc.exe process as the process that owns the handle:

Handle v3.42
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

Smc.exe pid: 856 NT AUTHORITY\SYSTEM 66C: Q:

2. If the problem is caused by the Symantec application, contact Symantec to obtain

Symantec Endpoint Protection 11 Release Update 6 (RU6), which was released to
resolve this issue.

More information
For more information about the Handle.exe utility, see Handle v4.22.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to recover a deleted computer
object that supports a Network Name
resource in a failover cluster
Article • 12/26/2023

This article describes how to recover a deleted computer object that supports a Network
Name resource in a failover cluster.

Applies to: Windows Server 2012 R2

Original KB number: 950805

Summary
By default, the new security model in Windows Server 2008 or Windows Server 2008 R2
failover clustering includes Kerberos authentication. To create this security model, every
Client Access Point (CAP) that is created in a Windows Server 2008 or Windows Server
2008 R2 failover cluster contains a Network Name resource. The Network Name
resource has a corresponding Computer Account that is created in the Active Directory
directory service when the resource is online for the first time.

By default, the Computer Account is created in the Computers container. However, the
Computer Account can be relocated to another organizational unit (OU). The Computer
Account can also be pre-staged in an OU before the CAP is created. If these Computer
Accounts are deleted from Active Directory, availability of the Network Name resource
will be reduced.

The computer accounts that are created in Active Directory represent the Network
Name resources in a failover cluster. These accounts have the following distinct types:

The computer account that represents the name of the cluster is called the Cluster
Name Object (CNO). This account is the primary security context for a cluster.
Other computer accounts that belong to Network Name resources in the same
cluster are called Virtual Computer Objects (VCOs). These accounts are created by
the CNO. If either of these accounts is deleted from Active Directory, the next time
that the Network Name tries to go online, the Network Name fails, and the
following error message is logged in the System log: Event ID: 1207

Event Level: Error

Event Source: FailoverClustering

Event ID: 1207

Description: Cluster network name resource ResourceName cannot be brought online.

The computer object associated with the resource could not be updated in domain
DomainName for the following reason:

The text for the associated error code is: There is no such object on the server.

The cluster identity CNO$Name may lack permissions required to update the object.
Work with your domain administrator to ensure the cluster identity can update
computer objects in the domain.

and the following messages are logged in the cluster log:

WARN [RES] Network Name <FSCAP01>: Trying to remove credentials for LocalSystem
returned status C0000225, STATUS_NOT_FOUND is a non-critical failure for a remove
operation INFO [RES] Network Name <FSCAP01>: Initiating the Network Name
operation: 'Verifying computer object associated with network name resource FSCAP01'
INFO [RES] Network Name <FSCAP01>: Trying to find computer account FSCAP01
object GUID(d66e09dd8857e84da1f3a26fb1903e38) on any available domain controller.
WARN [RES] Network Name <FSCAP01>: Search for existing computer account failed.
status 80072030 WARN [RES] Network Name <FSCAP01>: Search for existing computer
account failed. status 80072030 INFO [RES] Network Name <FSCAP01>: Trying to find
object d66e09dd8857e84da1f3a26fb1903e38 on a PDC. WARN [RES] Network Name
<FSCAP01>: Search for existing computer account failed. status 80072030 INFO [RES]
Network Name <FSCAP01>: Unable to find object
d66e09dd8857e84da1f3a26fb1903e38 on a PDC. INFO [RES] Network Name
<FSCAP01>: GetComputerObjectViaGUIDEx() failed, Status 80072030. WARN [RES]
Network Name <FSCAP01>: Trying to remove credentials for LocalSystem returned
status C0000225, STATUS_NOT_FOUND is a non-critical failure for a remove operation
WARN [RHS] Resource FSCAP01 has indicated that it cannot come online on this node.
WARN [RCM] HandleMonitorReply: ONLINERESOURCE for 'FSCAP01', gen(8) result 5015.

Note: status 80072030 = There is no such object on the server

However, problems will occur even before the Network Name resource is cycled offline
and online. For example, a user or a highly available application may be unable to access
resources when a security token that represents the cluster computer object in Active
Directory cannot be obtained.

To recover from the deletion of a Computer Object that is associated with a cluster
Network Name resource is different for a CNO than recovering from the deletion of a
Computer Object for a VCO.
To recover a deleted computer object that corresponds to the CNO, follow these steps:

1. Coordinate with a domain administrator to first recover the deleted Computer

Object from the Deleted Objects container in Active Directory.

2. Verify that the Computer Object has been restored to the correct location, and
then enable the account.

3. Force domain replication to occur, or wait for the configured replication interval.

4. In the Failover Cluster Management Microsoft Management Console (MMC) snap-

in, right-click the failed network name that corresponds to the cluster name, point
to More actions, and then click Repair Active Directory Object.

７ Note

The user who follows these steps in the Failover Cluster Management MMC snap-in
must also have the "Reset Passwords" permission in the domain.

To recover a deleted computer object that corresponds to a VCO, follow these steps:

1. Coordinate with a domain administrator to first recover the deleted computer

object from the Deleted Objects container in Active Directory.
2. Verify that the computer object has been restored to the correct location, and then
enable the account.
3. View the security settings for the computer object, and then verify that the CNO
still has permissions to the object.
4. Force domain replication, or wait for the configured replication interval.
5. In the Failover Cluster Management MMC snap-in, right-click the failed Network
Name resource, and then click **Bring this resource online. If a deleted computer
object no longer exists in the Deleted Objects container, then the object never
existed or it was deleted and garbage collected after meeting or exceeding
tombstone lifetime. Never restore AD from a backup that is older than the
tombstone lifetime. This can induce lingering objects into the environment.

References
For more information, visit the following Microsoft Web sites:

Recovering a Deleted Cluster Name Object (CNO) in a Windows Server 2008 Failover
Cluster

Event ID 1207 - Active Directory permissions for cluster accounts

Active Directory backup and restore

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error (The parameter is incorrect) and
cluster validation fails against "Validate
Resource" status
Article • 12/26/2023

This article helps to resolve the error "The parameter is incorrect" that occurs when
cluster validation fails against the Validate Resource status.

Applies to: Windows Server 2016

Original KB number: 4561946

Symptoms
When you check the Active Directory organizational unit (OU), cluster validation fails
against the "Validate Resource" status, and you receive the following error message:

An error occurred while executing the test. The operation has failed. An error
occurred while checking the Active Directory organizational unit for the cluster
name resource. The parameter is incorrect.

If you try to create the client access points, the process can still fail if the IP address used
is the same as the address in the error message.

This problem can also occur after you grant CNO permission to the cluster OU, and the
user also has full control permissions on the CNO object.

Cause
The parameter error is caused when authenticated users don't have default Read
permissions on the default Computers container.

Resolution
To resolve this problem, grant the Read permission to authenticated users.
Authenticated users require Read permissions to objects that are in the Computers
container, even if the computer objects aren't there.

Status
A test has been added to cluster validation to specifically check for the CNO permission.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't bring a clustered resource online
troubleshooting guidance
Article • 12/26/2023

Try our Virtual Agent - It can help you quickly identify and fix common issues when

a resource fails to come online.

This guidance is designed to get you started on troubleshooting issues where clustered
resources can't be brought online in a Windows-based cluster environment.

Troubleshooting checklist
1. When a resource fails to come online, Event ID 1069 is logged on the server that's
hosting the resource of concern:

Error 1069 Microsoft-Windows-FailoverClustering Cluster resource '<Name of

the Resource>' of type '<Resource Type>' in clustered role '<Available
Storage>' failed.

2. Check the System event log for the Event ID, and then check if other errors or
warnings are logged. For example:

If a physical disk resource can't come online, check for disk-related errors or
warnings. For example, Event ID 129 (bus reset) or Event ID 153 (IO retried).

If a network name resource can't come online, check for DNS-related entries.

If an IP address resource can't come online, check for NIC-related events,

errors, or warnings.

3. If nothing except Event ID 1069 is logged, review the cluster log for further
troubleshooting. Open an elevated PowerShell prompt and run the following
cmdlet:

PowerShell

Get-ClusterLog -Destination C:\temp

７ Note
 This cmdlet will generate the cluster logs on all cluster members and copy
them to the C:\temp folder on the server where the cmdlet was executed.

4. Search for strings in the cluster log that might correlate with Event ID 1069:

Output

[RCM] rcm::RcmResource::HandleFailure
[RHS] Online for resource
OnlineThread: Error <Code> bringing resource online.
[RHS] RhsCall::DeadlockMonitor: Call ONLINERESOURCE

７ Note

The placeholder <Code> represents the error code and can differ depending
on the issue.

Common support scenarios

Can't bring a network name online

Can't bring a physical disk online

Can't bring an IP address online

Data collection
Before contacting Microsoft Support, you can gather information about the issue.

Prerequisites
1. TSS must be executed in the context of an account with admin rights on the
local system, and EULA must be accepted (once EULA is accepted, TSS won't
prompt it again).

2. We recommend that the local machine uses the RemoteSigned PowerShell

execution policy.

７ Note
 In case the current PowerShell execution policy doesn't allow running TSS, the
following actions could be taken:

Set RemoteSigned for the Process level and run the following cmdlet:

PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned

Verify if the change has taken effect, run the following cmdlet:

PS C:\> Get-ExecutionPolicy -List

Since the Process level permissions only apply to the current PowerShell session,
once the given PowerShell window in which TSS runs is closed, the assigned
permission for the Process level will also go back to the previously configured state.

Gather key information before you contact Microsoft

Support
1. Download TSS and unzip it to the C:\tss_tool folder.

2. Open an elevated PowerShell prompt and change the directory to the C:\tss_tool
folder.

3. Start the trace by running the cmdlet on the source and destination nodes.

PowerShell

.\Get-psSDP.ps1

Feedback
Was this page helpful?  Yes  No

Provide product feedback

New SMB 3.0 features in the Windows
Server file server
Article • 12/26/2023

This article describes new features of the Server Message Block (SMB) 3.0 protocol.

Applies to: Windows 8.1 - all editions, Windows Server 2012 R2 and later versions of
Windows
Original KB number: 2709568

Summary
Windows Server introduces new server message block (SMB) file server features. To take
advantage of these new features, the SMB client and SMB server must support SMB 3.0.

The SMB 2.x protocol was introduced in Windows Server 2008 and in Windows Vista.

The SMB 3.0 protocol was introduced in Windows Server 2012 and in Windows 8.

New SMB features introduced in the Windows

file server
SMB Transparent Failover
SMB Scale Out
SMB Multichannel
SMB Direct
SMB Encryption
VSS for SMB file shares
SMB Directory Leasing
SMB PowerShell

SMB Transparent Failover

Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
SMB Transparent Failover functionality.

SMB 1.0- and SMB 2.x-capable clients will be able to connect to, and access, shares that
are configured to use the Continuously Available property. However, SMB 1.0 and SMB
2.x clients won't benefit from the SMB Transparent Failover feature. If the currently
accessed cluster node becomes unavailable, or if the administrator makes administrative
changes to the clustered file server, the SMB 1.0 or SMB 2.x client will lose the active
SMB session and any open handles to the clustered file server. The user or application
on the SMB client computer must take corrective action to reestablish connectivity to
the clustered file share.

７ Note

SMB Transparent Failover is incompatible with volumes enabled for short file name
(8.3 file name) support or with compressed files (such as NTFS-compressed files).

SMB Scale Out

Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
SMB Scale Out feature.

SMB 1.0 clients don't contain the required client functionality to access SMB scale-out
file shares and will receive an Access Denied error message when they try to connect to
a scale-out file share.

SMB scale-out file shares are always configured so that the Continuously Available
property is set. SMB 2.x clients will be able to connect to SMB scale-out file shares but
won't benefit from the SMB Transparent Failover functionality.

SMB Multichannel
Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
SMB Multichannel functionality. SMB 1.0 and SMB 2.x clients will use a single SMB
connection.

SMB Direct (SMB over Remote Direct Memory Access

[RDMA])
SMB Direct is available in Windows Server 2012, Windows 10 (Enterprise, Education, and
Pro for Workstations editions), and later versions. SMB Direct Functionality requires that
the SMB client and SMB server support SMB 3.0.

SMB Encryption
Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
SMB Encryption functionality.

VSS for SMB file shares

Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
Volume Shadow Copy Service (VSS) for SMB file shares functionality.

SMB Directory Leasing

Both the SMB client and SMB server must support SMB 3.0 to take advantage of the
SMB Directory Leasing functionality.

SMB PowerShell
SMB PowerShell management cmdlets were introduced in Windows Server 2012 and in
Windows 8. Older SMB clients and SMB servers will have to continue using down-level
tools for management (for example, net.exe) and APIs (for example, Win32 APIs).

References
For more information about the common errors you may experience with SMB 3.0, see
/troubleshoot/windows-server/networking/error-messages-smb-connections .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommended hotfixes and updates for
Windows Server 2012-based failover clusters
Article • 12/26/2023

This article describes the hotfixes that are currently available for Windows Server 2012-based failover
clusters and highly recommended to be installed on each server of a failover cluster.

Applies to: Windows Server 2012

Original KB number: 2784261

Summary
Failover Cluster Management enables multiple servers to provide a high availability of server roles.
Failover Cluster Management is frequently used for file services, virtual machines, database
applications, and mail applications.

） Important

The process for installing service packs and hotfixes on Windows Server 2012 differs from the
process in earlier versions. In Windows Server 2012, you can use the Cluster-Aware Updating
(CAU) feature. CAU automates the software-updating process on clustered servers while
maintaining availability. For more information, see Cluster-Aware Updating Overview.

Introduction
The following Microsoft Knowledge Base articles describe the currently available fixes that are highly
recommended to be installed on all failover clusters. Most of the updates apply to computers that
are running Windows Server 2012. Some updates, such as KB 976424 , may be needed on
computers that are running Windows Server 2008 R2 or Windows Server 2008 if those operating
systems are present in the environment.

These updates are considered to be important to install to ensure the highest level of reliability.

７ Note

You may substitute a newer monthly rollup in place of KB 4282815. The remainder of the
updates in this list are still needed as some components in those updates released before
September 2016 and are not included in the newer monthly rollup.

ﾉ Expand table
Date Knowledge Title Component Why we recommend this
when the Base hotfix
hotfix article
was
added

September 3185280 September 2016 update rollup for Clussvc.exe Resolves an issue when a cluster
30, 2016 Windows Server 2012 node sends an Internet Control
Message Protocol (ICMP)
request to a gateway, TCPIP
returns a timeout error (Error
code 11010,
IP_REQ_TIMED_OUT), even if
ICMP doesn't receive a timeout.
Available from Windows Update.
Includes the fixes in 3090343
and 3076953 .

July 22, 3062586 0x000000D1 Stop error on a Windows Netft Prevents a Stop 0xD1 when
2015 Server 2012-based cluster processing a network buffer list
(NBL). Not all 0x000000D1 Stop
errors are caused by this issue.
Available for individual
download.

July 6, 3018489 "No host bus adapter is present" error Storport To receive the updated logging
2015 when querying SAS cable issues in capabilities of storport.sys
Windows Server 2012 R2 or Windows covered in KB 2819476 plus
Server 2012 the fixes in KB 3018489 , KB
2908783 and KB 2867201 .
Available for individual
download.

April 22, 3048474 WMI provider cannot start when you WMI Recovers a WMI provider when it
2015 manage Hyper-V or failover cluster in has hit the WMI memory
Windows 8 or Windows Server 2012 threshold so you can continue to
manage Hyper-V or failover
cluster in Windows 8 or
Windows Server 2012. Available
for individual download.

January 3004098 Memory leak occurs when you create or Csvfs.sys Prevents a memory leak when
13, 2015 delete CSV snapshots by using a VSS you create or delete CSV
hardware provider in Windows snapshots by using a hardware
Volume Shadow Copy Service
(VSS) provider. Available for
individual download.

April 8, 2916993 Stop error 0x9E in Windows Server 2012 Ntoskrnl.exe Prevents a lock contention and
2014 or Windows 8 Stop 0x9e when a large file is
mapped into the system cache,
for instance a backup operation
is copying files from snapshots.
Available for individual
download.
Date Knowledge Title Component Why we recommend this
when the Base hotfix
hotfix article
was
added

March 17, 2929869 CSV snapshot file is corrupted when Csvflt.sys Prevents CSV snapshot file
2014 you create some files on the live volume Csvfs.sys corruption when a file is deleted
Volsnap.sys and recreated on the live
volume. Available for individual
download.

Jan. 15, 2913695 OffloadWrite is doing NTFS.sys Performance improvement when

2014 PrepareForCriticalIo for the whole VHD there is an offload write for a
in a Windows Server 2012 or Windows virtual hard disk (VHD) in the
Server 2012 R2 Hyper-V host host. Available for individual
download.

Jan. 2, 2878635 Update is available that improves the Multiple This hotfix prevents a CSV
2014 resiliency of the cloud service provider failover by fixing an underlying
in Windows Server 2012: December issue in NTFS, software
2013 snapshots, and by increasing the
overall resilience of the Cluster
service and CSV during expected
pause states. Available for
individual download.

Nov. 14, 2894464 Error message when you try to schedule Failover This hotfix resolves an error
2013 a shadow copy task in Windows Server Cluster when you try to schedule a
2012 Resource DLL shadow copy task on a shared
disk. Available for individual
download.

June 14, 2838043 Can't access a resource that is hosted Failover This hotfix prevents an error
2013 on a Windows Server 2012-based Cluster when resources that are hosted
failover cluster Resource DLL on a Windows 8-based or
Windows Server 2012-based
failover cluster are accessed
from a Windows XP-based or
Windows Server 2003-based
client computer.

This hotfix also resolves an Event

ID 1196 with error: The handle is
invalid when the cluster network
name resource does not come
online and register in DNS.

Available for individual

download and included in
2889784 (Windows RT,
Windows 8, and Windows Server
2012 update rollup: November
2013).
 Date Knowledge Title Component Why we recommend this
when the Base hotfix
hotfix article
was
added

Jan. 23, 2803748 Failover Cluster Management snap-in Failover Resolves a crash in the Failover
2013 crashes after you install update 2750149 Cluster Cluster Management snap-in
on a Windows Server 2012-based Management after update 2750149 is installed
failover cluster snap-in on a Windows Server 2012-
based failover cluster. Available
from Windows Update or the
Microsoft Download Center.

Nov. 13, 2770917 Windows 8 and Windows Server 2012 Multiple Improves clustered server
2012 cumulative update: November 2012 performance and reliability in
Hyper-V and Scale-Out File
Server scenarios. Improves SMB
service and client reliability
under certain stress conditions.
Install update 2770917 by using
Windows Update in order to
receive the cumulative update as
described in KB 2770917.

Nov. 13, 976424 Error code when the kpasswd protocol KDCSVC Install on every domain
2012 fails after you perform an authoritative controller that is running
restore: Windows Server 2008 Service
"KDC_ERROR_S_PRINCIPAL_UNKNOWN" Pack 2 or Windows Server 2008
R2 in order to add a Windows
Server 2012 failover cluster.
Otherwise, Create Cluster may
fail with error message:
CreateClusterNameCOIfNotExists
(6783): Unable to set password
on <ClusterName$> when it
tries to set the password for the
cluster computer object. This
hotfix is included in Windows
Server 2008 R2 Service Pack 1.

More information
For more information about the recommended hotfixes and updates for Windows Server 2012-
based Hyper-V servers and Windows Server 2012 R2-based failover clusters, see the following
resources:

Hyper-V: Update List for Windows Server 2012

Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Corrupted memory dump file when you
try to obtain a full memory dump file
from a virtual machine that is running in
a cluster environment
Article • 12/26/2023

This article provides a solution to an issue where a corrupted memory dump file is
generated when you try to obtain a full memory dump file from a virtual machine.

Applies to: Windows Server 2012 R2

Original KB number: 2913486

Symptoms
You have a virtual machine that is running in a cluster environment in Windows Server
2012 or Windows Server 2008 R2. When you try to obtain a full memory dump file from
the virtual machine, a corrupted memory dump file is generated. While the memory
dump file is loading, you may receive the following message:

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not present or unreadable.

GetContextState failed, 0xD0000147

Unable to get program counter

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

Additionally, you may notice that writing a full memory dump file does not finish and
that the virtual machine is restarted on another node in the cluster.

Cause
This issue occurs because the Enable heartbeat monitoring for the virtual machine
option is selected for the virtual machine. This option resets the clustered virtual
machine after one minute (the default value), and the clustered virtual machine requires
longer that one minute to finish writing the memory dump.
 ７ Note

Heartbeats between the virtual machine and Virtual Machine Manager occur every
few seconds. It can require up to one minute to detect that the virtual machine is
down because the virtual machine resource checks the heartbeat status from
Virtual Machine Manager in its isAlive entry-point function. By default, isAlive
occurs one time every minute. However, the heartbeats may stop 30 seconds
before the one-minute interval. In this case, the cluster can restart the virtual
machine on the same server or fail it over to another node.

Resolution
To resolve this issue, disable the Enable heartbeat monitoring for the virtual machine
option.

Option 1: Change the settings from the GUI

1. Open Failover Cluster Manager.
2. Click Roles, and then find the virtual machine resource.
3. On the Resources tab, right-click the virtual machine.
4. Click Properties, and then click the Settings tab.
5. In Heartbeat Setting, click to clear the Enable automatic recovery for application
health monitoring check box.
6. Click to clear the Enable heartbeat monitoring for the virtual machine check box,
and then click OK.

Option 2: Change the settings by using Windows

PowerShell
1. Start Windows PowerShell.

2. Check the virtual machine name. To do this, type the following Windows
PowerShell command:

PowerShell

PS C:\> Get-ClusterResource

3. Check whether the Enable heartbeat monitoring for the virtual machine and
Enable automatic recovery for application health monitoring options are
 selected. To do this, type the following Windows PowerShell command:

PowerShell

PS C:\> Get-ClusterResource <VirtualMachineName> | Get-ClusterParameter

CheckHeartbeat

4. When the CheckHeartbeat value is 1, both options are selected. To cancel both
options, change this value to 0. To do this, type the following Windows PowerShell
command:

PowerShell

PS C:\> Get-ClusterResource <VirtualMachineName> | Set-ClusterParameter

CheckHeartbeat 0

If you want to cancel only the Enable automatic recovery for application health
monitoring option, you should run the following Windows PowerShell command:

PowerShell

PS C:\> (Get-ClusterResource <Object>).EmbeddedFailureAction = 1

More information
Mini and kernel memory dump files are written successfully. This occurs because the
time that is required to write these files doesn't exceed the one-minute threshold.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster service startup options
Article • 12/26/2023

This article lists all the available switches that can be used as startup parameters to start
the Cluster service.

Applies to: Windows Server 2012 R2

Original KB number: 258078

Summary
This is a list of all the available switches that can be used as startup parameters to start
the Cluster service.

To do this, go to the properties of the service, put the appropriate switch in the Start
Parameters box, and then click Start.

You can also use the switches when you start the Cluster service from the command line.
For example:

Console

net start clussvc.exe / switch

７ Note

Include a dash (-) before the switch for Microsoft Windows 2000 Server and earlier
versions.

The debug switch has special startup parameters. See the Debug section later in
this article for correct usage.

Windows Server 2003 includes abbreviations for each switch. This simplifies using
Cluster service startup switches. For example, you can start the service with the
/FixQuorum switch or the /FQ switch.

Valid option switches include the following:

ﾉ Expand table
 Switch Function Windows 2003
Abbreviation

FixQuorum Don't mount the quorum device, and quorum FQ

logging turned off.

NoQuorumLogging Quorum logging turned off. NQ

Debug Displays events during the start of Cluster service.

For special syntax, see the "Debug" section later in
this article.

LogLevel N Sets the log level for debug mode.

DebugResMon The Cluster service waits for a debugger to be DR

attached to all Resource Monitor processes at their
start.

Windows 2000 and later only switches include the following.

ﾉ Expand table

Switch Function Windows 2003

Abbreviation

ResetQuorumLog Dynamically re-creates the quorum log and RQ

checkpoint files (this functionality is automatic in
Microsoft Windows NT 4.0).

NoRepEvtLogging No replication of Event Log entries.

Windows Server 2003 and later only switches include the following.

ﾉ Expand table

Switch Function Windows 2003

Abbreviation

ForceQuorum or Force a majority node set with the node list N1, FO
<N1,N2,...> N2, and so forth. (Applicable only for Majority
Node Set quorum.)

NoGroupInfoEvtLogging Don't log events to the event log related to NG

group online and offline.

Description of switches
The following is a description of some of the switches:

Debug
Function: Cluster logging may not contain any helpful information in diagnosing Cluster
service to start failures. This is because the Cluster service may fail prior to the
Cluster.log starting. Starting the Cluster service with this switch displays the initialization
of the Cluster service and can help you identify these early occurring problems.

Requirements: Use this switch for temporary diagnostic purposes only. If the Cluster
service fails to start because of a logon error of the service account, or another system-
related error, the service may not have a chance to run. As a result, a cluster.log file may
not be created. This method runs the service outside the normal environment given by
the Service Control Manager. To use this switch, you must be logged on locally with
administrative rights and start the command from the command prompt. Don't use the
debug switch for normal use or for any length of time. The service doesn't run as
efficiently with the option set.

Usage scenarios: This switch must be used only when the Cluster service fails to start up.
This switch will display on the screen the operation of the Cluster service as it tries to
start. This switch can only be used when starting the service from the command prompt,
and you must be in the folder where the Cluster service is installed. By default, this is
%SystemRoot%\Cluster. This is also the only switch that you don't use with the net start
command to start the service.

Operation: Open a command prompt, change to the %SystemRoot%\cluster folder, and

then type the following clussvc /debug [loglevel#] " .

where loglevel# is one of the following.

ﾉ Expand table

# Description

0 No logging takes place.

1 Only errors are logged.

2 Errors and warnings are logged.

3 All events, including those not written to the event log, are logged.

Alternatively, you can also use the set command to control the cluster log level when
you use the debug switch. From the command prompt, type the following set
clusterloglevel= x where x is one of the values that is shown in the previous table.

The Cluster service sends output to the window similar to what you would see in the
cluster.log. Alternatively, you can also capture this information to a file by using the
following command syntax:

clussvc /debug > c:\debug.log

When the Cluster service is running correctly, press CTRL+C to stop the service.

７ Note

You can use the ClusterLogLevel environment variable to control the output level
when you use the debug switch.

FixQuorum
Function: Lets the cluster service start up despite problems with the quorum device. The
only resources that will be brought online once the service is started is the Cluster IP
Address and the Cluster Name. You can open Cluster Administrator and bring other
resources online manually.

Requirements: This switch MUST be used only in diagnosis mode on a very temporary
basis and not during normal operation. Only one node must be started up using this
switch and a second node must not be attempted to be joined to the node started up
using this switch. Typically, this switch is used alone.

Usage scenarios: If the cluster service is unable to start up in the normal way because of
the failure of the quorum resource, users can start up the cluster service in this mode
and attempt to diagnose the failure.

Operation: After the cluster service is started up, all resources including the quorum
resource remain offline. Users can then manually try to bring the quorum resource
online and monitor the cluster log entries as well as the new event log entries and
attempt to diagnose any problems with the quorum resource. The syntax is as follows:
net start clussvc /fixquorum .

ResetQuorumLog
Function: If the quorum log and checkpoint file isn't found or is corrupt, this can be used
to create files based on the information in the local node's
%SystemRoot%\Cluster\CLUSDB registry hive. If the quorum log file is found to be in
proper order, this switch has no effect.

Requirements: Typically, only one node is started up by using this switch, and this switch
is used alone. It must be used only by experienced users who understand the
consequences of using information that is potentially out of date, to create a new
quorum log file.

Usage scenarios: This switch must be used only when the Cluster service fails to start up
on a Windows 2000 or later machine because of a missing or corrupted quorum log
(Quolog.log) and Chkxxx.tmp files. Windows NT 4.0 will automatically re-create these
files if they don't exist. This functionality was added in Windows 2000 to give more
control over the start of the Cluster service.

７ Note

If the cluster is running Windows 2000 Service Pack 4 (SP4) and the hotfix 872970
has previously been installed, /resetquorumlog is no longer needed. The default
behavior is to create a new log file at startup if the old one is missing or corrupt.

Operation: The Cluster service does an auto-reset of the quorum log file if it's found to
be missing or corrupted by using the information in the currently loaded cluster hive by
using the file %systemroot%\Cluster\CLUSDB. The syntax is as follows:

Console

net start clussvc /resetquorumlog

DebugResMon
Function: Helps you to debug the resource monitor process and, therefore, the resource
dynamic-link libraries (DLLs) that are loaded by the resource monitor. You can use any
standard Windows-based debugger.

Requirements: Can only be used when the cluster service is started from the command
prompt and when using the debug switch. There's no equivalent registry setting that
can be used when Cluster service is run as a service. Debugger must be available for
attaching to the resource monitor when it starts up. Typically, this switch is used alone.

Usage scenarios: Developers can use this switch to debug the resource monitor process
and their custom resource DLLs. This option is extremely useful if a bug in a resource
DLL causes the resource monitor process to quit unexpectedly soon after it's started up
by the Cluster service and before users can manually attach a debugger to the resource
monitor process.

Operation: Just before the resource monitor process is started up, the Cluster service
process waits with a message (Waiting for debugger to connect to the resmon process
X),where X is the Process ID (PID) of the resource monitor process. The Cluster service
does this waiting for all resource monitor processes created by it. After the user attaches
a debugger to the resource monitor process, and the resource monitor process starts
up, the Cluster service continues with its initialization.

NoRepEvtLogging
Function: The norepevtlogging switch prevents replication of those events recorded in
the event log. This switch is useful in reducing the amount of information displayed in
the command window by filtering out events already recorded in the event log. Event
log replication is a feature that was added in Windows 2000.

Usage scenarios: This switch is used to prevent replication of the event logs. If there's a
large number of event log entries, the Cluster service will replicate these, and log these
to the cluster.log. This can cause the cluster.log to wrap quickly. The switch can also be
used to start the Cluster service and log those events that aren't recorded in the event
log to a local file, Debugnorep.log. The syntax is as follows:

Console

clussvc /debug /norepevtlogging > c:\debugnorep.log\

Operation: The norepevtlogging command can be set as a start parameter when starting
the Cluster service from the Computer Management console.

The command-line syntax is:

Console

net start clussvc /norepevtlogging

This command prevents the node that was started with this switch from replicating its
information to other nodes, but it will still receive information from other nodes that
were started normally.

NoQuorumLogging
Function: Turns off all logging of the cluster registry changes to the quorum disk.
Registry check pointing doesn't affect other resources.

Requirements: This switch must be used only in diagnosis mode to diagnose problems
with the quorum log file (Quolog.log) or the cluster hive checkpoint file (Chkxxx.tmp) in
the \MSCS directory on the quorum drive. If one node is started up by using this switch,
any other node must also be started up by using this switch. Typically, this switch is used
on one node alone.

Usage scenarios: Use this switch when the quorum log file or checkpoint files become
corrupted and you want to manually replace these files with backup copies.

Operation: The Cluster service completely bypasses the logging functionality in this case.
When run in this mode, "partition-in-time" scenarios can occur. If this is the case, cluster
node registry entries can fall out of synchronization, and new changes can be lost. The
syntax is as follows: net start clussvc /noquorumlogging .

ForceQuorum
Function: When you use a Majority Node Set (MNS) quorum model on a Windows
Server 2003 cluster, in some cases a cluster must be allowed to continue to run even if it
doesn't have quorum (majority). Consider the case of a geographically dispersed cluster
with four nodes at the primary site and three nodes at the secondary site. While there
are no failures, the cluster is a seven-node cluster where resources can be hosted on any
node, on any site. If there's a communications failure between the sites or if the
secondary site is taken offline (or fails), the primary site can continue because it will still
have quorum. All resources will be re-hosted and brought online at the primary site.

In the event of a catastrophic failure of the primary site, however, the secondary site will
lose quorum, and, therefore, all resources will be terminated at that site. One of the
primary purposes for having a multi-site cluster is to survive a disaster at the primary
site; however, the cluster software itself can't make a determination about the state of
the primary site. The cluster software can't differentiate between a communications
failure between the sites and a disaster at the primary site. That must be done by
manual intervention. In other words, the secondary site can be forced to continue even
though the Cluster service believes it doesn't have quorum. This is known as forcing
quorum.

Because this mechanism is effectively breaking the semantics associated with the
quorum replica set, it must only be done under controlled conditions. In the example
above, if the secondary site and primary site lose communication and an administrator
forces quorum at the secondary site, resources will be brought online at BOTH sites,
thus allowing the potential for inconsistent data or data corruption in the cluster.

Requirements: Forcing quorum is a manual process that requires that you stop the
Cluster service on ALL the remaining nodes. The Cluster service must be told which
nodes should be considered as having quorum.

Usage scenarios: Special care must be taken if and when the primary site comes back
because the nodes are configured as part of the cluster. While a cluster is running in the
force quorum state, it's fully functional. For example, nodes can be added or removed
from the cluster; new resources, groups, and so forth, can be defined.

７ Note

The Cluster service on all nodes NOT in the force quorum node list must remain
stopped until the force quorum information is removed. Failure to do so can lead to
data inconsistencies OR data corruption.

Operation: Set up the Cluster service startup parameters on ALL remaining nodes in the
cluster. This is done by starting up the Services control panel, selecting the Cluster
service, and then entering the following in the Start parameters option:

Console

net start clussvc /forcequorum node_list

For example, if the secondary site contains Node5, Node6, and Node7, and you wanted
to start the Cluster service and have those be the only nodes in the cluster, use the
following command:

Console

net start clussvc /forcequorum /forcequorum node5,node6,node7

７ Note

There should be no spaces in the key (except where there are spaces in the node
names themselves).
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster Service Stops Responding on a
Cluster Node When You Restart the
Active Node
Article • 12/26/2023

This article provides a resolution for the issue that Cluster Service stops responding on a
Cluster Node when you restart the Active Node.

Applies to: Windows Server 2012 R2

Original KB number: 822050

Symptoms
When you restart the active node of a server cluster that consists of two or more nodes,
you experience all the following symptoms:

If you are running Cluster Administrator on the remaining nodes, you receive the
following error message when you try to connect to the cluster:

Cluster 'ClusterName' is no longer available.

If you try to start Cluster Administrator, Cluster Administrator stops responding,

and you may receive the following error message:

An error occurred trying to open the cluster at 'ServerName':

The interface is unknown.

Error ID: 1717 (000006b5).

When you view the contents of C:\Winnt\ Cluster.log, you see information similar
to:

[FM] OnlineGroup: Failed on resource e3f4af72-6454-4199-b9af-fa6f57032a65.

Status 70
Microsoft Clustering Service suffered an unexpected fatal error
at line 701 of source module D:\nt\private\cluster\service\fm\group.c. The
error code was 70.
 When the restarted cluster node starts successfully, the Cluster Administrator
program that is running on the other nodes responds as you expect.

Cause
This issue occurs if you pause one node of a server cluster and then you restart the
active cluster node. When the active node restarts, the paused node tries to bring
resource groups online. Because this node is paused, the node cannot make additional
connections, and it cannot bring the Quorum disk group online. Error code 70
corresponds to the following error message:

The remote server has been paused or is in the process of being started.

７ Note

These results will also occur in clusters that have more than two nodes. Even
though a non-paused node exists in a working state when the active node is
restarted, if the paused node is the first node that is contacted to take ownership of
the quorum disk. The non-paused node does not have the opportunity to arbitrate
for the quorum disk.

Resolution
To resolve this issue, resume the paused cluster node before you restart the active
cluster node.

７ Note

Before you resume a paused cluster node, you must first determine if a cluster
node is paused.

1. Click Start, click Run, type cmd in the Open box, and then click OK.

2. At the command prompt, type cluster node, and then press ENTER. Output is
similar to:

７ Note
 The following sample output is based on a two-node cluster configuration. If
you have more than two nodes, the additional nodes will also appear in the
list.

Node Node ID Status

-------------- --------- ---------------------
CLUSTER-1 1 Paused
CLUSTER-2 2 Up

７ Note

If the only cluster node that is not paused is in the process of restarting, you
receive the following error message:
System error 1753 has occurred. There are no more endpoints available from
the endpoint mapper.

3. At the command prompt, type cluster node node_name /resume (where

node_name is the name of the cluster node) and then press ENTER.

For example, type cluster node cluster-1 /resume, and then press ENTER.
Information appears that is similar to:

Resuming node 'cluster-1'...

Node Node ID Status

-------------- --------- ---------------------
CLUSTER-1 1 Up

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot the Cluster service
account when it modifies computer
objects
Article • 12/26/2023

This article describes how to troubleshoot the Cluster service when it creates or modifies
a computer object in Active Directory for a server cluster (virtual server).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 307532

Active Directory access rights for creating a

computer object
By default, members of the Domain Users group are granted the user right to add
workstations to a domain. By default, this user right is set to a maximum quota of 10
computer objects in Active Directory. If you exceed this quota, the following event ID
message is logged:

If several clusters are using the same domain account as their Cluster service
account, you may receive this error message before you create ten computer
objects in a given cluster. One way to resolve this issue is to grant the Cluster service
account the Create Computer Objects permission on the Computers container. This
permission overrides the Add Workstations to a Domain user right, which has a
default quota of ten.

To verify that the Cluster service account has the Add Workstations to a Domain user
right:

1. Sign in to the domain controller on which the Cluster service account is stored.

2. Start the Domain Controller Security Policy program from Administrative Tools.

3. Click to expand Local Policies, and then click to expand User Rights Assignments.

4. Double-click Add Workstations to a Domain and note the accounts that are listed.

5. The Authenticated Users group (the default group) should be listed. If it isn't listed,
you must grant this user right to either the Cluster service account or a group that
contains the Cluster service account on the domain controllers.
 ７ Note

You must grant this user right to the domain controllers because computer
objects are created on the domain controllers.

6. If you explicitly add the Cluster service account to this user right, run gpupdate on
the domain controller (or run secedit for Windows 2000) so that the new user
right is replicated to all domain controllers.

7. Verify that the policy won't be overwritten by another policy.

Cluster Service account doesn't have proper

user rights on local node
Verify that the Cluster Service account has the appropriate user rights on each node of
the cluster. The Cluster Service account must be in the local administrators group and
should have the rights listed below. These rights are given to the Cluster Service account
during the configuration of the Cluster node. It's possible that a higher-level policy is
over-writing the local policy or that an upgrade from a previous operating system
doesn't add all of the required rights. To verify that these rights are given on the local
node, follow these procedures:

1. Start the Local Security Settings console from the Administrative Tools group.

2. Navigate to User Rights Assignments under Local Policies.

3. Verify that the Cluster Service account has explicitly been given the following
rights:

Sign in as a service
Act as part of the operating system
Back up files and directories
Adjust memory quotas for a process
Increase scheduling priority
Restore files and directories

７ Note
 If the Cluster Service account has been removed from the local Administrators
Group, manually re-create the Cluster service account and give the Cluster
Service the required rights.

If any of the rights are missing, give the Cluster Service account explicit rights for it,
then stop and restart the Cluster Service. The added rights don't take effect until
you restart the Cluster Service. If the Cluster Service account still can't create a
Computer Object, verify that a Group Policy isn't over-writing the Local Policy. To
do it, you can either type gpresult at the Command Prompt if you are in a
Windows 2000 Domain or Resultant Set of Policy (RSOP) from an MMC Snap-in if
you are on a Windows Server 2003 domain.

If you are in a Windows Server 2003 domain, search in Help and Support on
"RSOP" for instructions on using Resultant Set of Policy.

If the Cluster Service account doesn't have the "Act as part of the operating
system" right, the Network Name resource will fail and the Cluster.log will register
the following message:

Use the above steps to verify that the Cluster Service account has all the
required rights. If the local security policies are being over-written by a Domain
or Organizational Unit (OU) Group policy, then there are several options. You
can place the Cluster nodes into their own OU that has the "Allow inheritable
permissions from parent to propagate to this object" de-deselected.

Required access rights when using a pre-

created computer object
If members of the Authenticated Users group or the Cluster service account are blocked
from creating a computer object, if you're the domain administrator, you must pre-
create the virtual server computer object. You must grant certain access rights to the
Cluster service account on the pre-created computer object. The Cluster service tries to
update the computer object that matches the NetBIOS name of the virtual server.

To verify that the Cluster service account has the proper permissions on the computer
object:

1. Start the Active Directory Users and Computers snap-in from Administrative Tools.

2. On the View menu, select Advanced Features.

3. Locate the computer object that you want the Cluster service account to use.
 4. Right-click the computer object, and then select Properties.

5. Select the Security tab, and then select Add.

6. Add the Cluster service account or a group that the Cluster Service account is a
member of.

7. Grant the user or the group the following permissions:

Reset Password
Validated Write to DNS Host Name
Validated Write to Service Principal Name

8. Select OK. If there are multiple domain controllers, you may need to wait for the
permission change to be replicated to the other domain controllers (by default, a
replication cycle occurs every 15 minutes).

Network name resource doesn't come online

when kerberos is disabled
A Network Name resource doesn't come online if a computer object exists but you
don't select the Enable Kerberos Authentication option. To resolve the issue, use either
of the following procedures:

Delete the corresponding computer object in Active Directory.

Select Enable Kerberos Authentication on the Network Name resource.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot cluster issue with Event ID
1135
Article • 12/26/2023

This article helps you diagnose and resolve Event ID 1135, which may be logged during
the startup of the Cluster service in Failover Clustering environment.

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure
Stack HCI, versions 21H2 and 20H2

Try our Virtual Agent - It can help you quickly identify and fix common Active

Directory replication issues.

Start page
Event ID 1135 indicates that one or more Cluster nodes were removed from the active
failover cluster membership. It may be accompanied by the following symptoms:

Cluster Failover\nodes being removed from active failover cluster membership:

Having a problem with nodes being removed from active Failover Cluster
membership

Event ID 1069:

Event ID 1069 - Clustered Service or Application Availability

Event ID 1177 for Quorum loss:

Event ID 1177 - Quorum and Connectivity Needed for Quorum

Event ID 1006 for Cluster service halted:

Event ID 1006 - Cluster Service Startup

A validation and the network tests would be recommended as one of the initial
troubleshooting steps to ensure there are no configuration issues that might be a cause
for problems.

Check if installed the recommended hot fixes

The Cluster service is the essential software component that controls all aspects of
failover cluster operation and manages the cluster configuration database. If you see the
event ID 1135, we recommend you to install the fixes mentioned in the following articles
and reboot all the nodes of the cluster, then observe if issue reoccurs.

Recommended hotfixes and updates for Windows Server 2012 R2-based failover
clusters
Recommended hotfixes and updates for Windows Server 2012-based failover
clusters
Recommended hotfixes and updates for Windows Server 2008 R2 SP1 failover
clusters

Check if the cluster service running on all the nodes

Follow the following command according to your Windows operation system to validate
that cluster service is continuously running and available.

For Windows Server 2008 R2 cluster

From an elevated command prompt, run cluster.exe node /stat .

For Windows Server 2012 and Windows Server 2012 R2 cluster

Run the following PowerShell cmdlet: Get-ClusterResource

Is the cluster service continuously running and available on all the nodes?

Several scenarios of Event ID 1135

We want you to take a closer look on at the System Event logs on all the nodes of your
cluster. Review the Event ID 1135 that you're seeing on the nodes and copy all the
instances of this event. This will make it convenient for you to look at them and review.

Output

Event ID 1135
Cluster node ' **NODE A** ' was removed from the active failover cluster
membership. The Cluster service on this node may have stopped.
This could also be due to the node having lost communication with other
active nodes in the failover cluster.
Run the Validate a Configuration wizard to check your network configuration.
If the condition persists, check for hardware or software errors related to
the network adapters on this node.
 Also check for failures in any other network components to which the node is
connected such as hubs, switches, or bridges.

There are three typical scenarios:

Scenario A
You're looking at all the Events and all the nodes in the cluster are indicating that NODE
A had lost communication.

It could be possible that when you're seeing the system logs on NODE A, it has events
for all the remaining nodes in the cluster.

Solution

This quite suggests that at the time of issue, either due to network congestion or
otherwise the communication to the NODE A was lost.

You should review and validate the Network configuration and communication issues.
Remember to look for issues pertaining to Node A.
Scenario B
You're looking at the Events on the nodes and let us say that your cluster is dispersed
across two sites. NODE A, NODE B, and NODE C at Site 1 and NODE D & NODE E at Site
2.

On Nodes A,B, and C, you see that the events that are logged are for connectivity to
Nodes D & E. Similarly, when you see the events on Nodes D & E, the events suggest
that we lost communication with A, B, and C.

Solution
If you see similar activity, it is indicative that there was a communication failure, over the
link that connects these sites. We would recommend that you review the connection
across the sites, if this is over a WAN connection, we would suggest that you verify with
your ISP about the connectivity.

Scenario C
You're looking at the Events on the nodes and you see that the names of the nodes
don't tally out with any particular pattern. Let us say that your cluster is dispersed across
two sites. NODE A, NODE B and NODE C at Site 1 and NODE D & NODE E at Site 2.

On Node A: You see events for Nodes B, D, E.

On Node B: You see events for Nodes C, D, E.
On Node C: You see events for Nodes A, B, E.
On Node D: You see events for Nodes A, C, E.
 On Node E: You see events for Nodes B, C, D.
Or any other combinations.

Solution
Such events are possible when the network channels between the nodes are choked and
the cluster communication messages are not reaching in a timely manner, making the
cluster to feel that the communication between the nodes is lost resulting in the
removal of nodes from the cluster membership.

Review Cluster Networks

We would recommend that you review your Cluster Networks by checking the following
three options one by one to continue this troubleshooting guide.

Check for Antivirus Exclusion

Exclude the following file system locations from virus scanning on a server that is
running Cluster Services:

The path of the FileShare Witness

The %Systemroot%\Cluster folder

Configure the real-time scanning component within your antivirus software to exclude
the following directories and files:

Default virtual machine configuration directory

(C:\ProgramData\Microsoft\Windows\Hyper-V)

Custom virtual machine configuration directories

Default virtual hard disk drive directory (C:\Users\Public\Documents\Hyper-

V\Virtual Hard Disks)

Custom virtual hard disk drive directories

 Custom replication data directories, if you're using Hyper-V Replica

Snapshot directories

mms.exe

７ Note

This file may have to be configured as a process exclusion within the antivirus
software.

Vmwp.exe

７ Note

This file may have to be configured as a process exclusion within the antivirus
software.

Additionally, when you use Live Migration together with Cluster Shared Volumes,
exclude the CSV path C:\Clusterstorage and all its subdirectories. If you're
troubleshooting failover issues or general problems with Cluster services and antivirus
software is installed, temporarily uninstall the antivirus software or check with the
manufacturer of the software to determine whether the antivirus software works with
Cluster services. Just disabling the antivirus software is insufficient in most cases. Even if
you disable the antivirus software, the filter driver is still loaded when you restart the
computer.

Check for network port configuration in firewall

The Cluster service controls server cluster operations and manages the cluster database.
A cluster is a collection of independent computers that act as a single computer.
Managers, programmers, and users see the cluster as a single system. The software
distributes data among the nodes of the cluster. If a node fails, other nodes provide the
services and data that were formerly provided by the missing node. When a node is
added or repaired, the cluster software migrates some data to that node.

System service name: ClusSvc

ﾉ Expand table
 Application Protocol Ports

Cluster Service UDP 3343

Cluster Service TCP 3343 (This port is required during a node join
operation.)

RPC TCP 135

Cluster Admin UDP 137

Kerberos UDP/TCP 464*

SMB TCP 445

Randomly allocated high UDP UDP Random port number between 1024 and 65535
ports** Random port number between 49152 and
65535***

７ Note

Additionally, for successful validation on Windows Failover Clusters on Windows

Server 2008 and above, allow inbound and outbound traffic for ICMP4, ICMP6.

For more information, see Creating a Windows Server 2012 Failover Cluster Fails
with Error 0xc000005e.
For more information about how to customize these ports, see the "References"
section in Service overview and network port requirements for Windows.

This is the range in Windows Server 2012, Windows 8, Windows Server 2008 R2,
Windows 7, Windows Server 2008, and Windows Vista.

Besides, run the following command to check for network port configuration in firewall.
For example: This command helps determine port 3343 available\open used for Failover
Cluster:

Console

netsh advfirewall firewall show rule name="Failover Clusters (UDP-In)"

verbose

Run the Cluster Validation report for any errors or

warnings
The cluster validation tool runs a suite of tests to verify that your hardware and settings
are compatible with failover clustering.

Follow these instructions:

1. Run the Cluster Validation report for any errors or warnings. For more information,
see Understanding Cluster Validation Tests: Network

2. Verify for warnings and errors for Networks. For more information, see
Understanding Cluster Validation Tests: Network.
Check the List Network Binding Order
This test lists the order in which networks are bound to the adapters on each node.

The Adapters and Bindings tab lists the connections in the order in which the
connections are accessed by network services. The order of these connections reflects
the order in which generic TCP/IP calls/packets are sent on to the wire.

Follow the below steps to change the binding order of network adapters:

1. Select Start, select Run, type ncpa.cpl, and then select OK. You can see the
available connections in the LAN and High-Speed Internet section of the Network
Connections window.
2. On the Advanced menu, select Advanced Settings, and then select the Adapters
and Bindings tab.
3. In the Connections area, select the connection that you want to move higher in
the list. Use the arrow buttons to move the connection. As a general rule, the card
that talks to the network (domain connectivity, routing to other networks, etc.
should be the first bound (top of the list) card).

Cluster nodes are multi-homed systems. Network priority affects DNS Client for
outbound network connectivity. Network adapters used for client communication
should be at the top in the binding order. Non-routed networks can be placed at lower
priority. In Windows Server 2012 and Windows Server 2012 R2, the Cluster Network
Driver (NETFT.SYS) adapter is automatically placed at the bottom in the binding order
list.

Check the Validate Network Communication

Latency on your network could also cause this to happen. The packets may not be lost
between the nodes, but they may not get to the nodes fast enough before the timeout
period expires.

This test validates that tested servers can communicate with acceptable latency on all
networks.

For example: Under Validate Network Communication, you may see the following
messages for network latency issues:

Output

Succeeded in pinging network interface node003.contoso.com IP Address

192.168.0.2 from network interface node004.contoso.com IP Address
192.168.0.3 with maximum delay 500 after 1 attempt(s).
Either address 10.0.0.96 is not reachable from 192.168.0.2 or **the ping
latency is greater than the maximum allowed 2000 ms**
This may be expected, since network interfaces node003.contoso.com -
Heartbeat Network and node004.contoso.com - Production Network are on
different cluster networks
Either address 192.168.0.2 is not reachable from 10.0.0.96 or **the ping
latency is greater than the maximum allowed 2000 ms**
This may be expected, since network interfaces node004.contoso.com -
Production Network and node003.contoso.com - Heartbeat Network for MSCS are
on different cluster networks

For multi-site cluster, you may increase the time-out values. For more information, see
Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster.

Check with ISP for any WAN connectivity issues.

Check if you encounter any of the following issues.

Network packets lost between nodes

1. Check Packet loss using Performance

If the packet is lost on the wire somewhere between the nodes, then the
heartbeats will fail. We can easily find out if this is a problem by using Performance
Monitor to look at the "Network Interface\Packets Received Discarded" counter.
Once you have added this counter, look at the Average, Minimum, and Maximum
numbers and if they are any value higher than zero, then the receive buffer needs
to be adjusted up for the adapter.
 If you're experiencing network packet lost on VMware virtualization platform, see
the "Cluster installed in the VMware virtualization platform" section.

2. Upgrade the NIC drivers

This issue can occurs due to outdated NIC drivers\Integration Components

(IC)\VmTools or faulty NIC adapters. If there are network packets lost between
nodes on Physical machines, please have your network adapter driver updates. Old
or out-of-date network card drivers and/or firmware. At times, a simple
misconfiguration of the network card or switch can also cause loss of heartbeats.

Cluster installed in the VMware virtualization platform

Verify VMware adapter issues in case of VMware environment.

This issue may occur if the packets are dropped during high traffic bursts. Ensure that
there is no traffic filtering occurring (for example, with a mail filter). After eliminating this
possibility, gradually increase the number of buffers in the guest operating system and
verify.

To reduce burst traffic drops, follow these steps:

1. Select Start, select Run, type devmgmt.msc and press Enter .

2. Expand Network adapters, right-click vmxnet3 and select Properties.
 3. Select the Advanced tab.
4. Select Small Rx Buffers and increase the value. The default value is 512 and the
maximum is 8192.
5. Select Rx Ring #1 Size and increase the value. The default value is 1024 and the
maximum is 4096.

Check the following articles to verify VMware adapter issues in case of VMware
environment:

Nodes being removed from Failover Cluster membership on VMware ESX?.

Large packet loss at the guest operating system level on the VMXNET3 vNIC in
ESXi

Notice any Network congestion

Network congestion can also cause network connectivity issues.

Verify your network is configured as per MS and vendor recommendations, see

Configuring Windows Failover Cluster Networks.

Check the network configuration

If it still doesn't work, please check if you have seen partitioned network in cluster GUI
or you have NIC teaming enabled on the heartbeat NIC.

If you see partitioned network in cluster GUI, see "Partitioned" Cluster Networks to
troubleshoot the issue.

If you have NIC teaming enabled on the heartbeat NIC, check Teaming software
functionality as per teaming vendor's recommendation.

Upgrade the NIC drivers

This issue can occurs due to outdated NIC drivers or faulty NIC adapters.

If there are network packets lost between nodes on Physical machines, have your
network adapter driver updates. Old or out-of-date network card drivers and/or
firmware.

At times, a simple misconfiguration of the network card or switch can also cause loss of
heartbeats.

Check the network configuration

If it still doesn't work, check whether you have seen partitioned network in cluster GUI or
you have NIC teaming enabled on the heartbeat NIC.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot Cluster service
startup issues in Windows Server 2003
Article • 12/26/2023

This article describes the basic troubleshooting steps you can use to diagnose Cluster
service startup issues with Windows Server 2003.

Applies to: Windows Server 2003

Original KB number: 266274

Summary
This article describes basic troubleshooting steps you can use to diagnose Cluster
service startup issues with Windows Server 2003. Although this isn't a comprehensive list
of all the issues that can cause the Cluster service not to start, it does address a majority
Windows Server 2003 startup issues. The contents of this article do NOT apply to
Windows Server 2008 or later.

More information
When the Cluster service initially starts, it attempts to join an existing cluster. For this to
occur, the Cluster service must be able to contact an existing cluster node. If the join
procedure doesn't succeed, the cluster continues to the form stage; the main
requirement of this stage is the ability to mount the quorum device.

These are the steps in the startup process in order:

Authenticate the Service account.

Load the local copy of the cluster database.
Use information in the local database to try to contact other nodes to begin the
join procedure. If a node is contacted and authentication is successful, the join
procedure is successful.
If no other node is available, the Cluster service uses the information in the local
database to mount the quorum device and updates the local copy of the database
by loading the latest checkpoint file and replaying the quorum log.

Troubleshooting Cluster service startup issues

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

1. Verify that the cluster node that is having problems is able to properly authenticate
the Service account. You can determine this by logging on to the computer with
the Cluster service account, or by checking the System event log for Cluster service
logon problem event messages.

2. Verify that the %SystemRoot%\Cluster folder contains a valid Clusdb file and that
the Cluster service attempted to start. Start Registry Editor (Regedt32.3xe) and
verify that the following registry key is valid and loaded:
HKEY_LOCAL_MACHINE\Cluster

The cluster hive should have a structure that is very similar to Cluster
Administrator. Make note of the network and quorum keys. If the database isn't
valid, you can copy and use the cluster database from a live node.

3. If the node isn't the first node in the cluster, check connectivity to other cluster
nodes across all available networks. Use the Ping.exe tool to verify TCP/IP
connectivity, and use Cluster Administrator to verify that the Cluster service can be
contacted. Use the TCP/IP addresses of the network adapters in the other nodes in
the Connect to dialog box in Cluster Administrator.

4. If it can't contact any other node, the service continues with the form phase. It
attempts to locate information about the quorum in the local cluster database, and
then tries to mount the disk. If the quorum disk can't be mounted, the service
doesn't start. If another node has successfully started and has ownership of the
quorum, the service doesn't start. This is usually caused by connectivity or
authentication issues. If this isn't the case, you can check the status of the quorum
device by starting the service with the -fixquorum switch, and attempt to bring the
quorum disk online, or change the quorum location for the service. Also, check the
System event log for disk errors. If the quorum disk successfully comes online, it's
likely that the quorum is corrupted.
 5. Check the attributes of the Cluster.log file to make sure that it's not read-only, and
make sure that no policy is in effect that prevents modification of the Cluster.log
file. If either of these conditions exist, the Cluster service can't start.

If these steps don't resolve the problem, you should take additional troubleshooting
steps. The cluster log file can be valuable in additional troubleshooting. By default,
cluster logging is enabled on Windows 2000-based computers that are running the
Cluster service.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster service fails to start
troubleshooting guidance
Article • 12/26/2023

Troubleshooting checklist

Check the ports that the cluster service uses

Make sure that the following ports are open to cluster traffic on any firewalls:

Port 135: Remote procedure call (RPC) endpoint mapper or distributed component
object model (DCOM).

Port 135: RPC endpoint mapper over user datagram protocol (UDP).

Port 3343: Cluster network driver.

Port 445: Server message block (SMB).

Port 139: NetBIOS session service.

Ports in the range of 5000 to 5099: If Event ID 1721 is logged when you connect to
a cluster as a cluster administrator, try opening the ports in this range (or other
ports) to RPC traffic. The ports support communication through RPC unless you
just type a period character (.).

This issue can occur because the cluster service uses at least 100 ports for RPC
communication. The number of ports available to the cluster service can become
too small when other services use some of the necessary ports. These services may
include Windows DNS service, Windows Internet Name service (WINS), or
Microsoft SQL Server service.

Ports in the range of 8011 to 8031: If firewalls separate the cluster nodes, the ports
in the range of 8011 to 8031 must be open to internode RPC traffic. Otherwise,
errors in the cluster log indicate that a sponsor node isn't available. These errors
occur because there aren't enough ports available for RPC communication
between a node that tries to join the cluster and a node that can sponsor that
node.

For more information about how to configure a network and network ports for a cluster,
see the following articles:
 Enable a network for cluster use

Service overview and network port requirements for Windows

After you change the port settings, try to bring the node online again before you
proceed.

Run the cluster validation tool

1. Open the Failover Cluster Manager snap-in (CluAdmin.msc).

2. Select Failover Cluster Manager in the top left column.

3. Select Validate Configuration.

4. Type the name of each node in the cluster and select Add after each one.

5. When all nodes have been added to the Selected servers: list, select Next.

6. Select Run all tests (recommended) > Next > Next.

7. Allow the test to finish. Once complete, select View Report.

8. Review any tests results that are labeled as Failed or Warning. This information
may help provide actionable steps to fix the issue.

9. To get a downloadable file, navigate to the C:\Windows\Cluster\Reports folder and

open the Validation Report (.MHT) file.

７ Note

In Windows Server 2016 and later versions, it's an .HTM file.

Check the security policies that might affect the cluster

node
In the Group Policy Object Editor, these policy objects are located in Computer
Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

７ Note

To access the local security policy settings, select Start, type local security policy,
and then select Local Security Policy.
 Make sure that the list of accounts includes the accounts that are responsible for
running the cluster node. For more information, see How to access this computer
from the network and Allow log on locally security policy setting.

Make sure that the list of accounts doesn't include local accounts. For more
information, see How to deny access to this computer from the network.

Make sure the list of accounts and groups doesn't include the "Everyone" group.
For more information, see Deny log on locally security policy setting.

After you change the policy settings, try to bring the node online again before you
proceed.

Temporarily disable firewalls

Disable the firewall between the node and the rest of the cluster, and then try to bring
the node online again. If the node still doesn't come online, the firewall can be the
cause.

） Important

Don't leave this change in place after you finish troubleshooting. After you use this
change for testing, return these settings to the original configuration.

Check the network hardware and software for issues

Check the System event log for hardware or software errors that are related to the
network adapters on this node.

Check the network adapter, cables, and network configuration for the networks
that connect the nodes.

If you're teaming the network adapters, make sure that the teaming configuration
is correct.

Check hubs, switches, or bridges in the networks that connect the nodes.

Review log files

To identify the source of the issue, review log information from multiple sources. For
example:
 In Event Viewer, navigate to Applications and Services
Logs\Microsoft\Windows\FailoverClustering-Client\Diagnostic, and review the
Cluster API Debug Tracing logs.

Generate a fresh cluster log for the node. On the server that is running the affected
node, open an elevated PowerShell prompt and run the following cmdlet:

Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime

To generate a more detailed trace, follow these steps:

1. At an elevated PowerShell prompt, run the following cmdlet to start the trace:

logman create trace "base_cluster" -ow -o c:\base_cluster.etl -p "Microsoft-

Windows-FailoverClustering-Client" 0xffffffffffffffff 0xff -nb 16 16 -bs 1024

-mode Circular -f bincirc -max 4096 -ets

2. Reproduce the issue.

3. To stop the trace, run the following cmdlet:

Logman stop base_cluster.etl -ets

4. To convert the trace, run the following cmdlet:

Netsh trace convert base_cluster.etl

5. To generate a cluster log from the data, run the following cmdlet:

Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime

For more information about tracing and other issues to look out for, see How to
Troubleshoot Create Cluster Failures .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 5120 Cluster Shared Volume
troubleshooting guidance
Article • 12/26/2023

Try our Virtual Agent - It can help you quickly identify and fix common Active

Directory replication issues

This guidance is designed to help troubleshoot status codes related to Event ID 5120
Cluster Shared Volume.

Troubleshooting checklist
Event ID 5120 indicates that there has been an interruption to communication between
a cluster node and a volume in Cluster Shared Volumes (CSV). This interruption may be
short enough that it isn't noticeable or long enough that it interferes with services and
applications using the volume. If the interruption persists, review other events in the
System or Application event logs for information about communication between the
node and the volume.

1. Verify that the Cluster Shared Volume can come online. To confirm that a Cluster
Shared Volume can come online:
a. To open the failover cluster snap-in, select Start > Administrative Tools >
Failover Cluster Manager. If the User Account Control dialog box appears,
confirm that the action it displays is what you want, and then select Yes.
b. In the Failover Cluster Manager snap-in, check whether the cluster you want to
manage is displayed. If it isn't displayed, then in the console tree, right-click
Failover Cluster Manager, select Manage a Cluster, and then select or specify
the cluster you want.
c. If the console tree is collapsed, expand the tree under the cluster you want to
manage, and then select Cluster Shared Volumes.
d. In the center pane, expand the listing for the volume you're verifying and view
the status of the volume.
e. If a volume is offline, bring it online by right-clicking the volume and then
selecting Bring this resource online.

2. Use a Windows PowerShell cmdlet to check the status of a resource in a failover

cluster:
 a. On a node in the cluster, select Start, point to Administrative Tools, and then
select Windows PowerShell Modules. If the User Account Control dialog box
appears, confirm that the action it displays is what you want, and then select
Yes. Run the following cmdlet:

PowerShell

Get-ClusterSharedVolume

b. If you run the preceding cmdlet without specifying a resource name, the status
is displayed for all Cluster Shared Volumes in the cluster.

3. If you see a few random Events ID 5120 with an error of

STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR or error code c0130021, they can be
safely ignored. We recognize it isn't optimal as they create false positive alarms
and trigger alerts in management software.

4. If you see Event ID 5120 is logged with error codes other than
STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR, it's a sign of a problem. Make sure to
review the error code in the description of each Event ID 5120 logged. Be careful
not to dismiss the event because of a single event with
STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR. If you see other errors logged, there
are fixes available that need to be applied.

Common issues and solutions

If you see Event ID 5120, the Description field of the event includes a status message
that indicates the cause of the event. The following list consists of 20 status messages:

Status code:
STATUS_BAD_IMPERSONATION_LEVEL(0xC00000A5)
Certain operations, such as renaming that you perform on files or folders on a Cluster
Shared Volume, may fail with the error "STATUS_BAD_IMPERSONATION_LEVEL
(0xC00000A5)". This issue occurs when you perform the operation on a CSV owner node
by using the context of a process that doesn't have administrator permissions.

To work around this issue, do one of the following operations:

1. Perform the operation by using the context of a process that has administrator
permissions.
2. Perform the operation by using a node that doesn't have CSV ownership.
Microsoft is working on a resolution and will provide an update in an upcoming release,
as described in February 12, 2019—KB4487020 (OS Build 15063.1631) .

Status code: STATUS_BAD_NETWORK_NAME(c00000cc)

1. Check your system event log for events that indicate network connectivity
problems, host bus adapter (HBA) problems, or disk problems.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_BAD_NETWORK_PATH(c00000be)

Check the storage configuration and multipath I/O (MPIO) settings. You can enable
MPIO path verification on all cluster nodes by using the PowerShell cmdlet Set-
MPIOSetting . Follow these steps on each cluster node:

1. Open a PowerShell Command Prompt window.

2. Run the following cmdlets:

PowerShell

Set-MPIOSetting -NewPathVerificationState Enabled

Set-MPIOSetting -NewPathVerificationPeriod <integer>

７ Note

In this cmdlet, <integer> is the length of time for the server to verify every
path (in seconds). The default is 30 seconds.

Status code:
STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR(c0130021)
Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

In particular, make sure that the following update is installed on all Windows Server
2012 R2 and earlier servers.
Update is available that improves the resiliency of the cloud service provider in
Windows: December 2013 (KB2878635)

７ Note

In Windows Server 2016 and later versions, the name of this status code is
STATUS_CLUSTER_CSV_NO_SNAPSHOTS.

Status code:
STATUS_CONNECTION_DISCONNECTED(c000020c)
Communication between a cluster node and a CSV has been interrupted. This
interruption may be short enough that it isn't noticeable or long enough that it
interferes with services and applications that use the volume. If the interruption persists,
review other events in the System or Application event logs for information about
communication between the node and the volume.

In addition, confirm that the CSV can come online by using the following steps:

７ Note

To perform the following procedures, the account you use has to be a domain
account and has to belong to the local Administrators group on each clustered
server, or it has to have the equivalent authority.

1. Select Start > Administrative tools > Failover Cluster Manager.

2. In the Failover Cluster Manager snap-in, check whether the cluster you want to
manage is displayed. If it isn't displayed, then in the console tree, right-click
Failover Cluster Manager, select Manage a Cluster, and then select or specify the
cluster you want.
3. In the center pane, expand the listing for the volume you're verifying. View the
status of the volume.
4. If a volume is offline, bring it online by right-clicking the volume and then selecting
Bring this resource online.

To use a PowerShell cmdlet to check the status of a resource in a failover cluster, open a
PowerShell Command Prompt window on a node in the cluster, and run Get-
ClusterSharedVolume .

７ Note
 If you run the preceding cmdlet without specifying a resource name, the status is
displayed for all CSVs in the cluster.

For more information, see Event ID 5120 — Cluster Shared Volume Functionality.

Status code: STATUS_CONNECTION_RESET(c000020d)

1. Check your system event log for events that indicate network connectivity
problems, host bus adapter (HBA) problems, or disk problems.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.
3. Check the exclusions that are configured for your antivirus solution.

Status code: STATUS_DEVICE_BUSY(80000011)

1. Check the status of the storage resources. This message might indicate that the
persistent reservation of the volume has been lost.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code:
STATUS_DEVICE_NOT_CONNECTED(c000009d)
This status code indicates that connectivity between the cluster nodes and the storage
has been lost.

1. Check your system event log for events that indicate network connectivity
problems, host bus adapter (HBA) problems, or disk problems.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_FILE_CLOSED(c0000128)

1. Check network connectivity. Check the event logs for other events that are related
to connectivity, such as Event ID 1135. Additionally, check the status of workloads
that generate heavy network traffic (such as backups).
 2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_FILE_NOT_AVAILABLE(c0000467)

1. Check the health status of Smart Array. Make sure that related drivers and
firmware are up to date.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code:
STATUS_INSUFFICIENT_RESOURCES(c000009a)
Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_IO_TIMEOUT(c00000b5)

This status code indicates that a redirected file system IO operation took longer than the
time allowed. The timeout is two minutes for synchronous operations and four minutes
for asynchronous operations.

The cause of the timeout varies. It might indicate a software, configuration, or hardware
problem.

1. Check your system event log for events that indicate network connectivity
problems, host bus adapter (HBA) problems, or disk problems.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date. In particular, make sure that October 18, 2018—KB4462928
(OS Build 14393.2580) is installed. This update addresses an issue that occurs
when restarting a node after draining the node. Event ID 5120 appears in the log
with a "STATUS_IO_TIMEOUT c00000b5" message. This may slow or stop input and
output (I/O) to the VMs, and sometimes the nodes may drop out of cluster
membership.
Status code:
STATUS_MEDIA_WRITE_PROTECTED(c00000a2)
This status code indicates that there's a connectivity issue. Make sure that the Server
Message Block (SMB) protocol is enabled.

Status code:
STATUS_NETWORK_UNREACHABLE(c000023c)
This status code indicates that either there is a network fault between the node and the
CSV or Disk Control Manager (DCM) has mapped an incorrect path to the volume.

Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_NO_MEDIA_IN_DEVICE(c0000013)

This status code indicates a problem in the storage system. Check the health status of
the storage system.

Status code: STATUS_NO_SUCH_DEVICE(c000000e)

This code indicates that connectivity between a node and the CSV has been lost.

1. Check the network connectivity and the cluster exclusion in the firewall.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code:
STATUS_UNEXPECTED_NETWORK_ERROR(c00000c4)
Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_UNSUCCESSFUL(c0000001)

1. Check the connectivity between the nodes and the CSV.
 2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Status code: STATUS_USER_SESSION_DELETED(c0000203)

Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

In particular, make sure that October 18, 2018—KB4462928 (OS Build 14393.2580) is
installed. This update addresses a problem that generates this status code in the case of
multiple Windows Server 2016 Hyper-V clusters.

Status code: STATUS_VOLUME_DISMOUNTED(c000026e)

1. Check your system event log for events that indicate storage problems, network
connectivity problems, host bus adapter (HBA) problems, or disk problems.
2. Make sure that the affected system has the latest versions of network and storage
drivers and firmware installed. Additionally, make sure that Microsoft updates and
hotfixes are up to date.

Data collection
Before contacting Microsoft Support, you can gather information about your issue.

Refer the prerequisites for the toolset to run properly.

Gather key information before you contact Microsoft

Support
Use the Windows live dump feature to save a snapshot of kernel memory on the
affected computer. To do this, follow these steps:

1. Check the live dump folder (C:\Windows\LiveKernelReports\) for previous live dump
files.

2. Make sure that the live dump feature has been enabled. For more information on
enabling the feature, see Troubleshooting Hangs Using Live Dump .

3. Download TSS and unzip it in the C:\tss folder.

 4. Open an elevated version of PowerShell and change the directory to the C:\tss
folder.

5. Run the SDP tool to collect the logs from the source and destination nodes.

6. Unzip the file and run the following cmdlet on both nodes:

PowerShell

TSS.ps1 -SDP Cluster -SkipSDPList skipHang,skipBPA,skipSDDC

7. Collect all logs. Zip and attach the live dump files to your support request.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Unable to get Computer Object using
GUID" error message when a network
name request fails in a Windows Server
failover cluster
Article • 12/26/2023

This article provides a solution to fix an issue where a Client Access Point (CAP) in a
failover cluster does not come online as expected.

Applies to: Windows Server 2012 R2

Original KB number: 2008654

Symptoms
A CAP in a Windows Server failover cluster does not come online as expected. In this
situation, the following Error event is logged:

Log Name: System

Source: Microsoft-Windows-FailoverClustering
Event ID: 1207
Task Category: Network Name Resource
Level: Error
Description:
Cluster network name resource '<Resource Name>' cannot be brought online. The
computer object associated with the resource could not be updated in domain
'<domain FQDN>' for the following reason:
Unable to get Computer Object using GUID.
The text for the associated error code is: The specified domain either does not exist
or could not be contacted.
The cluster identity '<Cluster CNO or Node>$' may lack permissions required to
update the object. Work with your domain administrator to ensure that the cluster
identity can update computer objects in the domain.

Additionally, when you view the cluster log, you see the following error message:

Search for existing computer account failed. status 8007054B

 ７ Note

Error code 0x8007054b = "ERROR_NO_SUCH_DOMAIN // The specified domain

either does not exist or could not be contacted."

Cause
During a cluster operation, maintenance tasks may be required on computer objects in
Active Directory. For example passwords may have to be created, deleted, enabled,
disabled, and rotated, and SPNs may have to be updated. When servers are located in
perimeter networks (also known as DMZs, demilitarized zones, and screened subnets)
that have access only to Read-Only Domain Controllers (RODC), you can work around
some of these tasks by manually creating and deleting computer objects. Other
operations are forwarded by RODCs to a writeable domain controller elsewhere in the
domain. However, there are some modification operations that the cluster performs in
which a writeable domain controller is explicitly requested.

Resolution
To resolve this problem, provide the failover cluster access to a writeable domain
controller.

To learn more about the Active Directory requirements for failover clustering, visit the
following Microsoft Web site:

Failover Cluster Step-by-Step Guide: Configuring Accounts in Active Directory

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster validation test on Active
Directory configuration fails in a multi-
site cluster scenario
Article • 12/26/2023

This article describes Active Directory configuration validation may fail in a multi-site
cluster scenario.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4025260

Symptoms
When you run a cluster validation test for your multi-site failover cluster, the test may
fail at validating the Active Directory configuration with one of the following error
messages:

Connectivity to a writable domain controller from node Computer2.contoso.com

could not be determined because of this error: Could not get domain controller
name from machine Computer2.
The site name of node Computer2.contoso.com could not be determined because of
this error: Could not get domain controller name from machine
Computer2.contoso.com .

Regardless of the errors, the cluster nodes can successfully communicate with some
domain controller and form a failover cluster.

More information
When you start a cluster validation test on a node, the node selects a domain controller
to be used for the test. During the Active Directory configuration validation, all
computers that are selected as part of the validation are pointed to use this domain
controller. In a multi-site cluster scenario, the network communications may be
designed in way where computers are only allowed to communicate with domain
controllers that are in their local site. Therefore, these computers are prevented from
communications with remote domain controllers. In this scenario, computers in other
sites are not able to communicate with the selected domain controller, which leads to
the failure of the cluster validation test.
If the computers can communicate to a domain controller in the domain, and the
domain controllers are successfully replicating, then the functionality of your failover
cluster is not impacted.

In a multi-site cluster scenario, you can safely ignore the failed validation. Meanwhile,
your failover cluster is still supported by Microsoft Technical Support.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error: "An item with the same key has
already been added"
Article • 12/26/2023

This article helps to fix the error "An item with the same key has already been added".

Applies to: Windows Server 2012 R2

Original KB number: 2002405

Symptoms
When you run the Validate a Configuration wizard for Windows Server 2008 Failover
Cluster, you may receive the following error:
"An error occurred while executing the test. There was an error verifying the firewall
configuration. An item with the same key has already been added."

Cause
This error is reported if any network adapters have the same Globally Unique Identifier
(GUID) across any nodes in the cluster. This can be determined by running the following
WMI query on each node in the cluster and comparing the results -

For example, from inside PowerShell, run: - Get-WMIObject Win32_NetworkAdapter | fl

Name, Guid

A sample output for an adapter would look like this -

Name : Intel(R) PRO/1000 MT Desktop Adapter

GUID: {7488FB48-851A-40B6-AB47-1EA7408C762F}

７ Note

This scenario typically occurs if an operating system image is being used to deploy
cluster nodes and that image was not correctly prepared for deployment by
running sysprep.

Resolution
To resolve this issue the network interface GUID's on each of the nodes must be unique.
One node can be left unchanged. But the following process must be performed against
the remaining nodes.

1. Download and then install the latest version of the network adapter driver on the
computer.

2. Click Start, click Run, type regedit, and then click OK.

3. Locate and then delete the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\Config

4. If your server is a domain controller, go to step 5. If your server is not a domain

controller, delete the following registry subkeys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Adapters\ {GUID}
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\I
nterfaces\{GUID}

5. Click Start, click Run, type sysdm.cpl, and then click OK.

6. In the Systems Properties dialog box, click the Hardware tab, and then click
Device Manager.

7. In Device Manager, expand Network adapters, right-click the network adapter that
you want, and then click Uninstall.

8. Restart the computer.

To verify that the network interface GUID was updated, use one of the following
methods.
Method 1: Perform the following:
Get-WMIObject Win32_NetworkAdapter | fl Name, Guid
Method 2: Run Failover Cluster's Validate a Configuration wizard, and make sure that the
error does not occur.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The validation fails when you run a
cluster validation wizard for a Windows
Server 2008 cluster
Article • 12/26/2023

This article provides a resolution for a problem in which a duplicate address error occurs
when you validate a Windows Server 2008 failover cluster.

） Important

This article contains information about how to modify the registry. Make sure that
you back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back
up, restore, and modify the registry, click the following article number to view the
article in the Microsoft Knowledge Base: 322756 How to back up and restore the
registry in Windows

Applies to: Windows Server 2012 R2

Original KB number: 969256

Symptoms
When you run a cluster validation wizard for a Windows Server 2008 cluster, the
validation fails. Additionally, you may receive an error that resembles the following error
message:

Verifying that there are no duplicate IP addresses between any pair of nodes.

Found duplicate physical address 02-10-18-39-6D-38 on node

servername.domainname.com adapter Local Area Connection 19 and node
server2name.domainname.com adapter Local Area Connection 19.

Found duplicate IP address fe80::100:7f:fffe%14 on node servername.domainname.com

adapter Local Area Connection 11 and node server2name.domainname.com adapter
Local Area Connection 11."

Cause
This problem occurs when only one of the following conditions is true:

The Teredo transition technology is enabled on a Windows Server 2008 cluster

node. Teredo allows IPv6 communications to pass through IPv4 NATs and IPv4
servers. However, Teredo gives the same IPv6 address to its network interfaces.
Failover clustering flags this as an error because it requires unique IP addresses.
The referenced servers are built from the same image and automatically create the
Cluster NetFT adapter on each node with an identical MAC address. Failover
clustering flags this as an error because it requires unique physical addresses.

Resolution
There are two possible solutions, depending on the combination of error messages that
you receive.

Issue 1
If the error message doesn't include a reference to a "duplicate physical address,"
Teredo is most likely the cause of the problem. To resolve this problem, disable Teredo
by using one of the following two methods.

７ Note

The failover cluster validation tests have been changed in Windows Server 2008
SP2 and later and Windows Server 2008 R2 so that the Teredo addresses will not
cause the test to issue a failure or a warning.

Method 1: Turn off Teredo by using a Netsh command

1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.

７ Note

If the User Account Control dialog box appears, confirm that the action that
the dialog box displays is what you want, and then click Continue.

2. At the command prompt, type the following lines (press ENTER after each line):

Console
 netsh
interface
teredo
set state disabled

3. Close the command prompt.

Method 2: Turn off Teredo by specifying a registry setting in

Windows Server 2008

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base: 322756 How to back up and restore the registry in Windows

1. For best results, close all programs on the computer on which you're changing the
registry setting.

2. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.

７ Note

If the User Account Control dialog box appears, confirm that the action that
the dialog box displays is what you want, and then click Continue.

3. Type regedit at the command line.

4. Locate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6

5. Right-click Parameters, click New, click DWORD, and then type the name
DisabledComponents for the new value. Make sure that you type the name exactly
as shown, including capitalization. Then, click Enter.

6. Double-click DisabledComponents.
 7. In the Edit DWORD Value dialog box, click Hexadecimal under the Base field, and
then type 8 in the Value data field.

8. Click OK.

9. Restart the computer.

７ Note

You can also disable Teredo by using Device Manager. However, this only
disables the Teredo adapter so that the system does not show the adapter
anymore. This does not disable the underlying logic for Teredo. This could
cause issues later. Therefore, we recommend that you disable Teredo through
the command line or through the registry entry.

Issue 2
If the error message includes a reference to a "duplicate physical address," the problem
most likely occurs because the referenced servers are based from the same image. To
resolve this issue, remove and then reinstall the Failover Cluster feature. To do this,
follow these steps:

1. Remove the Failover Cluster feature. To do this, follow these steps:

a. Open Server Manager.
b. In the navigation pane, click Features, and then click Remove Features.
c. Click to clear the Failover Clustering check box.
d. Review the warning dialog box to make sure that you're prepared to continue.
Click Yes, and then click Next.
e. Verify that the options that you want are being removed, click Remove, and
then click Close.

2. Reinstall the Failover Cluster feature. To do this, follow these steps:

a. Open Server Manager.
b. In the navigation pane, click Features, and then click Add Features.
c. Click to select the Failover Clustering check box, and then click Next.
d. Verify that the options that you want are being added, click Install, and then
Close.

７ Note
 The Sysprep command is not supported when an image is captured after you add
the Failover Clustering feature. If you install the Failover Clustering feature, and
then you run the sysprep command on the image, the virtual adapter for all the
nodes will have the same MAC address. The virtual network adapter (NetFT) takes a
MAC address based from one of the addresses of the physical network interface
cards (NICs) when the Failover Clustering feature is installed.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section of this article.

For more information about the Teredo transition technology, visit the following Web
sites:

Internet Protocol Version 6, Teredo, and Related Technologies in Windows Vista

For more information about how to run the cluster validation wizard for a failover cluster
in Windows Server 2008, visit the following Web site:

Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster validation fails the SCSI-3
Persistent Reservation test in Windows
Server
Article • 12/26/2023

This article provides a solution to an issue where the SCSI-3 Persistent Reservation test
fails when you run the Failover Cluster Validation report.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2822335

Symptoms
When running the Failover Cluster Validation report on an existing cluster configured in
Windows Server 2008 R2 Service Pack 1, the SCSI-3 Persistent Reservation test may fail
with the following error:

Failed to access cluster disk 0 from node <node name> status 31

Cluster Disk 0 does not support Persistent Reservations. Some storage devices
require specific firmware versions or settings to function properly with failover
clusters. Please contact your storage administrator or storage vendor to check the
configuration of the storage to allow it to function properly with failover clusters.

Cause
Some Storage devices have a defined limit in the amount of SCSI-3 registrations or
reservations that it can handle. The problem comes in where you have exceeded that
limit.

Resolution
Work with the storage vendor to see if there is a firmware update that can raise this
limit. If a firmware update is not available, it may require that you move some of your
storage to different arrays.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Storage tests on a failover cluster might
not discover all shared LUNs
Article • 03/22/2024

This article discusses how to resolve an issue in which the Validate a Configuration
Wizard doesn't discover all of the shared LUNs that a cluster uses.

Applies to: Windows Server, all versions

Original KB number: 2914974

Symptoms
Consider the following scenario:

You have a Windows Server multi-site failover cluster that has nodes in site A and
site B.
A multi-site storage area network (SAN) uses storage arrays in each site for site-to-
site mirroring.
You use the Validate a Configuration Wizard to run a set of validation tests on the
failover cluster.

In this scenario, storage tests might not detect all logical unit numbers (LUNs) as shared
LUNs.

Cause
The storage validation tests that the wizard runs select only shared LUNs. For a shared
LUN, the disk signatures, device identification number (page 0x83), and storage array
serial number are the same on all cluster nodes. When you use site-to-site mirroring, a
LUN in one site (site A) has a mirrored LUN in another site (site B). These LUNs have the
same disk signatures and device identification numbers (page 0x83). However, the
storage array serial numbers are different. Because of the difference, the wizard doesn't
recognize that the LUNs are shared.

Resolution
To resolve the issue, run all the cluster validation tests before you configure the site-to-
site mirroring.
 ７ Note

If you have to run the validation tests after you configure mirroring, LUNs that you
don't select for the storage validation tests are supported by Microsoft and the
storage vendor as valid shared LUNs.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Validation fails when you run the Disk
Failover test on a Windows Server 2012
failover cluster
Article • 12/26/2023

This article provides a solution to an issue where validation fails when you run the Disk
Failover test on a Windows Server 2012 failover cluster.

Applies to: Windows Server 2012 R2

Original KB number: 3020013

Symptoms
When you run the Cluster Validation report on a Windows Server 2012 failover cluster,
the Validate Disk Failover test may fail, and you may receive errors that resemble the
following:

Node 2012N2.burragevmlab.com holds the SCSI PR on Test Disk 1 but has failed in its
attempt to bring the disk online. The device is not ready.

Cause
This issue occurs because the Automount feature is turned off. To determine whether this
option is turned off, follow these steps:

1. Open an administrative command prompt, and then run the following command:
Diskpart

2. At the Diskpart prompt, run the following command: Automount

The results will tell you whether Automount is enabled or disabled.

Resolution
To resolve this issue, enable Automount . To do this, run the following command from an
administrative command prompt: Mountvol.exe /E

No restart is required for this to take effect.

 ７ Note

Make sure that you verify this information on all nodes that you will be adding to
the cluster.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You do not see the cluster disk in
explorer or diskmgmt on Failover in a
Windows 2008 or Windows 2008 R2
Cluster
Article • 12/26/2023

This article provides a resolution to an issue where cluster disk cannot be found in
explorer or diskmgmt on Failover.

Applies to: Windows Server 2012 R2

Original KB number: 2517921

Symptoms
The file share resource failover from Node A to Node B and the file share disk (example
N:) doesn't show up in the explorer or disk management console. We see the following
events as the drive letter got swapped during failover and the file share resource won't
come online even if the dependencies of the files share (that is disk and IP) were online.

Log Name: System

Source: Microsoft-Windows-FailoverClustering
Event ID: 1588
Task Category: File Server Resource
Level: Error
User: SYSTEM
Description:
Cluster file server resource 'AdminData' cannot be brought online. The resource
failed to create file share 'NAMEOF FILESHARE RESOURCE$' associated with network
name 'NAMEOF FILESHARE RESOURCE'. The error code was '3'. Verify that the
folders exist and are accessible. Additionally, confirm the state of the Server service
on this cluster node using Server Manager and look for other related events on this
cluster node. It may be necessary to restart the network name resource 'NAMEOF
FILESHARE RESOURCE' in this clustered service or application.

We also see:

Log Name: System

Source: Microsoft-Windows-Kernel-Tm
 Event ID: 1
Task Category: None
Level: Information
Keywords: None
User: SYSTEM
Description:
The Transaction (UOW=%1, Description='%3') was unable to be committed, and
instead rolled back; it was due to an error message returned by CLFS while
attempting to write a Prepare or Commit record for the Transaction. The CLFS error
returned was: %4.

Log Name: System

Source: Microsoft-Windows-UserPnp
Event ID: 20010
Task Category: (7010)
Level: Information
User: SYSTEM
Computer:
Description:
One or more of the Plug and Play service's subsystems has changed state.
PlugPlay install subsystem enabled: 'true'
PlugPlay caching subsystem enabled: 'true'

Cause
This event happens if you have a network drive mapped on the Node B with the same
drive letter (that is N:) which was assigned to the cluster disk on the Active node.

It happens if you have the Mapped network drive assigned with the same drive letter,
which was held by cluster disk resource on the active node or on the node before
failover. If there is the local hard disk with same drive letter, then this issue doesn't
happen as the part manager assign the same drive letter by swapping it.

Resolution
You will be able to see the disk with drive letter N: on Node B in explorer and disk
management, once you disconnect the mapped network drive. Even if you don't
disconnect the network drive the drive letter would be still accessible with share and
also viewable with same drive letter N: under failover cluster MMC.
References
Failover Cluster Step-by-Step Guide: Configuring a Two-Node File Server Failover Cluster

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cluster Validation fails "Validate Cluster
Network Configuration" Test with Error
80070005
Article • 12/26/2023

This article provides a solution to the error 80070005 that occurs when failover cluster
validate fails.

Applies to: Windows Server 2012 R2

Original KB number: 2012835

Summary
On a Windows Server 2008 or Windows Server 2008 R2 Failover Cluster, Validate may fail
with either of the following errors:

Validate Cluster Network Configuration

Validate the cluster networks that would be created for these servers.
An error occurred while executing the test.
There was an error initializing the network tests.
There was an error creating the server-side agent (CPrepSrv).
Creating an instance of the COM component with CLSID {E1568352-586D-43E4-
933F-8E6DC4DE317A} from the IClassFactory failed due to the following error:
80070005.

OR

Validate IP Configuration
Validate that IP addresses are unique and subnets configured correctly.
An error occurred while executing the test.
There was an error initializing the network tests.
There was an error creating the server-side agent (CPrepSrv).
Creating an instance of the COM component with CLSID {E1568352-586D-43E4-
933F-8E6DC4DE317A} from the IClassFactory failed due to the following error:
80070005.

Cause
This can be caused by deploying a cloned image of the operating system that was not
properly prepared using the System Preparation Tool (Sysprep).

Resolution
If the base image was not generated by using Sysprep with the /Generalize option, you
must rebuild the base image, and then reinstall Windows Server.

More information
It is not supported to SysPrep servers that have the Failover Clustering feature installed.
The Failover Cluster feature must be installed after the system has been SysPreped and
cloned.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Creating a Failover Cluster Fails with
Error 0xc000005e
Article • 12/26/2023

This article provides a solution to fix the error 0xc000005e that occurs when you create a
failover cluster with Windows Server 2012.

Applies to: Windows Server 2012 R2

Original KB number: 2830510

Symptoms
When attempting to run the Create Cluster Wizard to create a Failover Cluster with
Windows Server 2012, the operation may fail. Additionally, you may receive the
following error:

An error occurred while creating the cluster. An error occurred creating cluster
'MyCluster'. Unknown error (0xc000005e)

Note: An error 0xc000005e means STATUS_NO_LOGON_SERVER

Upon investigating the CreateCluster.mht that is located under

C:\Windows\Cluster\Reports directory, you may notice the operation failure happens
during the following:

Verifying computer object 'MyCluster' in the domain. Unable to successfully cleanup.

Cause
This problem can occur if TCP or UDP Port 464 is blocked.

Resolution
To resolve this problem, ensure that port 464 for both TCP and UDP is open on all
firewall network devices between the nodes in the cluster and the domain controller.

The error STATUS_NO_LOGON_SERVER is caused because the nodes in the cluster were
unable to communicate with a domain controller to set the password when attempting
to configure the computer objects in Active Directory. Port 464 is enabled by default in
Windows Firewall on Windows Server 2012.
More information
For more information on the Active Directory service port requirements, see the
following article: Active Directory and Active Directory Domain Services Port
Requirements

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive an error message, and event
ID 1289 is logged when you try to create
a cluster
Article • 12/26/2023

This article helps to fix a problem that occurs when you try to create a cluster on a set of
computers that have the Failover Clustering feature installed.

Applies to: Windows Server 2012 R2

Original KB number: 973838

Symptoms
Consider the following scenario:

You install the Failover Clustering feature on a set of Windows Server 2008-based
computers.
You try to create a failover cluster on these computers by using the Failover Cluster
Management Microsoft Management Console (MMC) snap-in or by using the
Cluster.exe tool.

In this scenario, the cluster creation fails, and you receive the following error message:

An error occurred while creating the cluster. An error occurred creating cluster
'clustername'. The service has not been started.

Additionally, the following event is logged in the System log:

Cause
To eliminate single points of failure that are related to network communication, failover
clustering uses the Microsoft Failover Cluster Virtual Miniport driver. Additionally, this
driver generates a physical address during startup. However, any of the following
situations would make cluster creation fail:

No physical adapter has a universally administered MAC address.

Cluster configuration is not fully cleaned up after a sequence of repeated
installation and removal of the Failover Clustering feature.
Resolution
To resolve this problem, follow these steps to reinstall the Failover Clustering feature:

1. On each computer that you want to make a cluster node, use the Server Manager
console to remove the Failover Clustering feature.
2. Restart each computer from which you have removed the Failover Clustering
feature.
3. Add the Failover Clustering feature on all these computers again.
4. Run cluster validation against these computers.
5. Try creating a cluster.

If the problem is not resolved after you reinstall the Failover Clustering feature, follow
these steps, and then run the reinstallation again.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

1. Open Registry Editor.

2. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{4D36E972-E325-
11CE-BFC1-08002BE10318}

3. Under this subkey, find the subkey that holds a DriverDesc string value entry
whose value is "Microsoft Failover Cluster Virtual Adapter."

4. Under the subkey that you found in step 3, add the following string value registry
entry:
Name: DatalinkAddress
Value data: 02-AA-BB-CC-DD-01

5. Restart the computer.

 6. Repeat step 1 through step 5 on other computers on which you experience this
problem. When you do this on other computers, replace the value data of the
registry with different values in order to set a unique value for each node. For
example, set the value on the second node to 02-AA-BB-CC-DD-02, and set value
on the third node to 02-AA-BB-CC-DD-03. If you notice this behavior on distinct
clusters, make sure that you use an address for each node that is unique across all
clusters.

7. Try creating the cluster again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x80090327 when adding a node to a cluster
Article • 12/26/2023

This article provides a solution to fix error 0x80090327 that occurs when you add a node to a cluster.

Applies to: Windows Server

Original KB number: 5015645

You fail to add a node to a cluster. When checking the cluster logs, you find that a sponsor node rejects the
connection with error 0x80090327.

Example cluster log for the joining node:

Output

113533 [Verbose] 00001ef8.000010d4::<Date Time> WARN cxl::ConnectWorker::operator ():

HrError(0x000004ca)' because of '[SV] Schannel Authentication or Authorization Failed'

Example cluster logs for the sponsor node:

Output

22064 [Verbose] 000016ec.00000e7c::<Date Time> ERR

mscs_security::SchannelSecurityContext::AuthenticateAndAuthorize: HrError(0x80090327)' because of
'[Schannel] Server: missing context attributes, requested: 34836, received: 2076'
22065 [Verbose] 000016ec.00000e7c::<Date Time> WARN mscs::ListenerWorker::operator ():
HrError(0x80090327)' because of '[SV] Schannel Authentication or Authorization Failed'

Remove Transport Layer Security (TLS) 1.3 registry keys

） Important

This section, method, or task contains steps that tell you how to modify the registry. However, serious
problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these
steps carefully. For protection, back up the registry before you modify it so that you can restore it if a
problem occurs. For more information about how to back up and restore the registry, see How to back up
and restore the registry in Windows .

This issue occurs because TLS 1.3 is enabled on the sponsor node. To resolve this issue, remove the following
registry keys:

ﾉ Expand table

Name Data Path

DisabledByDefault 00000000 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS

1.3\Client

Enabled 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS

1.3\Client

DisabledByDefault 00000000 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS

 Name Data Path

1.3\Server

Enabled 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS

1.3\Server

７ Note

These keys are only supported in Windows Server 2022. For more information, see Protocols in TLS/SSL
(Schannel SSP).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The implications of using the
/forcequorum switch to start the Cluster
service in Windows Server 2008
Article • 12/26/2023

This article discusses the implications of starting the Cluster service by using the
/forcequorum switch

Applies to: Windows Server 2012 R2

Original KB number: 947713

Beta Information
This article discusses a beta release of a Microsoft product. The information in this
article is provided as-is and is subject to change without notice.

No formal product support is available from Microsoft for this beta product. For
information about how to obtain support for a beta release, see the documentation that
is included with the beta product files, or check the Web location where you
downloaded the release.

Introduction
In Windows Server 2003, server clusters that are configured to use a majority node set
(MNS) quorum model can force the Cluster service to start when less than the required
minimum number of cluster nodes are participating in the cluster. The following formula
is used to determine the minimum number of cluster nodes that are required:
(<Total configured cluster nodes>/2) + 1

For example, a 4-node MNS cluster requires a minimum of three nodes to be

considered functional ((4/2) + 1 = 3).

To start the Cluster service by using the MNS quorum model method, use the
ForceQuorum registry key, or use a startup parameter, such as the /forcequorum switch.

７ Note
 The ForceQuorum registry key is located under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters

There are special procedures that are required to correctly recover after you use the
/forcequorum switch. This article discusses the implications of using the /forcequorum
switch to start the Cluster service in Windows Server 2008. In Windows Server 2008-
based failover clusters, starting the Cluster service together with a /forcequorum switch
has more implications than it did in earlier operating systems.

More information
In Windows Server 2008-based failover clusters, the cluster configuration information is
tracked across all nodes in the cluster and on a witness disk, if one is configured. A
Paxos tagging process is used to guarantee consistency of the cluster configuration
across all nodes and on the witness disk. The Paxos algorithm is used for guaranteeing
consistency across distributed systems. The algorithm is used by the Cluster service to
guarantee data consistency when updates to the cluster configuration are propagated
across all nodes in the cluster.

In Windows Server 2008-based failover clusters, the Paxos tag consists of three
numbers. Each number is separated by a colon. For example, a tag may resemble the
following:
3:3:276
These numbers represent the NextEpoch number, the LastUpdateEpoch number, and
the sequence number. Ideally, the Paxos tag should be the same across all replicas of
the cluster configuration. The Epoch numbers are changed every time that the cluster is
formed. The sequence number is changed every time that an update is made to the
cluster configuration. The synchronization process in a cluster sends out a proposal to
all the nodes in the cluster. The proposal consists of a sequence number and a proposal
number. A cluster node checks its local copy of the cluster configuration to see whether
it has a newer sequence number or a higher proposal number. If the node does not
have more current information (higher numbers), the node sends an acceptance back to
the proposing node. If most of the nodes in the cluster (a "consensus") send back an
acceptance to the proposing node, the data is sent to each cluster node to be
incorporated locally.

When a cluster node joins a cluster, the node sends its Paxos tag information as part of
the joining process. If the Paxos tag information for the joining node is older than the
current cluster configuration, a complete copy of the cluster configuration is pushed to
the node as part of the joining process. This copy of the cluster configuration is known
as a cluster registry hive. This behavior guarantees that all nodes that are joining a
cluster have the most up-to-date configuration information.

The Paxos tag format in a cluster can change only in the following two scenarios:

When an authoritative restore of the cluster configuration is executed.

When the Cluster service is started by using the /forcequorum switch. The
shorthand for the switch is /fq.

The new Paxos tag formatting uses time stamps. The following is an example of the new
formatting:
2007/12/31-15 35 55.889_4:2007/12/31-15 35 55.889_4:294

This format guarantees that the nodes that run the Cluster service together with this
Paxos tag format will have the golden or authoritative copy of the cluster configuration.
Any node that joins the cluster will automatically have this copy of the cluster
configuration pushed to it during the joining process. Therefore, when you decide to
force the Cluster service to start on a specific node in a Windows Server 2008-based
failover cluster, it is important to select the node that has the most up-to-date cluster
configuration information. Otherwise, some configuration settings may be lost.

References
For more information about the MNS quorum model, visit the following Microsoft Web
site: https://technet.microsoft.com/library/cc784005(WS.10).aspx

For more information about the Paxos algorithm, visit the following Microsoft Web site:
https://research.microsoft.com/users/lamport/pubs/paxos-simple.pdf

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Move a Windows Server cluster from
one domain to another
Article • 12/26/2023

Windows clustering provides high availability of server resources. This article describes
how to move a Windows Server Cluster from one domain to another.

Applies to: Windows Server 2003

Original KB number: 269196

７ Note

We do not recommend performing this type of move in a production environment.

More information
Because of an increased dependence on Active Directory Domain Services, Microsoft
does not support moving an already installed and configured Windows Server 2008,
Windows Server 2008 R2 and Windows Server 2012 failover cluster from one domain to
another. The following steps are not for Windows Server 2008, Windows Server 2008 R2
and Windows Server 2012 you must create a new cluster. Additionally, you must
recluster highly available applications.

Although you can move a Microsoft Windows 2000-based server cluster or a Windows
Server 2003-based server cluster from one domain to another, we recommend that you
rebuild the cluster in the new domain so that all installed services and applications are
configured correctly in the new domain. You can use the steps in this article to enable
the cluster service to start and operate in a new domain. However, these steps will not
make sure that all resources will be available in the new domain.

７ Note

Microsoft does not provide support to administrators who try to move

resources from one domain to another if the underlying operation is
unsupported. For example, Microsoft does not provide support to
administrators who try to move a Microsoft Exchange server from one domain
to another.
 You cannot move Windows NT 4.0-based clusters from one domain to
another if any of the nodes in the cluster are domain controllers.

２ Warning

We recommend that you perform a full backup of all data on all shared hard disks
on each node in the cluster before you try to move the cluster.

The steps in this article enable the Cluster service to start in the new domain. However,
you may be unable to bring the resources online in the new domain, and the resources
that can be brought online may not work correctly.

To move the cluster:

1. Create a user account for the Cluster service in the new domain. You must make
sure that no Group Policy objects (GPOs) or security template requirements
remove any of these rights. The user account must have the following rights:

Lock pages in memory.

Log on as a service.
Act as part of the operating system. (Windows 2000 and Windows Server
2003)
Back up files and directories.
Increase quotas.
Increase scheduling priority.
Load and unload device drivers.
Restore files and directories.
Adjust memory quotas for a process (Windows Server 2003).

In addition, the Cluster service account must have administrative permissions on all
nodes in the cluster.

2. Set the Startup value for the Cluster service to Manual on all nodes in the cluster:
a. Click Start, point to Settings, click Control Panel, and then double-click Services.
b. Click Cluster Service, and then click Startup.
c. Change the Startup Type from Automatic to Manual.
d. Click OK.

3. Stop the Cluster service on all cluster nodes:

a. Click Start, point to Settings, click Control Panel, and then double-click Services.
b. Click Cluster Service, and then click Stop.
4. Turn off all nodes except one.

5. Move the node into the new domain by using procedures that are appropriate to
your operating system. Complete the process, and then restart the node.

6. On the node, change the service account that is used by the Cluster service to log
on to the domain to the user account that you created.

7. Start the Cluster service on that node.

8. Use Cluster Administrator to verify that there are no issues. Try to bring all
resources online. Test the functionality of all resources from client computers, and
then check the Event Viewer System log for error messages.

７ Note

At this point, you can still cancel the move by moving this node back into the
old domain and starting the nodes that are not moved.

9. If the first node move is successful, continue to migrate the other nodes in the
cluster to the new domain starting with step 5 for each node.

２ Warning

If you move a computer that has a Virtual Microsoft SQL Server 7.0 instance to
another domain, and you do not first uncluster SQL Server 7.0, the SQL cluster
resources may fail. Because of the failure of the SQL Server 7.0, you may have to
work with Microsoft CSS to manually uncluster SQL Server 7.0. After you have
unclustered SQL Server 7.0, you must use the SQL Cluster Failover Wizard to
reestablish your clustered SQL Server computers. You may also have to completely
remove SQL Server 7.0, and then reinstall it.

７ Note

If your DNS server is in a secure zone, DNS registrations may be affected. In a

secure DNS zone, the credentials of the account performing the registration are
captured and stored with the records. This protects them from being maliciously
replaced with incorrect values. For a cluster virtual server, the original cluster service
account would be used for this purpose. You may see DNS registration failures in
the System Event logs, typically error 9005 (refused). If this occurs, delete the
 records on the DNS server, and bring the Network Name offline, then online again
so that the new credentials can be recorded with the registration.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message "Provider load failure"
when you try to add a node to a
Windows Server 2008-based Failover
Cluster
Article • 12/26/2023

This article provides a solution to an error that occurs when you try to add a node to a
Windows Server 2008-based Failover Cluster.

Applies to: Windows Server 2012 R2

Original KB number: 2854337

Symptoms
When you attempt to add a node to your existing Windows Server 2008-based Failover
Cluster using the Add-Node wizard, you receive the following error message at the
bottom of the Add-Node wizard screen:

Provider load failure

Cause
The error "Provider Load Failure" is returned from WMI when a query is performed and
it's unable to load the required providers to satisfy the query. In this case, the cluster
"Add Node" wizard is making query to identify the domain of the server and the
provider is not correctly registered on the server.

Follow these steps to determine if you are experiencing this issue, on both the server
you are attempting to add to the cluster as well as the node that is already part of the
cluster:

1. Open WMI Tester - wbemtest.exe.

2. Select Connect.
3. In the Namespace box enter root\cimv2, and then select Connect.
4. Select Query and then enter SELECT Domain FROM Win32_ComputerSystem .

If you get the "Provider load failure" error, you are experiencing the problem
documented in this article, on this server.
Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To resolve this problem you need to correct the registration information for the
Cimwin32.dll file in the registry, using these steps:

1. Identify a Windows Server 2008 computer that is at the same Service Pack and
Hotfix level as the problem server and you are able to run the above mentioned
query successfully, in Wbemtest.exe.

７ Note

This do not necessarily need to be a Cluster node.

2. To open Registry Editor, select Start and then enter regedit.‌

Administrator permission required if you are prompted for an administrator

password or confirmation, type the password or provide confirmation.

3. Navigate to the following key:

HKEY_CLASSES_ROOT\CLSID\{D63A5850-8F16-11CF-9F47-00AA00BF345C}\InprocServer32

4. Select the key or the subkey that you want to back up.

5. Select the File menu, and then select Export.

6. In the Save in box, select the location where you want to save the backup copy,
and then type a name for the backup file in the File name box. Save it as a .REG
file.

7. Copy the above saved .REG file to the problem server.

8. Access the file on the problem server and double-click the file to merge it into the
registry.
 9. Restart the server.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error (The cluster node already exists)
may appear during cluster setup
Article • 12/26/2023

This article provides a solution to the error (The cluster node already exists) that occurs
during cluster setup.

Applies to: Windows Server 2003

Original KB number: 555216

Symptoms
During create new cluster via Cluster Administrator or cluster.exe command line, the
following error may appear:

The cluster node already exists

Cause
If the current server is member of exiting cluster, or/and the current resource (most
often quorum disk) is available.

Resolution
The resolution process depends on the current status of the cluster member:

1. If the current server should belong to exiting cluster, verity that quorum disk in
online and all cluster resource available for regular use. The server should not be
used as a new cluster member.

2. If the current shouldn't belong to exiting cluster or/and the cluster configuration
cannot be restored or be fixed, follow the following instructions:

The following process is irreversible, and may require reinstall the cluster.
a. Go to Start > Run.
b. Write Cmd and press on Enter button.
c. Write cluster node nodename /forcecleanup and press Enter.
d. The message should be appear after a few seconds: Clean up successfully
completed.
Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Guest Cluster nodes in Hyper-V may not
be able to create or join
Article • 12/26/2023

This article provides workarounds to an issue that Guest Cluster nodes in Hyper-V may
not be able to create or join.

Applies to: Windows Server 2012 R2

Original KB number: 2872325

Symptoms
Failover clusters that are running in virtual machines (sometimes referred to as "guest
clusters") could have problems with nodes joining the cluster.

By using the Create Cluster Wizard, the cluster may fail to create. Additionally, the
report from the wizard may have the following message:

An error occurred while creating the cluster.

An error occurred creating cluster '<clustername>'.
This Operation returned because the timeout period expired

７ Note

The above errors can also be seen anytime that communications between the
servers that are specified to be part of the cluster creation do not complete. A
known cause is described in this article.

In some scenarios, the cluster nodes are successfully created and joined if the VMs are
hosted on the same node. However, once the VMs are moved to different nodes, the
communications between the nodes of the guest cluster starts to fail. Therefore the
nodes of the cluster may be removed from the cluster.

Cause
This issue can occur due to packets not reaching to the virtual machines, when the VMs
are hosted on Windows Server 2012 failover cluster nodes, due to a failover cluster
component that is bound to the network adapters of the hosts. The component is called
the "Microsoft Failover Cluster Virtual Adapter Performance Filter" and it was first
introduced in Windows Server 2012.

The problem only affects the network packets addressed to cluster nodes hosted in
virtual machines.

Workaround
It is recommended that, if the Windows Server 2012 failover cluster is going to host
virtual machines that are part of guest clusters, you should unbind the "Microsoft
Failover Cluster Virtual Adapter Performance Filter" object from all of the virtual switch
network adapters on the Windows Server 2012 Failover Cluster nodes.

７ Note

This problem can affect any Windows Server Failover Cluster version that is running
inside of virtual machines as a guest cluster. The information mentioned in the
cause and workaround of this article is specific to Windows Server 2012 Failover
Clusters that are used to host virtual machines.

You can disable the "Microsoft Failover Cluster Virtual Adapter Performance Filter"
object using one of the methods from below:

Disabling using the GUI

Open Network Connections to get the list of network adapters. All network adapters
with the "vEthernet" (default name) are the virtual networks (i.e. virtual switch). The
physical adapters that also have a Hyper-V virtual adapter configured for it will not have
the "Microsoft Failover Cluster Virtual Adapter Performance Filter" binding, so there is
nothing to disable for those adapters.

1. Right click on one of the "v" adapters and select Properties from the menu.
2. Uncheck the item labeled "Microsoft Failover Cluster Virtual Adapter Performance
Filter".
3. Click on OK to close the dialog and have the binding disabled for the unchecked
item.
4. Repeat for all the adapters.

Disabling using Windows PowerShell

The following process will disable the network adapter, which is binding for "Microsoft
Failover Cluster Virtual Adapter Performance Filter" on every adapter on the server that
has the Componentid of "vms_mp". This Componentid indicates that the adapter is a
Hyper-V adapter used by the virtual switch.

You can run this process on each node of the server so that every server has the binding
disabled for the adapters used by the virtual switch.

Open the Windows PowerShell console with Administrator access using the Run as
Administrator option.

Run the following:

PowerShell

Get-netadapter | Disable-NetAdapterBinding -DisplayName "Microsoft

Failover Cluster Virtual Adapter Performance Filter"

７ Note

If you desire to enable the binding again, just replace "Disable-

NetAdapterBinding" with "Enable-NetAdapterBinding".

To verify which network adapters have the "Microsoft Failover Cluster Virtual
Adapter Performance Filter" item bound to it, you can run the following process:

PowerShell

PS C:\Windows\system32> Get-NetAdapterBinding | Where-Object

{$_.DisplayName -eq "Microsoft Failover Cluster Virtual Adapter
Performance Filter"} | FT Name,DisplayName,Enabled

Name DisplayName Enabled

------- --------------- ----------
vEthernet Microsoft Failover Cluster Virtual A... False
vEthernet 2 Microsoft Failover Cluster Virtual A... False
vEthernet 3 Microsoft Failover Cluster Virtual A... False
Ethernet 3 Microsoft Failover Cluster Virtual A... False
Ethernet 2 Microsoft Failover Cluster Virtual A... False
Ethernet Microsoft Failover Cluster Virtual A... False

The "Enabled" property of the binding for each adapter is "False", which means it's
not bound to that adapter.

More information
Windows Server 2012 failover cluster has a component that is bound to the network
adapters called "Microsoft Failover Cluster Virtual Adapter Performance Filter" and it can
cause some of the packets addressed to cluster nodes in the virtual machine to not
reach the virtual machine. If this issue occurs while a node is joining the cluster inside of
the virtual machine, it may fail to successfully be added to the cluster, or join the cluster.

The "Microsoft Failover Cluster Virtual Adapter Performance Filter" component is used
by the failover cluster NetFT virtual adapter to route some cluster specific
communications between nodes of the cluster. This item is not required to have it's
binding enabled for NetFT to function. Therefore, for Hyper-V hosts running Windows
Server 2012, it is recommended to disable the binding of this component on all
adapters of Hyper-V hosts that are members of a failover cluster.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You are unable to join a node into a
cluster if UDP port 3343 is blocked
Article • 12/26/2023

This article provides a solution to an issue where users are unable to join a node into a
cluster if UDP port 3343 is blocked.

Applies to: Windows Server 2012 R2

Original KB number: 2455128

Symptoms
Consider the following scenario:

On a computer that is running Windows Server 2008 or Windows Server 2008 R2.
You attempt to join the node into a cluster.

In this scenario, you may not be able to join the node into the cluster and you may
receive the following error in system event log:

Log Name: System

Source: Microsoft-Windows-FailoverClustering
Date: <date>
Event ID: 1572
Task Category: Cluster Virtual Adapter
Level: Critical
Keywords:
User: SYSTEM
Computer: <computer>
Description:
Node <computer> failed to join the cluster because it could not send and receive
failure detection network messages with other cluster nodes. Please run the Validate
a Configuration wizard to ensure network settings. Also verify the Windows Firewall
'Failover Clusters' rules.

Cause
Cluster nodes communicate over User Datagram Protocol (UDP) port 3343. The issue
may occur because the UDP port 3343 is not opened.
Resolution
To fix the issue, open the required UDP port 3343 on the cluster.

More information
This is a sample cluster log. The UDP port 3343 on the cluster is blocked:

00001344.0000043c::2010/07/27-12:54:42.832 INFO [CORE] Node 88f462ac-eb7c-

4b57-aaf2-7a989aa38806: Cookie Cache 88f462ac-eb7c-4b57-aaf2-7a989aa38806
00001344.0000043c::2010/07/27-12:54:42.832 DBG [CHANNEL
10.100.20.27:~3343~] Not closing handle because it is invalid.
00001344.0000043c::2010/07/27-12:54:42.832 WARN cxl::ConnectWorker::operator
(): GracefulClose(1226)' because of 'channel to remote endpoint
10.100.20.27:~3343~ is closed'
00001344.00001b8c::2010/07/27-12:54:43.815 INFO [JPM] Node 3: Selected
partition 904(1 2 4 5) as a target for join
00001344.00001b8c::2010/07/27-12:54:43.815 WARN [JPM] Node 3: No connection
to node(s) (2). Cannot join yet
00001344.0000043c::2010/07/27-12:54:44.813 INFO [JPM] Node 3: Selected partition
904(1 2 4 5) as a target for join
00001344.0000043c::2010/07/27-12:54:44.813 WARN [JPM] Node 3: No connection
to node(s) (2). Cannot join yet
00001344.00001b8c::2010/07/27-12:54:45.827 INFO [JPM] Node 3: Selected
partition 904(1 2 4 5) as a target for join
00001344.00001b8c::2010/07/27-12:54:45.827 WARN [JPM] Node 3: No connection
to node(s) (2). Cannot join yet
00001344.0000043c::2010/07/27-12:54:46.825 INFO [JPM] Node 3: Selected partition
904(1 2 4 5) as a target for join
00001344.0000043c::2010/07/27-12:54:46.825 WARN [JPM] Node 3: No connection
to node(s) (2). Cannot join yet

You can confirm the UDP port 3343 by command netstat -ano .

For more information, see Event ID 1572 — Network Connectivity and Configuration.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

Cluster IP address resources fail on both
nodes of a two-node, two-site cluster
when one node disconnects from the
public VLAN
Article • 12/26/2023

This article describes the behavior that occurs when one node of a two-node, two-site
cluster disconnects from the public cluster VLAN. In this case, the IP address resources
and their corresponding cluster groups fail on both nodes.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2

Symptoms
Consider the following scenario:

You have a two-site cluster that has one node in each site. The cluster uses a File Share
Witness (FSW) resource. The cluster nodes are connected by the following networks:

One stretched private VLAN

One non-stretched public VLAN

In this scenario, one of the nodes disconnects from the public VLAN. The following
figure shows the resulting configuration.

The cluster detects the interruption and marks the public VLAN network adapter on
Node 2 as "Failed." Therefore, all the cluster IP address resources on Node 2 fail. The
cluster groups that are associated with those resources also fail. The cluster generates
messages that resemble the following:
 000005ec.000011e4::2020/09/19-19:41:51.777 DBG [IM - public-1.0.0] Adding
interface states for cross-subnet-route-only interfaces

000005ec.000011e4::2020/09/19-19:41:51.777 DBG [IM - public-1.0.0] Interface

1ee3567e-84f7-459a-a39e-a5c44de643fa has no up cross-subnet routes. Marking it
as failed

Because the two sites cannot communicate across the public VLAN, the cluster also
marks the public VLAN network adapter on Node 1 as "Failed." Therefore, all the cluster
IP Address resources and the associated cluster groups on Node 1 fail.

00001790.000006ac::2020/09/19-19:41:51.780 INFO [IM] Changing the state of

adapters according to result: <class mscs::InterfaceResult>

00001790.00001678::2020/09/19-19:41:51.780 DBG [IM]

EventManager::ProcessInterfaceChanged: Ignoring event for Node1- 1.0.0-range
that should not be published.

00001790.00001678::2020/09/19-19:41:51.780 DBG [NM] Got interface changed

event for adapter Node1 - 1.0.0-range, new state 1

000012dc.00001664::2020/09/19-19:41:51.796 WARN [RES] IP Address <Cluster IP

Address x.x.x.x>: WorkerThread: NetInterface 1ee3567e-84f7-459a-a39e-
a5c44de643fa has failed. Failing resource.

In the end, lost connection to one node causes the cluster groups on both nodes to be
in a failed state. You have to manually bring the nodes online again.

If the two cluster nodes were in the same site, a similar network disconnect would cause
the public VLAN network adapter on Node 2 to fail in the same manner. However, in
that case all the cluster groups on Node 2 would fail over to Node 1. The cluster IP
address resources on Node 1 wouldn't fail.

Status
This behavior is by design. We recommend that you use four nodes instead of two
nodes for multi-site clusters. Azure AzS HCI clusters require four nodes.

Workaround
To prevent this behavior, you can change your cluster configuration by using any of the
following methods:

Add at least one cluster node to each site. In this configuration, if one node on a
site disconnects, the remaining node continues to communicate with the other
site. The cluster resources on the remaining node and on the nodes in the
unaffected site remain online.
Add another cluster node at a third site. In this configuration, if one node
disconnects, the two remaining nodes remain online, and cross-site
communication continues.
Change the private cluster network to a non-stretched VLAN. In this configuration,
if one node disconnects, the cluster starts the arbitration algorithm to determine
resource and quorum ownership.

If you have the configuration that is described in the "Symptoms" section and you have
to disconnect a node in a controlled manner (such as for a planned maintenance
window), prepare the cluster before you disconnect. Use one of the following
approaches:

Disable all networks except the public cluster VLAN.

Shut down all the cluster nodes except one.

When you're ready to resume typical operations, start by enabling the networks (or
restarting the nodes).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Having a problem with nodes being
removed from active failover cluster
membership
Article • 12/26/2023

This article introduces how to resolve the problems in which nodes are removed from
active failover cluster membership randomly.

Symptoms
When the issue occurs, you're seeing events like this event logged in your system event
log:

This event is logged on all nodes in the Cluster except for the node that was removed.
The reason for this event is because one of the nodes in the Cluster marked that node as
down. It then notifies all of the other nodes of the event. When the nodes are notified,
they discontinue and tear down their heartbeat connections to the downed node.

What caused the node to be marked down

All nodes in a Windows 2008 or 2008 R2 failover cluster talk to each other over the
networks that are set to allow cluster network communication on this network. The
nodes send out heartbeat packets across these networks to all of the other nodes. These
packets are supposed to be received by the other nodes and then a response is sent
back. Each node in the Cluster has its own heartbeats that it's going to monitor to
ensure the network is up and the other nodes are up. The following example should
help clarify this behavior:

If any one of these packets isn't returned, then the specific heartbeat is considered
failed. For example, W2K8-R2-NODE2 sends a request and receives a response from
W2K8-R2-NODE1 to a heartbeat packet so it determines the network and the node is
up. If W2K8-R2-NODE1 sends a request to W2K8-R2-NODE2 and W2K8-R2-NODE1
doesn't get the response, it's considered a lost heartbeat and W2K8-R2-NODE1 keeps
track of it. This missed response can have W2K8-R2-NODE1 show the network as down
until another heartbeat request is received.

By default, Cluster nodes have a limit of five failures in 5 seconds before the connection
is marked down. So if W2K8-R2-NODE1 doesn't receive the response five times in the
time period, it considers that particular route to W2K8-R2-NODE2 to be down. If other
routes are still considered to be up, W2K8-R2-NODE2 will remain as an active member.

If all routes are marked down for W2K8-R2-NODE2, it's removed from active failover
cluster membership and the Event 1135 that you see in the first section is logged. On
W2K8-R2-NODE2, the Cluster Service is terminated and then restarted so it can try to
rejoin the Cluster.

For more information on how we handle specific routes going down with three or more
nodes, see "Partitioned" Cluster Networks blog that was written by Jeff Hughes.

Now that we know how the heartbeat process

works, what are some of the known causes for
the process to fail
1. Actual network hardware failures. If the packet is lost on the wire somewhere
between the nodes, then the heartbeats fail. A network trace from both nodes
involved will reveal this.

2. The profile for your network connections could possibly be bouncing from Domain
to Public and back to Domain again. During the transition of these changes,
network I/O can be blocked. You can check to see if this is the case by looking at
the Network Profile Operational log. You can find this log by opening the Event
Viewer and navigating to Applications and Services
Logs\Microsoft\Windows\NetworkProfile\Operational. Look at the events in this log
on the node that was mentioned in the Event ID 1135 and see if the profile was
changing at this time. If so, see The network location profile changes from
"Domain" to "Public" in Windows 7 or in Windows Server 2008 R2 .

3. You have IPv6 enabled on the servers, but have the following two rules disabled for
Inbound and Outbound in the Windows Firewall:

Core Networking - Neighbor Discovery Advertisement

Core Networking - Neighbor Discovery Solicitation

4. Anti-virus software could be interfering with this process also. If you suspect this,
test by disabling or uninstalling the software. Do this at your own risk because
you're unprotected from viruses at this point.

5. Latency on your network could also cause this to happen. The packets might not
be lost between the nodes, but they might not get to the nodes fast enough
before the timeout period expires.

6. IPv6 is the default protocol that Failover Clustering will use for its heartbeats. The
heartbeat itself is a UDP unicast network packet that communicates over Port 3343.
If there are switches, firewalls, or routers not configured properly to allow this
traffic through, you can experience issues like this.

7. IPsec security policy refreshes can also cause this problem. The specific issue is that
during an IPSec group policy update all IPsec Security Associations (SAs) are torn
down by Windows Firewall with Advanced Security (WFAS). While this is
happening, all network connectivity is blocked. When renegotiating the Security
Associations if there are delays in performing authentication with Active Directory,
these delays (where all network communication is blocked) will also block cluster
heartbeats from getting through and cause cluster health monitoring to detect
nodes as down if they don't respond within the 5-second threshold.
 8. Old or out-of-date network card drivers and/or firmware. At times, a simple
misconfiguration of the network card or switch can also cause loss of heartbeats.

9. Modern network cards and virtual network cards might be experiencing packet
loss. This can be tracked by opening Performance Monitor and adding the counter
"Network Interface\Packets Received Discarded." This counter is cumulative and
only increases until the server is rebooted. Seeing a large number of packets
dropped here could be a sign that the receive buffers on the network card are set
too low or that the server is performing slowly and can't handle the inbound traffic.
Each network card manufacturer chooses whether to expose these settings in the
properties of the network card, therefore you need to refer to the manufacturer's
website to learn how to increase these values and the recommended values should
be used. If you're running on VMware, the following blog talks about this in a little
more detail including how to tell if this is the issue as well as points you to the
VMware article on the settings to change.

Nodes being removed from Failover Cluster membership on VMware ESX

These are the most common reasons that these events are logged, but there could be
other reasons also. The point of this blog was to give you some insight into the process
and also give ideas of what to look for. Some will raise the following values to their
maximum values to try to get this problem to stop.

ﾉ Expand table

Parameter Default Range

SameSubnetDelay 1000 milliseconds 250-2000 milliseconds

CrossSubnetDelay 1000 milliseconds 250-4000 milliseconds

SameSubnetThreshold 5 3-10

CrossSubnetThreshold 5 3-10

Increasing these values to their maximum might make the event and node removal go
away, it just masks the problem. It doesn't fix anything. The best thing to do is to find
out the root cause of the heartbeat failures and get it fixed. The only real need for
increasing these values is in a multi-site scenario where nodes reside in different
locations and network latency can't be overcome.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Nodes being removed from failover
cluster membership on VMware ESX
Article • 12/26/2023

This article addresses the issue of finding nodes removed from active failover cluster
membership when the nodes are hosted on VMware ESX.

Symptom
You see the following event in the System Event Log of the Event Viewer when this issue
occurs:

Resolution
One specific problem is with the VMXNET3 adapters dropping inbound network packets
because the inbound buffer is set too low to handle large amounts of traffic. You easily
can find out if packets are being drop by using Performance Monitor to look at the
Network Interface\Packets Received Discarded counter.
After you've added this counter, look at the Average, Minimum, and Maximum
numbers. If the values are higher than zero, then the receive buffer needs to be adjusted
upward for the adapter. This problem is documented in Large packet loss in the guest
OS using VMXNET3 in ESXi (2039495) .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to set up a clustered print server
Article • 12/26/2023

This article describes the steps to set up a clustered print server.

Applies to: Windows Server 2003

Original KB number: 278455

More information
You can use Windows Clustering to host print server functionality. The configuration
steps in Microsoft Windows Server 2003 differ from those in Microsoft Windows NT
Server 4.0, Enterprise Edition, Microsoft Windows 2000 Advanced Server, and Microsoft
Windows 2000 Datacenter Server. To set up a clustered print server, you need to
configure only the Spooler resource in Cluster Administrator and then connect to the
virtual server to configure the ports and print queues. This is an improvement over
previous versions of Windows Clustering in which you had to repeat the configuration
steps on each node in the cluster.

How to configure the spooler resource for the cluster

The first step in setting up a clustered printer server is to create a Spooler resource for
the service on a clustered server. The appropriate resources need to be made available
to the spooler service. To do this, create a Spooler resource in Cluster Administrator:

1. To open Cluster Administrator, click Start, click Run, type cluadmin, and then click
OK.

2. Right-click in the left pane, and then click Configure Application.

3. At the Welcome screen, click Next, and then click Next again to create a new
virtual server.

4. Click Use an existing Resource Group, and then click an existing group that has a
Disk resource in which you want to store the spooler and printer drivers. Click
Next.

5. For the resource group name, provide a name that accurately represents the
group, such as "SPOOLER."

７ Note
 This name is for administrative purposes only in Cluster Administrator.

6. At the Virtual Server Access Information screen:

a. Under Network Name, enter a NetBIOS name to which clients will connect. This
is the NetBIOS virtual server name that is used by clients to access the printers:
\\VirtualServer\Printer

７ Note

Microsoft recommends adhering to the 8.3-naming standard to assure

compatibility with earlier versions of the client.

b. Enter the IP address that clients will use to connect to this virtual print server. If
the nodes of the cluster have Print Services for Unix installed and running,
clients can connect using line printer remote (LPR) to this IP address.

7. Click Next.

8. At the Advanced Properties screen, you can make modifications to the resources
that are about to be created, and then click Next.

9. At the Create a Resource for My Application screen, click Next.

10. Click Print Spooler, and then click Next.

11. Give the Spooler resource a name.

７ Note

This name is for administrative purposes only in Cluster Administrator.

12. Set the dependencies for the Spooler resource:

a. Click Advanced Properties, and on the Dependencies tab, click Modify.
b. Double-click the Physical Disk resource on which you want the spooler files to
be located, and the Network Name resource that you just created.
c. Click OK twice.

13. Click Next.

14. Click Finish to complete the wizard.

15. Verify configuration and test failover:

a. Right-click the spooler group, and then click Bring Online.
 b. Verify that all resources come online, and then check the event logs for errors.
c. Right-click the spooler group, click Move Group, move the Spooler resource to
each node in the cluster that is a possible owner, and then verify that all
resources come online.

７ Note

If you are setting up an active/active print server, you need to create one
group for each node and you want to set each spooler group to have a
different preferred owner. You cannot have multiple Spooler resources in the
same group. An active/active print server configuration is one in which there
are multiple nodes in the cluster that are processing print jobs for clients with
multiple spoolers. This could include as many as two to four nodes that are
actively handling requests.

When a single node is hosting multiple groups with print spoolers, you'll be able to
browse all printers from all groups.

How to create the printer queues

Now that you've properly configured the Spooler resource with the necessary resources,
you can create all of the print queues for all of the physical printers. You can also use the
Clustool utility from the Resource Kit to migrate previously existing printer queues on a
server to a clustered server. After that, use the Print Migrate utility to migrate the printer
drivers. For best results, avoid having multiple servers configured to communicate
directly with the same printer.

1. From one of the nodes or a remote computer that has administrative permissions
to the cluster click Start, click Run, type \\VirtualServer where VirtualServer is the
name that is specified for the Network Name resource on which the Spooler
resource is dependent.

2. Double-click the Printers folder.

3. Double-click Add Printers to open the Add Printer Wizard, and then click Next.

4. Select Create a new port, and then click Next.

７ Note

TCP/IP ports are the only supported port type on a Windows Clustering. Use
the Standard TCP/IP Port option unless the printing clients need RFC-
 compliant LPR ports. If this is the case, follow these steps:
a. In Control Panel, double-click Add/Remove Programs, and then click
Add/Remove Windows Components to start the Windows Components
Wizard.
b. Under Components, scroll down and click to select the Other Network File
and Print Services check box.
c. Click Details to open the Other Network File and Print Services window,
click to select the Print Services for UNIX check box, and then click OK to
close the Other Network File and Print Services window.
d. Click Next to continue with the Windows Components Wizard.

When you complete the wizard, the LPR port will be available as a port type. By
default, according to RFC 1179, LPR will use only 11 TCP ports.

5. Type the IP address of the network printer that you want to process the print jobs
in the Printer Name or IP Address box.

７ Note

Bi-directional printing can also be a problem when using LPR printing. Some
printer drivers enable this option by default. When you create the LPR port
and printer, disable the Bi-directional printing option. If this option is
enabled, it may cause a printer to accept one or more print jobs, and then
stop accepting jobs until the printer is physically reset.

You no longer have to create a locally defined printer port configuration for each
node. In Windows 2000 (and later) the port configuration is stored in the cluster
registry and is therefore shared between all cluster nodes, under the following key:
HKEY_Local_Machine\Cluster\Resources\%Spooler GUID%\Parameters\Monitors\

6. Choose the appropriate driver for this printer, and then click Next.

7. Give the printer a unique name on the cluster server.

8. Choose a share name for the printer; this name must also be unique on this cluster.
You don't want to have any other printers with the same share name on this
cluster, even if they are in a different group and associated with a different Spooler
resource. In the event of a failure, in an active/active configuration the same node
in the cluster may own both spooler groups. If this occurs, printers that share a
 common name won't be available. Again, it's recommended to adhere to the 8.3-
naming standard for compatibility with earlier versions.

７ Note

The installation process then copies the printer driver files to the
\\VirtualServer\print$ share. The printer drivers are copied to the
%SystemRoot%\System32\Spool\Drivers\Spooler GUID\Drivers folder of the
node in the cluster that owns the Network Name resource for this virtual
name. The drivers are also copied to the shared disk in the \PrinterDrivers
folder.

9. Test the printing for this printer:

After you add all the desired print queues, use Cluster Administrator to move the
group that contains the Print Spooler resource to all other nodes. This copies the
printer drivers from the \PrinterDrivers folder on the shared disk to the
%SystemRoot%\System32\Spool\Drivers%Spooler GUID%\Drivers folder on that
node.

７ Note

Printing is available immediately to clients when the queue has been created
even though the drivers have not been copied to all other available nodes. It
is not necessary to move the spooler group over to all other nodes
immediately after creating the queues for the cluster to function. You can do
this later when you can schedule a brief outage during which time you can
take the Spooler resource offline.

When you set up a print cluster, you have to set the Quorum log size to a size that is
large enough to comply with the number of printers that will be installed. You should
increase the size of the reset quorum log when you increase the size of the Quorum log
size. To help determine whether you have to increase the reset quorum log size value,
verify the size of the Clusdb file. Each node includes a local copy of this file in the
%SystemRoot%\Cluster folder. The size of the reset quorum log for the transactional log
should be larger than the size of the Clusdb file for the cluster registry.

For example, if you have installed printers and the size of the Clusdb file is 6 megabytes
(MB), you should increase the size of the reset quorum log to 8192 bytes (8 MB). By
default, the size of the reset quorum log on Windows Server 2003 is 4 MB. You should
increase the size of the reset quorum log in 64-KB increments. A good rule is to double
the current size of the reset quorum log.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot upgrade the operating
system of a clustered server from
Windows Server 2003 or later versions
Article • 12/26/2023

This article provides workarounds for an issue where you can't upgrade the operating
system of a clustered server from Windows Server 2003 or later versions.

Applies to: Windows Server 2012 R2

Original KB number: 935197

Symptoms
When you try to perform one of the following server operating system upgrades, the
upgrade is blocked:

Windows Server 2003 to Windows Server 2008 or Windows Server 2008 R2

Windows Server 2008 to Windows Server 2008 R2 or Windows Server 2012
Windows Server 2008 R2 to Windows Server 2012 or Windows Server 2012 R2
Windows Server 2012 to Windows Server 2012 R2

When this problem occurs, the following error message is recorded in the System
Compatibility report:

You must make the following changes before upgrading Windows

Uninstall the following Windows components and features:

Server Clustering - Please read Microsoft Knowledge Base article: 935197

Cause
This behavior occurs because the server is a cluster member. Windows Server 2008,
Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 do not
support an upgrade of clustered servers from previous versions. This is because of
incompatibilities between the cluster versions.

Workaround
To work around this behavior, use one of the following methods, as appropriate for your
situation.

Method 1: Clean installation

1. Perform a clean installation of Windows Server 2008 or a later version on the
nodes in the cluster.
2. Install the Failover Clustering feature, create a new cluster, and then reconfigure
the cluster settings.

Method 2: In-place migration

To perform in-place migration, go to the following Microsoft website for more
information:

Migrating to a Failover Cluster Running Windows Server 2008 R2

Status
This behavior is by design.

More information
The Help files for Windows Server 2008 and later versions contain more information
about supported paths from previous versions of clustered servers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to update Windows Server failover
clusters
Article • 12/26/2023

This article describes how to update failover clusters in Windows Server.

Applies to: Windows Server 2012 R2

Original KB number: 174799

Summary
This article describes how to install service packs or hotfixes on a Windows Server
failover cluster. Applying a service pack or hotfix to a server cluster is the same as
applying a service pack or hotfix to Windows Server. However, there are special
conditions that you should consider to make sure that clients have a high level of access
while you perform the installation.

More information
To install Windows service packs or hotfixes on a Windows Server failover cluster, follow
these steps, depending on the version of Windows Server that you're running. Always
install the same service packs or hotfixes on each cluster node. Follow these steps unless
you're directed otherwise by the instructions for a particular service pack version.

Windows Server 2012 - 2019

Installing service packs and hotfixes on Windows Server 2012 - 2019 requires a different
process. For more information, see Draining Nodes for Planned Maintenance with
Windows Server .

Install service packs or hotfixes by using Failover Cluster

Manager in Windows Server 2008 R2
Membership in the local Administrators group on each clustered server or an equivalent
is required to complete this procedure.

1. Check the System log for errors, and make sure that the system is operating
correctly.
 2. Make sure that you have a current backup and updated emergency repair disk for
each system. If there are corrupted files, a power outage, or an incompatibility, you
may have to revert to the state of the system before you tried to install the service
packs or hotfixes.

3. In the Failover Cluster Manager snap-in, right-click Node A, and then click Pause.

4. On Node A, expand Services and Applications, and then click the service or
application.

5. Under Actions (on the right side), click Move this service or application to
another node, and then select the node.

７ Note

As the service or application moves, its status is displayed in the details pane
(the center pane).

6. Follow steps 4 and 5 for each service and application that is configured on the
cluster. On a cluster that has more than two nodes, from the options next to Move
this service or application to another node, you can select Best possible. This
option has no effect if you don't have a Preferred owners list configured for the
service or application that you're moving. (In this case, the node will be selected
randomly.) If you configured a Preferred owners list, the Best possible option will
move the service or application to the first available node on the list.

7. Install the service packs or hotfixes on Node A, and then restart the computer.

8. Check the System log for errors. If you find any errors, troubleshoot them before
you continue this process.

9. In the Failover Cluster Manager snap-in, right-click Node A, and then click Resume.

10. In the Failover Cluster Manager snap-in, right-click Node B, and then click Pause.

11. Under Actions (on the right side), click Move this service or application to
another node, and then select the node.

７ Note

As the service or application moves, its status is displayed in the details pane
(the center pane).
 12. Follow steps 10 and 11 for each service and application that is configured on the
cluster.

13. Install the service packs or hotfixes on Node B, and then restart the computer.

14. Check the System log for errors. If you find any errors, troubleshoot them before
you continue this process.

15. In Failover Cluster Manager, right-click Node B, and then click Resume.

16. Right-click each group, click Move Group, and then move the groups back to their
preferred owner. For more information, see Test the Failover of a Clustered Service
or Application and Pause or Resume a Node in a Failover Cluster.

Install service packs or hotfixes by using Windows

PowerShell cmdlets in Windows Server 2008 R2
Membership in the local Administrators group on each clustered server or an equivalent
is required to complete this procedure.

1. Check the System log for errors, and make sure that the system is operating
correctly.

2. Make sure that you have a current backup and updated emergency repair disk for
each system. If there are corrupted files, a power outage, or an incompatibility, you
may have to revert to the state of the system before you tried to install the service
packs or hotfixes.

3. In the Windows Server 2008 R2, use the Windows PowerShell Modules link under
Administrative Tools to automatically import all the Windows PowerShell modules
for the features or roles that you've installed.

4. Use the shortcut in Administrative Tools to start Failover Cluster PowerShell

Management. Or, start Windows PowerShell on your computer by right-clicking
and then selecting Run as administrator.

5. Load the Failover Clusters module by running the following command: Import-
Module FailoverClusters .

6. Suspend (Pause) activity on failover cluster node A by running the following

command: Suspend-ClusterNode nodeA .

7. Move a clustered service or application (a resource group) from one node to

another by running the following command: Move-ClusterGroup \<clustered
 service> -Node nodeB .

 Tip

You can also use following command to move all groups of the node to the
preferred owner of the best possible node: Get-ClusterNode NodeA | Get-
ClusterGroup | Move-Cluster Group .

8. Install the service pack on Node A, and then restart the computer.

9. Check the System log for errors. If you find any errors, troubleshoot them before
you continue this process.

10. Resume activity on node A that was suspended in step 5 by running the following
command: Resume-ClusterNode nodeA .

11. Suspend (Pause) activity on other failover cluster node by running the following
command: Suspend-ClusterNode nodeB .

12. Move a clustered service or application (a resource group) from one node to
another by running the following command: Move-ClusterGroup <clustered
service> -Node nodeB .

７ Note

You can again use following command to move all groups of the node to the
preferred owner of the best possible node:
Get-ClusterNode NodeB | Get-ClusterGroup | Move-Cluster Group .

13. Install the service pack on Node B, and then restart the computer.

14. Check the System log for errors. If you find any errors, troubleshoot them before
you continue this process.

15. Resume activity on node B that was suspended in step 10 by running the following
command: Resume-ClusterNode nodeB .

16. Move the clustered service or application (a resource group) back to their
preferred owner by running the following command: Move-ClusterGroup
<CusteredService> -Node <NodeName> .

For more information, go to the following Microsoft websites:

 Failover Cluster Cmdlets in Windows PowerShell
Overview of Server Manager Commands

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommended hotfixes and updates for
Windows Server 2008 R2-based server
clusters
Article • 12/26/2023

This article describes the hotfixes and updates that we recommend that you install on
each node of a Windows Server 2008 R2-based failover cluster.

Applies to: Windows Server 2008 R2

Original KB number: 980054

Summary
When you update your Windows Server 2008 R2-based failover cluster, you help reduce
downtime. You also help decrease the number of errors, failed print jobs, and other
support issues that you experience.

７ Note

We recommend that you evaluate these hotfixes and updates to determine

whether they might resolve problems in your environment. If you determine that
cluster nodes that are in your environment may be affected by the problems that
an update or hotfix addresses, install the hotfix or update on each cluster node that
is in your environment.

Use the information in the More information section to help you determine whether a
particular hotfix or update applies to the server cluster. Before you install a particular
hotfix or update, we recommend that you review the original Microsoft Knowledge Base
(KB) article that describes that hotfix or update.

More information
We recommend that you install Windows Server 2008 R2 Service Pack 1 (SP1), as it has
many fixes for problems with Windows Clustering. We also recommend installing the
hotfixes that are referenced in Recommended hotfixes and updates for Windows Server
2008 R2 SP1 Failover Clusters. If for any reason you cannot immediately apply SP1, we
recommend that you install the following Windows Server 2008 R2 hotfixes, depending
on your environment.
General hotfixes
We recommend that you install the following hotfixes if you plan to install the failover
clustering feature on Windows Server 2008 R2 Core:

ﾉ Expand table

Date when Knowledge Title Component Why we recommend

the hotfix Base article this hotfix
was added

August 3, 2685891 CAP does not come Clusres.dll Prevents cluster outage
2013 online in a Windows when CAP fails to come
Server 2008 R2-based online. Available for
or Windows Server individual download.
2008-based failover
cluster

April 25, 2559392 The List Running Multiple Prevents cluster

2012 Processes test fails validation .dll validation failure.
when you run the files Passing validation is
Failover Cluster required to have a
Validation Wizard on supported cluster
a Windows 7-based configuration. Available
or Windows Server for individual
2008 R2-based cluster download.
node

March 16, 2639032 0x0000003B, Clusauthmgr.dll Prevents a Stop error.

2012 0x00000027, and Available for individual
0x0000007e Stop Csvfilter.sys download.
errors when a
connection to a CSV
is lost.

November 2687646 A LUN that is clussvc.exe Prevents a LUN from

22, 2012 registered to a cluster not being detected by
shared volume is cluswmi.dll the operating system.
invisible and Available for individual
inaccessible download.

January 17, 2524478 The network location Ncsi.dll Prevents potential loss
2012 profile changes from of cluster
Domain to Public in Nlaapi.dll communication.
Windows 7 or in Available for individual
Windows Server 2008 Nlasvc.dll download.
R2
 Date when Knowledge Title Component Why we recommend
the hotfix Base article this hotfix
was added

May 14, 2545850 Users cannot access Multiple Prevents CNO and VCO
2011 an IIS-hosted website Authentication objects from failing to
after the computer DLL's register in DNS due to
password for the Kerberos authentication
server is changed in not working after the
Windows 7 or in computer password is
Windows Server 2008 changed.
R2

March 24, 978309 IPv6 transition Tunnel.sys Fixes components

2010 technologies, such as leveraged by failover
ISATAP, 6to4, and cluster on 2008 R2
Teredo do not work Server Core
on a computer that is installations. Available
running Windows for individual
Server 2008 R2 Server download.
Core

September 976571 Stability update for Win32spl.dll Fixes print cluster

4, 2010 Windows Server 2008 stability. Apply only if
R2 Failover Print print cluster resources
Clusters are configured.
Available for individual
download.

To avoid problems that affect the cluster operation when the network is unreliable,
install the following hotfix:

2552040 A Windows Server 2008 R2 failover cluster loses quorum when an

asymmetric communication failure occurs

To avoid performance issues on the cluster and possible system crashes, install the
following hotfix:

2520235 0x0000009E Stop error when you add an extra storage disk to a failover
cluster in Windows Server 2008 R2

Resource-specific hotfixes
We recommend that you install the following hotfixes, depending on the resources that
are running on the server cluster. You do not have to install these hotfixes if you are not
running these resources on the server cluster.
976571 Stability update for Windows Server 2008 R2 Failover Print Clusters

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Failover behavior on clusters of three or
more nodes
Article • 12/26/2023

This article documents the logic by which groups fail from one node to another when
there are three or more cluster node members.

Applies to: Windows Server 2012 R2

Original KB number: 299631

Summary
The movement of a group can be caused by an administrator who manually moves a
group or by a node or resource failure. Where the group moves depends on how the
move is initiated and whether the Preferred Owner list is set.

More information
Information about the Preferred Owner list is covered in the Help file under "Server
Clusters," including information about planning and optimizing server clusters. This
article documents the following four possible scenarios:

1. There's a node or resource failure and the Preferred Owner List is set.
2. There's a node or resource failure and the Preferred Owner List isn't set.
3. Administrator manually moves group to "Best Possible" and the Preferred Owner
List is set.
4. Administrator manually moves group to "Best Possible" and the Preferred Owner
List isn't set.

Scenario 1
If a node or resource fails and the Preferred Owner List has been defined, the Cluster
Service fails the Group to the next available node in the Node List. The Node List is
composed of the Preferred Owners List followed by the remaining nodes arranged by
their Node ID. The Node ID is defined when a node is joined to a cluster or if a node is
evicted or and re-added.

You can view the Node ID order by examining the registry under the
\HKEY_LOCAL_MACHINE\Cluster\Nodes key.
For example, suppose we have a six node Cluster and that the nodes were installed and
joined the Cluster in the following order: NodeA, NodeB, NodeC, NodeD, NodeE, and
NodeF. Assume that a Group has NodeA, NodeC, and NodeE listed as the Preferred
Owners.

Having this information, the Node List for the Group would then be the following:

1. NodeA - Preferred Owner number one

2. NodeC - Preferred Owner number two
3. NodeE - Preferred Owner number three
4. NodeB - Second installed Node
5. NodeD - Fourth installed Node
6. NodeF - Sixth installed Node

In this scenario, if a Node failure or a failure of a resource was to occur and its restart
threshold were hit, the whole Group would fail to the next node down in the Node List.
For example, if NodeC contained the resource that failed, the whole Group would fail to
NodeE. It wouldn't fail to NodeA even though it's listed first in Preferred Owner List. If
NodeE fails, the Group would fail over to NodeB and not to NodeA.

Scenario 2A
If a resource fails and the Preferred Owner List isn't set, the Group follows a Node List
much like it did in Scenario 1. The Node List is built only from the Node ID. Upon a node
or resource failure, resources follow a downward path failing to the subsequent node in
the Node List. When it reaches the last listed node in the Node List, it starts with the first
node in the Node List.

1. NodeA - First installed Node

2. NodeC - Second installed Node

3. NodeE - Third installed Node

4. NodeB - Fourth installed Node

5. NodeD - Fifth installed Node

6. NodeF - Sixth installed Node

For example, this list has the installation order of the different Cluster nodes. If NodeE
were to fail, all groups that it owned would fail over to NodeB and not to NodeF.

Scenario 2B
If a node fails and the Preferred Owner List isn't set for a group on that node, then an
available node will be selected randomly for the group to be moved to. This will
distribute the groups among the available nodes.

Scenario 3
If a Cluster administrator manually chooses Move group and selects Best Possible and
the Preferred Owner List is configured, the Group will always start at the top of the Node
List. As in Scenario 1, the Node List is composed of the Preferred Owner List and the
installation order.

1. NodeA - Preferred Owner number one

2. NodeC - Preferred Owner number two
3. NodeE - Preferred Owner number three
4. NodeB - Second installed Node
5. NodeD - Fourth installed Node
6. NodeF - Sixth installed Node

In this example, when Best Possible is selected, the Group always tries to move to
NodeA. If the Group is already on NodeA or NodeA isn't available, the Group tries to
move to NodeC. If a Group is on NodeD and the Administrator chooses to move it to
Best Possible, the Group goes to NodeA. If NodeA, NodeC, or NodeE aren't active,
either NodeB or NodeF is randomly chosen.

Scenario 4
If as Cluster administrator, you manually choose Move group and you select Best
Possible and the Preferred Owner List isn't configured, an active node is chosen
randomly to host the group. Without the Preferred Owner List configured, it's possible
that a Group may move to a Node that is already running several other Groups.

We recommend that you configure the Preferred Owner list on a large node cluster if
the load between nodes is significantly different or if the nodes aren't homogeneous.

７ Note

The exception to the failover behavior that is mentioned here is with the default
Group that holds the Quorum resource that is named the Cluster Group. The
Cluster Group does not follow the typical Preferred Owner list behavior. Instead, if
the owner of the Quorum resource fails, the new owner will be the previous group
that successfully owned the Quorum resource.
The AntiAffinityClassNames public property can also affect where a Group will fail over
to.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Run the chkdsk /f command on a shared
cluster disk
Article • 12/26/2023

This article describes how to run the chkdsk /f command on a shared cluster disk.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 176970

Summary
When you try to run the chkdsk /f or chkdsk /f /r command on a shared cluster drive,
Chkdsk may not run and may state that the drive could not be locked for exclusive use.
If you schedule Chkdsk to run after the computer restarts, Chkdsk may generate the
following error message during the startup process:

Cannot determine file system on drive ??\ drive letter.

More information
Under most circumstances, running Chkdsk with the /F or /R switch requires the
computer to be restarted because of open handles on the shared disk. Typically, there
are no services or drivers running that prevent autochk (a derivative of Chkdsk) from
checking the disk when the computer restarts. However, if you are using Windows
Clustering, the file system does not mount the shared disk until the Cluster service starts
because the owner of the shared disk is unknown. This causes Chkdsk to report that it
cannot determine the file system on a shared cluster disk. Running Chkdsk in Read-Only
mode may seem to work, but Chkdsk does not fix any problems.

If you suspect that there is file corruption on the shared disk, use the following steps to
close all open handles to the shared disk and run Chkdsk on the drive:

1. Quit all programs and stop all non-cluster-aware services.

2. Start the Cluster Administrator tool, right-click the cluster name, and then click
Properties.

3. On the Quorum tab, note which hard disk is the quorum hard disk. If the hard disk
on which you want to run Chkdsk contains the quorum log, temporarily move the
quorum to another shared disk.
 4. Use the Cluster Administrator tool to find the group that contains the shared hard
disk on which you want to run Chkdsk.

5. After you find the physical disk resource on which you want to run Chkdsk, take
the entire group offline, including the shared disk. This closes all of the handles to
the physical disk. To take the group offline, right-click the group name, and then
click Take off-line.

6. In the Cluster Administrator tool, click the shared disk on which you want to run
Chkdsk, and then bring it online. To do this, right-click the disk resource, and then
click Bring on-line.

７ Note

If the dirty bit was previously set, Chkdsk may automatically run and the
Physical Disk resource may take a while to come online. In Windows NT 4.0,
you will see a Command Prompt window with Chkdsk running. In Windows
2000, if you open Task Manager you will see Chkdsk running as a process.

7. At a command prompt, change to a drive other than the drive on which you are
attempting to run Chkdsk, and then type the chkdsk **x**: /f /r command,
where X is the shared disk.

If you receive a Disk cannot be locked error message when you try to run Chkdsk, verify
that all services and tools that have access to the drive are stopped, and then try to run
Chkdsk again. Any running service or program that has an open handle to the drive can
prevent Chkdsk from running. Windows 2000 and later versions of Windows can
attempt to close open handles to the shared disk. If you are prompted to close open
handles, press the Y key.

If handles remain open or the cluster contains a single

shared disk
If programs or drivers maintain an open handle to the shared disk, or if there is only a
single shared disk (on which the quorum log is stored), you must take down the entire
cluster. Doing this requires that you disable the clustering components temporarily so
that the file system can mount the shared disk when you restart the node. You must also
shut down the other nodes in the cluster so that they do not take ownership of the
shared disk when the node restarts.

To do this, use the steps in the appropriate section.

Windows Server 2003
You must put the physical disk resource in maintenance mode before you run a "chkdsk
/F" command against a volume on a Microsoft Windows Server 2003-based computer.
You must do this to prevent the physical disk resource from going into a failed state.

Windows 2000

1. Quit all programs, stop all programs that are not cluster-aware, and then log on to
the server with an account that has Administrative credentials.
2. Start Cluster Administrator, right-click cluster name, and then click Properties.
3. Click the Quorum tab, and then note which drive is the quorum disk. If the drive
on which you want to run Chkdsk contains the quorum log, temporarily move the
quorum disk to another shared drive.
4. Copy FSUtil.exe from the %SystemRoot%\System32 folder on a Windows XP-or-later-
based computer to the local drive on the Windows 2000-based computer.
5. On the Windows 2000-based computer, at a command prompt, change to the
folder that contains FSUtil.exe, and then type the fsutil dirty set drive:
command, where drive is the shared drive.
6. Use Cluster Administrator to find the group that contains the shared drive on
which you want to run Chkdsk.
7. Right-click the group name, and then click Take offline. This takes the whole group
offline, including the shared drive, and closes all the handles to the physical drive.
8. Right-click the Physical Disk resource, and then click Bring Online. This brings the
drive online. Chkdsk runs on the volume, and it may be in an online pending state
for a while.
9. After Chkdsk runs on the volume, bring all other resources in the group online.

Windows NT 4.0

1. Turn off node B.

2. Log on to node A as an administrator.
3. Run the chkdsk /f command on the shared disk. When you are prompted to
schedule Chkdsk to run when the computer next restarts, press Y.
4. In the Devices tool in Control Panel, click Cluster Disk, and then click Startup.
5. Change the Startup type to Disabled.
6. In the Services tool in Control Panel, click the Cluster Server service, and then click
Startup.
7. Change the Startup type to Disabled.
 8. Quit Control Panel, and then restart node A. Chkdsk runs without interference from
the Cluster Disk driver or any other service.
9. After Chkdsk is finished, change the Startup type back to its original setting, and
then restart the computer to activate the cluster.
10. Turn on node B.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unexpected cluster failover
troubleshooting guidance
Article • 12/26/2023

A cluster won't trigger a failover unless there's an actual issue with one of the cluster's
components (software or hardware). It will perform a basic recovery step, and the
affected resource will fail over to another node because of the following possible causes:

Resource failure

Networking issue such as node eviction

Cluster Shared Volume (CSV) disk failure

Troubleshooting checklist
1. Identify the occurrence timestamp in the System Event Log. Then, search for events
about the source Microsoft-Windows-FailoverClustering and check for Event ID
1069, 1146, or 1230 .

2. Match the time zone of the System event log to the GMT time zone in the cluster
log.

７ Note

To quickly find the time zone difference, search for The current time is .

3. Navigate to the occurrence timestamp in the cluster log and identify the
corresponding line. You may find an error such as:

Resource <name> IsAlive has indicated failure

IsAlive sanity check failed

７ Note

The error can be different depending on the issue.

4. Scroll up in the cluster log and try to identify if there's any other error that might
be the actual cause.
 5. Scroll down in the cluster log and search for Group move or Move of group for the
affected resource. Take note of the exact timestamp and the destination node.

6. Switch over to the cluster log of the destination's node and check the resource's
behavior when it's online. If the resource manages to come online, you'll find the
following log:

Resource <name> has come online

Group move for <name> has completed

Otherwise, you'll find the following log:

Online for resource <name> failed

More information
For more information, see the following articles:

Resource Hosting Subsystem (RHS) in Windows Server Failover Clusters

Failover behavior on clusters of three or more nodes

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommended hotfixes and updates for
Windows Server 2012 R2-based failover
clusters
Article • 12/26/2023

This article describes the hotfixes that are currently available for Windows Server 2012 R2-based
failover clusters and are highly recommended to be installed on each server of a failover cluster.

Applies to: Windows Server 2012 R2

Original KB number: 2920151

Summary
Failover Cluster Management enables multiple servers to provide a high availability of server roles.
Failover Cluster Management is frequently used for file services, virtual machines, database
applications, and mail applications.

） Important

The process for installing service packs and hotfixes for Windows Server 2012 R2 differs from
the process for earlier versions of Windows Server. In Windows Server 2012 R2, you can use the
Cluster-Aware Updating (CAU) feature. CAU automates the software-updating process on
clustered servers and maintains availability. For more information, see Cluster-Aware Updating
Overview.

The following Microsoft Knowledge Base articles describe the currently available fixes that are highly
recommended to be installed on all failover clusters. Most of the updates apply to computers that
are running Windows Server 2012 R2. Some updates, such as KB 976424 , may be required on
computers that are running Windows Server 2008 R2 or Windows Server 2008 if those operating
systems are present in the environment.

These updates are considered to be important installations to ensure the highest level of reliability.

Any Windows Server 2012 R2 cluster

７ Note

You may substitute a newer monthly rollup in place of KB 4282815. The remainder of the
updates in this list are still needed as some components in those updates released before
September 2016 and are not included in the newer monthly rollup.
 ﾉ Expand table

Date that Related Title Component Why we recommend this

update Knowledge update
was Base
added article

June 14, 4284815 June 12, 2018-KB4284815 (Monthly Multiple This security update rollup
2018 Rollup) includes improvements and fixes
that were released after
September 2016. Available from
Windows Update or for individual
download from Microsoft Update
Catalog and Microsoft Download
Center. To apply this update, you
must first install update
2919355 on Windows Server
2012 R2.

June 21, 3137728 VSS restore fails when you use Vssvc Includes the fix from 3123538 .
2017 ResyncLuns VSS API in Windows Server Available from Windows Update
2012 R2-based failover cluster or for individual download from
Microsoft Update Catalog and
Microsoft Download Center. To
apply this update, you must first
install update 2919355 on
Windows Server 2012 R2.

August 3179574 August 2016 update rollup for Windows Multiple This rollup includes a fix that
22, 2016 RT 8.1, Windows 8.1, and Windows addresses an issue with cluster
Server 2012 R2 services that may stop working
when network loss logging occurs
when a network connection is
down and virtual machines are
configured with one possible
owner. Available from Windows
Update or for individual
download from Microsoft Update
Catalog. To apply this update, you
must first install the update
2919355 on Windows Server
2012 R2.

July 21, 3172614 July 2016 update rollup for Windows RT Multiple This rollup includes
2016 8.1, Windows 8.1, and Windows Server improvements and fixes from
2012 R2 June 2016 update rollup KB
3161606 and May 2016 update
rollup KB 3156418 including an
update (3153887 ) that
increases the default values of
SameSubnetThreshold,
CrossSubnetThreshold, and
RouteHistoryLength to be more
tolerant of brief transient network
issues. Available on Windows
update or for individual
Date that Related Title Component Why we recommend this
update Knowledge update
was Base
added article

download from Microsoft Update

Catalog. To apply this update, you
must first install the update
2919355 on Windows Server
2012 R2.

October 3091057 Cluster validation fails in the Validate Cprepsrv Changes some timing of the
28, 2015 Simultaneous Failover test in a Validate Simultaneous failover
Windows Server 2012 R2-based failover test to more accurately verify the
cluster storage compatibility with the
failover cluster. Available for
individual download.

December 3013769 December 2014 update rollup for Multiple An update rollup package that
18, 2014 Windows RT 8.1, Windows 8.1, and resolves issues and includes
Windows Server 2012 R2 performance and reliability
improvements. Available from
Windows Update and for
individual download from
Download Center. To apply this
update, you must first install the
update 2919355 on Windows
Server 2012 R2.

November 3000850 November 2014 update rollup for Multiple A cumulative update that includes
18, 2014 Windows RT 8.1, Windows 8.1, and the security updates and
Windows Server 2012 R2 nonsecurity updates including
Failover Clustering updates that
were released between April 2014
and November 2014. Available
from Windows Update and for
individual download from
Download Center. To apply this
update, you must first install the
update 2919355 on Windows
Server 2012 R2.

April 8, 2919355 Windows RT 8.1, Windows 8.1, and Multiple A cumulative update that includes
2014 Windows Server 2012 R2 Update April, the security updates and
2014 nonsecurity updates including
Failover Clustering updates that
were released before March 2014.
Available from Windows Update
and for individual download from
Download Center.

December 976424 Error code when the kpasswd protocol KDCSVC Enables you to add a Windows
18, 2013 fails after you perform an authoritative Server 2012 failover cluster. Install
restore: on every domain controller that is
"KDC_ERROR_S_PRINCIPAL_UNKNOWN" running Windows Server 2008
Service Pack 2 (SP2) or Windows
 Date that Related Title Component Why we recommend this
update Knowledge update
was Base
added article

Server 2008 R2. Otherwise, Create

Cluster may fail when you try to
set the password for the cluster
computer object, and you receive
a
CreateClusterNameCOIfNotExists
(6783): Unable to set password
on <ClusterName$> error
message. This hotfix is included in
Windows Server 2008 R2 Service
Pack 1 (SP1).

Windows Server 2012 R2 Hyper-V clusters

In addition to the updates listed above, the following Microsoft Knowledge Base articles describe
currently available fixes that are highly recommended to be installed on Hyper-V failover clusters.
These updates target reliability improvements when backing up virtual machines on Hyper-V failover
clusters.

ﾉ Expand table

Date that Related Title Component Why we recommend this update

update Knowledge
was added Base article

June 21, 3145384 MinDiffAreaFileSize Volsnap.sys Describes an update that increases the
2017 registry value limit is MinDiffAreaFileSize registry key value
increased from 3 GB to limit from 3 GB to 50 GB in Windows
50 GB in Windows 8.1 8.1 and Windows Server 2012 R2.
or Windows Server Before you install this update, see the
2012 R2 "Prerequisites" section. Includes the fix
from 3060678 . Available from
Windows Update or for individual
download from Microsoft Update
Catalog. To apply this update, you
must first install the update 2919355
on Windows Server 2012 R2.

September 3063283 Update to improve the Hyper-V Increases the time-out to detect the
15, 2015 backup of Hyper-V Integration volumes to shadow copy when the
Integrated components Services Guest OS has multiple volumes.
in Hyper-V Server 2012 Available for individual download. To
R2 apply this update, you must first install
the update 2919355 on Windows
Server 2012 R2.
References
For more information about the recommended hotfixes and updates for Windows Server 2012-
based Hyper-V servers and Windows Server 2012-based Failover Clusters, see:

Hyper-V: Update List for Windows Server 2012

2784261

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Adding support for more than eight
LUNs in Windows Server
Article • 12/26/2023

This article describes the support for a large number of logical unit numbers (LUNs) in
Windows Server products.

） Important

This article contains information about how to modify the registry. Make sure to
back up the registry before you modify it. Make sure that you know how to restore
the registry if a problem occurs. For more information about how to back up,
restore, and modify the registry, see Windows registry information for advanced
users.

Applies to: Windows Server 2012 R2, Windows Server 2016

Original KB number: 310072

Summary
This article describes the support for a large number of logical unit numbers (LUNs) in
Windows Server products. When you configure a server with more than eight LUNs, the
hardware vendor must be involved in the planning and configuration. There may be
several different ways to achieve the configuration you want; the hardware vendor is
best equipped to supply the necessary information. This article isn't meant to be all-
inclusive because of the various implementations that a hardware vendor can use.
Contact your hardware manufacturer to determine if and how your hardware can
support more than eight LUNs.

Windows Server 2008 and Windows Server 2008 R2 support up to:

Eight buses per adapter

128 target IDs per bus
255 LUNs per target ID

Windows Server 2012 and later versions of Windows support up to:

255 buses per adapter

128 target IDs per bus
255 LUNs per target ID
More information

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall your operating system. Microsoft cannot guarantee that these problems
can be solved. Modify the registry at your own risk.

Terminology used in this article

Host Bus Adapter (HBA): This is the controller that is connected to the storage
device. It may be a SCSI or Fibre controller because both topologies can support
more than eight LUNs.
Storage device: This is the controller in the array to which the HBA attaches. This is
the device that controls the drives.
Large LUN: This is a commonly used term for the practice of supporting more than
eight LUNs.

Windows Server supports Large LUNs, but the method for enabling it depends on the
hardware implementation and drivers. If the storage device reports the HiSupport bit in
its standard inquiry data, Windows automatically enables Large LUNs without requiring
any manual registry entries. Contact the hardware vendor to determine if the storage
device reports the HiSupport bit. The hardware drivers may also enable large LUN
support during their installation routines.

If the hardware doesn't report the HiSupport bit, or the drivers don't enable Large LUN
support, a manual registry entry is required. This feature works only if the storage
devices support the SCSI REPORT LUNS command. Note that editing the registry to
enable Large LUNs requires detailed knowledge of the devices' hardware IDs and
registry entries; this is the least-preferred method. Contact the hardware vendor for
additional information. Follow these steps to configure the required registry entry:

1. Find the hardware ID of the storage device. To find the hardware ID:
a. Start Regedit.exe, and then locate and click the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI

b. Disk and storage devices that are enumerated by the system are listed. The
storage device on which you want to enable LargeLUNs should appear in the list
starting with Disk&Ven_. The name of the storage device should be
recognizable after the Disk&Ven_ text.
 c. To find the hardware ID for the proper storage device, open the different
Disk&Ven_ keys to display the different instances of the storage devices. A value
labeled FriendlyName with a description to the right appears under each of the
instances.
d. After you locate the storage device, double-click hardwareID for one of the
instance names. This is typically listed under the FriendlyName value.
e. The value data lists the hardware ID of the storage device. Often, several
hardware IDs are listed. Copy only one of these hardware IDs. Make sure to
copy only the portion of the value after "SCSI\" to the Clipboard.

７ Note

There may be several hardware IDs for the same device. This occurs because
the device may be detected in different ways for different firmware revisions
of the same device. You may have to try each of the different hardware IDs in
the following steps. If you have any problems with this, contact your storage
device hardware manufacturer.

2. With the hardware ID from the previous steps, follow the next steps to enable
Large LUN support for the appropriate storage device:

a. Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ScsiPort\SpecialTargetL

ist

b. On the Edit menu, point to New, and then click Key.

c. A new key named New Key #1 is created. Right-click New Key #1, and then click
Paste to paste the hardware ID that you copied earlier.

７ Note

Right-clicking New Key #1 also displays a Rename command that you can
use to attempt to paste the data again if New Key #1 is not in the proper
state.

d. After you create the new key, create a new DWORD value named LargeLuns
with a value of 1.

７ Note
 "LargeLuns" is plural.

3. Reboot the computer.

Issues involved in manually enabling Large LUN support

Duplicate disks may appear after you enable Large LUN support. This can occur if the
HBA driver enables Large LUN support in a proprietary fashion coupled with the manual
registry entry. The issue occurs if both the Windows LargeLuns feature and the HBA's
LargeLuns feature are enabled.

If logical unit 0 isn't present, the REPORT LUNS command can't be sent to the target
device. Windows enumerates only eight logical units, even if more units are present in
the disk array. To support large configurations, the time that is necessary to determine
the size configuration needed to be minimized. Because the number of logical units can
be as high as 255 on some systems (0 - 254), lots of time can be spent in sending
inquiry commands to non-existent logical units. Notice that any LUN number returned
from Storage should be in range of 0 - 254.

Any LUN with a LUN number larger than 254 will not be recognized by the Windows
operating system. Consult your hardware manufacturer about the different parameters
that should be used with your particular hardware.

Even though Windows can access Large LUNs, there may be other environment
variables that need to be taken into consideration.

Additional parameters for the SpecialTargetList key

For Windows Server, there are several additional parameters that you can use under the
SpecialTargetList key. They are:

SparseLun - Allow for discontinuous LUN list.

OneLun - Only scan LUN zero.
LargeLuns - The device supports more than seven LUNs.
SetLunInCdb - The device requires the LUN in CDBs sent to it.
NonStandardVPD - The device supports VPD 0x83 but not 0x80.
BinarySN - The device returns a binary serial number.

These keys are checked in the order in which they're listed; the information at each level
is logically "OR'ed" with that from the previous level.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Antivirus software that isn't cluster-
aware may cause problems with Cluster
Services
Article • 12/26/2023

This article provides help to solve problems with Cluster Services that be caused by
antivirus software that isn't cluster-aware.

Applies to: Windows Server 2022、Windows Server 2019、Windows Server 2016、

Windows Server 2012 R2
Original KB number: 250355

Summary
Antivirus software that is not cluster-aware may cause unexpected problems on a server
that is running Cluster Services. For example, you may experience resource failures or
problems when you try to move a group to a different node.

Workaround

２ Warning

This workaround may make a computer or a network more vulnerable to attack by

malicious users or by malicious software such as viruses. We do not recommend
this workaround but are providing this information so that you can implement this
workaround at your own discretion. Use this workaround at your own risk.

７ Note

Antivirus software helps protect your computer from viruses. You must not
download or open files from sources that you do not trust, visit Web sites that you
do not trust, or open e-mail attachments when the antivirus software is disabled.

For more information about computer viruses, see How to prevent and remove viruses
and other malware .
Most antivirus software uses filter drivers (device drivers) that work together with a
service to scan for viruses. These filter drivers reside above the file system recognizer
and scan files as they are opened and closed on a local hard disk. Antivirus software may
not understand the shared disk model and may not correctly allow for failover.

If you are troubleshooting failover issues or general problems with a Cluster services
and antivirus software is installed, temporarily uninstall the antivirus software or check
with the manufacturer of the software to determine whether the antivirus software
works with Cluster services. Just disabling the antivirus software is insufficient in most
cases. Even if you disable the antivirus software, the filter driver is still loaded when you
restart the computer.

Even if you are not monitoring the shared disk, the filter drivers are still loaded and may
affect the operation of the cluster.

You can run antivirus software on a SQL Server cluster. However, you must make sure
that the antivirus software is cluster-aware. Contact your antivirus software vendor
about cluster-aware versions and interoperability.

Additionally, you should exclude the following file system locations and the processes
from virus scanning on a server that is running Cluster Services:

Directory
The path of the \Cluster folder on the quorum hard disk. For example, exclude
the Q:\Cluster folder from virus scanning.
The %Systemroot%\Cluster folder.
The temp folder for the Cluster Service account. For example, exclude the
\cliusr\Local Settings\Temp folder from virus scanning.

Process
clussvc.exe ( %systemroot%\Cluster\clussvc.exe )

This file may have to be configured as a process exclusion within the antivirus
software.

rhs.exe ( %systemroot%\Cluster\rhs.exe )

This file may have to be configured as a process exclusion within the antivirus
software.
For more information about running antivirus software on servers that are running SQL
Server, see Configure antivirus software to work with SQL Server.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Changing the IP address of network
adapters in cluster server
Article • 12/26/2023

This article describes how to change the IP addresses of the network adapters in the
nodes of a cluster.

Applies to: Windows Server 2012 R2

Original KB number: 230356

More information
During this procedure, it's important that the cluster server maintains a connection to
the network. This is necessary so that it can communicate with a domain controller to
validate the cluster server Service account.

This article assumes that there are two nodes named A and B.

７ Note

For more information about clustered Microsoft SQL Server installations, click the
following article number to view the article in the Microsoft Knowledge Base:

244980 How to change the network IP addresses of SQL Server failover cluster
instances

1. Change the IP address of the network adapter on node A. This may require the
computer to be rebooted. If you're prompted to restart the computer, do so.

2. Start Cluster Administrator and open a connection to the cluster. To administer the
cluster, you need to open a connection to "." (without quotation marks) in Cluster
Administrator when you're prompted to do so. You must perform this process on
one of the nodes in the cluster. If you do this remotely, it may be possible to open
a connection to the name of the node itself. During this process, Cluster
Administrator may respond with the following error message:

A connection to the cluster at

cluster name could not be opened. This may be caused by the Cluster Service
on node cluster name not being started. Would you like Cluster Administrator
to attempt to start the Cluster Service on node cluster name?
 This occurs because Cluster Administrator attempts to connect to the last cluster it
administered.

3. Double-click the IP Address resource to open its properties.

4. On the Parameters tab in the IP Address resource properties, make sure that the
Network to Use box contains the new network as the network to use.

5. Fail all groups over to the functional node A.

6. Change the IP addresses for the network adapters in node B.

7. Reboot the computer.

8. When both nodes agree on the subnets, the old networks disappear and the new
networks are created.

9. You can rename the networks at this time.

You use "." to administer the cluster because the IP Address resource doesn't come
online when the Cluster service recognizes a new network and no longer uses the old
network.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Configure the Shadow Copies of Shared
Folders feature on a Windows Server
2003-based server cluster file share
Article • 12/26/2023

This article describes how to configure a Shadow Copies of Shared Folders target on a
server cluster in Microsoft Windows Server 2003.

Applies to: Windows Server 2003

Original KB number: 838421

Summary
Windows Server 2003 includes the Shadow Copies of Shared Folders feature to permit
you to revert to an earlier version of a specific file or a group of files in a folder.

Configure a shadow copy

To configure a shadow copy, you must first create a file share resource in your server
cluster by using the Cluster Administrator tool. Additionally, Microsoft recommends that
you add another hard disk to the same group that contains the file share resource. This
additional disk will function as the destination drive for shadow copy backups. For
additional information about how to create a file share on a Microsoft Windows 2000-
based server cluster, click the following article number to view the article in How to
create file shares on a cluster .

７ Note

Although you can use the same drive that contains your file share resource as the
destination drive for your shadow copies, for performance reasons, Microsoft
recommends that you use a separate physical hard disk drive.

） Important

You must assign a drive letter to the hard disk that you use for shadow copy
backups. If possible, avoid creating a shadow copy on a mount point. Setting
 shadow storage on a mount point in a cluster is supported on a server cluster in
Windows Server 2003.

When you configure shadow copies on the server cluster, a dependency is automatically
configured between the host drive and the destination drive. You do not have to
manually create this dependency. To configure shadow copies, follow these steps:

1. Click Start, right-click My Computer, and then click Manage.

2. Right-click Shared Folders, point to All Tasks, and then click Configure Shadow
Copies.

3. In the Select a volume list, click the drive that contains the file share resource that
you want to create a shadow copy for. For example, click drive R.

4. Click Settings, and then click the destination drive for the shadow copy in the
Located on this volume list.

７ Note

To appear in the Located on this volume list, the destination drive must
contain a share.

5. If you do not want to configure a limit to the size of the shadow copy, click No
limit.

6. Click OK, and then click Enable.

7. Click Yes to enable shadow copies.

７ Note

There may be a delay while the initial shadow copy is created.

8. Click OK.

When you enable shadow copies, the following behavior occurs:

The host drive becomes dependent on the destination drive.

A Volume Shadow Copy Service Task resource type is created in the resource
group that contains the drives that you created the shadow copy on. This resource
is used to synchronize shadow copy schedules.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Configure volume mount points on a
server cluster in Windows Server
Article • 12/26/2023

This article describes how to create volume mount points on a server cluster by using
the NTFS volume mount points functionality.

Applies to: Windows Server 2012 R2

Original KB number: 947021

Summary
By using volume mount points, you can graft or mount a target partition onto a folder
on another physical disk. You can also exceed the 26-letter limitation for drive letter
references.

You can use the following methods to add mount points in Windows Server.

７ Note

These methods are the same for clustered or nonclustered computers.

Use Logical Disk Manager (Diskmgmt.msc).

Use Mountvol.exe at a command prompt.
Write your own .exe file by using the Win32 SetVolumeMountPoint and
DeleteVolumeMountPoint functions.

More information
When you create a volume mount point on a Windows Server failover cluster, you must
consider the following key items:

A volume mount point cannot be created between clustered and nonclustered

disks.
You cannot create a volume mount point on the witness disk or on the disk that is
used for the "No Majority: Disk only" quorum type.
Volume mount points are transparent to programs.
How to set up volume mount points on the disks that are
not a resource in the cluster
1. Log on to the local computer by using administrative rights to the cluster node
that hosts both the mount point and the volume for the mount point.

2. On each node of the cluster, use the Disk Management console to make sure that
only one node has each disk in the "online" state. The disks should be online on
the same node and on only that node.

3. On the disk that will host the volume for the mount point, follow these steps:
a. In the middle pane of the Disk Management console, right-click the disk item
where the disk number is shown, and then click Online if the disk is not already
online.
b. Right-click the disk item again, and then click Initialize Disk if the disk is not
already initialized.
c. If the disk does not have a volume, complete steps 3d-3g. If the disk has a
volume, go to step 3h.
d. Right-click some unallocated space, and then click New Simple Volume.
e. When the New Simple Volume Wizard starts, click Next, enter the volume size,
and then click Next.
f. On the Assign Drive Letter or Path screen, assign a drive letter, and then click
Next.
g. Format the partition by using the NTFS file system, click Next, and then click
Finish.
h. If the volume does not have a drive letter, complete steps 3i-3j. If the volume
has a drive letter, go to step 4.
i. Right-click the disk, and then click Change Drive Letter and Paths.
j. Click Add, assign a drive letter, and then click OK.

4. On the disk that will host the mount point, follow these steps:
a. In the middle pane of the Disk Management console, right-click the disk item
where the disk number is shown, and then click Online if the disk is not already
online.
b. Right-click the disk item again, and then click Initialize Disk if the disk is not
already initialized.
c. If the disk does not have a volume, complete steps 4d-4i. If the disk has a
volume, go to step 4j.
d. Right-click some unallocated space, and then click New Simple Volume.
e. When the New Simple Volume Wizard starts, click Next.
f. Enter the volume size, and then click Next.
 g. On the Assign Drive Letter or Path screen, click Mount in the following empty
NTFS folder, and then click Browse.
h. Expand X:, where X represents the root drive that hosts the mount point. Select
an empty folder or create a new folder, click OK, and then click Next.
i. Format the partition by using the NTFS file system, click Next, and then click
Finish.
j. Make sure that the volume does not have a drive letter assigned to it.
k. Right-click the disk, click Change Drive Letter and Paths, and then click Add.
l. Click Mount in the following empty NTFS folder, and then click Browse.
m. Expand the root drive that hosts the volume for the mount point. Select an
empty folder, or create a new folder, and then click OK two times.

5. Follow these steps to add the following disks to the cluster:

The disk that contains the mount point

The disk that hosts the volume for the mount point

a. Open the Failover Cluster Management snap-in. To do this, click Start, click
Administrative Tools, and then click Failover Cluster Management. If the
User Account Control dialog box appears, confirm that the action that it
displays is what you want, and then click Continue.

b. In the navigation pane, click Storage.

c. In the Actions pane, click Add a Disk.

d. Select the disk that hosts both the mount point and the volume for the
mount point, and then click OK. Both disks now appear in the Available
Storage area of the storage pane.

e. Right-click the disk resource that hosts the mount point, and then click
Properties.

f. On the Dependencies tab, click the Resource column.

g. Click the root disk, click Apply, and then click OK. This dependency will
cause the resource to come online after the disk resource that hosts the
mount point is successfully brought online.

6. Right-click the newly added disk resources, and then click More actions.

7. Click Move this resource to Another Service or application to move the resource
to the appropriate application or service group.
How to set up volume mount points on the clustered
disks

７ Note

Follow these steps on the node on which the "Services and Applications"
group is hosted.
In these steps, volume N and volume Y already exist in the same "Cluster
Service and Application" group.
Volume N represents the volume that will host the mount point folder.
Volume Y represents the volume that is being mounted by the mount point.
Volume Y does not require an assigned drive letter before you follow these
steps.
If you receive a "parameter is incorrect" error message when you access Disk
Management on one of the nodes in your server cluster, exit Disk
Management, start Failover Cluster Manager, navigate to Storage, and then
put volume N into Maintenance Mode.

1. In the middle pane of the Disk Management console of the cluster node that owns
both volumes N and Y, right-click volume Y, and then click Change Drive Letter
and Paths.
2. Click Add, click Mount in the following empty NTFS folder, and then click Browse.
3. Click volume N, click New Folder, type a name for the new folder, and then click
OK two times to return to the Server Manager console.
4. Open the Failover Cluster Management console.
5. Test the mount point on each node by moving the "Service and Application" group
that holds both of the disk resources to each node. Make sure that the disks come
online on each node and that the information in the volume that was mounted can
be accessed through Windows Explorer or by using the command line and the "N:\
<mount point folder name>" path.

Best practices when you use volume mount points

Create a dependency in the mounted volume disk resource that specifies the disk
that is hosting the mount point folder. This makes the mounted volume dependent
on the host volume, and it makes sure that the host volume comes online first.

７ Note
 This practice is no longer necessary in Windows Server 2008 and later versions
of Windows.

If you move a mount point from one shared disk to another shared disk, make sure
that the shared disks are located in the same group.

Try to use the root (host) volume exclusively for mount points. The root volume is
the volume that hosts the mount points. This practice greatly reduces the time that
is required to restore access to the mounted volumes if you have to run the
Chkdsk.exe tool. This also reduces the time that is required to restore from backup
on the host volume.

If you use the root (host) volume exclusively for mount points, the size of the host
volume must be at least 5 megabytes (MB). This reduces the probability that the
volume will be used for anything other than the mount points.

In a cluster where high availability is important, you can make redundant mount
points on separate host volumes. This helps guarantee that if one root (host)
volume is inaccessible, you can still access the data that is located on the mounted
volume through the other mount point. For example, if HOST_VOL1 (D :) is located
on Mountpoint1, user data is located on LUN3. Then, if HOST_VOL2 (E:) is located
on Mountpoint1, user data is located on LUN3. Therefore, customers can access
LUN3 by using either D:\mountpoint1 or E:\mountpount1.

７ Note

Because the user data that is located on LUN3 depends on both the D and E
volumes, you must temporarily remove the dependency of any failed host
volume until the volume is back in service. Otherwise, the user data that is
located on LUN3 remains in a failed state.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to create file shares on a cluster
Article • 12/26/2023

This article describes how to create file shares on a cluster.

Applies to: Windows Server 2012 R2

Original KB number: 224967

Summary
To create highly available file shares on a cluster, you should create them using either
Cluster Administrator (CluAdmin.exe) or the cluster API set. When the share is placed in
a group with other related resources (IP Address, Network Name, and a storage device),
the share is available from whichever node in the cluster owns the group of resources.
This article lists basic steps for creating a basic File Share resource.

Steps to create a file share on a server cluster

To create a file share on a server cluster, follow these steps:

７ Note

The information in this article is also valid for the Windows 2000 Cluster service.

1. Open Windows Explorer and create a folder on a shared disk that you want to
share out for users.

2. Assign the appropriate NTFS file level permissions on the folder. Make sure that
the account used to start the Cluster Service has at least READ rights to the folder.

７ Note

Do not share the folder in Windows Explorer as you normally would for a file
share. If you do not grant the Cluster account the appropriate permissions or
share the folder through Windows Explorer, it may cause the cluster file share
to fail. This also includes any administrative shares that already exist, you do
not want to create shares for the root of the drive (Q$) for example.

3. Start Cluster Administrator (CluAdmin.exe).

4. Select a group that has an existing IP Address and Network Name resources. If you
do not have these resources created, you will need to complete this before
continuing.

5. Right-click and select New, then Resource.

6. Fill in an administrative name and description for the resource. From the Resource
Type pull down, select File Share, click Next.

７ Note

This is the name that will be displayed in Cluster Administrator and is only
used for administrative purposes. This is not the share name that users will
connect to, give the resource a name that will be easy to identify and manage.

7. Select the nodes that you want to be possible owners of the resource. Click Next
to leave all nodes as possible owners.

７ Note

Possible Owners defines whether a resource is ever able to failover to a

specific node. Use extreme caution in defining Possible Owners because
defining a possible owner for a single resource will affect the failover for the
entire group.

8. Select a Network Name and Physical Disk resource that the file share will be
dependent on.

７ Note

Dependencies serve two functions.

a. They define the bindings for a resource. You want the file share to be
dependent on the Network Name resource that clients are going to use when
connecting to the file share. The IP Address resource that the Network Name
resource is dependent upon is the IP Address that will be used when connecting
to this share. You never want a file share resource to be dependent on the
"Cluster Name" resource.

b. They define the start order for a resource. You want to make sure that the
network name that the share is going to be created under and the physical disk
 where the folder resides that is going to be shared are online and available
before attempting to bring the File Share online.

When creating a dependency 'Tree', it is best to keep it as simple as possible. A file

share resource should always be dependent on a Network Name that the clients
will use to connect to this share and Physical disk resource where the folder is
located. The Physical Disk resource should never be dependent on anything. The
Network Name resource should be dependent on an IP Address resource that the
virtual server will be associated with. The IP Address resource should not be
dependent on anything.

9. On the File Share Parameters screen, fill in the following information and click
Finish:

a. The "Share Name" is the name of the share that will be created for the UNC
when clients connect. This needs to be a valid NetBIOS name, and is
recommended to be a valid URL name as well.

b. The "Path" is the full path on the local node to the shared disk where the folder
is located. For example: T:\Users.

c. The "Comment" is the information about the share that will appear when a
client browses the share.

10. By default, when resources are created, they are in an offline state. The following
steps are a best practice. Follow them to isolate the effect of the resource failure
on other production resources. This will help until the resource is ready to be
brought into production for users.
a. Right-click the resource, and then click Properties.
b. Click the Advanced tab, click to select the Do not restart button, and then click
OK.
c. Bring the resource online. Make sure that it functions correctly.
d. After you confirm that the resource functions correctly, and you are ready to
bring it into production, take the resource offline. Then, click to select the
Restart button.
e. Bring the resource online.

７ Note

The User Limit dialog can be used to limit the number of simultaneous users.
Click the Permissions button to set share level permissions. Only domain level
groups should be used in defining share level permissions because local
 groups and user accounts do not reside on the other node, and the
permissions will not take effect when the file share is failed over. The only
exception to this is if all nodes in the cluster are domain controllers. It is
recommended to use NTFS permissions instead of share level permissions on
a server cluster.
The Advanced dialog can be used to create a Dynamic file share or a DFS
Root. The Advanced button was a feature that was added in Windows NT 4.0
Service Pack 4. If you are running Windows NT 4.0, but you do not see the
Advanced button, reapply Windows NT 4.0 Service Pack 4 or higher.

When browsing the file share, file shares for other virtual servers on the same cluster
may be visible. If you are going to create a large number of file share resources, it may
be easier to script the creation using Cluster.exe.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Enable support for Clustered Windows
Servers that use clustered RAID
controllers
Article • 12/26/2023

This article provides a solution to an issue where the validation may fail when you run a
cluster validation wizard for Windows Server-based Failover Cluster.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2839292

Symptoms
When you run a cluster validation wizard for Windows Server 2008 R2-based or
Windows Server 2012-based Failover Cluster, the validation may fail. Additionally, you
may receive an error message that resembles the following:

Disk bus type does not support clustering

Cause
This problem occurs if the shared storage type used by the system is Direct Attached
clustered RAID controllers.

Resolution
To resolve this problem, add a registry key that enables support for shared storage using
Direct Attached clustered RAID controllers.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .
To add the key to the registry, follow these steps:

1. Open Registry editor (regedit.exe).

2. Locate and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters

3. Right-click Parameters and then select New.

4. Select DWORD and give it a name of AllowBusTypeRAID.

5. Once the key is created, give it a value of 0x01.

6. Click OK.

7. Exit the Registry editor.

8. Restart the computer.

More information
For more information on validated solutions for Cluster in a Box Validation Kit, visit the
following article:

Windows Server Storage documentation

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 1222 when you create a
Windows Server 2012 failover cluster
Article • 12/26/2023

This article provides a solution to solve an issue where the event ID 1222 is logged when
you create a Windows Server 2012 failover cluster.

Applies to: Windows Server 2012 R2

Original KB number: 2770582

Symptoms
When you create a Windows Server 2012 failover cluster, the event ID 1222 is logged in
the System log.

Cause
When you create a Windows Server failover cluster, a Cluster Computer object for the
cluster name is created in Active Directory Domain Services (AD DS). The object is called
a Cluster Name Object (CNO).

A new feature in Windows Server 2012 flags Cluster Computer objects to prevent them
being deleted accidentally. If you do not have sufficient rights to the organizational unit
(OU) in AD DS where the Computer objects are being created, an event is logged that
notifies you that the cluster objects are not protected from accidental deletion.

Resolution
To resolve this issue, follow these steps:

1. Start Active Directory Administrative Center, and then select the tree view.
2. Select the CNO's organizational unit (OU).
3. Locate and right-click the CNO, and then click Properties.
4. Click to select the Protect from accidental deletion check box, and then click OK.

７ Note

Cluster Computer objects that are not protected from accidental deletion have no
adverse effect on the functionality of the cluster. If you are not concerned about
 the unintentional deletion of Cluster Computer objects, you can safely ignore this
warning.

More information
To improve the level of protection and ability to recover from the accidental deletion of
Custer Computer objects, we recommend that you enable the Active Directory Recycle
Bin feature. For more information about how to do this, go to the following websites:

Step-by-step guide to the Active Directory Recycle Bin feature

How to configure accounts in Active Directory

For more information about Cluster Computer Objects, go to the following MSDN
website:

How to identify stale Cluster Computer objects

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to extend the partition of a cluster
shared disk
Article • 12/26/2023

This article describes how to add additional storage capacity to a cluster if the
underlying hardware RAID supports capacity extension technology.

Applies to: Windows Server 2012 R2

Original KB number: 304736

Summary
Capacity extension provides the ability to add additional drives to an existing RAID set
and extend the logical drive so that it appears as free space at the end of the same
logical drive. You can use the Diskpart.exe command-line utility to extend an existing
partition into free space. This process has the following requirements:

The additional disk space must appear as free space at the end of the existing
drive, and it must be directly behind the existing volume that is to be extended.
The extension mustn't rely on software fault tolerance to combine the existing
partition and free space.
The disk signatures of the existing drive remain the same.
Use of the Physical Disk Resource type for the disk. If the disk resource is provided
by a third-party manufacturer, you must contact that manufacturer for information
about how to increase disk space.

More information

） Important

If you add an additional drive to an existing array and the new drive appears as a
new logical disk (instead of free space at the end of the existing drive), the
hardware doesn't support capacity extension because it refers to the free space as a
new drive, and the following procedure won't work. Some storage hardware will, by
default, automatically create a new logical disk and volume for the new space
despite the fact that the expansion of the existing logical disk is a possible option.
When you are using server clusters of Windows Server 2003 or failover clusters of
Windows Server 2008 or of Windows Server 2008 R2, software fault tolerance isn't
 natively supported, and the creation of a spanned volume (Volume Set) isn't a
viable option. To add additional space:

Create a second physical disk resource.

Delete and then re-create the array with the additional disk, and then replace
the disk.

How to extend an existing drive into free space

if the Hardware Supports Capacity Extension
You can do an online extension or an offline extension of a data volume.

How to do an online extension of a data volume

You can do an online extension of a cluster data volume in Windows Server 2008 or in
Windows Server 2008 R2 without stopping the cluster application(s). However, not all
vendor-specific applications, drivers, and utilities for Windows Server 2003 fully support
transparent online extension of cluster volumes. So we recommend that you test the
specific hardware environment and hardware configuration to confirm that it will behave
correctly before you do the online extension in Windows Server 2003.

To do an online extension of the disk partition, follow these steps:

1. Add the additional physical drives and extend the additional disk or disks as free
space by using the instructions that are included with the hardware vendor
documentation.

2. Open the Disk Management snap-in, verify that the new free space is added to the
end of the proper drive.

3. Right-click the existing partition, and then select Properties. On the General tab,
type a unique name for the partition. This name will be used to identify the
partition that you want to extend.

７ Note

If you encounter any problem with the previous steps when you are extending
the drive, contact your hardware vendor for assistance.

4. Extend the partition by using one of the following methods:

 Use the Disk Management snap-in in Windows Server 2008 R2

To extend the partition by using the Disk Management snap-in, follow these
steps:
a. In Disk Management, right-click the data volume that you want to extend.
b. Select Extend Volume.....
c. Follow the instructions in the Extend Volume Wizard.

７ Note

Windows Vista and Windows Server 2008 doesn't allow Disk

Management snap-in to Extend volume and user should use diskpart to
extend volume instead.

Use the Diskpart.exe utility

To extend the partition by using the Diskpart.exe utility, follow these steps:
a. Open a command prompt, type diskpart, and then press ENTER.
b. At the DISKPART prompt, type list volume, and then press ENTER to
display the existing volumes on the computer.
c. At the DISKPART prompt, type select volume <volume number>, and then
press ENTER. Here volume number is the number of the volume that you
want to extend. The volume has the unique name that you created in step
3. The volume is listed in the output of the list volume command.
d. At the DISKPART prompt, type extend, and then press ENTER to extend the
partition into all of the available disk space to the end of the drive. Or,
type extend size=<size> to extend the selected volume by size megabytes
(MB).
e. Type exit, and then press ENTER to exit the command prompt.

How to do an offline extension of a data volume

To do an offline extension of the disk partition in Windows Server 2003, follow these
steps:

1. Back up the shared disk (or disks) that you want to extend.

2. Power off all but one node in the cluster.

3. Take the entire group that the physical disk resource is located in offline. Bring only
the physical disk resource that is to be extended online. This process should close
all open handles to the disk.
 ７ Note

If you have any disk or Host Bus Adapter (HBA) utilities that access the disk,
you may need to quit them or stop the services so that they will release any
handles to the disk.

4. Add the additional physical drives and extend the additional disk or disks as free
space by using the instructions that are included with the hardware vendor
documentation.

5. Open the Disk Management snap-in, verify that the new free space is added to the
end of the proper drive.

6. Right-click the existing partition, and then select Properties. On the General tab,
type a unique name for the partition. This name will be used to identify the
partition that you want to extend. Exit Disk Management snap-in.

７ Note

If you encounter any problem with the previous steps when you are extending
the drive, contact your hardware vendor for assistance.

7. Open a command prompt, type diskpart, and then press ENTER.

8. At the DISKPART prompt, type list volume, and then press ENTER to display the
existing volumes on the computer.

9. At the DISKPART prompt, type select volume <volume number>, and then press
ENTER. Here volume number is the number of the volume that you want to extend.
The volume has the unique name that you created in step 6. The volume is listed in
the output of the list volume command.

10. At the DISKPART prompt, type extend, and then press ENTER to extend the
partition into all of the available disk space to the end of the drive. Or, type extend
size=<size> to extend the selected volume by size megabytes (MB).

11. Type exit, and then press ENTER to exit the command prompt.

12. Now that the volume is extended, you can bring the entire group that contains the
physical disk resource online, and then power up all of the other nodes in the
cluster.

13. Verify that the group can come online and failover to all other nodes in the cluster.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unable to manage cluster using failover
cluster manager. Error Received:
"Connection to the cluster is not
allowed since you are not an
administrator on the cluster node(s)"
Article • 12/26/2023

This article provides a solution to fix an error that you receive when managing cluster by
using failover cluster management console.

Applies to: Windows Server 2012 R2

Original KB number: 2462468

Symptoms
While managing cluster using failover cluster management console, we receive the
following error:

Error
The operation has failed.
An error occurred connecting to the cluster '.'.

[Expanded Information]
An error occurred trying to display the cluster information.
Connection to the cluster is not allowed since you are not an administrator on the
cluster node(s) (Node name)

or

When you run the Cluster validation, you receive the following error:
 Unable to determine if you have administrator privileges on server "Node name" .
Ensure sure that the server service and remote registry services are enabled, and
that the firewall is properly configured for remote access.

Managing cluster using command prompt will still work and will be able to list groups
(cluster group), resources (cluster. res) and even be able to do failover of groups (cluster
group "cluster group" /move) but will error out while managing cluster using GUI
(Failover Cluster Management console).

７ Note

Command to list group & resources, move group are given in bracket.

Cause
This issue occurs if you have server service not started on the node that is shown in the
error. Expand the error to check node name. Additionally, you may get above
mentioned issue due to incorrect protocol enabled which are required for Microsoft
clustering.

Resolution
Open services console and start the Server service.

Ensure the cluster network has both the mentioned below protocol checked:

1. Client for Microsoft networks

2. File and printer sharing for Microsoft networks

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How the Cluster service reserves a disk
and brings a disk online
Article • 12/26/2023

This article describes how the Microsoft Cluster service reserves and brings online disks
that are managed by cluster service and related drivers.

Applies to: Windows Server 2003

Original KB number: 309186

More information
The Cluster service only uses the SCSI protocol to manage disks on the shared bus.

７ Note

This does not mean that all disks will be of type SCSI, specifying the hardware
interface known as SCSI, but rather that the storage unit must be able to properly
interpret and process the SCSI protocol and commands.

The following list of commands is the additional SCSI protocol features that will be used
when disks are in a clustered environment.

reserve : This command is issued by a host bus adapter to obtain or maintain

ownership of a SCSI device. A device that is reserved refuses all commands from all
other host bus adapters except the one that initially reserved it, the initiator.

release : This command is issued by the owning host bus adapter when a disk

resource is taken offline; it frees a SCSI device for another host bus adapter to
reserve.

reset : This command breaks the reservation on a target device. This command

can either be a bus reset (for the entire bus) or, using the storport drivers a
targeted reset for a particular device on the bus. The following procedure
describes how a server cluster starts and gains control of the shared disks. This
scenario assumes that only one node is being turned on at a time:

When the computer is started, the Cluster Disk Driver (Clusdisk.sys) reads the following
local registry key to obtain a list of the signatures of the shared disks under cluster
management:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters
\Signatures

After the list is obtained, the cluster service attempts to scan all of the devices on the
shared SCSI bus to find matching disk signatures.

When the first node in the cluster starts, the cluster disk driver first marks all LUNs (LUN:
logical unit number, a unique identifier used on a SCSI bus to distinguish between
devices that share the same bus) matching the Signatures key as offline volumes. Note
that this is not the same as taking a cluster resource offline. The volume is marked
offline to prevent multiple nodes from having write access to the volumes
simultaneously. If the cluster is a shared disk cluster, one of the disks is designated as
quorum disk by the cluster service. Quorum disk is the first resource brought online
when cluster service attempts to form a cluster.

When the cluster service on the forming node starts, it first tries to bring online the
physical device designated as quorum disk. It executes the disk arbitration algorithm on
the quorum disk to gain ownership. On successful arbitration, cluster service sends a
request to clusdisk to start sending periodic reserves to the disk (to maintain
ownership). Then cluster service sends a request to clusdisk to unblock access to the
quorum disk and mounts the volumes on the disk. Successful mounting of the
volume(s), completes the online procedure and the cluster service then continues with
the cluster form process. The request is passed from the cluster disk driver to the
Microsoft storage driver stack and finally to the driver specific to the HBA that
communicates to the disks. It may also be passed to any multipath software running in
the storage stack.

After the storage controller/device driver reports that the device has been successfully
reserved, the cluster service ensures that the drive can be read from and written to.
Once the disk has passed all of these tests, the disk resource is marked as online and the
cluster service then continues to bring all other resources online.

Each node in the cluster renews reservations for any LUNs it owns every three seconds. If
the nodes of a cluster lose network communication with each other (for example, if
there is no communication over the private or public network), the nodes begin a
process known as arbitration to determine ownership of the quorum disk. The node that
wins ownership of the quorum disk resources in total communication loss between
cluster node will remain functional. Any nodes that cannot communicate and cannot
maintain or acquire ownership of the quorum disk will terminate the cluster service and
any resources that node was hosting will be moved to another node in the cluster.

1. The node that currently owns the quorum disk is the defending node. The
defender assumes that it is defending against any cluster nodes that it cannot
 communicate with and for which it did not receive a shutdown notification. The
defender continually renews its reservation to the quorum by requesting a SCSI
reserve be placed on the LUN every three seconds.

2. All other nodes (nodes that do not own the quorum disk and cannot communicate
with the node that owns the quorum resource) become challenging nodes.

3. When the challenger detects the loss of all communications, it immediately

requests a bus-wide SCSI reset to break any existing reservations.

4. Seven seconds after the SCSI reset requested, the challenger tries to reserve the
quorum disk. If the defender node is online and functioning, it will have already
reserved the quorum disk as it typically does every three seconds. The challenger
detects that it cannot reserve the quorum, and terminates the cluster service. If the
defender is not functioning properly, the challenger can successfully reserve the
quorum disk. After ten seconds, the challenger brings the quorum online and takes
ownership of all resources in the cluster. If the defending node loses ownership of
the quorum device, then the cluster service on the defending node terminates
immediately.

When a cluster node takes a disk resource offline, it requests that the SCSI reserve be
released and then the drive will once again be unavailable to the operating system.
Anytime a disk resource is offline in a cluster, the volume that the resource points to
(the disk with the matching signature) will be inaccessible to the operating system on
any of the cluster nodes.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure FTP for IIS in a
Windows Server failover cluster
Article • 12/26/2023

This article describes how to configure FTP for Internet Information Services (IIS) 8.0 or a
later version in a Windows Server failover cluster. The procedures in this article apply
only to the FTP service.

７ Note

For more information about how to configure Web services in a failover cluster,
click the following article number to view the article in the Microsoft Knowledge
Base:

970759 Configuring IIS World Wide Web Publishing Service in a Windows Server
failover cluster

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 974603

Configure high availability for IIS FTP servers

using Failover Clustering
1. Install the Web Server role on all cluster nodes. If you're installing on Windows
Server 2012, don't include the "FTP Server" role. If you're installing on Windows
Server 2012 R2 or a later version, include the in-box "FTP Server" role. For more
information about IIS 8 deployment guide, visit the following website: Open IIS
Manager (IIS 8)

2. Install the Failover Clustering feature on all cluster nodes and create the cluster. For
more information, visit the following website: Failover Cluster Deployment Guide

3. Set up a file share that will be used for IIS Shared Configuration.

4. Configure IIS Shared Configuration on all cluster nodes.

5. Configure Offline Files for IIS Shared Configuration on all cluster nodes.

6. Configure the FTP site and specify the location of its content on one cluster node.
 7. Configure highly availability for your FTP site by creating a generic script in Failover
Clustering.

Set up a file share that will be used for IIS

shared configuration
1. Create a user who will access the share that will be used for the IIS shared
configuration.

2. Create the file share. This share will be used to store the IIS shared configuration
that will be shared between IIS on all cluster nodes. There are multiple options:

On a stand-alone server that's not part of any failover cluster, create a file
share.

On another Windows Server failover cluster, create a high availability file

share. For more information, visit the following Microsoft website: Failover
Cluster Step-by-Step Guide: Configuring a Two-Node File Server Failover
Cluster

On the same failover cluster that will host the high availability FTP site, create
a high availability file share. For more information, visit the following
Microsoft website: Failover Cluster Step-by-Step Guide: Configuring a Two-
Node File Server Failover Cluster

3. Set the permissions on the share that you created in step 2. Give the user whom
you created in step 1 Full Control permissions to the file share and NTFS
permissions.

4. Confirm that all cluster nodes can browse to the file share. The path of the file
share is \\<fileservername>\<sharename> .

Configure the IIS shared configuration on all

cluster nodes
On one of the cluster nodes, export the shared configuration to the file share:

1. Navigate to Administrative Tools, and then select Internet Information Services

(IIS) Manager.
2. In the left pane, select the server name node.
3. Double-click the Shared Configuration icon.
 4. On the Shared Configuration page, select Export Configuration in the Actions
pane (the right pane) to export the configuration files from the local computer to
another location.
5. In the Export Configuration dialog box, type the path of the file share ( \\
<fileservername>\<sharename> ) in the Physical path box.

6. Select Connect As, and then type the user name and the password for the user
account that has access to the share in which the shared configuration is stored,
and then select OK. This account will be used to access the share. You should use a
restricted Active Directory account that's not the domain administrator.
7. In the Export Configuration dialog box, type a password that will be used to
protect the encryption keys, and then select OK.
8. On the Shared Configuration page, select the Enable shared configuration check
box.
9. Type the physical path, the user account, and the password that you entered
previously, and then select Apply in the Actions pane.
10. In the Encryption Keys Password dialog box, type the encryption key password
that you set earlier, and then select OK.
11. In the Shared Configuration dialog box, select OK.
12. Select OK.

On each of the other cluster nodes, use the shared configuration that you just exported
to the file share:

1. Navigate to Administrative Tools, and then select Internet Information Services

(IIS) Manager.
2. Select the server name node.
3. Double-click the Shared Configuration icon.
4. On the Shared Configuration page, select the Enable shared configuration check
box.
5. Type the physical path of the file share ( \\<fileservername>\<sharename> ), the user
account, and the password that you entered previously, and then select Apply in
the Actions pane.
6. In the Encryption Keys Password dialog box, type the encryption key password
that you set earlier, and then select OK.
7. In the Shared Configuration dialog box, select OK.
8. Select OK.

７ Note
 For more information about how to set up shared configurations in IIS, visit the
following Microsoft website: Shared Configuration

Configure Offline Files for IIS Shared

Configuration on all cluster nodes
On each cluster node, enable Offline Files:

1. Install the Desktop Experience feature. To do this, follow these steps:

a. Navigate to Administrative Tools, and then select Server Manager.
b. In the left pane, select Features.
c. Select Add Features in the right pane.
d. Do one of the following, as appropriate for your Windows version:

For Windows Server 2016, review Install Server with Desktop Experience.
For Windows Server 2102 and 2012 R2, choose Desktop Experience under
User Interfaces and Infrastructures in the features list

2. Do the following:
For Windows Server 2012, 2012 R2 and 2016, select Sync Center in Control Panel,
and then select Manage offline files.

3. Select Enable Offline Files. Don't restart the computer at this point.

4. Ensure that the cache is set to read-only. To do this, run the following command at
an elevated cmd prompt:

Console

REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v

ReadOnlyCache /t REG_DWORD /d 1 /f

5. Restart the computer.

6. Browse to the file server from the computer. Right-click the share that contains the
IIS shared configuration, and then select Always Available Offline.

７ Note

If you set up the file share to be highly available on the same failover cluster
that hosts IIS nodes, the Always Available Offline option will not appear when
you right-click the share if the cluster node that you are on is hosting the
 highly available file server. You will have to move the high available file server
application to another node.

7. In Control Panel, open Offline Files. Select Open Sync Center, and then select
Schedule.

8. Schedule an offline file sync for every day or according to your requirements. You
can also configure the offline sync to run every few minutes. Even if you don't set
up a scheduler, when you change something in the Applicationhost.config file, the
change is reflected on the Web server.

７ Note

For more information about how to configure offline files for a shared
configuration in IIS, see Offline Files for Shared Configuration.

Configure the FTP site and specify the location

of its content on one cluster node
Find the cluster node that owns the cluster disk resource where the FTP site content files
will reside:

1. Navigate to Administrative Tools, and then select Failover Cluster Manager.

2. Connect to the cluster. If you are on one of the cluster nodes, the cluster will
appear on the list automatically.
3. Under "Storage," find the disk resource on which the FTP site content will reside. To
do this, expand the storage tree for the disk resource. Make sure that the storage
isn't used by any other high availability application on the cluster. You'll find the
storage under "Available Storage."
4. Note the cluster node on which this resource is online. You'll configure IIS on that
cluster node.
5. Note the cluster disk resource name. You'll use this for the content files.

On the cluster node on which the resource is online, configure the FTP server to use the
shared disk for FTP site content:

1. Navigate to Administrative Tools, and then select Internet Information Services

(IIS) Manager.
2. In the left pane, expand the server name node.
3. Expand Sites, right-click Sites, and then select Add FTP Site.
 4. In the Add FTP Site dialog box, type the site name. For the content directory, type
the location where the FTP site content files are located. This is the location of the
cluster disk resource that you noted in step 5 of the previous procedure.
5. Configure remaining FTP site settings.
6. Select Finish.

Configure high availability for your FTP site by

creating a generic script in Failover Cluster
Manager
For the last step to configure high availability for FTP site, set up the generic script
resource that will be used to monitor the FTP service:

1. On each cluster node, copy the script at the end of this article to
Windows\System32\inetsrv\Clusftp7.vbs .

2. Navigate to Administrative Tools, and then select Failover Cluster Manager.

3. Connect to the cluster. If you are on one of the cluster nodes, the cluster will
appear on the list automatically.
4. Do the following:
For Windows Server 2012, 2012 R2 and 2016, right-click Roles and then select
Configure Role to create it.
5. Click Generic Script.
6. Select the script file from the following path:
%systemroot%\System32\Inetsrv\Clusftp7.vbs

7. Set the Client Access Point (CAP) name to the FTP site name that clients will use to
connect to the high availability FTP site. Specify the static IPs to use for the FTP site
CAP. If you're using Dynamic Host Configuration Protocol (DHCP), this option
won't be displayed.
8. In the Select Storage step, select the cluster shared disk on which the FTP site
content files reside. The storage should be unused by any other high availability
application on the cluster. If the file share that is used for the IIS shared
configuration is hosted on the same cluster, a different disk resource should be
used here.
9. After you confirm the settings, the wizard will create the cluster group, cluster
resources, and the dependencies between the resources, and then bring the
resources online.

７ Note
To host multiple high availability FTP sites on the same failover cluster, follow the
same steps that are mentioned earlier. You can point to the same script file for all
FTP sites on the cluster if you did not customize the script. However, if you make
changes that are specific to the individual FTP sites, use a different script file for
each FTP site and different clustered shared storage. For example, in
%systemroot%\System32\Inetsrv, useClusftp7.vbs for the first FTP site,Clftp7-

2.vbsfor the second,Clftp7-3.vbsfor the third, and so on. Each script file monitors a
different FTP site.

） Important

The following script is for sample purposes only and is not explicitly supported by
Microsoft. Use of this script in an IIS 8.0 FTP clustered environment is done at your
own risk.

Visual Basic Script

'<begin script sample>

'This script provides high availability for IIS FTP websites

'The script is applicable to:
' - Windows Server 2012: Microsoft FTP Service 7.5 for IIS 8.0 (available
for download from microsoft.com)
' - Windows Server 2012 R2 or a later version: FTP Service in the box

'More thorough and application-specific health monitoring logic can be added

to the script if needed

Option Explicit

'Helper script functions

'Start the FTP service on this node

Function StartFTPSVC()

Dim objWmiProvider
Dim objService
Dim strServiceState
Dim response

'Check to see if the service is running

set objWmiProvider = GetObject("winmgmts:/root/cimv2")
set objService = objWmiProvider.get("win32_service='ftpsvc'")
 strServiceState = objService.state

If ucase(strServiceState) = "RUNNING" Then

StartFTPSVC = True
Else
'If the service is not running, try to start it
response = objService.StartService()

'response = 0 or 10 indicates that the request to start was

accepted
If ( response <> 0 ) and ( response <> 10 ) Then
StartFTPSVC = False
Else
StartFTPSVC = True
End If
End If

End Function

'Cluster resource entry points. More details here:

'http://msdn.microsoft.com/en-us/library/aa372846(VS.85).aspx

'Cluster resource Online entry point

'Make sure the FTP service is started
Function Online( )

Dim bOnline
'Make sure FTP service is started
bOnline = StartFTPSVC()

If bOnline <> True Then

Resource.LogInformation "The resource failed to come online because
ftpsvc could not be started."
Online = False
Exit Function
End If

Online = true

End Function

'Cluster resource offline entry point

'On offline, do nothing.
Function Offline( )

Offline = true

End Function

'Cluster resource LooksAlive entry point

'Check for the state of the FTP service
Function LooksAlive( )

Dim objWmiProvider
 Dim objService
Dim strServiceState

set objWmiProvider = GetObject("winmgmts:/root/cimv2")

set objService = objWmiProvider.get("win32_service='ftpsvc'")
strServiceState = objService.state

if ucase(strServiceState) = "RUNNING" Then

LooksAlive = True
Else
LooksAlive = False
End If

End Function

'Cluster resource IsAlive entry point

'Do the same health checks as LooksAlive
'If a more thorough than what we do in LooksAlive is required, this should
be performed here
Function IsAlive()

IsAlive = LooksAlive

End Function

'Cluster resource Open entry point

Function Open()

Open = true

End Function

'Cluster resource Close entry point

Function Close()

Close = true

End Function

'Cluster resource Terminate entry point

Function Terminate()

Terminate = true

End Function

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Microsoft support policy for Windows
server failover clusters
Article • 12/26/2023

This article describes Microsoft support policy for Windows Server 2012 or Windows
Server 2012 R2 failover clusters implementation.

Applies to: Windows Server 2012 R2

Original KB number: 2775067

Introduction
Microsoft Customer Service and Support supports Windows Server 2012 or Windows
Server 2012 R2 failover clusters that meet the following criteria:

All hardware and software components in the failover cluster meet the
qualifications to receive at least one of the following Windows Server 2012 or
Windows Server 2012 R2 logos:

Certified for Windows Server 2012 or Windows Server 2012 R2 Devices

This logo is designed for line-of-business and mission-critical hardware and

software and demonstrates that a hardware or software component meets the
highest technical bar for Windows fundamentals and platform compatibility that
is set by Microsoft.

Certified Windows Server 2012 or Windows Server 2012 R2 Systems

This logo is designed for cloud and infrastructure hardware and software. The
Certified for Windows Server 2012 or Windows Server 2012 R2 logo
demonstrates that a server system meets the security, reliability, and
manageability requirements of Microsoft products. Additionally, the logo
demonstrates that a server system supports all the roles, features, and interfaces
that Windows Server 2012 or Windows Server 2012 R2 supports.

The fully configured failover cluster passes all required failover cluster validation
tests. To validate a failover cluster, run the Validate a Configuration Wizard in the
Failover Cluster Manager snap-in, or run the Windows PowerShell cmdlet Test-
Cluster .
Changes in Windows Server 2012 or Windows
Server 2012 R2
Before you create a cluster, run a failover cluster validation test on fully configured
hardware that is running Windows Server 2012 or Windows Server 2012 R2. The failover
cluster validation test identifies potential hardware and software configuration issues.
Run the failover cluster validation test on hardware and software that is certified under
the Windows Server Logo Program for Windows Server 2012 or Windows Server 2012
R2.

To configure a failover cluster in Windows Server 2012 or Windows Server 2012 R2, the
failover cluster must pass the required failover cluster validation tests. The failover
cluster validation tests perform the following functions on the collection of servers that
you intended to use as a cluster:

Hardware and Software inventory

Network analysis
Storage tests
System configuration

By default, if the failover cluster validation tests recognize that one or more nodes
already exist in a cluster, the cluster configuration function is performed. Also, if the
failover cluster validation tests recognize that one or more nodes have the Hyper-V role
installed, the Hyper-V configuration function is performed.

For a more information about how to validate hardware for a Windows Server 2012 or
Windows Server 2012 R2 failover cluster, go to the following Microsoft website:

Validate Hardware for a Failover Cluster

７ Note

All reports that the Validate a Configuration Wizard in the Failover Cluster Manager
snap-in generates are stored in the %systemroot%\cluster\Reports folder.

Run the failover cluster validation tests on a fully configured failover cluster before you
install the Failover Clustering feature. The failover cluster is valid if it receives one of the
following indicators for each test in the Summary Report:

A green check mark (passed)

A yellow yield sign (warning)

 ７ Note

The yellow yield sign indicates that the aspect of the proposed failover cluster
that is being tested is not in alignment with Microsoft best practices.
Investigate this aspect to make sure that the configuration of the cluster is
acceptable for the environment of the cluster, for the requirements of the
cluster, and for the roles that the cluster hosts.

A red circle with single bar (canceled)

If a failover cluster receives a red "X" (fail) in one of the tests, you cannot use the part of
the failover cluster that failed in a Windows Server 2012 or Windows Server 2012 R2
failover cluster. Additionally, if a test fails, all other tests do not run, and you must
resolve the issue before you install the failover cluster.

Run the validation tests when a major component of the cluster is changed or updated.
For example, run the validation tests when you make the following configuration
changes to the failover cluster:

Add a node to the cluster

Upgrade or replace the storage hardware
Upgrade the firmware or the driver for host bus adapters (HBAs)
Update the multipathing software or the version of the device specific module
(DSM)
Change or update a network adapter

Microsoft Support may also request that you run the validation tests against a
production cluster. When you do this, the failover cluster validation tests perform a
hardware and software inventory, test the network, validate the system configuration,
and perform other relevant tests. In some scenarios, you can run only a subset of the
tests. For example, when troubleshooting a problem with networking, Microsoft Support
may request that you run only the hardware and the software inventory and the
networking test against the production cluster.

When an underlying storage configuration change or problem causes a cluster storage

failure, Microsoft Support may also request that you run the validation tests on
production clusters. The relevant disk resources and the resources on which the disks
depend are taken offline during the test. Therefore, run the validation tests when the
production environment is not being used.

７ Note
 The ability to specify one or more disks to be included in the failover cluster
validation tests is added in Windows Server 2012 or Windows Server 2012 R2.

For more information about advanced failover cluster validation scenarios, go to the
following Microsoft website:

Validate Hardware for a Failover Cluster

More information
Microsoft supports the failover clusters that are listed under Cluster Solutions on the
Windows Server Catalog for the following versions of Windows Server:

Windows Server 2008 R2 Datacenter

Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Itanium-based Systems
Windows Server 2008 Datacenter
Windows Server 2008 Enterprise
Windows Server 2008 Itanium-based Systems
Windows Server 2003 Datacenter Server
Windows Server 2003 Enterprise Edition
Windows Server 2003 Advanced Server

For more information about the Windows Server Catalog, see Windows Server
Catalog .

For more information about failover clustering, see Failover Clustering Overview.

For more information about the Microsoft support policy for earlier operating systems,
click the following article numbers to view the articles in the Microsoft Knowledge Base:

309395 The Microsoft support policy for server clusters, the Hardware
Compatibility List, and the Windows Server Catalog

943984 The Microsoft Support Policy for Windows Server 2008 or Windows
Server 2008 R2 Failover Clusters

Feedback
Was this page helpful?  Yes  No
Provide product feedback
NetBIOS and WINS don't bind to cluster
IP address resources
Article • 12/26/2023

This article provides a workaround for an issue where NetBIOS and WINS don't bind to
cluster IP address resources.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4556018

Symptoms
Assume that you have an environment in which cluster servers are running Windows
Server 2016 or a later version of Windows. You notice the following issues:

Issue 1

Applications that depend on NetBIOS (TCP port 139) connectivity to cluster

resources cannot connect to the Cluster service.

Issue 2

The WINS name resolution service does not respond to incoming queries or
registration requests on cluster networks.

Cause
This behavior is by design. It occurs because NetBIOS no longer binds to IP address
resources in Windows Server 2016 or later versions of the Windows Server-based Cluster
service.

Workaround
To work around this behavior, use the Cluster Management console to determine the
name of the IP address resource that must be changed.
After you determine the IP address resource, run the following commands in an elevated
PowerShell window. In the commands, substitute the name of the actual IP address
resource.

PowerShell
 Get-ClusterResource"resource name"| Set-ClusterParameter EnableNetBIOS 1
Stop-ClusterResource"resource name"
Start-ClusterResource"resource name"

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommended private heartbeat
configuration on a cluster server
Article • 12/26/2023

This article describes recommended configuration for the private adapter on a cluster
server.

Applies to: Windows Server 2003

Original KB number: 258750

Summary
Communication between Server Cluster nodes is critical for smooth cluster operations.
Therefore, you must configure the networks that you use for cluster communication are
configured optimally and follow all hardware compatibility list requirements. For
networking configuration, two or more independent networks must connect the nodes
of a cluster to avoid a single point of failure. The use of two local area networks (LANs)
is typical. (Microsoft Product Support Services does not support the configuration of a
cluster with nodes connected by only one network.)

At least two of the cluster networks must be configured to support heartbeat

communication between the cluster nodes to avoid a single point of failure. To do so,
configure the roles of these networks as either "Internal Cluster Communications Only"
or "All Communications" for the Cluster service. Typically, one of these networks is a
private interconnect dedicated to internal cluster communication.

Additionally, each cluster network must fail independently of all other cluster networks.
This means that two cluster networks must not have a component in common that can
cause both to fail simultaneously. For example, the use of a multiport network adapter
to attach a node to two cluster networks would not satisfy this requirement in most
cases because the ports are not independent.

To eliminate possible communication issues, remove all unnecessary network traffic

from the network adapter that is set to Internal Cluster communications only (this
adapter is also known as the heartbeat or private network adapter). Clustering
communicates by using Remote Procedure Call (RPC) calls on IP sockets with User
Datagram Protocol (UDP) packets. The process described in this article:

Removes NetBIOS from the interconnect.

Sets the proper Cluster communication priority order.
 Sets the proper adapter binding order.
Defines the proper network adapter speed and mode.
Configures TCP/IP correctly.
Disable the Media Sense feature (in Windows 2000 only).

７ Note

The information in this article does not apply to Windows Server 2008 or Windows
Server 2008 R2 failover clusters. The recommendations for network configuration
for the newer versions of Failover Cluster in non-CSV environments are noted at
Appendix A: Failover Cluster Requirements. The scenario where the settings in this
article are likely to cause adverse behavior on Windows Server 2008 or Windows
Server 2008 R2, is with a CSV environment. Recommendations with CSV is located
at Requirements for Using Cluster Shared Volumes in a Failover Cluster in
Windows Server 2008 R2.

Recommended configuration for the private

adapter in Windows 2000 and Windows 2003
1. Click Start, point to Settings, click Control Panel, and then double-click Network
and Dial-up Connections.

2. On the Advanced menu, click Advanced Settings.

3. In the Connections box, make sure that your bindings are in the following order,
and then click OK:

External public network

Internal private network (Heartbeat)
[Remote Access Connections]

4. Right-click the network connection for your heartbeat adapter, and then click
Properties.

７ Note

You may want to rename this connection for simplicity (for example, rename it
to "Private").

5. Use one of the following procedures:

 If the server is using a quorum type other than Majority Node Set (MNS), click
to select Internet Protocol (TCP/IP), and then click to clear all other options.

If the server is using a MNS quorum, click to select Internet Protocol (TCP/IP)
and at least one other file-sharing network protocol, and then click to clear all
other options.

７ Note

If the server is using a MNS quorum, you must have at least one network that
has file-sharing capabilities for the MNS quorum to function. We strongly
recommend that you have multiple networks on the cluster that have file
sharing enabled to avoid a single point of failure for the quorum resource.

6. If you have a network adapter that can transmit at multiple speeds, and the
adapter can specify a speed and duplex mode, manually specify a speed and
duplex mode.

With network adapters that can manually specify a speed and duplex mode, make
sure that you hard set them to the same on all nodes and according to the
manufacturers' specifications. For network adapters that do not support manual
settings, follow the card manufacturer's specifications.

The information that is traveling across the heartbeat network is small, but latency
is critical for communication. If you have the same the speed and duplex settings,
this helps to make sure that you have reliable communication.

If you are not sure of the supported speed of your card and connecting devices, or
your manufacturer's recommended settings, Microsoft recommends that you set
all the devices on that path of 10 MB/Sec and Half Duplex. This configuration will
provide sufficient bandwidth and reliable communication.

７ Note

Microsoft does not recommend the use of any type of fault-tolerant adapter
or "Teaming" for the heartbeat. If you require redundancy for your heartbeat
connection, use multiple network adapters set to Internal Communication
Only and define their network priority in the Cluster configuration. Issues seen
with early multi-ported network adapters, verify that your firmware and driver
are at the most current revision if you use this technology.
 Contact your network adapter manufacturer for information about compatibility
on a Server Cluster.

7. Click Internet Protocol (TCP/IP), and then click Properties.

8. On the General tab, verify that you have selected a static IP address that is not on
the same subnet or network as another one of the public network adapters. An
example of good IP addresses to use for the private adapters is 10.10.10.10 on
node 1 and 10.10.10.11 on node 2 with a subnet mask of 255.0.0.0. If your public
network uses the 10.x.x.x network and 255.0.0.0 subnet mask, use an alternate
private network IP and subnet.

9. Make sure that there is no value set in the Default Gateway box.

10. Verify that there are no values defined in the Use the following DNS server
addresses box.

７ Note

If the cluster nodes are also DNS servers, "127.0.0.1" is displayed in the Use
the following DNS server addresses box (the box will not be blank); this is
acceptable.

11. Click Advanced.

12. On the DNS tab, verify that there are no values defined. Make sure that the
Register this connection's addresses in DNS and Use this connection's DNS suffix
in DNS registration check boxes are cleared.

13. When you close the dialog box, you may receive the following prompt. If you
receive this prompt, click Yes:

This connection has an empty primary WINS address. Do you want to

continue?

14. If you are using a crossover cable for your private heartbeat interconnect, disable
the TCP/IP stack destruction feature of Media Sense.

７ Note

Do not perform this step on a Windows Server 2003 Cluster.

 To disable the TCP/IP stack destruction feature of Media Sense, add the following
registry value to each node:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Value Name: DisableDHCPMediaSense

Data Type: REG_DWORD
Data: 1

15. Complete the previous steps on all other nodes in the cluster.

16. Start Cluster Administrator.

17. Click the cluster name at the root of Administrator. On the File menu, click
Properties.

18. On the Network Priority tab, verify that the private network is listed at the top. If it
is not, use the Move Up button to increase its priority.

19. Click the private network, and then click Properties.

20. Click to select the Enable this network for cluster use check box.

21. Click Internal cluster communications only (private Network). For more
information, see How to use Windows Server cluster nodes as domain controllers.

Recommended configuration for the private

adapter in Windows NT 4.0
1. Click Start, point to Settings, click Control Panel, and then double-click Network.

2. On the Protocols tab, click TCP/IP Protocol, and then click Properties.

3. In the Adapter box, click the private network adapter.

4. On the IP Address tab, verify that you have selected a static IP address that is not
on the same subnet or network as another one of the public network adapters. An
example of good IP addresses to use for the private adapters is 10.10.10.10 on
node 1 and 10.10.10.11 on node 2 with a subnet mask of 255.0.0.0.

5. Make sure that there is no value set in the Default Gateway box.

6. On the WINS Address tab, click the heartbeat adapter in the Adapter box.

7. Verify that there are no values defined for the WINS server entries.
 8. When you close the dialog box, you may receive the following prompt. If you
receive this prompt, click Yes:

At least one of the adapter cards has an empty primary WINS address. Do you
want to continue?

9. On the Routing tab, verify that the Enable IP Forwarding check box is cleared.

10. Click OK.

11. If you have a network adapter that can transmit at multiple speeds and can specify
a speed and duplex mode, manually specify a speed and duplex mode.

With network adapters that can manually specify a speed and duplex mode, make
sure that you hard set them to the same on all nodes and according to the
manufacturer's specifications. For network adapters that do not support manual
settings, follow the card manufacturer's specifications.

The information that is traveling across the heartbeat network is small, but latency
is critical for communication. If you have the same speed and duplex settings, you
can help make sure that you have reliable communication.

If you do not know the supported speed of your card and connecting devices,
Microsoft recommends you set all devices on that path to 10 MB/Sec and Half
Duplex. This configuration provides sufficient bandwidth and reliable
communication.

７ Note

Microsoft does not recommend that you use any type of fault-tolerant
adapter or "Teaming" for the heartbeat. If you require redundancy for your
heartbeat connection, use multiple network adapters set to Internal
Communication Only and define their network priority in the Cluster
configuration. Issues seen with early multi-ported network adapters, verify
that your firmware and driver are at the most current revision if you use this
technology.

Contact your network adapter manufacturer for information about compatibility

on a Server Cluster.

12. On the Bindings tab, click All Adapters in the Show Bindings For box.

13. Click the plus sign (+) next to the adapter used for the private interconnect.
 14. Click WINS Client (TCP/IP), and then click Disable.

７ Note

No protocols other than TCP/IP should be enabled on the heartbeat adapter.

Verify that all others are disabled (including such items as Network Monitor).

15. In the Show Bindings For box, click All Protocols.

16. Click the plus sign (+) next to TCP/IP Protocol.

17. Make sure that the public network adapter is the first binding (at the top of the
binding list). To do this, click the private network adapter and use the Move Down
button. If you have multiple public network adapters, make sure the heartbeat
adapter is listed last.

18. Click OK to finish modifying the network properties and accept the changes.

19. Reboot the node for the changes to take effect.

20. Complete the previous steps on all other nodes in the cluster.

21. Start Cluster Administrator.

22. Click the cluster name at the root of Administrator. On the File menu, click
Properties.

23. On the Network Priority tab, verify that the private network is listed at the top. If it
is not, use the Move Up button to increase its priority.

24. Click the private network, and then click Properties.

25. Click to select the Enable this network for cluster use check box.

26. Click Internal cluster communications only (private Network). For more
information, see How to use Windows Server cluster nodes as domain controllers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recommended hotfixes and updates for
Windows Server 2008 R2 SP1 Failover
Clusters
Article • 12/26/2023

This article documents recommended hotfixes for Windows Server 2008 R2 Service Pack
1 (SP1) Failover Clusters. Applying these fixes can improve the reliability of your high
availability solution.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2545685

７ Note

We recommend that you evaluate each fix to determine whether it applies to your
environment. If you determine that Failover Clusters in your environment may be
affected by the problem(s) that a fix addresses, install the fix on each cluster node
by using the procedures that are described in How to update Windows Server
failover clusters.

Use the information in the More information section to help you determine
whether a particular fix applies to the cluster. Before you install a particular fix, we
recommend that you review the original Microsoft Knowledge Base (KB) article that
describes the fix.

Recommended hotfixes and updates

ﾉ Expand table

Date when Knowledge Title Component Why we recommend

the hotfix Base article this hotfix
was added

January 22, 3033918 Disk resource does Clusres.dll Makes sure that chkdsk
2015 not come online in works correctly on
Windows Server 2012 clustered volumes.
R2 or Windows
Server 2008 R2-
based failover cluster
 Date when Knowledge Title Component Why we recommend
the hotfix Base article this hotfix
was added

November 2972254 Hyper-V virtual Clussvc.exe Prevents connectivity

19, 2014 machines cannot be issues between nodes.
connected to Cluswmi.dll
sometimes when TCP
connections
reconnect in
Windows

July 23, 2871803 0x0000007E Stop Clusauthmgr.dll Prevents a blue screen

2014 error when you log error when you log off
off from a Windows Csvfilter.sys Cluster Administrator.
Server 2008 R2 SP1- Available for individual
based failover cluster download.

November 2524478 The network location Ncsi.dll Prevents loss of Cluster

17, 2012 profile changes from communication.
Domain to Public in Nlaapi.dll
Windows 7 or in
Windows Server 2008 Nlasvc.dll
R2

April 25, 2559392 The List Running Multiple Prevents Cluster

2012 Processes test fails Validation DLL's Validation failure.
when you run the Passing validation is
Failover Cluster required to have a
Validation Wizard on Supported Cluster
a Windows 7-based configuration.
or Windows Server
2008 R2-based
cluster node

June 14, 2545850 Users cannot access Multiple Prevents CNO and VCO
2011 an IIS-hosted website Authentication objects from failing to
after the computer DLL's register in DNS because
password for the of Kerberos
server is changed in authentication failure
Windows 7 or in after the computer
Windows Server 2008 password is changed.
R2

To see the latest list of hotfixes for Windows Server 2008 R2 Hyper-V configurations, see
Hyper-V Update List for Windows Server 2008 R2.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

SMB features don't work with non-
default cluster network name
configuration on Windows Server 2016,
Windows Server 2012 R2, and Windows
Server 2012
Article • 12/26/2023

This article describes an issue in which some SMB features don't work correctly together
with non-default cluster network name configuration in Windows Server 2012 R2.

Applies to: Windows Server 2012 R2

Original KB number: 4018013

Symptoms
Consider the following scenario:

You're using a Windows Server 2012, Windows Server 2012 R2, or Windows Server
2016 cluster.

You changed the Properties for the cluster network name resource so that the
DNSName and Name property are different than the Name of the cluster network
name resource. For example, you run the following PowerShell cmdlet:

PowerShell

Get-ClusterResource "ClusterNetworkNameResource" | Get-ClusterParameter

Object Name Value Type
------ ---- ----- ----
ClusterNetworkNameResource Name ServerNameX String
ClusterNetworkNameResource DnsName ServerNameX String

You create a file share in this cluster group with the CA Feature enabled.

In this scenario, the CA Feature doesn't work correctly, and you receive the following
event in the SMBWitnessClient log:

Log Name: WitnessClientAdmin

Source: Microsoft-Windows-SMBWitnessClient
 Event ID: 8
Level: Error
Description:
witness client failed to register with Witness Server for notification on NetName with
error (The parameter is incorrect.)

７ Note

This event could also be logged with for a file share without the CA feature
enabled.

Cause
This issue occurs because the SMB code expects the Name of the cluster network name
resource and the property names of DNSName and Name to be identical.

Workaround
To work around this issue, you have to adjust the properties of the cluster network name
resource to be identical to the Name of the resource.

More information
The purpose of the SMB witness service is to speed up the detection of cluster node
failures. This SMB witness service is only active for clustered CA shares. For Non-CA
shares, the SMB witness service is not used.

If the Event ID 8 is logged and the witness client could not register for a cluster network
name (CA file share), then this is equal to the SMB witness service is disabled.

A cluster node failure is first found during the cluster service health checks and the SMB
witness service also gets this Information immediately from the cluster.

Next the SMB clients are notified from the SMB witness service that they need to
reconnect to the remaining cluster nodes. This Process is finished in a few seconds. If the
SMB witness service is not running, then the SMB client needs to rely on the TCP and
SMB timeouts. Depending on the configuration, this can take about 45-90 Seconds until
the client notices the cluster node outage and reconnects to the remaining cluster
nodes. In some special configurations, it can take multiple minutes until the cluster node
outage is notified.

The SMB witness service is not necessarily needed to enable CA but it is recommended
to have this service running in default configurations as this speeds up the detection of
node failures. Nevertheless the CA feature is fully supported with disabled SMB witness
service.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Overview of the Microsoft third-party
storage software solutions support
policy
Article • 12/26/2023

This article outlines the Microsoft third-party storage software solutions support policy
that works in conjunction with Microsoft server products.

Applies to: Windows Server 2012 R2

Original KB number: 841696

Introduction
If you're using third-party storage solutions that run in conjunction with Microsoft server
products such as Microsoft Exchange Server and Microsoft SQL Server, you may find
occasions where you require support for the configuration. You can contact Microsoft
Product Support Services (PSS) if you require help, although depending on your
configuration, PSS may provide support directly, or may instruct you to contact the
storage vendor if you require help.

More information

The Designed for Windows Logo program, Exchange, and

SQL Server
Exchange, SQL Server, and other Microsoft software products that run on Windows do
not have separate Hardware Compatibility Tests for qualifying hardware to be used in
conjunction with them. They rely on the Designed for Windows Logo program for
hardware devices to qualify storage hardware and other hardware components for use
with various Windows desktop and server operating systems. A block storage hardware
target (such as small computer system interface [SCSI], Fibre Channel, or iSCSI) that
receives the Designed for Windows (DFW) logo is qualified to receive support for
Exchange, SQL Server, SharePoint Portal Server, and other Microsoft programs that run
on Windows.

Third-party software that is running on Designed for

Windows targets
Many storage vendors offer software solutions for backup, replication, mirroring, and
snapshots that are for use with their storage products. Some Microsoft customers have
used these products. They're frequently well integrated as part of an overall hardware
solution. If you run these third-party products on a Windows system that is attached to
a storage target device (such as SCSI, Fibre Channel, or iSCSI) that qualifies under the
Designed for Windows Logo program, you don't void the basic support for the device.
However, if a problem exists with the program or the hardware product directly, you
must contact the product manufacturer or vendor for support. If it's appropriate,
Microsoft may work in conjunction with the third-party vendor to resolve the issue after
you make initial contact with the third-party vendor or manufacturer.

７ Note

For third-party software programs that install drivers, this policy applies only if all
the included drivers are signed. This includes filter drivers, system drivers, and
others.

When you use a third-party program on qualified hardware such as block mode devices,
you must contact the third-party software vendor for support for that software product.
For example, if you use snapshot management software or backup software that
configures the storage hardware directly, you must contact the vendor directly for
support with the tool. However, when you these third-party programs on a Windows
system that is connected to qualified hardware or that is installed with qualified
hardware, your overall configuration is still supported by Microsoft. You can still run
these programs without invalidating or otherwise compromising the supportability of
your configuration.

７ Note

For third-party software programs that install drivers, this policy only applies if all
the included drivers are signed. This includes filter drivers, system drivers, and
others.

Microsoft won't offer direct support for third-party software that is used on qualified
hardware, just as Microsoft doesn't offer direct support for other third-party
independent programs that run on Windows. If you call Microsoft for support for third-
party software that is used in conjunction with qualified hardware, and PSS determines
that there's a problem with the third-party software product, PSS will refer you to the
software vendor.
The role of Volume Shadow Copy Service
Volume Shadow Copy Service (VSS) is an infrastructure where multiple third-party
storage management programs, business programs, and hardware providers cooperate
in the creation and management of shadow copies.

Because VSS is an API that is licensed and built upon by these third parties, Microsoft
makes no warranty or recommendation on the performance or reliability of the third-
party solution. Microsoft relies on partners to offer VSS-enabled solutions and to
provide support for them. We recommend that customers use VSS-enabled backup
products.

When designed and implemented correctly, VSS-enabled products help make sure that
synchronization occurs between the server program, the backup program, and the
Windows storage subsystem. VSS-enabled products help make sure that pending writes
are held while the backup is created. VSS-enabled products help make sure that system
state information is accurately captured. This is especially true when backing up
Exchange, SQL Server, the Microsoft Cluster Service (MSCS), and the Active Directory
directory service.

Role of the Microsoft Certified for Windows program

The Microsoft Certified for Windows program is a logo program for Windows Server
software programs. This is a third-party testing process that is conducted by VeriTest for
Windows 2000 Server and Windows Server 2003 logos.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise,
regarding the performance or reliability of these products.
Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft doesn't guarantee the
accuracy of this third-party contact information.

References
For additional information about how storage solutions are supported for Microsoft
Exchange 5.5, Microsoft Exchange Server 2003, Microsoft SQL Server 7.0, and Microsoft
SQL Server 2000, click the following article numbers to view the articles in the Microsoft
Knowledge Base:

833770 Support for SQL Server 2000 on iSCSI technology components

304261 Support for network database files

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot issues with accounts used
by failover clusters
Article • 01/10/2024

This article provides troubleshooting guidance for issues with accounts used by failover
clusters.

When you create a failover cluster and configure clustered services or applications, the
failover cluster wizard creates the necessary Active Directory accounts and gives them
the correct permissions. Issues can occur if a needed account is deleted, or necessary
permissions are changed. The following sections provide steps to troubleshoot these
issues.

Troubleshoot password issues with the cluster

name account
You receive an event message about computer objects or the cluster identity that
includes the following text:

Output

Logon failure: unknown user name or bad password.

The event message indicates that the password for the cluster name account no longer
matches the corresponding password stored by the clustering software.

７ Note

To complete the following steps:

Your account should be at least a member of the local Administrators group

(or equivalent). In addition, your account should be given the Reset password
permission for the cluster name account (unless it's a Domain Admins account
or the Creator Owner of the cluster name account).
You can use the account that was used to install the cluster.

For more information about using the appropriate accounts and group
memberships, see Local and Domain Default Groups.
 For more information about ensuring the cluster administrators have the correct
permissions, see Planning ahead for password resets and other account
maintenance.

To resolve these issues, follow the steps:

1. Select Start, go to Administrative Tools, and then select Failover Cluster Manager
to open the failover cluster snap-in. If the User Account Control dialog box
appears, confirm that the action it displays is what you want, and then select Yes.

2. In the Failover Cluster Manager snap-in, check whether the cluster you want to
configure is displayed. If it isn't displayed, in the console tree, right-click Failover
Cluster Manager, select Manage a Cluster, and then select or specify the desired
cluster.

3. In the center pane, expand Cluster Core Resources.

4. Under Cluster Name, right-click the Name item, and then select Take Offline.

5. Under Cluster Name, right-click the Name item, point to More Actions, and then
select Repair Active Directory Object.

７ Note

The Repair Active Directory Object option will be greyed out unless the
cluster's Name resource is offline. Taking the cluster's Name resource offline
shouldn't negatively impact other cluster groups, such as the SQL Server
Failover Cluster Instance. This is because those other cluster groups don't
depend on the cluster's Name resource.

Troubleshoot issues caused by changes in

cluster-related Active Directory accounts
If the cluster name account is deleted or permissions are removed from the account,
you'll experience issues when you try to configure a new clustered service or application.
In this scenario, use the Active Directory Users and Computers snap-in to view or
change the cluster name account and other related accounts.

For more information about the related events (Event IDs 1193, 1194, 1206, and 1207),
see Active Directory Permissions for Cluster Accounts .
 ７ Note

The following steps require at least membership in the Domain Admins group (or
equivalent). For more information about using the appropriate accounts and group
memberships, see Local and Domain Default Groups .

To resolve these issues, follow the steps:

1. On a domain controller, select Start, go to Administrative Tools, and then select

Active Directory Users and Computers. If the User Account Control dialog box
appears, confirm that the action it displays is what you want, and then select Yes.

2. Expand the default Computers container or the folder in which the cluster name
account (the computer account for the cluster) is located. The Computers
container is located in Active Directory Users and Computers\<domain-
node>\Computers.

3. Examine the icon for the cluster name account. The account shouldn't be disabled
by having a downward-pointing arrow on it. If it's disabled, right-click it and select
Enable Account if possible.

4. On the View menu, make sure that the Advanced Features option is selected.

When the Advanced Features option is selected, you can see the Security tab in
the properties of accounts (objects) in Active Directory Users and Computers.

5. Right-click the default Computers container or the folder in which the cluster
name account is located, and then select Properties.

6. On the Security tab, select Advanced.

7. In the list of accounts with permissions, select the cluster name account, and then
select Edit.

７ Note

If the cluster name account isn't listed, select Add and add it to the list.

8. For the cluster name account (also known as the cluster name object or CNO),
ensure that the Allow checkbox is selected for the Create Computer objects and
Read all properties permissions.
 9. Select OK until you return to the Active Directory Users and Computers snap-in.

10. Review domain policies (consult a domain administrator if applicable) related to

the creation of computer accounts (objects). Ensure that the cluster name account
can create a computer account each time you configure a clustered service or
application. For example, if your domain administrator has configured settings that
cause all new computer accounts to be created in a specialized container rather
than the default Computers container, make sure that these settings also allow the
cluster name account to create new computer accounts in that container.

11. Expand the default Computers container or the container in which the computer
account for one of the clustered services or applications is located.

12. Right-click the computer account for one of the clustered services or applications,
and then select Properties.

13. On the Security tab, confirm that the cluster name account is listed among the
accounts that have permissions, and select it. Confirm that the cluster name
account has the Full control permission (the Allow checkbox is selected). If it
doesn't, add the cluster name account to the list and give it the Full control
permission.
14. Repeat steps 12-13 for each clustered service and application configured in the
cluster.

15. Make sure that the domain-wide quota (by default, 10 ) for creating computer
objects hasn't been reached (consult a domain administrator if applicable). If the
previous items in this procedure have all been reviewed and corrected, and the
quota has been reached, consider increasing the quota. To change the quota,
follow these steps:
a. Open a command prompt as an administrator and run the ADSIEdit.msc
command.
b. Right-click ADSI Edit, and then select Connect to > OK. Then, Default naming
context is added to the console tree.
c. Double-click Default naming context, right-click the domain object under it,
and then select Properties.
d. Scroll to ms-DS-MachineAccountQuota and select it. Select Edit, change the
value, and then select OK.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

IaaS with SQL Server - tuning failover
cluster network thresholds
Article • 12/26/2023

This article introduces solutions for adjusting the threshold of failover cluster networks.

Symptom
When you run Windows failover cluster nodes in IaaS with a SQL Server Always On
availability group, changing the cluster setting to a more relaxed monitoring state is
recommended. Cluster settings out of the box are restrictive and could cause unneeded
outages. The default settings are designed for highly tuned on premises networks and
don't take into account the possibility of induced latency caused by a multitenant
environment such as Microsoft Azure (IaaS).

Windows Server Failover Clustering is constantly monitoring the network connections

and health of the nodes in a Windows Cluster. If a node is not reachable over the
network, then recovery action is taken to recover and bring applications and services
online on another node in the cluster. Latency in communication between cluster nodes
can lead to the following error:

Error 1135 (system event log)

Cluster node Node 1 was removed from the active failover cluster membership. The
Cluster service on this node might have stopped. This could also be due to the node
having lost communication with other active nodes in the failover cluster. Run the
Validate a Configuration wizard to check your network configuration. If the condition
persists, check for hardware or software errors related to the network adapters on this
node. Also check for failures in any other network components to which the node is
connected such as hubs, switches, or bridges.

Cluster.log example:

Output

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG [NETFTAPI] Signaled

NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address
10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] got event: Remote
endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] Marking Route from
10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [NDP] Checking to see if
all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote
xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [NDP] All routes for route
(virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote
fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO [CORE] Node 8: executing
node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO [NODE] Node 8: Cleaning up
connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO [Nodename] Clearing 0
unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO [NODE] Node 8: n12 node
object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO [DCM]
HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] Route history 1: Old:
05.936, Message: Response, Route sequence: 150415, Received sequence:
150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0
Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO [NODE] Node 8: closing n12
node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] Route history 2: Old:
06.434, Message: Request, Route sequence: 150414, Received sequence: 150402,
Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp:
2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO [DCM] HandleRequest:
dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] Route history 3: Old:
06.934, Message: Response, Route sequence: 150414, Received sequence:
150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0
Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO [IM] Route history 4: Old:
07.434, Message: Request, Route sequence: 150413, Received sequence: 150401,
Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp:
2014/06/10-07:54:26.664, Ticks since last sending: 36

Output

0000ab34.00007328::2014/06/10-07:54:34.100 INFO
<realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO
<realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO
<virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO
<virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO
<Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO
 <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO </struct
mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO removed

Output

0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR [QUORUM] Node 8: Lost

quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR [QUORUM] Node 8: goingAway:
0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR lost quorum (status = 5925)

Cause
There are two settings that are used to configure the connectivity health of the cluster.

Delay - This defines the frequency at which cluster heartbeats are sent between nodes.
The delay is the number of seconds before the next heartbeat is sent. Within the same
cluster, there can be different delays between nodes on the same subnet and between
nodes, which are on different subnets.

Threshold - This defines the number of heartbeats, which are missed before the cluster
takes recovery action. The threshold is a number of heartbeats. Within the same cluster,
there can be different thresholds between nodes on the same subnet and between
nodes that are on different subnets.

By default Windows Server 2016 sets the SameSubnetThreshold to 10 and

SameSubnetDelay to 1000 ms. For example, if connectivity monitoring fails for 10
seconds, the failover Threshold is reached resulting in the unreachable that node being
removed from cluster membership. This results in the resources being moved to another
available node on the cluster. Cluster errors will be reported, including cluster error 1135
(above) is reported.

Resolution
To resolve this issue, relax the Cluster network configuration settings. See Heartbeat and
threshold.

References
For more information on tuning Windows Cluster network configuration settings, see
Tuning Failover Cluster Network Thresholds .

For information on using cluster.exe to tune Windows Cluster network configuration

settings, see How to Configure Cluster Networks for a Failover Cluster.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unexpected warning and error
messages in a virtualized Windows
Server failover cluster
Article • 12/26/2023

This article describes an issue where unexpected warning and error messages occur in a
Windows Server failover cluster that has been configured to run as a guest (virtual
machine) in a Hyper-V environment.

Applies to: Windows Server 2012 R2

Original KB number: 2014304

Symptoms
In a Windows Server failover cluster that has been configured to run as a guest (virtual
machine) in a Hyper-V environment, the following messages are written to the logs that
are indicated in the message details:

Warning message:

Log Name: Microsoft-Windows-FailoverClustering-Manager/Admin

Source: Microsoft-Windows-FailoverClustering-Manager/Admin
Event ID: 4694
Level: Warning
Hyper-V management tools were not found on the system. Creation and
management of virtual machines will be disabled in Failover Cluster Manager. Install
Hyper-V role admin tools for servers or RSAT tools for clients to enable those
options.
Error message:

Log Name: Microsoft-Windows-Hyper-V-High-Availability/Admin

Source: Hyper-V-High-Availability
Event ID: 21123
Level: Error
Failed to set the migration networks at the VMMS: Class not registered
(0x80040154)

Cause
These messages are registered because of the new functionality in Windows Server
failover clusters. This new functionality includes better interoperability with Hyper-V.
Even when the failover cluster is running in a virtualized environment as a guest (virtual
machine), the failover clustering feature expects aspects of the Hyper-V role to be
available. When the failover cluster doesn't find these Hyper-V aspects, these messages
are written to the logs in question.

Resolution
To resolve the warning message, install the Hyper-V role Remote Server Administration
tools. To add the Hyper-V Remote Server Administration tools, follow these steps:

1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, click Features, and then click Add Features.
3. Expand Remote Server Administration Tools.
4. Click Hyper-V Tools, click Next, and then click Install.

There's no workaround or resolution for the error message. However, you can safely
ignore this error message in this scenario.

More information
In a Windows Server 2008 R2 IA-64 environment, there's no workaround for this error
message because Hyper-V doesn't support the IA-64 architecture.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to use Windows Server cluster
nodes as domain controllers
Article • 12/26/2023

This article describes how to use Windows Server cluster nodes as domain controllers.

Applies to: Windows Server 2012 R2

Original KB number: 281662

Summary

７ Note

The information in this article addresses a situation that you do not generally
encounter in most Information Technology architectures.

Links to all of the articles that are referenced within this article are located in the
"References" section.

There are instances when you can deploy cluster nodes in an environment where there
are no pre-existing Active Directory. This scenario requires that you configure at least
one of the cluster nodes as a domain controller. It is recommended that 2+ nodes be
configured as domain controllers, so that there be at least one backup domain
controller. Keeping the configuration of the nodes consistent across the cluster is a
general best practice, and you may wish to enable all nodes as domain controllers.
Because Active Directory depends on the Domain Name System (DNS), each domain
controller must be a DNS server if there is not another DNS server available that
supports dynamic updates or SRV records. (Microsoft recommends that you use Active
Directory-integrated zones). For more information, see article 255913.

More information
Depending on the workload deployed on the Failover Cluster, there are different
support policies and recommendations:

Microsoft Exchange Server - Is not supported in a clustered configuration where

the cluster nodes are domain controllers. For more information, click the following
article number to view the article in the Microsoft Knowledge Base: 898634
 Active Directory domain controllers are not supported as Exchange Server cluster
nodes.
Microsoft SQL Server - Is not supported in a clustered configuration where the
cluster nodes are domain controllers. For more information, click the following to
view more information: Installing SQL Server on a Domain Controller
Windows Server Hyper-V - It is not recommended to run other workloads
(including the domain controller role) in the hypervisor parent partition.

If you have a cluster deployment in which there is no link with a domain, you must
configure the cluster nodes as domain controllers prior to setting up the cluster. If the
connectivity between cluster nodes and domain controllers is such that the link is either
slow or unreliable, consider having a domain controller co-located at the same site or
location as the cluster.

Consider the following important points when you are deploying Windows Server 2003,
Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 Failover
Clustering nodes as domain controllers:

It is not recommended to combine the Active Directory Domain Services role and
the Failover Cluster feature on Windows Server 2003, Windows Server 2008, or
Windows Server 2008 R2

It is not supported for a Windows Server 2003, Windows Server 2008, or Windows
Server 2008 R2 node in a Failover Cluster to be a Read-Only Domain Controller
(RODC)

It is not supported for a Windows Server 2003, Windows Server 2008, or Windows
Server 2008 R2 Failover Cluster running Microsoft Exchange Server or Microsoft
SQL Server to be a domain controller

It is not supported to combine the Active Directory Domain Services role and the
Failover Cluster feature on Windows Server 2012

It is recommended that at least two nodes be configured as domain controllers

and potentially all nodes for consistency if cluster nodes are configured as domain
controllers.

There is overhead that is associated with the running of a domain controller. A

domain controller that is idle can use anywhere between 130 to 140 megabytes
(MB) of RAM, which includes the running of Failover Clustering. There is also
replication traffic if these domain controllers have to replicate with other domain
controllers within the domain and across domains. Most corporate deployments of
clusters include nodes with gigabytes (GB) of memory so this is not generally an
issue.

If the Windows Server 2003 cluster nodes are the only domain controllers, they
each have to be DNS servers as well, and they should point to themselves for
primary DNS resolution, and to each other for secondary DNS resolution. You must
address the problem of the ability to not register the private interface in DNS,
especially if it is connected by way of a crossover cable (two-node only). For
additional information about how to configure the heartbeat interface, click the
following article number to view the article in the Microsoft Knowledge Base:
258750 Recommended private "heartbeat" configuration on a cluster server

However, before you can accomplish step 12 in article 258750, you must first
modify other configuration settings, which are outlined in the following article in
the Microsoft Knowledge Base: 275554 The host's "A" record is registered in
DNS after you choose not to register the connection's address

If the cluster nodes are the only domain controllers, they must each be global
catalog servers, or you must implement domainlets.

The first domain controller in the forest takes on all flexible single master
operation (FISMO) roles, refer to article 197132. You can redistribute these roles to
each node. However, if a node fails, the flexible single master operation roles that
the node has taken on are no longer available. You can use Ntdsutil to forcibly take
away the roles and assign them to the node that is still running (refer to article
223787). Review article 223346 for information about placement of flexible single
master operation roles throughout the domain.

Clustering other programs, such as SQL or Exchange, in a scenario where the

nodes are also domain controllers, may not result in optimal performance due to
resource constraints

You cannot cluster domain controllers for fault tolerance. You can promote
computers to be domain controllers, and then you can install the Cluster service on
those computers, but there is no method to store Active Directory on any one of
the cluster's managed drives. There is no "failover" of Active Directory. Having
multiple domain controllers are by the very nature deliver high availability of
directory services.

Nodes in a Windows Server 2003, Windows Server 2008, and Windows Server 2008
R2 Failover Cluster must have access to a Read-Write Domain Controller
 It is supported to deploy a Windows Server 2012 Failover Cluster in an
environment that only has access to a Read-Only Domain Controller (RODC)

It is recommended to leave at least one domain controller on bare metal when

deploying domain controllers inside of virtual machines with Windows Server 2008
and Windows Server 2008 R2

References
For more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
255913 Integrating Windows 2000 DNS into an existing BIND or Windows NT 4.0-
based DNS namespace

258750 Recommended private "heartbeat" configuration on cluster server

275554 The host's "A" record is registered in DNS after you choose not to register the
connection's address

223787 Flexible single master operation transfer and seizure process

197132 Windows 2000 Active Directory FSMO roles

223346 FSMO placement and optimization on Windows 2000 domain controllers

234790 How to find servers that hold flexible single master operations roles

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Installing updates, features, or roles
troubleshooting documentation for
Windows Server
Article • 02/19/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve issues with installing updates, features, or roles. The topics
are divided into one subcategory. Browse the content or use the search feature to find
relevant content.

Installing updates, features, or roles sub

category
Failure to install Windows Updates

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unable to connect to WSUS
Administration Website
Article • 02/19/2024

This article provides a solution to an issue where you're unable to connect to WSUS
Administration website.

Applies to: Windows Server 2012 R2

Original KB number: 2737219

Symptoms
You are unable to connect to WSUS Administration website while opening
"Windows Server Update Service"
In addition to this when you open Windows Small Business Server Console you get
error message "An error occurred while retrieving updates information" under
"Updates" tab.

You see HTTP Error 500 in IIS log file for WSUS Administration Website:

<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 GET /selfupdate/iuident.cab - 8530 -

fe80::e3a4:2b81:92b4:c6e7%11 - 500 24 50 3715
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/reportingwebservice/reportingwebservice.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 422
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/ApiRemoting30/WebService.asmx - 8530 - fe80::e3a4:2b81:92b4:c6e7%11
Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 6
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/ServerSyncWebService/serversyncwebservice.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 601
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ClientWebService/Client.asmx -
8530 - fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
 (compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 508
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/ReportingWebService/ReportingWebService.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7%11 Windows-Update-Agent 500 24 50 12078
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/SimpleAuthWebService/SimpleAuth.asmx - 8530 - fe80::e3a4:2b81:92b4:c6e7%11
Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 547
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/DssAuthWebService/DssAuthWebService.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500
24 50 483
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST
/ApiRemoting30/WebService.asmx - 8530 - fe80::e3a4:2b81:92b4:c6e7%11
Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.1) 500 24
50 8

After enabling Failed Request Tracing on "WSUS Administration" and

"ApiRemoting30" Websites for Http status code 500, results in the following errors.

http://<ServerName>:8530/ApiRemoting30/WebService.asmx

App Pool WsusPool Authentication NOT_AVAILABLE

User from token
Activity ID {00000000-0000-0000-9000-0080000000D3}

Site 1572271583
Process 6860
Failure Reason STATUS_CODE
Trigger Status 500.24
Final Status 500.24
Time Taken 16 msec

ModuleName ConfigurationValidationModule
Notification 1
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 24
 ErrorCode 2147942450
ConfigExceptionInfo
Notification BEGIN_REQUEST
ErrorCode The request is not supported. (0x80070032)

Errors in Application Logs

Log Name: Application
Source: Windows Server Update Services
Date: <DateTime>
Event ID: 7053
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ServerName.domain.local
Description:
The WSUS administration console has encountered an unexpected error. This may
be a transient error; try restarting the administration console. If this error persists,
Try removing the persisted preferences for the console by deleting the wsus file
under %appdata%\Microsoft\MMC\.

System.InvalidOperationException -- Client found response content type of

'text/html; charset=utf-8', but expected 'text/xml'.
The request failed with the error message:
.
.
.
Source
System.Web.Services
Stack Trace:
at
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMe
ssage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters)
at
Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int
32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml,
String computerTargetScopeXml, String preferredCulture, Int32 publicationState,
Int32 propertiesToGet)
 at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.
ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean
includeDownstreamComputers, String updateScopeXml, String
computerTargetScopeXml, String preferredCulture, ExtendedPublicationState
publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
at
Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources
updateSources, Boolean includeDownstreamComputers, UpdateScope
updatesToInclude, ComputerTargetScope computersToInclude,
UpdateServerStatusPropertiesToGet propertiesToGet) at
Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSo
urces updateSources)
at
Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshO
bjectForCache()
at Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()
at
Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_
DoWork(Object sender, DoWorkEventArgs e)

Cause
The above behavior is experienced due to incorrect settings on the WSUS
Administration Website. By default we do not have " ASP.NET Impersonation " Enabled for
any of the WSUS Administration Websites.

Resolution
Open IIS Console

Highlight WSUS Administration Website

Double-click "Authentication"
Highlight ASP.NET Impersonation , on the right under "Action" pane click on
"Disable"
Check the following websites under WSUS Administration and make sure ASP.NET
Impersonation is Disabled. If any of the below Web Applications have ASP.NET

Authentication Enabled,** then disable them.

ApiRemoting30
ClientWebService
Content
 DssAuthWebService
Inventory
ReportingWebService
Selfupdate
ServerSyncWebService
SipleAuthWebService
Restart IIS

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't install the .NET Framework 3.5
without a public Internet environment
on an OEM Windows installation
Article • 02/19/2024

This article provides a workaround for an issue where the Microsoft .NET Framework 3.5
installation fails without a public Internet environment on an OEM Windows installation.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2956772

Symptoms
Consider the following scenario:

You have an exclusive network environment that is not connected to the Internet.
You have a Windows operating system installed from a standard OEM image in this
environment. This image may include a combination of languages and the latest
updates relevant to the system and environment.
You try to install the .NET Framework 3.5 or the .NET Framework 3.5 Service Pack 1
(SP1) on this computer.

In this scenario, you receive an error message, and the .NET Framework installation fails.

The .NET Framework installation also fails in one of the following situations:

You use the stand-alone .NET Framework redistributable package.

The sources\sxs folder from the original installation media is used as an alternative
source.

Cause
This issue occurs because Windows was designed with the intent that the operating
system would have access to the Internet.

If you cannot access the Internet, the .NET Framework 3.5 has to pull data from an
alternative source. If that source does not explicitly match the installing OS (such as a
hotfix, hotfix version, or a language pack-specific file that was installed), you will
encounter this issue.
Workaround
To work around this issue, create an installation media that has the .NET Framework 3.5
preinstalled. To do this, follow the steps on the following webpage for each language
that will be installed on this operating system: The .NET Framework 4.5 is default and
the .NET Framework 3.5 is optional Or, you can temporarily connect the computer
that needs the .NET Framework 3.5 to the Internet in order to install the .NET
Framework.

７ Note

You have to perform these steps before you install the language packs. However,
hotfixes typically must be installed after the language packs are installed.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section. Currently, an efficient and effective strategy has not been
located for existing operating systems. However, this issue is under investigations for
future operating systems.

More information
If you were successful in building an alternative installation source by using an offline
OS image, be aware that with this solution, you have to make sure that this alternative
source has all updates (hotfixes) applied to it that might be on the target computers
together with all language packs. This image has to be kept up-to-date as new updates
are released.

７ Note

Some hotfixes can only be obtained by contacting Microsoft directly. These hotfixes
should also be considered when you build the installation source if this route is
selected.

Our recommendation regarding the building of installation media (as mentioned in the
"Workaround" section) is to build an alternative-source media and test it, as this process
has proven expensive considering the time that must be spent. This is compared to
creating installation media by using known file versions.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot install some updates or
programs in Windows XP
Article • 02/19/2024

This article offers you some advanced manual methods that can be used to fix some
problems that prevent you from installing some updates or programs.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 822798

Symptoms
When you try to download an ActiveX control, install an update to Windows or to a
Windows component, install a service pack for Windows or for a Windows component,
or install a Microsoft or third-party software program, you may experience one or more
of the following symptoms:​​

７ Note

These problems may occur for these reasons.

You receive the following error message when you try to install a program or
update:

Digital Signature Not Found

The Microsoft digital signature affirms that software has been tested with
Windows and that the software has not been altered since it was tested.
The software you are about to install does not contain a Microsoft digital
signature. Therefore, there is no guarantee that this software works correctly
with Windows.
Name of software package
If you want to search for Microsoft digitally signed software, visit the Windows
Update Web site at http://update.microsoft.com to see if one is available.
Do you want to continue the installation?

If you click More Info, you receive the following message:

Microsoft Windows
The signature on the software package you want to install is invalid. The
 software package is not signed properly.

After you click OK in the first error message dialog box, you receive a message that
states that the installation was successful, or you receive the following error
message:

Name of Update Package

The cryptographic operation failed due to a local security option setting.

When you try to install an update or to install a service pack, you receive an error
message that is similar to one of the following:

Error 1

Name of Update Package

Setup could not verify the integrity of the file Update.inf. Make sure the
Cryptographic service is running on this computer.

Error 2

Failed to install catalog files.

Error 3

The software you are installing has not passed Windows Logo testing to
verify its compatibility with Windows XP. (Tell me why this testing is
important.)
This software will not be installed. Contact your system administrator.

Error 4

The software you are installing has not passed Windows Logo testing to
verify its compatibility with this version of Windows. (Tell me why this
testing is important.)

When you try to install a Windows XP service pack, you receive an error message
that is similar to the following:

Service Pack 1 Setup could not verify the integrity of the file. Make sure the
Cryptographic service is running on this computer.
 When you attempt to install Microsoft Data Access Components (MDAC) 2.8, you
receive an error message that is similar to the following:

INF Install failure. Reason: The timestamp signature and/or certificate could not
be verified or is malformed.

The %WINDIR%\System32\CatRoot2\Edb.log may grow to 20 megabytes (MB)

even though the file is typically less than 1 MB.

When you try to install a package from the Windows Update Web site or from the
Microsoft Update Web site, you receive a message that is similar to the following:

The software has not passed Windows logo testing and will not be installed.

When you examine the %systemroot%\Windowsupdate.log file, you see an entry

for one of the following errors:​​
0x80096001
0x80096005
0x80096010
0x800B0001
0x800B0003
0x800B0004
0x800B0109
0x8007f0da
0x8007f01e

When you use Microsoft windows update on a Windows XP-based computer, the
update process fails, and you receive a 0x8007f007 error message. This may occur
regardless of what type of update you select.

The Svcpack.log file may contain entries that are similar to the following

937.406: GetCatVersion: Failed to retrieve version information from

C:\WINDOWS\system32 \CatRoot{F750E6C3-38EE-11D1-85E5-
00C04FC295EE}\Tmp.0.scw.cat with error 0x57 937.437: GetCatVersion: Failed to
retrieve version information from C:\WINDOWS\Tmp.0.scw.cat with error
0x80092004 940.344: InstallSingleCatalogFile: MyInstallCatalog failed for
Tmp.0.scw.cat; error=0xfffffbfe. 940.344: DoInstallation:MyInstallCatalogFiles
failed:STR_CATALOG_INSTALL_FAILED
955.125: UnRegisterSpuninstForRecovery, failed to delete SpRecoverCmdLine value,
error 0x2
955.125: DoInstallation: Failed to unregistering spuninst.exe for recovery.
 962.656: DeRegistering the Uninstall Program -> Windows Server 2003 Service Pack,
0
962.656: Failed to install catalog files. 1448.406: Message displayed to the user:
Failed to install catalog files.
1448.406: User Input: OK
1448.406: Update.exe extended error code = 0xf01e
1448.406: Update.exe return code was masked to 0x643 for MSI custom action
compliance.

Cause
These problems may occur in any of the following situations:

Log file or database corruption exists in the %Systemroot%\System32\Catroot2

folder.
Cryptographic Services is set to disabled.
Other Windows files are corrupted or missing.
The timestamp signature or certificate could not be verified or is malformed.
The hidden attribute is set for the %Windir% folder or one of its subfolders.
The Unsigned non-driver installation behavior Group Policy setting (Windows
2000 only) is set to Do not allow installation or Warn but allow installation, or the
Policy binary value is not set to 0 in the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Non-Driver Signing

The Enable trusted publisher lockdown Group Policy setting is turned on, and you
do not have the appropriate certificate in your Trusted Publishers certificate store.
This Group Policy setting is located under User Configuration, under Windows
Settings, under Internet Explorer Maintenance, under Security, under
Authenticode Settings in the Group Policy MMC snap-in.
You are installing Internet Explorer 6 SP1, and the 823559 (MS03-023) security
update is installed.
The software distribution folder is corrupted.

Method 1: Rename the Edb.log file

Rename the Edb.log file, and then try to install the program again. To rename the
Edb.log file, follow these steps:

1. Click Start, click Run, type cmd in the Open box, and then click OK.

７ Note
 On a Windows Vista-based computer, click Start, type cmd in the Start Search
text box, right-click cmd.exe, and then click Run as administrator.

2. At the command prompt, type the following command, and then press Enter:

Console

ren %systemroot%\system32\catroot2\Edb.log *.tst

Method 2: Temporarily turn off Trusted

Publishers Lockdown and install the
appropriate certificates to your trusted
publishers certificate store
You can continue to use the Enable trusted publisher lockdown Group Policy setting,
but you must first add the appropriate certificates to your Trusted Publishers certificate
store. To do this, turn off the Enable trusted publisher lockdown Group Policy setting,
install the appropriate certificates in your Trusted Publishers certificate store, and then
turn the Enable trusted publisher lockdown Group Policy setting back on. To install the
appropriate certificate for Microsoft Windows and Microsoft Internet Explorer product
updates, follow these steps:

1. Download the Microsoft product update that you want to install from the
Microsoft Download Center, from the Windows Update Catalog, or from the
Microsoft Update.

For more information about how to download product updates from the Microsoft
Download Center, view how to obtain Microsoft support files from the Online
Services Catalog .

For more information about how to download product updates from the Windows
Update Catalog, view how to download updates that include drivers and hotfixes
from the Windows Update Catalog .

2. Extract the product update package to a temporary folder. The command-line

command that you use to do this depends on the update that you are trying to
install. View the Microsoft Knowledge Base article that is associated with the
update to determine the appropriate command-line switches that you will use to
extract the package. For example, to extract the 824146 security update for
Windows XP to the C:\824146 folder, run Windowsxp-kb824146-x86-enu -
 x:c:\824146 . To extract the 828750 security update for Windows XP to the

C:\828750 folder, run q828750.exe /c /t:c:\828750 .

3. Right-click the KB Number.cat file from the product update package in the
temporary folder you created in step 2, and then click Properties.

７ Note

The KB Number.cat file may be in a subfolder. For example, the file may be in
the C:\824146\sp1\update folder or in the C:\824146\sp2\update folder.

4. On the Digital Signatures tab, click the digital signature and then click Details.

5. Click View Certificate, and then click Install Certificate.

6. Click Next to start the Certificate Import Wizard.

7. Click Place all certificates in the following store, and then click Browse.

8. Click Trusted Publishers, and then click OK.

9. Click Next, click Finish, and then click OK.

Method 3: Verify status of all certificates in

certification path and import missing or
damaged certificates from another computer
To verify certificates in the certificate path for a Windows or Internet Explorer product
update, follow these steps:

Step 1: Verify Microsoft certificates

1. In Internet Explorer, click Tools, and then click Internet Options.

2. On the Content tab, click Certificates.

3. On the Trusted Root Certification Authorities tab, double-click Microsoft Root

Authority. If this certificate is missing, go on to step 2.

4. On the General tab, make sure that the Valid from dates are 1/10/1997 to
12/31/2020.
 5. On the Certification Path tab, verify that This certificate is OK appears under
Certificate Status.

6. Click OK, and then double-click the NO LIABILITY ACCEPTED certificate.

7. On the General tab, make sure that the Valid from dates are 5/11/1997 to
1/7/2004.

8. On the Certification Path tab, verify that either This certificate has expired or is
not yet valid or This certificate is OK appears under Certificate Status.

７ Note

Although this certificate is expired, the certificate will continue to work. The
operating system may not work correctly if the certificate is missing or
revoked. For more information, view Required trusted root certificates.

9. Click OK, and then double-click the GTE CyberTrust Root certificate. You may have
more than one of these certificates with the same name. Check the certificate that
has an expiration date of 2/23/2006.

10. On the General tab, make sure that the Valid from dates are 2/23/1996 to
2/23/2006.

11. On the Certification Path tab, verify that This certificate is OK appears under
Certificate Status.

７ Note

Although this certificate is expired, the certificate will continue to work. The
operating system may not work correctly if the certificate is missing or
revoked.

12. Click OK, and then double-click Thawte Timestamping CA.

13. On the General tab, make sure that the Valid from dates are 12/31/1996 to
12/31/2020.

14. On the Certification Path tab, verify that This certificate is OK appears under
Certificate Status.

Step 2: Import missing or damaged certificates

If one or more of these certificates are missing or corrupted, export the missing or
corrupted certificates to another computer, and then install the certificates on your
computer. To export certificates on another computer, follow these steps:

1. In Internet Explorer, click Tools, and then click Internet Options.

2. On the Content tab, click Certificates.
3. On the Trusted Root Certification Authorities tab, click the certificate that you
want to export.
4. Click Export, and then follow the instructions to export the certificate as a DER
encoded Binary x.509(.CER) file.
5. After the certificate file has been exported, copy it to the computer where you
want to import it.
6. On the computer where you want to import the certificate, double-click the
certificate.
7. Click Install certificate, and then click Next.
8. Click Finish, and then click OK.

Method 4: Clear temporary file and restart

hotfix installation or service pack installation
To clear the temporary file and restart the hotfix installation or the service pack
installation, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. At the command prompt, type the following commands. Press Enter after each
command.

Console

net stop cryptsvc

ren %systemroot%\System32\Catroot2 oldcatroot2
net start cryptsvc
exit

3. Remove all the tmp*.cat files in the following folders:

%systemroot% \system32\CatRoot{127D0A1D-4EF2-11D1-8608-
00C04FC295EE}
%systemroot% \system32\CatRoot{F750E6C3-38EE-11D1-85E5-
00C04FC295EE}
 If no files that start with tmp exist in this folder, do not remove any other files. The
.cat files in this folder are necessary for installing hotfixes and service packs.

） Important

Do not rename the Catroot folder. The Catroot2 folder is automatically

recreated by Windows, but the Catroot folder is not recreated if the Catroot
folder is renamed.

4. Delete all the oem*.* files from the %systemroot% \inf folder.

5. Restart the failed hotfix installation or service pack installation.

Method 5: Empty the software distribution

folder
1. Click Start, click Run, type services.msc, and then click OK.

７ Note

On a Windows Vista-based computer, click Start, type services.msc in the

Start Search box, right-click services.msc, and then click Run as
administrator.

2. In the Services (Local) pane, right-click Automatic Updates, and then click Stop.

3. Minimize the Services (local) window.

4. Select all the contents of the Windows distribution folder, and then delete them.

７ Note

By default, the Windows distribution folder is located in the drive

:\Windows\SoftwareDistribution folder. In this location, drive is a placeholder
for the drive where Windows is installed.

5. Make sure that the Windows distribution folder is empty, and then maximize the
Services (local) window.

6. In the Services (Local) pane, right-click Automatic Updates, and then click Start.
 7. Restart the computer, and then run Windows Update again.

Method 6: Perform an in-place upgrade

If all these methods do not resolve your problem, you may have to perform an in-place
upgrade.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Can't install Windows Server 2019 on
servers with a high processor count
Article • 02/19/2024

This article provides workarounds for an issue in which Windows Server 2019 can't be
installed on servers with a high processor count.

When you install Windows Server 2019 on servers with a high processor count, the
installation fails at the setup stage, and you encounter the following issues:

The mouse and keyboard don't respond.

Windows Setup can't recognize the storage device.

In the memory dump file, "USB Port Reset Failures" occur on the port with the CD-ROM.

This is a known limitation when installing Windows Server 2019 on servers that have the
latest processor with a high processor count.

To work around this issue, use one of the following methods:

Install Windows Server 2022 instead of Windows Server 2019.

Disable hyper-threading in firmware before installing Windows Server 2019. After
the installation, hyper-threading can be enabled.
Update the installation media with the latest rollup packages. Both the install.wim
and boot.wim files need to be updated.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The CBS.log file contains entries that
some files aren't repaired even after you
successfully run the SFC utility on a
Windows Server based computer
Article • 02/19/2024

This article describes an issue where the CBS.log file records entries when a static file
changes. Because the static file isn't protected by the Windows Resource Protection
feature, the feature reports the change in the CBS.log file.

Applies to: Windows Server 2012 R2

Original KB number: 954402

Symptoms
You run the System File Checker (SFC) utility (Sfc.exe) to scan for changes in Windows
system files in a Windows Server 2008-based computer. When you run the SFC utility,
you may receive the following message:

All files and registry keys listed in this transaction have been successfully repaired.

However, when you view the %windir%\Logs\CBS\CBS.log file that the Sfc.exe program
generates, you may see the following entries:

<Date> <Time>, Info CSI 00000142 [SR] Repairing 1 components

<Date> <Time>, Info CSI 00000143 [SR] Beginning Verify and Repair transaction
<Date> <Time>, Info CSI 00000145 [SR] Cannot repair member file
[l:18{9}]"img11.jpg" of Microsoft-Windows-Shell-Wallpaper-Common, Version =
6.0.5720.0, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral,
VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral,
TypeName neutral, PublicKey neutral in the store, hash mismatch
<Date> <Time>, Info CSI 00000147 [SR] Cannot repair member file
[l:18{9}]"img11.jpg" of Microsoft-Windows-Shell-Wallpaper-Common, Version =
6.0.5720.0, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral,
VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral,
TypeName neutral, PublicKey neutral in the store, hash mismatch
<Date> <Time>, Info CSI 00000149 [SR] Repair complete
<Date> <Time>, Info CSI 0000014a [SR] Committing transaction
 <Date> <Time>, Info CSI 0000014e [SR] Verify and Repair Transaction completed.
All files and registry keys listed in this transaction have been successfully repaired

Cause
Static files and mutable files are the two kinds of files that are defined in the system.
Static files can't be changed. Mutable files can be changed. Registry files and log files
are examples of mutable files. The Windows Resource Protection (WRP) feature doesn't
scan mutable files. The WRP feature scans static files when the SFC utility scans the
computer. The WRP feature helps protect most of the static files. However, in this case,
the WRP feature doesn't protect the Img11.jpg static file. If a static file changes when
the WRP feature scans the file, the change is recorded in the CBS.log file. Because the
WRP feature doesn't protect the Img11.jpg static file, the WRP feature has no option
other than to report the change in the CBS.log file.

More information
The Sfc.exe program writes the details of each verification operation and of each repair
operation to the CBS.log file. Each SFC.exe program entry in the CBS.log file has an [SR]
tag.

７ Note

The Windows Modules Installer service also writes to the CBS.log file. The Windows
Modules Installer service installs optional features, updates, and service packs.

You can search for [SR] tags to help locate SFC.exe program entries. To search for [SR]
tags and to redirect the search results to a text file, follow these steps:

1. Click Start, type cmd in the Start Search box, right-click cmd in the Programs list,
and then click Run as administrator.

If you're prompted for an administrator password or for confirmation, type the

password, or click Continue.

2. At the command prompt, type the following command, and then press ENTER:

Console

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

 ７ Note

The Sfcdetails.txt file includes the entries that are logged every time that the
SFC.exe program runs on the computer.

3. Type exit, and then press ENTER to close the Command Prompt window.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of System File Checker
(Sfc.exe)
Article • 02/19/2024

This article describes System File Checker (Sfc.exe), which is a command-line utility used
with the Windows File Protection (WFP) feature.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 310747

Summary
System File Checker gives an administrator the ability to scan all protected files to verify
their versions. If System File Checker discovers that a protected file has been
overwritten, it retrieves the correct version of the file from the cache folder
( %Systemroot%\System32\Dllcache ) or the Windows installation source files, and then
replaces the incorrect file. System File Checker also checks and repopulates the cache
folder. You must be logged on as an administrator or as a member of the Administrators
group to run System File Checker. If the cache folder becomes damaged or unusable,
you can use the sfc /scannow , the sfc /scanonce , or the sfc /scanboot commands to
repair its contents.

System File Checker tool syntax

Sfc [/Scannow] [/Scanonce] [/Scanboot] [/Revert] [/Purgecache] [/Cachesize=x]

/Scannow : Scans all protected system files immediately and replaces incorrect

versions with correct Microsoft versions. This command may require access to the
Windows installation source files.

/Scanonce : Scans all protected system files one time when you restart your

computer. This command may require access to the Windows installation source
files when you restart the computer. The SfcScan DWORD value is set to 2 in the
following registry key when you run this command:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

/Scanboot : Scans all protected system files every time you start your computer.

This command may require access to the Windows installation source files every
 time you start your computer. The SfcScan DWORD value is set to 1 in the
following registry key when you run this command:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

/Revert : Returns scan to the default setting (do not scan protected files when you

start the computer). The default cache size is not reset when you run this
command. This command is equivalent to the /Enable switch in Windows 2000.

/Purgecache : Purges the file cache and scans all protected system files

immediately. This command may require access to the Windows installation source
files.

/Cachesize=x : Sets the file cache size to x megabytes (MB). The default size of the

cache is 50 MB. This command requires you to restart the computer, and then run
the /purgecache command to adjust the size of the on-disk cache. This command
sets the SfcQuota DWORD value to x in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

For more information about the Windows File Protection feature, see Description of the
Windows File Protection feature .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Description of the Windows Server
Update Services 3.0 Service Pack 1
package
Article • 02/19/2024

This article provides some information about Windows Server Update Services 3.0
Service Pack 1 package.

Applies to: Windows Server 2012 R2

Original KB number: 948014

Introduction
Microsoft has released a service pack for Microsoft Windows Server Update Services 3.0
(WSUS). This article includes information about how to obtain the service pack and how
to obtain a list of issues that the service pack fixes. Additionally, this article includes
information about the issues that you may experience when you install the service pack
and information about how to determine whether the service pack is installed.

More information

How to obtain and install WSUS 3.0 Service Pack 1 (SP1)

The following file is available for download from the Microsoft Download Center:

Download the WSUS 3.0 Service Pack 1 package now.

For more information about how to download Microsoft support files, click the following
article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services Microsoft scanned
this file for viruses. Microsoft used the most current virus-detection software that was
available on the date that the file was posted. The file is stored on security-enhanced
servers that help prevent any unauthorized changes to the file.

Removal information
You cannot use Add or Removed Programs in Control Panel to remove only WSUS 3.0
Service Pack 1 because it will remove all of WSUS 3.0 as well.
Issues that the service pack fixes
Bulk approval of updates now does not overwrite existing approvals. Instead, bulk
approval now updates to a new target group. Bulk approval does not overwrite the
existing approvals of the old target groups. By default, bulk approval will add to
the existing set of approvals for an update that is not approved.

Optional approvals are considered when computing effective approval for

overlapping target groups. A required approval will override an optional approval
in the following scenario:
A computer is a member of multiple target groups.
An update is approved for optional approval to one of the target groups.
The same update is approved for required approval to at least one of the other
target groups that is at the same or greater depth in the target group tree.

７ Note

We recommend that you use the WSUS APIs to "optionally" approve updates
for WSUS 3.0 SP1 and to approve updates that are not critical updates or
security updates.

For example, assume that you have a required approval on Update X for Group A
and an optional approval for Group B. If a computer belongs to both Group A and
Group B, the update would be listed as optional on the client computer. Because
the target groups are at the same level, required approval should always "win."

The Computer Detailed Status report to Excel works.

The Configuration Wizard keeps a proxy server password if one is set before
upgrade.

Support is provided for a separate proxy server and port for SSL traffic.

Provides improved performance by turning off AUTO SHRINK on SUSDB.

Some client updates are based on Windows Error reporting (Watson).

The Add Printer Wizard now works when you receive lots of drivers from Windows
Update.

How to determine whether the service pack is installed

Look for "Windows Server Update Services 3.0 SP1" in Add or Remove Programs in
Control Panel or Program Files and Features in Control Panel. If "Windows Server Update
Services 3.0 SP1" does not appear, the service pack is not installed.

The improvements of WSUS 3.0 SP1

WSUS 3.0 SP1 includes the following improvements:

Added support for Windows Server 2008.

Added a new Client Servicing API:

Support client registration
Filter of updates by category and classification
Applicability rule extension mechanism
Package metadata and report update status for each client

Added improvements for local publishing. Supports publishing of drivers within

the enterprise by using vendor-provided catalogs. The API includes support for
bundles and for prerequisites.

Includes all the hotfixes that have been issued since the release of WSUS 3.0.

Performance improvements. These include in-line data compression between the

WSUS server and the remote administration console.

７ Note

In Windows Server 2008, you must enable dynamic compression for Internet
Information Services (IIS).

The WSUS 3.0 SP1 Update Package

WSUS 3.0 SP1 is available on Windows Update. The package behavior is as follows:

An upgrade occurs for all earlier versions of WSUS starting with WSUS 2.0 through
the original version of WSUS 3.0. The original version of WSUS 3.0 runs on
computers that are running Windows Server 2003 SP1 or later versions.
All upgrades require user interaction.
This service pack package supersedes previous updates for WSUS 3.0.
Upgrades of all WSUS installations that use remote SQL Server installations are
blocked. This is now a manual upgrade process.
 Upgrades of earlier versions of WSUS that are running on Windows Server 2008
are not supported.
The original version of System Center Essentials 1.0 is not upgraded to WSUS 3.0
SP1. This will be handled by a future release of System Center Essentials.>

７ Note

"WSUS 2.0 SP1" and "WSUS 2.0 Client SelfUpdate Update for WSUS 2.0 SP1"
packages will be expired. These updates are still available on the following
Microsoft Web site: https://www.microsoft.com/download/Search.aspx

Known issues with WSUS 3.0 SP1

You receive an error message during the installation: "Failed to set
SMTP_USERPASSWD property from SmtpUserPassword registry value (Error
0x800700EA: More data is available.)"

Symptoms

During the installation of this package, you may receive an error message that
resembles the following in the %temp%\Wsussetup.log file:

Error MWUSSetup CUpgradeDriver::PerformPresetupActions: Failed to set

SMTP_USERPASSWD property from SmtpUserPassword registry value (Error
0x800700EA: More data is available.)

Cause

This problem occurs because a Simple Mail Transfer Protocol (SMTP) password that is
greater than 11 characters fails. This causes the WSUS 3.0 SP1upgrade to fail. WSUS
does not copy its local copy of the password.

Workaround

To work around this issue, temporarily change the locally saved password, run the WSUS
3.0 SP1 upgrade, and then change the password back to the original password that is
used by the SMTP account. To do this, follow these steps:

1. Click Start, click Administrative Tools, and then click Microsoft Windows Update
Server Services 3.0.
2. Click to select Options, and then click E-Mail notification.
3. On the E-Mail Server tab, enter a password that is less than 12 characters.
 4. Click OK to save the password.

７ Note

Do not use Test because this password would be invalid for the SMTP account. 5.
Exit the WSUS Administration tool. 6. Run the WSUS 3.0 SP1 upgrade. 7. After you
successfully upgrade to WSUS 3.0 SP1, change the password back to the original
password.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error C0190003 after you install updates
in Windows Server 2012 R2
Article • 02/19/2024

This article provides a workaround for an issue that triggers an error when you restart a
Windows Server 2012 R2-based computer after you install updates.

Applies to: Windows Server 2012 R2

Original KB number: 3074603

Symptoms
Consider the following scenario:

You try to install many updates from Windows Update. This includes update
3000850.
You're using a native 4K sector disk as a system drive.

However, after the update installation process finishes and the computer is restarted,
you may receive one of the following error messages:

Error C0190003 applying update operation 21417 of 247778 (wow64_microsoft-

window

Fatal error C0190003 applying update operation 19505 of 247778 (amd64_microsoft

７ Note

The number of operations and file names may vary.

In this situation, the computer doesn't restart successfully.

Cause
During the installation process, all the file operations (copy, move, and delete, for
example) must be transactional. However, if there are lots of files to process, the
transaction log may become full. In this situation, transactions are reverted, and the
error message is displayed.
Workaround
If you haven't installed the updates yet, you can work around this issue by increasing the
transaction log size. To do this, open cmd.exe as an administrator, and then run the
following command:

Console

fsutil resource setlog maxextents 100 C:\

７ Note

This command increases the maximum number of containers for the boot drive
(drive C) to 100. (The default value is 20.) If you set the value to 100 and still
experience the same error, you may want to try a higher number.

If you've already experienced the issue that's described in the Symptoms section, you
can recover from the issue by following these steps:

1. While the error message is displayed, press the power button to turn off the
computer.

2. Press the power button and then immediately press the F8 key. This displays the
Advanced Boot Options menu.

3. Select Repair Your Computer, and then press Enter.

4. On the Choose an option menu, select Troubleshoot.

5. On the Advanced options menu, select Command Prompt.

6. Select the administrator account, and then enter the password.

7. At a command prompt (cmd.exe), run the following command:

Console

Dism /image:C:\ /cleanup-image /revertpendingactions

8. Close the command prompt.

9. On the Choose an option menu, select Continue.

Status
Microsoft has confirmed that this is a problem in Windows Server 2012 R2.

References
Microsoft support policy for 4K sector hard drives in Windows

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error code 2359302 when installing
updates in Windows Server 2019
Article • 02/19/2024

This article helps resolve an issue in which you receive error code 2359302 when
installing updates in Windows Server 2019.

When you install updates in Windows Server 2019, you receive the 2359302 error in the
Windows Setup event log under Event Viewer. For example:

Windows update could not be installed because of error 2359302 "" (Command line:
""C:\Windows\system32\wusa.exe" "C:\temp\windows10.0-kb5027222-x64
5802ce76528f37a5abbd6bde65549a9bad98acfc.msu" ")

In the system, the updates are displayed as Install Pending.

７ Note

To obtain the similar output, open a command prompt or Powershell window as an

administrator and run Dism /Online /Get-Packages /Format:table .

In the Component Based Servicing (CBS) registry key, the updates are displayed under
the PendedSessionPackages registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based

Servicing\PendedSessionPackages
Uninstall all pending updates and delete the
pending transactions
To resolve this issue, follow these steps:

1. Start the system in the Windows Recovery Environment (WinRE) environment by

using one of the following media:

Windows Server operating system (OS) media

Microsoft Diagnostics and Recovery Toolset (DaRT) 10
Other Windows bootable media

2. Run the list volume command to list all volumes and find the OS disk. For example,
the D volume is the OS disk in the following screenshot:

3. Navigate to the transaction folder and show hidden files by running the following
commands:

Console

cd D:\Windows\System32\Config\TxR\
attrib -h -r -s
dir
4. Back up the transaction files by running the following commands:

Console

mkdir backup
copy *.* backup
dir backup

5. Delete the transaction files by running the following commands:

dir
del *.blf
del *.regtrans-ms

6. Navigate to the WinSxS folder and rename the pending.xml file by running the
following commands:

Console
 cd D:\Windows\WinSxS\
ren pending.xml pending.xml.old

7. In Registry Editor, select the HKEY_LOCAL_MACHINE registry key, and then select File >
Load Hive.

8. Navigate to the following folder and select the COMPONENTS hive:

C:\Windows\System32\config

9. Delete the ExecutionState and PendingXmlIdentifier registry values (if they exist)
from the following registry key:

HKEY_LOCAL_MACHINE\COMPONENTS

10. Run the following command to revert pending actions:

Console

DISM /image:D :\ /cleanup-image /revertpendingactions

You'll receive the following message:

Output

Reverting pending actions from the image.... The operation completed.

11. Restart the system, and you'll receive the following message:

Reverting pending actions

12. Install the update again by running the following command:

Console

DISM /online /Add-package /PackagePath:"C:\temp\Win10.xxx.CAB"

Feedback
Was this page helpful?  Yes  No
Provide product feedback
ERROR_INVALID_DATA error at startup
after installing updates
Article • 02/19/2024

This article helps resolve an issue in which you receive the "ERROR_INVALID_DATA" error
at the system startup after installing Windows updates.

After you install an update and restart the system, the system performs a rollback at the
system startup, and you receive the "ERROR_INVALID_DATA" error.

This issue occurs because the database of performance counters is corrupted.

Rebuild the performance counter setting

To resolve this issue, follow these steps:

1. Open an elevated Windows PowerShell prompt, and then navigate to the

C:\windows\system32\wbem folder by running the following cmdlet:

PowerShell

cd C:\Windows\system32\wbem

2. Run the following wmiadap cmdlet to parse all the performance libraries:

PowerShell

C:\Windows\system32\wbem>wmiadap.exe /f

3. Run the following lodctr cmdlet to rebuild the performance counter setting:

PowerShell

C:\Windows\system32\wbem>lodctr /r

Then, you receive the following message if the cmdlet runs successfully:

Output

Successfully rebuilt performance counter setting from system backup

store
 4. Install the update again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x800705aa when Windows
Update fails
Article • 02/19/2024

This article helps resolve an issue in which Windows Update fails with error 0x800705aa.

Windows Cumulative Updates (CUs) can't be installed, or the system shows a

notification that updates are missing.

You can also find the following error by searching "Failed to load the COMPONENTS
hive" in CBS.log (C:\Windows\Logs\CBS):

Info CBS Failed to load the COMPONENTS hive from

'C:\Windows\System32\config\COMPONENTS' into registry key
'HKLM\COMPONENTS'. [HRESULT = 0x800705aa -
ERROR_NO_SYSTEM_RESOURCES]

When you check the RegistrySizeLimit registry value in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control , you find that the value is set to

a value other than 0.

Insufficient resource prevents the system from

extending the COMPONENTS hive
The value of the RegistrySizeLimit registry key specifies the maximum size of the
registry in megabytes. When the registry reaches this size, Windows stops adding new
keys and values to the registry. That means the system won't perform Windows
servicing activities such as CU installation.

Delete the RegistrySizeLimit setting

Open the Registry Editor as an administrator, and go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control . Then, delete the

RegistrySizeLimit registry key or set it to 0, and restart the system.

７ Note
 This allows the operating system to automatically set the registry size as needed.
We recommend deleting the registry key unless it's specifically required.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x80070005 "Access denied" when
you activate Windows
Article • 02/19/2024

This article discusses how to fix Windows activation error 0x80070005 (access denied).

Applies to: Windows Server, all versions, and Windows client, all versions

Symptoms
You run the slmgr /ato command to activate a domain-joined computer that's running
Windows. However, Windows doesn't activate, and you receive the following error
message:

Windows Script Host Activating Windows(R), ServerDatacenter edition (00091344-

1ea4-4f37-b789-01750ba6988c) ... Error: 0x80070005 Access denied: the requested
action requires elevated privileges

Additionally, the following event is logged in the Application log:

Output

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date:
Event ID: 8229
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer:
Description:
The rules engine failed to perform one or more scheduled actions.
Error Code:0x80070005
Path:C:\Windows\System32\SLUI.exe

Cause
The SELF account doesn't have the correct DCOM permissions.

Solution: Restore SELF account permissions

To restore the permissions of the SELF account, follow these steps:

1. In the Search box, type dcomcnfg, and then select Component Services
(depending on your version of Windows, you might have to select dcomcnfg Run
command instead).

2. In the left pane of the Component Services snap-in, select Component Services >
Computers, right-click My Computer, and then select Properties.

3. In the My Computer Properties dialog box, select the COM Security tab, and then
select Edit Default in the Access Permissions area.

4. In the Access Permission dialog box, if SELF doesn't appear in the Group or user
names area, select Add. In the Enter the object names to select text box, type
SELF, select Check Names, and then select OK.

5. In the Group or user names area, select SELF, and then select the following
checkboxes in the Allow column:

Local Access
Remote Access

6. Select OK to close Access Permission, and then select OK to close My Computer

Properties.

7. Restart the computer.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0xC004E015
(SL_E_EUL_CONSUMPTION_FAILED)
when you activate Windows
Article • 02/22/2024

This article helps fix the error 0xC004E015 that occurs when you activate Windows.

You receive the following error when you activate Windows:

Error: 0xC004E015 On a computer running Microsoft Windows non-core edition, run

'slui.exe 0x2a 0xC004E015' to display the error text.

This error occurs because the C:\Windows\System32\spp\store\2.0\tokens.dat file is

corrupted.

To resolve the issue, rebuild the tokens.dat file and activate Windows again.

More information
Normally, Windows can create a tokens.dat file. If you get an "Error: Product not found"
error, run the following commands to reapply the Key Management Services (KMS)
client key:

Console

cscript c:\windows\system32\slmgr.vbs /ipk <KMS Client Key>

cscript c:\windows\system32\slmgr.vbs /ato

７ Note

You can get the <KMS Client Key> in Key Management Services (KMS) client
activation and product keys depending on your Windows version.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Error 0x800f0922 caused by corrupted
scheduled task when installing Windows
updates
Article • 02/19/2024

This article helps resolve the 0x800f0922 (CBS_E_INSTALLERS_FAILED) error that occurs
when installing Windows updates.

When you install Windows updates, you receive the 0x800f0922

(CBS_E_INSTALLERS_FAILED) error.

In the CBS.log file, you see the following entries:

Output

Info, CSI 00000c61 Begin executing advanced installer phase 38 index

2480 (sequence 2519)
Old component: [l:0]''
New component: [l:168 ml:169]'Microsoft-OneCore-SecureBootEncodeUEFI-
Task, Culture=neutral, Version=10.0.14393.6078,
PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64,
versionScope=NonSxS'
Install mode: install
Smart installer: FALSE
Installer ID: {<InstallerID>}
Installer name: 'Task Scheduler'
…
Error CSI 00000c63 (F) Logged @: [l:26 ml:27]'JobsHandler::Install
enter'
Error CSI 00000c64 (F) Logged @: [l:34 ml:35]'JobsHandler::Install
type=4 pass=4'
Error CSI 00000c65 (F) Logged @: [l:36 ml:37]'IsScheduleServiceRunning
queries SCM'
Error CSI 00000c66 (F) Logged @: [l:37 ml:38]'IsScheduleServiceRunning
returns true'
Error CSI 00000c67 (F) Logged @: [l:23 ml:24]'InstallTaskOnline enter'
Error CSI 00000c68 (F) Logged @: [l:49 ml:50]'InstallTaskOnline:
RegisterTask failed 0x80070002'
Error CSI 00000c69 (F) Logged @: [l:70 ml:71]'WmiCmiPlugin
jobshandler.cpp(237): RegisterTask failed. HR=0x80070002.'
Error CSI 00000c6a (F) Logged @: [l:57 ml:58]'WmiCmiPlugin
plgutil.cpp(217): fnc failed. HR=0x80070002.'
Error CSI 00000c6b (F) Logged @: [l:74 ml:75]'WmiCmiPlugin
jobshandler.cpp(364): ForEachElementIn failed. HR=0x80070002.'
Error CSI 00000c6c (F) Logged @: [l:86 ml:87]'WmiCmiPlugin
jobshandler.cpp(836): InstallManifestSectionOnline failed. HR=0x80070002.'
Error CSI 00000c6d@2023/8/7:15:43:34.530 (F) CMIADAPTER: Inner Error
Message from AI HRESULT = HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)
 ['The system cannot find the file specified.']
Error CSI 00000c6e@ (F) CMIADAPTER: AI failed. HRESULT =
HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)
…
Error CSI 00000c6f@ (F) CMIADAPTER: Exiting with HRESULT code =
HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND).

Error [0x018003] CSI 00000c71 (F) Failed execution of queue item

Installer: Task Scheduler ({<InstallerID>}) with HRESULT
HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND). Failure will not be ignored: A
rollback will be initiated after all the operations in the installer queue
are completed; installer is reliable
Error CBS Startup: Failed to process advanced operation queue,
startupPhase: 0. A rollback transaction will be created. [HRESULT =
0x800f0922 - CBS_E_INSTALLERS_FAILED]
Info CBS Progress: UI message updated. Operation type: Update. Stage: 1
out of 1. Rollback.
Info CBS Setting original failure status: 0x800f0922, last forward
execute state: CbsExecuteStateResolvePending

In the Task Scheduler event log, you see the following entries:

Output

Log Name: Microsoft-Windows-TaskScheduler/Operational

Source: Microsoft-Windows-TaskScheduler
Event ID: 146
Task Category: Task loading at service startup failed
Level: Error
Keywords:
User: SYSTEM
Description:
Task Scheduler failed to load task
"\Microsoft\Windows\PI\SecureBootEncodeUEFI" at service startup. Additional
Data: Error Value: 2147942402.

This issue occurs because the scheduled SecureBootEncodeUEFI task is corrupted.

Delete staged packages and clean up corrupted

tasks
To fix this issue, follow these steps:

1. Find the staged update packages by running the get-packages cmdlet:

PowerShell
 Dism /english /online /get-packages /format:table | findstr /i
"Staged"

2. Delete the staged update packages by running the remove-package cmdlet. For
example:

PowerShell

Dism /online /remove-package

/PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~14393XXXX

3. Identify the SecureBootEncodeUEFI GUID by running the following cmdlet:

PowerShell

reg query "HKLM\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\PI\SecureBo
otEncodeUEFI" /v ID

The cmdlet output looks like the following:

Output

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\PI\SecureBo
otEncodeUEFI
ID REG_SZ {<GUID>}

4. Running the following cmdlets to delete the SecureBootEncodeUEFI registry values:

７ Note

You need to replace the {GUID} value returned from Step 3.

PowerShell

reg delete "HKLM\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Schedule\TaskCache\Maintenance\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Schedule\TaskCache\Plain\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows
 NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\PI\SecureBo
otEncodeUEFI" /f

For more information about how to clean up corrupted tasks, see MS10-092:
Vulnerability in Task Scheduler could allow for elevation of privilege .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x800f0922 when the MPIO
feature installation fails
Article • 02/19/2024

This article helps to fix the error 0x800f0922 that occurs when the Microsoft Multipath
I/O (MPIO) feature installation fails.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 3008079

Symptoms
When you try to install the MPIO feature by using the graphical user interface (GUI) or
Windows PowerShell, you receive the following error message:

The request to add or remove features on the specified server failed.

Installation of one or more roles, role services, or features failed. Error: 0x800f0922.

Additionally, information that resembles the following is logged in the Component

Based Servicing log (CBS.log):

<DateTime>, Info CSI 00000029 Begin executing advanced installer phase 32

(0x00000020) index 11 (0x000000000000000b) (sequence 41)
Old component: [l:0]""
New component: [ml:344{172},l:342{171}]"Microsoft-Windows-
MultipathDeviceSpecificModule, Culture=neutral, Version=6.2.9200.16384,
PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64,
versionScope=NonSxS"
Install mode: install
Installer ID: {3d07d150-2f3d-4184-9793-d0fd59b0c885}
Installer name: [12]"Root Devices"
<DateTime>, Error CSI 00000001@<DateTime> (F) CMIADAPTER: Inner Error
Message from AI HRESULT = 800f0207 [Error,Facility=(000f),Code=519 (0x0207)]
[66]"The device instance cannot be created because it already exists."
]
[gle=0x80004005]
<DateTime>, Error CSI 00000002@<DateTime> (F) CMIADAPTER: AI failed. HRESULT
= 800f0207 [Error,Facility=(000f),Code=519 (0x0207)]
Element:
[308]"<rootDevices xmlns="urn:schemas-microsoft-com:asm.v3">
<rootDevice classGUID="{4D36E97D-E325-11CE-BFC1-08002BE10318}"
deviceName="ROOT\MPIO\0001" generateId="false">
<properties>
<property name="HardwareIds" value=""ROOT\MSDSM"" />
</properties>
</rootDevice>"[gle=0x80004005]
<DateTime>, Error CSI 00000003@<DateTime> (F) CMIADAPTER: Exiting with
HRESULT code = 800f0207 [Error,Facility=(000f),Code=519 (0x0207)].
[gle=0x80004005]
<DateTime>, Info CSI 0000002a Performing 1 operations; 1 are not lock/unlock and
follow:
(0) LockComponentPath (10): flags: 0 comp: {l:16
b:0079df39e6ddcf01300000001413a815} pathid: {l:16
b:0079df39e6ddcf01310000001413a815} path:
[l:234{117}]"\SystemRoot\WinSxS\x86_microsoft.windows.s..ation.badcomponents_3
1bf3856ad364e35_6.2.9200.16384_none_353ccb4c94858655" pid: 1314 starttime:
130566894897453336 (0x01cfdde62dc9d918)
<DateTime>, Error [0x018005] CSI 0000002b (F) Failed execution of queue item
Installer: Root Devices ({3d07d150-2f3d-4184-9793-d0fd59b0c885}) with HRESULT
800f0207 [Error,Facility=(000f),Code=519 (0x0207)]. Failure will not be ignored: A
rollback will be initiated after all the operations in the installer queue are completed;
installer is reliable [2](gle=0x80004005)
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CBS.log to WER report.
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_<DateTime>.log to
WER report.
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_<DateTime>.log to
WER report.
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_<DateTime>.log to
WER report.
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_<DateTime>.log to
WER report.
<DateTime>, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_<DateTime>.log to
WER report.
<DateTime>, Info CBS Not able to add pending.xml.bad to Windows Error Report.
[HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
<DateTime>, Info CBS Not able to add SCM.EVM to Windows Error Report.
[HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
<DateTime>, Info CSI 0000002c Creating NT transaction (seq 3), objectname [6]"
(null)"
 <DateTime>, Info CSI 0000002d Created NT transaction (seq 3) result 0x00000000,
handle @0x330
<DateTime>, Info CSI 0000002e@<DateTime> Beginning NT transaction commit...
<DateTime>, Info CSI 0000002f@<DateTime> CSI perf trace:
CSIPERF:TXCOMMIT; 15663 <DateTime>, Info CSI 00000030@<DateTime> CSI
Advanced installer perf trace:
CSIPERF:AIDONE;{3d07d150-2f3d-4184-9793-d0fd59b0c885};Microsoft-Windows-
MultipathDeviceSpecificModule, Version = 6.2.9200.16384, pA =
PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS,
PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral,
PublicKey neutral;199927us
<DateTime>, Info CSI 00000031 End executing advanced installer (sequence 41)
Completion status: HRESULT_FROM_WIN32(ERROR_ADVANCED_INSTALLER_FAILED)

Also, the following information is logged in the device installation text log
(SetupAPI.dev.log):

>>> [Setup Root Device - Install]

>>> Section start <DateTime>
set: {Install Root Device: ROOT\MPIO\0001} <DateTime>
!!! set: Could not create a device information element for device ROOT\MPIO\0001.
HRESULT = 0x800f0207
set: {Install Root Device - exit(0x800f0207)} <DateTime>
<<< Section end <DateTime>
<<< [Exit status: FAILURE(0x00000207)]

Cause
This issue occurs because of some stale entries in the registry key for the MPIO feature.

Resolution
To resolve this issue, remove the following key from the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\MPIO\0001

Status
Microsoft has confirmed that this is a problem in the Microsoft products listed at the
beginning of this article.
Explanation of the error codes
ﾉ Expand table

Error Code Symbol File Description

0x800f0922 CBS_E_INSTALLERS_FAILED cbsapi.h Processing advanced installers

and generic commands failed.

0x800f0207 SPAPI_E_DEVINST_ALREADY_EXISTS winerror.h The device instance cannot be

created because it already
exists.

0x80070002 ERROR_FILE_NOT_FOUND winerror.h The system cannot find the file

specified.

0x00000207 SE_AUDITID_LPC_INVALID_USE msaudite.h Invalid use of LPC port.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DISM fails with 0x800f0906 or runs
continuously when you convert
Windows Server 2012 R2 Core to Server
with a GUI
Article • 02/19/2024

This article discusses an issue where converting Windows Server Core to GUI by using a
DISM or PowerShell command fails with error 0x800f0906.

Applies to: Windows Server 2012 R2

Original KB number: 3023427

Symptoms
This issue occurs when you run a DISM command, an equivalent Windows PowerShell
command, or another similar method to convert to GUI.

The DISM command that is used for conversion contains the following switches:

/enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Mgmt

/featurename:Server-Gui-Shell

You receive one of the following information clusters on the command prompt:

Information for failure with error code 0x800f0906:

Console

Dism.exe /online /enable-feature /featurename:ServerCore-FullServer

/featurename:Server-Gui-Mgmt /featurename:Server-Gui-Shell
/source:wim:d:\sources\install.wim:4

Deployment Image Servicing and Management tool

Version: 6.3.9600.17031
Image Version: 6.3.9600.17031
Enabling feature(s)
[===========================66.7%====== ]
Error: 0x800f0906
The source files could not be downloaded.
 Use the "source" option to specify the location of the files that are required to
restore the feature. For more information on specifying a source location, see
http://go.microsoft.com/fwlink/?LinkId=243077 .

The DISM log file can be found at C:\Windows\Logs\DISM\dism.log.

Information for the DISM command that continues to run for a long time without
stopping:

Console

Dism.exe /online /enable-feature /featurename:ServerCore-FullServer

/featurename:Server-Gui-Mgmt /featurename:Server-Gui-Shell
/source:wim:d:\sources\install.wim:4

Deployment Image Servicing and Management tool

Version: 6.3.9600.17031
Image Version: 6.3.9600.17031
Enabling feature(s)
[===========================66.7%====== ]

７ Note

The progress bar on the command prompt always remains at 66.7%. The size of the
CBS.log file that is under the %windir%\logs\cbs path will continue to increase.

Errors in CBS logs

The CBS.log file shows one of the following two errors:

Error 1

<DateTime>, Info CBS Session: 30409734_2213032090 initialized by client

WindowsUpdateAgent.
<DateTime>, Info CBS Opened cabinet package, package directory: \\?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056b
d76ba, sandbox location: \\?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056b
d76ba, cabinet location: \\?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056b
d76ba\windows8.1-kb3000850-x64-express.cab, manifest location: \\?
 \C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056b
d76ba\update.mum
...
...
...
<DateTime>, Info DPX Extraction of file: amd64_microsoft-windows-c.. t-
resources-
mrmcore_31bf3856ad364e35_6.3.9600.17418_none_dc8ca600359fa9c4\mrmco
rer.dll failed because it is not present in the container.
<DateTime>, Info CBS Asynchronous Session: 30409734_2213032090 finalized.
[HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]

Error 2

<DateTime>, Info CBS Not able to find package:

Package_for_KB2959977~31bf3856ad364e35~amd64~6.3.1.1 from the cached
windows update index. [HRESULT = 0x800f090d -
CBS_E_MISSING_PACKAGE_MAPPING_INDEX]
<DateTime>, Info CBS Failed to find package:
Package_for_KB2959977~31bf3856ad364e35~amd64~~6.3.1.1 from the index
mapping [HRESULT = 0x800f090d -
CBS_E_MISSING_PACKAGE_MAPPING_INDEX]

７ Note

The updates that appear during the error may different. The cause of these errors is
in the CBS component and the index file, not the updates themselves. The sample
output and the list of updates that are mentioned in the error are based on internal
testing of a default but updated Windows Server 2012 R2 Core installation that has
no additional features or roles enabled.

Cause of Error 1 in CBS logs

This issue occurs when the conversion requires files to be downloaded for updates that
are bundled as a part of a single updateID.

Local testing shows that presence of the following updates on the Core server will cause
the conversion to fail with the DPX Extraction 0x80070002 errors:

3000850
3003057
 3014442
2919355
2959977

７ Note

To see sample values for updateID, open the wuindex.xml file under the
%windir%\servicing\packages path, and search for the updateID string.

Cause of Error 2 in CBS logs

The cause is the entry <Map
Package="package_for_kb2959977~31bf3856ad364e35~amd64~~6.3.1.1"/> is missed
under updateID 8452bac0-bf53-4fbd-915d-499de08c338b, inside the file
%windir%\servicing\packages\wuindex.xml.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x800f0922 when trying to
uninstall Windows Server roles or
features
Article • 02/19/2024

This article helps fix the error 0x800f0922 that occurs when you uninstall Microsoft
Windows Server roles or features.

Applies to: Windows Server 2012 R2, Windows Server 2016

Original KB number: 4094128

Symptoms
When you try to uninstall a Windows Server role or feature by using Server Manager or
the PowerShell cmdlet Uninstall-WindowsFeature , the attempt fails, and you receive
error code 0x800f0922 and the following error message:

CBS_E_INSTALLERS_FAILED
Processing advanced installers and generic commands failed

For example, when uninstalling Windows Deployment Services (WDS), the following
errors were logged in the CBS.log under C:\Windows\Logs\CBS :

SQM: Reporting selectable update change for package: Microsoft-Windows-

Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
update: Microsoft-Windows-Deployment-Services, start: Installed, applicable:
Resolved, target: Resolved, client id: DISM Package Manager Provider, initiated
offline: False, execution sequence: 1433, first merged sequence: 1433, download
source: 0, download time (secs): 4294967295, download status: 0x0 (S_OK),reboot
required: False, overall result:0x800f0922 (CBS_E_INSTALLERS_FAILED)
SQM: Upload requested for report: UpdateChange_Microsoft-Windows-
Deployment-Services_Microsoft-Windows-Deployment-Services-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, session id: 142860, sample
type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
TI: CBS has queried the current reboot required state: 0
SQM: Reporting selectable update change for package: Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
update: Microsoft-Windows-Deployment-Services-Deployment-Server, start: Staged,
applicable: Resolved, target: Resolved, client id: DISM Package Manager Provider,
initiated offline: False, execution sequence: 1433, first merged sequence: 1433,
download source: 0, download time (secs): 4294967295, download status: 0x0
(S_OK),reboot required: False, overall result:0x800f0922 (CBS_E_INSTALLERS_FAILED)
SQM: Upload requested for report: UpdateChange_Microsoft-Windows-
Deployment-Services-Deployment-Server_Microsoft-Windows-Deployment-
Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, session id: 142860,
sample type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
TI: CBS has queried the current reboot required state: 0
SQM: Reporting selectable update change for package: Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
update: Microsoft-Windows-Deployment-Services-Transport-Server, start: Installed,
applicable: Resolved, target: Resolved, client id: DISM Package Manager Provider,
initiated offline: False, execution sequence: 1433, first merged sequence: 1433,
download source: 0, download time (secs): 4294967295, download status: 0x0
(S_OK),reboot required: False, overall result:0x800f0922 (CBS_E_INSTALLERS_FAILED)
SQM: Upload requested for report: UpdateChange_Microsoft-Windows-
Deployment-Services-Transport-Server_Microsoft-Windows-Deployment-Services-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, session id: 142860, sample
type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
SQM: Reporting package change for package: Microsoft-Windows-Deployment-
Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current: Installed,
pending: Default, start: Installed, applicable: Installed, target: Installed, limit:
Installed, hotpatch status: DisabledBecauseNoHotpatchPackagesInitiated, status:
0x0, failure source: Execute, reboot required: False, client id: DISM Package Manager
Provider, initiated offline: False, execution sequence: 1433, first merged sequence:
1433 reboot reason: REBOOT_NOT_REQUIRED RM App session: -1 RM App name:
N/A FileName in use: N/A
SQM: Upload requested for report: PackageChangeBegin_Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
session id: 142859, sample type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
SQM: Reporting package change completion for package: Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
current: Installed, original: Installed, target: Installed, status: 0x800f0922, failure
source: Execute, failure details: "(null)", client id: DISM Package Manager Provider,
initiated offline: False, execution sequence: 1433, first merged sequence: 1433,
pending decision: InteractiveInstallFailed, primitive execution context: Interactive
SQM: execute time performance datapoint is invalid. [HRESULT = 0x80070490 -
ERROR_NOT_FOUND]
SQM: Failed to initialize Win SAT assessment. [HRESULT = 0x80040154 - Unknown
Error]
SQM: average disk throughput datapoint is invalid [HRESULT = 0x80040154 -
Unknown Error]
SQM: Upload requested for report: PackageChangeEnd_Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
session id: 142862, sample type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
TI: CBS has queried the current reboot required state: 0
SQM: Reporting selectable update change for package: Microsoft-Windows-
Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
update: Microsoft-Windows-Deployment-Services-Admin-Pack, start: Staged,
applicable: Resolved, target: Resolved, client id: DISM Package Manager Provider,
initiated offline: False, execution sequence: 1433, first merged sequence: 1433,
download source: 0, download time (secs): 4294967295, download status: 0x0
(S_OK),reboot required: False, overall result:0x800f0922 (CBS_E_INSTALLERS_FAILED)
SQM: Upload requested for report: UpdateChange_Microsoft-Windows-
Deployment-Services-Admin-Pack_Microsoft-Windows-Deployment-Services-UI-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, session id: 142860, sample
type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
SQM: Reporting package change for package: Microsoft-Windows-Deployment-
Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current:
Installed, pending: Default, start: Installed, applicable: Installed, target: Installed,
limit: Installed, hotpatch status: DisabledBecauseNoHotpatchPackagesInitiated,
status: 0x0, failure source: Execute, reboot required: False, client id: DISM Package
Manager Provider, initiated offline: False, execution sequence: 1433, first merged
sequence: 1433 reboot reason: REBOOT_NOT_REQUIRED RM App session: -1 RM
App name: N/A FileName in use: N/A
SQM: Upload requested for report: PackageChangeBegin_Microsoft-Windows-
Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
session id: 142859, sample type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
SQM: Reporting package change completion for package: Microsoft-Windows-
Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
current: Installed, original: Installed, target: Installed, status: 0x800f0922, failure
source: Execute, failure details: "(null)", client id: DISM Package Manager Provider,
 initiated offline: False, execution sequence: 1433, first merged sequence: 1433,
pending decision: InteractiveInstallFailed, primitive execution context: Interactive
SQM: execute time performance datapoint is invalid. [HRESULT = 0x80070490 -
ERROR_NOT_FOUND]
SQM: Failed to initialize Win SAT assessment. [HRESULT = 0x80040154 - Unknown
Error]
SQM: average disk throughput datapoint is invalid [HRESULT = 0x80040154 -
Unknown Error]
SQM: Upload requested for report: PackageChangeEnd_Microsoft-Windows-
Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384,
session id: 142862, sample type: Standard
SQM: Ignoring upload request because the sample type is not enabled: Standard
FinalCommitPackagesState: Completed persisting state of packages
Enabling LKG boot option
Exec: Processing complete. Session: 30651968_3203616141, Package: Microsoft-
Windows-ServerCore-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384
[HRESULT = 0x800f0922 - CBS_E_INSTALLERS_FAILED]
Failed to perform operation. [HRESULT = 0x800f0922 - CBS_E_INSTALLERS_FAILED]
Session: 30651968_3203616141 finalized. Reboot required: no [HRESULT =
0x800f0922 - CBS_E_INSTALLERS_FAILED]
Failed to FinalizeEx using worker session [HRESULT = 0x800f0922]

Cause
This issue can occur if there are more than 65,000 files in the Windows Temp directory.
The Windows Temp directory is located at C:\Windows\Temp . Check Windows
environment variables to confirm the location of the Windows Temp directory.

Resolution
To resolve the problem, delete the contents of the Windows Temp folder (normally
C:\Windows\Temp ), and then again try to remove the Windows Server role or feature.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Failed to be changed to the Absent
state. Status: 0x800f0922" when
installing updates in Windows Server
2019
Article • 02/19/2024

This article helps fix the "Failed to be changed to the Absent state. Status: 0x800f0922"
error when installing updates in Windows Server 2019.

You receive the error code 0x800f0922 when you try to install an update in Windows
Server 2019. For example:

Package KB5027222 failed to be changed to the Absent state. Status: 0x800f0922

In the CBS.log file, you see the following entries with a failed status by searching
completion status , and the package fails to be changed to the Absent state:

Output

<DateTime>, Info CSI 00000e61 Begin executing advanced

installer phase 38 index 825 (sequence 864)
Old component: [l:157 ml:158]'Microsoft-Windows-DLNA-MDEServer,
Culture=neutral, Version=10.0.17763.1697, PublicKeyToken=<PublicKeyToken> ,
ProcessorArchitecture=amd64, versionScope=NonSxS'
New component: [l:154 ml:155]'Microsoft-Windows-DLNA-MDEServer,
Culture=neutral, Version=10.0.17763.1, PublicKeyToken=<PublicKeyToken>,
ProcessorArchitecture=amd64, versionScope=NonSxS'
Install mode: install
Smart installer: false
Installer ID: {<Installer ID>}
Installer name: 'HTTP Installer'
<DateTime>, Error [0x01803e] CSI 00000e64 (F) Failed execution of
queue item Installer: HTTP Installer ({<Installer ID>}) with HRESULT
HRESULT_FROM_WIN32(1058). Failure will not be ignored: A rollback will be
initiated after all the operations in the installer queue are completed;
installer is reliable[gle=0x80004005]
...........
CSIPERF:AIDONE;{<Installer ID>};Microsoft-Windows-DLNA-MDEServer, version
10.0.17763.1, arch amd64, nonSxS, pkt {l:8 b:<PublicKeyToken>};8529us
<DateTime>, Info CSI 00000e6e End executing advanced
installer (sequence 864)
Completion status: HRESULT_FROM_WIN32(ERROR_ADVANCED_INSTALLER_FAILED)
…
<DateTime>, Info CBS WER: Generating failure report for
package: Package_for_RollupFix~<PublicKeyToken>~amd64~~17763.4499.1.5,
 status: 0x80070422, failure source: CSI Other, start state: Installed,
target state: Absent, client id: Software Explorer

In the log file, the error code 1058 indicates that the HTTP service can't be started
because it's disabled or there's no enabled device associated with it.

Enable the HTTP service

To fix this issue, follow these steps:

1. In Registry Editor, go to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP
2. Change the Start registry value to 3.
3. Close Registry Editor and install the update again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Failed to schedule Software Protection
service for restart error in Windows
Server 2012
Article • 02/19/2024

This article provides a solution to an error that occurs when the Network Service
account doesn't have permissions to the SoftwareProtectionPlatform folder.

Applies to: Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2
Original KB number: 3033200

Symptoms
You may frequently receive the following event in the Application log for the Software
Protection service:

Cause
The issue may occur if one or more of the following conditions are true:

The Task Scheduler service is disabled.

The Software Protection Platform service isn't running under the NETWORK
SERVICE account.
Read permissions for the NETWORK SERVICE account are missing on the following
folder: C:\Windows\System32\Tasks\Microsoft\Windows\SoftwareProtectionPlatform

Resolution
To resolve this issue, follow these steps:

1. Verify that the Task Scheduler service is running.

2. Open the Computer Management tool, and then navigate to Configuration ->
Task Scheduler -> Task Scheduler Library -> Microsoft -> Windows ->
SoftwareProtectionPlatform.
3. On the General tab of SoftwareProtectionPlatform, select the security options,
and then verify that the Software Protection Platform service is set to use the
NETWORK SERVICE account.
 4. In Windows Explorer, browse to the
C:\Windows\System32\Tasks\Microsoft\Windows\SoftwareProtectionPlatform folder,

and then verify that the NETWORK SERVICE account has Read permissions for that
folder.
5. Restart the Software Protection service if it's running.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0x80004005 when you try to
install or start the Network Policy Server
role service
Article • 02/19/2024

This article provides a solution to fix the error 0x80004005 that occurs when you install
or start the Network Policy Server role service.

Applies to: Windows Server 2012 R2

Original KB number: 981478

Symptoms
When you try to install or start the Network Policy Server role service on a computer
that is running Windows Server 2008 R2, the role is not installed, or the service is not
started. Additionally, you receive an error message that resembles the following:
Windows could not start the Network Policy Server service on Local Computer. Error
0x80004005 Unspecified error

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base: 322756 How to back up and restore the registry in Windows

To resolve this problem, set the NT AUTHORITY\NETWORK SERVICE subkey in the

registry to 1. To do this, follow these steps:

1. Start Registry Editor. To do this, click Start, type regedit in the Start Search box,
and then press ENTER.
 If you are prompted for an administrator password or for confirmation, type the
password or provide confirmation.

2. Locate and then click to select the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\VssAccessControl

3. Right-click NT AUTHORITY\NETWORK SERVICE, and then click Modify.

4. In the Value data box, type 1, and then click OK.

5. On the File menu, click Exit to exit Registry Editor.

6. Stop all instances of the Lashost.exe process.

7. Restart the Network Policy Server service.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Fix Windows Update errors by using the
DISM or System Update Readiness tool
Article • 02/19/2024

This article offers you advanced manual methods to fix problems that prevent Windows
Update from installing successfully by using the System Update Readiness Tool or the
Deployment Image Servicing and Management (DISM) tool.

７ Note

This article is intended for use by support agents and IT professionals. If you're
home users and looking for more information about fixing Windows update errors,
see Fix Windows Update errors .

Original KB number: 947821

Common corruption errors

Windows updates may fail to install if there are corruption errors. The following table
lists the possible error codes for Windows Update for your reference:

ﾉ Expand table

Code Error Description

0x80070002 ERROR_FILE_NOT_FOUND The system cannot find the

file specified.

0x8007000D ERROR_INVALID_DATA The data is invalid.

0x800F081F CBS_E_SOURCE_MISSING The source for the package

or file not found.

0x80073712 ERROR_SXS_COMPONENT_STORE_CORRUPT The component store is in

an inconsistent state.

0x800736CC ERROR_SXS_FILE_HASH_MISMATCH A component's file does not

match the verification
information present in the
component manifest.

0x800705B9 ERROR_XML_PARSE_ERROR Unable to parse the

requested XML data.
 Code Error Description

0x80070246 ERROR_ILLEGAL_CHARACTER An invalid character was

encountered.

0x8007370D ERROR_SXS_IDENTITY_PARSE_ERROR An identity string is

malformed.

0x8007370B ERROR_SXS_INVALID_IDENTITY_ATTRIBUTE_NAME The name of an attribute in

an identity is not within the
valid range.

0x8007370A ERROR_SXS_INVALID_IDENTITY_ATTRIBUTE_VALUE The value of an attribute in

an identity is not within the
valid range.

0x80070057 ERROR_INVALID_PARAMETER The parameter is incorrect.

0x800B0100 TRUST_E_NOSIGNATURE No signature was present in

the subject.

0x80092003 CRYPT_E_FILE_ERROR An error occurred while

Windows Update reads or
writes to a file.

0x800B0101 CERT_E_EXPIRED A required certificate is not

within its validity period
when verifying against the
current system clock or the
time stamp in the signed
file.

0x8007371B ERROR_SXS_TRANSACTION_CLOSURE_INCOMPLETE One or more required

members of the transaction
are not present.

0x80070490 ERROR_NOT_FOUND Windows could not search

for new updates.

0x800f0984 PSFX_E_MATCHING_BINARY_MISSING Matching component

directory exist but binary
missing

0x800f0986 PSFX_E_APPLY_FORWARD_DELTA_FAILED Applying forward delta

failed

0x800f0982 PSFX_E_MATCHING_COMPONENT_NOT_FOUND Can't identify matching

component for hydration

For example, an update might not install if a system file is damaged. The DISM or
System Update Readiness tool may help you fix some Windows corruption errors.
Check this page for Windows Update troubleshooting scenarios.

Solution 1: Use DISM

７ Note

The solution mentioned in this section applies to Modern Windows versions like
Windows 11, Windows 10, Windows Server 2016, or later. For Windows 7 and
Windows Server 2008 R2, check Solution 2: Use the System Update Readiness
tool.

To resolve this problem, use the DISM tool. Then, install the Windows update or service
pack again.

1. Open an elevated command prompt. To do this, open the Start menu or Start
screen, type Command Prompt, right-click Command Prompt, and then select Run
as administrator. If you're prompted for an administrator password or for a
confirmation, type the password, or select Allow.

2. Type the following command, and then press Enter. It may take several minutes for
the command operation to be completed.

Console

DISM.exe /Online /Cleanup-image /Restorehealth

） Important

When you run this command, DISM uses Windows Update to provide the files
that are required to fix corruptions. However, if your Windows Update client is
already broken, use a running Windows installation as the repair source, or
use a Windows side-by-side folder from a network share or from a removable
media, such as the Windows DVD, as the source of the files. To do this, run the
following command instead:

Console

DISM.exe /Online /Cleanup-Image /RestoreHealth

/Source:C:\RepairSource\Windows /LimitAccess
 ７ Note

Replace the C:\RepairSource\Windows placeholder with the location of your

repair source. For more information about using the DISM tool to repair
Windows, reference Repair a Windows Image.

3. Type the sfc /scannow command and press Enter. It may take several minutes for
the command operation to be completed.

4. Close the command prompt, and then run Windows Update again.

DISM creates a log file (%windir%/Logs/CBS/CBS.log) that captures any issues that the
tool found or fixed. %windir% is the folder in which Windows is installed. For example,
the %windir% folder is C:\Windows.

Solution 2: Use the System Update Readiness

tool

７ Note

The solution mentioned in this section is applicable for Windows 7 and Windows
Server 2008 R2. For Modern Windows versions like Windows 11, Windows 10,
Windows Server 2016, or later, check Solution 1: Use DISM.

To resolve this problem, use the System Update Readiness tool. Then, install the
Windows update or service pack again.

1. Download the System Update Readiness tool.

Go to Microsoft Update Catalog and download the tool that corresponds to the
version of Windows that's running on your computer. For more information about
how to find the version of Windows that you installed, see Find out if your
computer is running the 32-bit or 64-bit version of Windows .

７ Note

This tool is updated regularly, and we recommend that you always download
the latest version. This tool isn't available in every supported language.

2. Install and run the tool.

 a. Select Download on the Download Center webpage, and then do one of the
following:

To install the tool immediately, select Open or Run, and then follow the
instructions on your screen.
To install the tool later, select Save, and then download the installation file
to your computer. When you're ready to install the tool, double-click the
file.

b. In the Windows Update Standalone Installer dialog box, select Yes.

3. When the tool is installed, it automatically runs. Although it typically takes less
than 15 minutes to run, it might take much longer on some computers. Even if the
progress bar seems to have stopped, the scan is still running, so don't select
Cancel.

4. When you see Installation complete, select Close.

 5. Reinstall the update or service pack you were trying to install previously.

To manually fix corruption errors that the tool detects but can't fix, see How to fix errors
that are found in the CheckSUR log file.

Solution 3: Use Microsoft Update Catalog

You can also try to download the update package directly from Microsoft Update
Catalog , and then install the update package manually.

For example, you may have problems when you try to install updates from Windows
Update. In this situation, you can download the update package and try to install the
update manually. To do this, follow these steps:

1. Open the Microsoft Update Catalog page for KB3006137 .

2. Find the update that applies to your operating system appropriately in the search
results, and then select the Download button.

3. Select the link of the file to download the update.

 4. Select Close after the download process is done. Then, you can find a folder that
contains the update package in the location that you specified.

5. Open the folder, and then double-click the update package to install the update.

What does the System Update Readiness tool

do

Verify the integrity of resources

The System Update Readiness tool verifies the integrity of the following resources:

Files that are located in the following directories:

%SYSTEMROOT%\Servicing\Packages
%SYSTEMROOT%\WinSxS\Manifests
Registry data that's located under the following registry subkeys:
HKEY_LOCAL_MACHINE\Components
HKEY_LOCAL_MACHINE\Schema
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Component
Based Servicing
This list may be updated at any time.

When the System Update Readiness tool detects incorrect manifests, Cabinets, or
registry data, it may replace the incorrect data with a corrected version.

Logging
The System Update Readiness tool creates a log file that captures any issues that the
tool found or fixed. The log file is located here:

%SYSTEMROOT%\Logs\CBS\CheckSUR.log
%SYSTEMROOT%\Logs\CBS\CheckSUR.persist.log

Fix errors found in the CheckSUR log file

To manually fix corruption errors that the System Update Readiness tool detects but
can't fix, follow these steps:

1. Open %SYSTEMROOT%\Logs\CBS\CheckSUR.log.

７ Note

%SYSTEMROOT% is an environment variable that saves the folder in which

Windows is installed. For example, generally, the %SYSTEMROOT% folder is
C:\Windows.

2. Identify the packages that the tool can't fix. For example, you may find the
following information in the log file:

Output

Summary:

Seconds executed: 264

Found 3 errors
CBS MUM Missing Total Count: 3
Unavailable repair files:

servicing\packages\Package_for_KB958690_sc_0~31bf3856ad364e35~amd64~~6.
0.1.6.mum
...

In this case, the package that's corrupted is KB958690.

 3. Download the package from Microsoft Download Center or Microsoft Update
Catalog .

4. Copy the package (.msu) to the %SYSTEMROOT%\CheckSUR\packages directory. By

default, this directory doesn't exist, and you need to create it.

5. Rerun the System Update Readiness tool.

If you're a technical professional, see How to fix errors found in the CheckSUR.log for
another option on fixing errors in the CheckSUR.log.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to block user access to Windows
Update on Windows Server
Article • 02/19/2024

This article describes how to block user access to Windows Update on Windows Server.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4014345

Symptoms
The default settings in Windows Server allow user who is not an administrator to scan
for and apply Windows Updates. Administrators may want to change this setting to limit
access to Windows Updates, especially in Remote Desktop Services Host deployments.

More Information
To change this setting, use the Group Policy "Remove access to use all Windows update
features." The full path to this Group Policy is:
Computer Configuration\Administrative Templates\Windows Components\Windows
update\Remove access to use all Windows update features

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How To Use the Recovery Console on a
Computer That Does Not Start
Article • 02/19/2024

This article describes how to use the Recovery Console on a computer that does not
start.

Applies to: Windows Server 2003

Original KB number: 326215

Summary
This step-by-step article describes how to use Recovery Console to recover a Windows
Server 2003-based computer that does not start.

The Recovery Console is a command-line tool that you can use to repair Windows if the
computer does not start correctly. You can start the Recovery Console from the
Windows Server 2003 CD, or at startup, if you previously installed the Recovery Console
on the computer.

Use the Recovery Console on a Computer that Does Not

Start

７ Note

You must be logged on as Administrator or as a member of the Administrators

group to perform this procedure. Also, if your computer is connected to a network,
network policy settings may prevent you from completing this procedure.

To run the Recovery Console, follow these steps:

1. Configure the computer to start from the CD or the DVD drive. For more
information, see the computer documentation or contact the computer
manufacturer.

2. Insert the Windows Server 2003 CD in the computer's CD or DVD drive.

3. Restart the computer.

 4. When you receive the message that prompts you to press any key to start from the
CD, press a key to start the computer from the Windows Server 2003 CD.

5. When the Welcome to Setup screen appears, press the R key to start the Recovery
Console.

6. Select the Windows installation that you must access from the Recovery Console.

7. Follow the instructions that appear on the screen, type the Administrator
password, and then press ENTER.

8. At the command prompt, type the appropriate Recovery Console commands to

repair your Windows Server 2003 installation.

For a list of commands that are available in the Recovery Console, type
help at the command prompt, and then press ENTER.

７ Note

Alternatively, you can install the Recovery Console as a startup option on the
computer so that it is always available. For information about how to do so,
see the Precautionary Measures section in this article.

9. To quit the Recovery Console and restart the computer, type

exit at the command prompt, and then press ENTER.

Recovery Console Commands

The following list describes the available commands for the Recovery Console:

Attrib changes attributes on one file or folder.

Batch executes commands that you specify in the text file, InputFile. OutputFile
holds the output of the commands. If you omit the OutputFile argument, output is
displayed on the screen.

Bootcfg is used for boot configuration and recovery. You can use the bootcfg
command to make changes to the Boot.ini file.

CD (chdir) operates only in the system directories of the current Windows

installation, in removable media, in the root directory of any hard disk partition, or
in the local installation sources.
Chkdsk: The /p switch runs Chkdsk even if the drive is not flagged as dirty. The /r
switch locates bad sectors and recovers readable information. This switch implies
/p. Chkdsk requires Autochk. Chkdsk automatically looks for Autochk.exe in the
startup folder or in the boot folder. If Chkdsk cannot find the file in the startup
folder, it looks for the Windows Server 2003 installation CD. If Chkdsk cannot find
the installation CD, it prompts the user for the location of Autochk.exe.

Cls clears the screen.

Copy copies one file to a target location. By default, the target cannot be
removable media, and you cannot use wildcard characters. Copying a compressed
file from the Windows Server 2003 installation CD automatically decompresses the
file.

Del (delete) deletes one file. Del operates in the system directories of the current
Windows installation, in removable media, in the root directory of any hard disk
partition, or in the local installation sources. By default, you cannot use wildcard
characters.

Dir displays a list of all files, including hidden and system files.

Disable disables a Windows system service or a Windows driver. The servicename

argument is the name of the service or the driver that you want to disable. When
you use this command to disable a service, it displays the service's original startup
type before changing the type to SERVICE_DISABLED. It is a good idea to note the
original startup type so that you can use the enable command to restart the
service.

Diskpart manages partitions on hard disk volumes.

The /add option creates a new partition.
The /delete option deletes an existing partition.
The device-name argument is the device name for a new partition. One example
of a device name for a new partition is \device\harddisk0.
The drive-name argument is the drive letter for a partition that you are deleting,
such as D: .
Partition-name is the partition-based name for a partition that you are deleting,
and can be used instead of the drive-name argument. One example of a
partition-based name is \device\harddisk0\partition1.
The size argument is the size in megabytes of a new partition.

Enable enables a Windows system service or a Windows driver. The servicename

argument is the name of the service or the driver that you want to enable, and
start_type is the startup type for an enabled service. The startup type uses one of
the following formats:

Console

SERVICE_BOOT_START
SERVICE_SYSTEM_START
SERVICE_AUTO_START
SERVICE_DEMAND_START

Exit quits the Recovery Console and then restarts the computer.

Expand expands a compressed file. The source argument is the file that you want to
expand. By default, you cannot use wildcard characters. The destination argument
is the directory for the new file. By default, the destination cannot be removable
media and cannot be read-only. You can use the attrib command to remove the
read-only attribute from the destination directory. The option /f:filespec is
required if the source contains more than one file. This option permits wildcard
characters. The /y switch disables the overwrite confirmation prompt. The /d switch
specifies that the files should not be expanded and displays a directory of the files
in the source.

Fixboot writes a new boot sector on the system partition. The fixboot command

is only supported on x86-based computers.

Fixmbr repairs the boot partition's master boot record (MBR). The device-name
argument is an optional name that specifies the device that requires a new MBR.
Omit this variable when the target is the boot device. The fixmbr command is only
supported on x86-based computers.

Format formats a disk. The /q switch performs a quick format. The /fs: file-system
switch specifies the file system.

Help lists all the commands that the Recovery Console supports. For more
information about a specific command, type help
command-name or
command-name /? .

Listsvc displays all available services and drivers on the computer.

Logon displays detected installations of Windows and requests the local

Administrator password for those installations. Use this command to move to
another installation or subdirectory.
 Map displays currently active device mappings. Include the arc option to specify
the use of Advanced RISC Computing (ARC) paths instead of Windows device
paths. (ARC is the format that is used for the Boot.ini file.)

Md (Mkdir) creates a directory. The command operates only in the system

directories of the current Windows installation, in removable media, in the root
directory of any hard disk partition, or in the local installation sources.

More/Type displays the specified text file to the screen.

Rd (rmdir) removes a directory. The command operates only in the system

directories of the current Windows installation, in removable media, in the root
directory of any hard disk partition, or in the local installation sources.

Ren (rename) renames a single file. The command operates only in the system
directories of the current Windows installation, in removable media, in the root
directory of any hard disk partition, or in the local installation sources. You cannot
specify a new drive or path as the target.

Set displays and sets the Recovery Console environment variables.

Systemroot sets the current directory to %systemroot%.

Precautionary Measures

How to Install the Recovery Console as a Startup Option

You can install the Recovery Console on a working computer so that it is available to use
if you cannot start Windows. This precautionary measure can save you time if you must
use the Recovery Console.

７ Note

You must be logged on as Administrator or as a member of the Administrators

group to complete this procedure. Also, if your computer is connected to a
network, network policy settings may prevent you from completing this procedure.

To install the Recovery Console as a startup option:

1. While Windows is running, insert the Windows Server 2003 CD in the computer's
CD or DVD drive.

2. Click Start, and then click Run.

 3. In the Open box, type the following line, where
drive is the drive letter of the computer's CD drive or DVD drive that contains the
Windows Server 2003 CD, and then click OK:
**drive: \i386\winnt32.exe /cmdcons

To install Recovery console as a startup option for Windows Server 2003 x64
edition, type the following line:
**drive: \amd64\winnt32.exe /cmdcons

4. Click Yes when the message appears, to install the Recovery Console.

5. When you receive the message that states that the Recovery Console is
successfully installed, click OK.

6. To use the Recovery Console, restart the computer, and then use the ARROW keys
to select Microsoft Windows Recovery Console in the Please select the operating
system to start list.

How to Remove the Recovery Console

As a precaution, do not remove the Recovery Console. However, if you want to remove
the Recovery Console, you must do so manually.

To remove the Recovery Console, follow these steps:

1. Restart the computer.

2. Click Start, and then click My Computer.

3. Turn on the Show hidden files and folders option (if it is not already turned on). To
do so, follow these steps:
a. On the Tools menu, click Folder Options.
b. Click the View tab.
c. Click Show hidden files and folders, click to clear the Hide protected operating
system files (Recommended) check box (if it is selected), and then click OK.

4. Double-click the drive letter that represents the hard disk on which you installed
the Recovery Console.

5. Delete the Cmdcons folder from the root folder, and then delete the Cmldr file. To
do so, follow these steps:
a. Right-click Cmdcons, and then click Delete. Follow the instructions that appear
on the screen, and then click Yes to confirm the deletion.
 b. Right-click Cmldr, and then click Delete. Follow the instructions that appear on
the screen, and then click Yes to confirm the deletion.

6. Remove the Recovery Console entry from the Boot.ini file. To do so, follow these
steps.

２ Warning

Incorrectly modifying the Boot.ini file may prevent your computer from
restarting. Make sure that you delete only the entry for the Recovery Console.

a. At the root folder, right-click the Boot.ini file, and then click Properties. Click to
clear the Read-only check box, and then click OK.

b. Open the Boot.ini file in Notepad.

c. Locate the Recovery Console entry, and then delete it. The Recovery Console
entry looks similar to the following line:
C:\cmdcons\bootsect.dat="Microsoft Windows Recovery Console" /cmdcons

d. On the File menu, click Save, and then click Exit to quit Notepad.

7. Change the attribute for the Boot.ini file back to Read-only. To do so, right-click
Boot.ini, and then click Properties. Click to select the Read-only check box, and
then click OK.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Microsoft Product Support Reporting
Tool for Microsoft Software Update
Services v 5.2.2003.0
Article • 02/19/2024

This article provides some steps for installing the Microsoft Product Support Reporting
Tool for Microsoft Software Update Services.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 823398

Summary
This article describes how to install the Microsoft Product Support Reporting Tool for
Microsoft Software Update Services. The Microsoft Product Support Reporting Tool (also
known as MPS_REPORTS) is a compressed software package that contains scripts and
utilities that you can use to capture critical system, diagnostic, and configuration
information about your computer. This tool includes the Software Update Services
edition that is described in this article and other editions that are designed for specific
support issues.

More information
You can use the Microsoft Product Support Reporting Tool for Software Update Services
to gather detailed information about the current configuration of a computer. The
information you collect helps a Microsoft Support Professional isolate the problem.

The Microsoft Product Support Reporting Tool for Software Update Services works on
Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0. When the tool
runs, it detects the Windows operating system that is installed to determine which
commands it will use to collect information. The reporting tool does not change any
registry entries and does not modify the operating system.

How to Use the Microsoft Product Support Reporting

Tool for Software Update Services
To use the Microsoft Product Support Reporting Tool for Software Update Services,
follow these steps:
 1. Download Mpsrpt_sus.exe.

2. Double-click the copy of Mpsrpt_sus.exe that you saved to your computer, and
then click Yes to accept the End User License Agreement (EULA).

７ Note

Be patient while the tool collects information. The tool may stop responding
for five to fifteen minutes.

3. The tool creates a .cab file named Computer_name MPSReports Date.cab in the
System_root\MPSReports\Msus\Cab folder. The .cab file contains the reports that
are generated by the Microsoft Product Support Reporting Tool. If the .cab file is
not created, copy all the files in the System_root\MPSReports\Msus folder to a
compressed (zipped) file.

７ Note

The System_root folder is the folder where you installed the operating system.
Typically, this folder is the C:\Winnt folder or the C:\Windows folder.

4. Send the .cab file or compressed (zipped) file to your Microsoft Support
Professional using the e-mail address the Microsoft Support Professional provides.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

List of updates in Windows Server 2003
Service Pack 2
Article • 02/19/2024

This article lists problems that are fixed in Microsoft Windows Server 2003 Service Pack 2
(SP2).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 914962

Summary
Service packs are cumulative. Which means that the problems that are fixed in a service
pack are also fixed in later service packs.

This article contains a reference to the Maintenance Decision Support System (MDSS)
utility, which is a utility that Microsoft Support provides as-is and doesn't support.
Microsoft makes no warranty, implied or otherwise, about the performance or reliability
of the MDSS utility.

More information
This article contains a list of Microsoft Knowledge Base (KB) articles that describe the
fixes and updates that are contained in Microsoft Windows Server 2003 Service Pack 2
(SP2).

This article is primarily intended to help IT Professionals and corporate helpdesks in

supporting and maintaining a company's computer system.

For more information about Windows Server 2003 SP2, see Release Notes for Microsoft
Windows Server 2003 Service Pack 2.

７ Note

The x64-based versions of Windows Server 2003 and Microsoft Windows XP

Professional x64 Edition are based on the Windows Server 2003 code tree. Service
and support activities for Windows XP Professional x64 Edition use the Windows
Server 2003 tree and don't use the Windows XP client tree.
Update list
For more information about the updates that are included in Microsoft Windows Server
2003 SP2, click the following article numbers to view the articles in the Microsoft
Knowledge Base.

ﾉ Expand table

Article Article title Category

number

925104 The System log reports many "PerfOS event ID: 2001" errors when Admin Tools
you use a Microsoft Windows Server 2003-based computer that has
more than 32 processors

902400 MS05-051: Vulnerabilities in MS DTC and COM+ could allow remote COM+
code execution

910695 FIX: You cannot obtain detailed error information about DCOM COM+
10009 errors in Windows Server 2003

244139 Windows feature lets you generate a memory dump file by using Drivers
the keyboard

898544 FIX: You cannot burn a CD or a DVD on a computer that is running Drivers
Windows Server 2003

921883 MS06-040: Vulnerability in Server service could allow remote code Distributed
execution Systems (DS)

906866 You may receive a "STOP 0x00000035 File Systems

NO_MORE_IRP_STACK_LOCATIONS" error message when you try to
log on to a domain

922582 Error message when you try to update a Microsoft Windows-based File Systems
computer: "0x80070002"

896358 MS05-026: A vulnerability in HTML Help could allow remote code Help
execution

917557 FIX: You may experience slow performance when you use Integrated IIS 6.0
Windows authentication together with the Kerberos authentication
protocol in IIS 6.0

896688 MS05-052: Cumulative security update for Internet Explorer Internet

Explorer

899812 You receive a "Internet Explorer has encountered a problem and Internet
needs to close" error when you use Internet Explorer 6 to view a Explorer
Web page that hosts an ActiveX control
 Article Article title Category
number

912812 MS06-013: Cumulative security update for Internet Explorer Internet

Explorer

894081 Nlb Networking

904942 Authentication fails when you use Outlook or Outlook Express to try Security
to log on to a HTTP-based mail server if you use Internet Explorer
version 7.0

919557 You receive pre-authentication errors when you use keytab files that Security
are generated by using the Ktpass.exe tool on a Windows Server
2003 SP1-based computer

922706 How to use Certificate Services Web enrollment pages together with Security
Windows Vista

824995 Windows starts and ends daylight saving time incorrectly if the time Shell
zone is set to (GMT+02:00) Cairo

901115 A Terminal Services client computer may make beep sounds after Terminal
you connect to a Windows Server 2003 Service Pack 1-based Server
computer

902346 FIX: Error messages when you use a Windows Management WMI
Instrumentation (WMI) query to register WMI events on a computer
that is running Windows Server 2003 or Windows XP: "0x80041032"
and "0x80041003"

This service pack also includes the fixes and the updates that are contained in Windows
Server 2003 Service Pack 1 (SP1).

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to re-register Windows
client/server in WSUS
Article • 02/19/2024

This article provides the steps to re-register a Windows client/server in Windows Server
Update Services (WSUS).

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 555974

Summary
This article will help you to re-register a Windows client/server in WSUS.

Tips
To re-register a Windows client/server in WSUS, review the following instructions:

1. Run gpupdate /force command on the Windows client/server that have a

registration issue in WSUS.

2. Run wuauclt /detectnow command on the Windows client/server that have a

registration issue in WSUS.

 Tip

You can use the Event Viewer to review the re-registration.

3. In rare cases, you may need to run wuauclt.exe /resetauthorization /detectnow

command on the Windows client/server that have a registration issue in WSUS.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the
suitability, reliability, or accuracy of the information and related graphics contained
herein. All such information and related graphics are provided "as is" without warranty
of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and
conditions with regard to this information and related graphics, including all implied
warranties and conditions of merchantability, fitness for a particular purpose,
workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental,
special, consequential damages or any damages whatsoever including, without
limitation, damages for loss of use, data or profits, arising out of or in any way
connected with the use of or inability to use the information and related graphics
contained herein, whether based on contract, tort, negligence, strict liability or
otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of
damages.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SystemInfo.exe does not display all
updates in Windows Server 2003
Article • 02/19/2024

This article provides a workaround for an issue where SystemInfo.exe can't display all
installed updates.

Applies to: Windows Server 2003

Original KB number: 2644427

Symptoms
When using SystemInfo.exe in Windows Server 2003 to display a list of installed hotfixes,
some hotfixes may not be listed if over 200 are installed.

Cause
There is a buffer size limitation that does not allow all system update hotfixes to be
displayed.

Workaround
Microsoft is currently aware of this issue. To work around this issue, run the following
command at a Windows command prompt:

Console

wmic qfe list

More information
Windows Server 2003 is currently at end of life cycle and Service Packs are no longer
being developed for this product. When installing a Service Pack, the number of hotfixes
being shown by the SystemInfo.exe tool is reduced to a much smaller number.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

System Partition goes offline after
installing some third-party disk or
Storage Management Software
Article • 02/19/2024

This article provides a resolution to an issue where System Partition goes offline after
installing some third-party disk or Storage Management Software.

Applies to: Windows Server 2012 R2

Original KB number: 2419286

Symptoms
Issue 1

When installing Hyper-V Role, you may get the following error:

Failure configuring windows features

Reverting changes
Do not turn off your computer

Under CBS.log, look for the following log:

Process output: [l:100 [100]"The boot configuration data store could not be
opened. The system cannot find the file specified."][gle=0x80004005]

Issue 2

When you run Cluster validation, Storage validation fails, under Cluster Validation
Reports we can see the following error:

List all disks visible to one or more nodes (including non-cluster disks).
Prepare storage for testing
Preparing storage for testing on node Node1.contoso.com
Preparing storage for testing on node Node1
Failed to prepare storage for testing on node Node1 status 87
Failed to prepare storage for testing on node Node1 status 87

Issue 3
 When you run Bcdedit /enum all , you get the following error:

The boot configuration data store could not be opened. The system cannot
find the file specified."

Look for the registry key HKEY_LOCAL_MACHINE\BCD00000000. If we check under

HKLM, you will not find the key BCD00000000.

Cause
If some third-party storage disk or Storage Management software is installed, it may
bring all the volume without drive letter offline.

Generally, 100-MB partition is system partition that contains Boot configuration

Database and does not have a drive letter assigned.

Resolution
To solve this issue, use one of the following methods:

From command prompt, run the following commands:

Console

C:\\>Diskpart
C:\Diskpart> List volume
C:\Diskpart> Select volume 1 (Considering this is 100-MB system
partition)
c:\Diskpart> Online volume
C:\Diskpart> exit

From the Disk Management console, assign the drive letter to the 100-MB
partition it should bring the disk online.

To access Disk Management, open command prompt, run the following command:

C:>Diskmgmt.msc

Select the 100-MB volume; Right click on the volume Change drive letter & Path,
assign a drive letter.

Assigning the drive letter will ensure the volume not offline again after a reboot.
 The volumes may go offline if AUTOMOUNT is disabled either while using a third
party storage software or if the user manually disabled the AUTOMOUNT for the
volume. To check this, type the DISKPART> automount command after running
diskpart in the administrator command prompt.

Automatic mounting of new volumes is disabled.

To enable AUTOMOUNT, run the following command

Console

DISKPART> automount enable

Reboot the server and the volume will not go offline.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to temporarily deactivate the
kernel mode filter driver in Windows
Article • 02/19/2024

This article describes how to deactivate the kernel mode filter driver without removing
the corresponding software.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 816071

） Important

This article contains information that shows you how to help lower security settings
or how to turn off security features on a computer. You can make these changes to
work around a specific problem. Before you make these changes, we recommend
that you evaluate the risks that are associated with implementing this workaround
in your particular environment. If you implement this workaround, take any
appropriate additional steps to help protect your system.

Summary
You may want to deactivate the filter driver when you are troubleshooting the following
issues:

File copy or backup problems.

Program errors that occur when you are opening files from network drives or you
are saving files to network drives. For more information about these program
errors, see Slow network performance when you open a file that is located in a
shared folder on a remote network computer .

Event ID 2022 errors messages that occur in the System log, for example:

Disable filter drivers

When you are troubleshooting any one of these issues, frequently, you have to do more
than just stop or disable the services that are associated with the software. Even if you
disable the software component, the filter driver is still loaded when you restart the
computer. You may be forced to remove a software component to find the cause of an
issue. As an alternative to removing the software component, you can stop the relevant
services and disable the corresponding filter drivers in the registry. For example, if you
prevent antivirus software from scanning or filtering files on your computer, you must
also disable the corresponding filter drivers.

To disable filter drivers, you must first identify third-party services and their
corresponding filter drivers. After you do this, follow these steps.

２ Warning

This workaround may make your computer or your network more vulnerable to
attack by malicious users or by malicious software such as viruses. We do not
recommend this workaround but are providing this information so that you can
implement this workaround at your own discretion. Use this workaround at your
own risk.

） Important

An antivirus program is designed to help protect your computer from viruses. You
must not download or open files from sources that you do not trust, visit Web sites
that you do not trust, or open e-mail attachments when your antivirus program is
disabled.

For more information about computer viruses, see How to prevent and remove viruses
and other malware .

1. Stop all services that belong to the software package.

2. Set the Startup type to Disabled. To do this, follow these steps:

a. Click Start, click Control Panel, double-click Administrative Tools, and then
double-click Services.
b. In the Details pane, right-click the service that you want to configure, and then
click Properties.
c. On the General tab, click Disabled in the Startup type box.

3. Set the Start registry key of the corresponding filter drivers to 0x4. A value of 0x4
will disable the filter driver. To do this, follow these steps.

） Important
 This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
added protection, back up the registry before you modify it. Then, you can
restore the registry if a problem occurs. For more information about how to
back up and restore the registry, see How to back up and restore the registry
in Windows .

a. Start Registry Editor.

b. Create a backup of the HKEY_LOCAL_MACHINE\System registry hive.
c. Locate, and then click the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services .

d. Click the entry for the filter driver that you want to disable.
e. Double-click the Start registry setting, and then set it to a value of 0x4.

７ Note

This registry entry typically has a value of 0x3.

4. Restart the computer.

Most antivirus software uses filter drivers that work together with a service to scan for
viruses. These filter drivers are still loaded after the service is deactivated. These filter
drivers scan files as they are opened and closed on a hard disk. For troubleshooting
purposes, temporarily remove the antivirus software or contact the manufacturer of the
software to determine whether a newer version is available.

Example of filter drivers

This section describes some of the typical filter driver names by product:

Antivirus
Inoculan: INO_FLPY and INO_FLTR
Norton: SYMEVENT, NAVAP, NAVEN, and NAVEX
McAfee (NAI): NaiFiltr and NaiFsRec
Trend Micro: Tmfilter.sys and Vsapint.sys

Backup agent
 Backup Agent for Open Files: Ofant.sys

Open Transaction Manager from Veritas BackupExec: Otman.sys (Otman4.sys or

Otman5.sys)

７ Note

Use caution if you disable these filter drivers by using the method that is
described in this article. If you do this, you may receive a stop 0x7b error
message.

The stop 0x7b Inaccessible_Boot_Device error message may occur if the following
registry keys exist and contain references to the Otman5 driver when the
Otman5.sys driver either does not exist on the hard disk or if the driver is set to
disabled.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325

-11CE-BFC1-08002BE10318}\UpperFilters

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{71A27CDD-812A

-11D0-BEC7-08002BE2092F}\UpperFilters

If you experience the stop 0x7b error message, you should back up these
registry keys and delete the Otman5 reference.

Driver registry settings

The following table lists valid settings and their description for the driver's Start and
Type registry settings:

ﾉ Expand table

Value Value Setting Description of Value Setting

Name

Start 0 = SERVICE_BOOT_START Ntldr or Osloader preloads the driver so that it is in

memory when the computer starts.

These drivers are initialized just before the

SERVICE_SYSTEM_START drivers.

Start 1 = SERVICE_SYSTEM_START The driver loads and initializes after

SERVICE_BOOT_START drivers have initialized.
 Value Value Setting Description of Value Setting
Name

Start 2 = SERVICE_AUTO_START Service Control Manager (SCM) starts the driver or

service.

Start 3 = SERVICE_DEMAND_START SCM must start the driver or service on demand.

Start 4 = SERVICE_DISABLED The driver or service does not load or initialize.

Type 1 = SERVICE_KERNEL_DRIVER Device driver.

Type 2= Kernel-mode file system driver.

SERVICE_FILE_SYSTEM_DRIVER

Type 8= File system recognizer driver.

SERVICE_RECOGNIZER_DRIVER

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Installing Windows features and roles
troubleshooting guidance
Article • 02/19/2024

Try our Virtual Agent - It can help you quickly identify and fix Roles and Features

related issues.

This guidance is designed to help troubleshoot issues when adding or removing roles
and features in Windows.

Troubleshooting checklist
1. Check errors in the Windows event log, especially the System event log and the
Windows Setup event log. For example, navigate to the following location in Event
Viewer and search for Event IDs in the range of 4000 to 4099.

Applications And Services Logs\Microsoft\Windows\ServerManager-MultiMachine

2. Try to add or remove a different role or feature. This method will help to determine
if the issue is specific to a role or feature.

3. Verify the state of the component store for any corruption.

a. Run the following command to repair the Windows image. For more
information, see Repair a Windows image.

Dism /Online /Cleanup-Image /RestoreHealth

b. The results are logged in the following log file:

%windir%/Logs/CBS/CBS.log

c. In the log file, search for the following line:

Checking System Update Readiness

4. After verifying the component store and fixing any corruption, run the SFC
/scannow command at an elevated command prompt to scan and restore Windows

files. For more information, see Use the System File Checker tool to repair missing
or corrupted system files .
Common support scenarios
See the following list of common issues for scenario-specific guidance:

ﾉ Expand table

Issue or error Solution

Server Manager is Server Manager can't be used to manage servers that are running a
collecting inventory data. newer version of Windows Server than the version that is running
The wizard will be available Server Manager. For example, Server Manager running in Windows
after data collection 8 as part of Remote Server Administration Tools can't be used to
finishes. manage a server that's running Windows Server 2012 R2.

Error 0x00070543 when Error 0x00070543

selecting Roles in Server
Manager

Error 0x800706BE and can't Error 0x800706BE

view roles or features

Error 0x800F0922 when Error 0x800F0922

trying to uninstall roles or
features

Error 0x800F081F when Error 0x800F081F

installing features

Error 0x800F0818 and can't Error 0x800F0818

add roles or features

For more information, see Install or uninstall roles, role services, or features.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server update
troubleshooting guidance
Article • 02/19/2024

Try our Virtual Agent - It can help you quickly identify and fix common Windows

Update issues.

This solution is designed to get you started on Windows Update troubleshooting

scenarios.

Troubleshooting checklist

Step 1: Identify the issue by examining the event log for

specific errors
1. Open Event Viewer from the Control Panel > Administrative Tools.
2. Look for Windows Update Agent events in the System log, and the errors in the
System and Application logs around the same time that updates were applied.
3. Expand the Event Viewer tree to Application and Service Logs > Microsoft >
Windows > WindowsUpdateClient > Operational.
4. Identify the Update that is failing to install and the failure code.
5. Find the error and the resolution in Common Windows Update errors or Windows
Update error codes by component.

Step 2: Check for Pending Reboot state

If the computer hasn't been restarted, restart the computer.

Step 3: Services Stack update

Install the latest servicing stack update. See Latest Servicing Stack Updates .

Step 4: Run the Windows Update troubleshooter for

Windows
1. Download the troubleshooter, and select Open or Save in the pop-up window. (If
you choose Save, you'll need to open the troubleshooter from the save location.)
 2. Select Next to start the troubleshooter, and follow the steps to identify and fix any
issues.
3. After the troubleshooter finishes, try running Windows Update again. From the
Start button, select Settings > Update & security > Windows Update > Check for
updates, and install any available updates.
4. If applicable, Reset windows update components .

Step 5: Use DISM or System Update Readiness tool to

troubleshoot Windows Update issue
See Fix Windows Update errors by using the DISM or System Update Readiness tool for
more information.

Common issues and solutions

You receive "Update not applicable" error message

Error message

The update is not applicable to your computer.

Cause 1: Update is superseded

To troubleshoot this issue, check that the package that you are installing contains newer
versions of the binaries. Alternatively, check that the package is superseded by another
new package.

Cause 2: Update is already installed

To troubleshoot this issue, verify that the package that you are trying to install isn't
already installed.

Cause 3: Wrong update for architecture

To troubleshoot this issue, verify that the package that you're trying to install matches
the Windows version that you are using. The Windows version information can be found
in the "Applies To" section of the article for each update. For example, Windows Server
2012-only updates cannot be installed on Windows Server 2012 R2-based computers.
Verify that the package you want to install matches the processor architecture of the
Windows version that you are using. For example, an x86-based update can't be
installed on x64-based installations of Windows.

Cause 4: Missing prerequisite update

To troubleshoot this issue, read the package’s related article to find out whether the
prerequisite updates are installed. For example, if you receive the error message in
Windows 8.1 or Windows Server 2012 R2, you might have to install the April 2014
update 2919355 as a prerequisite and one or more pre-requisite servicing updates (KB
2919442 and KB 3173424).
To determine if these prerequisite updates are installed, run this PowerShell command:
get-hotfix KB3173424, KB2919355, KB2919442

If the updates are installed, the command returns the installed date in the InstalledOn
section of the output.

Updates aren't downloading from Windows Server

Update Services (WSUS) or Configuration Manager
Error message:

Failed to connect to Mux due to network or cert errors

To troubleshoot this issue, check the numeric code provided in the error message code:
this corresponds to the winsock error code. Certificate errors are granular (for example,
cert cannot be verified, cert not authorized, etc.)

The device isn't receiving an update that you deployed

To troubleshoot this issue, follow these steps:

1. Check that the device’s updates for the relevant category aren’t paused. See Pause
feature updates and Pause quality updates.

2. Feature updates only: The device might have a safeguard hold applied for the
given feature update version. For more information about safeguard holds, see
Safeguard holds and Opt out of safeguard holds.

3. Check that the deployment to which the device is assigned has the state offering.
Deployments that have the states paused or scheduled won't deploy content to
devices.
 4. Check that the device has scanned for updates and is scanning the Windows
Update service. To learn more about scanning for updates, see Scanning updates.

5. Feature updates only: Verify that the device is successfully enrolled in feature
update management by the deployment service. A device that is successfully
enrolled is represented by a Microsoft Entra device resource with an update
management enrollment for feature updates and has no Microsoft Entra device
registration errors.

6. Expedited quality updates only: Check that the device has the Update Health Tools
installed (available for Windows 10 version 1809 or later in the update described in
KB 4023057 - Update for Windows 10 Update Service components , or a more
recent quality update). The Update Health Tools are required for a device to
receive an expedited quality update. The program’s location on the device is
C:\Program Files\Microsoft Update Health Tools.
To verify its presence, view the installed programs list or use this PowerShell script:

PowerShell

Get-WmiObject -Class Win32\_Product \| Where-Object {$\_.Name -amatch

"Microsoft Update Health Tools"}

The device is receiving an update that you didn't deploy

To troubleshoot this issue, follow these steps:

1. Check that the device is scanning the Windows Update service and not a different
endpoint. If the device is scanning for updates from a WSUS endpoint, for
example, it might receive different updates. To learn more about scanning for
updates, see Scanning updates.
2. Feature updates only: Check that the device is successfully enrolled in feature
update management by the deployment service. A device that isn't successfully
enrolled might receive different updates according to its feature update deferral
period. A device that is successfully enrolled is represented by a Microsoft Entra
device resource with an update management enrollment for feature updates and
has no Microsoft Entra device registration errors.

WSUS troubleshooting

WSUS connection failures

If you are using WSUS 3.0 SP2 on Windows Server 2008 R2, you must have update
4039929 or a later-version update package installed on the WSUS server.

Here's how to verify the server version:

1. Open the WSUS console.

2. Select the server name.
3. Locate the version number under Overview > Connection > Server Version.
4. Check whether the version is 3.2.7600.283 or a later version.

If you are using WSUS on Windows Server 2012 or a later version, you must have one of
the following Security Quality Monthly Rollups or a later-version rollup installed on the
WSUS server:

Windows Server 2012 - KB4039873

Windows Server 2012 R2 - KB4039871
Windows Server 2016 - KB4039396

７ Note

If you're using Configuration Manager with the software update point installed on a
remote site system server, the WSUS Administration Console must be installed on
the site server. For WSUS 3.0 SP2, KB 4039929 or a later update must also be
installed on the WSUS Administration console. A server restart is required after
installing 4039929 (remotely or locally). Check whether the issue persists after
the restart.

To troubleshoot connection failures, follow these steps:

1. Verify that the Update Services service and the World Wide Web Publishing
Service are running on the WSUS server.
2. Verify that the Default website or WSUS Administration website is running on the
WSUS server.
3. Review the IIS logs for the WSUS Administration website (c:\inetpub\logfiles), and
check for errors.

Error code: 80244007

Error message:

SyncUpdates_WithRecovery failed
To fix the issue, follow these steps on the WSUS server:

1. Open an elevated Command Prompt window and go to the following location:

%programfiles%\Update Services\WebServices\ClientWebService

2. Type the following commands, and press Enter after each command:

Console

takeown /f web.config
icacls web.config /grant administrator:(F)
notepad.exe web.config

3. Locate the following line in web.config:

XML

<add key="maxInstalledPrerequisites" value="400"/>

4. Change the value from 400 to 800.

5. Save the web.config file.

6. Run IISReset .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Reference
Log files created by Windows Update
Windows Update troubleshooting
Windows Update common errors and mitigation
Troubleshooting issues with WSUS client agents
PowerShell script to decline superseded updates in WSUS
Windows Server Update Services best practices
WSUS client computers restart without any notification
WSUS client takes too long to finish an update scan
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Update for Business reports:
Troubleshooting guidance
Article • 02/19/2024

Applies to: Windows Server, all supported versions

This article is designed to help get you started on troubleshooting issues that you might
encounter when you use Windows Update for Business reports.

Troubleshooting checklist
Here's a list of the basic steps to resolve most Windows Update for Business reports
issues:

Verify that you belong to the correct roles:

Azure: Either the Log Analytics Reader or Log Analytics Contributor Azure role.
Microsoft Entra: An administrative role.

At a high level, Azure roles control permissions to manage Azure resources, while
Microsoft Entra roles control permissions to manage Microsoft Entra ID resources.
For more information, see Windows Update for Business reports prerequisites:
Permissions.

Verify that at least one device is sending telemetry, especially if you received a
successful save message during enrollment but still haven't seen any data after 48
hours. If no devices are sending telemetry, run the configuration script on the
clients to make sure that they're active and configured correctly.

Verify that the devices are Microsoft Entra joined or Microsoft Entra hybrid joined.

Verify that the devices are turned on, active, and can scan for Windows updates. To
be included in reports, a device must have been active at least one time in the past
28 days.

Make sure that each device has the Allow device name to be sent in Windows
diagnostic data policy enabled.

Check the size of the report. For performance, the default limit for rows in Azure
workbooks is set to 1,000. If your report has more than 1,000 rows, do one of the
following:
Export the report data to Excel to view the whole report.
 To view the information in Logs view, select the three-dot icon that's next to the
component of interest.
Check the policy configuration.

７ Note

If you have questions about report content or customization, see Frequently Asked
Questions about Windows Update for Business reports.

Common issues and solutions

Stuck at the "Waiting for Windows Update for Business

reports data" page
This issue has several potential causes. To resolve the issue, check the following:

Verify that you belong to the correct roles:

Azure: Either the Log Analytics Reader or Log Analytics Contributor Azure role.
Microsoft Entra: An administrative role.

At a high level, Azure roles control permissions to manage Azure resources, and
Microsoft Entra roles control permissions to manage Microsoft Entra resources. For
more information, see Windows Update for Business reports prerequisites:
Permissions.

Verify that at least one device is sending telemetry, especially if you received a
successful save message during enrollment but still haven't seen any data after 48
hours. If no devices are sending telemetry, run the configuration script on the
clients to make sure that they're active and configured correctly.

If the preceding solutions don't apply or don't resolve the issue, use the
Configuration flyout of your administrative console to unenroll and re-enroll. Wait
for 24–48 hours. If the issue persists, contact Microsoft Support.

Devices are missing from reports

This issue has several potential causes. To resolve the issue, check the following:

Verify that the devices are Microsoft Entra joined or Microsoft Entra hybrid joined.
 Verify that the devices are sending telemetry. If the missing devices aren't sending
telemetry, run the configuration script to make sure that they're active and
configured correctly.

Verify that the devices are turned on, active, and can scan for Windows updates. To
be included in reports, a device must have been active at least one time in the past
28 days.

Check the size of the report. For performance, the default limit for rows in Azure
workbooks is set to 1,000. If your report has more than 1,000 rows, do one of the
following:
Export the report data to Excel to view the whole report.
To view the information in Logs view, select the three-dot icon that's next to the
component of interest.

For more in-depth troubleshooting of missing diagnostic data, see Windows Update for
Business reports: How to troubleshoot diagnostic data transmission.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Why you may be prompted to restart
your computer after you install a
security update on a Windows-based
computer
Article • 02/19/2024

This article describes why you may be prompted to restart your Microsoft Windows-
based computer after you install a security update.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 887012

Why you may be prompted to restart your

computer
After you install a security update, you may be prompted to restart your computer if one
of the following conditions is true:

The security update updates a DLL that is loaded in one or more processes that are
required by Windows. The security update can't be completed while the DLL is
loaded. So the security update must stop the process that causes the DLL to be
loaded. Stopping the process will unload the DLL that is required to complete the
update. However, the process in which the DLL is loaded can't be stopped while
Windows is running. For example, the security update that is described in security
bulletin MS04-011 updates many DLLs that are loaded in core operating system
processes that can't be stopped without shutting down Windows.
The security update updates an .exe file that is currently running as a process that
is required by Windows. The update can't be completed while this process is
running. However, you can't force this process to stop unless you shut down
Windows. For example, Csrss.exe is a required process in Windows.
The security update updates a device driver that is currently being used and that is
required by Windows. The update can't be completed while this device driver is
being used. However, you can't unload this device driver unless you shut down
Windows. For example, Disk.sys is a device driver that is required by Windows.
The security update makes changes to the registry. These changes require that you
restart your computer.
 The security update makes changes to registry entries that are read only when you
start your computer.

How to reduce your chances of being

prompted to restart your computer
To reduce your chances of being prompted to restart your computer after you install a
security update, you can try to end the processes use the files that are being updated by
the security update.

To determine whether files that are being updated by a security update are being used
by your computer, you can use Process Explorer from Sysinternals to examine how the
files are being used and by what processes they're being used. You may be able to stop
the services or to end the processes that are using the files. For more information about
Process Explorer, see Windows Sysinternals.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft doesn't guarantee the
accuracy of this third-party contact information.

Except for our own products, Microsoft doesn't support or recommend this product
over others in the same area. We provide this information only as a convenience for our
customers and, excepting our own products, don't provide warranties of any kind, either
express or implied. The warranties that we don't provide include but aren't limited to the
implied warranties of merchantability or fitness for a particular purpose.

How to suppress the message to restart your

computer
To suppress the message to restart your computer, use a command-line switch. The
command-line switch that you use depends on the installer that is used by the security
update. For more information about command-line switches for Windows and IExpress
software update packages, see How does Windows Update work?

When you use Windows Installer, a security update that uses the .msi or the .msp file
name extension is installed on your computer. For more information about command-
line options, see Command-Line Options.

） Important
 In certain cases, you must restart your computer to fully apply the security update.
Your computer may remain vulnerable if the security update isn't fully applied.

Technical support for x64-based versions of

Microsoft Windows
Your hardware manufacturer provides technical support and assistance for x64-based
versions of Windows. Your hardware manufacturer provides support because an x64-
based version of Windows was included with your hardware. Your hardware
manufacturer might have customized the installation of Windows with unique
components. Unique components might include specific device drivers or might include
optional settings to maximize the performance of the hardware. Microsoft will provide
reasonable-effort assistance if you need technical help with your x64-based version of
Windows. However, you might have to contact your manufacturer directly. Your
manufacturer is best qualified to support the software that your manufacturer installed
on the hardware.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Applies To
This article applies to all currently supported Microsoft operating systems.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to obtain the latest service pack
for Windows Server 2008
Article • 02/19/2024

This article describes how to obtain Windows Server 2008 Service Pack 2 (SP2).

Applies to: Windows Server 2008 Service Pack 2

Original KB number: 968849

Summary
Windows Server 2008 updates are distributed in service packs. Service packs help keep
Windows Server 2008 current. Additionally, service packs extend and update the
functionality of your computer.

Service packs include updates, system administration tools, drivers, and additional
components. These components are conveniently bundled for easy downloading.
Service packs are cumulative. Each new service pack contains all the fixes that are
included in previous service packs, and also contain any new fixes. You do not have to
install a previous service pack before you install the latest service pack.

Windows Server 2008 SP2

Release date: May 26, 2009

You can download Windows Server 2008 SP2 from the Windows Update site and from
the Microsoft Download Center. The following versions of Windows Server 2008 SP2 are
available:

A 32-bit version
A 64-bit (x64-based) version
An Itanium-based version

Obtain Windows Server 2008 SP2 from Windows Update

You can download Windows Server 2008 SP2 from Microsoft Windows Update .

Obtain Windows Server 2008 SP2 from the Microsoft

Download Center
To download Windows Server 2008 SP2 from the Microsoft Download Center, visit the
appropriate Microsoft Web site:

Windows Server 2008 Service Pack 2 and Windows Vista Service Pack 2 - Five Language
Standalone DVD ISO

７ Note

If you have installed a prerelease version of Windows Server 2008 SP2, uninstall the
prerelease version of the service pack, and then install the final product from the
Microsoft Download Center.

Hotfixes and security updates included in

Windows Server 2008 SP2
For a list of hotfixes and security updates in Windows Server 2008 SP2, see Hotfixes and
Security Updates in Windows Server 2008 SP2 and Windows Vista SP2.

Release notes
For more information about issues with Windows Server 2008 Service Pack 2, see
Release Notes for Windows Server 2008 with Service Pack 2.

For more information, see Information about Service Pack 2 for Windows Vista and for
Windows Server 2008 .

Additional resources
For documentation, tools, and resources to help you evaluate, deploy, and manage
Windows Server 2008 SP2 on the servers in your organization, see What's new in
Windows 10 deployment.

For frequently asked questions about Windows Server 2008 Service Pack 2 and about
Windows Vista Service Pack 2, see Frequently Asked Questions: Windows Server 2008
Service Pack 2 and Windows Vista Service Pack 2.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

WSUS (Windows Server Update
Services) clients cannot install updates
when Symantec Endpoint Protection is
installed on the same Web site with
WSUS
Article • 02/19/2024

This article provides a solution to an issue where Windows Server Update Services
(WSUS) clients can't install updates when Symantec Endpoint Protection is installed on
the same Web site.

Applies to: Windows Server 2012 R2

Original KB number: 968248

Symptom
WSUS clients do not install approved updates from WSUS.

The Symantec Endpoint Protection Manager is able to download current definitions to

clients.

The WSUS client computers are configured correctly to connect to WSUS and appear on
the WSUS Administration console. The WSUS server is functional in every other respect.

Cause
WSUS and the Symantec Endpoint Protection Manager both utilize a virtual directory
called "Content." If WSUS and Symantec are both installed onto the same default Web
site using Port 80, only the last one installed will be able to serve updates to clients.

Choose one of the following methods to resolve this problem.

Resolution 1: Move the WSUS content directory

to a new location by using the Wsusutil utility
To move the WSUS Content directory, follow these steps:
1. Log on to the WSUS server by using an account that is a member of the local
Administrators group.

2. Create a new destination folder for the WSUS content directory on an NTFS
partition. The new destination folder must have the same permissions that were set
on the original folder.

3. Click Start, right-click Command Prompt, and then click Run as administrator.

4. Navigate to the directory that contains the Wsusutil.exe utility:

cd WSUSInstallDir\Tools

5. Type the following command:

Console

wsusutil movecontent contentpath logfile -skipcopy

７ Note

The contentpath placeholder is the new root for content files (the path must
exist) and logfile is the path and file name of the log file to create.

6. Press ENTER. Wsusutil does the following:

a. Updates the WSUS database to refer to the new location of the update files.

b. Ensures that the content and metadata are synchronized.

c. Retains the old content directory. It remains intact and is not deleted by the
utility.

d. Using the -skipcopy parameter ensures that the files in the existing content
directory are not copied to the new WSUS destination folder.

7. Symantec Endpoint Protection Manager can now use the default content directory.

７ Note

You may need to repair or reinstall Symantec Endpoint Protection Manager.

Resolution 2: Move WSUS to port 8530 by
using the Wsusutil utility
This option will cause IIS to use the alternate port, but all of the files will remain in place
and will still be used. You may need to reconfigure the WSUS client's Group Policy
setting(s) for the new port.

To move WSUS to port 8530, follow these steps:

1. Log on to the WSUS server by using an account that is a member of the local
Administrators group.

2. On the WSUS server, click Start, right-click Command Prompt, and then click Run
as administrator.

3. Navigate to the directory that contains the Wsusutil.exe utility:

cd WSUSInstallDir\Tools

4. Type the following command:

Console

wsusutil usecustomwebsite true

5. Press ENTER. WSUS will now run on port 8530.

6. As applicable, reconfigure the WSUS client's Group Policy setting for port 8530.

7. Symantec Endpoint Protection Manager can now use the default content directory
and port 80.

７ Note

You may need to repair or reinstall Symantec Endpoint Protection Manager.

Resolution 3: Move Symantec Endpoint

Protection Manager to an alternate port
For more information, see the Symantec documentation for the supported alternate port
number and procedures.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The Windows Server Update Services
3.0 installation package is available
Article • 02/19/2024

This article provides some information about Windows Server Update Services 3.0
installation package.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 935524

Introduction
This article describes the Release-to-Web (RTW) version of Windows Server Update
Services (WSUS) 3.0. WSUS 3.0 upgrades the earlier version of this product. You can
install the RTW version of WSUS 3.0 on the following operating systems:

Microsoft Windows Server 2003 with Service Pack 1 or a later service pack
Microsoft Windows XP with Service Pack 2
Windows Vista

More information
WSUS 3.0 delivers new features that let administrators more easily deploy updates and
manage updates across an organization. This update can upgrade computers that are
running the following versions of WSUS to WSUS 3.0 RTW:

WSUS 2.0
WSUS 2.0 Service Pack 1 (SP1)
WSUS 3.0 RC

Before you install WSUS 3.0, make sure that the computer meets the minimum system
requirements.

System requirements

WSUS 3.0 Server software prerequisites

Windows Server 2003 with Service Pack 1 or a later service pack

WSUS 2.0, WSUS 2.0 Service Pack 1, or WSUS 3.0 RC

 Internet Information Services (IIS) 6.0 or a later version

Microsoft .NET Framework 2.0

Microsoft Management Console 3.0

Microsoft Report Viewer

Optional: Microsoft SQL Server 2005 with Service Pack 1

７ Note

If a compatible version of SQL Server is not installed, WSUS 3.0 installs

Windows Internal Database.

WSUS 3.0 Administration Console software prerequisites

Windows Vista, Windows XP with Service Pack 2, or Windows Server 2003 with
Service Pack 1 or a later service pack
WSUS 3.0 RC
Microsoft .NET Framework 2.0
Microsoft Management Console 3.0
Microsoft Report Viewer

Update information
For more information about how to download Microsoft support files, click the following
article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection
software that was available on the date that the file was posted. The file is stored on
security-enhanced servers that help prevent any unauthorized changes to the file.

You can find the shortcut to start the WSUS 3.0 Administration Console in the
Administrative Tools folder. In Windows XP with SP2 and in Windows Vista, the
Administrative Tools folder is in Control Panel.

Important configuration issue

If you use a proxy server that requires authentication, you must overwrite the proxy
server password in the WSUS Server Configuration Wizard. If you do not do it, the WSUS
server may not synchronize updates. Because the configuration wizard starts
automatically at the end of the Setup process, this problem can cause synchronization
errors after you upgrade to WSUS 3.0. You can avoid this problem by canceling the
Configuration Wizard after the upgrade or by reentering the correct proxy password
when the wizard runs. To recover from this problem after it has occurred, follow these
steps:

1. In the WSUS 3.0 console tree, click Options.

2. In the details pane, click Update Source and Proxy Server.
3. In the Update Source and Proxy Server dialog box, click the Proxy Server tab.
4. Reenter the proxy password. Then, save the setting.

For more information about Windows Server Update Services, visit the following
Microsoft Web site:
WSUS TechNet Center
https://technet.microsoft.com/wsus/default.aspx

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

WSUS SelfUpdate service doesn't send
automatic updates
Article • 02/19/2024

This article provides a solution to an issue where the client computers don't receive
updates when you use a Microsoft Windows Server Update Services (WSUS) SelfUpdate
service to send automatic updates.

Applies to: Windows Server 2012 R2

Original KB number: 920659

Symptoms
When you try to use the WSUS SelfUpdate service to send automatic updates to client
computers, the client computers do not receive the updates. Additionally, the client
computers do not report to the WSUS server.

When this occurs, the WSUS Administration console logs the following error message:

Check your server configuration. One or more Update Service components could
not be contacted. Check your server status and ensure that the Windows Server
Update Service is running.
Non-running services: SelfUpdate

The event log may also include the following event:

Cause
This problem may occur if one or more of the following conditions are true:

The permissions on the C:\Program Files\Update Service\SelfUpdate directory are

missing or incorrectly configured, or the IUSR_ ComputerName account has been
removed from the Users group.
The SelfUpdate virtual directory is missing from the WSUS server.
The SelfUpdate virtual directory is not configured for the default site on port 80.
The SelfUpdate virtual directory does not have anonymous access permissions.
The default Web site is configured to use specified IP addresses and is missing an
entry for 127.0.0.1.
The default Web site does not have anonymous access permissions.
 The WSUS server also has Microsoft Windows SharePoint Services installed. The
WSUS resources have not been excluded from SharePoint management.
The Selfupdate.msi installation was defective. Therefore, files are missing from the
~\Selfupdate subfolders.

Resolution
To resolve this problem, you must have the following minimum permissions on the
C:\Program Files\Update Service\SelfUpdate directory.

ﾉ Expand table

Group Permissions

Administrators Full Control

System Full Control

Domain/Users or Local/Users Read&Execute, Read, List Folders

IUSR_ ComputerName Read&Execute, Read, List Folders

７ Note

IUSR_ ComputerName represents the host name of the server that is running IIS
where WSUS is installed. If this account is a member of the Users group, you do not
have to explicitly define these permissions.

To resolve a problem where the SelfUpdate virtual directory is missing or there is no

SelfUpdate virtual directory listed under the Web site that is bound to port 80, run the
Selfupdate.msi file that is located in the Program files\Update services\Setup folder.

To resolve issues where the SelfUpdate virtual directory does not have anonymous
access permissions, open IIS Manager, expand the default Web site, right-click the
SelfUpdate virtual directory, and then click Properties. On the Directory Security tab,
click edit under Authentication and access control. Make sure that anonymous access is
enabled.

７ Note

This step should be performed for the default Web site as well. The SelfUpdate tree
does not work if you have a Web site that is bound to a specific IP address in your
 IIS configuration. The workaround is either to set your IIS configuration to respond
to "All unassigned" addresses or to add 127.0.0.1 to the list of IP addresses used for
SelfUpdate.

Use Internet Information Services (IIS) Management console to verify that the server is
set up with one of the following two configurations.

Configuration 1: WSUS is installed on the default Web site

Configure the default Web site by using the following settings:

SelfUpdate
Content
ClientWebService
SimpleAuthWebService
WSUSAdmin
ReportingWebService
DssAuthWebService
ServerSyncWebService

Configuration 2: WSUS is installed on a custom Web site

Configure the default Web site on port 80 by using the following settings:

SelfUpdate
ClientWebService

Configure WSUS Administration on port 8530 with the following settings:

SelfUpdate
Content
ClientWebService
SimpleAuthWebService
WSUSAdmin
ReportingWebService
DssAuthWebService
ServerSyncWebService

Regardless of the configuration that you select, you must also verify the following
settings:
 You must configure the SelfUpdate virtual directory under the default Web site or
any other Web site to listen on Port 80.
The SelfUpdate virtual directory points to C:\Program Files\Update
Service\SelfUpdate.
The WSUSAdmin virtual directory is the only virtual directory in IIS that should
have security set to Integrated Windows Authentication. Set all other virtual
directories security to Anonymous Access Enabled.

Status
Microsoft has confirmed that this is a problem.

More information
When you use IIS, you can move the SelfUpdate directory to a different Web site. To do
this, follow these steps:

1. Click Start, click Run, type Control admintools, and then double-click Internet
Information Services (IIS) Manager.
2. Expand the Web Sites folder, and then click the WSUS Administration node.
3. Right-click the SelfUpdate node, point to All Tasks, and then click Save
Configuration to File.
4. Type a name for the file and then save the file to another folder. You will use this
file in steps 9 through 12.
5. Right-click the ClientWebService node, select All Tasks, and then click Save
Configuration to File.
6. Type a name for the file and save the file to the same folder that you used in step
4. You will use this file in steps 13 through 15.
7. Select the default Web site or another Web site that is running on port 80.
8. Right-click the Web site, point to New, and then click Virtual Directory (from file).
9. Select the directory where you saved the SelfUpdate and the ClientWebService.xml
files in steps 4 and 6.
10. Select the SelfUpdate.xml file, and then click Open.
11. Click Read File, click the SelfUpdate file that is now listed under Select a
configuration to import, and then click OK.
12. In the IIS Manager dialog box, type the name for a new virtual directory in the
Alias box, and then click OK.
13. Select the ClientWebService.xml file, and then click Open.
14. Click Read File, click the SelfUpdate file that is now listed under Select a
configuration to import, and then click OK.
 15. In the IIS Manager dialog box, type the name for a new virtual directory in the
Alias box, and then click OK.
16. If this is a new Web site, start the Web site from IIS Manager. If this is an existing
Web site, restart the Web site from IIS Manager.

References
For more information about automatic updates in Windows, see Description of the
Automatic Updates feature in Windows .

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server Update Services 3.0
SP2 Dynamic Installer for Server
Manager
Article • 02/19/2024

This article describes the Windows Server Update Services 3.0 SP2 Dynamic Installer for
Server Manager.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 972493

Introduction
Microsoft has released the Windows Server Update Services (WSUS) 3.0 Service Pack 2
(SP2) Dynamic Install for Windows Server 2008. WSUS enables information technology
administrators to fully manage the distribution of updates that are released through
Microsoft Update to computers in their network.

This article includes information about the contents of the service pack, links to
instructions and system requirements for installation on supported Windows Server
2008 operating systems by using Server Manager, and how to determine whether the
service pack is installed.

Feature improvements and important software

updates in Service Pack 2
Integration with Windows Server 2008 R2
Support for the BranchCache feature on Windows Server 2008 R2
Support for Windows 7 clients

WSUS feature improvements

Auto-approval rules: Auto-approval rules now include the ability to specify the
approval deadline date and time for all computers or specific computer groups.
Update files and languages: Improved handling of language selection for
downstream servers includes a new warning dialog box that appears when you
decide to download updates only for specified languages.
 Easy upgrade: WSUS 3.0 SP2 can be installed as an in-place upgrade from earlier
versions of WSUS and preserves all settings and approvals. The user interface is
compatible between WSUS 3.0 SP1 and SP2 on the client and the server.
Reports: New Update and Computer Status reports let you filter on updates that
are approved for installation. You can run these reports from the WSUS console or
use the API to incorporate this functionality into your own reports.

Software updates
Stability and reliability fixes for the WSUS 3.0 server, such as support for IPv6
addresses that are longer than 40 characters.
The approval dialog now sorts computer groups alphabetically by group name.
Computer status report sorting icons are now functional in x64 environments.
A new release of Windows Update Agent is included with WSUS 3.0 SP2. This new
release provides improvements and fixes, such as support for APIs that are called
by a nonlocal system callnoninteractiveteractive session.

More information
By default, Windows Server 2008 SP2 includes the ability to install the WSUS Role
Service by using Server Manager. This role lets you use the MMC Server Manager snap-
in and wizards to install, configure, and manage WSUS 3.0 SP2. The dynamic package
for WSUS 3.0 SP2 will only install by using Server Manager.

The WSUS 3.0 SP2 package has the following Microsoft Update detection logic and
characteristics:

Classification: Update

Supersedes: WSUS 3.0 SP1

This package is applicable only to the following Windows Server operating systems
with the WSUS-Server Manager integration:

Windows Server 2008 SP1 with Server Manager

For more information, click the following article number to view the article in
the Microsoft Knowledge Base: 940518 An update is available that integrates
Windows Server Update Services (WSUS) 3.0 into Server Manager in Windows
Server 2008

Windows Server 2008 SP2

 Windows Server 2008 R2, x64 edition only

Applicability rules:
Is installed = No
Is installable

Download Center:
The WSUS 3.0 SP2 Download Center Web site includes the RTM Microsoft user
license terms.
Pre-3.0 SP1 versions of WSUS 3.0 are no longer available for download.

After WSUS 3.0 is detected as installed by Server Manager, it can be configured and
managed within the Server Manager user interface or the WSUS 3.0 snap-in. To install
WSUS 3.0 SP2 on a server that runs Windows Server 2008 SP2 that is being updated by
a WSUS 3.0 server, approve the Windows Server Update Services 3.0 SP2 Dynamic Install
for Windows Server 2008, and then install WSUS role by using Server Manager.

How to determine whether the service pack is

installed
Look for "Windows Server Update Services 3.0 SP2" in Add or Remove Programs or
Program Files and Features in Control Panel. If "Windows Server Update Services 3.0
SP2" doesn't appear, the service pack isn't installed.

Removal information
You can't use Add or Remove Programs in Control Panel to remove only WSUS 3.0
Service Pack 2 because it will also remove all WSUS 3.0.

To remove WSUS 3.0 SP2 by using Server Manager, follow these steps:

1. Log on to the server on which you plan to remove WSUS 3.0 SP2 by using an
account that is a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Server Manager.
3. In the right side pane of the Server Manager window, in the Roles Summary
section, click Remove Roles.
4. If the Before You Begin page appears, click Next.
5. On the Select Server Roles page, clear the Windows Server Update Services check
box.
6. On the Windows Server Update Services page, click Next.
7. On the Confirm Installation Selections page, click Remove.
 8. On the Remove Windows Server Update Services 3.0 SP2 page, select any
additional items to be removed, and then click Next.
9. Click Finish to exit the wizard when the WSUS 3.0 SP2 Removal Wizard is finished.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Update for Business reports:
Troubleshoot diagnostic data
transmission
Article • 02/19/2024

Applies to: Windows Server, all supported versions

This article is designed to help you troubleshoot missing device data from Windows
Update for Business reports. If data is missing from your reports, there are three primary
questions that you have to answer:

Did Windows Update for Business reports receive the data but not include it in
reports?
Are the devices correctly configured to send diagnostic data, and have they tried
to send it?
Are network connections and permissions correctly configured, including any
proxy servers?

Verify that Windows Update for Business

reports is receiving data
After you enroll a device and configure it to share data, wait for 48 hours for data to
start appearing in reports. In some cases, data from devices that aren't active much
might take up to 14 days to appear in reports.

To verify that the reports service is receiving data from the device, run a query the
UCClient table. For example, the following query shows the total enrolled device count
per time-generated:

UCClient | summarize count() by TimeGenerated

 

If the table contains data from the device but the data is missing from reports, a
problem might exist in the report configuration. For more information, see the following
articles:

Use Windows Update for Business reports

Windows Update for Business reports schema

If sufficient time has passed since the device was configured and enrolled, and the table
still contains no device data, go to the next section to start troubleshooting the device.

Check the data transmission prerequisites for

devices

７ Note

This section summarizes the data transmission prerequisites. For a full discussion of
these requirements and an up-to-date list of endpoints, see Enable Windows
diagnostic data processor configuration.

Requirements for devices

 Use a supported version of Windows 11 or Windows 10
The following editions are supported:
Enterprise
Professional
Education
The device must be Microsoft Entra joined (it can be a hybrid Microsoft Entra join).
The diagnostic data setting on the device should be set to Required diagnostic
data or a higher value.

Requirements for internet access

Devices have to be able to connect to the following endpoints. (This list was current at
the time of publication.)

us-v10c.events.data.microsoft.com ( eu-v10c.events.data.microsoft.com for

tenants that have billing addresses in the EU Data Boundary).

watsonc.events.data.microsoft.com ( eu-watsonc.events.data.microsoft.com for

tenants that have billing addresses in the EU Data Boundary).

settings-win.data.microsoft.com

*.blob.core.windows.net

７ Note

Tenants that have billing addresses in countries or regions in the Middle East
or Africa, and European countries or regions that aren't in the EU, also use the
eu-v10c.events.data.microsoft.com and eu-
watsonc.events.data.microsoft.com endpoints. Their diagnostic data is

processed initially in Europe. However, those tenants aren't considered part of

the EU Data Boundary.

Devices can connect directly or by using a proxy server. If a device has to use a proxy
server, the device configuration must meet the requirements that are described in the
next section.

Configure devices to use a proxy connection

If your devices have to use a proxy connection, you can use one of two types:
 A user proxy (WinINET-based)
A system proxy (WinHTTP-based)

Microsoft recommends that you configure the proxy servers to allow traffic to the
diagnostic data endpoints without requiring proxy authentication. This approach is the
most comprehensive solution, and it's compatible with all versions of Windows 10 and
Windows 11.

On the device, the Windows Universal Telemetry Client (UTC) service is responsible for
transmitting diagnostic data. When the UTC service starts to transmit, it first tries to
connect directly to the endpoint. If the UTC service can't connect in that manner, it
checks the device for a proxy configuration. The UTC service uses either type of proxy
configuration, unless Group Policy dictates a specific proxy configuration. For more
information about how to use Group Policy to configure the proxy server, see Configure
device proxy and Internet connectivity.

The following table lists the two types of proxy connections and which scenarios each is
suitable for.

ﾉ Expand table

Type Scenarios

User proxy At least one user account has permissions to access the device console, the proxy
server, and the endpoint.

System The device is headless (users don't sign in).

proxy
Device users don't have internet permissions.

The proxy servers require authentication, but they don't support Integrated
Windows Authentication.

Your infrastructure is integrated with Microsoft Defender for Endpoint.

） Important

Before you configure devices to use a proxy server, make sure that the devices have
the latest quality updates for a supported version of Windows.

Configuring a user proxy

When you use the user proxy approach, the UTC service uses the context of the signed-
in user to connect to the proxy server and the diagnostic data endpoints. Therefore,
make sure that the designated user account has the appropriate permissions.

On the device, in Network and internet settings, use the Proxy tab to configure the
user-level (WinINET) proxy.

７ Note

You can also use the legacy Internet Options control panel to configure the proxy
settings.

Configuring a system proxy

Configuring the local system account

When you use the system proxy approach, the UTC service uses the local system context
to connect to the proxy server (through WinHTTP) and the diagnostic data endpoints.
Therefore, make sure that the local system account has the appropriate permissions. To
do this, use one of the following methods:

In a Command Prompt window on the device, run netsh winhttp set proxy .
Use the Web Proxy Auto-Discovery (WPAD) protocol.
Use a transparent proxy.
In Group Policy, configure a device-wide WinINET proxy by enabling Make proxy
settings per-machine (rather than per-user) .
Establish a routed connection.
Use Network Address Translation (NAT).

Configuring the proxy servers

Make sure that the proxy servers use the following configuration: The proxy servers use
Integrated Windows Authentication. The proxy servers allow Active Directory Domain
Services (AD DS) computer accounts to access the diagnostic data endpoints.

Feedback
Was this page helpful?  Yes  No
Provide product feedback
Windows Update for Business reports:
Use the configuration script to
troubleshoot device configuration
Article • 02/19/2024

Applies to: Windows Server, all supported versions

When you're troubleshooting, you can use the Windows Update for Business reports
configuration script to test endpoint connectivity, make sure that the correct services are
running, and check for common issues.

You can download the script from the Microsoft Download Center .

For more information about the script, including the available parameters, see
Configuring devices through the Windows Update for Business reports configuration
script.

７ Note

If you don't find any issues in the device configuration, and you determine that the
Windows Update for Business reports are correctly configured, your issue is likely
related to data transmission. For more information, see Windows Update for
Business reports: How to troubleshoot diagnostic data transmission.

Configuring the script

The device must have Windows 10 or a later version and the latest version of Windows
PowerShell installed. To run the script, you have to use an elevated PowerShell window
on the device (the script itself runs in the System context).

） Important

The script package includes PSExec.exe. If you use a mobile device manager
such as Microsoft Intune, and you've implemented attack surface reduction
(ASR) rules beyond the standard ASR rules, the rules might block the script.
For more information, see Block process creations originating from PSExec
and WMI commands.
 After you finish troubleshooting the device, remove PSExec.exe.

Running the script

To use the script to troubleshoot a client device:

1. Sign in to the device as an administrator.

2. Download the script package to the device that you're troubleshooting, and
expand the script package.

3. Create a folder on the device for log data. The default name and path that the
script uses is *The default value is .\UCLogs.

4. Edit RunConfig.bat to set the following required parameters:

runMode=Pilot

logPath=<path of the folder that you created for log data>

７ Note

Pilot mode is a verbose mode. The script has another mode,

Deployment, that runs silently.
Don't modify the Commercial ID parameters. They're used for the earlier
version of Windows Update for Business reports (Update Compliance).

5. If you want to set additional parameters, the following RunConfig.bat parameters

are optional.

ﾉ Expand table

Parameter Allowed values and description Example

logMode 0: Log only to the console. logMode=2

1: (default) Log to file and console.
2: Log only to file.

DeviceNameOptIn true: (default) Device name is sent to DeviceNameOptIn=true

Microsoft.
false: Device name isn't sent to Microsoft.

ClientProxy Direct: (default) The device connects directly ClientProxy=Direct

to the endpoints.
 Parameter Allowed values and description Example

System: The device connects by using a

system proxy, without authentication.
User: The device connects by using the user
account's internet configuration. The
connection might not require user
authentication.

For more information, see How the Windows

Update client determines which proxy server
to use to connect to the Windows Update
website

6. Save the changes to RunConfig.bat, and then close the file.

7. Open an elevated PowerShell window, navigate to the folder that contains the
script files, and then run RunConfig.bat.

Reviewing the script output

The script creates a working folder in the folder that you identified in the logPath
parameter in RunConfig.bat. The default folder name is UA_yy_MM_dd_HH_mm_ss_GUID,
where yy_MM_dd_HH_mm_ss represents the date and time that you ran the script. The
script saves all output files and other diagnostic files in this working folder.

Analyzing the script log file and error codes

The script log file, UA_yy_MM_dd_HH_mm_ss_GUID.txt, has the same name as the
working folder. You should review this file first. You can use the following table to
interpret any error codes that are listed in the file.

ﾉ Expand table

Error Description

1 Unexpected error

12 CheckVortexConnectivity failed, check the log output for more information.

12 Unexpected failure when running CheckVortexConnectivity.

16 Reboot is pending on device. Restart the device then re rerun the script.

17 Unexpected exception in CheckRebootRequired.

Error Description

27 Not system account.

30 Unable to disable Enterprise Auth Proxy. This registry value must be 0 for UTC to operate
in an authenticated proxy environment.

34 Unexpected exception when attempting to check proxy settings.

35 Unexpected exception when checking user proxy.

37 Unexpected exception when collecting logs.

40 Unexpected exception when checking and setting telemetry.

41 Unable to impersonate logged-on user.

42 Unexpected exception when attempting to impersonate logged-on user.

43 Unexpected exception when attempting to impersonate logged-on user.

44 Error when running CheckDiagTrack service.

45 DiagTrack.dll not found.

50 DiagTrack service not running.

51 Unexpected exception when attempting to run Census.exe.

52 Couldn't find Census.exe.

54 Microsoft Account Sign In Assistant (MSA) Service disabled.

55 Failed to create new registry path for SetDeviceNameOptIn.

56 Failed to create property for SetDeviceNameOptIn at registry path.

57 Failed to update value for SetDeviceNameOptIn.

58 Unexpected exception in SetDeviceNameOptIn.

59 Failed to delete LastPersistedEventTimeOrFirstBoot property at registry path when

attempting to clean up OneSettings.

60 Failed to delete registry key when attempting to clean up OneSettings.

61 Unexpected exception when attempting to clean up OneSettings.

62 AllowTelemetry registry key isn't the correct type of REG_DWORD.

63 AllowTelemetry isn't set to the appropriate value and it couldn't be set by the script.

64 AllowTelemetry isn't the correct type of REG_DWORD.

 Error Description

66 Failed to verify UTC connectivity and recent uploads.

67 Unexpected failure when verifying UTC CSP.

99 Device isn't Windows 10 or Windows 11.

100 Device must be Microsoft Entra joined or Microsoft Entra hybrid joined to use Windows
Update for Business reports.

101 Check Microsoft Entra join failed with unexpected exception.

102 DisableOneSettingsDownloads policy shouldn't be enabled. Please disable this policy.

Analyzing the other output and diagnostic data

These files record information that the script exports from the registry.

RegAppCompatFlags.txt

This file records appraiser (sometimes referred to as Device Appraiser or Microsoft

Compatibility Appraiser) information. Appraiser is the Windows component that
corresponds to the compatibility updates. It assesses the apps and drivers on the device
for compatibility with the latest version of Windows. Appraiser depends on the following
files:

%windir%\System32\appraiser.dll. The file version must be 10.0.17763 or later.

%windir%\System32\CompatTelRunner.exe. If the file doesn't exist, make sure that
all compatibility updates are installed on the device.

RegDataCollection.txt
This file records the DataCollection settings. This data represents the current telemetry
configuration of the device, per applied policies.

You can use this data to verify that the appropriate values are applied to transmit
diagnostic data to Microsoft. This data resembles the following excerpt:

Output

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection]
"AllowDeviceNameInTelemetry"=dword:00000001
"AllowUpdateComplianceProcessing"=dword:00000010
"AllowCommercialDataPipeline"=dword:00000001
RegPoliciesDataCollection.txt
This file records device-level and user-level settings for controlling diagnostic data. The
device-level configuration data resembles the following excerpt:

Output

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataC
ollection]
"AllowTelemetry"=dword:00000003
"MaxTelemetryAllowed"=dword:00000003

The AllowTelemetry entry controls the type (if any) of diagnostic data to transmit. The
entry has the following allowed values:

0 – Security (This value is supported on only Enterprise, Education, and Server

editions of Windows.)
1 – Basic (required) telemetry
2 – Enhanced telemetry
3 – Full telemetry

The user-level configuration data resembles the following excerpt:

Output

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataC
ollection\Users]

RegSQM.txt

This information is primarily about Windows 7 devices. If you're working in later

Windows versions, you can use this information as a fallback identifier for the device.

RegDiagTrack.txt
This file records all the registry settings for the Connected User Experiences and
Telemetry (DiagTrack) (UTC) service. All the entries that store these settings reside under
the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\DiagTrack

\ subkey. The following excerpt shows such a report:

Output
 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\Di
agTrack]
"TimeStampInterval"=dword:00000001
"Capabilities"=hex:c6,f6,43,15,00,00,00,00
"mspflags"=hex(b):11,00,00,00,00,00,00,00
"DiagTrackAuthorization"=dword:00000f9f
"LaunchCount"=hex(b):03,00,00,00,00,00,00,00
"DiagTrackStatus"=dword:00000003
"LastFreeNetworkLossTime"=hex(b):00,00,00,00,00,00,00,00
"LastConnectivityHeartBeatTime"=hex(b):00,00,00,00,00,00,00,00
"LastConnectivityState"=dword:00000002
"ConnectivityNoNetworkTime"=dword:00000001
"ConnectivityRestrictedNetworkTime"=dword:00000000
"LastPersistedEventTime"=hex(b):40,e5,64,27,cb,8a,d9,01
"LatencyDataLastUploadTime"=hex(b):00,00,00,00,00,00,00,00
"TriggerCount"=hex(b):00,04,00,00,00,00,00,00
"HttpRequestCount"=hex(b):07,00,00,00,00,00,00,00
"TriggerLatency"="0.088490"
"HttpRequestLatency"="0.077600"
"LastSuccessfulUploadTime"=hex(b):7a,96,6c,2b,cb,8a,d9,01
"LastSuccessfulRealtimeUploadTime"=hex(b):7a,96,6c,2b,cb,8a,d9,01
"LastSuccessfulNormalUploadTime"=hex(b):55,2a,aa,a7,ca,8a,d9,01

Using the DCode tool to convert hexadecimal values to date-time

format

As shown in the previous excerpt, many of these entries use big-endian hexadecimal
format. To convert them to UTC dates and times, use a tool such as DCode . This tool is
available as a free download.

The DCode tool uses input values that have a slightly different format than the one that
the file uses. You have to reverse the sequence of the segments, and then remove all
non-numeric characters. For example, consider the following value from the excerpt:

Console

hex(b):55,2a,aa,a7,ca,8a,d9,01

To convert this value, open DCode, select Format, and then select Hexadecimal (Big
Endian). In Value, enter the following:

Console

01d98acaa7aa2a55
Then, select Decode. The list of results includes a Windows FileTime (UTC) entry that
has the value, 2023-05-20 03:24:58.5114197 Z.

７ Note

By default, all dates and times are Coordinated Universal Time (UTC) values. To
display the time stamp in a different time zone, use the Time Zone setting in
DCode.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Update Standalone Installer
(WUSA) returns 0x5
ERROR_ACCESS_DENIED when
deploying .msu files through WinRM
and Windows Remote Shell
Article • 02/19/2024

This article helps work around an issue that occurs when you deploy Windows Update
.msu files through Windows Remote Management 2.0 and Windows Remote Shell.

Applies to: Windows 7 Service Pack 1

Original KB number: 2773898

Symptoms
Windows Update Standalone Installer (WUSA) returns 0x5 ERROR_ACCESS_DENIED
when deploying Windows Update .msu files through Windows Remote Management 2.0
and Windows Remote Shell. You may also see the following in the Application Event log:

Source: Microsoft-Windows-WUSA
Event ID: 3
Level: Error
Description: Windows update could not be installed because of error 2147942405
"Access is denied."

Installing an update using WUSA or the WUA APIs on a remote machine isn't supported.

Workaround
To work around this issue, use the following method:

Extract the .msu file through Windows Remote Shell with WUSA using the following
command:

Console

winrs.exe -r:<computername> wusa.exe <update> /extract:<destination>

When complete, install the .cab package with dism.exe or Package Manager. To use
dism.exe, use the command below:

Console

winrs.exe -r:<computername> dism.exe /online /add-package /PackagePath:

<Path_To_Package>\KBnnnnnnn.cab

More information
The Windows Update Standalone Installer uses the Windows Update Agent API to install
update packages. Update packages have a .msu file name extension. The .msu file name
extension is associated with the Windows Update Standalone Installer.

The security restrictions on remote use of the WUA APIs are documented here:

Using WUA From a Remote Computer

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You can't install features in Windows
Server 2012 R2
Article • 02/19/2024

This article provides a solution to an issue that prevents you from adding features to a
Windows Server 2012 R2-based computer that's running the Server Core installation
option.

Applies to: Windows Server 2012 R2

Original KB number: 2913316

Symptoms
Consider the following scenario:

You have a computer that's running Windows Server 2012 R2.

The computer is running the Server Core installation option.
The Server Core option was installed by using Volume Licensing media that doesn't
have access to Windows Update.

In this scenario, the feature installation fails. Also, you receive the following error
message:

Error: 0x800f081f
The source files could not be found. Use the "Source" option to specify the location
of the files that are required to restore the feature. For more information on
specifying a source location, see Configure a Windows Repair Source .

Resolution
To resolve this problem, use one of the following methods.

Method 1: Connect to the Internet

­If the server can connect to Windows Update for the feature installation, let the server
make the connection.

Method 2: Use Windows Server 2012 R2 installation

media
If the server can't connect to Windows Update, download the new Volume Licensing
media (released on December 11, 2013) and use the Install-WindowsFeature PowerShell
command. To do it, follow these steps:

1. Insert the updated Windows Server 2012 R2 DVD into the computer's DVD drive.

2. Type the following command to determine the index number that's required for
steps 3 and 4.

PowerShell

Dism /get-wiminfo /wimfile:<drive>:\sources\install.wim

７ Note

In this command, <drive> represents the actual drive letter.

Example output from the DISM command:

Console

Index : 1
Name : Windows Server 2012 R2 SERVERSTANDARDCORE
Description : Windows Server 2012 R2 SERVERSTANDARDCORE
Size : 6,653,342,051 bytes
Index : 2
Name : Windows Server 2012 R2 SERVERSTANDARD
Description : Windows Server 2012 R2 SERVERSTANDARD
Size : 11,807,528,410 bytes
Index : 3
Name : Windows Server 2012 R2 SERVERDATACENTERCORE
Description : Windows Server 2012 R2 SERVERDATACENTERCORE
Size : 6,653,031,430 bytes
Index : 4
Name : Windows Server 2012 R2 SERVERDATACENTER
Description : Windows Server 2012 R2 SERVERDATACENTER
Size : 11,809,495,151 bytes

７ Note

When you specify the <index> number in the Install-WindowsFeature

PowerShell cmdlet in step 4, you must use the index number for the full (non-
core) version of the SKU that you currently have installed. For example, if you
have Windows Server 2012 R2 Datacenter installed, the required index
 number is 4. If you have Windows Server 2012 R2 Standard installed, the
required index number is 2.

3. Open a PowerShell command prompt by typing the following command:

Powershell

Powershell.exe

4. Type the following PowerShell command, in which <drive> represents the location
of the Windows Server 2012 R2 installation files and <index> represents the
numbered index from step 2:

Powershell

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source

wim:<drive>:\sources\install.wim:<index>

For example: If your media is on drive F, and you're installing the full version of
Datacenter, enter the following command:

Powershell

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source

wim:f:\sources\install.wim:4

More information
The Windows Server 2012 R2 Volume Licensing media was designed to require access to
Windows Update to add optional components or features that aren't included in the
side-by-side repository. If the server doesn't have Internet access, or if access to
Windows Update has been restricted, you can't enable optional components or features
by using the DISM command, Windows PowerShell cmdlets, or Server Manager.

Status
Microsoft has confirmed it to be a problem in the packaging of volume licensed media
for Windows Server 2012 R2. This behavior isn't by design and has been corrected in the
Volume Licensing build that was released on December 11, 2013. Use the new media for
any Windows Server 2012 R2 installations. See the Resolution section to resolve this
problem on servers on which you can't install features.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Licensing and activation
troubleshooting documentation for
Windows Server
Article • 02/19/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve licensing and activation-related issues. The topics are
divided into one subcategory. Browse the content or use the search feature to find
relevant content.

Licensing and activation sub category

Windows volume activation

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Application Event Log Warning ID 1058
(Security-SPP) may be logged after
reboot on OEM systems
Article • 02/19/2024

This article provides some information about Application Event Log Warning ID
1058(Security-SPP) which may be logged after reboot on OEM systems.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 2916670

Summary
Application Event Log Warning ID 1058 (Security-SPP) may be logged after an OEM
system that utilizes OA (OEM Activation) has been rebooted.

Cause
This warning is logged because of test activation data being present as part of the
manufacturing process for OEM systems.

This warning ID can be safely ignored in this scenario.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you try to validate
a copy of Windows: The cryptographic
operation failed because of a local
security option setting
Article • 02/19/2024

This article provides a solution to an error that occurs when you try to validate a copy of
Windows.

Applies to: Windows Server 2012 R2

Original KB number: 2715304

Symptoms
When you try to validate a copy of Windows, you may receive an error message that
resembles the following:

Update installation failed. Error information: 0x80092026

When you try to validate Windows, Windows downloads an update 971033 . However,
when Windows tries to install the update, the update shows an error message that is
mentioned above. Additionally, if you try to download the update KB971033 on your
machine and run it manually, you may receive following error message:

Installer encountered an error: 0x80092026

The cryptographic operation failed due to a local security option setting.

Cause
This error occurs when the State value of the following registry subkey is incorrectly set.
This value corresponds to the Internet Explorer security setting Check for publisher's
certificate Revocation and Check for signatures on downloaded programs.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing

You can find a key with the name State. By default the value is set to 23c00.
Resolution
To resolve this problem, change the registry key to a valid setting, for example:

State = 0x00023e00 - Check for publisher's certificate Revocation Unchecked

State = 0x00023c00 - Check for publisher's certificate Revocation Checked

Use one of the following methods:

Method 1: Edit the registry

２ Warning

If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you
can solve problems that result from using Registry Editor incorrectly. Use Registry
Editor at your own risk.

1. Start Registry Editor (Regedit.exe).

2. Navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing .

3. On the left side pane, look for State key and double-click to open it.
4. Change the Value data to 23c00 or 23e00 (Hexadecimal).
5. Quit Registry Editor.

Method 2: Create a reg file

1. Start Notepad.

2. In Notepad, paste the following information.

registry

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\T
rust Providers\Software Publishing
"State"=dword:00023c00

3. Save the file as a .reg file.

4. Double-click the .reg file that you saved in step 3.

Above registry changes don't require any reboot. You can try to install the update
manually.

You would be able to validate your Windows successfully.

More information
In some cases, you might be required to update the State value for following two
registries as well.

HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust

Providers\Software Publishing
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust

Providers\Software Publishing

７ Note

Ensure whatever value is updated for

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing , should be exact for above two registry.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0xC004E002 during activation for
Windows
Article • 02/19/2024

This article provides a solution to an error 0xC004E002 when you try to activate
Windows.

Applies to: Windows Server 2012 R2, Windows 10 - all editions, Windows 7 Service Pack
1
Original KB number: 978305

Symptoms
When you try to activate Windows Vista, Windows Server 2008, Windows 7, Windows
Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, or Windows Server
2012 R2, you may receive one of the following error messages:

Code: 0xC004C003
Description: The activation server determined that the specified product key has
been blocked.

Code: 0xC004E002
Description: The Software Licensing Service reported that the license store contains
inconsistent data.

Cause
This issue occurs because the incorrect permissions are set on the Tokens.dat file or this
file is corrupted.

Resolution
To resolve this issue, try the following methods in order.

Method 1: Set the correct permissions to the Tokens.dat

file
1. Select Start, and then type cmd in the Search box.
2. Right-click cmd, and then select Run as Administrator.

3. At the command prompt, type the following command depending on the

operating system and then press ENTER:

For Windows Vista or Windows Server 2008:

Console

icacls
%windir%\serviceprofiles\networkservice\appdata\roaming\microsoft\softw
arelicensing /grant "BUILTIN\Administrators:(OI)(CI)(F)" "NT
AUTHORITY\SYSTEM:(OI)(CI)(F)" "NT Service\slsvc:(OI)(CI)(R,W,D)"

The correct permissions for tokens.dat should look like this output from icacls:

Console

tokens.dat NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
NT SERVICE\SLSVC:(I)(R,W,D)

For Windows 7 or Windows Server 2008 R2:

Console

icacls
%windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\Softw
areProtectionPlatform /grant "BUILTIN\Administrators:(OI)(CI)(F)" "NT
AUTHORITY\SYSTEM:(OI)(CI)(F)" "NETWORK SERVICE:(OI)(CI)(F)"

The correct permissions for token.dat should look like this output from icacls:

Console

tokens.dat NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
NT AUTHORITY\NETWORK SERVICE:(I)(F)

For Windows 8, Windows Server 2012, Windows 8.1, or Windows Server 2008 R2:

Console

icacls
"%windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\WSLicens
 e" /grant "BUILTIN\Administrators:(OI)(CI)(F)" "NT AUTHORITY\SYSTEM:
(OI)(CI)(F)" "NETWORK SERVICE:(OI)(CI)(F)"

The correct permissions for tokens.dat should look like this output from icacls:

Console

tokens.dat NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
NT SERVICE\WSService:(OI)(CI)(R,W,D)

4. Close the Command Prompt window.

７ Note

You must type this command from an elevated command prompt.

Method 2: Rename the Tokens.dat file

1. Select Start, and then type cmd in the Search box.

2. Right-click cmd, and then select Run as Administrator.

3. At the command prompt, type the following command and then press ENTER.

For Windows Vista or for Windows Server 2008

Console

net stop slsvc

For Windows 7 or for Windows Server 2008 R2

Console

net stop sppsvc

For Windows 8, Windows Server 2012, Windows 8.1, or Windows Server 2008 R2

Console

net stop sppsvc

 ７ Note

If you receive a message that asks whether you want to continue with this
operation, type Y and then press ENTER.

4. Type the following command and then press ENTER.

For Windows Vista or for Windows Server 2008

Console

cd
%windir%\serviceprofiles\networkservice\appdata\roaming\microsoft\softw
arelicensing

For Windows 7 or for Windows Server 2008 R2

Console

cd
%windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\Softw
areProtectionPlatform

For Windows 8, Windows Server 2012, Windows 8.1, or Windows Server 2008 R2:

Console

cd
%windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\WSLicense

5. Type the following command and then press ENTER:

Console

ren tokens.dat tokens.bar

6. Type the following command and then press ENTER:

For Windows Vista or Windows Server 2008

Console

net start slsvc

 For Windows 7 or Windows Server 2008 R2

Console

net start sppsvc

For Windows 8, Windows Server 2012, Windows 8.1, or Windows Server 2008 R2:

Console

net start sppsvc

7. Type the following command and then press ENTER:

Console

cd %windir% \System32

8. Type the following command and then press ENTER:

Console

cscript slmgr.vbs -rilc

9. Restart the computer two times for the changes to apply.

Did this fix the problem

Check whether the problem is fixed. If the problem is fixed, you're finished with this
section. If the problem isn't fixed, for Windows 7 or Windows Server 2008, you can
contact support . Assisted support is no longer available for Windows Vista.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0xC004F06C when you activate
Windows
Article • 02/19/2024

This article helps fix the error 0xC004F06C and the error message "The Key Management
Service (KMS) determined that the request timestamp is invalid" when you activate
Windows.

When you try to activate Windows by using the Slmgr /ato command, you receive the
following error message:

Error: 0xC004F074 The Software Licensing Service reported that the computer could
not be activated. No Key Management Service (KMS) could be contacted. Please see
the Application Event Log for additional information.

In addition, Event ID 12288 with the 0xC004F06C error is logged in the application event
log.

Output

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date:
Event ID: 12288
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer:
Description:
0xC004F06C, 0x00000000, azkms.core.windows.net:1688, <CMID>, <DateTime>,
1, 5, 0, 34e1ae55-27f8-4950-8877-7a03be5fb181,

This error occurs in one of the following conditions:

The Windows Time service isn't working.

The NtpClient time provider isn't enabled.
Domain-joined computers don't sync time with Active Directory Domain Services
(AD DS).

To resolve this error, follow these steps:

1. Make sure the Windows Time service is running.

 a. Type services.msc in the Search box and press Enter to open the Services
window.

b. Search for Windows Time and make sure the service is running.

c. Run the following command from an elevated command prompt to make sure
the service is working properly:

Console

w32tm.exe /query /status /verbose

2. For non-domain-joined computers, use the Network Time Protocol (NTP) time
source by enabling the NtpClient provider.

） Important

This section, method, or task contains steps that tell you how to modify the
registry. However, serious problems might occur if you modify the registry
incorrectly. Therefore, make sure that you follow these steps carefully. For
protection, back up the registry before you modify it so that you can restore it
if a problem occurs. For more information about how to back up and restore
the registry, see How to back up and restore the registry in Windows .

a. Open Registry Editor and go to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\
NtpClient

b. Change the value of the Enabled registry entry to 1 to enable the NtpClient
provider in the current time service.

3. For domain-joined computers, use the AD DS time source by configuring the time
client type.

a. Open Registry Editor and go to the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W32Time\Parameters .

b. Make sure the value of the Type registry entry is NT5DS. This means the
computer is synchronizing its time with the AD DS time hierarchy.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0xC004F074 when you try to
activate Windows
Article • 02/19/2024

This article helps fix the error 0xC004F074 that occurs when you activate Windows.

Applies to: Supported versions of Windows Server and Windows Client

Original KB number: 974998

When you try to activate Windows, you may get error 0xC004F074 and one of the
following error messages:

0xC004F074 with description "The Key Management Server (KMS) is

unavailable"

Error: 0xC004F074 The Software Licensing Service reported that the product
could not be activated. No Key Management Service (KMS) could be
contacted. Please see the Application Event Log for additional information.

The Key Management Server (KMS) is

unavailable
When trying to activate Windows 7 or Microsoft Windows Server 2008 R2 KMS client
machines, you may get this error message:

0xC004F074 with description "The Key Management Server (KMS) is unavailable"

At the same time, the following entries may get logged in the KMS Event Log on the
KMS client and the KMS host.

In the application event log on the KMS client, you see the following event:

Output

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date:

Event ID: 12288

Task Category: None
Level: Information
Keywords: Classic
 User: N/A
Computer:

Description:
The client has sent an activation request to the key management service
machine.
Info:
0xC004F06C, 0x00000000, <KMS Host FQDN>:1688, 36f27b39-2fd5-440b-be67-
a09996d27a38, 2010/09/29 17:52, 0, 2, 41760, 68531fb9-5511-4989-97be-
d11a0f55633f, 5

In the application event log on the KMS host, you see the following event:

Output

Log Name: Key Management Service

Source: Microsoft-Windows-Security-Licensing-SLC
Date:

Event ID: 12290

Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer:
Description:
An activation request has been processed.
Info:
0xC004F06C,5,<KMS Client name>,36f27b39-2fd5-440b-be67-
a09996d27a38,2010/9/29 21:46,0,2,41520,68531fb9-5511-4989-97be-d11a0f55633f

This error can occur for one of the following reasons:

A support version mismatch between the KMS client and the KMS host machine
A time difference between the KMS client and the KMS host machine

Support version mismatch between KMS client and KMS

host machine
Most commonly, we're seeing this error when the KMS host is running on Windows
Server 2003 or Windows Server 2008 and the KMS client is Windows 7 or Windows
Server 2008 R2. An update is needed for the KMS host running on Windows Server 2003
and an update is needed for the KMS host running on Windows Server 2008 to be able
to activate KMS clients that are Windows 7 or Windows Server 2008 R2.

If you're running Windows Server 2008 as your KMS host, you need this update hotfix
968912 .
Time difference between KMS client and KMS host
machine
The error 0xC004F06C listed in the info section may occur if the difference between
system time on the client computer and the system time on the KMS host is more than
4 hours. We recommend that you use a Network Time Protocol (NTP) time source or the
Active Directory service to synchronize the time between computers. Time is
coordinated between the KMS host and the client computer in Coordinated Universal
Time (UTC).

Make sure that the system time on the client and the KMS host is the same. The time
zone set on the client computer doesn't affect the activation since it's based on UTC.

Run the w32tm /resync command to resync the time on the client.

No Key Management Service (KMS) could be

contacted
When you try to activate Windows by using the Slmgr /ato command, you receive error
code 0xC004F074 with the following error message:

Error: 0xC004F074 The Software Licensing Service reported that the product could
not be activated. No Key Management Service (KMS) could be contacted. Please see
the Application Event Log for additional information.

This error occurs for one of the following reasons:

The Software Protection Platform Service (sppsvc service) on the KMS host has
stopped running.
There are networking issues between the KMS client and the KMS host server. For
example, TCP 1688 traffic is blocked between the KMS client and the KMS host
server.
There's an incorrect or old KMS host server record in the Domain Name System
(DNS).

Sppsvc service on the KMS host has stopped running

Check if the sppsvc service is running on the KMS server. If the service is stopped, start
it.
Networking issues between the KMS client and the KMS
host server
Open port 1688 between the KMS client and KMS host server, and use the Test-
NetConnection PowerShell cmdlet to check if the port is open between the client and

server. Here's an example:

PowerShell

Test-NetConnection -ComputerName <KMS Host Server> -Port 1688

ComputerName : <KMS host server>

RemoteAddress : <KMS host server IP address>
RemotePort : 1688
InterfaceAlias : Wi-Fi
SourceAddress : <Client machine IP address>
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

Review the TcpTestSucceeded output parameter. If it's False , it means that port 1688 is
blocked between the KMS client and the KMS server.

Incorrect or old KMS host server record in DNS

Verify the KMS DNS record in the DNS pointing to an incorrect or old KMS server in the
environment by using the following steps:

1. Open the DNS management console.

2. Select the _tcp folder under your domain name folder, and search for the _VLMCS
SRV record.

3. Check if the correct KMS host server name is present in the _VLMCS SRV record.

4. Verify the host record of the KMS host server by going to the domain name folder
and verifying the Host A record. Change the IP address to point to the new KMS
 server host if it's incorrect.

References
Resolve Windows activation error codes

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error 0xC004F015 when you activate
Windows 10 Enterprise on a Windows
Server 2012 R2 KMS host
Article • 02/19/2024

This article provides a solution to a 0xC004F015 error that occurs when you activate
Windows 10 Enterprise on a Microsoft Windows Server 2012 R2 and Windows Server
2008 R2 KMS host.

Applies to: Windows Server 2012 R2

Original KB number: 3086418

Symptoms
On a computer that is running a volume-licensed installation of Windows 10 Enterprise,
you cannot activate Windows if you are using a Customer Support Volume License Key
(CSLVK). Additionally, the following error entry is logged in the event log as Event ID
12290:

0xC004F015

Error details
0xc004f042 - SL_E_VL_KEY_MANAGEMENT_SERVICE_ID_MISMATCH

The Software Licensing Service determined that the specified Key Management
Service (KMS) cannot be used.

Cause
This problem can occur if you use the Windows 10 KMS host product key in a Windows
Server 2012 R2 and Windows Server 2008 R2 environment. You must use the updated
WS2012R2+Win10 KMS host product key if the following conditions are true.

Client CSVLKs are installed on client computers.

Server CSVLKs are installed on server computers.

Prerequisites to activate Windows 10 Enterprise

To activate Windows 10 Enterprise in a Windows Server 2012 R2 environment, the
following prerequisites apply:

You must have Windows Server 2012 R2 with the Volume Activation role installed.
You must have update 3172614 installed.

To activate Windows 10 Enterprise in a Windows Server 2008 R2 environment, the

following prerequisites apply:

You must have Windows Server 2008 R2 with the Volume Activation role installed.
You must have update 3079821 installed.

Resolution
To resolve this problem, follow these steps:

1. Log on to the Volume Licensing Service Center (VLSC).

2. Click License.
3. Click Relationship Summary.
4. Click License ID of their current Active License.
5. After the page loads, click Product Keys.
6. In the list of keys, locate Windows Srv 2012R2 DataCtr/Std KMS for Windows 10.
7. Install this key on the KMS host.

More information
For the client KMS host, this problem should not occur on a client KMS host server.

Activation of Windows 10 is not supported if you are running a KMS host on any of the
following operating systems:

Windows Vista
Windows Server 2008
Windows Server 2003

The Generic Volume License Key (GVLK) for Windows 10 editions can be located at
Appendix A: KMS Client Setup Keys.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error code 0x8007000D when you try to
activate a Windows 7 machine by using
any type of product key
Article • 02/19/2024

This article helps fix the error 0x8007000D that occurs when you activate a Windows 7
machine by using any type of product key.

Applies to: Windows 7 Service Pack 1

Original KB number: 2230957

Symptoms
You try to activate a Windows 7 machine by using any type of product key. Running
slsmgr -dlv or slmgr -ato from a command line generates the following error:

The data is invalid.

Error code 8007000d.

Cause
The System account by default has Full Control permissions to the registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root and any subkeys.

If those permissions have been altered for the Root key or any subkey(s), we would see
the error code 0x8007000D.

Resolution
Assign the minimum permission of Enumerate Subkeys to the System account for the
registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root and any of its
subkeys.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 8208, 8200, or 900 is logged
Article • 02/19/2024

This article provides a resolution for Event ID 8208, 8200, or 900.

Applies to: Windows Server 2012 R2

Original KB number: 2958281

Symptoms
You see one or more of the following event IDs logged in the Application log:

Source: Microsoft-Windows-Security-SPP
Date: <DateTime>
Event ID: 900
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Server1.contoso.com
Description:
The Software Protection service is starting.
Parameters:caller=wsqmcons.exe

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date: <DateTime>
Event ID: 900
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Server1.contoso.com
Description:
The Software Protection service is starting.
Parameters:caller=WSHost.exe

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date: <DateTime>
 Event ID: 8200
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Server1.contoso.com
Description:
License acquisition failure details.
hr=0x80072EE7

Log Name: Application

Source: Microsoft-Windows-Security-SPP
Date: <DateTime>
Event ID: 8208
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Server1.contoso.com
Description:
Acquisition of genuine ticket failed (hr=0x80072EE7) for template Id {99d92734-
d682-4d71-983e-d6ec3f16059f}

７ Note

The 0x80072EE7 error code indicates that the system did not have appropriate
Internet access to be able to obtain the Windows Genuine Advantage ticket.

Cause
These event IDs may be logged if an application or component in Windows tries to
validate and call the Genuine Advantage APIs to acquire a Windows Genuine Advantage
ticket if one does not exist. For example, these event IDs may be logged in the following
situations:

You opt in to the Customer Experience Improvement Program (CEIP).

(Caller=wsqmcons.exe)
You install the Desktop Experience feature, which then installs the Microsoft Store.
(Caller=wshost.exe)
 ７ Note

When you try to access the Microsoft Store, this triggers a request for a Windows
Genuine Advantage ticket and an attempt to acquire one through validation.

Resolution
The events that are mentioned in the "Symptoms" section are logged if the system does
not have access to the Internet. To prevent these events from occurring, connect the
system to the Internet, and then check the firewall and proxy settings.

If you cannot connect the system to the Internet, you can try the following methods to
prevent Event ID 900, depending on the caller program identity:

If Caller=wsqmcons.exe, open Server Manager, and then clear the Participating

check box to opt out of CEIP.
If Caller=wshost.exe, disable the Microsoft Store application by enabling the
Computer Configuration\Administrative Templates\Windows
Components\Store\Turn off the Store application policy in either the local or
domain Group Policy.

７ Note

The inability to obtain a Windows Genuine Advantage ticket may not prevent the
component from working. The presence of these event IDs does not mean that the
computer is not genuine or that a licensing issue exists.

More information
The Genuine Advantage feature is designed for client operating systems and is typically
not found on a server. However, it is possible for a Windows component to use the
Windows Genuine Advantage APIs if it has to.

For more information about volume activation, see the following Microsoft TechNet
topic:

Volume Activation Overview

For more information about Windows Genuine Advantage, see the following Windows
article:
Genuine Windows: frequently asked questions

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 12321 Warning Token Based
Activation failed
Article • 02/19/2024

This article provides a resolution for Event ID 12321 Warning Token Based Activation
failed.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 2020644

Symptoms
The Application Event log may log an event ID 12321 warning event from the source
Microsoft-Windows-Security-Licensing-SLC. The description field will state Token Based
Activation failed.
HR=0xC004F011

Cause
This event will occur when the Token Issuance License is not installed inside Windows or
the certificates on the Smartcard are not present and activation is attempted.

0xC004F011 = SL_E_LICENSE_FILE_NOT_INSTALLED

Windows Software Licensing is checking whether Token Activation is available on this

volume license system and reporting that the license or certificate is not available so
Token Based licensing will not work.

Resolution
This issuance license file or Smartcard certificates are only needed when Token Based
activation is being attempted.

If you are not using Token-Based Activation, this warning message can be safely
ignored. And it will not affect the ability, which activates Windows using KMS host
machines or MAK keys.

If you are using Token Based Activation, you need to reinstall the Token Issuance license
acquired from Microsoft.
SLMGR /ILC <token-based-license-filename>

More information
Token-Based activation functionality was enabled in Service Pack 2 for Windows Vista
and Windows Server 2008.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Security Event 12293 with error
0x80072338 registering KMS host
record
Article • 02/19/2024

This article provides a resolution to fix the event ID 12293 that occurs when setting up a
KMS host.

Applies to: Windows Server 2012 R2

Original KB number: 2553863

Symptoms
When setting up a KMS host, you may receive the following Event ID in the application
event log on the KMS host.

Source: Security-SPP
Event ID: 12293
Publishing the Key Managment Service (KMS) to DNS in the contoso.com domain
failed.
Info: 0x80072338

0x80072338: DNS_ERROR RCODE_BADSIG

DNS signature failed to verify.

Cause
This error can occur if the KMS host doesn't have permissions to edit the existing
_VLMCS SRV record in DNS.

Resolution
Use the following steps to change the permissions to allow the new KMS host to update
the record.

1. In DNS goto Forward Lookup Zones\Contoso.com\_tcp.

2. Locate the _VLMCS record
3. Right click, choose properties
 4. On security tab, add the new KMS host computer name with Full Control
5. Restart sppssvc or slsvc service on KMS host

７ Note

These are instructions specific to Microsoft DNS server. If you're using a third party
DNS server, consult your documentation for how to change permissions.

More information
SRV records in DNS use the record name as the ID for all records of that type. The first
KMS host to create a record named VLMCS.TCP becomes the Creator/Owner of SRV
records with that name. Other KMS can't publish SRV records in that zone with that
name until given permission to do so.

The _VLMCS SRV record can be thought as an array with single name. In a default DDNS
configuration, any machine can create a unique SRV record. Once a _VLMCS record
exists, no other computer has the rights to change that record. The second and later
KMS hosts create the SRV records with the same name. The SRV record design allows a
DNS admin to explicitly and control which machines are allowed to advertise services in
the DNS zone.

When publishing to DNS is successful, the KMS host will log an Event ID 12294 in the
application event log.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you try to activate Windows
Server 2003 over the Internet: Message
Number 32777
Article • 02/19/2024

This article provides workarounds to an issue where you see an error when you activate
Microsoft Windows Server 2003 over the Internet fails.

Applies to: Windows Server 2003

Original KB number: 816897

Symptoms
When you try to activate Windows Server 2003 over the Internet, Windows Product
Activation may be unsuccessful and you may experience the following issues:

You receive a message that prompts you for a user name and password.

You receive the following error message:

Unable to establish a connection with the activation server. Please check your
network settings and confirm that you are able to connect to the Internet, then
try again. Message number 32777.

Windows Product Activation is unsuccessful whether or not you enter your user name
and password.

Cause
This issue occurs if both of the following conditions are true:

Microsoft Internet Explorer's Enhanced Security Configuration is enabled on the

server.
You connect to the Internet through a proxy server where Basic Authentication is
enabled.

The Internet Explorer Enhanced Security Configuration (also known as Internet Explorer
hardening) uses certificate revocation. This certificate revocation lookup process involves
a URL retrieval operation. In this case, the URL retrieval goes through the proxy server
and occurs outside the explicit context of the logged-on user. Therefore, Basic
Authentication mistakenly prompts you for a user account name and password. As the
user, you are typically not aware that certificates are being validated, and you may be
prompted repeatedly during the validation of a series of certificates.

To work around this issue, use one of the following methods.

７ Note

The following methods are listed in the order of the most preferred to least
preferred, with the most preferred method appearing first.

Workaround 1: Don't use Basic Authentication

Avoid using Basic Authentication on the proxy server. If you must use Basic
Authentication, exclude the URLs for the certificate revocation lists (CRLs) from the
requirement for basic authentication. To do this, configure the following list of CRLs to
be unauthenticated on the proxy server:

http://crl.microsoft.com/pki/crl/productsMicrosoftProductSecureServer.crl

http://crl.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunications
.crl

http://crl.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl

http://www.microsoft.com/pki/crl/productsMicrosoftProductSecureServer.crl
http://www.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunications

.crl
http://www.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl

Workaround 2: Activate by using the telephone

If you receive the error message described in the Symptoms section of this article when
you try to activate Windows, click the Telephone button in the Activate Windows Wizard
to activate Windows over the telephone.

Workaround 3: Turn off certificate revocation in

Internet Explorer
Turn off certificate revocation in Internet Explorer to permit Windows activation to
succeed. To do so, follow these steps.
 ７ Note

Microsoft recommends that you do not turn off certificate revocation in Internet
Explorer.

1. Start Internet Explorer.

2. On the Tools menu, click Internet Options.

3. Click the Advanced tab, and then clear the following check boxes in the Settings
list:

Check for publisher's certificate revocation

Check for server certificate revocation (requires restart)

4. Click Apply, and then click OK.

5. Quit and then restart Internet Explorer.

6. Activate Windows.

7. In Internet Explorer, click Internet Options on the Tools menu.

8. Click the Advanced tab, and then select the following check boxes in the Settings
list:

Check for publisher's certificate revocation

Check for server certificate revocation (requires restart)

9. Click Apply, and then click OK.

10. Quit and then restart Internet Explorer.

More information
Because other issues may generate error message number 32777, you can view the
Setuplog.txt file to determine whether the issue described in this article is the cause of
this error. Status code 407 typically indicates the occurrence of the issue described in
this article. The following is an example of Status code 407 as it appears in a Setuplog.txt
file:

<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,4423,,DISPID_E
XTERNAL_CONNECTEDTOINTERNETEx
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1560,,tries to
 connect to the WPA HTTP server
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,2170,,Disabled
RAS Autodial for current logon session
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1480,,HTTP
status code from WPA HTTP server 407
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,2184,,Restore
value of RAS Autodial for current logon session
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1657,,could
connect to WPA HTTP server
<DateTime>,OOBE Trace,0,,GetPreferredConnection: null
<DateTime>,OOBE Trace,0,,UseModem: false
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,3049,,DISPID_E
XTERNAL_CONNECT
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,3054,,DISPID_E
XTERNAL_RECONNECT
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,4500,,DISPID_E
XTERNAL_ACTIVATE
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,6979,,Waiting
for response from m_pLicenseAgent->AsyncProcessHandshakeRequest()
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,5724,,m_pLicen
seAgent->AsyncProcessHandshakeRequest() failed. Error = 32777
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,311,,Windows
Product Activation error.
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,313,,ReturnActi
vationStatus: Status = 7, Detail = 32777
<DateTime>,OOBE Trace,0,,Activation failed. Error = 7

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to change the Volume Licensing
product key
Article • 02/19/2024

This article describes how to change the Volume Licensing product key.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 328874

Introduction

２ Warning

The steps in the article are effective only on Volume License media. If you try these
steps on OEM media or on retail media, you will not change the product key.

When you install Windows XP or Windows Server 2003, the media must match the
product key. That is, the channel (MSDN, retail, OEM, Volume License, and so on), the
SKU (Windows XP Professional, Windows XP Home Edition, and so on), and the
language (English, French, and so on) must match between the product key and the
media. It is necessary so that you can successfully enter the product key. If the
installation media does not match the product key, you receive the following error
message:

Product Key is invalid.

If you use a "leaked" product key (a product key that is known to be available to the
public) to deploy Windows XP across multiple computers (a Volume Licensing
installation), you might be unable to install Windows XP Service Pack 1 (SP1) and later
versions of Windows XP, or automatically obtain updates from the Windows Update
Web site. For example, you might receive the following error message when you install
Windows XP SP1 and later versions of Windows XP:

The Product Key used to install Windows is invalid. Please contact your system
administrator or retailer immediately to obtain a valid Product Key. You may also
contact Microsoft Corporation's Anti-Piracy Team by emailing [email protected]
if you think you have purchased pirated Microsoft software. Please be assured that
 any personal information you send to the Microsoft Anti-Piracy Team will be kept in
strict confidence.

This article is intended for an advanced computer user. You might find it easier to follow
the steps if you print this article first.

More information

Prerequisites
You must have a valid product key before you can use the information in this article. To
obtain a valid product key, click the following link to contact the Microsoft Volume
Licensing Service Center:
https://www.microsoft.com/licensing/servicecenter/home.aspx

Steps to change the volume licensing product key

This article describes two methods for how to change the Windows XP product key after
a Volume Licensing installation to resolve the issue. One method uses the Windows
Activation Wizard graphical user interface (GUI) and the other method uses a Windows
Management Instrumentation (WMI) script. The Activation Wizard method is easier.
However, if you must change the product key for multiple computers, the script method
is more suitable.

Method 1: Use the Activation Wizard

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows
If you only have a few volume licensing product keys to change, you can use the
Activation Wizard.
 ７ Note

We recommend that you run System Restore to create a new restore point before
you follow these steps.

Deactivate Windows

1. Click Start, and then click Run.

2. In the Open box, type regedit, and then click OK.

3. In the navigation pane, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WPAEvents

4. In the topic pane, right-click OOBETimer, and then click Modify.

5. Change at least one digit of this value to deactivate Windows.

Reactivate Windows and add new product key

1. Click Start, and then click Run.

2. In the Open box, type the following command, and then click OK.
%systemroot%\system32\oobe\msoobe.exe /a

3. Click Yes, I want to telephone a customer service representative to activate

Windows, and then click Next.

4. Click Change Product key.

5. Type the new product key in the New key boxes, and then click Update.

If you are returned to the previous window, click Remind me later, and then restart
the computer.

6. Repeat steps 1 and 2 to verify that Windows is activated. You receive the following
message: Windows is already activated. Click OK to exit.

7. Click OK.

8. Install Windows XP Service Pack 1a or a later version of Windows XP.

If you cannot restart Windows after you install Windows XP SP1 or a later version of
Windows XP, try the following steps:
 1. Restart your computer and start pressing F8 until you see the Windows Advanced
Options menu.
2. Select Last Known Good Configuration from the menu and press ENTER. This
option starts Windows by using a previous good configuration.
3. Repeat steps 1 through 8 under "Reactivate Windows and add new product key."

If you can install SP1 or a later version of Windows XP and you can restart Windows, you
have resolved the issue. If the issue has not been resolved, try method 2 or see the
"Next Steps" section for more troubleshooting resources.

Method 2: Use a script

If you must change the product key for multiple computers, we recommend this
method. You can create a WMI script that changes the volume licensing product key,
and then deploy this script in a startup script.

The sample ChangeVLKey2600.vbs script and the sample ChangeVLKeySP1 script that
are described in this section use the new volume licensing key that you want to enter as
a single argument. It is in a five-part alphanumeric form.

We recommend that you use the ChangeVLKey2600.vbs script on Windows XP-based

computers that are not running Windows XP SP1 and later versions of Windows XP and
that you use the ChangeVLKeySP1.vbs script on Windows XP-based computers that are
running Windows XP SP1 and later versions of Windows XP. These scripts perform the
following functions:

They remove the hyphen characters (-) from the five-part alphanumeric product
key.
They create an instance of the win32_WindowsProductActivation class.
They call the SetProductKey method with the new volume licensing product key.
You can create a batch file or a cmd file that uses either of the following sample
scripts, together with the new product key as an argument.

You can deploy it as part of a startup script or run it from the command line to change
the product key on a single computer.

Examples

For more information about how to script the product key, visit the following Microsoft
Web site:
https://technet.microsoft.com/library/bb457096.aspx
ChangeVLKeySP1.vbs

Visual Basic Script

'
' WMI Script - ChangeVLKey.vbs
'
' This script changes the product key on the computer
'
'***************************************************************************
ON ERROR RESUME NEXT

if Wscript.arguments.count<1 then
Wscript.echo "Script can't run without VolumeProductKey argument"
Wscript.echo "Correct usage: Cscript ChangeVLKey.vbs ABCDE-FGHIJ-KLMNO-
PRSTU-WYQZX"
Wscript.quit
end if

Dim VOL_PROD_KEY
VOL_PROD_KEY = Wscript.arguments.Item(0)
VOL_PROD_KEY = Replace(VOL_PROD_KEY,"-","")'remove hyphens if any

for each Obj in GetObject("winmgmts:

{impersonationLevel=impersonate}").InstancesOf
("win32_WindowsProductActivation")
result = Obj.SetProductKey (VOL_PROD_KEY)
if err <> 0 then
WScript.Echo Err.Description, "0x" & Hex(Err.Number)
Err.Clear
end if
Next

ChangeVLKey2600.vbs

Visual Basic Script

'
' WMI Script - ChangeVLKey.vbs
'
' This script changes the product key on the computer
'
'***************************************************************************
ON ERROR RESUME NEXT
if Wscript.arguments.count<1 then
Wscript.echo "Script can't run without VolumeProductKey argument"
Wscript.echo "Correct usage: Cscript ChangeVLKey.vbs ABCDE-FGHIJ-KLMNO-
PRSTU-WYQZX"
Wscript.quit
end if

Dim VOL_PROD_KEY
 VOL_PROD_KEY = Wscript.arguments.Item(0)
VOL_PROD_KEY = Replace(VOL_PROD_KEY,"-","")'remove hyphens if any
Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.RegDelete "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\WPAEvents\OOBETimer" 'delete OOBETimer registry value
for each Obj in GetObject("winmgmts:
{impersonationLevel=impersonate}").InstancesOf
("win32_WindowsProductActivation")

result = Obj.SetProductKey (VOL_PROD_KEY)

if err <> 0 then
WScript.Echo Err.Description, "0x" & Hex(Err.Number)
Err.Clear
end if

Next

The following example shows how to use the ChangeVLKeySP1.vbs script from a
command line:

1. Click Start, and then click Run.

2. In the Open box, type the following command, where AB123-123AB-AB123-123AB-
AB123 is the new product key that you want to use, and then click OK:
c:\changevlkeysp1.vbs ab123-123ab-ab123-123ab-ab123

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to rebuild the Tokens.dat file when
you troubleshoot Windows activation
issues
Article • 02/19/2024

When you troubleshoot Windows activation issues, you may have to rebuild the
Tokens.dat file.

Applies to: Windows 10 - all editions, Windows Server 2012 R2, Windows Server 2019,
Windows Server 2016
Original KB number: 2736303

Rebuild the Tokens.dat file

1. Open an elevated command prompt:
a. Open Start menu or Start screen, search cmd.
b. Right click Command Prompt in the search results, and select Run as
administrator.

2. Type the following commands in the order in which they're presented. Press Enter
after each command.

a. net stop sppsvc

b. For Windows 10, Windows Server 2016 and later versions of Windows:
cd %windir%\system32\spp\store\2.0

For Windows 8.1 and Windows Server 2012 R2:

cd %windir%\system32\spp\store\2.0

For Windows 8 and Windows Server 2012:

cd %windir%\system32\spp\store

For Windows 7, Windows Server 2008 and Windows Server 2008 R2:
cd

%windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareP

rotectionPlatform

７ Note
 For Windows 8.1 that were upgraded from Windows 8, the location may
still be %windir%\system32\spp\store.

c. ren tokens.dat tokens.bar

d. net start sppsvc

e. cscript.exe %windir%\system32\slmgr.vbs /rilc

3. Restart the computer.

More information
After you rebuild theTokens.dat file, you must reinstall your product key by using one of
the following methods:

At the same elevated prompt command, type the following command, and then
press Enter:

cscript.exe %windir%\system32\slmgr.vbs /ipk \<product key>

Right-click My Computer, select Properties, and then select Change product key.

７ Note

You should never use the /upk switch to uninstall a product key. To install a
product key over an existing product key, use the /ipk switch.
For more information about Key Management Services (KMS) client setup
keys, see KMS client activation and product keys.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

The specified database is not a valid
VAMT database error message when
you try to create a database by using
VAMT 3.0 on a Windows 8 or Windows
Server 2012-based computer
Article • 02/19/2024

This article describes an issue in which you cannot create a database by using VAMT 3.0.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 2755159

Symptoms
When you try to create a database by using Volume Activation Management Tool
(VAMT) 3.0 on a computer that is running Windows 8 or Windows Server 2012, you
receive the following error message:

The specified database is not a valid VAMT database.

Cause
The issue occurs because the account that you use to log on to the computer does not
have permissions to create the database.

Resolution
To resolve the issue, log on to the computer as the local administrator, and then try to
create the database. If the issue still occurs, install Microsoft SQL Server 2008 R2
Management Studio Express (SSMSE), and then grant yourself the relevant permissions.

For more information about downloading SSMS, see Download SQL Server
Management Studio (SSMS).

For more information about SQL Server permissions, see Security and Protection
(Database Engine).
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Active Directory Based
Activation (ADBA) clients that don't
activate
Article • 02/19/2024

７ Note

This article was originally published as a TechNet blog on March 26, 2018.

I recently helped a customer with deploying Windows Server 2016 in their environment.
We took this opportunity to also migrate their activation methodology from a KMS
Server to Active Directory Based Activation.

As proper procedure for making all changes, we started the migration in the customer's
test environment. We began the deployment by following the instructions in Active
Directory-Based Activation vs. Key Management Services . The domain controllers in
the test environment were all running Windows Server 2012 R2, so we didn't need to
prep the forest. We installed the role on a Windows Server 2012 R2 Domain Controller
and chose Active Directory Based Activation as the volume activation method. We
installed the KMS key and gave it a name of "KMS AD Activation (** LAB)." We followed
the blog post step by step.

We started by building four virtual machines, two Windows 2016 Server Standard and
two Windows 2016 Server Datacenter. At this point everything was great. We built a
physical server running Windows 2016 Server Standard, and the machine activated
properly.

Truthfully, the set up and configuration were super easy, so that part was simple and
straight forward. However, all the virtual machines I had built the week prior showed
that they weren't activated. I went back to the physical machine and it was fine. I went to
the customer to discuss what had happened. The first question was "What changed over
the weekend?" And as usual the answer was "nothing." This time, nothing really had
been changed, and we had to figure out what was going on.

I went to one of the problem servers, opened a command prompt, and checked the
output from the slmgr /ao-list command. The /ao-list switch displays all activation
objects in Active Directory.
The results show that we have two activation objects: one for Windows Server 2012 R2,
and the newly created KMS AD Activation (** LAB) which is the Windows Server 2016
license. This confirms the Active Directory is correctly configured to activate Windows
KMS clients.

Knowing that the slmgr command is for license activation, I continued with different
options. I tried the /dlv switch, which will display detailed license information. This
looked fine, I was running the Standard version of Windows Server 2016, there's an
Activation ID, an Installation ID, a validation URL, even a partial Product Key.
Does anyone see what I missed at this point? We'll come back to it after my other
troubleshooting steps but suffice it to say the answer is in this screenshot.

My thinking now is that for some reason, the key is broken, so I use the /upk switch,
which uninstalls the current key. While this was effective in removing the key, it's
generally not the best way to do it. Should the server get rebooted before getting a new
key it may leave the server in a bad state? I found that using the /ipk switch (which I do
later in my troubleshooting) overwrites the existing key and is a safer route to take.
I ran the /dlv switch again, to see the detailed license information. Unfortunately, that
didn't give me any helpful information, just a product key not found error. Because
there's no key since I just uninstalled it.

I figured it was a long shot, but I tried the /ato switch, which should activate Windows
against the known KMS servers (or Active Directory as the case may be). Again, just a
product not found error.

The next thought was that sometimes stopping and starting a service does the trick, so I
tried that next. I need to stop and start the Microsoft Software Protection Platform
Service (SPPSvc service). From an administrative command prompt, I use the trusty net
stop and net start commands. I notice at first that the service isn't running, so I think

this must be it.

However, after starting the service and attempting to activate Windows again, I still get
the product not found error.

I then looked at the Application Event Log on one of the trouble servers. I find an error
related to License Activation, Event ID 8198, that has a code of 0x8007007B.

While looking up this code, I found an article that says the error code means that the file
name, directory name, or volume label syntax is incorrect. Reading through the methods
described in the article, it didn't seem that any of them fit the situation. When I ran the
nslookup -type=all _vlmcs._tcp command, I found the existing KMS server (still lots of

Windows 7 and Server 2008 machines in the environment, so it was necessary to keep it
around), but also the five domain controllers as well. This indicated that it wasn't a DNS
problem and the issues were elsewhere.
So I know DNS is fine. Active Directory is properly configured as a KMS activation
source. The physical server has been activated properly. Could this be an issue with just
VMs? As an interesting side note at this point, my customer informs me that someone in
a different department has decided to build more than a dozen virtual Windows Server
2016 machines as well. So now I assume I've got another dozen servers to deal with that
won't be activating. However, those servers activated just fine.

Well, I headed back to the slmgr command to figure out how to get these monsters
activated. This time I'm going to use the /ipk switch, which will allow me to install a
product key. I went to Appendix A: KMS Client Setup Keys to get the appropriate keys
for the Standard version of Windows Server 2016. Some servers are Datacenter, but I
need to fix this one first.

I used the /ipk switch to install a product key, choosing the Windows Server 2016
Standard key.
From here on out I only captured results from my Datacenter experiences, but they were
the same. I used the /ato switch to force the activation. We get the awesome message
that the product has been activated successfully.

Using the /dlv switch again, we can see that now we have been activated by Active
Directory.
Now, what had gone wrong? Why did I have to remove the installed key and add those
generic keys to get these machines to activate properly? Why did the other dozen or so
machines activate with no issues? As I said earlier, I missed something key in the initial
stages of looking at the issue. I was thoroughly confused, so reached out to the poster
from the initial blog. The poster saw the problem right away and helped me understand
what I had missed early on.

When I ran the first /dlv switch, in the description was the key. The description was
Windows® Operating System, RETAIL Channel. I had looked at that and thought that
RETAIL Channel meant that it had been purchased and was a valid key.
When we look at the output of the /dlv switch from a properly activated server, notice
the description now states the VOLUME_KMSCLIENT channel. This lets us know that it's
indeed a volume license.
So what does that RETAIL channel mean then? Well, it means the media that was used to
install the operating system was an MSDN ISO. I went back to my customer and asked if,
by some chance, there was a second Windows Server 2016 ISO floating around the
network. Turns out that yes, there was another ISO on the network, and it had been
used to create the other dozen machines. They compared the two ISOs and sure enough
the one that was given to me to build the virtual servers was, in fact, an MSDN ISO. They
removed that MSDN ISO from their network and now we have all existing servers
activated and no more worries about the activation failing on future builds.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Windows activation error
codes
Article • 02/19/2024

This article provides troubleshooting information to help you respond to error messages
that you may receive when you try to use a Multiple Activation Key (MAK) or the Key
Management Service (KMS) to perform Volume Activation on one or more Windows-
based computers.

７ Note

This article is intended for technical support agents and IT professionals. If you're
looking for more information about Windows activation error messages, see Get
help with Windows activation errors .

Look for the error code in the following tables, then select the link to see more
information about that error code and how to resolve it.

For more information about volume activation, see Plan for volume activation.

For more information about volume activation for current and recent versions of
Windows, see Volume Activation [client].

For more information about volume activation for older versions of Windows, see
Volume Activation information for Windows Vista, Windows Server 2008, Windows
Server 2008 R2 and Windows 7.

You can also try our Virtual Agent , which can help you quickly identify and
troubleshoot issues related to KMS and MAK activation.

Diagnostic tool

７ Note

This tool is intended to resolve Windows activation issues on computers that run
Enterprise, Professional, or Server editions of Windows.

Microsoft Support and Recovery Assistant (SaRA) simplifies Windows KMS Activation
troubleshooting.
 Download the Assistant

The SaRA tool troubleshoots by attempting to start up Windows. If Windows returns an

activation error code, the tool then displays targeted solutions for the following known
error codes:

0xC004F038
0xC004F039
0xC004F041
0xC004F074
0xC004C008
0x8007007b
0xC004C003
0x8007232B

Summary of error codes

The following table lists known error codes for Windows Activation, and includes links to
relevant sections later in this article that can help you resolve related issues.

ﾉ Expand table

Error code Error message Activation

type

0x8004FE21 This computer is not running genuine Windows. MAK

KMS client

0x80070005 Access denied. The requested action requires elevated privileges. MAK
KMS client
KMS host

0x8007007b 0x8007007b DNS name does not exist. KMS client

0x80070490 The product key you entered did not work. Check the product key MAK
and try again, or enter a different one.

0x800706BA The RPC server is unavailable. KMS client

0x8007232A DNS server failure. KMS host

0x8007232B DNS name does not exist. KMS client

0x8007251D No records found for DNS query. KMS client

0x80092328 DNS name does not exist. KMS client

Error code Error message Activation
type

0xC004B100 The activation server determined that the computer could not be MAK
activated.

0xC004C001 The activation server determined the specified product key is MAK
invalid.

0xC004C003 The activation server determined the specified product key is MAK
blocked.

0xC004C008 The activation server determined that the specified product key KMS
could not be used.

0xC004C020 The activation server reported that the Multiple Activation Key has MAK
exceeded its limit.

0xC004C021 The activation server reported that the Multiple Activation Key MAK
extension limit has been exceeded.

0xC004F009 The Software Protection Service reported that the grace period MAK
expired.

0xC004F00F The Software Licensing Server reported that the hardware ID MAK
binding is beyond level of tolerance. KMS client
KMS host

0xC004F014 The Software Protection Service reported that the product key is MAK
not available. KMS client

0xC004F02C The Software Protection Service reported that the format for the MAK
offline activation data is incorrect. KMS client

0xC004F035 The Software Protection Service reported that the computer could KMS client
not be activated with a Volume license product key. KMS host

0xC004F038 The Software Protection Service reported that the computer could KMS client
not be activated. The count reported by your Key Management
Service (KMS) is insufficient. Please contact your system
administrator.

0xC004F039 The Software Protection Service reported that the computer could KMS client
not be activated. The Key Management Service (KMS) is not
enabled.

0xC004F041 The Software Protection Service determined that the Key KMS client
Management Server (KMS) is not activated. KMS needs to be
activated.

0xC004F042 The Software Protection Service determined that the specified Key KMS client
 Error code Error message Activation
type

Management Service (KMS) cannot be used.

0xC004F050 The Software Protection Service reported that the product key is MAK
invalid. KMS
KMS client

0xC004F051 The Software Protection Service reported that the product key is MAK
blocked. KMS

0xC004F064 The Software Protection Service reported that the non-genuine MAK
grace period expired.

0xC004F065 The Software Protection Service reported that the application is MAK
running within the valid non-genuine period. KMS client

0xC004F06C The Software Protection Service reported that the computer could KMS client
not be activated. The Key Management Service (KMS) determined
that the request timestamp is invalid.

0xC004F074 The Software Protection Service reported that the computer could KMS client
not be activated. No Key Management Service (KMS) could be
contacted. Please see the Application Event Log for additional
information.

To resolve the errors, see the following causes of each error message and
troubleshooting steps.

0x8004FE21 This computer isn't running genuine

Windows
When you receive this error, you see this error message:

This computer is not running genuine Windows.

Causes:

This issue can occur for several reasons:

A user or program installed language packs (MUI) on computers running editions

of Windows not licensed for extra language packs.

７ Note
 This issue doesn't necessarily indicate tampering. Some applications can
install multilingual support even when that edition of Windows isn't licensed
for those language packs.

When malware modifies Windows in order to install more features.

Certain system files are corrupted.

Solution:

To resolve this issue, you must reinstall the operating system.

0x80070005 Access denied

The full text of this error message is:

Access denied. The requested action requires elevated privileges.

Cause:

User Account Control (UAC) prohibits activation processes from running in a non-
elevated command prompt window.

Solution:

1. Open the Start menu and search for Command Prompt.

2. Right-click Command Prompt, and select Run as administrator.
3. In the command prompt, run slmgr.vbs .

0x8007007b DNS name doesn't exist

When you encounter this error, you see this error message:

DNS name does not exist.

Cause:

This issue can occur if the KMS client can't find the KMS SRV resource records in DNS.

Solution:

For more information about troubleshooting such DNS-related issues, see Common
troubleshooting procedures for KMS and DNS issues.
0x80070490 The product key didn't work
When you encounter this issue, you see this error message:

The product key that you entered didn't work. Check the product key and try again,
or enter a different one.

Causes:

There are two possible reasons why you may encounter this issue:

The Multiple Activation Key (MAK) wasn't valid.

A known issue in Windows Server 2019 interfered with authenticating the product
key.

Solution:

To work around this issue and activate the computer:

1. Open the Start menu and search for Command Prompt.

2. Right-click Command Prompt, and select Run as administrator.

3. In the command prompt, run the following command:

Console

slmgr -ipk <5x5 key>

0x800706BA The RPC server is unavailable

When you encounter this error, you see this error message:

The RPC server is unavailable.

Cause:

You can encounter this issue because of the following things:

The KMS host doesn't have configured firewall settings.

DNS SRV records are stale.

Solution 1:
On the KMS host, make sure you've enabled the firewall exception for the Key
Management Service on TCP port 1688.

Solution 2:

Check your DNS SRV records and make sure they point to a valid KMS host.

Solution 3:

If you still see this error after performing solutions 1 and 2, check your network
connections to make sure you can access the server.

You can also follow the instructions in Common troubleshooting procedures for KMS
and DNS issues.

0x8007232A DNS server failure

When you encounter this issue, you see this error message:

DNS server failure.

Cause:

You can encounter this issue when the system has network or DNS issues.

Solution:

To resolve this issue, troubleshoot your network connections and DNS by following the
instructions in Common troubleshooting procedures for KMS and DNS issues.

0x8007232B DNS name doesn't exist

When you encounter this error, you see this error message:

DNS name does not exist.

Cause:

This error message appears when the KMS client can't find KMS server resource records
(SRV RRs) in DNS.

Solution 1:
Make sure you've installed a KMS and the DNS publishing is enabled (default). If the
DNS isn't available, point the KMS client to the KMS host by opening an elevated
command prompt and running the following command:

Console

slmgr.vbs /skms <kms_host_name>

Solution 2:

If you don't have a KMS host, get and install an MAK, then try activating the system
again.

If these solutions don't resolve the issue, see the instructions in Common
troubleshooting procedures for KMS and DNS issues.

0x8007251D No records found for DNS query

When you encounter this error, you see this error message:

No records found for DNS query.

Cause:

This error message appears when the KMS client can't find the KMS SRV records in the
DNS.

Solution:

To resolve this issue, follow the instructions in Common troubleshooting procedures for
KMS and DNS issues to troubleshoot your network connections and DNS.

0x80092328 DNS name doesn't exist

When you encounter this error, you see this error message:

DNS name does not exist.

Cause:

You can encounter this issue if the KMS client can't find the KMS SRV resource records in
DNS.
Solution:

To resolve this issue, follow the instructions in Common troubleshooting procedures for
KMS and DNS issues to troubleshoot your network connections and DNS.

0xC004B100 The activation server determined that the

computer couldn't be activated
When you encounter this error, you see this error message:

The activation server determined that the computer could not be activated.

Cause:

You can encounter this issue when Microsoft doesn't support the MAK you're using.

Solution:

To troubleshoot this issue, verify that the MAK you're using is the same MAK that
Microsoft provided to you. To verify that the MAK is valid, contact the Microsoft
Licensing Activation Centers .

0xC004C001 The activation server determined the

specified product key is invalid
When you encounter this error, you see this error message:

The activation server determined the specified product key is invalid.

Cause:

You can encounter this issue when the MAK you enter isn't valid.

Solution:

You can try reentering the MAK to make sure you entered the correct information.
Otherwise, verify the MAK you're using is valid by contacting the Microsoft Licensing
Activation Centers .

0xC004C003 The activation server determined the

specified product key is blocked
When you encounter this error, you see this error message:

The activation server determined the specified product key is blocked.

Cause:

You can encounter this issue if the MAK is blocked on the activation server.

Solution:

Contact the Microsoft Licensing Activation Centers to obtain a new MAK. After you
obtain the new MAK, try installing and activating Windows again.

0xC004C008 The activation server determined that the

specified product key couldn't be used
When you encounter this error, you see this error message:

The activation server determined that the specified product key could not be used.

Cause:

This error message appears when the KMS key has exceeded its activation limit. You can
only activate KMS host keys up to 10 times on no more than six different computers.

Solution:

Contact the Microsoft Licensing Activation Centers to request more activations for
activation server permission.

0xC004C020 The activation server reported that the

Multiple Activation Key has exceeded its limit
When you encounter this error, you see this error message:

The activation server reported that the Multiple Activation Key has exceeded its
limit.

Cause:

This error message appears when the MAK exceeds its activation limit. By design, you
can only activate a MAK a limited number of times.
Solution:

Request more activations to increase limit. If you require more activations, contact the
Microsoft Licensing Activation Centers .

0xC004C021 Multiple Activation Key extension limit

exceeded
When you encounter this error, you see this error message:

The activation server reported that teh Multiple Activation Key extension limit has
been exceeded.

Cause:

This error message appears when the MAK exceeds its activation limit. By design, you
can only activate a MAK a limited number of times.

Solution:

Request more activations to increase extension limit. If you need more activations,
contact the Microsoft Licensing Activation Centers .

0xC004F009 The Software Protection Service reported

that the grace period expired
When you encounter this error, you see this error message:

The Software Protection Service reported that the grace period expired.

Cause:

This error message appears when the grace period expires before you activate the
system. The system is currently in the Notifications state.

Solution:

For assistance, contact the Microsoft Licensing Activation Centers .

0xC004F00F hardware ID binding is beyond level of

tolerance
When you encounter this error, you see this error message:

The Software Licensing Server reported that the Hardware ID binding is beyond
level of tolerance.

Cause:

This error message appears when the system hardware changes or its drivers update.

Solution 1:

If you're using MAK activation, reactivate the system phone by using either online or
phone activation during the Out of Tolerance (OOT) grace period.

Solution 2:

If you're using KMS activation, try one of the following things:

Restart Windows.

Open an elevated command prompt and run the following command:

Console

slmgr.vbs /ato

0xC004F014 The Software Protection Service reported

that the product key isn't available
When you encounter this error, you see this error message:

The Software Protection Service reported that the product key is not available.

Cause:

This issue happens when no product keys are installed on the system.

Solution:

If you're using MAK activation, install a MAK product key.

If you're using KMS activation:

1. Check the Pid.txt file located on the installation media in the \sources folder for a
KMS Setup key.
 2. Install the key.

0xC004F02C the format for the offline activation data is

incorrect
When you encounter this error, you see this error message:

The Software Protection Service reported that the format for the offline activation
data is incorrect.

Cause:

This error message appears when the system detects the data entered during phone
activation isn't valid.

Solution:

To resolve this issue, make sure you entered the caller ID (CID) correctly.

0xC004F035 Invalid Volume License Key

When you encounter this error, you see this error message:

Error: Invalid Volume License Key. In order to activate, you need to change your
product key to a valid Multiple Activation Key (MAK) or Retail key. You must have a
qualifying operating system license AND a Volume license Windows 7 upgrade
license, or a full license for Windows 7 from a retail source. ANY OTHER
INSTALLATION OF THIS SOFTWARE IS IN VIOLATION OF YOUR AGREEMENT AND
APPLICABLE COPYRIGHT LAW.

This error message indicates that the computer doesn't have a Windows marker in its
BIOS that identifies it as an OEM system running a qualifying edition of Windows. In
short, this message means the Volume License Key is invalid. This information is required
for KMS client activation.

Cause:

Microsoft only licenses Windows 7 Volume editions for upgrade. Microsoft doesn't
support installing a Volume operating system on a computer that doesn't already have a
qualifying operating system installed.

Solution:
Activate your Volume License Key by using the following steps:

1. Change your product key to a valid Multiple Activation Key (MAK) or Retail key. To
change your key, you must have both a qualifying operating system license and a
Volume license Windows 7 upgrade license, or a full license for Windows 7 from a
retail source.
2. Try to activate your key again.

If you see error message 0x80072ee2 when you attempt to activate your key again, you
need to activate your key by phone.

To activate your key by phone:

1. Open a command prompt and run slmgr /dti , then record the value of the
Installation ID.
2. Contact the Microsoft Licensing Activation Center and provide the Installation ID
in order to receive a Confirmation ID.
3. To activate by using the Confirmation ID, run slmgr /atp <Confirmation ID> .

0xC004F038 The count reported by your Key

Management Service (KMS) is insufficient
When you encounter this issue, you see this error message:

The Software Protection Service reported that the computer couldn't be activated.
The count reported by your Key Management Service (KMS) is insufficient. Please
contact your system administrator.

Cause:

You normally encounter this issue when the count on the KMS host isn't high enough.
For Windows Server, the KMS count must be greater than or equal to five. For Windows
(client), the KMS count must be greater than or equal to 25.

Solution:

Add computers to the KMS pool. Before you can use KMS to activate Windows, you
must have more computers in the KMS pool. To obtain the current count on the KMS
host, run Slmgr.vbs /dli .

0xC004F039 The Key Management Service (KMS) isn't

enabled
When you encounter this issue, you see this error message:

The Software Protection Service reported that the computer couldn't be activated.
The Key Management Service (KMS) isn't enabled.

Cause:

This issue occurs when KMS doesn't respond to a KMS request.

Solution:

To resolve this issue, troubleshoot the network connection between the KMS host and
the client. Make sure that a firewall isn't blocking or otherwise filtering TCP port 1688
(default).

0xC004F041 The Software Protection Service determined

that the Key Management Server (KMS) isn't activated
When you encounter this issue, you see this error message:

The Software Protection Service determined that the Key Management Server (KMS)
isn't activated. KMS needs to be activated.

Cause:

This issue occurs when the KMS host hasn't been activated.

Solution:

To resolve this issue, activate the KMS host by using either online or telephone
activation.

0xC004F042 the specified Key Management Service

(KMS) can't be used
When you encounter this error, you see this error message:

The Software Protection Service determined that teh specified Key Management
Service cannot be read.

Cause:
You may encounter this issue when the KMS client tried to contact a KMS host that
couldn't activate the client software. This scenario is common in mixed environments
with application-specific and operating system-specific KMS hosts.

Solution:

To resolve this issue, make sure your KMS clients are connection to the correct hosts,
especially if you're using specific KMS hosts to activate specific applications or OSes.

0xC004F050 The Software Protection Service reported

that the product key is invalid
When you encounter this error, you see this error message:

The Software Protection Service reported that the product key is invalid.

Cause:

You can encounter an issue if there was a typo or if you try to use a Beta key on a
generally available version of the operating system.

Solution:

To resolve this issue, make sure you're installing the correct KMS key on the
corresponding version of Windows. Make sure you've entered the correct characters and
numbers. If you're copying and pasting the key, make sure the Clipboard didn't replace
the hyphens with em-dashes.

0xC004F051 The Software Protection Service reported

that the product key is blocked
When you encounter this error, you see this error message:

The Software Protection Service reported that the product key is blocked.

Cause:

This error message appears when Microsoft blocks the product key.

Solution:

To resolve this issue, get a new MAK or KMS key, install it on the system, then try
activating again.
0xC004F064 The Software Protection Service reported
that the non-genuine grace period expired
When you encounter this error, you see this error message:

The Software Protection Service reported that teh non-genuine grace period
expired.

Cause:

This error occurs when Windows Activation Tools (WAT) determines that a system that's
trying to be activated isn't authentic.

Solution:

To resolve this issue, contact the Microsoft Licensing Activation Centers for assistance.

0xC004F065 the application is running within the valid

non-genuine period
When you encounter this error, you see this error message:

The Software Protection Service reported that the application is running within the
valid non-genuine period.

Cause:

You may encounter this error message because WAT has determined the system trying
to activate isn't genuine. However, because of the Non-Genuine Grace Period, the
system continues to run.

Solution:

To resolve this issue, you must get and install a genuine product key, then activate the
system before the grace period ends. If you don't, the system goes into the Notification
state at the end of the grace period.

0xC004F06C The request timestamp is invalid

When you encounter this issue, you see this error message:
 The Software Protection Service reported that the computer couldn't be activated.
The Key Management Service (KMS) determined that the request timestamp is
invalid.

Cause:

You can encounter this issue if the system time on the client computer is too different
from the time on the KMS host. Time synchronization is important to system and
network security, so desynchronization can cause issues to occur.

Solution:

To resolve this issue, you need to change the system time on the client to match the
KMS host. We recommend you use a Network Time Protocol (NTP) time source or Active
Directory Domain Services for time synchronization. This issue uses UTP time, so time
zone selection doesn't affect it.

0xC004F074 No Key Management Service (KMS) could be

contacted
When you encounter this issue, you see this error message:

The Software Protection Service reported that the computer couldn't be activated.
No Key Management Service (KMS) could be contacted. Please see the Application
Event Log for additional information.

Cause:

This issue occurs when all the KMS host systems your client tires to contact return errors.

Solution:

To resolve this issue:

1. Open the Application Event Log.

2. Identify each event associated with the activation attempt that has an Event ID of
12288.
3. Troubleshoot each of these errors by following the instructions in Common
troubleshooting procedures for KMS and DNS issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Activation fails with error
code: 0x8007267C
Article • 02/19/2024

This article provides solutions to an issue where Windows Activation fails with the error
code 0x8007267C.

Applies to: Windows 10 - all editions, Windows 7 Service Pack 1, Windows Server 2012
R2
Original KB number: 2009462

Symptoms
Windows Activation fails with the error code 0x8007267C.

Cause
This issue will occur if the machine attempting to activate does not have a DNS server
registered in its network properties.

Error code 0x8007267C definition:

No DNS servers configured for local system
DNS_ERROR_NO_DNS_SERVERS

Resolution 1: Register DNS server in the

network properties and test name resolution
To resolve this problem, client connectivity to a DNS server must be resolved. The
following steps may help to expose the problem:

1. On the client getting the error, open a command prompt and run IPCONFIG /all .

2. Verify the assigned IP address, subnet mask, DNS server and default gateway are
set with the correct values for your environment.

3. Verify basic IP connectivity to the DNS Server using the PING command using the
address of the DNS server from step 1.

ping <DNS Server IP address>

If connectivity to the DNS server is failing, consider using the following as a guide to
troubleshoot further:

Troubleshooting TCP/IP

After resolving the connectivity issues to the DNS server, reattempt activation using the
following command from an Elevated Command prompt

Console

cscript \windows\system32\slmgr.vbs -ato

Resolution 2: Use a MAK (multiple activation

key) and phone based activation
If you do not have a DNS server connected to the network, you can switch to a MAK
product key to activate your volume license installation. If you are using MSDN media or
TechNet media, you must change the product key to the product key provided. The
MSDN product key or the TechNet product key for Windows Server 2008 or for
Windows Vista Enterprise is the MAK product key.

Use the following command to change the product key to the MAK product key:

slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Then, launch the phone activation wizard to complete the activation of the machine slui
04.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows installation fails with error:
The product key entered does not
match any of the Windows images
available for installation. Enter a
different product key
Article • 02/19/2024

This article describes the The product key entered does not match any of the Windows
images available for installation. Enter a different product key error that occurs when
you install Windows.

Applies to: Windows 10 - all editions, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2
Original KB number: 2796988

Symptoms
During the installation of Windows, the setup may fail after prompting for language and
keyboard selections. Additionally, you may receive the following error message:

The product key entered does not match any of the Windows images available for
installation. Enter a different product key.

Cause
This problem can occur if the supplied product key doesn't match the media that is
being used to install Windows. The supplied product key may be in an unattended file,
in the EI.CFG file, in the PID.txt file, or in the firmware of the BIOS. Windows computers
that come with the operating system installed ship with the product key in the firmware,
and if that product key doesn't match the media, you'll see the error message above.

For example: Installing Windows Server on a computer than came from the
manufacturer with Windows 10 installed is likely to cause this problem.

Resolution
To resolve this problem, use one of the following methods that applies to the scenario:
 1. If there's an Unattend file, Edition Configuration (EI.cfg) file or the Product ID
(PID.txt) file on the system, change the product key to the correct one for the
media you're trying to install.
2. If the system has a Product key in the Motherboard (O. A. 3.0 [OEM Activation]
supplies an OEM product key in the firmware) you should use an Unattend file,
Edition Configuration (EI.cfg) file or the Product ID (PID.txt) file.

More information
When installing Windows, setup.exe uses the following priority logic for product keys:

1. Answer file (Unattended file, EI.cfg, or PID.txt)

2. OA 3.0 product key in the BIOS/Firmware
3. Product key entry screen

If a key is supplied, the key is attempted to be use with the image that is available on
the media being installed. If the supplied product key doesn't match step 1 from above
logic, an image in the WIM file, then the setup will fail with the error message
mentioned in Symptoms section. If there's no product key supplied in the step 1 and
step 2, you'll get the product key prompt during setup.

７ Note

Volume License media supplies a product key with the media so it succeeds
with step 1 logic.
You should not see this issue with Volume License media unless you are using
an Unattend file or have modified files on the media to change or replace the
EI.cfg or PID.txt.
How to drop a PID.txt with the product key specified: Windows Setup Edition
Configuration and Product ID Files (EI.cfg and PID.txt)

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows is not genuine error
Article • 02/19/2024

This article helps fix the 0x80070005 error that occurs when you log on to a computer.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2704233

Symptoms
When you log on to a computer that is running Windows, you receive the following
Windows Activation message:

Windows is not genuine

Your computer might be running a counterfeit copy of Windows.

Additionally, the desktop background is black, and you receive the following error
message in the lower-right corner of the screen:

The copy of Windows in not genuine

When you view the System properties in Control Panel, the following information is
displayed:

７ Note

To view the System properties, click Start, click Control Panel, click System and
Security, and then click System.

You must activate today. Activate Windows now.

If you use the slmgr.vbs /dlv script to view the licensing status, you receive the following
message:

Error: 0x80070005 Access denied: the requested action requires elevated privileges

７ Note

This error message may also occur when a command that is being executed
requires an elevated command prompt and is unrelated to the issue discussed
here.
If you see a message that Windows might not be genuine, and there's no
error code, go to Genuine Windows: frequently asked questions .

Resolution
To resolve this problem, use the following methods, depending on your scenario.

Scenario 1: Lack of permissions

The network service account has to have full control and read permissions in the
following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profilelist\S-1-5-

20

The permissions may have been removed when a Plug and Play Group Policy Object
(GPO) was applied.

To resolve the problem in this scenario, use method A or method B.

Method 1: Edit the permissions of the Group Policy
1. Determine the source of the policy. To do this, follow these steps:

a. On the computer that is experiencing the Activation error message, run the
Resultant Set of Policy wizard. To do this, click Start, type rsop.msc in the Search
box, and then press Enter.

b. In the navigation pane, expand the following containers: See image

Computer Configuration
Windows Settings
Security Settings

c. In the navigation pane, click System Services.

d. If the Plug and Play service is configured through a Group Policy setting, you
see the GPO listed here with settings other than Not Defined. Additionally, you
can see which GPO is applying this setting.

2. Open the GPO that is identified in step 1, and then open the corresponding Group
Policy setting.
 3. Click Edit Security, and then click Advanced.

4. In the Advanced Security Settings for Plug and Play window, click Add, and then
add the SERVICE account.

5. Click OK.

6. Select the following permissions in the Allow section, and then click OK:

Query template
Query status
Enumerate dependents
Interrogate
User-defined control
Read permissions

７ Note

These are the minimum required permissions.

7. Run gpupdate /force after you apply the previous permissions to the Group Policy
setting. To do this, click Start, type gpupdate /force in the Search box, and then
press Enter.

8. Make sure that the appropriate permissions are applied. To do this, click Start, type
sc sdshow plugplay in the Search box, and then click OK.

The following are the permissions that are applied to the Plug and Play service in the
security descriptor definition language (SDDL):

D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWLOCRRC;;;IU)
(A;;CCLCSWLOCRRC;;;SU)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

(A;;CC LC SW LO CR RC ;;;SU is an Access Control Entry (ACE) that allows the following
rights to SU (SDDL_SERVICE - Service logon user):

A: Access Allowed
CC: Create Child
LC: List Children
SW: Self Write
 LO: List Object
CR: Control Access
RC: Read Control
SU: Service Logon User

If there are no GPOs in place, the default registry permissions have been changed. To
work around this problem, follow these steps:

1. Start Registry Editor on the computer that is receiving the error message. To do
this, click Start, type regedit in the Search box, and then press Enter.

2. Right-click the registry key HKEY_USERS\S-1-5-20 , and then click Permissions.

3. If the NETWORK SERVICE isn't present, click Add.

4. In Enter the object names to select area, type network service, click Check Names,
and then click OK.

5. Click NETWORK SERVICE, and then select the Full Control and Read permissions.
 6. Click OK.

7. Restart the computer.

8. After you restart the computer, you may have to activate the copy of Windows.
Complete the activation.

Method 2: Disable the Plug and Play GPO

７ Note

This method is intended for advanced computer users and cannot be performed on
computers that are running Windows 7 Home Premium, Windows 7 Home Basic, or
Windows 7 Starter. For help with advanced troubleshooting, ask your system
administrator or Contact Microsoft .

To disable the Plug and Play GPO, follow these steps:

1. Determine the source of the policy. To do this, follow these steps:

a. On the computer that is experiencing the Activation error message, run the
Resultant Set of Policy wizard. To do this, click Start, type rsop.msc in the Search
box, and then press Enter.
b. In the navigation pane, expand the following containers:
 Computer Configuration
Windows Settings
Security Settings
c. In the navigation pane, click System Services.
d. If the Plug and Play service is configured through a Group Policy setting, you
see the GPO listed here with settings other than Not Defined. Additionally, you
can see which Group Policy is applying this setting.

2. Disable the Group Policy settings and force the Group Policy to be reapplied. To do
this, follow these steps:

3. Edit the Group Policy that is identified in Step 1 and change the setting to Not
Defined. Or, follow the steps in Method 1 to add the required permissions for the
Network Service account.

4. Reapply the Group Policy setting. To do this, click Start, type gpupdate /force in
the Search box, and then press Enter.

７ Note

You may have to restart the computer.

Scenario 2: Missing registry entries

One or more of the following registry subkeys is missing:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profilelist\S-
1-5-18

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profilelist\S-
1-5-19

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profilelist\S-

1-5-20

To resolve this problem in this scenario, follow these steps:

1. Copy the text below into a text editor such as Notepad, and then save the text file
as Profilelist.reg.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList\S-1-5-18]
 "Flags"=dword:0000000c
"State"=dword:00000000
"RefCount"=dword:00000001
"Sid"=hex:01,01,00,00,00,00,00,05,12,00,00,00
"ProfileImagePath"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,\
00,6f,00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,\
5c,00,63,00,6f,00,6e,00,66,00,69,00,67,00,5c,00,73,00,79,00,73,00,74,00,65,\
00,6d,00,70,00,72,00,6f,00,66,00,69,00,6c,00,65,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList\S-1-5-19]
"ProfileImagePath"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,\
00,73,00,5c,00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,50,00,72,00,6f,00,\
66,00,69,00,6c,00,65,00,73,00,5c,00,4c,00,6f,00,63,00,61,00,6c,00,53,00,65,\
00,72,00,76,00,69,00,63,00,65,00,00,00
"Flags"=dword:00000000
"State"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList\S-1-5-20]
"ProfileImagePath"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,\
00,73,00,5c,00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,50,00,72,00,6f,00,\
66,00,69,00,6c,00,65,00,73,00,5c,00,4e,00,65,00,74,00,77,00,6f,00,72,00,6b,\
00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,00,00
"Flags"=dword:00000000
"State"=dword:00000000

2. Merge profilelist.reg. To do this, right-click the file that you saved in step 1, and
then click Merge.

3. Restart the computer.

4. Activate Windows.

Check whether the problem is fixed. If the problem is fixed, you're finished with this
section. If the problem isn't fixed, you can contact support .

Advanced information
Because the Licensing service uses Plug and Play to obtain hardware ID information and
binds the license to the computer, this setting can result in an activated system
appearing to be out of tolerance. The default permissions of the Plug and Play policy
don't grant the Licensing service the appropriate rights to access the Plug and Play
service. The Licensing service runs under the Network Service account.
Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error code: 0xc004f063 is displayed
when trying to activate or validate an
OEM version of Windows 8 or Windows
Server 2012
Article • 02/19/2024

This article provides a solution to an 0xc004f063 error that occurs when you try to
activate or validate an OEM version of Windows.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2817024

Symptoms
When you try to validate an OEM version of Windows 8 or Windows Server 2012, you
may receive the following error message:

Error code : 0xc004f063 The Software Licensing Service reported that the computer
BIOS is missing a required license.

Cause
This error usually occurs if a hardware is changed or any hardware device malfunctions
and Windows is unable to verify the license again. Windows is unable to read the SLIC
table in the BIOS that is required to be able to self-activate the OEM_SLP Key that is
currently in use. This happens due to one of the following reasons:

1. Service Tag or the Service Number is not updated by the OEM vendor after
motherboard replacement.
2. BIOS contains a default or a garbage value for Service Tag.
3. BIOS has incorrect product information.

Resolution
Contact the OEM vendor to update the BIOS that has the updated Serial Number or
Service Tag.
More information
This issue mostly occurs on OEM_SLP machines wherein Windows is bound with the
Service Tag of the machine. If an OEM_SLP Windows is validating its license after any
hardware change apart from the key, it will also verify the Service Tag number in the
BIOS.

７ Note

To check the Service Tag number on a machine, run the command wmic bios get
serialnumber .

Upgrading the BIOS is an effort to put the correct SLIC table on the machine. Software
Licensing Description Table (SLIC) is a digital signature placed inside the BIOS by the
system manufacturer. The OEM-SLP Key, and an XML formatted OEM certificate (issued
by Microsoft to each OEM) will be verified against this OEM-specific SLIC and auto
activate if everything is in order.

Data collection
If you need assistance from Microsoft support, we recommend you collect the
information by following the steps mentioned in Gather information by using TSS for
deployment-related issues.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server networking
troubleshooting documentation
Article • 03/18/2024

The topics in this section provide solutions and scenario guides to help you
troubleshoot and self-solve Networking-related issues. The topics are divided into
subcategories. Browse the content or use the search feature to find relevant content.

Networking sub categories

Access to remote file shares (SMB or DFS Namespace)
Background Intelligent Transfer Service (BITS)
DFSR
DNS
Dynamic Host Configuration Protocol (DHCP)
FRS
IP Address Management (IPAM)
Network Load Balancing (NLB)
RADIUS - Network Policy Server (NPS) or Internet Authentication Service (IAS)
Remote access
TCP/IP communications
Webwindows-client and WebDAV
Windows Firewall with Advanced Security (WFAS)
Windows NIC Teaming (Load Balance Failover)
WINS
Wireless networking and 802.1X authentication

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"The namespace cannot be queried.
Access is denied" error when you try to
create a domain-based DFS namespace
Article • 02/28/2024

This article describes how to resolve an issue in which you see an access denied error
when you try to create a domain-based namespace.

Applies to: Windows Server 2019

Symptoms
When you sign in to Windows by using an account that belongs to the Domain Admins
group, and then you try to create a domain-based namespace on any Distributed File
System (DFS) namespace server, the operation fails. Windows returns an error message
that resembles the following:

\contoso.com\Public The namespace cannot be queried. Access is denied.

However, when this error occurs, you can still successfully create a standalone
namespace.

Cause
When you create a new domain-based namespace, the computer queries the Domain
Name System (DNS) server for domain information. The DNS server responds by
sending a list of the A records of the domain controllers for that domain. The computer
then contacts one of the domain controllers, and tries to use your account credentials to
authenticate by using NTLM authentication.

If your account belongs to the Protected Users group, your account can't use NTLM
authentication. In this situation, authentication fails and generates a
STATUS_ACCOUNT_RESTRICTION error.

Resolution
To resolve the issue, remove your account from the Protected Users group.
More information
Protected Users Security Group
Guidance about how to configure protected accounts

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The network folder specified is currently
mapped using a different user name
and password error
Article • 12/26/2023

This article provides workarounds to solve the error messages that occur when you try
to use different user credentials to connect to the other network share.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1, Windows
7 Service Pack 1
Original KB number: 938120

Symptoms
Consider the following scenario:

You have a Windows-based computer.

There are two network shares on a remote server.
You use user credentials to connect to one of the network shares. Then, you try to
use different user credentials to connect to the other network share.

In this scenario, you receive this error message:

The network folder specified is currently mapped using a different user name and
password. To connect using a different user name and password, first disconnect
any existing mappings to this network share.

If you select OK in response to the error message, you receive the following error
message:

Multiple connections to a server or shared resource by the same user, using more
than one user name, are not allowed. Disconnect all previous connections to the
server or shared resource and try again.

Status
This behavior is by design.
Workaround 1
Use the IP address of the remote server when you try to connect to the network share.

Workaround 2
Create a different Domain Name System (DNS) alias for the remote server, and then use
this alias to connect to the network share.

After you use one of these methods, you can use different user credentials to connect to
the network share. In this situation, the computer behaves as if it is connecting to a
different server.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot event ID 1020 events on a
file server
Article • 03/16/2024

This article explains how to troubleshoot event ID 1020 events on a Server Message
Block (SMB) file server.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4562940

Symptoms
On a Windows Server-based SMB file server, you observe Event ID 1020 events from
SMB-Server in the Microsoft-Windows-SMBServer/Operational event log. The
information in these events resembles the following message:

File system operation has taken longer than expected.

Client Name: <Client-IP/Name>
Client Address: <Client-IP>:<Client-Port>
User Name: <Username>
Session ID: <SMB-Session-ID>
Share Name: <SMB-Share-Name>
File Name: <File-Name>
Command: <SMB-Command-Code>
Duration (in milliseconds): <Duration>
Warning Threshold (in milliseconds): 15000
Guidance:
The underlying file system has taken too long to respond to an operation. This
typically indicates a problem with the storage and not SMB.

When Windows logs these events, you might also observe the following symptoms:

The SMB server's clients experience performance problems. Because the SMB
server accesses the local filesystem on behalf of its SMB clients, performance issues
on the SMB server directly affect the clients. Client applications can experience very
long wait times if their interaction with the SMB server involves several consecutive
operations and each operation experiences a delay.
The SMB server's clients might have trouble accessing shares that the SMB server
manages.
 The SMB server's local applications or other components experience performance
issues. Those applications and components might not be able to log such
performance issues.
The SMB server appears to stop responding.

７ Note

The performance problems might not affect all the SMB server's disks at the same
time or to the same degree.

Cause
Event ID 1020 indicates that the SMB server's file system can't complete a read/write
(I/O) operation within the time that's allowed. By default, the time allowed is 15 seconds.
Typically, we expect such operations to finish within a single-digit millisecond time
frame.

Malfunctioning file system filter drivers can cause delays of several seconds. Issues that
involve the SMB server's physical disks can also cause severely reduce performance.
Such issues include the following:

The physical disks are overloaded.

VSS or other backup solutions are causing prolonged disk freeze situations.
The network/storage stack of an underlying hypervisor is performing poorly.
The network connections to the physical disks are experiencing problems.
The storage appliance itself (storage area network (SAN), network attached storage
(NAS), or other type) is experiencing issues.

File system delays that are less than the 15-second threshold don't produce a warning
event but do reduce the SMB server's performance.

Resolution
Because the cause of these file system delays might depend on the specifics of your
environment, you typically have to gather more data to isolate your specific issue.

Start by reviewing the SMB server event log. Event ID 1020 events include information
that can help you identify details and patterns. The event data includes the exact
duration of the delay and the SMB command code that encountered the delay. For a list
of SMBv2 command codes, see 2.2.1.2 SMB2 Packet Header - SYNC.
Collect trace logs
To further diagnose whether the problem originates from inside the Windows operating
system (for example, filter drivers) or from outside (for example, hardware, hypervisor,
network, or storage), use an application such as Storport Trace to collect trace data. Use
a tool such as StorPortPacman to check the disk response times. StorPort traces at the
lower end of the Windows storage stack, and the SMB server (or any other application)
encounters the delays at the upper end of the stack. For more information about
StorPortPacman, see Deciphering Storport Traces 101.

High maximum response times at the StorPort level indicate that the cause for the
performance issues resides outside the operating system. To determine what latencies
the system encounters from its logical disks at application (file server) level, enable
Perfmon or WPR tracing. Such trace data also shows latencies that are less than the 15-
second warning threshold. For more information, see Measuring Disk Latency with
Windows Performance Monitor (Perfmon).

Collect kernel dump file data

For extreme delays (10 or more minutes) and under some other conditions, the SMB
server creates a live kernel dump file. Such information is valuable for troubleshooting.

The following events in the Microsoft-Windows-SMBServer/Operational event log

indicate whether a live kernel dump file is available:

Event ID 1031: The server detected a problem and has captured a live kernel dump
to collect debug information.
Event ID 1032: The server detected a problem but was unable to capture a live
kernel dump to collect debug information.

Windows puts dump files into the %SystemRoot%\LiveKernelReports folder.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot the event ID 50 error
message
Article • 03/16/2024

This article helps troubleshoot the event ID 50 error message.

Symptoms
When Windows writes information to the physical disk, it might log the following event
messages in the System log:

Event ID: 50
Event Type: Warning
Event Source: Ftdisk
Description: {Lost Delayed-Write Data} The system was attempting to transfer file
data from buffers to \Device\HarddiskVolume4. The write operation failed, and only
some of the data may have been written to the file.
Data:
0000: 00 00 04 00 02 00 56 00
0008: 00 00 00 00 32 00 04 80
0010: 00 00 00 00 00 00 00 00
0018: 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00
0028: 11 00 00 80

Event ID: 26
Event Type: Information
Event Source: Application Popup
Description: Windows - Delayed Write Failed : Windows was unable to save all the
data for the file \Device\HarddiskVolume4\Program Files\Microsoft SQL
Server\MSSQL$INSTANCETWO\LOG\ERRORLOG. The data has been lost. This error
may be caused by a failure of your computer hardware or network connection.

Please try to save this file elsewhere.

These event messages mean exactly the same thing and are generated for the same
reasons. This article focuses on event ID 50.
 ７ Note

The device and path in the description and the specific hexadecimal data in these
messages vary depending on the exact circumstances that caused the event.

More information
There are several different sources for an event ID 50 message. For example, an event ID
50 message that's logged from a MRxSmb source occurs if there's a network
connectivity problem that involves the redirector. This article addresses event ID 50
messages that refer to disk write problems. Review the event ID 50 message to verify
that it refers to a disk write problem and that this article applies.

In this context, Windows logs an event ID 50 message if a generic error occurs when
Windows tries to write information from the file system Cache Manager (not the
hardware-level cache) to the physical disk. This write behavior, known as write-back or
delayed-write caching, is part of the memory management function of Windows. Write-
back caching improves system performance. However, failures in the delayed-write
operations might cause a loss of data or volume integrity.

Typically, when an application sends a write request to Windows, Cache Manager caches
the write request and reports to the application that the write was successful. Later,
Cache Manager writes the data to the physical disk and then clears the cache. If an error
occurs during the write operation, the data is lost when Cache Manager clears the cache.

Applications or processes that write non-critical data, such as logging processes, use
Cache Manager to improve overall performance. Applications that write critical data,
such as SQL Server, do not use Cache Manager. Such applications set a
FILE_FLAG_NO_BUFFERING flag to guarantee that the transaction is completed directly to

disk. Direct-to-disk writes never generate event ID 50 messages.

An event ID 50 message is similar to an event ID 9 or an event ID 11 message. Although

the error isn't as serious as the error that's indicated by the event ID 9 or event ID 11
message, you can use the same troubleshooting techniques for an event ID 50 message
as you do for an event ID 9 and an event ID 11 message. However, remember that
anything that's in the stack can cause lost-delay writes, such as filter drivers and mini-
port drivers.

Decoding the example event

The Symptoms section of this article provides the following example of an event ID 50
message:

Event ID: 50
Event Type: Warning
Event Source: Ftdisk
Description: {Lost Delayed-Write Data} The system was attempting to transfer file
data from buffers to \Device\HarddiskVolume4. The write operation failed, and only
some of the data may have been written to the file.
Data:
0000: 00 00 04 00 02 00 56 00
0008: 00 00 00 00 32 00 04 80
0010: 00 00 00 00 00 00 00 00
0018: 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00
0028: 11 00 00 80

How to identify the target disk

You can identify the disk that was the target of the write operation by using the
symbolic link that's listed for the drive in the "Description" section of the event ID
message, for example: \Device\HarddiskVolume4.

How to decode the data section

Event ID 50 messages (and also event ID 9, 11, 51 or similar "DISK" messages) include
binary data that you can use to help identify the problem. The message includes the
following data section:

Data:
0000: 00 00 04 00 02 00 56 00
0008: 00 00 00 00 32 00 04 80
0010: 00 00 00 00 00 00 00 00
0018: 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00
0028: 11 00 00 80

７ Note
 When you are converting the hexadecimal data in the event ID message to the
status code, remember that the values are represented in the little-endian format.

The following table describes what each offset of this message represents.

ﾉ Expand table

OffsetLengthValues Length Values

0x00 2 Not Used

0x02 2 Dump Data Size = 0x0004

0x04 2 Number of Strings = 0x0002

0x06 2 Offset to the strings

0x08 2 Event Category

0x0c 4 NTSTATUS Error Code

0x10 8 Not Used

0x18 8 Not Used

0x20 8 Not Used

0x28 4 NT Status error code

The NT Status error code

The final status code is the most important piece of information in an event ID 50
message. This is the error code that's returned when the write request is made, and it's
the key source of information. In the example, the final status code is listed at 0x28 at
the sixth line of the data set. In starts with "0028:" and includes the four octets in this
line:

0028: 11 00 00 80

When you convert the hexadecimal data in the event ID 50 message to the status code,
remember that the values are represented in the little-endian format. Because the status
code is the only piece of information that you're interested in, it might be easier to view
the data in WORDS format instead of BYTES. If you do this, the bytes will be in the
correct format and the data might be easier to interpret quickly.
To change your view of the data, select Words in the Event Properties window. In the
Data Words view, the data section of the example reads as follows:

Output

() Bytes (.)
Words 0000: 00040000 00560002 00000000 80040032 0010: 00000000 00000000
00000000 00000000 0020: 00000000 00000000 80000011

In this case, the final status code is 0x80000011. This status code maps to
STATUS_DEVICE_BUSY and implies that the device is currently busy. This was the reason

that the write operation failed.

For more information about NT status codes, see Using NTSTATUS Values. The list of
codes is also available in the Windows Software Developers Kit (SDK), in the
NTSTATUS.H file.

The event category code

In the example, the event category code (the code that's associated with event ID 50) is
listed in the second line. This line starts with "0008:" and it includes the last 4 bytes of
the following line:

0008: 00 00 00 00 32 00 04 80

In this case, the error code is 0x80040032, which corresponds to IO_LOST_DELAYED_WRITE .

This information appears in the event description as "Lost Delayed-Write Data."

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You may have to wait for a long time to
populate the information on shared
folder sessions in Computer
Management console
Article • 12/26/2023

This article provides a solution to an issue where information on shared folder sessions
is populated slow in Computer Management console.

Applies to: Windows Server 2012 R2

Original KB number: 2454039

Symptoms
When trying to view the information about client sessions by clicking Shared Folders >
Sessions in the Computer Management console, it may take a long time to populate the
information, and the console may stop responding or appear to hang.

Cause
Computer Management will try to resolve the client IP address to user-friendly NetBIOS
name. In and IPv6 and IPv4 hybrid environment, and clients use NetBIOS to access share
folders, if the NetBIOS name cannot be resolved, it shows the IPv6 address immediately.
However, if clients are using ipv4 to access share folder, the failure of resolving to the
NetBIOS name causes the Computer Management console to hang.

Resolution
1. Disable NetBIOS over TCP/IP:
a. Run ncpa.cpl.
b. Right-click the NIC.
c. Select properties.
d. Click TCPIPV4.
e. Click advanced.
f. Click WINS.
g. Choose Disable Netbios over TCPIP.
 2. Configure reverse lookup zone in DNS server. It is useful to computers that are
added in domain.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure DFS to use fully
qualified domain names in referrals
Article • 12/26/2023

This article describes how to configure a DFSN server to operate in that environment.

Applies to: Windows Server 2012 R2

Original KB number: 244380

Summary
By default, a Microsoft Distributed File System Namespace (DFSN) root referral reply to a
DFS root referral query is in NetBIOS name format ( \\<Server>\<Share> ). It's necessary
in certain environments that rely on NetBIOS and makes it possible for clients that
support NetBIOS-only name resolution to locate and connect to targets in the DFS
namespace. By default, Windows clients work fine with it.

However, some clients don't use NetBIOS. Two examples are clients that aren't running
Windows and clients that operate in an environment without WINS or that use DNS
name suffixes. Those clients are incompatible with the default DFSN behavior.

In these cases, the client may be unable to resolve the server name that is returned from
the root referral query. However, this problem can be addressed easily, because DFSN
can be configured to operate in a DNS-only environment.

７ Note

For namespace servers that are hosting only stand-alone namespaces, some steps
that are described in this article are unnecessary. (Such namespace servers include
clustered namespaces.) By default, DFSN clients can access such stand-alone
namespaces through either \\< Server-NetBIOS>\\<Namespace> or \\<Server-
FQDN>\\<Namespace> namespace paths. However, namespace server configuration is

still required for stand-alone namespaces in order to provide correct referrals.

The steps that are described in this article apply to all DFS namespace servers,
regardless of whether such namespace servers also act as Active Directory domain
controllers.
Four stages
The overall approach consists of the following four stages:

1. Configure a DNS suffix for resolution of qualified names on the client.

2. Verify DNS records of file server targets, and create host records as required.
3. Configure the DFSN server to respond by using FQDN referrals for root targets.
4. If it's required, update the namespace metadata for each folder target so that the
folder referrals use appropriate FQDN names for folder targets.

Steps for stage 3: Configure the DFSN server to

respond by using FQDN referrals for root
targets

７ Note

Before you continue with the following steps for stage 3, we recommend that you
back up the namespace metadata to guard against unexpected failures or
accidents. The backup steps, together with the other restore steps if you ever need
them, are covered in steps A and C of the Steps for stage 4 section.

７ Note

The DFSN Windows PowerShell cmdlets that are mentioned in this section are
available only starting with Windows Server 2012 or Windows 8.

1. Obtain the list of domain-based namespaces that are hosted on the server. To do
it, use one of the following methods:

PowerShell

Get-DfsnRoot - ComputerName ServerName |Where type -NotMatch

"Standalone"

PowerShell

dfsutil.exe server ServerName and manually identify the domain-based

namespaces
 ７ Note

If there are no domain-based namespaces that are hosted on this namespace

server, you don't have to follow some steps in this article.

2. ７ Note

You can skip the following step for namespace servers that host only stand-
alone namespaces.

Generally, domain-based namespaces are hosted on multiple namespace servers.

So when you remove the namespace from one namespace server, as you do in this
step, namespace availability isn't affected. However, you should make sure that
there is in fact more than one namespace server that is hosting your namespace.
To do it, use one of the following methods:

PowerShell

(Get-DfsnRootTarget -Path Namespace).Count

PowerShell

dfsutil.exe root Namespace

For example, the placeholder <Namespace> could represent the following:

\\contoso.com\DomainNamespace If you confirm that there are multiple namespace

servers hosting your namespace, you can skip step C that follows.

3. ７ Note

You can skip the following step for namespace servers that host only stand-
alone namespaces. You can also skip this step if you confirm that there are
multiple namespace servers that are hosting your namespace.

If there's only one namespace server for your namespace, you should temporarily
add a new namespace server before you remove the existing server. (See Add
Namespace Servers to a Domain-based DFS Namespace or New-DfsnRootTarget
cmdlet.) Or, you must save the namespace metadata for a re-creation later. (To do
it, see steps A and C of the Steps for stage 4 section.) However, you should be
 aware that the second approach will cause a transient downtime for the
namespace.

4. ７ Note

You can skip the following step for namespace servers that host only stand-
alone namespaces.

Remove each hosted domain-based namespace from the server. To do it, use one
of the following methods:

PowerShell

Remove-DfsnRootTarget -TargetPath NamespaceRootTarget

PowerShell

dfsutil.exe target Remove NamespaceRootTarget

For example, the placeholder <NamespaceRootTarget> could represent the

following:
\\Contoso-FS.contoso.com\AccountingSoftware

5. Enable the DFSN FQDN root referral behavior. To do it, use one of the following
methods:

PowerShell

Set-DfsnServerConfiguration -ComputerName ServerName -UseFqdn $true

PowerShell

Dfsutil.exe server registry dfsdnsconfig set ServerName

6. Restart the DFSN service. To do it, use one of the following methods:

PowerShell

Stop-Service dfs; Start-Service dfs

PowerShell
 Net stop dfs; Net start dfs

7. ７ Note

You can skip the following step for namespace servers that are hosting only
stand-alone namespaces.

Restore each namespace that you previously removed from this namespace server.
To do this, use one of the following methods:

PowerShell

New-DfsnRootTarget - TargetPath RootTarget [-Path Namespace]

PowerShell

Dfsutil target add \\RootTarget

8. Depending on what you did in step B, follow these optional steps:

a. If you took a backup of your namespace metadata in step B, you can import the
metadata into the namespace that you just re-created. Before you import the
metadata, you can also make any necessary adjustments as part of the same
step. (See the Steps for stage 4 section.)
b. If you temporarily added a namespace server in step B, you may remove it now.

Steps for stage 4: Update the namespace

metadata for each folder target so that the
metadata uses appropriate FQDN names
Follow these steps for each namespace that is hosted on the namespace server:

1. Export the namespace metadata:

XML

dfsutil.exe root export \\contoso.com\DomainNamespace1 C:\dir1\a.txt

2. Make any necessary FQDN-related adjustments to folder targets. For each "Target"
XML element that is contained in a "Link" XML element, change its NetBIOS
 reference to its equivalent FQDN reference.

For example, before the update, the element is as follows:

XML

<Target State="ONLINE" >\\FileServer-NetBIOS\Share1</Target>

After the update, the element is as follows:

XML

<Target State="ONLINE" >\\FileServer-FQDN\Share1</Target>

3. Import the updated namespace metadata:

XML

dfsutil.exe root import set C:\dir1\a.txt

\\contoso.com\DomainNamespace1

References
For more information about related topics, see:

Overview of DFS Namespaces

Dfsutil Syntax

Feedback
Was this page helpful?  Yes  No

Provide product feedback

If you receive a "Delayed Write Failed"
error message, it states that your data
has been lost
Article • 12/26/2023

This article helps to fix the error message "Delayed Write Failed" which states that your
data has been lost.

Applies to: Windows Server 2012 R2

Original KB number: 2021074

Symptoms
When writing to a network share, a failure may cause the following event to be written
to the event log:

Event ID: 50 {Delayed Write Failed} Windows was unable to save all the data for the
file <file>. The data has been lost. This error may be caused by a failure of your
computer hardware or network connection. Please try to save this file elsewhere.

Cause
This error can occur if there are pending cached writes to a file located on a remote
network share and the connection to that file is unexpectedly terminated. The
connection to the file could have been terminated for various reasons, including
network communication failures and filter drivers on either the client or the server
canceling the write I/O. When this error occurs, the pending cached write I/O in memory
cannot be written to the target file on the remote network share. The delayed write fails
and the target file may now be corrupt.

More information
It is the responsibility of the application to handle this error. Some applications may try
to reconnect to the remote file and retry the write operation. Other applications may
ignore the error or fail altogether and leave the target file corrupted. Some applications
like Windows Explorer may report the error to the user if a file copy fails. In the scenario
of a failed file copy, the source file remains unchanged and copy operation can be
restarted, overwriting the corrupted targeted remote file.
For more information, see the following link:
https://support.microsoft.com/kb/816004

Feedback
Was this page helpful?  Yes  No

Provide product feedback

About the DFS Namespaces service and
its configuration data
Article • 12/26/2023

This article provides some information about the DFS Namespaces service and its
configuration data.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 977511

Summary
The Distributed File System (DFS) Namespaces service stores configuration data in
several locations. If some of this data is missing or inaccessible, you may experience
failures and be unable to create a namespace.

Introduction
This article discusses the following topics to help you create a namespace:

Storage locations for configuration data.

Examples of how data becomes inconsistent.
Methods that you can use to remove orphaned configuration data.
Symptoms and error messages that you may receive.

More information

DFS Namespaces configuration storage locations

The following locations store different configuration data for the Distributed File System
(DFS) Namespaces:

Active Directory Domain Services (AD DS) stores domain-based namespace

configuration data in one or more objects that contain namespace server names,
folder targets, and various other configuration data.

The namespace servers maintain shares for each namespace hosted.

 The registry keys on the domain-based namespace servers store namespace
memberships.

７ Note

On the stand-alone namespace servers, registry keys store all the namespace
configuration data.

If any subset of the configuration data is missing or invalid, you may be unable to
manage the namespace. Additionally, you may receive many different error messages
when you manage DFS Namespaces by using the DFS Namespaces Microsoft
Management Console (MMC) snap-in, the Dfsutil.exe tool, or the Dfscmd.exe tool or
when a client accesses the namespace. See the Symptoms and error messages section
for a list of possible error messages.

Examples of how DFS Namespaces configuration data

may become inconsistent
The dfsutil/clean command is performed on a domain-based namespace server.
This command removes the namespace registry data. The configuration data that
is stored in the AD DS remains and is enumerated by the DFS Namespaces MMC
snap-in.
An authoritative restoration of AD DS is performed to recover a DFS namespace
that was deleted by using a DFS management tool such as the DFS Namespaces
MMC snap-in or the Dfsutil.exe tool. Although the restoration of AD DS may be
successful, the namespace is not operational unless other DFS Namespaces
configuration data is also restored or recovered.
Restoration of the system state for a namespace server by using a backup that was
created before the server became a namespace server.
Active Directory replication failures prevent namespace servers from locating the
DFS Namespaces configuration data.
Incorrect modification or incorrect removal of the share for the namespace on a
namespace server.
Manual manipulation of the registry or of the AD DS namespace configuration
data.

DFS Namespaces configuration cleanup and removal

DFS Namespaces configuration data is managed and maintained by management tools
that use DFS APIs. The DFS APIs notify the Active Directory domain controllers and the
DFS Namespaces servers about configuration changes. This behavior prevents the
configuration data from becoming orphaned and guarantees consistency in the
configuration data. If the notification process is inhibited, or if the data is otherwise
deleted or lost, follow the cleanup steps that are listed here to remove the configuration
data. These changes are not recoverable unless you make a backup of the system state
for the domain controller or for the namespace server.

For more information about how to back up the system state of a server that is running
Windows Server 2003, visit the following Microsoft Web site:

https://technet.microsoft.com/library/cc759141.aspx
For more information about how to back up the system state of a server that is running
Windows Server 2008, visit the following Microsoft Web site:

https://technet.microsoft.com/library/cc770266.aspx

７ Note

The following steps should only be used if recovery of the configuration data is not
possible or is not desired.

For more information about the recovery process for a DFS namespace, click the
following article number to view the article in the Microsoft Knowledge Base:

969382 Recovery process of a DFS Namespace in Windows 2003 and 2008 Server

1. For a domain-based DFS namespace, verify the removal of the AD DS namespace

configuration data. Before the removal process, you must accurately identify the
object that is associated with the malfunctioning or inconsistent namespace. To
remove the AD DS namespace configuration data, follow these steps:

a. Open the Adsiedit.msc tool. This tool is included in Windows Server 2008 and
requires that the AD DS role or tools are installed. This tool is available in
Windows Server 2003 Support Tools.

For more information about the Adsiedit.msc tool, visit the following Microsoft
Web site:

https://technet.microsoft.com/library/cc773354(WS.10).aspx

b. Locate the domain partition of the domain hosting the domain-based

namespace. Move to the following location:
CN=Dfs-Configuration,CN=System,DC= <domain DN>
 ７ Note

The <domain DN> placeholder is the distinguished name of the domain.

DFS Namespaces store the configuration objects in this location. "Windows

2000 Server mode" namespaces have an "fTDfs" class object that is named
identically to the namespace. "Windows Server 2008 mode" namespaces have a
"msDFS-NamespaceAnchor" class object that is named identically to the
associated namespace and that may contain additional child objects for any
configured folders.

c. Select the appropriate object such as the "fTDfs" or "msDFS-NamespaceAnchor"

object, and then delete it together with any child objects.

７ Note

Active Directory replication latencies may delay this change operation from
propagating to the remote domain controllers.

2. On any namespace servers that are hosting the namespace, verify the removal of
the DFS namespace registry configuration data. If other functioning namespaces
are hosted on the server, make sure that the registry key of only the inconsistent
namespace is removed. To remove the DFS namespace registry configuration data,
follow these steps:

a. In Registry Editor, locate the configuration registry key of the namespace at the
appropriate path by using one of the following paths:

Domain-based DFSN in "Windows Server 2008 mode"

HKEY_LOCAL_MACHINE \Software\Microsoft\Dfs\Roots\domainV2
Stand-alone DFSN
HKEY_LOCAL_MACHINE \Software\Microsoft\Dfs\Roots\Standalone
Domain-based DFSN in "Windows 2000 Server mode"
HKEY_LOCAL_MACHINE\Software\Microsoft\Dfs\Roots\Domain

b. If a registry key that is named identically to the inconsistent namespace is

found, use the Dfsutil.exe tool to remove the registry key. For example, run the
following command:

Console
 dfsutil /clean /server:<servername> /share:<sharename> /verbose

７ Note

The servername placeholder is the name of the server hosting the

namespace and the sharename placeholder is the name of the root share.
Or, delete the key manually.

c. On the namespace server, restart the DFS service in Windows Server 2003 or the
DFS Namespaces service in Windows Server 2008 to register the change on the
service.

3. Remove the file share that was associated with the namespace from the
namespace servers. Failure to follow this step may cause the recreation of the
namespace to fail because DFS Namespaces may block the namespace creation.

Windows Server 2003

a. Open the Computer Management MMC snap-in. To do it, run the
Compmgmt.msc tool.
b. Expand System Tools, expand Shared Folders, and then click Shares.
c. Right-click the DFS namespace share, and then click Stop Sharing. If you receive
the following error message, you must restart the server and then try again to
remove the share by using Computer Management MMC snap-in:

"The system cannot stop sharing <\server\share> because the shared

folder is a Distributed File System (DFS) namespace root"

Windows Server 2008

a. Open the "Share and Storage Management" MMC snap-in. To do it, run the
StorageMgmt.msc tool.
b. Right-click the share of the namespace, and then click Stop Sharing. If you
receive the following error message, you must restart the server and then
remove the share by using Computer Management MMC snap-in:

The system cannot stop sharing <\server\share> because the shared folder
is a Distributed File System (DFS) namespace root

Changing the DFS namespace configuration data should only be considered after you
evaluate all other recovery options. We recommend that you regularly obtain backups of
the system state for the DFS namespace servers and for the domain controllers of
domain-based DFS namespaces. These backups may be used to restore the namespace
configuration to full operation without the risk of having inconsistent DFS namespace
configuration data.

Symptoms and error messages

DFS Management MMC (Dfsmgmt.msc)

In the Dfsmgmt.msc tool, you may receive the following error messages:

\\ domain.com \namespace: The Namespace cannot be queried. Element not

found.

The server you specified already hosts a namespace with this name. Please
select another namespace name or another server to host the namespace.

A shared folder name "namespace" already exists on the server

<servername>. If the existing shared folder is used, the security setting
specified within the Edit Settings dialog box will not apply. To have a shared
folder created with those settings, you must first remove the existing shared
folder.

The namespace is not unique in the domain in which the namespace server
was created. You must go back to choose a new namespace name, or change
the namespace type to stand-alone.

\\ domain.com \ namespace1 : The namespace server \ servername \

namespace1 cannot be added. Cannot create a file when that file already
exists.

\\ domain.com \namespace: The namespace cannot be queried. The system

cannot find the file specified.

\\ domain.com \namespace: The namespace cannot be queried. The device is not

ready for use.

An error occurred while trying to delete share <namespacefolder>. The share

must be removed from the Distributed File System before it can be deleted.
Distributed File System MMC (Dfsgui.msc)
In the Dfsgui.msc tool, you may receive the following error messages:

The specified DFS root does not exist.

The DFS root "namespace1" already exists. Please give a different name for the
new DFS root.

The following error occurred while creating DFS root on server servername:
Cannot create a file when that file already exists.

The specified DFS root does not exist.

The system cannot find the file specified.

Dfsutil.exe

In the Dfsutil.exe tool, you may receive the following error message:

System error 1168 has occurred. Element not found.

Dfscmd.exe

In the Dfscmd.exe tool, you may receive the following error messages:

System error 1168 has occurred. Element not found.

System error 80 has occurred. The file exists.

System error 2 has occurred. The system cannot find the file specified.

DFS clients

On a computer that is running the DFS client, you may receive the following error
messages:

Windows cannot find '\\ domain.com \namespace\folder'. Make sure you typed
the name correctly, and then try again.
 File not found.

Windows cannot access '\\ domain.com \namespace\folder'. Check the spelling

of the name. Otherwise, there might be a problem with your network.
Additional details:
Error code: 0x80070002 The system cannot find the file specified.

Windows cannot access \\ domain.com \namespace1. Error code 0x80070035

The network path was not found.

\\ domain.com \namespace\folder is not accessible. You might not have

permission to use this network resource. . The network path was not found.

Configuration information could not be read from the domain controller,

either because the machine is unavailable, or access has been denied.

Windows cannot access \\ domain.com \namespace. Check the spelling of the

name. Otherwise, there might be a problem with your network. Additional
details:
Error code: 0x80070035 The network path was not found.

The system cannot find the path specified.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SMB file server share access is
unsuccessful through DNS CNAME alias
Article • 12/26/2023

This article provides solutions for the issue that DNS CNAME alias can't access SMB file
servers.

Applies to: Windows 10 - all editions, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows 7 Service Pack 1
Original KB number: 3181029

Symptoms
Configuration

You're running an SMB file server, such as Windows Server. The server has files and
resources that are configured by using their NetBIOS name, the DNS fully qualified
domain name (FQDN), and their alias (CNAME).
You have a client that's running Windows 7, Windows Server 2008 R2, or a later
version of Windows.

Scenarios

When an application or user uses the actual storage name (the NetBIOS name or
the FQDN) for files or other resources on the server that's using SMB, access is
successful.

When an application or user uses the CNAME alias for files or other resources on
the server that's using SMB, and you try to connect to a share on the file server
with its DNS CNAME alias. For example, you try to connect to a share on the file
server by using its DNS CNAME alias:

Console

NET USE * \\CNAME\share_name

In this case, you experience the following behaviors:

Access from a Windows Server 2008 R2 or Windows 7 client is successful.

 Access from a Windows Server 2012 R2, Windows 8.1, or a later version of
Windows client is unsuccessful. In this case, you receive an error message that
resembles the following one:

Open Folder

\\uncpath is not accessible. You might not have permission to use this
network resource. Contact the administrator of this server to find out if you
have access permissions.

Logon Failure: The target account name is incorrect.

Cause
If you use Network Monitor, Wire Shark, or Microsoft Message Analyzer to
examine the network trace when the SMB Session Setup is successful, the session
goes to the TREE Connect.

However, if you examine the network trace when the SMB Session Setup is
unsuccessful, the session fails with a Kerberos KRB_AP_ERR_MODIFIED error. Here's
an example of an unsuccessful SMB Session Setup request in a network trace:

Output

MessageNumber DiagnosisTypes Timestamp Source Destination Module

Summary
112 None DateTime Client Server SMB2 Negotiate, Status: Success,
2780879Guid: {12f74af4-be82-11e5-b5c2-005056890096}, DialectRevision:
SMB 2.
112 None DateTime Client Server SMB2 NegotiateRequest, Dialects: [SMB
2.0.2, SMB 2.1], Capabilities: , 2780879Guid: {12f74af4-be82-11e5-b5c2-
115 None DateTime Server Client SMB2 NegotiateResponse, Status:
Success, DialectRevision: SMB 2.1, Capabilities:
SMB2GlobalCapDfs|SMB2GlobalC
116 None DateTime Client Server SMB2 SessionSetup, Status:
STATUS_MORE_PROCESSING_REQUIRED, Kerberos, Flags: 0
116 None DateTime Client Server SMB2 SessionSetupRequest, Kerberos,
Flags: Unknown(0), PreviousSessionId: 0x0000000000000000
122 None DateTime Server Client SMB2 SessionSetupResponse, Status:
STATUS_MORE_PROCESSING_REQUIRED, Kerberos, SessionId:
0x000004030800006D
135 None DateTime Client Server SMB2 SessionSetup, Status:
STATUS_MORE_PROCESSING_REQUIRED, Kerberos, Flags: 0
135 None DateTime Client Server SMB2 SessionSetupRequest, Kerberos,
Flags: Unknown(0), PreviousSessionId: 0x0000000000000000
143 None DateTime Server Client SMB2 SessionSetupResponse, Status:
 STATUS_MORE_PROCESSING_REQUIRED, Kerberos, SessionId:
0x000004030800006D

In an unsuccessful SMB Session Setup request, the client forwards an incorrect

CNAME SPN. The SPN may be incorrect because it's registered for an old server.
However in a successful SMB Session Setup request such as in the Windows Server
2008 R2 client case, the client forwards the SPN for the actual server name.

If the file server name was resolved through DNS, the SMB client appends the DNS
suffix to the user-supplied name. That is, the first component of the SPN will
always be the user supplied name as in the following example:

Console

CNAME.contoso.com\share_name

７ Note

This try would fail on older SMB implementations (Like AIX Samba 3.5.8), that
cannot be configured for Kerberos authentication and does not listen to SMB
direct host port 445, but only on NetBIOS port 139.

If the file server name was resolved through some other mechanism such as
NetBIOS
Link-Local Multicast Name Resolution (LLMNR)
Peer Name Resolution Protocol (PNRP) processes

the SMB client uses the user supplied name such as the following one:

Console

CNAME\share_name

Resolution
To resolve this issue on a file server that is running the SMB version 1 protocol, add the
DisableStrictNameChecking value to the registry:

Registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parame
ters
 DWORD name: DisableStrictNameChecking
DWORD value: 1

） Important

Do not use DNS CNAMEs in the future for file servers. If you want to still give
alternate names to servers, you can do so with the following command:
NETDOM COMPUTERNAME/ADD

This command automatically registers SPNs for the alternate names.

We don't recommend that you resolve this issue for a file server that isn't Windows-
based by typing the following commands in an elevated Command Prompt window on
a Windows-based computer. You would have to be logged on with Domain
Administrator credentials. Then press Enter at the command prompt to register the SPN
for the CNAME of the non-Windows-based File Server storage device:

Console

SETSPN -a host/alias_name targetserver

SETSPN -a host/alias_name.contoso.com targetserver

７ Note

If you use Windows 2012 Clustering, install the hotfix for down-level clients in
which Windows XP or Windows Server 2003 computers cannot connect: Can't
access a resource that is hosted on a Windows Server 2012-based failover
cluster .
If you create a CNAME for the clustered name the clients are connecting to,
you have to make sure that you set the properties on that Clustered name so
that it responds to the CNAMEs: How to configure an alias for a clustered
SMB share with Windows Server 2012 .

Network trace
To collect a network trace, follow these steps:

1. Open an elevated Command Prompt window, type the following command, and
then press Enter:
 Console

netsh trace start NetConnection capture=yes maxsize=100

filemode=circular overwrite=yes
traceFile=c:\%COMPUTERNAME%_Repro_trace.etl

2. Delete any existing File Server network connections by running the following
command:

Console

NET USE * /DELETE

3. Initialize all name caching by deleting the existing cache:

a. To delete the DNS cache, type the following command, and then press Enter:

Console

IPCONFIG /FLUSHDNS

b. To delete the NetBIOS cache, type the following command, and then press
Enter:

Console

NBTSTAT /RR

c. To delete the Kerberos cache, type the following command, and then press
Enter:

Console

KLIST /PURGE

d. To delete the ARP cache, type the following command, and then press Enter:

Console

ARP -d

4. Try to connect to the network share by typing the following command and then
pressing Enter:
 Console

NET USE * \\server_name\share_name

5. To stop the network trace in an unsuccessful scenario, type the following

command, and then press Enter:

Console

netsh trace stop

Collect registry settings

To collect registry settings on the file server, select Start, select Run, type the command
in the Open box, and then select OK. Repeat this step for the following commands:

Console

REG.EXE SAVE HKLM\SYSTEM C:\TEMP\%COMPUTERNAME%_SYSTEM.HIV

REG.EXE SAVE HKLM\SOFTWARE C:\TEMP\%COMPUTERNAME%_SOFTWARE.HIV
REG.EXE SAVE HKCU\Software C:\TEMP\%COMPUTERNAME%_HKCU.HIV

７ Note

The registry setting files (.HIV) are saved to the TEMP folder on the file server.

Check registry settings

Check the settings of the following registry values on the file server:

Console

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
\SmbServerNameHardeningLevel
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
\DisableStrictNameChecking

Apply hotfixes (server and client)

For Windows 7 and Windows Server 2008 R2, apply the following Windows 7 Enterprise
hotfix rollup:

An enterprise hotfix rollup is available for Windows 7 SP1 and Windows Server 2008 R2
SP1

Additionally, apply the following hotfixes:

"Delayed write failed" error message when .pst files are stored on a network file
server that is running Windows Server 2008 R2
You experience a long logon time when you try to log on to a Windows 7-based or
a Windows Server 2008 R2-based client computer that uses roaming profiles
OpsMgr 2012 or OpsMgr 2007 R2 generates a "Heartbeat Failure" message and
then goes into a greyed out state in Windows Server 2008 R2 SP1

References
Error message when you try to access a server locally by using its FQDN or its
CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied"
or "No network provider accepted the given network path"
MS08-068: Vulnerability in SMB could allow remote code execution
Can't access a resource that is hosted on a Windows Server 2012-based failover
cluster
List of currently available hotfixes for the File Services technologies in Windows
Server 2008 and in Windows Server 2008 R2
List of currently available hotfixes for the File Services technologies in Windows
Server 2012 and in Windows Server 2012 R2
Add DisableStrictNameChecking registry key
DisableStrictNameChecking; server alias doesn't work from the actual server
Why do we need SPN for File Server (NAS / RAS / File Share System) DNS Alias
(Cname)

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error (Target account name is incorrect)
when a domain user accesses a share on
a file server that is running Windows
Server 2012 R2
Article • 12/26/2023

This article provides a solution to an issue where users fail to access a share on a file
server that is running Windows Server 2012 R2.

Applies to: Windows Server 2012 R2

Original KB number: 3040803

Symptoms
When domain users try to access a share on a file server that is running Windows Server
2012 R2, they cannot access the share, and they receive the following error message:

Logon failure: Target account name is incorrect.

Additionally when this problem occurs, Event ID 4 and Event ID 1097 are logged in the
Server log. This problem may occur for several hours or up to a day. Then, the user loses
access to the share on the server.

Event ID 4

Output

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the

server server_name$. The target name used was server_name$. This
indicates that the target server failed to decrypt the ticket provided
by the client. This can occur when the target server principal name
(SPN) is registered on an account other than the account the target
service is using. Please ensure that the target SPN is registered on,
and only registered on, the account used by the server. This error can
also happen when the target service is using a different password for
the target service account than what the Kerberos Key Distribution
Center (KDC) has for the target service account. Please ensure that the
service on the server and the KDC are both updated to use the current
password. If the server name is not fully qualified, and the target
domain (DNS_prefix.dns_suffix) is different from the client domain
(DNS_prefix.dns_suffix), check if there are identically named server
 accounts in these two domains, or use the fully-qualified name to
identify the server.

Event ID 1097

Output

The processing of Group Policy failed. Windows could not determine the
computer account to enforce Group Policy settings. This may be
transient. Group Policy settings, including computer configuration,
will not be enforced for this computer.

Cause
This problem occurs because the file server cannot decrypt the ticket that was encrypted
in AES256.

Resolution
To resolve this problem, set the value of the SupportedEncryptionTypes attribute to
0x7fffffff. To do this, follow these steps:

1. In the Group Policy Management Console (GPMC), expand Computer

Configuration, expand Windows Settings, expand Security Settings, expand Local
Policies, and then select Security Options.
2. Click to select the Network security: Configure encryption types allowed for
Kerberos option.
3. Click to select the Define these policy settings check box and all six check boxes
for the encryption types.
4. Click OK, and then close the GPMC.

７ Note

This policy sets the SupportedEncryptionTypes registry entry to a value of

0x7FFFFFFF. The SupportedEncryptionTypes registry entry is at the location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\K

erberos\parameters .

Status
Microsoft has confirmed that this is a problem in Windows Server 2012 R2.

References
Kerberos

Changes in Kerberos Authentication

Interpreting the SupportedEncryptionTypes Registry Key

Kerberos Enhancements

You cannot log on to a Windows 7-based or Windows Server 2008 R2-based client
computer after you disable AES encryption for Kerberos authentication

Feedback
Was this page helpful?  Yes  No

Provide product feedback

System error 2148073478, extended
error, or Invalid Signature error message
on SMB connections in Windows Server
2012 or Windows 8
Article • 12/26/2023

This article provides a solution to error messages that occur on Server Message Block
(SMB) connections.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2686098

Symptoms
After a Windows Server 2012-based or Windows 8-based computer fails to connect to a
third-party file server that supports the SMBv2 file protocol, you receive one of the
following error messages or a similar error message, depending on how you access the
third-party file server:

When you use a DIR command that has a UNC path:

Invalid Signature

When you run a NET USE command:

System error 2148073478 has occurred

When you try to browse to the UNC path:

An extended error has occurred

You may experience these errors in the following common scenarios:

A live migration of Hyper-V servers (running either Hyper-V Server 2012 or

Windows Server 2012 and Window 8) fails. This occurs because the storage is
required to be hosted on an SMB share.
You can't map network drives to a SAN in a Window 8-Windows Server 2012
environment.
Cause
This problem is caused by the Secure Negotiate feature that was added to SMB 3.0 for
Windows Server 2012 and Windows 8. This feature depends upon the correct signing of
error responses by all SMBv2 servers, including servers that support only protocol
versions 2.0 and 2.1. Some third-party file servers don't return a signed error response.
So the connection fails.

Resolution
To resolve this problem, contact the third-party file server vendor to request an update
that enables the file server to support Windows Server 2012 and Windows 8 clients.

Workaround

２ Warning

We don't recommend that you disable the requirement for secure negotiate, as this
reduces computer security. Disable secure negotiate only as a temporary
troubleshooting measure. Don't leave secure negotiate disabled; instead, contact
the third-party file server vendor and request an update that allows their file server
to support Windows Server 2012 and Windows 8 clients correctly.

The ability to disable secure negotiate functionality may be removed in future operating
systems.

To work around this problem, use either of the following methods:

Require signing on the third-party file server

To require signing on the SMB client or the SMB server, turn on the
RequireSecuritySignature setting. See your vendor's documentation for

instructions to set the signing setting to required on the vendor's SMB server.

You can enable signing by using PowerShell on a Windows Server 2012 or

Windows 8 client. To do it, run the following command:

PowerShell

Set-SmbClientConfiguration -RequireSecuritySignature $true

 Disable Secure Negotiate on the client

You can disable the Secure Negotiate option by using PowerShell on a Windows
Server 2012 or Windows 8 client. To do it, run the following command:

PowerShell

Set-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters"
RequireSecureNegotiate -Value 0 -Force

７ Note

This command may wrap to multiple lines in your web browser.

References
For more information, see New SMB 3.0 features in the Windows Server 2012 file server

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You cannot open file shares or Group
Policy snap-ins on a domain controller
Article • 12/26/2023

This article describes how to resolve a problem that occurs when SMB signing is
disabled for the Workstation or Server service on a domain controller.

Applies to: Windows Server 2003

Original KB number: 839499

Summary
You cannot open file shares or the Group Policy snap-ins on a Windows Server 2003
domain controller or on a Windows 2000 Server domain controller. When you log on to
the domain controller locally and then try to open shares on the domain controller, you
receive repeated password prompts, and you cannot open the shares. You can resolve
this problem by changing the registry.

２ Warning

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require that you
reinstall the operating system. Microsoft cannot guarantee that these problems can
be solved. Modify the registry at your own risk.

Symptoms

Scenario 1 - Server Message Block (SMB) signing is

disabled for the Workstation service on a domain
controller, but SMB signing is required for the Server
service on the same domain controller
Windows Server 2003

When you try to open Group Policy snap-ins on the domain controller, you receive an
error message that resembles the following:
 You do not have permission to perform this operation. Access is denied.

The domain controller logs the following events in the application event log every five
minutes:

Windows 2000 Server

When you try to open Group Policy snap-ins on the domain controller, you receive an
error message that resembles the following:

You do not have permission to perform this operation.

Access is denied. The domain controller logs the following event in the application
event log:

When you log on to the domain controller locally and then try to open shares on the
domain controller, you receive repeated password prompts, and you cannot open the
shares.

Scenario 2 - SMB signing is disabled for the Server

service on a domain controller, but SMB signing is
required for the Workstation service on the same domain
controller
Windows Server 2003

Failed to open the Group Policy Object. You may not have the appropriate rights.

The account is not authorized to log in from this station.

In a network trace, if SMB signing is enabled and required at the client and is disabled at
the server, the connection to the TCP session is gracefully closed after the Dialect
Negotiation, and the client receives the following error:

1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

The domain controller logs the following events in the application event log every five
minutes: When you log on to the domain controller locally and then try to open file
shares on the domain controller, you receive an error message that resembles the
following:
 \\Server_Name\Share_Name is not accessible. You might not have permission to use
this network resource. Contact the administrator of this server to find out if you
have access permissions.

The account is not authorized to log in from this station.

７ Note

In a network trace, if SMB signing is enabled, and if SMB signing is required at the
client and is disabled at the server, the connection to the TCP session is gracefully
closed after the dialect negotiation. Also, the client receives the following error
message: 1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

Windows 2000 Server

When you try to open Group Policy snap-ins on the domain controller, you receive an
error message that is similar to the following:

Failed to open the Group Policy Object. You may not have the appropriate rights.

The account is not authorized to log in from this station.

The domain controller logs the following event in the application event log: When you
log on to the domain controller locally and then try to open file shares on the domain
controller, you receive an error message that is similar to the following:

\\Server_Name\Share_Name is not accessible.

The account is not authorized to log in from this station.

７ Note

In a network trace, if SMB signing is enabled, and if SMB signing is required at the
client and is disabled at the server, the connection to the TCP session is gracefully
closed after the dialect negotiation. Also, the client receives the following error
message: 1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

Resolution
To resolve this behavior, follow these steps:
 ） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows XP .

Step 1 - Change the registry

Change the value of the enablesecuritysignature registry entry. To do this, follow these
steps:

1. On the domain controller, click Start, and then click Run.

2. Copy and then paste (or type) the regedit command in the Open box, and then
press Enter.

3. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

4. In the right pane, double-click enablesecuritysignature, type 1 in the Value data

box, and then click OK.

5. Double-click requiresecuritysignature, type 1 in the Value data box, and then click
OK.

6. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\paramet

ers

7. In the right pane, double-click enablesecuritysignature, type 1 in the Value data

box, and then click OK.
 8. Double-click requiresecuritysignature, type 0 in the Value data box, and then click
OK.

Step 2 - Restart the Server service and the Workstation service After you change the
registry values, restart the Server service and the Workstation service.

） Important

Do not restart the domain controller, because this action may cause Group Policy to
change the registry values back to the earlier values.

To restart the Server service and the Workstation service, follow these steps:

1. Click Start, point to Administrative Tools, and then click Services.

2. Right-click Server, and then click Restart.

3. Right-click Workstation, and then click Restart.

７ Note

If you are prompted to restart other services, click Yes.

Step 3 - Update the Sysvol share

Update the domain controller's Sysvol share. To do this, follow these steps:

1. Open the domain controller's Sysvol share. To do this, click Start, click Run, type
\\Server_Name\Sysvol in the Open box, and then press Enter.
2. If the Sysvol share does not open, repeat Step 1 - Change the registry and Step 2 -
Restart the Server and Workstation services .
3. Repeat Step 1 - Change the registry and Step 2 - Restart the Server and
Workstation services on each affected domain controller to make sure that each
domain controller can access its own Sysvol share.

Step 4 - Set up the SMB policy settings

After you connect to the Sysvol share on each domain controller, open the Domain
Controller Security Policy snap-in, and then set up the SMB signing policy settings. To do
this, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click
Domain Controller Security Policy.

2. In the left pane, expand Local Policies, and then click Security Options.

3. In the right pane, double-click Microsoft network server: Digitally sign

communications (always).

７ Note

In Windows 2000 Server, the equivalent policy setting is Digitally sign server
communication (always).

） Important

If you have client computers on the network that do not support SMB signing,
you must not enable the Microsoft network server: Digitally sign
communications (always) policy setting. If you enable this setting, you must
have SMB signing for all client communication, and client computers that do
not support SMB signing will not be able to connect to other computers. For
example, clients that are running Apple Macintosh OS X or Microsoft
Windows 95 do not support SMB signing. If your network includes clients that
do not support SMB signing, set this policy to disabled.
4. Click to select the Define this policy setting check box, click Enabled, and then
click OK.
 5. Double-click Microsoft network server: Digitally sign communications (if client
agrees).

７ Note

For Windows 2000 Server, the equivalent policy setting is Digitally sign server
communication (when possible).

6. Click to select the Define this policy setting check box, and then click Enabled.

7. Click OK.

8. Double-click Microsoft network client: Digitally sign communications (always).

9. Click to clear the Define this policy setting check box, and then click OK.

10. Double-click Microsoft network client: Digitally sign communications (if server
agrees).

11. Click to clear the Define this policy setting check box, and then click OK.

Step 5 - Run the Group Policy Update utility

Run the Group Policy Update utility (Gpupdate.exe) with the force switch. To do this,
follow these steps:

1. Click Start, and then click Run.

2. Copy and paste (or type) the cmd command in the Open box, and then press
Enter.

3. At the command prompt, type gpupdate /force , and then press Enter.

７ Note

The Group Policy Update utility does not exist in Windows 2000 Server. In
Windows 2000 Server, the equivalent command is secedit /refreshpolicy
machine_policy /enforce .

Step 6 - Check the application event log

After you run the Group Policy Update utility, check the application event log to make
sure that the Group Policy settings were updated successfully. After a successful Group
Policy update, the domain controller logs Event ID 1704. To open the Application log in
Event Viewer, follow these steps:

1. Click Start, point to Administrative Tools, and then click Event Viewer.

2. In the left pane, click Application.

3. Double-click event ID 1704 and confirm that the Group Policy setting was applied
successfully.

７ Note

The source of the event is SceCli.

Step 7 - Check the registry values

Check the registry values that you changed in Step 1 - Change the registry to make sure
that the registry values have not changed.

７ Note

This step makes sure that a conflicting policy setting is not applied at another
group or organizational unit (OU) level. For example, if the Microsoft network client:
Digitally sign communications (if server agrees) policy is configured as "Not
Defined" in Domain Controller Security Policy, but this same policy is configured as
disabled in Domain Security Policy, SMB signing will be disabled for the
Workstation service.

Step 8 - Check the SMB signing policy settings by using the Resultant Set of Policy
(RSoP) snap-in

If the registry values have changed after you run the Group Policy Update utility, check
the SMB signing policy settings by using the RSoP snap-in in Windows Server 2003. To
do this, follow these steps:

1. Click Start, click Run, type rsop.msc in the Open box, and then click OK.
 2. In the RSoP snap-in, the SMB signing settings are located in the following path:
Computer Configuration/Windows Settings/Security Settings/Local
Policies/Security Options

７ Note

If you are running Windows 2000 Server, install the Group Policy Update
utility from the Windows 2000 Server Resource Kit, and then type the
following at the command prompt: gpresult /scope computer /v

3. After you run this command, the Applied Group Policy Objects list appears. This
list shows all Group Policy Objects that are applied to the computer account. Check
the SMB signing policy settings for all these Group Policy Objects.

Additional resources
This behavior occurs if the SMB signing settings for the Workstation service and for the
Server service contradict each other. When you configure the domain controller in this
way, the Workstation service on the domain controller cannot connect to the domain
controller's Sysvol share. Therefore, you cannot start Group Policy snap-ins. Also, if SMB
signing policies are set by the default domain controller security policy, the problem
affects all the domain controllers on the network. Therefore, Group Policy replication in
the Active Directory directory service will fail, and you will not be able to edit Group
Policy to undo these settings.

Scenario 1 - If you run the domain controller diagnostic

tool (DcDiag.exe), you receive errors that are similar to
the following for Windows 2000 Server and for Windows
Server 2003
 Starting test: MachineAccount
Could not open pipe with [SERVERNAME]:failed with 5: Access is denied.
Could not get NetBIOSDomainName
Failed cannot test for HOST SPN
Failed cannot test for HOST SPN
* Missing SPN :(null)
* Missing SPN :(null)
......................... SERVERNAME failed test MachineAccount
Starting test: Services
Could not open Remote ipc to [SERVERNAME]:failed with 5: Access is denied.
......................... SERVERNAME failed test Services
Starting test: ObjectsReplicated
......................... SERVERNAME passed test ObjectsReplicated
Starting test: frssysvol
[SERVERNAME] An net use or LsaPolicy operation failed with error 5, Access is
denied..
......................... SERVERNAME failed test frssysvol
Starting test: frsevent
......................... SERVERNAME failed test frsevent
Starting test: kccevent
Failed to enumerate event log records, error Access is denied.
......................... SERVERNAME failed test kccevent
Starting test: systemlog
Failed to enumerate event log records, error Access is denied.
......................... SERVERNAME failed test systemlog

Scenario 2 - If you run the domain controller diagnostic

tool, you receive errors that are similar to the following
for Windows 2000 Server and for Windows Server 2003
Testing server: Default-First-Site-Name\SERVERNAME
Starting test: Replications
......................... SERVERNAME passed test Replications
Starting test: NCSecDesc
......................... SERVERNAME passed test NCSecDesc
Starting test: NetLogons
[SERVERNAME] An net use or LsaPolicy operation failed with error 1240, The
account is not authorized to log in from this station..
......................... SERVERNAME failed test NetLogons
Starting test: Advertising
 ......................... SERVERNAME passed test Advertising
Starting test: KnowsOfRoleHolders
......................... SERVERNAME passed test KnowsOfRoleHolders
Starting test: RidManager
......................... SERVERNAME passed test RidManager
Starting test: MachineAccount
Could not open pipe with [SERVERNAME]:failed with 1240: The account is not
authorized to log in from this station.
Could not get NetBIOSDomainName
Failed cannot test for HOST SPN
Failed cannot test for HOST SPN
* Missing SPN :(null)
* Missing SPN :(null)
......................... SERVERNAME failed test MachineAccount
Starting test: Services
Could not open Remote ipc to [SERVERNAME]:failed with 1240: The account is not
authorized to log in from this station.
......................... SERVERNAME failed test Services
Starting test: ObjectsReplicated
......................... SERVERNAME passed test ObjectsReplicated
Starting test: frssysvol
[SERVERNAME] An net use or LsaPolicy operation failed with error 1240, The
account is not authorized to log in from this station..
......................... SERVERNAME failed test frssysvol
Starting test: frsevent
......................... SERVERNAME failed test frsevent
Starting test: kccevent
Failed to enumerate event log records, error The account is not authorized to log in
from this station. ......................... SERVERNAME failed test kccevent
Starting test: systemlog
Failed to enumerate event log records, error The account is not authorized to log in
from this station. ......................... SERVERNAME failed test systemlog

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Guest access in SMB2 and SMB3
disabled by default in Windows
Article • 12/26/2023

This article describes information about Windows disabling guest access in SMB2 and
SMB3 by default, and provides settings to enable insecure guest logons in Group Policy.
However, this is generally not recommended.

Original KB number: 4046019

Symptoms
Starting from Windows 10, version 1709 and Windows Server 2019, SMB2 and SMB3
clients no longer allow the following actions by default:

Guest account access to a remote server.

Fall back to the Guest account after invalid credentials are provided.

SMB2 and SMB3 have the following behavior in these versions of Windows:

Windows 10 Enterprise and Windows 10 Education no longer allow a user to

connect to a remote share by using guest credentials by default, even if the remote
server requests guest credentials.
Windows Server 2019 Datacenter and Standard editions no longer allow a user to
connect to a remote share by using guest credentials by default, even if the remote
server requests guest credentials.
Windows 10 Home and Pro are unchanged from their previous default behavior;
they allow guest authentication by default.
Windows 11 Insider Preview Build 25267 Pro editions no longer allow a user to
connect to a remote share by using guest credentials by default, even if the remote
server requests guest credentials. All subsequent Windows 11 Insider Preview
builds no longer allow a user to connect to a remote share by using guest
credentials by default.

７ Note

This Windows 10 behavior occurs in Windows 10 1709, Windows 10 1803, Windows

10 1903, Windows 10 1909 as well as Windows 10 2004, Windows 10 20H2, and
Windows 10 21H1 as long as KB5003173 is installed. This default behavior was
previously implemented in Windows 10 1709 but later regressed in Windows 10
 2004, Windows 10 20H2, and Windows 10 21H1 where guest auth wasn't disabled
by default but could still be disabled by an administrator. See below for details on
ensuring that guest authentication is disabled.

If you try to connect to devices that request credentials of a guest instead of

appropriate authenticated principals, you may receive one of the following error
messages:

You can't access this shared folder because your organization's security
policies block unauthenticated guest access. These policies help protect your
PC from unsafe or malicious devices on the network.

Error code: 0x80070035

The network path was not found.

Also, if a remote server tries to force you to use guest access, or if an administrator
enables guest access, the following entries are logged in the SMB Client event log:

Log entry 1
Output

Log Name: Microsoft-Windows-SmbClient/Security

Source: Microsoft-Windows-SMBClient
Date: Date/Time
Event ID: 31017
Task Category: None
Level: Error
Keywords: (128)
User: NETWORK SERVICE
Computer: ServerName.contoso.com
Description: Rejected an insecure guest logon.
User name: Ned
Server name: ServerName

Guidance
This event indicates that the server tried to log on the user as an unauthenticated guest
but was denied by the client. Guest logons don't support standard security features such
as signing and encryption. So, guest logons are vulnerable to man-in-the-middle attacks
that can expose sensitive data on the network. Windows disables insecure (nonsecure)
guest logons by default. We recommend that you don't enable insecure guest logons.
Log entry 2
Output

Log Name: Microsoft-Windows-SmbClient/Security

Source: Microsoft-Windows-SMBClient
Date: Date/Time
Event ID: 31018
Task Category: None
Level: Warning
Keywords: (128)
User: NETWORK SERVICE
Computer: ServerName.contoso.com
Description: The AllowInsecureGuestAuth registry value is not configured
with default settings.
Default registry value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Para
meters] "AllowInsecureGuestAuth"=dword:0
Configured registry value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Para
meters] "AllowInsecureGuestAuth"=dword:1

Guidance
This event indicates that an administrator has enabled insecure guest logons. An
insecure guest logon occurs when a server logs on the user as an unauthenticated
guest. It typically occurs in response to an authentication failure. Guest logons don't
support standard security features, such as signing and encryption. So, allowing guest
logons makes the client vulnerable to man-in-the-middle attacks that can expose
sensitive data on the network. Windows disables insecure guest logons by default. We
recommend that you don't enable insecure guest logons.

Cause
This change in default behavior is by design and is recommended by Microsoft for
security.

A malicious computer that impersonates a legitimate file server could allow users to
connect as guests without their knowledge. We recommend that you don't change this
default setting. If a remote device is configured to use guest credentials, an
administrator should disable guest access to that remote device and configure correct
authentication and authorization.

Windows client and Windows Server haven't enabled guest access or allowed remote
users to connect as guest or anonymous users since Windows 2000. Only third-party
remote devices might require guest access by default. Microsoft-provided operating
systems don't.

Resolution
Configure your third-party SMB server device to require a username and password for
SMB connections. If your device allows guest access, any device or person on your
network can read or copy all of your shared data without any audit trail or credentials.

If you can't configure your third-party device to be secure, you can enable insecure
guest access with the following Group Policy settings:

1. Open the Local Group Policy Editor (gpedit.msc) on your Windows device.
2. In the console tree, select Computer Configuration > Administrative Templates >
Network > Lanman Workstation.
3. For the setting, right-click Enable insecure guest logons and select Edit.
4. Select Enabled > OK.

７ Note

If you need to modify the Active Directory domain-based group policy, use Group
Policy Management (gpmc.msc).

For monitoring and inventory purposes, this group policy sets the following DWORD
registry value to 1 (insecure guest auth enabled) or 0 (insecure guest auth disabled):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\LanmanWorkstation\

AllowInsecureGuestAuth

To set the value without using Group Policy, set the following DWORD registry value to 1
(insecure guest auth enabled) or 0 (insecure guest auth disabled):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
AllowInsecureGuestAuth

７ Note

As usual, the value setting in Group Policy will override the value setting in the non-
Group Policy registry value.
Starting from Windows 11 Insider Preview Build 25267, Pro editions disable insecure
guest authentication by default like Enterprise and Education editions.

On Windows 10 1709, Windows 10 1803, Windows 10 1903, Windows 10 1909, and

Windows Server 2019, guest authentication is disabled if AllowInsecureGuestAuth exists
with a value of 0 in
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
AllowInsecureGuestAuth .

On Windows 10 2004, Windows 10 20H2, and Windows 10 21H1 Enterprise and

Education editions with KB5003173 installed, guest authentication is disabled if
AllowInsecureGuestAuth doesn't exist or if it exists with a value of 0 in

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
AllowInsecureGuestAuth . Home and Pro editions allow guest authentication by default

unless you disable it using a group policy or registry setting.

７ Note

By enabling insecure guest logons, this setting reduces the security of Windows
clients.

More information
This setting has no effect on SMB1 behavior. SMB1 continues to use guest access and
guest fallback.

７ Note

SMB1 is uninstalled by default in the latest Windows client and Windows Server
configurations. For more information, see SMBv1 is not installed by default in
Windows 10 version 1709, Windows Server version 1709 and later versions.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

High CPU usage issue on the SMB
server
Article • 12/26/2023

This article discusses how to troubleshoot the high CPU usage issue on the SMB server.

High CPU usage because of storage

performance issues
Storage performance issues can cause high CPU usage on SMB servers. Before you
troubleshoot, make sure that the latest update rollup is installed on the SMB server to
eliminate any known issues in srv2.sys.

In most cases, you'll notice the issue of high CPU usage in the system process. Before
you proceed, use Process Explorer to make sure that srv2.sys, or ntfs.sys is consuming
excessive CPU resources.

Storage area network (SAN) scenario

In aggregate levels, the overall SAN performance may appear to be fine. However, when
you work with SMB issues, the individual request response time is what matters the
most.

Generally, this issue can be caused by some form of command queuing in the SAN. You
can use Perfmon to capture a Microsoft-Windows-StorPort tracing, and analyze it to
accurately determine storage responsiveness.

Disk IO latency
Disk IO latency is a measure of the delay between the time that a disk IO request is
created and completed.

The IO latency that is measured in Perfmon includes all the time that is spent in the
hardware layers plus the time that is spent in the Microsoft Port Driver queue
(Storport.sys for SCSI). If the running processes generate a large StorPort queue, the
measured latency increases. This is because IO must wait before it's dispatched to the
hardware layers.

In Perfmon, the following counters show physical disk latency:

 "Physical disk performance object" -> "Avg. Disk sec/Read counter" - This shows
the average read latency.
"Physical disk performance object" -> "Avg. Disk sec/Write counter" - This shows
the average write latency.
"Physical disk performance object" -> "Avg. Disk sec/Transfer counter" - This shows
the combined averages for both reads and writes.

The "_Total" instance is an average of the latencies for all physical disks in the computer.
Each of other instances represents an individual physical disk.

７ Note

Do not confuse these counters with Avg. Disk Transfers/sec. These are completely
different counters.

Windows Storage Stack

This section gives a brief explanation on the Windows Storage Stack.

When an application creates an IO request, it sends the request to the Windows IO

subsystem at the top of the stack. The IO then travels all the way down the stack to the
hardware "Disk" subsystem. Then, the response travels all the way back up. During this
process, each layer performs its function and then hands the IO to the next layer.
Perfmon doesn't create any performance data per second. Instead, it consumes data
that is provided by other subsystems within Windows.

For the "physical disk performance object," the data is captured at the "Partition
manager" level in the storage stack.

When we measure the counters that are mentioned in the previous section, we're
measuring all the time that is spent by the request below the "Partition manager" level.
When the IO request is sent by the partition manager down the stack, we time stamp it.
When it returns, we time stamp it again and calculate the time difference. The time
difference is the latency.

By doing this, we're accounting for the time that is spent in the following components:

Class Driver - This manages the device type, such as disks, tapes, and so on.
Port Driver - This manages the transport protocol, such as SCSI, FC, SATA, and so
on.
Device Miniport Driver - This is the device driver for the Storage Adapter. It's
supplied by the manufacturer of the devices, such as Raid Controller, and FC HBA.
Disk Subsystem - This includes everything that is below the Device Miniport Driver.
This could be as simple as a cable that is connected to a single physical hard disk,
or as complex as a Storage Area Network. If the issue is determined to be caused
 by this component, you can contact the hardware vendor for more information
about troubleshooting.

Disk queuing
There's a limited amount of IO that a disk subsystem can accept at a given time. The
excess IO gets queued until the disk can accept IO again. The time that IO spends in the
queues below the "Partition manager" level is accounted for in the Perfmon physical disk
latency measurements. As queues grow larger and IO must wait longer, the measured
latency also grows.

There are multiple queues below the "Partition manager" level, as follows:

Microsoft Port Driver Queue - SCSIport or Storport queue

Manufacturer Supplied Device Driver Queue - OEM Device driver
Hardware Queues - such as disk controller queue, SAN switches queue, array
controller queue, and hard disk queue

We also account for the time that the hard disk spends actively servicing the IO and the
travel time that is taken for the request to return to the "Partition manager" level to be
marked as completed.

Finally, we have to pay special attention to the Port Driver Queue (for SCSI Storport.sys).
The Port Driver is the last Microsoft component to touch an IO before we hand it off to
the manufacturer-supplied Device Miniport Driver.

If the Device Miniport Driver can't accept any more IO because its queue or the
hardware queues below it are saturated, we'll start accumulating IO on the Port Driver
Queue. The size of the Microsoft Port Driver queue is limited only by the available
system memory (RAM), and it can grow very large. This causes large measured latency.

High CPU caused by enumerating folders

To troubleshoot this issue, disable the Access Based Enumeration (ABE) feature.

To determine which SMB shares have ABE enabled, run the following PowerShell cmdlet:

PowerShell

Get-SmbShare | Select Name, FolderEnumerationMode

Unrestricted = ABE disabled.

AccessBase = ABE enabled.

You can enable ABE in Server Manager. Navigate to File and Storage Services > Shares,
right-click the share, select Properties, go to Settings and then select Enable access-
based enumeration.

Also, you can reduce ABELevel to a lower level (1 or 2) to improve performance.

You can check disk performance when enumeration is slow by opening the folder locally
through a console or an RDP session.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

%HOMEPATH%, %HOMESHARE%, and
%HOMEDRIVE% variables are resolved
incorrectly
Article • 12/26/2023

This article provides a solution to an issue where the %HOMEPATH% , %HOMESHARE% , and
%HOMEDRIVE% variables are resolved incorrectly.

Applies to: Windows Server 2012 R2

Original KB number: 237566

Symptoms
One of the features of the Microsoft Distributed File System (DfS) is to allow users to
map drives directly to folders and subfolders under a DfS share. If a user's home folder
is on a DfS share, the %HOMEDRIVE% variable is mapped only to the DfS root, and not to
the complete path. This behavior is evident when it's viewed from Windows NT Explorer.
In addition, the %HOMEPATH% and %HOMESHARE% variables are not resolved correctly.

For example, if "Dfs_root" is the DFS root on \\Pkdfs and the user's home folder is
\\Pkdfs\Dfs_root\Home\User1 :

%HOMEDRIVE% (for example, drive Z) is mapped to \\Pkdfs\Dfs_root

%HOMESHARE% resolves to \\Pkdfs\Dfs_root

%HOMEPATH% resolves to \Home\User1 .

Instead, %HOMEDRIVE%%HOMESHARE% should resolve to \\Pkdfs\Dfs_root\Home\User1 ,

%HOMEPATH% should resolve to \, and %HOMEDRIVE% (Z:) should map to

\\Pkdfs\Dfs_root\Home\User1 .

Resolution
To resolve this problem, obtain the latest service pack for Windows NT Server 4.0,
Terminal Server Edition.

Status
Microsoft has confirmed that it's a problem in the Microsoft products that are listed at
the beginning of this article. This problem was first corrected in Windows NT 4.0 Server,
Terminal Server Edition, Service Pack 5.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

List of currently available hotfixes for the
File Services technologies
Article • 12/26/2023

This article lists the hotfixes that are currently available for users who have installed the File
Services technologies on a Windows Server 2012-based computer or a Windows Server 2012 R2-
based computer.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 2899011

Summary
File Services provides technologies that help you manage storage, enable file replication, manage
shared folders, provide fast file searching, and enable access for UNIX client computers. This
article also lists the hotfixes that are currently available for users who use File Services on
Windows 8-based computers or Windows 8.1-based computers.

This article contains lists of Microsoft Knowledge Base articles that describe the currently
available fixes. The article is divided into two sections. The first section applies to Windows Server
2012 and to Windows 8, and the second section applies to Windows Server 2012 R2 and to
Windows 8.1. Each section is divided into subsections for different component drivers: SRV,
MRXSMB, and RDBSS. In general, the SRV drivers should be updated on the server or client
computer that is hosting the data. The MRXSMB and RDBSS drivers should be updated on the
server or client computer that is initiating access to the data. If you are unsure about which
component should be updated on which computer, you can update all three component drivers
on both the computer that is hosting the data and the computer that is accessing the data.

A servicing approach of installing the monthly rollups provides customers with a consistent
model for staying current and secure. You may substitute a more recent monthly rollup in place
of an older monthly rollup. The remainders of the updates in this list are still needed as some
components in those updates released prior to October 2016 and are not included in a more
recent monthly rollup.

Windows Server 2012 and Windows 8

The latest fixes for these SMB components can be achieved by installing two updates:

1. KB 2984005 - September 2014 update rollup for Windows RT, Windows 8, and Windows
Server 2012
2. KB 4520007 - October 8, 2019-KB4520007 (Monthly Rollup) or later

NTFS component
 ﾉ Expand table

Date Knowledge Title Why we Hotfix type and

added Base Article recommend availability
this hotfix

10- 3121255 0x00000024 Stop error in This hotfix To apply this update, you
Jan- FsRtlNotifyFilterReportChange and contains an must have Windows 8 or
2016 copy file may fail in Windows update for Windows Server 2012
Ntfs.sys for installed. Available on
Windows Server Windows Update. Also
2012. included in July 11, 2017-
KB4025331 (Monthly
Rollup) and later monthly
rollups.

SRV component

ﾉ Expand table

Date Knowledge Title Why we recommend Hotfix type and

added Base Article this hotfix availability

15- 4493451 April 9, 2019-KB4493451 This hotfix contains the Included in April 9, 2019-
April- (Monthly Rollup) 6.2.9200.22707 version KB4493450 (Security-only
2020 of srvnet.sys, srv2.sys. update).
Included in April 9, 2019-
KB4493451 (Monthly
Rollup) and later monthly
rollups.

11- 2984005 September 2014 update This update rollup To apply this update
Aug- rollup for Windows RT, contains the most rollup, you must have
2014 Windows 8, and current version of Windows 8, or Windows
Windows Server 2012 srvsvc.dll. Server 2012 installed.

MRXSMB component

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and
added Base article availability

15- 4516055 September 10, This update rollup contains the Included in September
Apr- 2019- 6.2.9200.22859 version of 10, 2019-KB4516062
2020 KB4516055 mrxsmb.sys, 6.2.9200.22702 version (Security-only update).
(Monthly Rollup) of mrxsmb10.sys, and Included in September
6.2.9200.22365 version of 10, 2019-KB4516055
mrxsmb20.sys. (Monthly Rollup) and
later monthly rollups.

RDBSS component
 ﾉ Expand table

Date Knowledge Title Why we recommend Hotfix type and

added Base article this hotfix availability

15- 4520007 October 8, 2019- This update contains the Included in October 8, 2019-
April- KB4520007 6.2.9200.22874 version of KB4519985 (Security-only
2020 (Monthly Rollup) rdbss.sys. update).
Included in October 8, 2019-
KB4520007 (Monthly Rollup)
and later monthly rollups.

Windows Server 2012 R2 and Windows 8.1

７ Note

The latest fixes for these SMB components can be achieved by installing KB 4525243 .

ﾉ Expand table

Date Knowledge Title Why we Hotfix type and

added Base Article recommend this availability
hotfix

13- 3121255 0x00000024 Stop error in This update To apply this update,
May- FsRtlNotifyFilterReportChange and contains the you must be running
2016 copy file may fail in Windows 6.3.9600.18183 Windows 8.1 or
version of ntfs.sys. Windows Server 2012
R2 and April 2014
Update 2919355.
Available from
Windows Update.
Also included in May 9,
2017-KB4019215
(Monthly Rollup) and
later monthly rollups.

SRV component

ﾉ Expand table

Date Knowledge Title Why we recommend this Hotfix type and

added Base Article hotfix availability

15- 4493446 April 9, 2019- This hotfix contains the Included in April 9, 2019-
April- KB4493446 6.3.9600.19309 version of KB4493467 (Security-only
2020 (Monthly Rollup) srv.sys, srv2.sys, and update).
srvnet.sys. Included in April 9, 2019-
KB4493446 (Monthly
 Date Knowledge Title Why we recommend this Hotfix type and
added Base Article hotfix availability

Rollup) and later monthly

rollups.

MRXSMB component

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and
added Base article availability

15- 4525243 November 12, This update rollup contains the Included in November
April- 2019- 6.3.9600.19537 version of 12, 2019-KB4525250
2020 KB4525243 mrxsmb.sys, 6.3.9600.19293 version (Security-only update).
(Monthly Rollup) of mrxsmb10.sys, and Included in November
6.3.9600.18586 version of 12, 2019-KB4525243
mrxsmb20.sys. (Monthly Rollup) and
later monthly rollups.

RDBSS component

ﾉ Expand table

Date Knowledge Title Why we recommend this Hotfix type and

added Base article hotfix availability

15- 4520005 October 8, 2019- This update rollup Included in October 8,

April- KB4520005 contains the 2019-KB4519990 (Security-
2020 (Monthly Rollup) 6.3.9600.19481 version of only update).
rdbss.sys Included in October 8,
2019-KB4520005 (Monthly
Rollup) and later monthly
rollups.

Registry keys introduced with hotfixes or security

updates
Windows Server 2012 and Windows Server 2012 R2

ﾉ Expand table

Date Knowledge Registry key

Base
article

06/10/2013 2848322 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

AsynchronousCredits
 Date Knowledge Registry key
Base
article

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\
ExtendedSessTimeout

Services for NFS in a Windows Server 2012

environment
Network File System (NFS) Server components Windows Server 2012 and Windows 8.0

ﾉ Expand table

Date Knowledge Title Why we recommend this Hotfix type and

added Base article hotfix availability

03-Jun- 3130902 Stop error 0x9E and This update contains the To apply this update, you
2016 failover cluster can't most current version of must be running Windows
come online in Nfssvc.exe, Nfssvr.sys, and Server 2012. Available for
Windows Server 2012 Msnfsflt.sys. individual download.

NFS Client components Windows Server 2012 and Windows 8.0

ﾉ Expand table

Date Knowledge Title Why we recommend Hotfix type and

added Base article this hotfix availability

03-Jun- 3042826 POSIX subsystem This hotfix contains the To apply this hotfix, you
2016 crashes when you try most current version of must be running Windows 8
to create a Telnet Psxdll.dll, Psxdllsvr.dll, or Windows Server 2012.
session in Windows Psxss.exe, Posix.exe. Available for individual
download.

Services for NFS in a Windows Server 2012 R2

environment

７ Note

The latest fixes for these Network File System (NFS) components can be achieved by
installing KB 4503276 .

ﾉ Expand table
 Date Knowledge Title Why we recommend this Hotfix type and
added Base article hotfix availability

15- 4487016 February 19, 2019- This hotfix contains the Included in February 19,
April- KB4487016 6.3.9600.18751 version of 2019-KB4487016 (Preview
2020 (Preview of Nfssvc.exe, 6.3.9600.19240 of Monthly Rollup) and
Monthly Rollup) version of Nfssvr.sys . later monthly rollups.

15- 4503276 June 11, 2019- This hotfix contains the Included in June 11, 2019-
April- KB4503276 6.3.9600.19364 version of KB4503290 (Security-only
2020 (Monthly Rollup) Rpcxdr.sys . update).
Included in June 11, 2019-
KB4503276 (Monthly
Rollup) and later monthly
rollups.

NFS Client components Windows Server 2012 R2 and Windows 8.1

ﾉ Expand table

Date Knowledge Title Why we recommend this hotfix Hotfix type and
added Base article availability

15- 4038792 September 12, This hotfix contains the Included in September
Apr- 2017-KB4038792 6.3.9600.18751 version of 12, 2017-KB4038792
2020 (OS Build Monthly Nfsclnt.exe , 6.3.9600.18385 (OS Build Monthly
Rollup) version of Nfsrdr.sys and Rollup) and later
6.3.9600.18384 version of monthly rollups.
Nfsnp.dll .

Server Message Block (SMB) model

The SMB model consists of two entities: the client and the server.

On the client, applications perform system calls by requesting operations on remote files. These
requests are handled by the redirector subsystem ( rdbss.sys ) and by the SMB mini-redirector
( mrxsmb.sys ), both of which translate the requests into SMB protocol sessions and requests over
TCP/IP. Starting with Windows Vista, the SMB 2.0 protocol is supported. The mrxsmb10.sys driver
handles legacy SMB traffic, and the mrxsmb20.sys driver handles SMB 2.0 and SMB 3.0 traffic.

On the server, SMB connections are accepted, and SMB requests are processed as local file
system operations through NTFS and the local storage stack. The srv.sys driver handles legacy
SMB traffic, and the srv2.sys driver handles SMB 2.0 traffic. The srvnet.sys component
implements the interface between networking and the file server for both SMB protocols. File
system metadata and content can be cached in memory via the system cache in the kernel
( ntoskrnl.exe ).

The following screenshot provides an overview of the different layers through which a user
request on a client computer must go to perform file operations over the network on a remote
SMB file server by using SMB 2.0.

Components in services for NFS in a Windows

Server 2012 environment
Services for NFS includes the following components:

Server for NFS

This component corresponds to the server-side implementation of the NFS file-sharing

protocol. Server for NFS enables a computer that is running Windows Server 2012 or
Windows Server 2012 R2 to act as a file server for UNIX-based client computers.

Client for NFS

This component corresponds to the client-side implementation of the NFS file-sharing

protocol. Client for NFS enables a Windows-based computer that is running Windows
Server 2012 (or Windows 8) to access files that are stored on a UNIX-based NFS server.

Windows Server 2012 includes both the Server for NFS and Client for NFS components. However,
Windows 8 includes only Client for NFS.

Microsoft Services for NFS provides a file-sharing solution for enterprises that have a mixed
Windows and UNIX environment. This communication model consists of client computers and a
server. Applications on the client request files that are located on the server through the
redirector ( Rdbss.sys ) and NFS mini-redirector ( Nfsrdr.sys ). The mini-redirector uses the NFS
protocol to send its request through TCP/IP. The server receives multiple requests from the
clients through TCP/IP and routes the requests to the local file system ( Ntfs.sys ), which accesses
the storage stack.

References
For more information about currently available hotfixes for the File Services technologies in
Windows Server 2008 and Windows Server 2008 R2, see KB2473205 .
For more information about performance tuning, see the Tuning parameters for SMB file servers
section in Performance Tuning for File Servers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to create a virtual directory on an
existing Web site to a folder that resides
on a remote computer
Article • 12/26/2023

This article describes how to create, test, and remove a virtual directory on an existing
Web site to a folder that resides on a remote computer.

Applies to: Windows Server 2012 R2

Original KB number: 308150

A remote virtual directory is a directory that's not contained within the Web site's home
directory but appears to client browsers as though it's within the home directory. A
remote virtual directory has an alias that is mapped to a Universal Naming Convention
(UNC) share location. A client appends the alias to the URL of the Web site to browse
the Web content in that virtual directory. The following table illustrates these mappings:

ﾉ Expand table

Physical location Alias URL path

C:\WWWroot home directory http://Sales

(none)

\\RemoteServer Customers http://Sales/Customers

\SalesData\ProdCustomers

Both virtual directories and physical directories (directories without an alias) are listed in
Internet Services Manager. A virtual directory is indicated by a folder icon that has a
globe in the corner.

How to configure a remote network share

To create a virtual directory to a remote network share, create the share, and then store
the Web content in that share. Set the appropriate sharing permissions, and then add
the appropriate NTFS permissions to control access to the folder that contains your
content.

７ Note
 You can also publish Web content to the remote share after the virtual directory is
created.

How to create a virtual directory

1. Log on to the Web server computer using an account that has administrative
privileges.

2. Click Start, point to Programs > Administrative Tools, and then click Internet
Services Manager.

3. In the Internet Information Services window, expand server name (where server
name is the name of the server).

4. Right-click the Web site that you want (for example, Default Web Site), point to
New, and then click Virtual Directory.

5. On the Welcome to the Virtual Directory Creation Wizard page, click Next.

6. On the Virtual Directory Alias page, type the alias that you want (for example,
Sales), and then click Next.

7. On the Web Site Content Directory page, type the UNC path to the remote folder
that you've created (for example, \\Server\Share), and then click Next.

8. On the User Name and Password page, type the user name and password that has
sufficient privileges to gain access to the remote folder.

７ Note

To maintain the highest levels of security, use an account that has the
minimum permissions that are necessary to provide access to the remote
content.

9. Click Next, retype the password that you used in step eight in the Confirm
Password dialog box, and then click OK.

10. On the Access Permissions page, click to select the check boxes of the permissions
that you want to set for the virtual directory.

By default, Read permissions and Run scripts permissions are already selected. For
example, if you want to allow users to change the content in the virtual directory,
click to select the Write check box.
 11. Click Next, and then click Finish.

７ Note

The virtual directory inherits the configuration and security settings of the
Web site in which it is created.

How to test the virtual directory

1. Start Internet Explorer.

2. In the Address box, type the URL to your Web server (for example,
http://WebServer ), and then click Go.

Verify that you can view the default Web site.

3. Append the alias of the virtual directory to the address that you typed in step two
(for example, http://WebServer/Sales ), and then click Go.

The virtual directory Web content is displayed in the browser window.

How to remove a virtual directory

To delete a virtual directory, remove the alias that Internet Information Services (IIS) uses
to reference the content stored in that directory.

７ Note

When you delete a virtual directory, the network share and its content are not also
deleted.

To delete a virtual directory, follow these steps:

1. Click Start, point to Programs > Administrative Tools, and then click Internet
Services Manager.

2. In the Internet Information Services window, click to expand server name (where
server name is the name of the server).

3. Expand the Web site that contains the virtual directory that you want to delete. For
example, expand Default Web Site.
 4. Right-click the virtual directory that you want (for example, Sales) and then click
Delete.

5. Click Yes when the following message is displayed:

Are you sure you want to delete this item?

７ Note

The Web content remains in the remote folder to which the virtual directory
was mapped.

6. Stop, and then restart the Web site:

a. Right-click the Web site that you want (for example, Default Web Site), and
then click Stop.
b. Right-click the Web site, and then click Start.

7. Quit the Internet Information Services snap-in.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Manually decommission a root server
that hosts a domain-based DFS root in
Windows Server 2003
Article • 12/26/2023

This article discusses how to decommission a root server that hosts a domain-based
Microsoft Distributed File System (DFS) root in Microsoft Windows Server 2003.

Applies to: Windows Server 2003

Original KB number: 842218

More information
To decommission a root server that hosts a domain-based DFS root, follow these steps:

1. Remove the root server from the DFS namespace. To do this:

Use the Distributed File System snap-in to remove the root server from the
DFS namespace. To do this:

a. Click Start, point to All Programs, point to Administrative Tools, and then
click Distributed File System.

b. In the left pane, click the DFS root that is to be removed.

c. In the right pane, right-click the root target that you want to remove, and
then click Remove Target.

d. Click Yes.

e. Close the DFS snap-in.

Use the version of the DFS utility (Dfsutil.exe) that is included in the Windows
Server 2003 Support Tools to remove the root server from the DFS
namespace. To do this, follow these steps.

７ Note

To install the DFS utility that is included in the Windows Server 2003
Support Tools, right-click Suptools.msi in the Support\Tools folder on
the Windows Server 2003 CD-ROM, and then click Install.
 a. Click Start, click Run, type cmd in the Open box, and then click OK.
b. Type the following command, and then press ENTER:
Dfsutil /UnmapFtRoot /Root:DFS root /Server: RootTargetServer
/Share:DFS share name

７ Note

RootTargetServer refers to the root server that is to be decommissioned.

Also, DFS root must be of the following form:
\\DomainOrServer\RootName.

2. On the decommissioned root target, remove DFS information from the registry by
using the following Dfsutil.exe command:
Dfsutil /Clean /Server:RootTargetServer /Share:DFS share name

3. On the decommissioned root server, at a command prompt, type net stop dfs, and
then press ENTER.

4. On the decommissioned root server, at a command prompt, type net start dfs, and
then press ENTER.

７ Note

After you remove a DFS root target, DFS stops giving referrals to the
decommissioned server within 15 minutes of the update to the DFS Active
Directory directory service object. The DFS Active Directory object resides on
the local domain controller and is issued by the PDC emulator master. The
time that the update can take depends on Active Directory replication
schedules.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to remove administrative shares in
Windows Server
Article • 12/26/2023

This article describes how to remove default administrative shares, and how to prevent
these shares from being automatically created in Windows Server.

Applies to: Windows Server

Original KB number: 954422

Introduction
By default, Windows Server automatically creates special hidden administrative shares
that administrators, programs, and services can use to manage the computer
environment or network. These special shared resources aren't visible in Windows
Explorer or in My Computer. However, you can view them by using the Shared Folders
tool in Computer Management. Depending on the configuration of your computer,
some or all of the following special shared resources may be listed in the Shares folder
in Shared Folders:

DriveLetter$: It's a shared root partition or volume. Shared root partitions and
volumes are displayed as the drive letter name appended with the dollar sign ($).
For example, when drive letters C and D are shared, they're displayed as C$ and
D$.

ADMIN$: It's a resource that is used during remote administration of a computer.

IPC$: It's a resource that shares the named pipes that you must have for
communication between programs. This resource cannot be deleted.

NETLOGON: It's a resource that is used on domain controllers.

SYSVOL: It's a resource that is used on domain controllers.

PRINT$: It's a resource that is used during the remote administration of printers.

FAX$: It's a shared folder on a server that is used by fax clients during fax
transmission.

７ Note
 NETLOGON and SYSVOL aren't hidden shares. Instead, they are special
administrative shares.

Generally, we recommend that you don't modify these special shared resources.
However, if you want to remove the special shared resources and prevent them from
being created automatically, you can do it by editing the registry.

Remove administrative shares by editing the

registry
To have us do this for you, go to the Fix it for me section. If you would rather fix this
problem yourself, go to the Let me fix it myself section.

Fix it for me
To fix this problem automatically, select the Fix this problem link. Then, select Run in the
File Download dialog box, and follow the steps in this wizard.

Notes

This wizard may be in English only; however, the automatic fix also works for other
language versions of Windows.
If you aren't on the computer that has the problem, you can save the automatic fix
to a flash drive or to a CD, and then you can run it on the computer that has the
problem. Now go to the Did this fix the problem? section.

Let me fix it myself

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information, see How to back up and restore the
registry in Windows .

To remove administrative shares and prevent them from being automatically created in
Windows, follow these steps:
 1. Select Start, and then select Run.

2. In the Open box, type regedit, and then select OK.

3. Locate, and then select the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\A

utoShareServer

７ Note

The registry subkey AutoShareServer must be set as type REG_DWORD. When

this value is set to 0 (zero), Windows does not automatically create
administrative shares. Be aware that this does not apply to the IPC$ share or
shares that you create manually.

4. On the Edit menu, select Modify. In the Value data box, type 0, and then select OK.

5. Exit Registry Editor.

6. Stop and then start the Server service. To do it, follow these steps:
a. Select Start, and then select Run.
b. In the Open box, type cmd, and then select OK.
c. At the command prompt, type the following lines. Press Enter after each line:
net stop server
net start server
d. Type exit to close the Command Prompt window.

Now go to the Did this fix the problem section.

Did this fix the problem

Check whether the problem is fixed. If the problem is fixed, you're finished with this
article. If the problem isn't fixed, you can contact support .

References
For more information about how to manage shared resources by using Shared Folders
in Windows Server, see the Shared Folders Help files. To do it, select Start, point to
Administrative Tools, and then select Computer Management. In the console tree,
right-click Shared Folders, and then select Help.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

IPC$ share and null session behavior in
Windows
Article • 12/26/2023

This article describes the inter-process communication share (IPC$) and null session
behavior in Windows.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 3034016

About IPC$ share

The IPC$ share is also known as a null session connection. By using this session,
Windows lets anonymous users perform certain activities, such as enumerating the
names of domain accounts and network shares.

The IPC$ share is created by the Windows Server service. This special share exists to
allow for subsequent named pipe connections to the server. The server's named pipes
are created by built-in operating system components and by any applications or
services that are installed on the system. When the named pipe is being created, the
process specifies the security associated with the pipe. Then it makes sure that access is
only granted to the specified users or groups.

Configure anonymous access by using network

access policy settings
The IPC$ share can't be managed or restricted in the following versions of Windows:

Windows Server 2003

Windows Server 2008
Windows Server 2008 R2

However, an administrator has controls over any named pipes that were enabled. They
can be accessed anonymously by using the Network access: Named Pipes that can be
accessed anonymously security policy setting. If the policy setting is configured to have
no entries, such as a Null value, no named pipes can be accessed anonymously. And you
must ensure that no applications or services in the environment rely on anonymous
access to any named pipes on the server.
Windows Server 2003 no longer prevents anonymous access to IPC$ share. The
following security policy setting defines whether the Everyone group is added to an
anonymous session:

Network access: Let Everyone permissions apply to anonymous users

If this setting is disabled, the only resources that can be accessed by an anonymous user
are those resources granted to the Anonymous Logon group.

In Windows Server 2012 or a later version, there's a feature to determine whether

anonymous sessions should be enabled on file servers. It's determined by checking if
any pipes or shares are marked for remote access.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A mapped network drive appears to be
disconnected after you install or
upgrade to Symantec AntiVirus 10.0 or
to Symantec Client Security 3.0
Article • 12/26/2023

This article provides a solution to an issue where mapped network drive is disconnected
after you install or upgrade to Symantec AntiVirus 10.0 or to Symantec Client Security
3.0.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 932463

Symptoms
After you install or upgrade to Symantec AntiVirus 10.0 or to Symantec Client Security
3.0 on a Microsoft Windows Server 2003-based computer or on a Microsoft Windows
XP-based computer, you receive the following message for a mapped network drive in
Windows Explorer:

Disconnected Network Drive

However, you can still access the contents of the mapped drive. Additionally, when you
try to remove the mapped drive in Windows Explorer, you receive the following error
message:

The network connection could not be found.

Cause
This problem occurs because of an issue in Symantec AntiVirus 10.0 and in Symantec
Client Security 3.0.

Resolution

） Important
 This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .

To remove the incorrectly labeled mapped drive, follow these steps:

1. Click Start, point to Run, type regedit, and then click OK.

2. In Registry Editor, locate the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoin

ts2

3. Right-click the mapped drive that you want to remove. For example, right-click
##Server_Name#Share_Name, and then click Delete.

７ Note

Replace the Server_Name placeholder with the name of the server that hosts the
mapped network drive. Replace the Share_Name placeholder with the name of the
mapped network drive.

More information
Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

When you redirect the Documents
folder on a Windows Vista-based or
Windows 7-based computer to a
network share, the folder name
unexpectedly changes back to
Documents
Article • 12/26/2023

This article provides workaround for the issue where the folder name unexpectedly
changes back to Documents when you redirect the Documents folder to a network
share.

Applies to: Windows 7 Service Pack 1

Original KB number: 947222

Symptoms
When you redirect the Documents folder on a Windows Vista-based or Windows 7-
based computer to a network share, the folder name unexpectedly changes back to
Documents. You expect the folder name to be the user name.

This behavior may create many Documents folders on the network share. If you try to
rename one Documents folder, all the other Documents folders change to that name.

Workaround
To work around this behavior, use one of the following methods.

Method 1
Create a subfolder under the redirected folder in the Universal Naming Convention
(UNC) path. For example, use the following UNC
path:\\server\users\username\Documents.

Method 2
Grant the user exclusive rights to the redirected folder. To do this, follow these steps:

1. Log on to the computer by using domain administrator credentials.

2. In the Start Search box, type gpmc.msc, right-click gpmc.msc, and then click Run
as administrator.

７ Note

If you are prompted for an administrator password, type the password. If you
are prompted for confirmation, provide confirmation.

3. Right-click the Group Policy Objects node, and then click New. Type the name of
the policy. For example, in the New GPO dialog box, type Windows Vista Folder
Redirection Policy.

4. Right-click the Group Policy object that you created in step 3, and then click Edit.

5. Under User Configuration, expand Windows Settings, and then expand Folder
Redirection.

6. Right-click the Documents folder, and then click Properties.

7. On the Target tab, configure the following:

In the Setting box, click Basic-redirect everyone's folder to the same

location.
In the Target Folder Location box, click Create a folder for each user under
the root path.
In the Root Path box, type the UNC file path to which you want to redirect
the Documents folder.

8. In the Documents Properties dialog box, click the Settings tab, and then configure
the following:

Click to select the Grant the user exclusive rights to Documents check box.
Click to select the Move the contents of Documents to the new location
check box.

9. Click OK.

Method 3
Do not grant the Read permission to the administrator for the Desktop.ini files on the
server. To do this, follow these steps:

７ Note

If more than one Desktop.ini file exists, follow these steps for all the Desktop.ini
files.

1. Right-click the Desktop.ini file, click Properties, and then click the Security tab.
2. In the Group or user names pane, click Administrators.
3. Click to select the Deny check box for the Read permission.
4. Click OK.

７ Note

Method 2 works only for new users. To update the names of the existing folders on
the server, we recommend that you use Method 3.

Status
This behavior is by design.

More information

Steps to reproduce the behavior

1. Right-click the Documents folder, and then click Properties.
2. Under the Location tab, enter the UNC path of the network share to which you
want to redirect the folder.

For example, enter a UNC path that resembles the following:\\server\users\username

After you do this, the name of the Documents folder is supposed to change to the user
name.

Feedback
Was this page helpful?
  Yes  No

Provide product feedback

Negotiate, Session Setup, and Tree
Connect failures
Article • 12/26/2023

This article describes how to troubleshoot the failures that occur during an SMB
Negotiate, Session Setup, and Tree Connect request.

Negotiate fails
The SMB server receives an SMB NEGOTIATE request from an SMB client. The
connection times out and is reset after 60 seconds. There might be an ACK message
after about 200 microseconds.

This problem is most often caused by antivirus program.

If you're using Windows Server 2008 R2, there are hotfixes for this problem. Make sure
that the SMB client and the SMB server are up to date.

Session Setup fails

The SMB server receives an SMB SESSION_SETUP request from an SMB client but failed
to response.

If the fully qualified domain name (FQDN) or Network Basic Input/Output System
(NetBIOS) name of the server is used in the Universal Naming Convention (UNC) path,
Windows will use Kerberos for authentication.

After the Negotiate response, there will be an attempt to get a Kerberos ticket for the
Common Internet File System (CIFS) service principal name (SPN) of the server. Look at
the Kerberos traffic on TCP port 88 to make sure that there are no Kerberos errors when
the SMB client is gaining the token.

７ Note

The errors that occur during the Kerberos Pre-Authentication are OK. The errors
that occur after the Kerberos Pre-Authentication (instances in which authentication
does not work), are the errors that caused the SMB problem.

Additionally, make the following checks:

 Look at the security blob in the SMB SESSION_SETUP request to make sure the
correct credentials are sent.
Try to disable SMB server name hardening (SmbServerNameHardeningLevel = 0).
Make sure that the SMB server has an SPN when it's accessed through a CNAME
DNS record.
Make sure that SMB signing is working. (This is especially important for older,
third-party devices.)

Tree Connect fails

Make sure that the user account credentials have both share and NT file system (NTFS)
permissions to the folder.

The cause of common Tree Connect errors can be found in 3.3.5.7 Receiving an SMB2
TREE_CONNECT Request. The following are the solutions for two common status codes.

[STATUS_BAD_NETWORK_NAME]

Make sure that the share exists on the server, and that it's spelled correctly in the
SMB client request.

[STATUS_ACCESS_DENIED]

Verify that the disk and folder that are used by the share exists and is accessible.

If you're using SMBv3 or later, check whether the server and the share require
encryption, but the client doesn't support encryption. To do this, take the following
actions:

Check the server by running the following cmdlet.

PowerShell

Get-SmbServerConfiguration | select Encrypt*

If EncryptData and RejectUnencryptedAccess are true, the server requires

encryption.

Check the share by running the following cmdlet:

PowerShell

Get-SmbShare | select name, EncryptData

 If EncryptData is true on the share, and RejectUnencryptedAccess is true on the
server, encryption is required by the share

Follow these guidelines as you troubleshoot:

Windows 8, Windows Server 2012, and later versions of Windows support client-
side encryption (SMBv3 and later).
Windows 7, Windows Server 2008 R2 and earlier versions of Windows don't
support client-side encryption.
Samba and third-party device might not support encryption. For more information,
you might have to consult product documentation.

References
For more information, see the following articles.

3.3.5.4 Receiving an SMB2 NEGOTIATE Request

3.3.5.5 Receiving an SMB2 SESSION_SETUP Request
3.3.5.7 Receiving an SMB2 TREE_CONNECT Request

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Reduced networking performance after
you enable SMB Encryption or SMB
Signing in Windows Server 2016 and
Windows Server 2019
Article • 12/26/2023

This article provides a solution to an issue where networking performance is reduced

after you enable Server Message Block (SMB) Encryption or SMB Signing in Windows
Server 2016 and Windows Server 2019. Windows Server 2022 improves network
performance for this scenario.

Applies to: Windows Server 2016, Windows Server 2019, Windows Server 2022
Original KB number: 4458042

Symptoms
You use a network adapter that has remote direct memory access (RDMA) enabled. After
you enable SMB Signing or SMB Encryption, the network performance of SMB Direct
together with the network adapter is significantly reduced.

In addition, one or more of the following Event IDs may be logged:

Output

Log Name: Microsoft-Windows-SMBClient/Operational

Source: Microsoft-Windows-SMBClient
Event ID: 30909
Level: Informational
Description:
The client supports SMB Direct (RDMA) and SMB Signing is in use.
Share name:ShareName
Guidance:
For optimal SMB Direct performance, you can disable SMB Signing. This
configuration is less secure and you should only consider this configuration
on trustworthy private networks with strict access control.

Output

Log Name: Microsoft-Windows-SMBClient/Operational

Source: Microsoft-Windows-SMBClient
Event ID: 30910
Level: Informational
 Description:
The client supports SMB Direct (RDMA) and SMB Encryption is in use.
Share name: <Share name>
Guidance:
For optimal SMB Direct performance, you can disable SMB Encryption on the
server for shares accessed by this client. This configuration is less secure
and you should only consider this configuration on trustworthy private
networks with strict access control.

Output

Log Name: Microsoft-Windows-SmbClient/Security

Source: Microsoft-Windows-SMBClient
Event ID: 31016
Level: Warning
Description:
The SMB Signing registry value is not configured with default settings.
Default Registry Value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\\Par
ameters]
"EnableSecuritySignature"=dword:1
Configured Registry Value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\\Par
ameters]
"EnableSecuritySignature"=dword:0
Guidance:
Even though you can disable, enable, or require SMB Signing, the negotiation
rules changed starting with SMB2 and not all combinations operate like SMB1.
The effective behavior for SMB2/SMB3 is:
Client Required and Server Required = Signed
Client Not Required and Server Required = Signed
Server Required and Client Not Required = Signed
Server Not Required and Client Not Required = Not Signed
When requiring SMB Encryption, SMB Signing is not used, regardless of
settings. SMB Encryption implicitly provides the same integrity guarantees
as SMB Signing.

Cause
Several features such as Storage Spaces Direct (S2D) or Cluster Shared Volumes (CSV)
use SMB as a protocol transport for intra-cluster communication. Therefore, the
performance of S2D may be significantly affected by enabling SMB Signing or SMB
Encryption that uses the RDMA network adapter.

When either SMB Signing or SMB Encryption is enabled, SMB stops using RDMA direct
data placement (also known as RDMA read/write). This is a fallback policy, and this
behavior is by design for the highest level of security. Therefore, SMB falls back to use
the RDMA connection in a purely send-and-receive mode. Data flows in a non-optimal
path because the maximum MTU limit is 1,394 bytes. This causes message
fragmentation and reassembly, and overall decreased performance.

This issue may occur after you follow the Security baseline for Windows 10 v1607
("Anniversary Update") and Windows Server 2016 to enable SMB Signing.

Or, if you use the following Group Policy settings to enable SMB Signing:

Microsoft network server - Digitally sign communications (always) - ENABLED

Microsoft network client - Digitally sign communications (always) - ENABLED

Resolution
SMB Signing and SMB Encryption have some trade-offs in performance. If network
performance is important to your deployment scenarios (such as with Storage Spaces
Direct), we recommend that you not deploy SMB Signing and SMB Encryption.

Windows Server 2022 SMB Direct now supports encryption. Data is encrypted before
placement, leading to relatively minor performance degradation. Furthermore, Windows
Server 2022 failover clusters now support granular control of encrypting intra-node
storage communications for Cluster Shared Volumes (CSV) and the storage bus layer
(SBL). This means that when using Storage Spaces Direct and SMB Direct, you can
decide to encrypt east-west communications within the cluster itself for higher or lower
security on a per SMB instance basis.

If you are deploying in a highly secure environment with Windows Server 2016 and
Windows Server 2019, we recommend that you apply the following configurations:

1. Do not deploy by using RDMA-enabled network adapters, or disable RDMA by

using the Disable-NetAdapterRdma cmdlet.

2. Based on the SMB client and SMB server version, evaluate the most appropriate
solution to optimize performance. Be aware that SMB Signing provides message
integrity, and SMB Encryption provides message integrity plus privacy to provide
the highest level of security.

SMB 3.0 (introduced with Windows Server 2012/Windows 8) - SMB Signing

will deliver better performance than SMB Encryption.
SMB 3.1 (introduced with Windows Server 2016/Windows 10) - SMB
Encryption will deliver better performance than SMB Signing, and has the
added benefit of increased security together with message privacy in addition
to message integrity guarantees.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

NFS Server and File Permissions
Article • 12/26/2023

This article provides some information about NFS Server and File Permissions.

Applies to: Windows Server 2012 R2

Original KB number: 231964

Summary
This article describes how to set file permissions on your Windows NT network file
system (NFS) exports to work with UNIX NFS workstations.

More information
You do not need to perform these steps when using only anonymous authentication,
although the results can give you some insight into how NTFS file permissions are
reflected onto UNIX workstations.

７ Note

The following instructions assume that the Windows NT Server-based NFS

computer is configured to use default values for advanced options and security
permissions.

On the Microsoft Windows NT Server-based NFS computer:

1. Always set the NTFS permissions on your export (and all folders and files
underneath the export) to Full Control for Everyone, the Administrators group, and
the Administrator user.

2. If your export folder is empty, create a dummy file called dummyfile in your NFS
export folder.

3. If you are not using a network information service (NIS) server, copy the
Etc/Passwd and Etc/Group files in binary mode from the appropriate UNIX
computer to the Winnt\System32\drivers\etc folder.

７ Note
 Leave the password fields blank. It is recommended that UIDs and GIDs be
unique as a whole, as well as user names and groups as a whole. For example,
do not use 1001 for a user and a group, and do not have a wheel user in
addition to a wheel group.

4. Map each user and each group to a unique Windows NT user and group. You can
do this using Server for NFS User Manager.

5. Map the UNIX root user to the Windows NT Administrator user and the group root
or wheel to the Windows NT Administrators group.

On the UNIX NFS client:

1. Log on as root (only root can mount an NFS export). Mount the export on your
UNIX workstation by typing

Console

mount ntserver :/F/export/home/user /mnt

where ntserver is the host name of the Windows NT Server-based computer,

F/export/home/user is the path to the export, and mnt is a locally available mount
point.

2. Check the permissions by typing:

Console

ls -l

Output similar to the following example is displayed:

Console

-rwxrwxrwx 1 root root dummyfile

3. Assign the appropriate owners to the files and folders by typing:

Console

/usr/ucb/chown -R user.group /mnt

 ７ Note

In some UNIX operating systems, the chown command does not take a group
parameter. In these situations, you need to type chgrp -R group /mnt in
addition to this command.

4. Assign appropriate permissions to the files and folders by typing:

Console

chmod -R g-w,o-wx /mnt

5. Verify the new permissions by typing:

Console

ls -l

Output similar to the following example is displayed:

Console

-rwxr-xr-- 1 user group dummyfile

If you are unable to change the permissions on a file or if you receive "access denied"
error messages, use the following steps:

1. On the Windows NT Server-based NFS computer, assign Full Control to the export
for Everyone, the Administrators group, and the Administrator user.
2. On the UNIX NFS client, copy the file to a different name (you must do it as a user,
not as root). Delete the original file in Windows NT and rename the file to its
original name.

Some Windows NT users and groups cannot be mapped to equivalent UNIX users or
groups. They may be displayed as nobody4 or nogroup. Special groups that exhibit this
behavior include:

Everyone
Network
Interactive
System
Authenticated users
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Overview of Server Message Block
signing
Article • 12/26/2023

This article describes Server Message Block (SMB) 2.x and 3.x signing, and how to
determine whether SMB signing is required.

Introduction
SMB signing (also known as security signatures) is a security mechanism in the SMB
protocol. SMB signing means that every SMB message contains a signature that is
generated by using the session key. The client puts a hash of the entire message into
the signature field of the SMB header.

SMB signing first appeared in Microsoft Windows 2000, Microsoft Windows NT 4.0, and
Microsoft Windows 98. Signing algorithms have evolved over time. SMB 2.02 signing
was improved by the introduction of hash-based message authentication code (HMAC)
SHA-256, replacing the old MD5 method from the late 1990s that was used in SMB1.
SMB 3.0 added AES-CMAC algorithms. In Windows Server 2022 and Windows 11, we
added AES-128-GMAC signing acceleration. If you want the best performance and
protection combination, consider upgrading to the latest Windows versions.

How SMB signing protects the connection

If someone changes a message during transmission, the hash won't match, and SMB will
know that someone tampered with the data. The signature also confirms the sender's
and receiver's identities. This prevents relay attacks. Ideally, you are using Kerberos
instead of NTLMv2 so that your session key starts strong. Don't connect to shares by
using IP addresses and don't use CNAME records, or you will use NTLM instead of
Kerberos. Use Kerberos instead. See Using Computer Name Aliases in place of DNS
CNAME Records for more information.

Policy locations for SMB signing

The policies for SMB signing are located in Computer Configuration > Windows
Settings > Security Settings > Local Policies > Security Options.

Microsoft network client: Digitally sign communications (always)

Registry key:
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Paramet
ers

Registry value: RequireSecuritySignature

Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)
Microsoft network client: Digitally sign communications (if server agrees)
Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Paramet
ers

Registry value: EnableSecuritySignature

Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)
Microsoft network server: Digitally sign communications (always)
Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

Registry value: RequireSecuritySignature

Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)
Microsoft network server: Digitally sign communications (if client agrees)
Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
Registry value: EnableSecuritySignature
Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)

Note In these policies, "always" indicates that SMB signing is required, and "if server
agrees" or "if client agrees" indicates that SMB signing is enabled.

Understanding "RequireSecuritySignature" and

"EnableSecuritySignature"
The EnableSecuritySignature registry setting for SMB2+ client and SMB2+ server is
ignored. Therefore, this setting does nothing unless you're using SMB1. SMB 2.02 and
later signing is controlled solely by being required or not. This setting is used when
either the server or client requires SMB signing. Only if both have signing set to 0 will
signing not occur.

ﾉ Expand table
 - Server – Server –
RequireSecuritySignature=1 RequireSecuritySignature=0

Client – Signed Signed

RequireSecuritySignature=1

Client – Signed Not signed

RequireSecuritySignature=0

Reference
Configure SMB Signing with Confidence

How to Defend Users from Interception Attacks via SMB Client Defense

SMB 2 and SMB 3 security in Windows 10: the anatomy of signing and cryptographic
keys

SMBv1 is not installed by default in Windows 10 version 1709, Windows Server version
1709 and later versions

Netdom computername

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Overview of problems that may occur
when administrative shares are missing
Article • 12/26/2023

This article provides a resolution for the problems that may occur when administrative
shares are missing.

Applies to: Windows Server 2012 R2, Windows 10 - all editions

Original KB number: 842715

Summary
This article describes the symptoms that may occur when one or more of the hidden
administrative shares are missing on your computer. The article also provides
information about how to resolve this problem.

If you have already determined that your computer is missing one or more of the
hidden administrative shares, see the "Cause" and "Resolution" sections. Realize that
missing administrative shares typically indicate that the computer in question has been
compromised by malicious software. We recommend that users format and reinstall
Windows on compromised servers.

Symptoms
You may experience a variety of issues when administrative shares are removed or are
otherwise missing from your computer.

If you use the net share command or MPSReports, the output may show that your
computer is missing the IPC$, ADMIN$, or C$ share. If you re-create a missing share, it
may be missing again after the next startup or logon. This issue may occur even if you
set the AutoShareServer and AutoShareWks registry DWORD values to 1.

You may find unknown processes that start from the Startup folder or from the Run key
in the registry. Antivirus software may detect viruses, worms, Trojans, or backdoors. Or
the FTP root on a Web server may be filled with unknown files.

The following list is a comprehensive list of the problematic behavior that may be
associated with this issue.
If the affected computer is a domain controller, you may receive error messages on
client computers during network logon or during the times when they try to join
the domain. Sometimes, you can log on with client computers, but you may
receive an error message that is similar to either of the following ones:

The domain password you supplied is not correct, or access to your logon
server has been denied.

The logon server did not recognize your domain password, or access to the
server has been denied.

No logon server is available to service the logon request.

When you try to join the domain, you may receive an error message that is
similar to:

The following error occurred attempting to join the domain

'Domain_Name': The network name cannot be found.

When you try to access or view the affected computer remotely by using a UNC
path, a mapped drive, the net use command, the net view command, or by
browsing the network in Network Neighborhood or My Network Places, you may
receive an error message that is similar to one of the followings:

The server is not configured for transactions.

System error 53 has occurred. The network path was not found.

Domain_Name is not accessible.

You may receive errors when you try to perform administrative tasks on a domain
controller. For example, MMC snap-ins such as Active Directory Users and
Computers or Active Directory Sites and Services may not start, and you may
receive an error message that is similar to the following one:

Naming Information cannot be located because: Login attempt failed.

When you try to add a user to a security group, you may receive an error message
that is similar to:
 Object Picker cannot open because no locations from which to choose objects
can be found.

When you try to run Netdom.exe to find the FSMO roles, you may receive an error
message that is similar to the following one:

Unable to update the password. The value provided as the current password is
incorrect.

When you try to run Dcdiag.exe, you may receive an error message that is similar
to the following one:

Failed with 67: The network name cannot be found

The results from Dcdiag.exe may also list LDAP bind errors that are similar to the
following one:

LDAP bind failed with error 1323.

When you try to run Netdiag.exe, you may receive an error message that is similar
to:

DC list test . . . . . . . . . . . : Failed

Failed to enumerate DCs by using the browser. [NERR_BadTransactConfig]

If you run a network trace when you try to connect to the affected computer, you
may see results that are similar to the following one:

Console

C session setup & X, Username = username, and C tree connect & X, Share
= \\<Server_Name>\IPC$
R session setup & X - DOS Error, (67) BAD_NET_NAME

On the server, the WINS service may not start or the WINS console may display a
red X, or both.

NetBT 4311 events that are similar to the following ones may be logged in Event
Viewer:

Event ID: 4311

Event Source: NetBT
 Event Type: Error
Description: Initialization failed because the driver device could not be created

The Terminal Services Licensing console may not start, and you may receive an
error message that is similar to:

No Terminal Services license server is available in the current domain or

workgroup. To connect to another license server, click license, click connect
and click the server name.

The network address is invalid

Cause
These issues may occur after a malicious program removes the administrative shares on
a computer that is running Windows Server.

Frequently, malicious users connect to these administrative shares by taking advantage

of weak passwords, missing security updates, direct exposure of the computer to the
Internet, or a combination of these factors. The malicious users then install malicious
programs to expand their influence over the computer and over the rest of the
computer network. In many cases, these malicious programs remove the administrative
shares as a defensive move to prevent other competing malicious users from taking
control of the infected systems.

Infection by one of these malicious programs can come directly from the Internet or
from another computer on the local network that is infected. It generally indicates that
security on the network is weak. Therefore, if you see these symptoms, we recommend
that you examine all other computers on the network for malicious programs by using
antivirus software and spyware detection tools. We also recommend that you perform a
security analysis to identify vulnerabilities on the network. See the "Resolution" section
for information about how to detect malicious programs and how to analyze network
security.

An example of a malicious program that targets administrative shares is the

Win32.Agobot program.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

７ Note
 The Win32.Agobot program is only an example. Malicious programs become
obsolete as antivirus vendors discover them and add them to their virus definitions.
However, malicious users frequently develop new programs and variants to avoid
detection by antivirus software.

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, click the following article number to view the article in the Microsoft
Knowledge Base:
322756 How to back up and restore the registry in Windows

To verify whether a computer is affected by this issue, follow these steps:

1. Examine the AutoShareServer and AutoShareWks registry values to make sure that
they are not set to 0:
a. Click Start, click Run, type regedit, and then press ENTER.
b. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameter
s

c. If the AutoShareServer and AutoShareWks DWORD values in the

LanmanServer\Parameters subkey are configured with a value data of 0,
change that value to 1.

７ Note

If these values do not exist, you do not have to create them because the
default behavior is to automatically create the administrative shares.

d. Quit Registry Editor.

2. Restart the computer. Typically, computers that are running Windows Server
automatically create the administrative shares during startup.
 3. After the computer restarts, verify that the administrative shares are active. To
examine the shares, use the net share command. To do it, follow these steps:

a. Click Start, click Run, type cmd, and then press ENTER.

b. At the command prompt, type net share, and then press ENTER.

c. Look for the Admin$, C$, and IPC$ administrative shares in the list of shares.

If the administrative shares are not listed, the computer may be running a malicious
program that removes the shares during startup. To look for malicious programs, follow
these steps:

1. Use the latest virus definitions to run a complete antivirus scan on the computer.
You can use your antivirus software or use one of several free virus-scanning
services that are available on the Internet. See the "More Information" section for
links to virus definition updates and to free online scans from antivirus software
vendors.

） Important

If you suspect that a computer is infected with malicious code, we

recommend that you remove it from the network as soon as possible. We
recommend this because a malicious user may be using the infected
computer to start Distributed Denial of Service (DDoS) attacks, to send
unsolicited commercial e-mail, or to share illegal copies of software, music,
and movies.

2. If the antivirus scan identifies a malicious program on the system, use the antivirus
vendor's removal instructions. Additionally, review the threat assessment and the
technical details about the program on your antivirus vendor's Web site. In
particular, check to see if the program includes backdoor capability. Backdoor
capability means that the program provides a way for the malicious user to regain
control of the system if the program is discovered and removed.

If the technical details about the program indicate that it has backdoor capability,
we recommend that you format the computer's hard disk and reinstall Windows
securely. For information about improving security of Windows-based computers
and servers, visit the following Microsoft Security Guidance Center

3. If the antivirus scan does not identify a malicious program on the system, it does
not mean that the computer is not infected by a malicious program. More likely, it
may mean that the malicious program is a new program or variant, and that the
 latest virus definitions do not detect it. In this case, contact the antivirus vendor to
report the problem, or open a support incident with Microsoft Product Support
Services (PSS) to investigate.

4. After you complete the antivirus scan, examine the computer for other malicious
programs, such as spyware or malicious user tools. See the "More Information"
section for links to spyware and to malicious user detection tools.

5. Microsoft provides third-party contact information to help you find technical

support. This contact information may change without notice. Microsoft does not
guarantee the accuracy of this third-party contact information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recovery process of a DFS Namespace
in Windows 2003 and 2008 Server
Article • 12/26/2023

This article describes the methods by which to recover a Distributed File System
Namespace (DFSN) in Windows Server.

Applies to: Windows Server 2012 R2

Original KB number: 969382

Rapid publishing
Rapid publishing articles provide information directly from within the Microsoft support
organization. The information contained herein is created in response to emerging or
unique topics, or is intended supplement other knowledge base information.

More information
The recovery process of a DFS Namespace depends on how the namespace
configuration data was lost, the type of Namespace (domain or standalone), and what
types of backups exist of the data. The data may have been inappropriately modified
through the DFS management tools, deleted directly within Active Directory or the
registry, or corrupted. Backups types of the configuration data include System-state
backups of a domain controller, backups of DFS Roots/Namespace servers, exported
data via the dfsutil.exe utility, and DFS service registry keys.

Background:

Before beginning the recovery process, determine if the loss of the DFS Namespace was
due to accidental administrative deletion of the namespace contents or by
loss/corruption of the DFS configuration data.

DFSN Recovery options:

Standalone DFSN
Registry data deleted?
Use system-state backup of Namespace server, see recovery option 1 of Standalone
DFS Root and Links
Use exported copy of the DFSN namespace using DFSUTIL, see recovery option 2 of
Standalone DFS Root and Links
 Recreate the DFS Namespace
Root or Link share deleted?
Use system-state backup of namespace server, see recovery option 1 of Shared
folders
Use saved share configuration registry data, see recovery option 2 of Shared fodlers

Domain DFSN
Active Directory configuration data is deleted?
Restore the Active Directory DFS configuration data from backup, see recovery
option 1 of Domain DFS Root and Links
Use exported copy of the DFSN domain namespace using DFSUTIL, see recovery
option 2 of DFS Root and Links
Recreate the namespace, see recovery option 3 of DFS Root and Links
Registry data deleted?
Use system-state backup of Namespace server to recover the registry
Recreate the namespace, see recovery option 3 of DFS Root and Links

Root or Link share deleted?

Use system-state backup of namespace server, see recovery option 1 of Shared
folders
Use saved share configuration registry data, see recovery option 2 of Shared fodlers

The following chart details how the data (Active Directory or registry of a DFS
namespace server) is impacted by various operations against a DFS namespace:

ﾉ Expand table

Namespace type Modification type Resulting configuration changes

Domain Domain DFS Root or Links Active Directory, Registry

Standalone Standalone Root/Link Registry

Domain/Standalone Shared folders File System, Registry

Utilize the dfsutil.exe utility to view the contents of the DFS configuration. Dfsutil is
available within the Windows Server 2003 and the Windows XP Support Tools package,
and it is included with Windows Server 2008 once the Distributed File System Role
Service is installed via Server Manager. The following data lists the configuration for the
DFS namespace/root named "DATA" after running the commands dfsutil
/root:\\contoso.com\DATA /view (on 2003) or dfsutil root \\contoso.com\DATA (on

2008):

DFS Utility Version 5.2 (built on 5.2.3790.3959)

Copyright (c) Microsoft Corporation. All rights reserved.

Domain Root with 1 Links [Blob Size: 704 bytes]

SiteCosting:ENABLED

Root Name="\CONTOSO\DATA" State="1" Timeout="300" Attributes="64"

Target Server="2003SERVER1" Folder="DATA" State="2"[Site: Default-First-Site-

Name]

Link Name="documentation" State="1" Timeout="1800"

Target Server="2003server1" Folder="documentation" State="2"[Site: Default-First-

Site-Name]

Target Server="2003server2" Folder="documentation" State="2"[Site: Default-First-

Site-Name]

Root with 1 Links [Blob Size: 704 bytes]

This DFS namespace contains a single folder/link called "Documentation" and contains
two folder/link targets, \\2003server1\documentation and
\\2003server2\documentation.

The DFS configuration Data queried by DFSUtil is stored within the following location
within Active Directory:

CN=Dfs-Configuration,CN=System,DC=<domain DN>

In Windows Server 2003, each Domain DFS Root/Namespace is stored within an "fTDfs"
object that contains an attribute "pKT" containing the configuration data (namespace
settings, namespace servers, folder targets, etc). For instance, the "DATA" namespace
listed in the dfsutil.exe output above is located with an fTDfs object at this location:
CN=DATA,CN=Dfs-Configuration,CN=System,DC=<domain DN>. No parts of this object
should ever be modified directly.

CN=Dfs-Configuration,CN=System,DC=<domain DN> |_fTDfs

In Windows Server 2008, Domain DFS Roots/Namespaces may be configured in

"Windows Server 2008 mode". In this mode, configuration data is stored under an
msDFS-NamespaceAnchor class object. An object of class "msDFS-Namespacev2"
represents each root, and each root contains an msDFS-Linkv2 object representing each
hosted link.

CN=Dfs-Configuration,CN=System,DC=<domain DN>
|_msDFS-NamespaceAnchor
|_msDFS-Namespacev2
|_msDFS-Linkv2

Each DFS Namespace/Root server utilizes registry data to identify the root(s) it hosts.
Without this information, the DFS service would not obtain the configuration data from
Active Directory and would fail to host the root(s).

For 2003/2008 domain-based DFS roots, this key stores the root associations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain

For "Windows Server 2008 mode" roots, the following key stores the root associations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\DomainV2

Within this key exists a subkey for each root hosted by the server and specifies the root
share via two values "LogicalShare" and "RootShare". The key for the "DATA" root would
be as follows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\DATA

For standalone DFS roots, configuration data isn't stored within Active Directory.
Configuration data is stored within the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone

Beneath the "Standalone" key exists subkeys for the specific standalone root(s) hosted
by the server, and within each, subkeys containing configuration data for the hosted
folders/links.
The file server shares specified by the "LogicalShare" and "RootShare" registry values
must exist and be accessible for proper operation of a DFS root. Access will be denied to
a root if the share is missing or is configured with inappropriate permissions. It is
recommended to never directly edit these registry values.

Backup:

To back up a DFS Namespace server, a system-state backup is required. The backup will
contain the registry configuration for the server's DFS service. If the domain-based
namespace server is also a domain controller, the system-state will also include a
backup of the Active Directory database, where domain-based DFS namespaces store
the configuration data. For namespace servers not running on domain controllers,
ensure at least one domain controller is backed up regularly to prevent the loss of
configuration data in the event a domain controller experiences a failure. Lastly, ensure
the DFS-related folders residing on the server are included within the backup.

For additional details about system-state backups and restorations, please see the
following articles:

Windows Server 2003

How Backup Works

Windows Server 2008

Windows Server Backup Step-by-Step Guide for Windows Server 2008

Note the typical shelf life of a system-state backup of Active Directory is only 60 days:
Useful shelf life of a system-state backup of Active Directory

An alternate method to save the DFS configuration data is via the DFSUtil.exe utility. The
output created via the "export" option may be used to recreate the missing DFS
configuration information lost through accidental deletion.

Recovery:

Once the scope of the modifications has been identified, the appropriate recovery
process should be performed.

Domain DFS Root and Links

Option 1 - Restore the Active Directory DFS configuration data from backup

For domain-based DFS, modification of a DFS root via a management tool has the
largest potential impact to the namespace. This is because whenever modifications are
performed via DFS API's, all root servers are notified of the changes and they will update
their registry as required. Thus, restoration of the DFS configuration within Active
Directory from backups may also require the task of recovering the registry of root
servers.

Authoritatively restore the DFS configuration blob. This requires the startup of a DC in
DS restore mode, restoring the Active Directory database from a backup that still
contains a valid copy of the DFS configuration, marking the DFS root directory object as
authoritative, and replicating this throughout the domain. DFS roots, by default, obtain
DFS configuration data from the PDC FSMO role owner domain controller. To prevent
replication latencies from impacting the time until the roots begin hosting the restored
namespace(s), consider using the PDC FSMO as the domain controller to restore.

The authoritative restoration process is detailed in the following article:

Performing an Authoritative Restore of Active Directory Objects

Performing an Authoritative Restore of Active Directory Objects

Restoring Active Directory:

Windows Server 2003:

Restore Active Directory from backup

1. Start the computer in Directory Services Restore Mode.

2. To start the Windows Server 2003 backup utility, click Start, point to All Programs,
point to Accessories, point to System Tools, and then click Backup.
3. On the Welcome to the Backup or Restore Wizard page, click Next.
4. Click Restore files and settings, and then click Next.
5. Select System State, and then click Next.
6. On the Completing the Backup or Restore Wizard page, click Advanced.
7. In Restore files to, click Original Location, and then click Next.
8. Click Leave existing files (Recommended), and then click Next.
9. Click Finish.
10. When the restore process is complete, click Close, and then click No to remain in
Directory Services Restore Mode.

７ Note

Do not reboot when prompted by the backup program. If a reboot is performed

and Active Directory replication takes place, the domain controller will replicate the
deletions again.

Windows Server 2008:

Performing a Nonauthoritative Restore of AD DS
 1. At the Windows logon screen, click Switch User, and then click Other User.

2. Type .\administrator as the user name, type the DSRM password for the server, and
then press ENTER.

3. Click Start, right-click Command Prompt, and then click Run as Administrator.

4. At the command prompt, type the following command, and then press ENTER:

Console

wbadmin get versions -backuptarget:\<targetDrive>:

-machine:\<BackupComputerName>

Where:

<targetDrive> is the location of the backup that you want to restore.

<BackupComputerName> is the name of the computer where you want to recover

the backup. This parameter is useful when you have backed up multiple computers
to the same location or you have renamed the computer since the backup was
taken.

5. Identify the version that you want to restore. You must enter this version exactly in
the next step.

6. At the command prompt, type the following command (wrapped for readability),
and then press ENTER:

Console

wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM>

-backuptarget:<targetDrive>: -machine:<BackupComputerName>

-quiet

Marking the DFS configuration data authoritative:

It is important to know the distinguished name of the namespace(s) to be restored so

that the DFS root object(s) may be marked authoritatively. It should be in the format
"CN=<rootname>,CN=DFS-Configuration,CN=System,DC=" and may need to be
enclosed in quotation marks if spaces exist within any labels.
 1. In Directory Services Restore Mode, click Start, click Run, type ntdsutil, and then
press ENTER.

2. At the ntdsutil: prompt, type authoritative restore, and then press ENTER.

3. To restore a subtree of objects, type the following command and then press
ENTER:

restore subtree DistinguishedName

For example, to restore all DFS Namespace objects in the domain contoso.com ,
type:

restore subtree "CN=Dfs-Configuration,CN=System,DC=contoso,dc=com"

２ Warning

All DFS namespaces will be affected by this operation, returning them to the
state contained in the backup.

To restore a single DFS Namespace object for a root named "DATA" in the domain
contoso.com , type:

restore subtree "CN=DATA,CN=Dfs-

Configuration,CN=System,DC=contoso,dc=com"

Restoring a subtree of objects ensures the operation will complete successfully for
both v1 and v2 namespaces.

4. Click Yes in the message box to confirm the command.

5. At the authoritative restore: and ntdsutil: prompts, type quit, and then press
ENTER.

6. Restart the domain controller in normal operating mode.

7. Allow Active Directory replication sufficient time to replicate the objects

throughout the domain.

Verify registry data on all DFS roots

Each domain DFS namespace/root server must have proper registry data under the
location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain in order to properly
host the restored DFS root(s). If the DFS namespace was deleted via a DFS management
tool, you may have to manually create the keys and "LogicalShare" and "RootShare"
values on each root. Once the registry data is in place, restart the DFS service on each
root to reinitialize DFS and obtain the restored configuration data.

For example, to create the "LogicalShare" and "RootShare" for a DFS Namespace named
"Data" whose shared folder for the root is named "DataShare", the following steps are
used:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain

3. Right-click Domain, point to New, and then click Key.

4. Type "Data" as the key name, and then press ENTER.
5. Right-click the "Data" key, point to New, and then click "String Value".
6. Type "LogicalShare" as the value name.
7. Right-click the "LogicalShare" value, and then click Modify.
8. In the Value data box, type "DataShare", and then click OK.
9. Right-click the "Data" key, point to New, and then click "String Value".
10. Type "RootShare" as the value name.
11. Right-click the "RootShare" value, and then click Modify.
12. In the Value data box, type "DataShare", and then click OK.

Option 2 - Import the DFS configuration if an export is available

An export of the DFS configuration consists of a text file generated via dfsutil.exe and
the following command:

Windows Server 2003:

Console

dfsutil /root:\\contoso.com\DATA /export:DATA-dfs-Root.txt

Windows Server 2008:

Console

dfsutil root export \\contoso.com\DATA DATA-dfs-root.txt

To recover a namespace via an export file, perform the following:

1. If the root doesn't already exist, create it using DFS Management. Add all
appropriate root targets. Dfsutil.exe will fail to import the configuration if the root
itself doesn't already exist and will not add root targets as defined in the file.
 However, you may review the contents of the export file to identify which root
targets should be manually added.

2. Import the configuration file to create all of the hosted links via the commands:
Windows Server 2003:

Console

dfsutil /root:\\contoso.com\DATA /import: DATA-dfs-Root.txt

Windows Server 2008:

Console

dfsutil root import set DATA-dfs-Root.txt \\contoso.com\DATA

(Where the domain is contoso.com , "DATA" is the root's name, and DATA-dfs-
Root.txt is the export file)

Attempting the import before the root has been created will result in the error
"Element not found."

Attempting to add a root target that already has registry configuration data
associated with the root results in the errors "The device is not ready for use" or
"Cannot create a file when that file already exists." To remove the registry data
from the affected server, utilize the "clean" option within DFSUtil:

Windows Server 2003:

Console

dfsutil /clean /server:<servername> /share:<sharename>

Windows Server 2008:

Console

dfsutil diag clean \\<servername>\<sharename>

3. Verify the import was successful. You may have to reopen any DFS management
tools to observe the imported links.

Option 3 - Recreate the Namespace(s)

It may be easier to recreate the namespaces as required. This activity will update the
configuration within Active Directory and the registry of the roots. If adding a server as a
root fails to indicate the root is already hosted by the server, check the registry
configuration of the server to ensure that it doesn't already have configuration data for
the original root. To remove such data, run the following command:

Console

dfsutil /clean /server:servername /share:sharename

(Where "servername" is the server that needs to be added as a new root target and
"sharename" is the name of the share to host the root)

On Windows Server 2008:

Console

dfsutil diag clean \\servername\sharename

Active Directory fTDfs object

If the ftDfs object within Active Directory was directly deleted, restore the object as
detailed in Option 1 of the "Domain DFS Root and Links" section. There should be no
need to repair missing registry data, as a direct deletion of the fTDfs object is performed
without using DFS API's and no notifications sent to the DFS roots of the deletion.

If an export of the DFS configuration exists, the process will be similar to that in Option
2 of the "Domain DFS Root and Links" section.

Lastly, you may also recreate the DFS namespace, ensuring each DFS root has been
properly cleaned of the previous configuration. See Option 3 of the "Domain DFS Root
and Links" section for more details.

Standalone DFS Root and Links

Option 1 - Restore the Standalone DFS configuration data from backup

If a standalone DFS namespace/root server experiences configuration data loss, it is

recommended to restore the system-state of the server from backup. This operation will
automatically restore the configuration data to the proper state. Attempting to modify
the registry of a standalone DFS root is not recommended.

Option 2 - Import the DFS configuration if an export is available

If a DFSUTIL.EXE export exists for the root, it may be imported via the commands:
Windows Server 2003:

Console

dfsutil /root:\\server-name\namespace-name /import: DATA-dfs-Root.txt

Windows Server 2008:

Console

dfsutil root import set DATA-dfs-Root.txt \\contoso.com\DATA

Option 3 - Recreate the Namespace(s)

It may be easier to recreate the standalone namespace(s) as required.

Shared folders

If a domain-based or a standalone DFS namespace server experiences loss of a DFS

share and the DFS configuration remains, the shares must be recovered to restore DFS
functionality.

Option 1 - Restore the Standalone DFS configuration data from backup

Restore the system-state from a backup made prior to the loss. The system-state
includes the registry data for the server to host the shares. Ensure the folder(s) for the
share(s) also are present on the server.

Option 2 - Recover the share configuration data from the registry

If a system-state backup of a DFS Namespace server is not available but share registry
information exists, this information may be used to restore the share configuration of
the server. Shares and assigned share permissions are stored in the following registry
key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

To save this registry key using the registry editor, click Export on the File menu.

This registry key may be imported to the DFS Namespace server or used as a reference
of the share names and location of shared folders for manual creation.

To restore or import the registry key using the registry editor, click Import on the File
menu.
Once the shares have been recovered, restart the Namespace server's DFS service to
initialize the namespace.

Disclaimer
Microsoft and/or its suppliers make no representations or warranties about the
suitability, reliability or accuracy of the information contained in the documents and
related graphics published on this website (the "materials") for any purpose. The
materials may include technical inaccuracies or typographical errors and may be revised
at any time without notice.

To the maximum extent permitted by applicable law, microsoft and/or its suppliers
disclaim and exclude all representations, warranties, and conditions whether express,
implied or statutory, including but not limited to representations, warranties, or
conditions of title, non infringement, satisfactory condition or quality, merchantability
and fitness for a particular purpose, with respect to the materials.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Robocopy may report error 1338 (The
security descriptor structure is invalid)
or error 87 (The parameter is incorrect)
when you copy data from CIFS file
servers
Article • 12/26/2023

This article provides a solution to fix error 1338 or error 87 that occurs when you copy
files and their associated file security from a CIFS file server.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 2459083

Symptoms
Robocopy may report one the following errors for some files, when copying files and
their associated file security from a CIFS file server:

yyyy/mm/dd hh:mm:ss ERROR 1338 (0x0000053A) Copying NTFS Security to

Destination File <file pathname>
The security descriptor structure is invalid.

yyyy/mm/dd hh:mm:ss ERROR 87 (0x00000057) Copying NTFS Security to

Destination File <file pathname>
The parameter is incorrect.

The error only occurs when copying file security, for example, by specifying /SEC or
/COPYALL on the Robocopy command line. If file security is not copied, all files are

copied successfully, and no errors are reported.

Cause
The error is caused by the CIFS file server returning invalid security information for a file.
For example, if the CIFS file server returns a NULL Security ID (SID) for a file's Owner, or a
file's Primary Group, when Robocopy tries to copy this information to the destination
file, Windows will return error 87 The parameter is incorrect or error 1338 The security
descriptor is invalid. This is by design - file security information in Windows is expected
to contain both Owner and Primary Group SIDs.

Resolution
On the CIFS file server, use the appropriate tools to correct the security information for
affected files, and ensure that all affected files have both an Owner SID and a Primary
Group SID.

More information
This is by design - file security information in Windows is expected to contain both
Owner and Primary Group SIDs. For more information about Security Descriptors and
Access Control Lists:

How Security Descriptors and Access Control Lists Work

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Slow SMB files transfer speed
Article • 12/26/2023

Server Message Block (SMB) file transfer speeds can slow down depending on the size
and quantity of your files, your connection type, and the version of apps you use. This
article provides troubleshooting procedures for slow file transfer speeds through SMB.

Slow transfer
You can troubleshoot slow file transfers by checking your current storage use. If you
observe slow transfers of files, consider the following steps:

Try the file copy command for unbuffered IO:

xcopy /J

robocopy /J

Test the storage speed. Copy speeds are limited by storage speed.

File copies sometimes start fast and then slow down. A change in copy speed
occurs when the initial copy is cached or buffered, in memory or in the RAID
controller's memory cache, and the cache runs out. This change forces data to be
written directly to disk (write-through).

To verify this situation, use storage performance monitor counters to determine

whether storage performance degrades over time. For more information, see
Performance tuning for SMB file servers.

Use RAMMap (SysInternals) to determine whether "Mapped File" usage in memory

stops growing because of free memory exhaustion.

Look for packet loss in the trace. Packet loss can cause throttling by the TCP
congestion provider.

For SMBv3 and later versions, verify that SMB Multichannel is enabled and
working.

On the SMB client, enable large MTU in SMB, and disable bandwidth throttling by
running the following cmdlet:

PowerShell

Set-SmbClientConfiguration -EnableBandwidthThrottling 0 -EnableLargeMtu

 1

Slow transfer of small files

A slow transfer of small files occurs most commonly when there are many files. This
occurrence is an expected behavior.

During file transfer, file creation causes both high protocol overhead and high file
system overhead. For large file transfers, these costs occur only one time. When a large
number of small files are transferred, the cost is repetitive and causes slow transfers.

Issue details
Network latency, create commands, and antivirus programs contribute to a slower
transfer of small files. The following are technical details about this problem:

SMB calls a create command to request that the file is created. Code checks
whether the file exists and then creates the file. Otherwise, some variation of the
create command creates the actual file.

Each create command generates activity on the file system.

After the data is written, the file is closed.
The process can suffer from network latency and SMB server latency. This latency
occurs because the SMB request is first translated to a file system command and
then to the actual file system to complete the operation.
The transfer continues to slow while an antivirus program is running. This change
happens because the data is typically scanned once by the packet sniffer and a
second time when the data is written to disk. In some scenarios, these actions are
repeated thousands of times. You can potentially observe speeds of less than 1
MB/s.

Slow open of Office documents

Office documents can open slowly, which generally occurs on a WAN connection. The
manner in which Office apps (Microsoft Excel, in particular) access and read data is
typically what causes the documents to open slowly.

You should verify that the Office and SMB binaries are up-to-date, and then test by
having leasing disabled on the SMB server. To verify both conditions have resolved,
follow these steps:
 1. Run the following PowerShell cmdlet in Windows 8 and Windows Server 2012 or
later versions of Windows:

PowerShell

Set-SmbServerConfiguration -EnableLeasing $false

You can also run the following command in an elevated Command Prompt
window:

Console

REG ADD
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\param
eters /v DisableLeasing /t REG\_DWORD /d 1 /f

７ Note

After you set this registry key, SMB2 leases are no longer granted, but oplocks
are still available. This setting is used primarily for troubleshooting.

2. Restart the file server or restart the Server service. To restart the service, run the
following commands:

Console

NET STOP SERVER

NET START SERVER

To avoid this issue, you can also replicate the file to a local file server. For more
information, see saving Office documents to a network server is slow when using EFS.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SMB multichannel troubleshooting
Article • 12/26/2023

This article describes how to troubleshoot issues that are related to SMB multichannel.

Check the network interface status

Make sure that the binding for the network interface is set to True on the SMB client
(MS_client) and SMB server (MS_server). When you run the following cmdlet, the output
should show True under Enabled for both network interfaces:

PowerShell

Get-NetAdapterBinding -ComponentID ms_server,ms_msclient

After that, make sure the network interface is listed in the output of the following
cmdlets:

PowerShell

Get-SmbServerNetworkInterface

PowerShell

Get-SmbClientNetworkInterface

You can also run the Get-NetAdapter cmdlet to view the interface index to verify the
result. The interface index shows all the active SMB adapters that are actively bound to
the appropriate interface.

Check the firewall

If there's only a link-local IP address, and no publicly routable address, the network
profile is likely set to Public. This means that SMB is blocked at the firewall by default.

The following cmdlet reveals which connection profile is being used. You can also use
the Network and Sharing Center to retrieve this information.

PowerShell
 Get-NetConnectionProfile

Under the File and Printer Sharing group, check the firewall inbound rules to make sure
that SMB-In is enabled for the correct profile.

You can also enable File and Printer Sharing in the Network and Sharing Center
window. To do this, select Change advanced sharing settings in the menu on the left,
and then select Turn on file and printer sharing for the profile. This option enables the
File and Printer Sharing firewall rules.

Capture client and server sided traffic for

troubleshooting
You need the SMB connection tracing information that starts from the TCP three-way
handshake. We recommend that you close all applications (especially Windows Explorer)
before you start the capture. Restart the Workstation service on the SMB client, start the
packet capture, and then reproduce the issue.

Make sure that the SMBv3.x connection is being negotiated, and that nothing in
between the server and the client is affecting dialect negotiation. SMBv2 and earlier
versions don't support multichannel.

Look for the NETWORK_INTERFACE_INFO packets. This is where the SMB client requests a list
of adapters from the SMB server. If these packets aren't exchanged, multichannel
doesn't work.

The server responds by returning a list of valid network interfaces. Then, the SMB client
adds those to the list of available adapters for multichannel. At this point, multichannel
should start and, at least, try to start the connection.

For more information, see:

3.2.4.20.10 Application Requests Querying Server's Network Interfaces

2.2.32.5 NETWORK_INTERFACE_INFO Response
3.2.5.14.11 Handling a Network Interfaces Response

In the following scenarios, an adapter can't be used:

There's a routing issue on the client. This is typically caused by an incorrect routing
table that forces traffic over the wrong interface.
Multichannel constraints have been set. For more information, see New-
SmbMultichannelConstraint.
Something blocked the network interface request and response packets.
The client and server can't communicate over the extra network interface. For
example, the TCP three-way handshake failed, the connection is blocked by a
firewall, session setup failed, and so on.

If the adapter and its IPv6 address are on the list that is sent by the server, the next step
is to see whether communications are tried over that interface. Filter the trace by the
link-local address and SMB traffic, and look for a connection attempt. If this is a
NetConnection trace, you can also examine Windows Filtering Platform (WFP) events to

see whether the connection is being blocked.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive a "System error 67 has
occurred. The network name cannot be
found" error message
Article • 12/26/2023

This article helps to fix the error message "System error 67 has occurred. The network
name cannot be found".

Applies to: Windows Server 2012 R2

Original KB number: 843156

Symptoms
If you try to log on to a computer by using your domain account, the domain controller
stops responding. Additionally, you cannot access your folder by using the universal
naming convention (UNC) network path, and you receive the following error message:

System error 67 has occurred. The network name cannot be found

Cause
This issue occurs if one of the following conditions is true:

The network components on the domain controller are not configured correctly.
You did not update the network drivers on the domain controller or the drivers
don't work with Microsoft Windows Server 2003.

Resolution
To resolve this issue, use either of the following methods.

Method 1
Update the network adaptor driver on the domain controller.

７ Note
 Make sure that you use a network adaptor driver that works with the operating
system that you are using.

Method 2
If Network Address Translator (NAT) is installed but is not configured correctly, disable
the Internet Protocol (IP) NAT driver, and then restart the computer. You can follow
these steps:

1. Click Start, right-click My Computer, and then click Properties.

2. On the Hardware tab, click Device Manager.
3. On the View menu, click Show hidden devices.
4. Expand Non-Plug and Play Drivers, right-click IP Network Address Translator, and
then click Disable.
5. Click Yes two times to restart the computer.

Workaround
To work around this issue, restart the Distributed File System service on the domain
controller.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

"Logon failure: account currently
disabled" and "System error 1331" error
messages
Article • 12/26/2023

This article provides a solution to the system error 1331 that occurs when you connect
to a share.

Applies to: Windows Server 2012 R2

Original KB number: 263936

Symptoms
When you attempt to connect to a share, you may receive the following error message:

Share path/Name is not accessible.

Logon failure: account currently disabled.

The computer may also display a "System error 1331" error message, which is the
equivalent of the preceding "Logon failure: account currently disabled" error message.

７ Note

There are no events logged in Event Viewer that are related to these errors.

Cause
This problem can occur when you attempt to access a share that is located on a
computer in a domain (either parent or child) from another domain, or when you
attempt to gain access to a share that is located in the same domain.

This problem occurs most commonly when a Windows computer that has been a
member of one domain is moved to another domain. The computer account for the
computer that has been moved displays a red "X". For this problem to occur in a single-
domain environment, the computer account had to have been set to disabled.

Resolution
To resolve this problem, delete the disabled computer account in Active Directory Users
and Computers.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

More information
The resolution in this article has also been documented to resolve the problem that
causes the following error message:

Access is denied; account is currently disabled.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

TCP connection is aborted during
Validate Negotiate
Article • 12/26/2023

In the network trace for the SMB issue, you notice that a TCP Reset abort occurred
during the Validate Negotiate process. This article describes how to troubleshoot the
situation.

Cause
This issue can be caused by a failed negotiation validation. This typically occurs because
a WAN accelerator modifies the original SMB Negotiate packet.

Microsoft no longer allows modification of the Validate Negotiate packet for any reason.
This is because this behavior creates a serious security risk.

The following requirements apply to the Validate Negotiate packet:

The Validate Negotiate process uses the FSCTL_VALIDATE_NEGOTIATE_INFO

command.
The Validate Negotiate response must be signed. Otherwise, the connection is
aborted.
You should compare the FSCTL_VALIDATE_NEGOTIATE_INFO messages to the
Negotiate messages to make sure that nothing was changed.

Workaround
You can temporarily disable the Validate Negotiate process. To do this, locate the
following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Under the Parameters key, set RequireSecureNegotiate to 0.

In Windows PowerShell, you can run the following cmdlet to set this value:

PowerShell

Set-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters"
RequireSecureNegotiate -Value 0 -Force
 ７ Note

The Validate Negotiate process can't be disabled in Windows 10, Windows Server
2016, or later versions of Windows.

If either the client or server can't support the Validate Negotiate command, you can
work around this issue by setting SMB signing to be required. SMB signing is considered
more secure than Validate Negotiate. However, there can also be performance
degradation if signing is required.

Reference
3.3.5.15.12 Handling a Validate Negotiate Info Request
3.2.5.14.12 Handling a Validate Negotiate Info Response

Feedback
Was this page helpful?  Yes  No

Provide product feedback

TCP three-way handshake failure during
SMB connection
Article • 12/26/2023

This article describes how to troubleshoot Transmission Control Protocol (TCP) three-
way handshake failure during SMB connection.

When you analyze a network trace, you notice that there's a TCP three-way handshake
failure that causes the SMB issue to occur.

Generally, the cause is a local or infrastructure firewall that blocks the traffic. This issue
can occur in either of the following scenarios.

The TCP SYN packet arrives on the SMB server,

but the SMB server doesn't return a TCP SYN-
ACK packet
To troubleshoot this scenario, follow these steps：

1. Run netstat or Get-NetTcpConnection to make sure that there's a listener on TCP

port 445 that should be owned by the SYSTEM process.

Console

netstat -ano | findstr :445

PowerShell

Get-NetTcpConnection -LocalPort 445

2. Make sure that the Server service is started and running.

3. Take a Windows Filtering Platform (WFP) capture to determine which rule or

program is dropping the traffic. To do this, run the following command in a
Command Prompt window:

Console

netsh wfp capture start

 Reproduce the issue, and then, run the following command:

Console

netsh wfp capture stop

Run a scenario trace, and look for WFP drops in SMB traffic (on TCP port 445).

Optionally, you could remove the anti-virus programs because they aren't always
WFP-based.

4. If Windows Firewall is enabled, enable firewall logging to determine whether it

records a drop in traffic.

Make sure that the appropriate "File and Printer Sharing (SMB-In)" rules are
enabled in Windows Firewall with Advanced Security > Inbound Rules.

７ Note

Depending on how your computer is set up, "Windows Firewall" might be

called "Windows Defender Firewall."

The TCP SYN packet never arrives at the SMB

server
In this scenario, you have to investigate the devices along the network path. You may
analyze network traces that are captured on each device to determine which device is
blocking the traffic.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Distributed File System
Namespace access failures in Windows
Article • 12/26/2023

This article provides a solution to solve Distributed File System Namespace (DFSN)
access failures.

Applies to: Windows 10 - all editions, Windows Server 2012 R2

Original KB number: 975440

Symptoms
On a computer that is running Windows XP or Window Server 2003, when you try to
access to a DFSN, you receive the following error message:

\\<Domain Name>\<DFS Namespace> is not accessible. You might not have

permission to use this network resource. Contact the administrator of this server to
find out if you have access permissions.

Configuration information could not be read from the domain controller, either
because the machine is unavailable, or access has been denied.

On Windows Vista and later versions of Windows, you may receive one of the following
error messages:

Windows cannot access \\<Domain Name>\<DFS Namespace>

The Network Path was not found

Cause
This error typically occurs because the DFSN client cannot complete the connection to a
DFSN path.

The connection may fail because of any of the following reasons:

Failure to connect to a domain controller to obtain a DFSN namespace referral

Failure to connect to a DFSN server
Failure of the DFSN server to provide a folder referral
Resolution
To resolve this problem, you must evaluate network connectivity, name resolution, and
DFSN service configuration. You can use the following methods to evaluate each of
these dependencies.

Connectivity
In this article, connectivity refers to the client's ability to contact a domain controller or a
DFSN server. If a client cannot complete a network connection to a domain controller or
to a DFSN server, the DFSN request fails.

You can use the following tests to verify connectivity.

Determine whether the client was able to connect to a domain controller for domain
information by using the DFSUtil.exe /spcinfo command. The output of this command
describes the trusted domains and their domain controllers that are discovered by the
client through DFSN referral queries. This is known as the Domain Cache.

In the following example, both the DNS domain name contoso.com and the NetBIOS
domain name CONTOSO are discovered by the client. Two domain controllers were
identified for the domain name CONTOSO: 2003server2 and 2003server1. If the client
accesses the DNS name contoso.com in a request, the entries are displayed under the
contoso.com entry.

Output

[*][2003server1.contoso.com]
[*][CONTOSO]
[*][contoso.com]
[+][CONTOSO]
[-2003server2]
[+2003server1]
[-][contoso.com]

Entries that are marked by an asterisk (*) were obtained through the Workstation
service. The other entries were obtained through referrals by the DFSN client. The
entries that are marked by a plus sign (+) are the domain controllers that are currently
used by the client. For more information about referral processes, see How DFS Works.

To evaluate connectivity, try a simple network connection to the active domain

controller by using its IP address. For example, type either of the following commands:

start \\192.168.1.11
 net view \\192.168.1.11

A successful connection lists all shares that are hosted by the domain controller.

If the connection is successful, determine whether a valid DFSN referral is returned to

the client after it accesses the namespace. You can do this by viewing the referral cache
(also known as the PKT cache) by using the DFSUtil.exe /pktinfo command.

The following output details the expected entries within the client's referral cache after
the client accesses the DFSN path \\contoso.com\dfsroot\link . The root has two targets
(rootserver1 and rootserver2). The link has a single target (fileserver).

Output

Entry: \contoso.com\dfsroot
ShortEntry: \contoso.com\dfsroot
Expires in 300 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
0:[\ROOTSERVER1\dfsshare] State:0x119 ( ACTIVE )
1:[\ROOTSERVER2\dfsshare] State:0x09 ( )

Entry: \contoso.com\dfsroot\link
ShortEntry: \contoso.com\dfsroot\link
Expires in 1800 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\fileserver\data] State:0x131 ( ACTIVE )

If you cannot find an entry for the desired namespace, this is evidence that the domain
controller did not return a referral. DFSN service failures are discussed later in this
article.

If you see an entry for the namespace (that is, \contoso.com\dfsroot ), the entry proves
that the client was able to contact a domain controller, but then did not reach any DFSN
namespace targets. If not any of the namespace targets that are listed are designated as
ACTIVE, that indicates that all targets were unreachable.

Try to access to each namespace server by using IP addresses. For this test, you must
specify only the IP address of the server, and you must not include the namespace share
(that is, net view \\192.168.1.11 but not net view \\192.168.1.11\dfsroot ). Otherwise,
you may unknowingly be referred to another DFS root server. If this occurs, you will
receive misleading results. Note any error messages that are reported during these
actions.

You must investigate and resolve any failures of a domain controller or of DFS
namespace server communications. For more information about TCP/IP networking
details and about troubleshooting utilities, see TCP/IP Technical Reference.
Name resolution
Clients must resolve the name of the DFS namespace and of any servers that are hosting
the namespace. Review the output that was previously generated by the dfsutil
/pktinfo and dfsutil /spcinfo commands. The server names that are listed must be

resolved by the client to IP addresses.

You can use the following methods to verify proper name resolution functionality.

WINS and NetBIOS names

NetBIOS name resolution failures may occur because name records are missing or
because you received the wrong IP address for the name. To test this, try to access
the domain controller by using only its NetBIOS computer name (that is, by using
the command net view \\2003server1 ). Then, verify that the shares that are listed
are those that are expected to be hosted by the server. As an administrator, you
can view the client's NetBIOS name cache by using the nbtstat -c command to
review all resolved names and their IP addresses. Consider the following example.

ﾉ Expand table

Name NetBIOS Remote Type Cache Name Table Host Address Life [sec]

2003server1 <00> UNIQUE 192.168.1.11 462

Review the following documents to troubleshoot WINS failures:

Troubleshooting WINS servers
Troubleshooting WINS clients

DNS names

By default, DFSN stores NetBIOS names for root servers. DFSN can also be
configured to use DNS names for environments without WINS servers. For more
information, see How to configure DFS to use fully qualified domain names in
referrals .

You can view the client's DNS resolver cache to verify resolved DNS names. To do
this, open a command prompt, and type the ipconfig /displaydns command.

Consider the following example.

Windows IP Configuration

2003server1
 Record Name . . . . . : 2003server1.contoso.com
Record Type . . . . . : 1
Time To Live . . . . : 882
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.1.11

Review the following documents to troubleshoot DNS failures:

Troubleshooting DNS clients
Troubleshooting DNS servers

Network capture

A network capture may help you diagnose a name resolution failure. Before you
perform a capture, flush cached naming information on the client. If you do this,
you will not expose any problems that may exist in the capture because cached
referral data or names will not be requested again over the network. To flush the
name caches, run the following commands in this order:
nbtstat -RR
ipconfig /flushdns

dfsutil /pktflush
dfsutil /spcflush

For more information about the Microsoft Network Monitor 3, see Information about
Network Monitor 3 .

For more information about the network traffic that is observed between a client and a
domain-based DFS environment, see How DFS Works.

For more information about DNS and WINS, see Name Resolution Technologies.

DFS and system configuration

Even when connectivity and name resolution are functioning correctly, DFS
configuration problems may cause the error to occur on a client. DFS relies on up-to-
date DFS configuration data, correctly configured service settings, and Active Directory
site configuration.

First, verify that the DFS service is started on all domain controllers and on DFS
namespace/root servers. If the service is started in all locations, make sure that no DFS-
related errors are reported in the system event logs of the servers.
When an administrator makes a change to the domain-based namespace, the change is
made on the Primary Domain Controller (PDC) emulator master. Domain controllers and
DFS root servers periodically poll PDC for configuration information. If the PDC is
unavailable, or if "Root Scalability Mode" is enabled, Active Directory replication
latencies and failures may prevent servers from issuing correct referrals. For more
information about Root Scalability Mode, see Reviewing DFS Size Recommendations.

One method to evaluate replication health is to interrogate the status of the last
inbound replication attempt for each domain controller. To do this, run the
repadmin.exe command. The required syntax for this command is as follows:

repadmin /showrepl * DN_of_domain

７ Note

In this command, * represents all domain controllers that are to be queried, and
DN_of_domain represents the distinguished name of the domain, such as
dc=contoso,dc=com.

Review the status and time of the last successful replication to make sure that DFSN
configuration changes have reached all domain controllers. You should investigate any
failures that are reported for inbound replication to a DC.

DFSN configuration problems may also prevent access to the namespace. One common
scenario in which this occurs is a client that belongs to a site that contains no
namespace or folder targets. If the namespace is configured to issue referral targets only
within the client's site (the insite option), DFSN will not provide a referral. To evaluate
whether the insite option is configured on a namespace, open a command prompt, and
then type the dfsutil /path:\\contoso.com\dfs /insite /display command.

Similarly, Active Directory site configuration problems may prevent DFSN servers from
correctly determining the client site. Therefore, these problems may cause referral
failures if insite is configured. The DFSN service maps the client to a site by analyzing the
source IP address of the client's referral request. The DFS service also maps each root
target server to a site by resolving the target server's name to an IP address. To evaluate
whether a domain controller or a DFS root can determine the correct site of the system,
run either of the following commands locally on the domain controllers and on the DFS
namespace server:

dfsutil /sitename:root_target_name

dfsutil /sitename:client_ip_address
References
Designing the Site Topology

How DFS Works

Updated namespace terminology

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DFS Namespace troubleshooting
guidance
Article • 12/26/2023

Try our Virtual Agent - It can help you quickly identify and fix common DFS-

Namespace issues.

Distributed File System (DFS) Namespace is a Windows technology designed to provide

distributed namespace access to file shares across an enterprise.

Troubleshooting checklist
Examine the SMB traffic to see if the issue is with getting the referral list from the
namespace server or connecting to the referred file server. To do so, follow these steps:

First, filter the trace by the SMB traffic for the DFS Namespace IP address. Example filter:
tcp.port==445 .

Then, look for the DFS referral. Follow these steps:

1. The protocol is named DFSC by packet capture parsers. Look for the DFSC traffic in
the filtered results or append the filter with DFSC in netmon or MA: tcp.port==445
and DFSC .

2. The client should send a DFS referral request to the DFS Namespace server. If no
DFS referral is being sent, and there's no indication of a firewall or anti-virus block,
restart the DFS client to clear any DFS referral caching. Then, start the data
collection steps over again.

3. The server should send a DFS referral response to the DFS client.

4. The referral step has completed successfully if a referral list has been returned. Skip
to step 4 if the referral process completed successfully.

5. Verify whether the DFS Referral Request arrived at the DFS Namespace server.
Standard TCP/IP and firewall troubleshooting applies if the referral doesn't arrive.
The most likely cause is the traffic being dropped or blocked somewhere.

If the referral request arrives but no response is sent:

a. Make sure the Windows Firewall or another network security application isn't
blocking the request.
 b. Verify Active Directory works correctly to troubleshoot the DFS Namespace
server.

Look for the DFS client to resolve DNS (assuming it isn't cached) and make a connection
to a file server.

1. It's possible that Windows won't attempt to contact a referral if there are other
networking issues, such as a DNS resolution failure.
2. To ensure that Windows will perform DNS resolution, you can flush the DNS cache
after starting the trace and before reproducing the issue. This operation allows you
to verify that DNS resolution is working correctly.
a. In Windows 8 and later versions of Windows, use PowerShell cmdlet: Clear-
DnsClientCache .

b. For previous versions of Windows, run command: ipconfig flushdns .

SMB troubleshooting applies to fixing the file server connection.

Common issues and solutions

Unsupported DFSN deployment scenario
Recovery process of a DFSN
Troubleshoot DFSN access failures
Fail to create a DFSN
DFSNs service and its configuration data

Data collection
Before contacting Microsoft support, you can gather information about your issue.

Prerequisites
1. TSS must be run by accounts with administrator privileges on the local system, and
EULA must be accepted (once EULA is accepted, TSS won't prompt again).
2. We recommend the local machine RemoteSigned PowerShell execution policy.

７ Note

If the current PowerShell execution policy doesn't allow running TSS, take the
following actions:
 Set the RemoteSigned execution policy for the process level by running the
cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy
RemoteSigned .

To verify if the change takes effect, run the cmdlet PS C:\> Get-
ExecutionPolicy -List .

Because the process level permissions only apply to the current PowerShell
session, once the given PowerShell window in which TSS runs is closed, the
assigned permission for the process level will also go back to the previously
configured state.

Gather key information before contacting Microsoft

support
1. Download TSS on all nodes and unzip it in the C:\tss folder.

2. Open the C:\tss folder from an elevated PowerShell command prompt.

3. Start the traces on the client and the server by using the following cmdlets:

Client:

PowerShell

TSS.ps1 -Scenario NET_DFScli

Server:

PowerShell

TSS.ps1 -Scenario NET_DFSsrv

4. Accept the EULA if the traces are run for the first time on the server or the client.

5. Allow recording (PSR or video).

6. Reproduce the issue before entering Y.

７ Note
 If you collect logs on both the client and the server, wait for this message on
both nodes before reproducing the issue.

7. Enter Y to finish the log collection after the issue is reproduced.

The traces will be stored in a zip file in the C:\MS_DATA folder, which can be uploaded to
the workspace for analysis.

Reference
Frequently Asked Questions

Distributed File System: Namespace Availability Questions

Distributed File System: Namespace Client Questions
Distributed File System: Namespace Management Questions
Distributed File System: Namespace Scalability and Sizing Questions
Distributed File System: Namespace Server Questions
Distributed File System: Namespace Site Discovery and Target Questions

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SMB troubleshooting guidance
Article • 03/16/2024

Try our Virtual Agent - It can help you quickly identify and fix common SMB issues.

This article is designed to help you troubleshoot Server Message Block (SMB) issues.
Most users are able to resolve their issue by using the solutions that are provided here.

SMB terminology
Communicating correct terminology is a key aspect of quality SMB troubleshooting.
Therefore, you should learn basic SMB terminology to ensure the accuracy of data
collection and analysis.

SMB Server (SRV) (also known as the file server) is always the system that hosts the
file system.
SMB Client (CLI) is always the system that tries to access the file system.

These terms are consistent regardless of the operating system version or edition. For
example, if a Windows Server 2016-based computer tries to reach the SMB share
\\MyWorkstation\Data on a Windows 10-based computer, Windows Server 2016 is the
SMB Client and Windows 10 is the SMB Server.

Troubleshooting checklist
Check that the correct SMB network protocol is installed. The SMBv1 network
protocol is no longer installed by default.
Disable SMBv1.
If SMBv1 is disabled on a device that supports only SMBv1, you can't access that
device. In this situation, upgrade your system.
You can't disable SMBv2 or SMBv3 separately because these versions are part of
the same driver.
Analyze the traffic: SMB is an application-level protocol that uses TCP/IP as the
network transport protocol. Therefore, an SMB-related issue might indicate that
there are underlying TCP/IP-related issues.
Analyze the protocol: To understand the exact commands and options that are
used, look at the actual SMB protocol details in the network trace.
Update SMB-related system files: Keep the system files updated. Make sure that
the latest update rollup is installed.
SMB file information
SMB Client binaries that are listed under %windir%\system32\Drivers:

RDBSS.sys
MRXSMB.sys
MRXSMB10.sys
MRXSMB20.sys
MUP.sys
SMBdirect.sys

SMB Server binaries that are listed under %windir%\system32:

Srvsvc.dll

SMB Server binaries that are listed under %windir%\system32\Drivers:

SRVNET.sys
SRV.sys
SRV2.sys
SMBdirect.sys

We recommend that you update the following components before you troubleshoot
SMB issues:

iSCSI: A file server requires file storage. If your storage has iSCSI components,
update those components.
Network: Update the network components.
Windows Core: For better performance and stability, update Windows Core.

Disconnecting all shared resources from local

computer
You can use the Net Use * /delete command to disconnect active or remembered
shared resources on a local computer.

７ Note

You can use this command on remote computers, also. Run Net help use for more
options.
 ） Important

This section of this article is based on community content.

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations

about the suitability, reliability, or accuracy of the information and related graphics
contained herein. All such information and related graphics are provided "as is"
without warranty of any kind. Microsoft and/or its respective suppliers hereby
disclaim all warranties and conditions with regard to this information and related
graphics, including all implied warranties and conditions of merchantability, fitness
for a particular purpose, workmanlike effort, title and non-infringement. You
specifically agree that in no event shall Microsoft and/or its suppliers be liable for
any direct, indirect, punitive, incidental, special, consequential damages or any
damages whatsoever including, without limitation, damages for loss of use, data or
profits, arising out of or in any way connected with the use of or inability to use the
information and related graphics contained herein, whether based on contract, tort,
negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has
been advised of the possibility of damages.

Common issues and solutions

When you access a Scale-Out File Server, performance is

limited
The client access network uses high-speed remote direct memory access (RDMA), but
the cluster network doesn't. Because of this behavior, redirection occurs only on the
cluster network. The cluster network typically connects to 1-GbE network adapters.

To troubleshoot this issue, you can configure the option to use the client access network
for Cluster Shared Volumes (CSV). Or, upgrade to Windows Server 2012 R2 or a later
version. That system automatically redirects clients to the cluster node that has the best
access to the volume of the file share. For more information, see the following Blog
Archive article: Automatic SMB Scale-Out Rebalancing in Windows Server 2012 R2.

SMB prefers the slower physical network adapter to the

virtual network adapter
The virtual network adapter on the host isn't RSS-capable. The physical network adapter
is RSS-capable. SMB always uses the RSS-capable network adapter instead of the non-
RSS network adapter even if the RSS network adapter is slower.

To troubleshoot this issue, disable the RSS capability on the physical network adapter, or
use SMB Multichannel constraints to restrict SMB communication to one or more
defined network interfaces. For more information, see the New-
SmbMultichannelConstraint SMB Share cmdlet in Windows PowerShell.

SMB reports the network adapter isn't RDMA-capable

even though you believe that it is
This issue occurs because RDMA-capable network adapters that have older drivers or
firmware might not correctly identify themselves as being RDMA-capable.

To troubleshoot this issue, update the network adapter firmware and driver from the
manufacturer's website.

The required amount of network traffic before SMB

Multichannel starts varies
The SMB Multichannel feature is used to discover the RSS and RDMA capabilities of
network adapters. On server operating systems, SMB Multichannel starts when the initial
read or write operation occurs. On client operating systems, SMB Multichannel doesn't
start until a certain amount of network traffic occurs.

On server operating systems, SMB Multichannel starts quickly only one time per session.
On client operating systems, you can configure a registry entry to start SMB
Multichannel more quickly. For more information, see the following Blog Archive blog
article: How much traffic needs to pass between the SMB Client and Server before
Multichannel actually starts?.

SMB Multichannel doesn't aggregate multiple 10-GbE

network adapters
An RSS-capable 10-GbE network adapter is sometimes identified as non-RSS-capable.
When this issue occurs, SMB uses only one TCP connection. When SMB Multichannel
uses both RSS-capable and non-RSS network adapters, it should use only the RSS-
capable network adapters.
Server-class network adapters should appear as RSS-capable. If they don't, update the
network adapter driver from the manufacturer's website, and then recheck the RSS
settings.

You might have to disable RSS on both network adapters to aggregate throughput. For
more information, see the following Blog Archive blog article: Windows Server 2012 File
Server Tip: Make sure your network interfaces are RSS-capable.

The virtual network adapter on the host doesn't perform

well
The virtual network adapter on the host isn't RSS-capable. Without an RSS-capable
network adapter, SMB uses only one TCP connection. This behavior occurs when you use
10-GbE network adapters, RSS-capable network adapters, and NIC Teaming.

To troubleshoot this issue, use multiple virtual network adapters to make sure that you
have multiple TCP connections. For more information, see the following Blog Archive
blog article: Windows Server 2012 File Server Tip: Make sure your network interfaces are
RSS-capable.

Windows Server 2012 R2 periodically logs SMBClient

event ID 30818
Assume that a Windows Server 2012 R2-based computer uses an InfiniBand network
adapter. This adapter uses the SMB Direct feature to support Remote Direct Memory
Access (RDMA) communication between cluster nodes and Hyper-V hosts. After you
restart a Hyper-V host, Windows might log event ID 30818 under the Applications and
Services Logs/Microsoft/Windows/SmbClient path in Event Viewer. When this occurs,
you might also experience performance issues.

On Windows Server 2012 R2, the LanmanServer service automatically starts the
SmbDirect service. However, if the LanmanWorkstation service happens to start first and
tries to open an RDMA connection before the SmbDirect service loads, Windows logs
event ID 30818. When the client initially communicates with the server over TCP/IP, it
uses the RDMA interface. Therefore, no user action is needed to recover.

Microsoft is considering providing a resolution for this issue in a future version of

Windows Server.

Workaround
 ） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For protection, back up
the registry before you modify it so that you can restore it if a problem occurs. For
more information about how to back up and restore the registry, see How to back
up and restore the registry in Windows .

To work around this issue on Windows Server 2012 R2, configure the SmbDirect service
to start automatically. To do this, follow these steps:

1. Open Registry Editor, and then navigate to the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\smbdirect

2. Right-click the Start registry entry, and then select Modify.

3. In the Value data box, change the value (the default value is 3, which means on-
demand) to 2 (automatic).

After you make this change, you should be able to restart the computer without
Windows logging event ID 30818 messages. If Windows continues to log these events,
some other issue might be preventing the RDMA interface from initializing.

When you install Windows Server, Windows logs Event ID

1
When you install Windows Server 2019, Windows Server 2016, or Windows Server 2012
R2, Windows logs Event ID 1. The event information resembles the following:

Log Name: Microsoft-Windows-SMBWitnessClient/Admin

Source: Microsoft-Windows-SMBWitnessClient
Event ID:1
Level: Error
Description: Witness Client initialization failed with error (The system cannot find the
file specified.)

If this is a fresh deployment of Windows Server that has no roles or features enabled,
you can safely ignore this event.
SMB known issues
TCP three-way handshake failure
Slow files transfer speed
Negotiate, Session Setup, and Tree Connect Failures
TCP connection is aborted during Validate Negotiate
SMB Multichannel troubleshooting
High CPU usage issue on the SMB server
Troubleshoot the Event ID 50 Error Message
SMBv1 is not installed by default
Access Denied when you access an SMB file share

Data collection
Before you contact Microsoft Support, you can gather information about your issue.

Prerequisites
Run TSS in the security context of an account that has administrator privileges on
the local system. The first time that you run it, accept the EULA. (After you accept
the EULA, TSS won't prompt you again.)
We recommend that you use the RemoteSigned PowerShell execution policy at the
LocalMachine scope.

７ Note

If the current PowerShell execution policy doesn't allow you to run TSS, take the
following actions:

1. Set the RemoteSigned execution policy for the process level by running the
Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned cmdlet.

2. To verify that the change takes effect, run the Get-ExecutionPolicy -List
cmdlet.

These process-level permissions apply to only the current PowerShell session. After
you close the PowerShell window in which TSS runs, the assigned permission for
the process level reverts to the previously-configured state.
Gather key information before contacting Microsoft
support
1. Download TSS on all nodes, and expand the file into the C:\tss folder.

2. Open the C:\tss folder in an elevated PowerShell Command Prompt window.

3. Start the traces on the client and the server by running the following cmdlets:

Client:

PowerShell

TSS.ps1 -Scenario NET_SMBcli

Server:

PowerShell

TSS.ps1 -Scenario NET_SMBsrv

4. Accept the EULA if the traces are run for the first time on the server or the client.

5. Allow recording (PSR or video).

７ Note

If you collect logs on both the client and the server, wait for this message to
appear on both nodes before you reproduce the issue.

6. Reproduce the issue.

7. After you reproduce the issue, enter Y to finish logging data.

TSS stores the traces in a compressed file in the C:\MS_DATA folder. You can upload the
file to the workspace for analysis.

References
Advanced Troubleshooting Server Message Block (SMB)
Enable or disable SMB versions
File sharing using the SMBv3
SMB compression
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you download a file by using
the Background Intelligent Transfer
Service: Content file download failed
Article • 12/26/2023

This article describes a problem that occurs if you're behind a proxy server or behind a
firewall that doesn't support HTTP 1.1 range requests.

Applies to: Windows Server 2012 R2

Original KB number: 922330

Symptoms
When you try to download a file by using the Background Intelligent Transfer Service
(BITS), you're unsuccessful. Additionally, the following error message is logged in the
Application log:

Event Type:Error
Event Source:Windows Server Update Services
Event Category:(2)
Event ID:364
Date: date
Time: time
User:N/A
Computer: ServerName
Description: Content file download failed. Reason: The server does not support the
necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that
the server support the Range protocol header.

Specifically, you experience this problem if you try to perform one or both of the
following actions:

You approve an update in Microsoft Windows Server Update Services (WSUS). In

this situation, the download process is triggered. However, the download
operation is unsuccessful. A red X appears over the update.
You try to download the Mssecure.cab file for the Microsoft Baseline Security
Analyzer (MBSA) Management Pack for Microsoft Operations Manager (MOM)
2005.
Cause
You may experience this problem if a computer is behind a firewall or behind a proxy
server. This problem occurs if one of the following conditions is true:

The proxy server environment doesn't support the HTTP 1.1 range request feature.
You're behind a SonicWALL firewall device, and the Enable HTTP Byte-Range
request with Gateway AV setting isn't enabled for the device.

When you copy a file by using BITS in background mode, the file is copied in multiple
small parts. To perform this kind of copy operation, BITS uses the HTTP 1.1 Content-
Range header. If you're behind a proxy server or behind a firewall that removes this
header, the file copy operation is unsuccessful.

７ Note

When BITS copies files in foreground mode, BITS doesn't use this header.

Resolution 1: The proxy server doesn't support

HTTP 1.1 range requests
Modify the proxy server settings to support HTTP 1.1 range requests. If you can't modify
the proxy server in this manner, configure BITS to work in foreground mode. To do this,
follow these steps:

1. Click Start, click Run, type one of the following commands, and then click OK.

If you're using WSUS 2.0 with an MSDE or WMSDE database that was created by a
default WSUS installation, type the following command:

Console

%programfiles%\Update Services\tools\osql\osql.exe -S
%Computername%\WSUS -E -b -n -Q "USE SUSDB update tbConfigurationC set
BitsDownloadPriorityForeground=1"

If you configured WSUS 2.0 to use an existing installation of Microsoft SQL Server,
type the following command:

Console
 %programfiles%\Update Services\tools\osql\osql.exe" -S %Computername% -
E -b -n -Q "USE SUSDB update tbConfigurationC set
BitsDownloadPriorityForeground=1"

If you're using WSUS 3.0 with a Windows Internal Database that was created by a
default WSUS installation, type the following command:

Console

%programfiles%\Update Services\Setup\ExecuteSQL.exe -S
%Computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbConfigurationC
set BitsDownloadPriorityForeground=1"

If you configured WSUS 3.0 to use an existing installation of SQL

Server, type the following command:

```console
%programfiles%\Update Services\Setup\ExecuteSQL.exe -S %Computername% -
d "SUSDB" -Q "update tbConfigurationC set
BitsDownloadPriorityForeground=1"

2. Restart the Update Services service. To do this, follow these steps:

a. Click Start, click Run, type services.msc, and then click OK.
b. In the Services dialog box, right-click Update Services, and then click Restart.

Resolution 2: The Enable HTTP Byte-Range

request with Gateway AV setting isn't enabled
Click to select the Enable HTTP Byte-Range request with Gateway AV check box on the
Internal Settings page of the SonicWALL configuration tool. For more information about
how to modify the SonicWALL firewall features, contact SonicWALL support. To do this,
visit the following SonicWALL Web site:

SonicWALL support

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

A backlog is reported for a DFSR Read-
Only member after you remove a
replication file filter
Article • 12/26/2023

This article provides a solution to an issue where a backlog is reported for a Read-Only
member after you remove a replication file filter.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 4021676

Symptoms
Consider the following scenario:

You are running Windows Server 2019, Windows Server 2016, or Windows Server
2012 R2.
The system uses Distributed File System Replication (DFSR) and includes Read-Only
replicated folders.
You are prestaging data regardless of the replication filter from DFSR Read/Write
to Read-Only member candidates. Therefore, files that are in the filter set now exist
on all members.
After the initial replication, you remove a replication file filter.
When DFSR members detect the filter change, they all run a DirWalkerTask look-
up for content.
On a Read-Only member, this process creates a UID for the file object and
increments the version vector Global Version Sequence Number (GVSN). However,
the local change is not propagated.
The Read/Write partner creates its own UID for the same file, and the Read-Only
member detects a name conflict.
Per standard conflict resolution, the newer local version of the file is selected. The
Read-Only member reports Local version dominates and subsumes the update
from the Read/Write partner.
The Read-Only member increments its GVSN and generates a tombstone for the
UID from the Read/Write partner. However, neither change is propagated.

In this scenario, a backlog is reported from the Read-Only member to the Read/Write
partner because the DFSR service has two local changes that are not replicated to its
partner. The first report entry is for the local change when DFSR introduces the file as a
new object. The second entry is created when DFSR generates a tombstone for the file
version from the Read/Write partner that lost the conflict resolution. It does this by
deleting that file version.

７ Note

When the same file is later changed on the Read/Write member, the Read-Only
member reuses the tombstone record in its database by reporting it as "Remote
version dominates" and then providing its own UID version. This action generates
conflict event 4412. Additionally, the Read-Only member clears its backlog.

Cause
This behavior is by design. The Read-Only member applies the standard conflict
resolution mechanism to new replication content if a filter is removed and existing
content has to be integrated into DFSR.

Resolution
In most circumstances, you can safely ignore backlogs that are reported in the DFSR
Read-Only member to Read/Write partner direction. This is because a Read-Only
member is not intended to have real changes.

If only a few files are affected, consider making generic changes to the files on the
Read/Write member.

Generally, an initial sync is required for the Read-Only member to remove such a
backlog.

More information
When you use Windows PowerShell scripts and the Get-DfsrBacklog cmdlet to create an
overview for multiple DFSR setups, you may want to consider the following logic to
exclude backlog outputs from Read-Only members to their partners:

PowerShell

#variables for checking multiple DFSR setups, may be different in your

existing script
$RGName="ReplicationGroupName"
$RFName="ReplicatedFolderName"
 $SMem="SendingMember"
$RMem="ReceivingMember"

#new variable for the DFSR subcription for the RF, containing the
value/attribute "ReadOnly"; obtained by Get-DfsrMembership

$DfsrSubscription=Get-DfsrMembership -Groupname $RGName -Computername $SMem

| Where-object {$_.foldername -eq $RFName}

#now gather only the Backlog output, when the senders configuration for this
RF is not Read-only

if ($DfsrSubscription.ReadOnly -eq 0)
{
Get-DfsrBacklog -Groupname $RGName -Foldername $RFName -
SourceComputerName $SMem -DestinationComputerName $RMem -verbose
}
else
{
Write-Host "Backlog detection skipped because Sending Member ($SMem) is
Read-only for this RF ($RFName)"
}

Result: Instead of backlog output from the Read-Only member, you now see the
following report entry:

Backlog detection skipped because Sending Member (SendingMember) is Read-

Only for this RF (ReplicatedFolderName)

７ Note

Even after the initial backlog clears, Read-Only members may again show a backlog
of updates after some time. If these updates are version vector tombstones (also
known as VersionVectorTombstones), you can ignore them. Such updates do not
include actual changes. A Read-Only member generates version vector tombstone
updates under the following conditions:

When it detects and marks stale database GUIDs (GcTask::GcStaleDbGuids)

When it signals replication partners that it is alive and waiting for updates
(GcTask::GcSendDbKeepAlive)

For more information about these functions, see The UID of version vector tombstones
in Processing Updates.

These generic updates increase version sequence numbers (and therefore change the
GVSN version chain vector) on the Read-Only member. However, the Read-Only
member never shares these updates with its replication partners, so the updates are
never tracked by using the global version vector on the other members. Therefore, a
backlog count shows a visible delta between the Read-Only member and its replication
partners.

To keep such updates from generating confusing data, scripts that gather backlog data
should exclude Read-Only members.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

The ConflictAndDeleted folder size may
exceed its configured limitation
Article • 12/26/2023

This article provides a resolution for the issue that the ConflictAndDeleted folder size
may exceed its configured limitation.

Applies to: Windows Server 2016, Windows Server 2012 R2

Original KB number: 951010

Symptoms
In Windows Server, the size of the ConflictAndDeleted folder may exceed its configured
limitation. By default, the limitation of the ConflictAndDeleted folder is 660 megabytes
(MB). When this problem occurs, the ConflictAndDeleted folder may exhaust available
disk space on the volume on which the folder resides. Additionally, the Distributed File
System (DFS) Replication service cannot replicate any files.

Cause
This problem occurs because the ConflictAndDeletedManifest.xml file is corrupted. This
file stores information about the current contents of the ConflictAndDeleted folder. The
DFS Replication service writes to the ConflictAndDeletedManifest.xml file when files are
added or removed from the ConflictAndDeleted folder.

Resolution
To resolve this problem, use WMIC commands to delete the contents of the
ConflictAndDeleted folder and the ConflictAndDeletedManifest.xml file. Run the WMIC
commands in a Command Prompt window (cmd.exe). To clean up the
ConflictAndDeleted folder content of a replicated folder, run the following command:

Console

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where

"replicatedfoldername='<ReplicatedFolderName>'" call
cleanupconflictdirectory
 ７ Note

In this command, <ReplicatedFolderName> represents the name of the replicated

folder.

To clean up the ConflictAndDeleted folder content of all of the replicated folders in a

replication group, enter the following command:

Console

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where

"replicationgroupname='<ReplicationGroupName>'" call
cleanupconflictdirectory

７ Note

In this command,<ReplicationGroupName> represents the name of the replication

group.

７ Note

If you have not run a WMIC command on the computer before, a short pause
occurs while the computer installs WMIC.

Depending on the size of the ConflictAndDeleted folder, this process may take a few
minutes. The process empties the ConflictAndDeleted folder and reduces or deletes the
ConflictAndDeletedManifest.xml file.

７ Note

If any conflicts or deletions occur while cleanupconflictdirectory runs, the

information that is related to those conflicts or deletions remains in the
ConflictAndDeleted folder and the ConflictAndDeletedManifest.xml file when the
process finishes. After the cleanup, the file is much smaller, and the total size of the
ConflictAndDeleted folder is less than the quota maximum mark.

Status
Microsoft has confirmed that it is a problem in the Microsoft products that are listed in
the "Applies to" section.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Delegate DFS replication in Windows
Server 2003 R2
Article • 12/26/2023

This article describes how to directly modify the permissions on the configuration
objects for each replication group.

Applies to: Windows Server 2003 R2

Original KB number: 911604

Introduction
Distributed File System (DFS) replication uses the Active Directory directory service to
store configuration objects. When you use Active Directory, you can delegate user rights
more exactly. The DFS Management feature provides high-level delegation support. This
support lets you grant users the ability to create a replication group. This support also
lets you grant users administrative rights on a replication group that has already been
created.

Configuration objects
It is useful to have an overview of all objects before you view each object in detail. This
section describes the objects that are used to configure DFS replication. The permissions
to these objects determine which users can perform specific operations on replication
groups.

Global objects
Global objects configure the replica set as a whole. For example, global objects
configure the number of replicated folders. Global objects also configure the
connections between each member of the replication group.

msDFSR-GlobalSettings
This object is created at the following times:

When the first replication group in a domain is created

The first time that a user is delegated rights to create replication groups in a
domain
This object is created in the system container. By default, only the domain administrator
can create this object.

The only security modification to this object that we recommend is to grant users the
right to create msDFSR-ReplicationGroup child objects in this container. To use DFS
Management for this task, perform the Delegate Management Permissions action on the
Replication node.

msDFSR-ReplicationGroup
This object contains all the global settings that are specific to a single replication group.
To modify the permissions on this container in DFS Management, perform the Delegate
Management Permissions action on a replication group. You can grant a user
administration rights on a replication group. You can also grant the user control of the
msDFSR-ReplicationGroup object and of all the child objects for a replication group. The
following attributes are stored in this object:

1. Description
The replication group description.
2. msDFSR-Topology
The default schedule.

msDFSR-Content
This object is created under the msDFSR-ReplicationGroup object when the replication
group is created. The msDFSR-Content object contains a msDFSR-ContentSet object for
each replicated folder in the replication group.

７ Note

No important attributes are stored in this object.

msDFSR-ContentSet

A msDFSR-ContentSet object is created for each replicated folder in the replication

group. The following attributes are stored in this object:

Description
The description of the replicated folder.
msDFSR-FileFilter
File filter for files is excluded from replication.
 msDFSR-DirectoryFilter
Directory filter for folders is excluded from replication.
msDFSR-DfsPath
Path of DFS folder when the replicated folder is published to a DFS namespace.

msDFSR-Topology

This object is created under the msDFSR-ReplicationGroup object when the replication
group is created. The msDFSR-Topology object contains a msDFSR-Member object for
each member of the replication group.

７ Note

No important attributes are stored in this object.

msDFSR-Member
A msDFSR-Member object is created for each member of the replication group. This
object references the computer object for the member. This object contains a msDFSR-
Connection object for each connection where this member is the receiving member of
the connection. The following attributes are stored in this object:

msDFSR-ComputerReference
A reference to the computer object for the member.

msDFSR-Connection
A msDFSR-Connection is created as a child of a msDFSR-Member object for each
incoming replication connection to that member. The following attributes are stored in
this object:

msDFSR-Enabled
The enabled state of the connection.
msDFSR-Schedule
The custom schedule of the connection.
msDFSR-Keywords
Keywords for the connection.
msDFSR-RdcEnabled
The enabled state of the rRemote Differential Compression.
Server-local objects
Server-local objects exist in the computer account for each server that participates in a
replication. These objects configure individual members of the replication group.

msDFSR-LocalSettings

This object is the top-level container for DFS replication objects on a computer account.

msDFSR-Subscriber

A msDFSR-Subscriber object is created for each replication group to which a server

belongs. This object contains a msDFSR-Subscription object for each replicated folder in
the replication group that is specified by the msDFSR-Subscriber object. The following
attributes are stored in this object:

msDFSR-MemberReference
A reference to the msDFSR-Member object.

msDFSR-Subscription

The msDFSR-Subscription object contains settings that are unique to each replicated
folder on the server. The following attributes are stored in this object:

msDFSR-RootPath
The local path of the replicated folder.
msDFSR-StagingPath
The staging path of the replicated folder.
msDFSR-StagingSizeInMb
The size of the staging folder.
msDFSR-ConflictSizeInMb
The size of the conflict folder.
msDFSR-Enabled
The enabled state of the subscription.
msDFSR-Flags
A flag that controls whether deleted files are moved to the conflict folder.

Detailed delegation
Grant permissions to create a replication group
This action is one of the two delegation actions that are available in DFS
Management. To manually perform this action in Active Directory Users and
Computers, follow these steps:

1. Start Active Directory Users and Computers.

2. Right-click the Domain\System\DFSR-GlobalSettings node, and then click
Properties.
3. Click the Security tab, and then click Advanced.
4. Grant the desired users or groups the Create All Child objects permission,
and then select This object only in the Apply onto area.

Delegate administrative rights to a replication group

This is the other delegation action that is available in DFS Management. To

manually perform this action in Active Directory Users and Computers, follow these
steps:

1. Start Active Directory Users and Computers.

2. Right-click the Domain\System\DFSR-GlobalSettings node, and then click
Properties.
3. Click the Security tab, and then click Advanced.
4. Grant the desired users or groups the Full Control permission, and then
select This object and all child objects in the Apply onto area.
5. Add the users or groups to each member's local Administrators group.

Manage local system settings without being a local administrator

Typically, the user must be an administrator to manage local computer settings. To

enable a user who is not an administrator to manage local computer settings,
grant the user direct control of the required objects in Active Directory. To do this,
follow these steps:

1. Start Active Directory Users and Computers.

2. Right-click the computer node, and then click Properties.

By default, the path of the computer node is one of the following:

Member servers
Domain\Computer\ComputerName\DFSR-LocalSettings
Domain controllers
Domain\Domain Controllers\ComputerName\DFSR-LocalSettings

3. Click the Security tab, and then click Advanced.

 4. Grant the desired users or groups the Full Control permission, and then click
to select This object and all child objects in the Apply onto area.

Control of all replication groups

To grant a user control of all existing and future replication groups in a domain,
follow these steps:

1. Start Active Directory Users and Computers.

2. Right-click the Domain\System\DFSR-GlobalSettings node, and then click
Properties.
3. Click the Security tab, and then click Advanced.
4. Grant the desired users or groups the Full Control permission, and then click
to select This object and all child objects in the Apply onto area.
5. Add the users or groups to each member's local Administrators group. Or,
grant the Full Control permission for the computer objects of each server in
the replication groups.

Add/Remove/Modify replicated folders

To grant a user rights only to modify, to add, or to delete a replicated folder, follow
these steps:

1. Start Active Directory Users and Computers.

2. Right-click the Domain\System\DFSR-
GlobalSettings\ReplicationGroup\Content node, and then click Properties.
3. Click the Security tab, and then click Advanced.
4. Grant the desired users or groups the Full Control permission, and then
select This object and all child objects in the Apply onto area.
5. Add the users or groups to each member's local Administrators group. Or,
grant the Full Control permission for the computer objects of each server in
the replication groups.

Add/Remove/Modify members and connections

To grant a user rights only to modify, to add, or to delete members and

connections, follow these steps:

1. Start Active Directory Users and Computers.

2. Right-click the Domain\System\DFSR-
GlobalSettings\ReplicationGroup\Topology node, and then click Properties.
3. Click the Security tab, and then click Advanced.
4. Grant the desired users or groups the Full Control permission, and then
select This object and all child objects in the Apply onto area.
 5. Add the users or groups to each member's local Administrators group. Or,
grant the Full Control permission for the computer objects of each server in
the replication groups.

Generate a report on a replication group

To generate a diagnostic report, a user must be a local administrator of the servers

that are part of the report.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DFSR no longer replicates files after
restoring a virtualized server's snapshot
Article • 12/26/2023

This article discusses an issue where the Distributed File System Replication (DFSR)
service fails to replicate files after restoring a virtualized server's snapshot.

Applies to: Windows Server 2012 R2

Original KB number: 2517913

Symptoms
Using any virtualization product, you create a guest snapshot of a server replicating files
with DFSR. You later restore that snapshot, returning the server to an earlier point in
time.

You notice the following behaviors on the restored server:

No files replicate inbound or outbound for several minutes, then DFSR events 5014
and 5004 are logged indicating replication is resuming.

Any files created, deleted, or modified after the snapshot was taken but prior to
restoration replicate inbound.

Any files created, deleted, or modified after the restoration don't replicate
outbound.

Any changes to files on partner servers will replicate inbound, regardless of up-to-
dateness, overwriting all changes made locally and potentially deleting newer data.

After a period of time, the DFSR databases will write errors and warnings in the
event log and rebuild automatically. After the rebuild completes successfully, DFSR
will again log internal errors and rebuild the database. This will continue infinitely.

Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 2212
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: 2008r2-06-f.contoso.com
Description:
The DFS Replication service has detected an unexpected shutdown on volume
C:. This can occur if the service terminated abnormally (due to a power loss, for
example) or an error occurred on the volume. The service has automatically
initiated a recovery process. The service will rebuild the database if it
determines it cannot reliably recover. No user action is required.

Additional Information:
Volume: C:
GUID: <GUID>
Log Name: DFS Replication
Source: DFSR
Date: <DateTime>
Event ID: 2104
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: 2008r2-06-f.contoso.com
Description:
The DFS Replication service failed to recover from an internal database error
on volume C:. Replication has been stopped for all replicated folders on this
volume.

Additional Information:
Error: 9214 (Internal database error (-1605))
Volume: 92404560-E6C8-11DF-BCA2-806E6F6E6963
Database: C:\System Volume Information\DFSR
Log Name: DFS Replication
Source: DFSR
Date: <DateTime>
Event ID: 2004
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: 2008r2-06-f.contoso.com
Description:
The DFS Replication service stopped replication on volume C:. This failure can
 occur because the disk is full, the disk is failing, or a quota limit has been
reached. This can also occur if the DFS Replication service encountered errors
while attempting to stage files for a replicated folder on this volume.

Additional Information:
Error: 9014 (Database failure)
Volume: 92404560-E6C8-11DF-BCA2-806E6F6E6963
Log Name: DFS Replication
Source: DFSR
Date: <DateTime>
Event ID: 2106
Task Category: None
Level: Information
Keywords: Classic
User: N/A Computer: 2008r2-06-f.contoso.com
Description:
The DFS Replication service successfully recovered from an internal database
error on volume C:. Replication has resumed on replicated folders on this
volume.

Additional Information:
Volume: 92404560-E6C8-11DF-BCA2-806E6F6E6963
Database: C:\System Volume Information\DFSR

Any servers that replicate with the restored computer will repeatedly show in their
%systemroot%\debug\dfsr*.log files:

20110302 11:05:26.068 1192 INCO 7487 InConnection::RestartSession Retrying

establish contentset session. connId:{1B7F0404-6B47-4575-97CE-B107D9DEE1FE}
csId:{E027985A-B48E-4B96-9F65-23D3EAADE871} csName:snaprf
20110302 11:05:26.068 1192 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed,
should have already been processed. Error:
+ [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 1192 C
A failure was reported by the remote partner]
+ [Error:9027(0x2343) DownstreamTransport::EstablishSession
downstreamtransport.cpp:4200 1192 C A failure was reported by the remote
partner]
+ [Error:9027(0x2343) DownstreamTransport::EstablishSession
downstreamtransport.cpp:4179 1192 C A failure was reported by the remote
partner*]
+ [Error:9028(0x2344) DownstreamTransport::EstablishSession
downstreamtransport.cpp:4179 1192 C The content set was not found]
 20110302 11:07:26.080 1192 DOWN 4186 [ERROR]
DownstreamTransport::EstablishSession Failed on connId:{1B7F0404-6B47-4575-
97CE-B107D9DEE1FE} csId:{E027985A-B48E-4B96-9F65-23D3EAADE871}
rgName:snapshotrg Error:
+ [Error:9027(0x2343) DownstreamTransport::EstablishSession
downstreamtransport.cpp:4179 1192 C A failure was reported by the remote
partner]
+ [Error:9028(0x2344) DownstreamTransport::EstablishSession
downstreamtransport.cpp:4179 1192 C The content set was not found]

Cause
Snapshots aren't supported by the DFSR database or any other Windows multi-master
databases. This lack of snapshot support includes all virtualization vendors and
products. DFSR doesn't implement USN rollback quarantine protection like Active
Directory Domain Services.

Under no circumstances should you create or restore snapshots of computers running

DFSR on read-write members in a production environment.

Snapshot restore is only supported for read-only members as their version vector isn't
tracked on partners and a USN rollback can't happen.

Resolution
To resolve this issue, contact Microsoft Support. The resolution involves special database
recovery steps that can be used to fix the affected server without impacting other
computers.

Recreating the replication group or replicated folder will not fix the issue on the restored
server and shouldn't be used as a troubleshooting step.

More information
For more information around snapshots and USN rollback protection, review:

Hyper-V Virtual Machine Snapshots: FAQ

USN and USN Rollback

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Recover from a DFSR database crash on
designated primary member
Article • 12/26/2023

This article provides a workaround for an issue where the Distributed File System
Replication (DFSR) database fails on a DFSR Replication member.

Applies to: Windows Server 2012 R2

Original KB number: 961879

Symptom
The DFSR database may fail on a DFSR Replication member.

The DFSR service stops replication with error Event ID 2104. Since clients still use this
member as change target, you do not want to lose the changes and need a solution
without restoring content from a backup. When you manually rebuild the DFSR
database by deleting the database from <Volume>:\System Volume Information\DFSR
and restarting DFSR service, DFSR performs initial replication from any other still-
enabled member as non-master and moves conflicting files to the ConflictAndDeleted
folder or new files to PreExisting. This may cause unnecessary manual clean up and
recovery.

The idea to avoid this condition is to reinitialize the affected replicated folder in an order
that ensures that the affected member becomes the designated primary member of the
corresponding replicated folders.

Resolution
When a DFSR database crash affected member needs to become primary master of a
replicated folder:

1. Check that all members are set to disabled for the folder, check for event 4008 on
all of them when you need to change the setting.

2. Force Active Directory replication when members in different Active Directory sites
and use DFSRDIAG POLLAD /MEM:<MEMBER> to update the DFSR service after
each change in the configuration.
 3. Enable the folder on the designated primary member first and wait for Event ID
4112 indicating that This member is the designated primary member for this
replicated folder.

4. Enable other member(s) for the replicated folder and wait for Event ID 4104
indicating that The DFS Replication service successfully finished initial replication on
the replicated folder.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You receive DFSR event ID 2212 after
you restart the DFSR service in Windows
Server 2008
Article • 12/26/2023

This article describes an issue in which you receive the DFS Replication event 2212, and
DFSR stops after you restart Windows Server 2008. A short time later, event 2214 is
logged in the DFS Replication log.

Applies to: Windows Server 2012 R2

Original KB number: 977518

Symptoms
When you restart the Distributed File System Replication (DFSR) service on a server that
is running Windows Server 2008, or you restart the server, the following event may be
logged in the DFS Replication log:

Log Name: DFS Replication

Source: DFSR

Event ID: 2212

Task Category: None

Level: Warning

Keywords: Classic

User: N/A

Computer: MyDfsrMember.contoso.com

Description:

The DFS Replication service has detected an unexpected shutdown on volume

Drive_Letter. This can occur if the service terminated abnormally (due to a power
loss, for example) or an error occurred on the volume. The service has automatically
initiated a recovery process. The service will rebuild the database if it determines it
cannot reliably recover. No user action is required.
After some time has passed, DFSR logs event ID 2214. This event indicates that the
database recovery process has finished. During database recovery, replication
performance is slowed.

Cause
This issue occurs because the Service Control Manager (SCM) uses the default time-out
value of 20 seconds for stopping a service. In some complex DFSR implementations, this
time-out value may be too short, and DFSR stops before the appropriate database is
closed. At service restart, DFSR detects this condition and performs the database
recovery.

Resolution
To resolve this issue, you can change the default time-out value that is used by the SCM
by adding the following registry value:

Value Name WaitToKillServiceTimeout

Data Type REG_SZ

String 20000 milliseconds (default value)

To specify the wait time, follow these steps:

1. Click Start, click Run, type regedit , and then click OK.

2. Locate and then click the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

3. On the Edit menu, point to New, and then click String Value.

4. Type WaitToKillServiceTimeout, and then press ENTER.

5. On the Edit menu, click Modify.

6. Type 60000, and then click OK.

7. Exit Registry Editor.

8. Restart the server.

If the time interval is something other than 60 seconds, you can set the value of the
WaitToKillServiceTimeout registry value to the difference in time, in milliseconds,
between the following two events in the DFSR event log:
 1006 - The DFS Replication service is stopping.

1008 - The DFS Replication service has stopped.

Make sure to install KB 2549760 to ensure proper performance of the

WaitToKillServiceTimeout registry value

2549760 WaitToKillServiceTimeout registry value does not work in Windows 7 or in

Windows Server 2008 R2

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DFSR event ID 2213 in Windows Server
2008 R2
Article • 12/26/2023

This article describes an issue that triggers event ID 2213 in Windows 2008 or Windows
2012.

Applies to: Windows Server 2008 R2 Service Pack 1

Original KB number: 2846759

Summary
Microsoft has introduced new functionality to the DFS Replication (DFSR) service for
Windows Server 2008 R2 through hotfix 2663685 . After you install hotfix 2663685 or a
later version of Dfsrs.exe in Windows Server 2008 R2, the DFSR Service no longer
performs automatic recovery of the Extensible Storage Engine (ESE)) database after the
database experiences a dirty shutdown. Instead, when the new DFSR behavior is
triggered, event ID 2213 is logged in the DFSR log. A DFSR administrator must manually
resume replication after a dirty shutdown is detected by DFSR.

Windows Server 2012 exhibits this behavior by default.

The DFSR service maintains one ESE database per volume on volumes that host a
replicated folder. DFSR uses this database to store metadata about each file and folder
in the replicated folder. The integrity of the database must be maintained to make sure
that the service continues to work correctly.

When DFSR is notified that the service must shut down, it starts to commit all
outstanding changes to the ESE database. Dirty shutdown in DFSR occurs when the
DFSR service cannot commit all pending changes to the DSFR ESE database before the
DFSR service is shut down. During startup, the DFSR service checks the integrity of the
database.

Dirty shutdown recovery may cause large backlogs, and these, in turn, may cause
replication conflicts. In some cases, before the fix in hotfix 2780453 was released, the
winning file may not be the version that the end-user wants. The update to stop
replication during dirty shutdown was intended as a safeguard that lets administrators
back up the data to capture deltas since the last backup was taken before replication is
resumed.
After you install hotfix 2780453, you no longer have to pause replication during a dirty
shutdown. The fix from hotfix 2780453 is included in all Windows 2012 default media.

Best practices
Best practices for AutoRecovery based on server role, OS, and patch level:

ﾉ Expand table

Role Windows Server Windows Server 2008 R2 with KB Windows Server

2008 R2 2780453 installed 2012

DC On On On

Cluster Node On On On

Writable DFSR Off On On

Server

Read-only DFSR On On On
Server

Disable the Stop Replication functionality in

AutoRecovery
To have DFSR perform AutoRecovery when a dirty database shutdown is detected, edit
the following registry value after hotfix 2780453 is installed in Windows Server 2008
R2. You can deploy this change on all versions of Windows Server 2012. If the value does
not exist, you must create it.

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters
Value: StopReplicationOnAutoRecovery
Type: Dword
Data: 0

Resume replication after event 2213 is logged

After event 2213 is logged, an administrator must run a WMIC command in order to
resume replication. The command specifics are provided in the text of event ID 2213.
Step 1: Recovery steps for Event ID 2213 logged on your
DFSR server
1. Back up the files in all replicated folders on the volume. Failure to do this may
result in data loss from unexpected conflict resolution during the recovery of the
replicated folders.

2. To resume the replication for this volume, use the ResumeReplication WMI method
of the DfsrVolumeConfig class. For example, from an elevated command prompt,
run the following command:

Console

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where

volumeGuid="E18D8280-2379-11E2-A5A0-806E6F6E6963" call ResumeReplication

Step 2: Copy the WMIC command from step 2 in event ID

2213 recovery steps, and then paste it into an elevated
command prompt
When the command runs successfully, it returns the following results:

Console

wmic /namespace:\\root\microsoftdfs pathdfsrVolumeConfig where

volumeGuid="F1CF316E-6A40-11E2-A826-00155D41C919" call ResumeReplication

Executing(file://ww2008r2dc1/root/microsoftdfs:DfsrVolumeConfig.VolumeGuid=%2
2F1CF316E-6A40-11E2-A826-00155D41C919%22)-
%3EResumeReplication()">\WW2008R2DC1\root\microsoftdfs:DfsrVolumeConfig.Vo
lumeGuid="F1CF316E-6A40-11E2-A826-00155D41C919")->ResumeReplication()
Method execution successful.Out Parameters:instance of __PARAMETERS{
ReturnValue = 0;};

For PowerShell users, you have to add single quotation marks to the WMIC command to
run it from PowerShell, as follows:

PowerShell

wmic /namespace:\\root\microsoftdfs pathdfsrVolumeConfig where

'volumeGuid="F1CF316E-6A40-11E2-A826-00155D41C919"' call ResumeReplication
Step 3: Check whether event IDs 2212 and 2214 have been
logged
Check whether event IDs 2212 and 2214 have been logged on the server on which you
ran the resume replication command. Additional note on recovery if you must reinitialize
a replicated folder (or perform initial synchronization) after a dirty shutdown, follow
these steps:

1. Disable the replicated folder.

2. Enable replication by using the steps in the preceding Recovery steps for Event ID
2213 logged on your DFSR server section.
3. Enable the replicated folder.

If you disable and enable the replicated folder before you run the WMIC command,
initial synchronization does not occur because the volume manager is offline.

Steps to reduce the chances of a dirty

shutdown
In Windows, a service has 30 seconds to shut down after it receives a shutdown
notification. After 30 seconds, the Service Control Manager forces the service to shut
down. Where the DFSR service is concerned, a busy hub server may need more than 30
seconds to commit outstanding changes to the database. If the DFSR service does not
commit all changes in the 30 seconds that are allotted by the Service Control Manager,
the service is forcibly closed, and this triggers a dirty shutdown recovery.

Power outages or any other hard reboot of a DFSR server may also trigger a dirty
shutdown recovery. To reduce the chances of a dirty shutdown, make sure that your
DFSR servers are connected to an uninterruptible power supply (UPS) to allow them to
gracefully shut down.

Extend service shutdown times

On DFSR servers that require more than 30 seconds to shut down, you can use the
WaitToKillServiceTimeout value to extend the time period that's allowed for all services
to shut down.

A DSFR server that needs more time to shut down typically logs events 2212 and 2214
on most server restarts or restarts of the service. Or if AutoRecovery from a dirty
shutdown is enabled, event 2213 is logged on every server restart or restart of the DFSR
service.
 Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
Value: WaitToKillServiceTimeout
Type: String
Data: 300000

This value is in milliseconds. This example displays five minutes of shutdown time. The
value can be increased or decreased as necessary. This value affects all services, not just
DFSR. We recommend that you set this value to the lowest value that still gives DFSR
sufficient time to shut down cleanly. Use the following process to determine how long
your DFSR service needs to shut down:

1. Add the WaitToKillServiceTimeout registry value with a setting of 300000

milliseconds (5 minutes). Restart the server to enable the setting.

） Important

See the note about installing 2549760 in the following Notes about
WaitToKillServiceTimeOut section.)

2. Monitor the next few restarts of the server for DFSR events 1006 (DFSR is stopping)
and 1008 (DFSR Stopped). Note the time that elapsed between events 1006 and
1008.

3. Adjust the time allowed for shutdown by the revising the

WaitToKillServiceTimeout value so that it more closely reflects the actual time that
DSFR needs to cleanly shut down.

Notes about WaitToKillServiceTimeOut

Restarting the server or restarting DFSR several times in a row will not provide an
adequate sample of the time that DFSR needs to shut down. You must allow the
service time to run a while in order to accumulate pending database transactions.

The WaitToKillServiceTimeout setting has maximum value of one hour. If the

setting exceeds one hour, SCM reverts to the default setting of 30 seconds for
service shutdown.

To make sure that SCM works correctly where the WaitToKillServiceTimeout setting
is concerned, make sure that hotfix 2549760 is installed on Windows Server 2008
R2.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

DFSR Diagnostics Report shows sharing
violations events in Windows Server
even though the files have already been
replicated
Article • 12/26/2023

This article provides a workaround for an issue where DFSR Diagnostics Report shows
sharing violations events even though the files have already been replicated.

Applies to: Windows Server 2012 R2

Original KB number: 973836

Symptoms
When you run the Distributed File System Replication (DFSR) Diagnostics Report (DFSR
Health Report) on a Microsoft Windows Server 2008-based computer or on a Windows
Server 2003-based computer, the report contains many entries for the sharing violations
events. However, when you check the files on the replication partner, you find that the
files have already been replicated.

Cause
This issue occurs in the current implementation of DFSR because no anti-events are
triggered when the files are replicated. Therefore, the reporting state of the files remains
as sharing violated.

Workaround
To determine the real state of the file, use the DFSRDIAG BACKLOG command to check for
sharing violations. The command output provides a list of the first 100 files that are not
replicated.

More information
There two kinds of DFSR events for sharing violations: Event ID 4302 and Event ID 4304.
The DFSR Diagnostics combines both kinds of events, and reports them only as Event ID
4302.

The following information explains more about these two kinds of events.

Event ID 4302: A local sharing violation occurs when the service can't receive an updated
file because the local file is being used. This occurs on the receive side of the file change.
The file is already replicated. However, it can't be moved from the installing directory to
the final destination.

Event ID 4304: The service can't stage a file for replication because of a sharing violation.
This occurs on the "send" side of the file change. DFSR wants to stage or copy the file
for replication. However, an exclusive lock prevents this.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to configure DFSR logging
Article • 12/26/2023

This article describes the way to change these DFSR debug log settings is via the WMI
Command-line interface WMIC.

Applies to: Windows Server 2003

Original KB number: 958893

Symptoms
By default DFSR debug logging is already turned on in a quite verbose setting to log up
to 100 files with 200000 lines in the %windir%\debug folder, as a compressed Winzip
compatible file: DFSRxxxxx.log.gz and DFSRxxxxx.log (currently used). This will consume
about 75-100 MB disk space and represents a kind of history of DFSR activity. In certain
troubleshooting conditions, it may be necessary to extend this history, since older
information will be overwritten.

The recommended way to change these debug log settings is via the WMI Command-
line interface WMIC.

The changes will be immediately realized by the DFSR service without the need to
restart DFSR.

SETTING: Debug Log Severity

Default: 4

Range: 1-5

WMIC syntax: wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set

debuglogseverity=5

NOTE: For the most issues, the default severity 4 is sufficient.

SETTING: Debug Log Messages

Default: 200000

Range: 1000 to 4294967295 (FFFFFFFF)

WMIC syntax: wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set

maxdebuglogmessages=400000
SETTING: Debug Log Files

Default: 1000

Range: 1 to 100000

WMIC syntax: wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set

maxdebuglogfiles=200

SETTING: Debug Log File Path

Default: %windir%\debug

WMIC syntax: wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set

debuglogfilepath="d:\dfsrlogs"

７ Note

The path must be created manually before, if not available the default value
%windir%\debug will be used.

SETTING: Enable Debug Logging

Default: TRUE

Range: TRUE or FALSE

WMIC syntax: wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set

enabledebuglog=true

NOTE: Debug logging is enabled by default

You can check your configuration with the tool DFSRDIAG:

dfsrdiag DumpMachineCfg /Mem: DFSRMember1

Machine Configuration Parameters:

ConflictHighWatermarkPercent: 90

ConflictLowWatermarkPercent: 60

DebugLogFilePath: C:\WINDOWS\debug

DebugLogSeverity: 4

Description:
DsPollingIntervalInMin: 60

EnableDebugLog: TRUE

EnableLightDsPolling: TRUE

LastChangeNumber: 1

LastChangeSource:

LastChangeTime: 20050830140044.000000-000

MaxDebugLogFiles: 200

MaxDebugLogMessages: 400000

RpcPortAssignment: 0

StagingHighWatermarkPercent: 90

StagingLowWatermarkPercent: 60

You can also realize the debug log settings in the header of every log file:

FRS Log Sequence: 3 Index: 6 Computer:DFSRMember1 TimeZone:W. Europe

Daylight Time (GMT+-2:00) Build:[Nov 23 2005 00:36:45 built by: dnsrv_r2]
Enterprise=1
Configuration logLevel: 4 maxEntryCount: 400000 maxFileCount:200 LogPath:\\.\C:
\WINDOWS\debug\

More information
DFSR Registry setting for more verbose event logging

SETTING: Event Log Verbosity

Output: DFS Replication event log

Value Path: HKLM\SYSTEM\CurrentControlSet\Services\Dfsr\Parameters

Value Name: Enable Verbose Event Logging

Value Type: REG_DWORD

Value Data: 1

７ Note
 Although the registry value doesn't exist by default, the following events are
suppressed by default unless verbose event logging is enabled:

2002 EVENT_DFSR_VOLUME_INITIALIZED

3002 EVENT_DFSR_RG_INITIALIZED

3004 EVENT_DFSR_RG_STOPPED

4002 EVENT_DFSR_CS_INITIALIZED

5006 EVENT_DFSR_CONNECTION_OUTCONNECTION_ESTABLISHED

5004 EVENT_DFSR_CONNECTION_INCONNECTION_ESTABLISHED

MaxDebugLogFiles Note

The maximum is 10,000 on Windows Server 2003 R2 and 100,000 on all later operating
systems. The default is 100 logs in Windows Server 2003 R2 and Windows Server 2008,
and 1000 logs in Windows Server 2008 R2 and later operating systems.

Disclaimer
Microsoft and/or its suppliers make no representations or warranties about the
suitability, reliability, or accuracy of the information contained in the documents and
related graphics published on this website (the "materials") for any purpose. The
materials may include technical inaccuracies or typographical errors and may be revised
at any time without notice.

To the maximum extent permitted by applicable law, Microsoft and/or its suppliers
disclaim and exclude all representations, warranties, and conditions whether express,
implied, or statutory, including but not limited to representations, warranties, or
conditions of title, non-infringement, satisfactory condition or quality, merchantability
and fitness for a particular purpose, with respect to the materials.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Security setting changes on folders
don't appear immediately on DFSR
replication partners
Article • 12/26/2023

This article provides a workaround for the delays on DFSR replication partners after
security setting changes on folders.

Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 3212430

Symptoms
Assume that you have the Distributed File System (DFS) Replication role service installed
in Windows Server 2012 R2, Windows Server 2016 or Windows Server, version 1709,
Windows Server Standard, version 1803 or Windows Server Datacenter, version 1803.
When you change the security settings of a folder through Windows Explorer, the
change appears only on replication partners for subordinate files but not immediately
on the folder itself or its subfolders.

For example, if you grant a user Modify permissions to a folder on a domain controller,
the user can access the files on a replication partner only under the folder. The user
does not immediately have permissions to access the folders (parent folder and
subfolders).

７ Note

The changes appear on replication partners for the folders after 7 to 10 minutes.

Cause
This issue occurs because when you make folder security changes remotely or locally,
there's a delay before the redirector sends the Close statement for the parent folder.
Therefore, the receiving NTFS driver doesn't immediately stamp the change with a USN
Close statement in the NTFS Journal for the DFSR USN consumer.

Workaround
To work around this issue, use one of the following methods:

Avoid changing folder permissions remotely even if you use Windows Server Core
Edition. Instead, make security changes on the target itself. You may also consider
having at least two domain controllers with GUI implemented one with the primary
domain controller (PDC) emulator operations master (also known as flexible single
master operations or FSMO) role for introducing the changes locally, and one as
potential backup for this operations master role.
On the server on which you use Windows Explorer to make security setting
changes, create the NoRemoteRecursiveEvents and the NoRemoteChangeNotify
registry entries, and set the registry value to 1 in one of the following registry
subkeys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explo

rer

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explor

er

７ Note

You must restart the computer to make these registry entries work.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

SYSVOL DFSR migration fails after you
in-place upgrade a domain controller to
Windows Server 2019
Article • 12/26/2023

This article provides a solution to an issue where SYSVOL DFSR migration fails after you
in-place upgrade a domain controller to Windows Server 2019.

Applies to: Windows Server 2019

Original KB number: 4493934

Summary
In a domain that is configured to use the File Replication Service, the SYSVOL folder is
not shared after you in-place upgrade a Windows Server 2019-based domain controller
from an earlier version of Windows. Until this directory is shared, the domain controller
does not respond to DCLOCATOR requests for LDAP, Kerberos, and other DC workloads.

Symptoms
In a domain that uses the legacy File Replication Service for SYSVOL, you in-place
upgrade a domain controller to Windows Server 2019.

When you try to migrate the domain to Distributed File System (DFS) Replication, the
following issues occur:

All Windows Server 2019-based domain controllers in the domain stop sharing the
SYSVOL folder and stop responding to DCLOCATOR requests.

All Windows Server 2019-based domain controllers in the domain have the
following event log errors:

Log Name: DFS Replication

Source: DFSR
Date: <time>
Event ID: 8013
Task Category: None
Level: Error
Keywords: Classic
 User: N/A
Computer: <fqdn>
Description:
DFSR was unable to copy the contents of the SYSVOL share located at
C:\Windows\SYSVOL\domain to the SYSVOL_DFSR folder located at
C:\Windows\SYSVOL_DFSR\domain. This could be due to lack of availability of
disk space or due to sharing violations.

Additional Information:
Sysvol NTFRS folder: C:\Windows\SYSVOL\domain
Sysvol DFSR folder: C:\Windows\SYSVOL_DFSR\domain
Error: 367 (The process creation has been blocked.)

Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 8028
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <fqdn>
Description:
DFSR Migration was unable to transition to the 'PREPARED' state for Domain
Controller <computer name>. DFSR will retry the next time it polls the Active
Directory. To force an immediate retry, execute the command 'dfsrdiag
/pollad'.
Additional Information:
Domain Controller: <computer name>
Error: 367 (The process creation has been blocked.)

The DFSRMIG.EXE /GetMigrationState command generates the following output for all
Windows Server 2019 domain controllers:

Dfsrmig /getmigrationstate
The following domain controllers have not reached Global state ('Prepared'):

Domain Controller (Local Migration State) - DC Type

===================================================
<Computer name>('Start') - Writable DC
 Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.

７ Note

The global state can be Prepared, Redirected, or Eliminated, depending on which

global state you set previously.

Cause
The File Replication Service (FRS) was deprecated in Windows Server 2008 R2 and is
included in later operating system releases for backwards compatibility only. Starting in
Windows Server 2019, promoting new domain controllers requires the DFS Replication
(DFSR) to replicate the contents in the SYSVOL share. If you try to promote a Windows
Server 2019-based computer in a domain that still using FRS for SYSVOL replication, the
following error occurs:

Verification of prerequisites for Domain Controller promotion failed. The specified

domain contoso.com is still using the File Replication Service (FRS) to replicate the
SYSVOL share. FRS is deprecated. The server being promoted does not support FRS
and cannot be promoted as a replica into the specified domain. You MUST migrate
the specified domain to use DFS Replication using the DFSRMIG command before
continuing. For more information, see https://go.microsoft.com/fwlink/?
linkid=849270

Because of a code defect, in-place upgrading a Windows Server 2012 R2 or Windows

Server 2016 domain controller to Windows Server 2019 does not enforce this block.
When you then run DFSRMIG.EXE /SetGlobalState to migrate to DFSR, all upgraded
Windows Server 2019 domain controllers are stuck in the Start phase and cannot
complete the transition to the Prepared or later phases. Therefore, the SYSVOL and
NETLOGON folders for the domain controllers are no longer shared, and the domain
controllers stop responding to location questions from clients in the domain.

Workaround
There are several workarounds for this issue, depending on which migration global state
you specified earlier.
Issue occurs in the Preparing or Redirecting phase
1. If you have already run DFRSMIG /SetGlobalState 1 or DFRSMIG /SetGlobalState 2
previously, run the following command as a Domain Admin:

Console

DFRSMIG /SetGlobalState 0

2. Wait for Active Directory replication to propagate throughout the domain, and for
the state of Windows Server 2019 domain controllers to revert to the Start phase.

3. Verify that SYSVOL is shared on those domain controllers and that SYSVOL is
replicating as usual again by using FRS.

4. Make sure that at least one Windows Server 2008 R2, Windows Server 2012 R2, or
Windows Server 2016 domain controller exists in that domain. Verify all Active
Directory partitions and the files in the SYSVOL are fully sourced from one or more
source domain controllers and that they are replicating Active Directory as usual
before you demote all of your Windows Server 2019 domain controllers in the next
step. For more information, see Troubleshooting Active Directory Replication
Problems.

5. Demote all Windows Server 2019-based domain controllers to member servers.

This is a temporary step.

6. Migrate SYSVOL to DFSR normally on the remaining Windows Server 2008 R2,
Windows Server 2012 R2, and Windows Server 2016 domain controllers.

7. Promote the Windows Server 2019-based member servers to domain controllers.

Issue occurs in the Eliminating phase

The FRS elimination phase cannot be rolled back by using DFSRMIG. If have already
specified FRS elimination, you can use either of the following workarounds.

Option 1
You still have one or more Windows Server 2008 R2, Windows Server 2012 R2, or
Windows Server 2016 domain controllers in that domain. Verify all Active Directory
partitions and the files in the SYSVOL are fully sourced from one or more source domain
controllers and that they are replicating Active Directory as usual before you demote all
of your Windows Server 2019 domain controllers in the next step. For more information,
see Troubleshooting Active Directory Replication Problems.

1. Demote all Windows Server 2019-based domain controllers. This is a temporary

step.
2. Migrate SYSVOL to DFSR as usual on the remaining Windows Server 2008 R2,
Windows Server 2012 R2, and Windows Server 2016 domain controllers.
3. Promote the Windows Server 2019-based member servers to domain controllers.

Option 2

All domain controllers in the domain are running Windows Server 2019.

７ Note

Step 6 of this workaround requires the promotion of at least one Windows

Server 2008 R2, Windows Server 2012 R2, or Windows Server 2016 DC.
Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or by using another method. These problems might require
that you reinstall the operating system. Microsoft cannot guarantee that these
problems can be solved. Modify the registry at your own risk.

1. In the ADSIEDIT.MSC tool, change the following distinguished name value and
attribute on the PDC Emulator:
CN=DFSR-GlobalSettings,CN=System,DC=<domain>,DC=<TLD> msDFSR-Flags =
0

2. Wait for Active Directory replication to propagate throughout the domain.

3. On all Windows Server 2019 domain controllers, change the DWORD type registry
value Local State to 0:

Registry setting: Local State

Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Sys
Vols\Migrating SysVols

Registry value: 0
Data type: REG_DWORD

4. On all Windows Server 2019 domain controllers, restart the following services by
running the following commands:
 Console

net stop netlogon & net start netlogon

net stop DFSR & net start DFSR

5. Verify that SYSVOL has shared on those domain controllers and that SYSVOL is
replicating as usual again by using FRS.

6. Promote one or more Windows Server 2008 R2, Windows Server 2012 R2, or
Windows Server 2016 domain controllers in that domain. Verify all Active Directory
partitions and the files in the SYSVOL are fully sourced from one or more source
domain controllers and that they are replicating Active Directory as usual before
you demote all of your Windows Server 2019 domain controllers in the next step.
For more information, see Troubleshooting Active Directory Replication Problems.

7. Demote all Windows Server 2019-based domain controllers to member servers.

This is a temporary step.

8. Migrate SYSVOL to DFSR as usual on the remaining Windows Server 2008 R2,
Windows Server 2012 R2, and Windows Server 2016 domain controllers.

9. Promote the Windows Server 2019-based member servers to domain controllers.

10. Optional: Demote the Windows Server 2008 R2, Windows Server 2012 R2, or
Windows Server 2016 DC that you added in step 6.

References
For more information about how to migrate FRS to DFSR for SYSVOL, see the following
articles:

Migrate SYSVOL replication to DFS Replication

SYSVOL Replication Migration Guide: FRS to DFS Replication (downloadable)

Streamlined Migration of FRS to DFSR SYSVOL

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot journal_wrap
errors on Sysvol and DFS replica sets
Article • 12/26/2023

This article discusses how to troubleshoot journal_wrap errors on Sysvol and DFS replica
sets.

７ Note

This article applies to Microsoft Windows 2000. Be aware that support for Windows
2000 ended on July 13, 2010. For more information about the Microsoft Support
Lifecycle policy, see the following Microsoft website: Microsoft Support Lifecycle
Policy

Applies to: Windows 2000

Original KB number: 292438

Summary
The File Replication Service (FRS) is a multithreaded, multi-master replication engine
that replaces the LMREPL (LanMan Replication) service in the 3.x and 4.0 versions of
Microsoft Windows NT. Windows 2000 domain controllers and servers use FRS to
replicate system policy and logon scripts for Windows 2000 and for earlier clients that
are located in the System Volume (Sysvol).

FRS can also replicate content between Windows 2000 servers that host the same fault-
tolerant Distributed File System (DFS) roots or child-node replicas.

This article describes how FRS uses and relies on the USN change journal for the NTFS
file system.

More information
The USN journal is a log of fixed size that records all changes that occur on NTFS 5.0-
formatted partitions. NTFRS monitors the NTFS USN journal file for closed files in FRS
replicated directories as long as FRS is running.

Journal wrap errors occur if a sufficient number of changes that occur while FRS is
turned off in such a way that the last USN change that FRS recorded during shutdown
no longer exists in the USN journal during startup. The risk is that changes to files and
folders for FRS replicated trees may have occurred while the service was turned off, and
no record of the change exists in the USN journal. To guard against data inconsistency,
FRS asserts into a journal wrap state.

To perform maintenance on FRS replica set members, administrators may stop the FRS
service for long periods of time. In this case, administrators may not realize the potential
impact. Also, error conditions may cause the FRS service to shut down, and this causes a
journal wrap error. In large replica sets, replica members may encounter the following
error during an authoritative restore (BURFLAGS=D4):

journal_wrap_error

To recover, the affected replica member must be reinitialized with a nonauthoritative

restore (BURFLAGS=D2) where it will synchronize files from an existing inbound partner.
This reinitialization can be time-consuming for large replica sets.

Consider the scenario where computers run versions of the Ntfrs.exe file on the
following system versions:

Windows 2000 (2195 binary)

Windows 2000 Service Pack 1 (SP1)
SP1 Hotfix (WINSE build 5298)

In these scenarios, the nonauthoritative restore process must be invoked manually. To

do this, you must set BURFLAGS=D2 in the Windows NT registry.

For Windows 2000 computers that use versions of the Ntfrs.exe file from Windows 2000
Service Pack 2 (SP2) or from Windows 2000 SP2 hotfix (WINSE 11773), the service
performs a programmatic nonauthoritative restore when the journal_wrap_error is
detected.

By default, versions of the Ntfrs.exe file from Windows 2000 Service Pack 3 (SP3) and
from Windows 2000 SP3 hotfix don't perform an automatic nonauthoritative restore (for
example, SP3 leaves content in place as 2195 and SP1 left the context in place) when
journal wrap errors are detected. SP3 versions of NTFRS may be configured to function
like SP2 when the "Enable journal wrap automatic restore" registry entry is set to 1 in the
following registry subkey: HKLM\System\Ccs\Services\Ntfrs\Parameters

） Important

We don't recommend that you use this registry setting, and this setting should not
be used versions of Windows after the Service Pack 3 version of Windows 2000. The
 recommended method for performing a nonauthoritative restore on FRS members
of DFS or SYSVOL replica sets is to use the FRS BurFlags registry value. For more
information about how to use the BurFlags registry value, click the following article
number to see the article in the Microsoft Knowledge Base: 290762 Using the
BurFlags registry key to reinitialize File Replication service replica sets

The following are appropriate options to reduce journal wrap errors:

Put the FRS-replicated content on less busy volumes.

Keep the FRS service running.
Avoid making changes to FRS-replicated content while the service is turned off.
Increase the USN journal size.

FRS is a service that must always be running on Windows domain controllers and
members of FRS-replicated DFS sets.

If you increase the USN journal size, and therefore you increase the number of changes
that the journal can hold before the journal "wraps," this reduces the possibility that the
USN journal wrap will occur. The USN journal size can be changed by setting the
following registry key: HKLM\System\CCS\Services\NTFRS\Parameters\"Ntfs Journal size
in MB" (REG_DWORD)

Valid settings range from 8 megabytes to 128 megabytes (MB). The default is 32 MB.
This setting applies to all volumes that are hosting an FRS replica tree. You have to stop
and then restart the NTFRS service for the increases to the USN journal size to occur.
However, to decrease the USN journal size, you must reformat all volumes that contain
FRS-replicated content.

The number of changes that a given USN journal file can hold can be estimated by using
the following formula: journal size /((60 bytes + (length of file name)) * 2) The number
"2" in this formula stems from two journal entries for each file change: 1 for open and 1
for close. Divide the journal size by the size per change to determine the approximate
number of changes that can occur before the journal wrap error is encountered. If we
assume that the file names are in an "8.3" file format, this maps to approximately
200,000 files and/or directories for a 32-MB journal file. The number of changes would
be less if long file names are used.

In Windows 2000 Service Pack 2, valid settings range between 8 MB and 128 MB, and
the default is 32 MB. In Windows 2000 Service Pack 3, valid settings range between 4
MB and 10,000 MB, and the default is 512 MB. These settings apply to all volumes that
host an FRS replica tree.
As a guideline, Microsoft suggests that you configure 128 MB of journal for every
100,000 files that are managed by replication on that volume.

For more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:

290762 Using the BurFlags registry key to reinitialize File Replication service replica
sets

Feedback
Was this page helpful?  Yes  No

Provide product feedback

How to troubleshoot missing SYSVOL
and Netlogon shares
Article • 12/26/2023

This article provides the steps to troubleshoot the missing SYSVOL and Netlogon shares
in Windows Server 2012 R2.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 2958414

Symptoms
SYSVOL and Netlogon shares aren't shared on a domain controller. The following

symptoms or conditions may also occur:

The sysvol folder is empty.

The affected domain controller was recently promoted.
The environment contains domain controllers running versions of Windows earlier
than Windows Server 2012 R2.
DFS Replication is used to replicate the SYSVOL Share replicated folder.
An upstream domain controller's DFS Replication service is in an error state.

Cause
Domain controllers without SYSVOL shared can't replicate inbound because of upstream
(source) domain controllers being in an error state. Frequently (but not limited to), the
upstream servers have stopped replication because of a dirty shutdown (event ID 2213).

Resolution
This section contains recommended methods for troubleshooting and resolving missing
SYSVOL and Netlogon shares on domain controllers that replicate by using the DFS
Replication service.

The process reinitializes DFS Replication if SYSVOL isn't shared on domain controllers
according to How to force an authoritative, or non-authoritative synchronization for
DFSR-replicated SYSVOL (like "D4/D2" for FRS) . It's unnecessary in most cases, and it
may cause data loss if done incorrectly. In addition, it prevents determining the cause of
the issue and averting future occurrences of the issue.

What follows are general steps to investigate the missing shares. Determine if the
problem is caused by a one-time occurrence, or if the upstream domain controller(s)
can't support replication by using DFS Replication.

Deleting the DFS Replication database from the volume shouldn't be required and is
discouraged. It causes DFS Replication to consider all local data on the server to be
nonauthoritative. By letting DFS Replication recover the database gracefully (as
instructed in the 2213 event), the last writer will still win any conflicting versions of
SYSVOL data.

Step 1 - Evaluate the state of DFS Replication on all

domain controllers
Evaluate how many domain controllers aren't sharing SYSVOL , have recently logged an
Error event, and how many domain controllers are in an error state. Follow these steps.

Check for the SYSVOL share

You may manually check whether SYSVOL is shared or you can inspect each domain
controller by using the net view command:

Console

For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i |

find "SYSVOL") & echo

Check DFS Replication state

To check DFS Replication's state on domain controllers, you may query WMI. You
can query all domain controllers in the domain for the SYSVOL Share replicated
folder by using WMI as follows:

Console

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i"

/namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE
replicatedfoldername='SYSVOL share' get
replicationgroupname,replicatedfoldername,state
The state values can be any of:
0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

７ Note

Depending on a domain controller's condition, it may fail to report a state

value and indicate no instance(s) available.

Check Event logs for recent errors or warnings

If any domain controllers don't report the SYSVOL Share replicated folder as being
in a state 4 (normal), check the event log of those domain controller(s) to evaluate
their condition. Review each domain controller for recent errors or warnings in the
DFS Replication event log, such as the warning event ID 2213 that indicates that
DFS Replication is currently paused.

Check the Content Freshness configuration

Determine whether DFS Replication triggered content freshness protection on the

affected domain controllers. Content Freshness is enabled on Windows Server
2012 (and later versions) domain controllers by default. However, it may also be
manually enabled on Windows Server 2008 R2 servers.

To evaluate if content freshness is enabled, the MaxOfflineTimeInDays setting will

be set to 60. If content freshness is disabled, MaxOfflineTimeInDays will be set to 0.
To check MaxOfflineTimeInDays , run the following command:

Console

wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path

DfsrMachineConfig get MaxOfflineTimeInDays

To query all domain controllers in the domain, run the following command:

Console

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i"

/namespace:\\root\microsoftdfs path DfsrMachineConfig get
 MaxOfflineTimeInDays

For each domain controller enabled for content freshness, evaluate if DFS
Replication has logged an event ID 4012 that indicates replication of the folder has
stopped because replication has failed for longer than the MaxOfflineTimeInDays
parameter.

Step 2 - Prepare the domain controllers that are in an

error state
Install appropriate updates

For any domain controllers running Windows Server 2008 R2, first install DFS
Replication updates to prevent data loss and to fix known issues. It's a best
practice to use the latest version of DFS Replication. See List of currently available
hotfixes for Distributed File System (DFS) technologies for the latest version of
DFS Replication.

Back up SYSVOL data

Do a backup of SYSVOL data (if present) on each domain controller. Backups may
be a file copy of the SYSVOL contents to a safe location or, it may be a backup that
uses backup software.

Depending on the situation, policy files could be moved to PreExisting or Conflict

and Deleted. PreExisting and Conflict and Deleted contents will be purged if
initial synchronization is done multiple times on a server. Back up data in these
locations to avoid data loss.

Step 3 - Recover DFS Replication on the domain

controllers in the error state
Based on the number of domain controllers in the domain, select the appropriate
method to recover the DFS Replication service.

For environments that have two domain controllers

Determine whether a dirty shutdown was detected (event ID 2213) on either domain
controller. You may find the second domain controller is waiting to complete
initialization of SYSVOL . The reason is, after promotion, it will log a 4614 event that
indicates that DFS Replication is waiting to do initial replication. In addition, it won't log
a 4604 event signaling that DFS Replication has initialized SYSVOL .

If content freshness is enabled on both domain controllers

If the second domain controller waits to do initial synchronization (event 4614

logged without the 4604 anti-event), follow the How to force an authoritative and
non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for
FRS) to set the first domain controller as authoritative. You don't have to
configure the second domain controller as nonauthoritative, because it's already
waiting to do initial synchronization.

Or, if the second domain controller is healthy and SYSVOL is shared, take the
following steps:

1. Back up all SYSVOL contents of the first domain controller.

2. Evaluate if the second domain controller's SYSVOL data is up to date. If not,

you may want to copy updated SYSVOL files to the second domain controller
from the first domain controller. Otherwise, any existing data present on first
domain controller not present on the second will go into the PreExisting and
Conflict and Deleted folders.

3. Set the first domain controller as nonauthoritative by disabling the

membership per How to force an authoritative and non-authoritative
synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS) .
Confirm that an event ID 4114 is logged to indicate the membership is
disabled.

4. Enable the first domain controller's membership, and wait for the 4614 and
4604 events that report completion of the initial synchronization. If necessary,
restore any updated files from PreExisting to the original location.

If content freshness isn't enabled or triggered on both domain controllers

If the first domain controller is in the event ID 2213 state, and the second domain
controller has never completed initialization after it was promoted, and content
freshness hasn't been triggered. Take the following steps:

1. Run the ResumeReplication WMI method on the first domain controller as

instructed in the 2213 event.

2. After replication resumes, it will log an event ID 4602 that indicates that DFS
Replication initialized the SYSVOL replicated folder and specified it as the
 primary member.

3. Run the dfsrdiag pollad command on the second domain controller to

trigger it to complete initial sync (event ID 4614). As soon as initial sync is
finished, event ID 4604 is logged, signaling SYSVOL has completed
initialization.

Or, if the first domain controller is in the 2213 state and the second domain
controller is healthy ( SYSVOL is shared), run the ResumeReplication WMI method
on the first domain controller. It will log event ID 2214 at the completion of dirty
shutdown recovery.

For environments that have three or more domain controllers

Determine whether a dirty shutdown was detected and whether DFS Replication is
paused on any domain controllers (event ID 2213). You may find a domain controller is
waiting to complete initialization of SYSVOL after promotion. It will log a 4614 event that
indicates that DFS Replication is waiting to do initial replication. It also won't log a 4604
event signaling that DFS Replication has initialized SYSVOL .

If content freshness is enabled, and there are three or more domain controllers in
the domain.

Content freshness protection will log an event ID 4012 that indicates that
replication has stopped because replication on the folder has failed for longer than
the MaxOfflineTimeInDays parameter. To reinitialize DFS Replication on the affected
domain controller(s), follow the instructions in How to force an authoritative and
non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for
FRS) .

If all domain controllers have logged the 4012 event and their state is 5, follow the
instructions in How to force an authoritative and non-authoritative synchronization
for DFSR-replicated SYSVOL (like "D4/D2" for FRS) to completely initialize
SYSVOL . It's the only situation to set a DFS Replication server as authoritative. Make

sure that the domain controller configured as authoritative has the most up-to-
date copy of all SYSVOL contents.

Or, if one or more domain controllers are blocking replication because of content
freshness, they each must be non-authoritatively recovered. Follow these steps:

1. Back up all SYSVOL contents of the domain controller(s). Typically, policy edits
are done on the PDC Emulator, but it isn't guaranteed. Any data present on
 the recovered domain controller(s) not matching the partners will go into the
PreExisting or Conflict and Deleted folder, or both.

2. Set the domain controller(s) as nonauthoritative by disabling the

membership, as described in How to force an authoritative and non-
authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for
FRS) . You must be aware of the replication topology, and you must fan out
from a healthy domain controller by selecting direct partners of it, then
recovering further downstream domain controllers, and so on. Event ID 4144
will be logged to confirm the membership is disabled. Make sure all domain
controllers requiring recovery log the event. It may be necessary to force
Active Directory replication and then run the dfsrdiag pollad command on
each domain controller to detect the disabled membership quickly.

3. Enable the membership and wait for the 4614 and 4604 events to report
completion of the initial synchronization. Restore any required files from
backup or from PreExisting and Conflict and Deleted as necessary.

If content freshness isn't enabled or triggered, and there are three or more domain
controllers in the domain

If content freshness protection isn't triggered, run the ResumeReplication WMI

method on the affected domain controllers. You must be aware of the replication
topology, and you must fan out from a healthy domain controller by selecting
direct partners of it, then recovering further downstream domain controllers, and
so on. After replication is resumed, DFS Replication will log events 2212, 2218, and
then 2214 (indicating that DFS Replication initialized the SYSVOL replicated folder).

Preventing future occurrences of the issue

Check whether the Application and System event logs are frequently reporting ESENT
database recovery operations, disk performance problems, or both. The event logs
typically coincide with unexpected shutdowns of the system, with DFS Replication not
stopping gracefully, or disk subsystem failures. Consider updating the system's drivers,
installing appropriate updates to the disk subsystem, or contacting the system's
hardware manufacturer to investigate further. You may also contact Microsoft Customer
Support Services to help evaluate the system's health and DFS Replication behavior.

The Service Control Manager (SCM) uses the default time-out time of 20 seconds for
stopping a service. In some complex DFS Replication implementations, this time-out
value may be too short, and DFS Replication stops before the appropriate database is
closed. At service restart, DFS Replication detects this condition, and then does the
database recovery. WaitToKillServiceTimeout may be used to grant DFS Replication more
time to commit changes to the database during shutdown. For more information, go to
article You receive DFSR event ID 2212 after you restart the DFSR service .

After you have restored DFS Replication of SYSVOL , DFS Replication health must be
carefully monitored in the environment to prevent this scenario. Regular review of DFS
Replication event logs, collecting of DFS Replication health reports, and collecting of
replication state (by using the WMI query in the Check DFS Replication state section
under Step 1 - Evaluate the state of DFS Replication on all domain controllers) are
recommended.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Information about Microsoft support
policy for a DFS-R and DFS-N
deployment scenario
Article • 12/26/2023

This article describes a Distributed File System Replication (DFS-R) and Distributed File
System Namespace (DFS-N) deployment scenario that Microsoft does not support.

Applies to: Windows Server 2012 R2

Original KB number: 2533009

Unsupported scenario
When you deploy DFS-R and DFS-N together with user home folders or with roaming
user profiles, the following scenario is not supported by Microsoft:

You deploy a single file server for each branch office. User home folders and
roaming user profiles of users in the branch office are stored on the branch office
file server.
You use DFS-R over WAN links from multiple branch office file servers to a central
hub server for centralized backup. You configure the hub server with read-only
replicated folders or read/write replicated folders.
You configure a DFS namespace to create a unified namespace.
You configure one namespace folder to have multiple folder targets. And, you add
the shared folder of the central file server as a second DFS-N folder target. You
enable all namespace folder targets, or you enable only one folder target at a time.
You configure the target priority of DFS-N so that the client refers to the branch
office file server first. When the branch office file server is not available, the client
will be redirected to the central file server. You may also specify that roaming users
be directed to a file server that contains their user data or user profile and that is
closest to their physical location.

７ Note

Although this scenario cites home folders and roaming user profiles as specific
content examples, the same issue applies to any fast-changing content that may
not have been replicated to a replication partner when the referral redirects the
user from a different partner to that partner. Additionally, the "central" file server
and "branch office" file server are examples, any similar deployment configurations
 are equally susceptible to the problems outlined in this article. Therefore, they are
not supported by Microsoft. A similar deployment example is that two branch
office servers replicate fast-changing content between one another.

Technical reasons that Microsoft does not

support the scenario
We do not support the deployment scenario for the following reasons:

User home folders or user profiles that are replicated by using DFS-R between the
branch office file servers and the central file server may not be up to date. The
issue may occur for one of the following reasons:
Large replication backlogs
Heavy system load
Bandwidth throttling
Replication schedules
DFS-R does not perform transactional replication of user profile data. A
transactional replication either replicates all changes to a user profile or replicates
nothing at all. Therefore, some files of a user profile may have been replicated,
whereas other files may not have been replicated before the user was failed over
to the central file server.
The client computer may be failed over to the central file server by the DFS-N
client in one of the following scenarios:
There are transient network glitches when the client computer accesses data
over Server Message Block (SMB) from the branch office file server.
There are specific error codes when the client computer accesses data over SMB
from the branch office file server. The redirection may occur even when the
branch office file server is available. Therefore, a user may be redirected to the
central file server even if you configure the target referral priority of the branch
office file server at a higher level.

Potential data consistency or data staleness

issues that may occur in the unsupported
scenario
If the replicated folder of the central file server is a read/write replica, one of the
following issues may occur:
 Roaming user profiles may be corrupted because all the changes that were made
by the users during their last logon may not have been replicated to the central file
server. Therefore, the users may change a stale or an incomplete copy of the
roaming profile during their next logon. This may cause user profile corruption.
A user may experience data loss or data corruption because the data on the central
file server may be stale or out-of-sync with the data on the branch office file server.
The user data becomes stale because the latest modification of the user data is not
yet replicated.
When a user edits a stale copy of the user data on the central file server, the data
on the central file server will overwrite the fresher data on the branch office file
server. This issue occurs because DFS-R is a multi-master replication engine that
uses a conflict-resolution heuristic of last writer wins for files that are in conflict. If
the replicated folder of the central file server is a read-only replica, one of the
following issues may occur:
When a user is directed to the central file server, applications and users will be
unable to change files that are stored in the shared folder. The user will be
confused because a file that can be changed before suddenly becomes read-only.
When a user is directed to the central file server, the roaming user profile may be
corrupted because all changes that were made by the user during his last logon
may not have been replicated to the central file server. Additionally, the roaming
user profiles infrastructure cannot write back any changes to the profile when the
user is logged off.
A user may experience data loss or data corruption because the data on the central
file server may be stale or out-of-sync with the data on the branch office file server.
The user data becomes stale because the latest modification of the user data is not
replicated. Additionally, users will notice synchronization errors or conflicts of files
that are changed on their computers. Users cannot resolve the conflicts because
the replicated folder is read-only.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error message when you try to access a
server locally by using its FQDN or its
CNAME alias after you install Windows
Server 2003 Service Pack 1: Access
denied or No network provider
accepted the given network path
Article • 12/26/2023

This article provides a solution to an error that occurs when you try to access a server
locally by using its FQDN or its CNAME alias.

Applies to: Windows 7 Service Pack 1, Windows Server 2012 R2

Original KB number: 926642

７ Note

This article contains information that shows you how to help lower security settings
or how to turn off security features on a computer. You can make these changes to
work around a specific problem. Before you make these changes, we recommend
that you evaluate the risks that are associated with implementing this workaround
in your particular environment. If you implement this workaround, take any
appropriate additional steps to help protect your system.

Symptoms
Consider the following scenario. You install Microsoft Windows Server 2003 Service Pack
1 (SP1) on a Windows Server 2003-based computer. After you do this, you experience
authentication issues when you try to access a server locally by using its fully qualified
domain name (FQDN) or its CNAME alias in the Universal Naming Convention (UNC)
path: \\servername\sharename.

In this scenario, you experience one of the following symptoms:

You receive repeated logon windows.

You receive an "Access denied" error message.
 You receive a "No network provider accepted the given network path" error
message.
Event ID 537 is logged in the Security event log.

７ Note

You can access the server by using its FQDN or its CNAME alias from another
computer in the network other than this computer on which you installed Windows
Server 2003 SP1. Additionally, you can access the server on the local computer by
using the following paths:

\\IPaddress-of-local-computer
\\Netbiosname or \\ComputerName

Cause
This problem occurs because Windows Server 2003 SP1 includes a new security feature
named loopback check functionality. By default, loopback check functionality is turned
on in Windows Server 2003 SP1, and the value of the DisableLoopbackCheck registry
entry is set to 0 (zero).

７ Note

The loopback check functionality is stored in the registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck .

Resolution

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For added protection,
back up the registry before you modify it. Then, you can restore the registry if a
problem occurs. For more information about how to back up and restore the
registry, see How to back up and restore the registry in Windows .
 ７ Note

This workaround may make your computer or your network more vulnerable to
attack by malicious users or by malicious software such as viruses. We do not
recommend this workaround but are providing this information so that you can
implement this workaround at your own discretion. Use this workaround at your
own risk.

To resolve this problem, set the DisableStrictNameChecking registry entry to 1. Then use
either of the following methods, as appropriate for your situation.

Method 1 (recommended): Create the Local Security

Authority host names that can be referenced in a NTLM
authentication request
To do this, follow these steps for all the nodes on the client computer:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

3. Right-click MSV1_0, point to New, and then click Multi-String Value.

4. In the Name column, type BackConnectionHostNames, and then press ENTER.

5. Right-click BackConnectionHostNames, and then click Modify.

6. In the Value data box, type the CNAME or the DNS alias, that is used for the local
shares on the computer, and then click OK.

７ Note

Type each host name on a separate line.

If the BackConnectionHostNames registry entry exists as a REG_DWORD
type, you have to delete the BackConnectionHostNames registry entry.

7. Exit Registry Editor, and then restart the computer.

Method 2: Disable the authentication loopback check

Re-enable the behavior that exists in Windows Server 2003 by setting the
DisableLoopbackCheck registry entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey to 1. To set

the DisableLoopbackCheck registry entry to 1, follow these steps on the client computer:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3. Right-click Lsa, point to New, and then click DWORD Value.

4. Type DisableLoopbackCheck, and then press ENTER.

5. Right-click DisableLoopbackCheck, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Exit Registry Editor.

8. Restart the computer.

７ Note

You must restart the server for this change to take effect. By default, loopback
check functionality is turned on in Windows Server 2003 SP1, and the
DisableLoopbackCheck registry entry is set to 0 (zero). The security is reduced when
you disable the authentication loopback check, and you open the Windows Server
2003 server for man-in-the-middle (MITM) attacks on NTLM.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.

More information
After you install security update 957097, applications such as SQL Server or Internet
Information Services (IIS) may fail when making local NTLM authentication requests.

For more information about how to resolve this issue, see the "Known issues with this
security update" section of KB article 957097 .
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Active Directory-integrated DNS zone
serial number behavior
Article • 12/26/2023

This article describes Active Directory-integrated Domain Name System (DNS) zone
serial number behaviors.

Applies to: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Original KB number: 282826

Summary
When a DNS server receives an update directly (either from the administrator, or
through dynamic updates), it always increases the serial number of the zone.

When a DNS server receives an update through Active Directory replication:

If the serial number of the replicated record is higher than the serial number in the
SOA record of the local copy of the zone, the local zone serial number is set to the
serial number in the replicated record.

７ Note

Each DNS record in the zone has a copy of the zone serial number at the time
when the record was last modified.

If the serial number of the replicated record is the same or lower than the local
serial number, and if the local DNS server is configured not to allow zone transfer
of the zone, the local zone serial number is not changed.

If the serial number of the replicated record is the same or lower than the local
zone serial number, if the DNS server is configured to allow a zone transfer of the
zone, and if the local zone serial number has not been changed since the last zone
transfer occurred to a remote DNS server, then the local zone serial number will be
incremented. Otherwise that is if a copy of the zone with the current local zone
serial number has not been transferred to a remote DNS server, the local zone
serial number is not changed.

More information
In a scenario where a third-party DNS server is configured as secondary for an Active
Directory-integrated zone, the first (preferred) primary server becomes unavailable, and
the secondary server attempts a zone transfer from another primary server for the zone,
then the secondary DNS server (by using IXFR) may not notice that the zone was
updated if the serial number of the zone is lower on the latter primary server. In this
scenario, the secondary successfully performs zone transfer after the primary's serial
number becomes greater than the serial number in the SOA record in the zone on the
secondary server.

７ Note

The multiple-master replication behavior of an Active Directory-integrated Domain

Name System (DNS) zone can cause inconsistencies with serial numbers of the zone
across multiple DNS servers. It is not possible to retrieve information (pull or
source) from multiple Active Directory-integrated primary DNS servers to a
secondary DNS server for the same Active Directory-integrated zone. This was
possible and frequently done with conventional single-master DNS. However,
because serial numbers are maintained separately on each Active Directory-
integrated DNS server, the mechanism for determining whether the secondary DNS
server has the most-recent copy may will fail.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Steps to avoid registering unwanted
NICs in DNS on a multihomed domain
controller
Article • 12/26/2023

This article provides a solution to an issue where unwanted network interface controllers
(NICs) are registered in Domain Name System (DNS) on a multihomed domain
controller (DC).

Applies to: Windows Server 2012 R2

Original KB number: 2023004

Symptoms
On Domain Controllers with more than one NIC where each NIC is connected to
separate Network, there's a possibility that the Host A DNS registration can occur for
unwanted NICs.

If one of the following conditions is true, the client will fail to contact the DC causing
authentication and many other issues:

The client queries for DC's DNS records, and gets an unwanted record.
The client queries for DC's DNS records, and gets a record of a different network
that isn't reachable to the client.

Cause
The DNS server will respond to the query in a round robin fashion if the DC has multiple
NICs registered in DNS. The DNS will serve the client with all the records available for
that DC.

To prevent this issue, we need to make sure the unwanted NIC address isn't registered in
DNS.

Below are the services that are responsible for Host A record registration on a DC:

1. Netlogon service
2. DNS server service (if the DC is running DNS server service)
3. DHCP client or DNS client (2003/2008)
If the NIC card is configured to register the connection address in DNS, then the
DHCP/DNS client service will register the record in DNS. Unwanted NIC should be
configured not to register the connection address in DNS.

If the DC is running DNS server service, then the DNS service will register the interface
"Host A" record that it has set to listen on. The Zone properties, the Name server tab list
out the IP addresses of interfaces present on the DC. If it has listed both the IPs, then
DNS server will register "Host A" record for both the IP addresses.

We need to make sure only the required interface listens for DNS and the zone
properties, name server tab has required IP address information.

Resolution
To avoid this problem, perform the following three steps (It's important that you follow
all the steps to avoid the issue).

1. Under Network Connections Properties:

On the unwanted NIC TCP/IP Properties, select Advanced > DNS, and then
unselect Register this connections Address in DNS.

2. Open the DNS server console, highlight the server on the left pane, and then select
Action > Properties. On the Interfaces tab, select listen on only the following IP
addresses. Remove unwanted IP address from the list.

3. On the Zone properties, select Name server tab. Along with FQDN of the DC, you'll
see the IP address associated with the DC. Remove unwanted IP address if it's
listed.

After doing it, delete the existing unwanted Host A record of the DC.

More information
Hardware details: IBM servers with two NICs.

1. Ethernet NIC
2. USB NIC (it also can be considered for multiple Ethernet NICs)

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Best practices for DNS client settings in
Windows Server
Article • 12/26/2023

This article describes best practices for the configuration of Domain Name System (DNS)
client settings. The recommendations in this article are for the installation of supported
Windows Server environments where there is no previously defined DNS infrastructure.

Original KB number: 825036

Domain controller with DNS installed

On a domain controller that also acts as a DNS server, Microsoft recommends that you
configure the domain controller's DNS client settings according to these specifications:

If the server is the first and only domain controller that you install in the domain,
and the server runs DNS, configure the DNS client settings to point to that first
server's IP address. For example, you must configure the DNS client settings to
point to itself. Do not list any other DNS servers until you have another domain
controller hosting DNS in that domain.

During the DCPromo process, you must configure additional domain controllers to
point to another domain controller that is running DNS in their domain and site,
and that hosts the namespace of the domain in which the new domain controller is
installed. or if using a 3rd-party DNS to a DNS server that hosts the zone for that
DC's Active Directory domain. Do not configure the domain controller to utilize its
own DNS service for name resolution until you have verified that both inbound
and outbound Active Directory replication is functioning and up to date. Failure to
do so may result in DNS "Islands".
For more information about a related topic, click the following article number to
view the article in the Microsoft Knowledge Base:

275278 DNS Server becomes an island when a domain controller points to itself
for the _msdcs.ForestDnsName domain

After you've verified that replication has completed successfully, DNS may be
configured on each Domain Controller in either of two ways, depending on the
requirements of the environment. The configuration options are:
Configure the Preferred DNS server in TCP/IP properties on each Domain
Controller to use itself as Primary DNS Server.
 Advantages: Ensures that DNS queries originating from the Domain
Controller will be resolved locally if possible. Will minimize impact of Domain
Controller's DNS queries on the network.
Disadvantages: Dependent on Active Directory replication to ensure that
DNS zone is up to date. Lengthy replication failures may result in an
incomplete set of entries in the zone.
Configure all Domain Controllers to use a centralized DNS server as their
Preferred DNS Server.
Advantages:
Minimizes the reliance on Active Directory replication for DNS zone
updates of Domain Controller locator records. It includes faster discovery
of new or updated Domain Controller locator records, as replication lag
time isn't an issue.
Provides a single authoritative DNS server, which may be useful when
troubleshooting Active Directory replication issues
Disadvantages:
Will more heavily use the network to resolve DNS queries originating from
the Domain Controller
DNS name resolution may depend on network stability. Loss of
connectivity to the Preferred DNS server will result in failure to resolve
DNS queries from the Domain Controller. It may result in apparent loss of
connectivity, even to locations that aren't across the lost network
segment.

A combination of the two strategies is possible, with the remote DNS server set as
Preferred DNS server, and the local Domain Controller set as Alternate (or vice
versa). While this strategy has many advantages, there are factors that should be
considered before making this configuration change:
The DNS client does not utilize each of the DNS servers listed in TCP/IP
configuration for each query. By default, on startup the DNS client will attempt
to use the server in the Preferred DNS server entry. If this server fails to respond
for any reason, the DNS client will switch to the server listed in the alternate
DNS server entry. The DNS client will continue to use this alternate DNS server
until:
It fails to respond to a DNS query, or:
The ServerPriorityTimeLimit value is reached (15 minutes by default).

７ Note

Only a failure to respond will cause the DNS client to switch Preferred DNS servers;
receiving an authoritative but incorrect response does not cause the DNS client to
 try another server. As a result, configuring a Domain Controller with itself and
another DNS server as Preferred and Alternate servers helps to ensure that a
response is received, but it does not guarantee accuracy of that response. DNS
record update failures on either of the servers may result in an inconsistent name
resolution experience.

Don't configure the DNS client settings on the domain controllers to point to DNS
servers of your Internet Service Provider (ISP). If you configure the DNS client
settings to point to your ISP's DNS servers, the Netlogon service on the domain
controllers doesn't register the correct records for the Active Directory directory
service. With these records, other domain controllers and computers can find
Active Directory-related information. The domain controller must register its
records with its own DNS server.

To forward external DNS requests, add the ISP's DNS servers as DNS forwarders in the
DNS management console. If you don't configure forwarders, use the default root hints
servers. In both cases, if you want the internal DNS server to forward to an Internet DNS
server, you also must delete the root "." (also known as "dot") zone in the DNS
management console in the Forward Lookup Zones folder.

If the domain controller that hosts DNS has several network adapters installed, you
must disable one adapter for DNS name registration.

For more information about how to configure DNS correctly in this situation, click the
following article number to view the article in the Microsoft Knowledge Base:

292822 Name resolution and connectivity issues on a Routing and Remote Access
Server that also runs DNS or WINS

To verify your domain controller's DNS client settings, type the following command at a
command prompt to view the details of your Internet Protocol (IP) configuration:
ipconfig /all

To modify the domain controller's DNS client configuration, follow these steps:

1. Right-click My Network Places, and then select Properties.

2. Right-click Local Area Connection, and then select Properties.

3. Select Internet Protocol (TCP/IP), and then select Properties.

4. Select Advanced, and then select the DNS tab. To configure the DNS information,
follow these steps:
 a. In the DNS server addresses, in order of use box, add the recommended DNS
server addresses.
b. If the For resolution of unqualified names setting is set to Append these DNS
suffixes (in order), Microsoft recommends that you list the Active Directory DNS
domain name first (at the top).
c. Verify that the DNS Suffix for this connection setting is the same as the Active
Directory domain name.
d. Verify that the Register this connection's addresses in DNS check box is
selected.
e. Select OK three times.

5. If you change any DNS client settings, you must clear the DNS resolver cache and
register the DNS resource records. To clear the DNS resolver cache, type the
following command at a command prompt: ipconfig /flushdns
To register the DNS resource records, type the following command at a command
prompt: ipconfig /registerdns

6. To confirm that the DNS records are correct in the DNS database, start the DNS
management console. There should be a host record for the computer name. (This
host record is an "A" record in Advanced view.) There also should be a Start of
Authority (SOA) record and a Name Server (NS) record that points to the domain
controller.

Domain controller without DNS installed

If you do not use Active Directory-integrated DNS, and you have domain controllers that
do not have DNS installed, Microsoft recommends that you configure the DNS client
settings according to these specifications:

Configure the DNS client settings on the domain controller to point to a DNS
server that's authoritative for the zone that corresponds to the domain where the
computer is a member. A local primary and secondary DNS server is preferred
because of Wide Area Network (WAN) traffic considerations.
If there's no local DNS server available, point to a DNS server that's reachable by a
reliable WAN link. Up-time and bandwidth determine reliability.
Don't configure the DNS client settings on the domain controllers to point to your
ISP's DNS servers. Instead, the internal DNS server should forward to the ISP's DNS
servers to resolve external names.

Windows Server member servers

On Windows Server member servers, Microsoft recommends that you configure the
DNS client settings according to these specifications:

Configure the primary and secondary DNS client settings to point to local primary
and secondary DNS servers (if local DNS servers are available) that host the DNS
zone for the computer's Active Directory domain.
If there are no local DNS servers available, point to a DNS server for that
computer's Active Directory domain that can be reached through a reliable WAN
link. Up-time and bandwidth determine reliability.
Don't configure the client DNS settings to point to your ISP's DNS servers. If you
do so, you may experience issues when you try to join the Windows Server-based
server to the domain, or when you try to log on to the domain from that computer.
Instead, the internal DNS server should configure forwarding to the ISP's DNS
servers to resolve external names.

Windows Server non-member servers

If you have servers that aren't configured to be part of the domain, you can still
configure them to use Active Directory-integrated DNS servers as their primary
and secondary DNS servers. If you have non-member servers in your environment
that use Active Directory-integrated DNS, they don't dynamically register their
DNS records to a zone that's configured to accept only secure updates.
If you don't use Active Directory-integrated DNS, and you want to configure the
non-member servers for both internal and external DNS resolution, configure the
DNS client settings to point to an internal DNS server that forwards to the Internet.
If only Internet DNS name resolution is required, you can configure the DNS client
settings on the non-member servers to point to the ISP's DNS servers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Error when you try delete a record from
a DNS zone: The record cannot be
deleted
Article • 12/26/2023

This article provides a workaround for an issue where you receive an error message
when you try to delete a record from a DNS zone.

Applies to: Windows Server 2012 R2

Original KB number: 837335

Symptoms
As member of the DnsAdmins security group, you may not be able to delete zone
information on a DNS server. If you try to delete a record, you may receive the following
error message:

The record cannot be deleted Access Denied

Cause
This issue may occur if security permissions for the DnsAdmins security group aren't
automatically added on the newly created Active Directory Integrated zones.

Workaround
To work around this issue, manually add the DnsAdmins security group to the zone
access control list (ACL) and grant Full Control.

To do so, use one of the following methods to assign Full Control to DnsAdmins security
group.

Method 1: Use the Dsacls.exe tool to assign Full Control

permissions to the DNSAdmins group
1. Log on to your computer as administrator.

2. Click Start, click Run, type cmd, and then click OK.
 3. Type the following command, and then press ENTER:

Console

dsacls "\\servername\CN=MicrosoftDNS, CN=System, DC=domain, dc=com" /G

DNSADMINS:GA / I:T

For more information about the Dsacls tool, see Dsacls.

Method 2: Use ADSI Editor to assign Full Control

permissions to the DNSAdmins group
1. Log on to your computer as administrator.

2. Click Start, click Run, type adsiedit.msc, and then click OK.

3. Expand Domain NC.

This node contains a folder that begins with DC= and reflects the correct domain
name, such as DC=exampledomain DC=net.

4. Expand CN=System, and then click CN=MicrosoftDNS.

5. In the right pane, right-click the folder where you want to change the permissions,
and then click Properties.

6. In the DomainComponent properties dialog box, click the Security tab.

7. In the DnsAdmins Permissions list, click to select the Full Control check box for the
Allow column, and then click OK two times.

8. On the File menu, click Exit.

Method 3: Use DNS to assign Full Control permissions to

the DnsAdmins group
1. Click Start, point to All Programs, point to Administrative Tools, and then click
DNS.
2. In the console tree, click the applicable zone.
3. On the Action menu, click Properties.
4. In the Properties dialog box for the zone, click Security, and then click Add.
5. In the Select Users, Computers, or Groups dialog box, type DnsAdmins, and then
click OK in the Enter the object names to select text box.
 6. In the Permissions list for DnsAdmins, click to select the Full Control check box for
the Allow column.
7. Click Advanced, click DnsAdmins, and then click Edit.
8. In the Apply onto drop-down menu, click to select This object and all child
objects.
9. Click OK three times.
10. On the File menu, click Exit.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

You can't modify the Hosts file or the
Lmhosts file
Article • 03/09/2024

This article provides a workaround for a problem in which you can't modify the Hosts
file or the Lmhosts file.

Applies to: Windows, all versions, and Windows Server, all versions
Original KB number: 923947

Symptoms
When you try to change the Hosts file or the Lmhosts file, Windows might deny you
access to the file and then generate an error message that resembles either of the
following messages.

Error message 1

Access to C:\Windows\System32\drivers\etc\ hosts was denied

Error message 2

Cannot create the C:\Windows\System32\drivers\etc\hosts file.

Make sure that the path and file name are correct.

This problem occurs even though you sign in by using an account that has
administrative credentials.

Workaround
1. Select Start > All Programs > Accessories, right-click Notepad, and then select
Run as administrator.

If you're prompted for an administrator password or for a confirmation, type the

password, or select Allow or Yes.

2. Open the Hosts file or the Lmhosts file, make the necessary changes, and then
select Save on the File menu.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Microsoft Exchange compatibility with
Single Label Domains, Disjointed
Namespaces, and Discontiguous
Namespaces
Article • 12/26/2023

This article describes the compatibility of Microsoft Exchange with Single Label Domains,
Disjoint Namespaces, and Discontiguous Namespaces.

Applies to: Windows Server 2012 R2

Original KB number: 2269838

Single Label Domains

For a description of Single Label Domains, see the Single Label Domains topic in the
Microsoft DNS Namespace Planning Solution Center.

Disjoint Namespaces
For a description of Disjoint Namespaces, see the Disjoint Namespaces topic in the
Microsoft DNS Namespace Planning Solution Center.

Discontiguous Namespaces
For a description of Discontiguous Namespaces, also known as a non-contiguous
namespaces, see the Discontiguous Namespaces topic in the Microsoft DNS Namespace
Planning Solution Center.

Exchange Server
In response to customer feedback, the Exchange team has updated its testing matrix
and has determined that Exchange Server 2010 will be supported on SLDs, Disjoint
Namespaces, and Discontiguous Namespaces. This page contains a brief description of
each of these scenarios and special considerations.

７ Note
 For information about disjoint namespace scenarios in Microsoft Exchange Server
2013, visit the following TechNet website:

Disjoint namespace scenarios

In adding support for these types of topologies, there's an underlying requirement for
DNS to be correctly installed and configured. Before users continue with any
deployment that is defined here, clients and servers must be able to reliably resolve DNS
queries for a given resource in the appropriate namespace.

Single Label Domains

Although Exchange 2010 is supported with SLDs, the Exchange product team's view is
that SLDs aren't a recommended configuration and may not be supported by future
Exchange versions. Other Microsoft or third-party applications that you want to run in
your environment may not be supported on an SLD. This could have an adverse effect
on your environment. Although we'll allow the installation of Exchange 2010 in an SLD,
we strongly recommend that you take steps to move your organization out of this
configuration.

Disjoint Namespaces
In Microsoft Exchange 2010, there are three supported scenarios for deploying
Exchange in a domain that has a disjoint namespace. The supported scenarios are as
follows:

Scenario 1: The primary DNS suffix of the domain controller isn't the same as the
DNS domain name. Computers that are members of the domain can be either
disjoint or not disjoint.
Scenario 2: A member computer in an Active Directory domain is disjoint even
though the domain controller isn't disjoint.
Scenario 3: The NetBIOS domain name of the domain controller isn't the same as
the subdomain of the DNS domain name of that domain controller.

For more information about Exchange 2010 and disjoint namespaces, see
Understanding Disjoint Namespace Scenarios.

Special considerations

In Exchange 2010, you may have to configure the DNS suffix search list to include
multiple DNS suffixes if you have a disjoint namespace. For more information, see
 Configure the DNS Suffix Search List for a Disjoint Namespace.
Msds-allowedDNSSuffixes must be configured within the Active Directory

environment for all namespaces that are used within the forest. For information
about how to configure this, see The computer's primary DNS suffix does not
match the FQDN of the domain where it resides.

Discontiguous (noncontiguous) namespaces

For discontiguous namespaces, DNS must be configured so that Exchange servers can
resolve all domain names in the environment. It's also a requirement that msds-
allowedDNSSuffixes are configured within the Active Directory environment for all
namespaces that are used within the forest.

For information about how to configure this, see Understanding DNS Client Settings.

Affected Exchange products

Exchange Server 2013

For more information about Exchange 2013 system requirements, see Exchange
2013 System Requirements.

Exchange Server 2010

For more information about Exchange 2010 system requirements, see the
Exchange 2010 System Requirements article.

Exchange Server 2007

Microsoft has changed the Setup prerequisite rule for SLDs from an Error to a
Warning. This change lets the Service Pack 1 installation continue in SLD
environments.

Exchange Server 2003

References
Product Compatibility page on the DNS Namespace Planning Solution Center

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Configure a secondary name server in
Windows Server 2003
Article • 12/26/2023

This step-by-step article describes how to configure a secondary DNS server.

Applies to: Windows Server 2003

Original KB number: 816518

Identify the secondary name server

On the primary DNS server, identify an additional name server. To do this, follow these
steps:

1. Click Start, point to Administrative Tools, and then click DNS.

2. In the console tree, expand Host name (where Host name is the host name of the
DNS server).

3. In the console tree, expand Forward Lookup Zones.

4. Right-click the zone that you want (for example, example.com ), and then click
Properties.

5. Click the Name Servers tab, and then click Add.

6. In the Server fully qualified domain name (FQDN) box, type the host name of the
server that you want to add.

For example, type namesvr2.example.com .

7. In the IP address box, type the IP address of the name server that you want to add
(for example, 192.168.0.22), and then click Add.

8. Click OK, and then click OK.

9. In the console tree, click Reverse Lookup Zones, right-click the zone that you want,
and then click Properties.

10. Click the Name Servers tab, and then click Add.

11. In the Server name box, type the host name of the server that you want to add.
 For example, namesvr2.example.com .

12. In the IP address box, type the IP address of the name server that you want to add
(for example, 192.168.0.22), and then click Add.

13. Click OK two times.

Install DNS on the secondary name server

To install the DNS service, follow these steps:

1. Log on to the computer as an administrator.

2. Click Start, point to Control Panel, and then click Add or Remove Programs.

3. Click Add\Remove Windows Components.

4. In the Components list, click Networking Services (do not click to select or click to
clear the check box), and then click Details.

5. Click to select the Domain Name System (DNS) check box, and then click OK.

6. On the Windows Components page, click Next.

7. Insert the Windows 2003 Server CD when you are prompted, and then click OK.

8. On the Completing the Windows Components Wizard page, click Finish.

9. Click Close.

DNS is now installed. To start the DNS snap-in, click Start, point to Administrative
Tools, and then click DNS.

Configure the forward lookup zone

To configure the forward lookup zone on the secondary name server, follow these steps:

1. Log on to the secondary name server as an administrator.

2. Click Start, point to Administrative Tools, and then click DNS.
3. In the console tree, under DNS, click Host name (where Host name is the host
name of the DNS server).
4. In the console tree, click Forward Lookup Zones.
5. Right-click Forward Lookup Zones, and then click New Zone.
6. When the New Zone Wizard starts, click Next to continue.
7. Click Secondary Zone, and then click Next.
 8. In the Name box, type the name of the zone (for example, example.com ), and then
click Next.
9. On the Master DNS Servers page, type the IP address of the primary name server
for this zone, click Add, click Next, and then click Finish.

Configure the reverse lookup zone

To configure the reverse lookup zone on the secondary name server, follow these steps:

1. Click Start, point to Administrative Tools, and then click DNS.

2. In the console tree, click Host name (where Host name is the host name of the
DNS server).

3. In the console tree, click Reverse Lookup Zones.

4. Right-click Reverse Lookup Zones, and then click New Zone.

5. When the New Zone Wizard starts, click Next to continue.

6. Click Secondary zone, and then click Next.

7. In the Network ID box, type the network ID (for example, type 192.168.0), and then
click Next.

７ Note

The network ID is that portion of the TCP/IP address that pertains to the
network.

For more information about TCP/IP networks, see Understand TCP/IP Addressing
and Subnetting Basics.

8. On the Zone File page, click Next, and then click Finish.

Troubleshoot an error: The zone is not loaded

by the DNS server
When you select a zone on the secondary name server, you may receive the following
error message in the right pane of the DNS window:

Zone not loaded by DNS Server

 The DNS server encountered an error while attempting to load the zone.
The transfer of zone data from the main server failed.

This issue may occur if zone transfers are disabled. To resolve this issue, follow these
steps:

1. Log on to the primary name server computer as an administrator.

2. Click Start, point to Administrative Tools, and then click DNS.

3. In the console tree, click Host name (where Host name is the host name of the
DNS server).

4. In the console tree, click Forward Lookup Zones.

5. Under Forward Lookup Zones, right-click the zone that you want (for example,
example.com), and then click Properties.

6. Click the Zone Transfers tab.

7. Click to select the Allow zone transfers check box, and then click one of the
following options:

To any server
Only to servers listed on the Name Servers tab
Only to the following servers.

７ Note

If you click Only to the following servers, type the IP address of the
secondary name server in the IP address box, and then click Add.

8. Click Apply, and then click OK.

9. Quit the DNS snap-in.

Troubleshoot DNS
To troubleshoot and obtain information about the DNS configuration, use the Nslookup
utility.

For more information about how to install and configure DNS, see How To Install and
Configure DNS Server in Windows Server 2003 .
Feedback
Was this page helpful?  Yes  No

Provide product feedback

NET: DNS: DNS client resolution
timeouts
Article • 12/26/2023

This document describes the fallback and timeout behavior that exist when one or more
Domain Name System (DNS) Servers IPs are configured on a Windows DNS client.

Applies to: Windows 10 - all editions

Original KB number: 2834226

Summary
For more information, see NET: DNS: Forwarders and Conditional Forwarders resolution
timeouts .

Configuring DNS clients with more than one DNS Server IP adds additional fault
tolerance to your DNS infrastructure. Adding multiple DNS Servers IPs allows DNS
names to continue to be resolved if failures of the only configured DNS Server, of the
underlying network link, or the supporting network infrastructure that connects a given
client to a DNS Server. Such name failures may cause application or component hangs,
resource outages waiting for dependent timeout expirations that directly or indirectly
cause operational failures.

For these reasons, it's recommended to configure any Windows client with more than
one DNS server, but it's important to be aware of the Windows client resolution process,
as it's different based on how many DNS servers we've configured.

What is the default behavior of a DNS client

when a single DNS server is configured on the
NIC
The behavior is the following (tested on Windows XP, Windows 7, and Windows 8 clients
with a single NIC):

ﾉ Expand table
 Time (seconds since Action
start)

0 Client queries the DNS server

1 If no response is received after 1 second, client queries again the DNS

server

2 If no response is received after 1 more second, client queries again the

DNS server

4 If no response is received after 2 more seconds, client queries again

the DNS server

8 If no response is received after 4 more seconds, client queries again

the DNS server

10 If no response is received after 2 more seconds, client stops querying

Any Name Error response by the DNS server will cause the process to stop - client
doesn't retry if the response was negative.

In this scenario, the client is then trying to query the same DNS server five times before
timing out.

Example

Windows 8 Client with a single DNS server configured, querying for Microsoft.com

Ipconfig on the client

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1

Network Monitor output

Time Time Offset TimeDelta Source Dest Details

6:23:33.8063812 0.0000000 0.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0xA5B4,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:23:34.8026943 0.9963131 0.9963131 10.0.0.31 10.0.0.1 DNS:QueryId = 0xA5B4,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet
 6:23:35.8042696 1.9978884 1.0015753 10.0.0.31 10.0.0.1 DNS:QueryId = 0xA5B4,
QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:23:37.8184257 4.0120445 2.0141561 10.0.0.31 10.0.0.1 DNS:QueryId = 0xA5B4,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:23:41.8394589 8.0330777 4.0210332 10.0.0.31 10.0.0.1 DNS:QueryId = 0xA5B4,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

What is the default behavior of a Windows XP

DNS client when two DNS servers are
configured on the NIC
The behavior is the following (tested on Windows XP clients with a single NIC):

ﾉ Expand table

Time (seconds Action

since start)

0 Client queries the first DNS server of the list

1 If no response is received after 1 second, client queries the second DNS

server of the list and at the same time queries again the first DNS server

3 If no response is received after 2 more seconds, client queries again the first
DNS server

7 If no response is received after 4 more seconds, client queries again the first
DNS server

9 If no response is received after 2 more seconds, client stops querying

Any Name Error response by any of the DNS servers will cause the process to stop -
client doesn't retry with the next server if the response was negative. Client tries new
servers only if the previous are unreachable.

In this scenario, the client is then trying to query mostly the first DNS server, and the
secondary once.

Example
Windows XP Client with two DNS servers configured querying for Microsoft.com

Ipconfig on the client

Console

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
10.0.0.2

Network Monitor output

Time Time Offset TimeDelta Source Dest Details

6:39:09.8013750 0.0000000 0.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0x1960,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:39:10.8013750 1.0000000 1.0000000 10.0.0.31 10.0.0.2 DNS:QueryId = 0x1960,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:39:10.8013750 1.0000000 0.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0x1960,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:39:12.8013750 3.0000000 2.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0x1960,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:39:16.8013750 7.0000000 4.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0x1960,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

What is the default behavior of a Windows 7 or

Windows 8 DNS client when two DNS servers
are configured on the NIC
The behavior is the following (tested on Windows 7 and Windows 8 clients with a single
NIC):

ﾉ Expand table
 Time (seconds since Action
start)

0 Client queries the first DNS server of the list

1 If no response is received after 1 second, client queries the second DNS

server of the list

2 If no response is received after 1 more second, client queries again the

second DNS server of the list

4 If no response is received after 2 more seconds, client queries all the

servers in the list at the same time

8 If no response is received after 4 more seconds, client queries all the

servers in the list at the same time

10 If no response is received after 2 more seconds, client stops querying

Any Name Error response by any of the DNS servers will cause the process to stop -
client doesn't retry with the next server if the response was negative. Client tries new
servers only if the previous are unreachable.

Example

Windows 8 Client with two DNS servers configured querying for Microsoft.com

Ipconfig on the client

Console

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
10.0.0.2

Network Monitor output

Time Time Offset TimeDelta Source Dest Details

6:28:12.5060330 0.0000000 0.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:28:13.5129164 1.0068834 1.0068834 10.0.0.31 10.0.0.2 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet
 6:28:14.5124283 2.0063953 0.9995119 10.0.0.31 10.0.0.2 DNS:QueryId = 0x7B1C,
QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:28:16.5288823 4.0228493 2.0164540 10.0.0.31 10.0.0.1 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:28:16.5289050 4.0228720 0.0000227 10.0.0.31 10.0.0.2 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:28:20.5582196 8.0521866 4.0293146 10.0.0.31 10.0.0.1 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

6:28:20.5582475 8.0522145 0.0000279 10.0.0.31 10.0.0.2 DNS:QueryId = 0x7B1C,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

What is the default behavior of a DNS client

when three or more DNS servers are
configured on the NIC
How many of them are used and what are the timeouts?

The behavior is the following (tested on Windows XP, Windows 7, and Windows 8 clients
with a single NIC):

ﾉ Expand table

Time (seconds since Action

start)

0 Client queries the first DNS server of the list

1 If no response is received after 1 second, client queries the second DNS

server of the list

2 If no response is received after 1 more second, client queries the third

DNS server of the list

4 If no response is received after 2 more seconds, client queries all the

servers in the list at the same time
 Time (seconds since Action
start)

8 If no response is received after 4 more seconds, client queries again all the
servers in the list at the same time

10 If no response is received after 2 more seconds, client stops querying

Any Name Error response by any of the DNS servers will cause the process to stop -
client doesn't retry with the next server if the response was negative. Client tries new
servers only if the previous are unreachable.

If the only reachable server is in position 4 or higher, we have an expected delay of at

least 4 seconds after the original query before actually trying it. This can cause issues if
the application that has requested the DNS resolution has an application resolution
timeout lower than this value. The only way to have this server queried earlier will be to
set it in the first three positions.

Example

Client with five DNS servers configured querying for Microsoft.com

Ipconfig on the client

Console

Pv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.4
10.0.0.5

Network Monitor output

Time Time Offset TimeDelta Source Dest Details

9:50:19.4165728 0.0000000 0.0000000 10.0.0.31 10.0.0.1 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:20.4030068 0.9864340 0.9864340 10.0.0.31 10.0.0.2 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet
9:50:21.4053190 1.9887462 1.0023122 10.0.0.31 10.0.0.3 DNS:QueryId = 0xE2A2,
QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:23.4022371 3.9856643 1.9969181 10.0.0.31 10.0.0.1 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:23.4022575 3.9856847 0.0000204 10.0.0.31 10.0.0.2 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:23.4022646 3.9856918 0.0000071 10.0.0.31 10.0.0.3 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:23.4023130 3.9857402 0.0000484 10.0.0.31 10.0.0.4 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:23.4023347 3.9857619 0.0000217 10.0.0.31 10.0.0.5 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:27.4113578 7.9947850 4.0090231 10.0.0.31 10.0.0.1 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:27.4113788 7.9948060 0.0000210 10.0.0.31 10.0.0.2 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:27.4113860 7.9948132 0.0000072 10.0.0.31 10.0.0.3 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:27.4113932 7.9948204 0.0000072 10.0.0.31 10.0.0.4 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet

9:50:27.4114034 7.9948306 0.0000102 10.0.0.31 10.0.0.5 DNS:QueryId = 0xE2A2,

QUERY (Standard query), Query for microsoft.com of type Host Addr on class
Internet
More information
Shall the client have more than one NIC active with different DNS servers configured on
them, the client resolution behavior is slightly different.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS namespace planning
Article • 12/26/2023

This article describes the design of the DNS namespace in an Active Directory
environment.

Applies to: Windows Server 2003

Original KB number: 254680

Summary
The resolution of names through the use of Domain Name System (DNS) is central to
Windows operation. Without proper name resolution, users can't locate resources on
the network. It's critical that the design of the DNS namespace is created with Active
Directory in mind and that the namespace that exists on the Internet not conflict with an
organization's internal namespace.

More information
The recommended approach to DNS design in an Active Directory environment is to
design the Active Directory environment first and then support that design with the DNS
structure. However, in some cases, the DNS namespace may already be in place. In such
a configuration, the Active Directory environment should be designed independently
and then implemented either as a separate namespace or as a subdomain of the
existing namespace. If the namespace you choose already exists on the Internet, it may
cause name resolution problems for internal clients.

Consider the following items:

Identify the DNS namespace that you'll be using for your domain. Identify the
name that your organization has registered for use on the Internet (for example,
company.com). If your company doesn't have a registered name, but you'll be
connected to the Internet, you may want to register a name on the Internet. Make
sure if you choose not to register a name that you choose a name that is unique.
You can review existing names at network solutions .
Use different internal and external namespaces. Internally, you could use
comp.com or a subdomain of the external name such as corp. company.com. The
subdomain structure could be useful if you already have an existing DNS
namespace. Different locations or organizations can be named with different
 subdomains such as nameone. corp. company.com or nametwo. corp.
company.com to ease administration.
Make Active Directory child domains immediately subordinate to their parent
domains in the DNS namespace. You can choose to create subdomains for
organizations within your company or locations. For example, leveltwo. levelone.
corp. company.com
Separate internal and external names on separate servers. External servers should
include only those names that you want to be visible to the Internet. Internal
servers should contain names that are for internal use. You can set your internal
DNS servers to forward requests that they can't resolve to external servers for
resolution. Different types of clients require different kinds of name resolution.
Web proxy clients, for example, don't require external name resolution because the
proxy server does this on their behalf. Overlapping internal and external
namespaces aren't recommended. In most cases, the end result of this
configuration is that computers will be unable to locate needed resources because
of receiving incorrect IP addresses from DNS. This is particularly a concern when
Network Address Translation (NAT) is involved and the external IP address is in an
unreachable range for internal clients.
Make sure that root servers aren't created unintentionally. Root servers may be
created by the Dcpromo Wizard, resulting in internal clients being able to reach
external clients or to reach parent domains. If the "." zone exists, a root server has
been created. It may be necessary to remove this for proper name resolution to
work.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Some DNS name queries are
unsuccessful after you deploy a
Windows-based DNS server
Article • 12/26/2023

This article describes an issue where DNS queries to some domains may not be resolved
successfully after you deploy a Windows-based DNS server.

Applies to: Windows Server 2012 R2

Original KB number: 832223

Symptoms
After you deploy a Windows-based DNS server, DNS queries to some domains may not
be resolved successfully.

Cause
This issue occurs because of the Extension Mechanisms for DNS (EDNS0) functionality
that is supported in Windows Server DNS.

EDNS0 allows larger User Datagram Protocol (UDP) packet sizes. However, some firewall
programs may not allow UDP packets that are larger than 512 bytes. Therefore, these
DNS packets may be blocked by the firewall.

Resolution
To resolve this issue, update the firewall program to recognize and allow UDP packets
that are larger than 512 bytes. For more information about how to do this, contact the
manufacturer of your firewall program.

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

Workaround
To work around this issue, turn off the EDNS0 feature on Windows-based DNS servers.
To do this, take the following action:

At a command prompt, type the following command, and then press Enter:

Console

dnscmd /config /enableednsprobes 0

７ Note

Type a 0 (zero) and not the letter "O" after "enableednsprobes" in this command.

The following information appears:

Registry property enableednsprobes successfully reset.

Command completed successfully.

７ Note

Dnscmd.exe is installed on all Windows-based DNS servers except servers that are
running Windows Server 2003 or Windows Server 2003 R2. You can install
Dnscmd.exe from the Windows Server 2003 Support Tools. To download the
Windows Server 2003 Support Tools, click the following Microsoft Download Center
link: Setspn

More information
Some firewalls contain features to check certain parameters of the DNS packet. These
firewall features may make sure that the DNS response is smaller than 512 bytes. If you
capture the network traffic for an unsuccessful DNS lookup, you may notice that DNS
requests EDNS0. Frames that resemble the following don't receive a reply:

Additional records
<Root>: type OPT, class unknown
Name: <Root>
Type: EDNS0 option
UDP payload size: 1280
In this scenario, the firewall may drop all EDNS0-extended UDP frames.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Unexpected DNS record registration
behavior if DHCP server uses "Always
dynamically update DNS records"
Article • 12/26/2023

Applies to: Windows 11, Windows 10, Windows 8.1

Symptoms
You have an infrastructure that uses Windows Dynamic Host Configuration Protocol
(DHCP) clients and Microsoft DHCP servers to assign and manage IP addresses. On the
DHCP server, you select Enable DNS dynamic updates according to the settings below
and Always dynamically update DNS records. In this configuration, you expect the
DHCP server to manage dynamic DNS updates for A records and PTR records. However,
you observe that both the client and the server create DNS records. Depending on your
configuration, this behavior has the following effects:

If you configure the DNS zones for Nonsecure and secure dynamic updates, you
see that the DHCP server creates records, and then the DHCP client deletes and re-
creates the same records.
If you configure the DNS zones for Secure only dynamic updates, DNS records
might become inconsistent. Both the DHCP server and the DHCP client create
records. However, the DHCP server can't update records that the DHCP client
creates, and the DHCP client can't update records that the DHCP server creates.

Cause
To obtain an IP address, the DHCP client sends a DHCP Request message to the DHCP
server. Typically, this message includes the client's fully qualified domain name (FQDN)
and flags that govern dynamic DNS update behavior. This information is collectively
named Option 81 (also known as the Client FQDN option).

７ Note

Some older DHCP clients do not use Option 81. To provide dynamic updates for
these clients, configure the DHCP server to enable the Dynamically update DNS
 records for DHCP clients that do not request updates (for example, clients
running Windows NT 4.0) option.

The DHCP server also stores a set of Option 81 flags that govern dynamic DNS update
behavior. Part of the DHCP DORA (Discover/Offer/Request/Acknowledge) process
involves a comparison between the client and the server of their values of the Option 81
flags to determine who is responsible for DNS updates. The flags that are involved in the
behavior that's described in the Symptoms section are named the O (override) and S
(server) bits. The flags function as follows:

If S = 0, the client is responsible for updating A records.

If S = 1, the server is responsible for updating A records.
If the S value that the client sends in its request differs from the server's S value,
the server sets its O value to 1.

As described in the RFC, the DHCP server's reply to the request message should include
its flag values. If O is set to 1 in the server's message, the client should understand that
the server is overriding the client's S value.

In Windows 8.1, a deliberate design change was introduced to the DHCP client's
dynamic DNS update behavior. This change supports continued development and
enhancements of the TCP/IP (Transmission Control Protocol/Internet Protocol) stack in
later versions of Microsoft operating systems. In Windows 8.1 and later versions, the
DHCP client doesn't honor the DHCP server's Option 81 O and S values. If the client is
configured to update A records, it continues to do this even if the server is also
configured to update A records. That's the case when you select Always dynamically
update DNS records in the DHCP management console.

If you configure your DNS zones for Secure only dynamic updates, then only the entity
(the DHCP client, DHCP server, or an account that the DHCP services are configured to
use) that created a DNS record can update or delete that record. If the DHCP client and
not the DHCP server creates a DNS record, the DHCP server can't modify that record
later.

７ Note

Microsoft's DHCP client doesn't provide a method to directly set the client's O and
S values in the user interface. By default, both values are 0. You can view the values
by recording a netsh trace of a DHCP client request, and by using a tool such as
Netmon to view the results.
 You can use the Windows PowerShell cmdlet, Get-DhcpServerv4OptionValue, to
view the DHCP server's Option 81 value. However, the cmdlet reports this value as a
single integer that combines several different settings as bit values. For example, if
you select Always dynamically update DNS records on the DNS tab of a DHCP
scope properties window, this sets the S value to 1. But the cmdlet reports one of
eight possible values for Option 81. All of these use S=1. The specific value depends
on the combination of settings that are made on the DNS tab.

For more information about how dynamic updates work between the DHCP client, the
DHCP server, and the DNS server, see DNS Processes and Interactions

Resolution
If your architecture requires that you use Always dynamically update DNS records, you
can create a registry key on the client computer to force the DHCP client to honor the
DHCP server override.

） Important

This section, method, or task contains steps that tell you how to modify the registry.
However, serious problems might occur if you modify the registry incorrectly.
Therefore, make sure that you follow these steps carefully. For protection, back up
the registry before you modify it so that you can restore it if a problem occurs. For
more information about how to back up and restore the registry, see How to back
up and restore the registry in Windows .

1. Navigate to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

2. Under the subkey, create the following entry:

Name: RegistrationOverwrite
Type: REG_DWORD
Value: 2

７ Note

RegistrationOverwrite has the following possible values:

0 - No overwrite.
 1 - Records that the DNS client creates overwrite records that the DHCP
server creates. This is the default value.
2 - Records that the DHCP server creates overwrite records that the DNS
client creates).

3. Restart the client computer.

4. In the DNS server management console, check the forward and reverse lookup
zones. Depending on your specific environment, you might have to manually
delete A and PTR records that the DHCP server doesn't have permission to delete
or change.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Cumulative list of reasons that cause
DNS records to disappear from DNS
zones
Article • 12/26/2023

This article lists the causes of the issue where DNS records don't show in a DNS zone.

Applies to: Windows Server 2012 R2

Original KB number: 2985877

Symptoms
Successfully registered DNS records are no longer present in a DNS zone.

Cause
Multiple root causes exist, and they're listed in the following table:

ﾉ Expand table

Cause Issue Synopsis

1 DNS Scavenging is The Scavenging feature on one or more DNS Servers was
misconfigured. configured to have overly aggressive settings and is
prematurely deleting DNS records for AD-integrated DNS
zones.

2 DNS zones are CNF or The container representing the DNS zone in Active
conflict mangled in Active Directory has become CNF or conflict mangled. It was
Directory. replaced by a different container that may first be empty or
contain a subset of the records contained in the previous
instance of the zone.

3 DnsAvoidRegisterRecord A code defect exists if SRV record registration is excluded

defined in a Group Policy by using the DC locator DNS records not registered by the
Object (GPO). DCs Group Policy setting. It modifies the
DnsAvoidRegisterRecords registry setting under the
hklm\software\policies\microsoft\netlogon\parameters
registry subkey.

4 Windows Server 2008 The bug causes records to be deleted from secondary
zone transfer deletion zones on Windows Server 2008 DNS Servers following zone
 Cause Issue Synopsis

bug. transfer.

5 Host "A" record is deleted A timing bug causes the premature deletion of host "A"
when the IP address is records when the DNS Server IP is changed.
changed. It occurs in
Windows Vista, Windows
Server 2008, Windows 7,
or Windows Server 2008
R2.

6 DHCP clients configured Windows 7 and Windows Server 2008 R2-based computers
with Option 81 deregister which receive DHCP-assigned addresses have Option 81
host "A" records during defined on the DHCP server. They deregister host "A"
host "AAAA" registration. records during "AAAA" record registration.

7 Timing issue caused when A DNS client's DNS Host record is deleted after you change
you change DNS server IP the DNS server IP address on the same client.
unless KB2520155 is
installed.

8 Record registration DNS dynamic update protocol updates for existing records
failures make records fail. So the records timestamp doesn't update. It makes the
vulnerable to the record vulnerable to deletion by a correctly configured DNS
scavenging process. Scavenging process.

9 DNS records are deleted DNS records that are currently registered by a DHCP-
when a given Windows enabled Windows client are deleted by the DHCP server.
client dynamic lease is The deletion occurs when the client's dynamic lease is
changed to a reservation. transitioned to a reservation, and the following settings are
enabled:
"Always dynamically update DNS A and PTR records"
"Discard A and PTR records when lease is deleted"
"Dynamically update DNS A and PTR records for
DHCP clients that don't request update"

Affected DNS records include the host "A," host "AAAA,"

and PTR records.

Resolution

Cause 1: DNS scavenging is misconfigured

Scavenging is the most common culprit when DNS records go missing from DNS zones.
Even Windows-based computers that have statically assigned servers register their
records every 24 hours. Verify that the NoRefresh and Refresh intervals are too low. For
example, if these values are both less than 24 hours, then you'll lose DNS records.

TechNet: Using DNS aging and scavenging

Cause 2: DNS zones are CNF or conflict mangled in Active

Directory
With exceptions, Active Directory allows for any domain controller to originate creating
an object in a writable directory partition. When two domain controllers create the same
object or container inside a replication window, the directory applies conflict resolution
logic to determine:

which object should remain.

which object should be quarantined.

When the replication of objects causes a name conflict (two objects have the same
name within the same container, or have the same container name), the directory
automatically renames one of the objects to have a unique name. Specifically, a "*CNF:
<GUID>" string is appended to the DN path of the created object. And the instance
created by the last writer domain controller remains.

If the container representing a DNS zone (or subordinate container) becomes conflict
mangled, the container representing a more complete copy of a DNS zone can be
replaced by container with the same name that's (at first) less complete or even empty.

Determine which copy of the zone should remain. Delete the bad copy of the zone,
which may be the one with the non-CNF-mangled DN path. Rename the CNF-mangled
copy of the zone as required. Then restart the DNS Server service or reload zones.

Cause 3: DnsAvoidRegisterRecord defined in a GPO

Cause 3 is related to a code defect in which SRV records are excluded by using the
DnsAvoidRegisterRecords setting in a GPO. The DNS server targeted by a Windows
client receives record updates once every five minutes. The timestamp and the version
number on dnsRecord constantly increase. SRV records are stored in dnsRecord
attribute, which is a non-linked multi-valued attribute. The domain controller, or DNS
server that receives the incorrect updates always wins the conflict resolution. Some
updates are lost, while other deleted records mysteriously come back.

SRV record loss associated with a mass restart has the same issue with last-writer wins
behavior on the non-linked multivalued attributes. But version churn caused by the GPO
isn't going to the source of the registrations. The mass restarts of lots of domain
controllers is the cause of the concurrent registrations. Some administrators have
worked around this behavior by lowering the SRV registration window.

A good solution to this problem is to configure the DNS client on domain controllers
point off-box DNS Servers addresses as primary for name resolution. Designate local
hub DNS servers per region and have all the DNS servers in that region point that one
DNS server. The hublet DNS servers all point to a single DNS server in a tiered hub-and-
spoke model. All DNS servers can point themselves as secondary's but not primaries.
Because restarts triggered by Windows Update usually occur at 03:00, as long as there's
only one hublet DNS server per time zone, you'll never meet this issue.

Check the Active Directory object version on the dnsNode object that contains the
missing record. If it's a large number, it might be your issue. A possibility is to move the
exclusion of the SRV records to local policy to stop the constant deregistrations.

However, there's an issue with the new behavior. In the new behavior, the SRV records
are removed only once, specifically the first time that the policy is applied. Because the
records are non-linked multi-valued attribute, the following condition can occur:

Multiple domain controllers remove SRV records on different DNS servers before
Active Directory coverage of the zone.

When the underlying attribute is fully converged, the last DNS server to receive a
deletion is the only version that's kept. Only the records that were removed on that DNS
server are removed from the SRV record. The SRV records removed on other DNS
servers seem to come back. Manual cleanup may be required after all domain
controllers have applied the GPO and the affected SRV records are fully converged.

Cause 4: Windows Server 2008 zone transfer delete bug

This issue is resolved by installing Windows Server 2008 Service Pack 2, or KB953317 .
This issue is specific to Windows Server 2008 DNS zones that are hosting secondary
copies of DNS zones. It doesn't occur when the Microsoft DNS Server role is installed on
computers running other versions of Windows.

Cause 5: Host "A" record is deleted when the IP address is

changed
Assume that you change DNS servers' IP addresses on a TCP/IP network stack on
Windows Server 2008 or Windows Server 2008 R2. Then you restart the computer. In
this scenario, sometimes the deletion of the host "A" record occurs on the original DNS
server after the registration of the host A record on the newly configured DNS server IP
address (Active Directory Integrated DNS). From a user perspective, anything that
depends on name resolution is broken.

When the DNS server IP is changed on the client, the client sends an SOA update to
delete its "A" Record from the old DNS server. And it sends another update to register
its "A" Record to the new DNS Server.

This DCR is designed to reduce the number stale host "A" records. Problem occurs in
Active Directory-integrated zones.

This issue arises when the DNS Server IP is changed on the client. When it changes,
client sends the register request to new server and delete request to old server. As both
the servers are already synced up, register won't occur. But deletion happens in the old
server, and then it's deleted in both servers because of Active Directory.

Cause 6: DHCP clients configured with Option 81 de-

register host "A" records during host "AAAA" registration
This problem occurs if Option 81 is defined and ISATAP or 6to4 interfaces are present.
DNS dynamic update protocol update incorrectly sets TTL to 0, which triggers record
deletion for IPv6 record registration.

Cause 7: Timing issue caused when you change DNS

server IP unless KB2520155 is installed
This issue occurs because of an issue in the DNS Client service. When the DNS server
configuration information is changed on a client, the DNS Client service deletes the DNS
host record of the client from the old DNS server. It then adds the record to the new
DNS server. The DNS record is present on the new server, which is a part of the same
domain. So the record isn't updated. But the old DNS server replicates the deletion
operation to the new DNS server and to other DNS servers. So the new DNS server
deletes the record, and the record is deleted across the domain.

Install KB2520155 on Windows Vista, Windows 7, Windows Server 2008, and Windows
Server 2008 R2 computers.

Cause 8: DNS Dynamic Update Protocol updates to

existing records fail causing them to be deleted by the
scavenging process as aged records
Multiple root causes exist for DNS record registration failures.

NETLOGON event 577X events are logged for record registration failures of SRV records
by the NETLOGON service.

Other events are logged for registration failures of host A and PTR records. Check
System logs for these failures. Such events may be logged by the clients that register
these records. Or they may be logged by the DHCP servers that register the records on
the clients' behalf.

Cause 9: Converting an active dynamic lease to a

reservation deletes the A and PTR records for that client
This behavior is by design. The DNS records (A record/PTR) are automatically updated
during the next DHCP renew request from the client.

More information
KB306602 How to optimize the location of a domain controller or global catalog that
resides outside of a client's site

KB953317 A primary DNS zone file may not transfer to the secondary DNS servers in
Windows Server 2008

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows DNS registers duplicate SRV
records for a DC if its computer name
has uppercase letters
Article • 12/26/2023

This article helps fix an issue where Windows DNS registers duplicate server location
(SRV) records for a domain controller if its computer name has uppercase letters.

Applies to: Windows Server 2019, Windows Server 2016

Original KB number: 4496901

Symptoms
You have one or more Windows Server 2019-based or Windows Server 2016-based
domain controllers (DCs) in a deployment that uses AD DS-integrated DNS zones. At
least one of the DCs has a computer name that includes uppercase characters.

In this situation, you notice that the DNS records for the domain include duplicate server
location (SRV) records for the DCs that have uppercase characters in their computer
names. One record includes the computer name in the RDATA in all lowercase
characters, and one record includes the computer name in the RDATA in the same
character case as the computer name.

Cause
This behavior occurs because of a change in how the Windows Server DNS functionality
manages the RDATA segment of an SRV record. In Windows Server 2012 R2 and earlier
versions, the RDATA segment contains only lowercase letters. If a computer name
contains uppercase letters, the DNS functionality converts them to lowercase. However,
the Windows Server 2016 (or later version) DNS functionality accepts uppercase and
lowercase letters.

When the DNS server checks to see whether a computer name already has an
associated SRV record, it does not account for changes in case. Therefore, it considers
winserv16.contoso.com and WinServ16.contoso.com to be different addresses.

For this reason, you may see unexpected effects if you use the following configurations:
 All the DNS servers and DCs in the domain have been upgraded from Windows
Server 2012 R2 (or an earlier version) to Windows Server 2016 (or a later version).
The DNS database may generate extra SRV records for any DC that has uppercase
characters in its computer name.

All the DNS servers and DCs in the domain run Windows Server 2012 or earlier.
You install the DNS server role on a Windows Server 2016 member server, and then
you promote that member server to a DC in the same domain. If the Windows
Server 2016 DC has uppercase characters in its computer name, it will have extra
SRV records in DNS.

You have a domain that contains DCs and DNS servers that run various versions of
Windows Server. The primary DNS server is a DC that runs Windows Server 2012 or
earlier, and the secondary DNS server is a Windows Server 2016 DC. The primary
DNS server becomes unavailable, and you change the Windows Server 2016 DC to
be the new primary DNS server. After this change, the DNS database may generate
extra SRV records for any DC that has uppercase characters in its computer name.

Resolution
Microsoft has released an update that mitigates this issue. The following table lists the
relevant versions of the update for affected versions of Windows.

ﾉ Expand table

Version Release

Windows Server 2019, version March 24, 2020-KB4541335 (OS Builds 18362.752 and
1903 18363.752)

Windows Server 2019, version March 17, 2020-KB4541331 (OS Build 17763.1131)
1809

Windows Server 2016 March 17, 2020-KB4541329 (OS Build 14393.3595)

The update introduces a new Group Policy policy setting in the NETLOGON.ADMX file,
as described in the following table.

ﾉ Expand table
 Policy Use lowercase DNS host names when registering domain controller SRV records
name

Policy Computer Configuration\Policies\Administrative Templates\System\Net Logon\DC

path Locator DNS Records\

Policy 1 (default). The policy is enabled. The policy purges duplicate DNS SRV records.
values When you install the update on a DC, this becomes part of that DC's default local
configuration.
0. The policy is disabled. Under this setting, the problematic behavior continues,
and DCs that have computer names that include uppercase characters continue to
register SRV records that include those uppercase characters. The value of 0 is
supported for only emergency or testing use. It should not be used under typical
conditions.

If the policy is not configured or the value is missing, the DC falls back to the new
default local configuration and treats the policy as enabled.

The update adds the following registry entry that is associated with this policy. (This
information is provided for reference only.)

Registry subkey:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Netlogon\Parameters

Registry entry: DnsSrvRecordUseLowerCaseHostNames

Data type: REG_DWORD

After you install the update

７ Note

You do not have to restart or disable the Netlogon service when you install the
update, manually clean up records, or disable the policy. You do not have to restart
the computer after you install the update.

When you install the update (or enable the policy in an environment in which it has
been disabled), the Netlogon service makes a best-effort attempt to remove existing
DNS records that have uppercase characters.

We recommend that you install this fix (or enable the policy), and then wait a day or two
to allow time for Netlogon to acquire and apply the new setting. Then, wait long
enough for the changes to replicate throughout the environment. After that time,
examine the DNS records for any remaining duplicates. It is likely that the policy will
miss some duplicate records. In that case, you would have to manually remove those
records.
You can use the following Windows PowerShell command to review records:

PowerShell

Get-DnsServerResourceRecord -ZoneName "contoso.com" -RRType Srv

７ Note

In this command, contoso.com is a placeholder domain name.

To remove the remaining duplicate records, run the following PowerShell command:

PowerShell

Remove-DnsServerResourceRecord -ZoneName "contoso.com" -RRType Srv -Name "

<hostname of record to delete>" -RecordData "<recorddata of record to
delete>"​

Disabling the policy does not require any cleanup.

） Important

Microsoft has released an update to resolve this problem and prevent it from
recurring. We recommend that you install the update instead of working around
the problem.

Workaround 1: Prevent duplicate SRV records

You can use the following methods to prevent Windows DNS from creating duplicate
SRV records:

Before you promote a member server to a DC or before you upgrade a DC to

Windows Server 2016 or a later version, make sure that its computer name
contains only lowercase characters.

Make sure that all internal build processes, tools, and scripts that create, modify, or
use computer names also use lowercase characters.

If you cannot rename your DCs (or if it will take a long time to do so), configure
your DNS topology so that DCs that run Windows Server 2016 or later use DNS
servers that run Windows Server 2016 or later. Similarly, configure DCs that run
 Windows Server 2012 R2 or earlier to use DNS servers that run Windows Server
2012 R2 or earlier.

Workaround 2: Remove duplicate SRV records

To work around this issue after you encounter it, you have to rename your DCs by using
all lowercase characters. Depending on the details of your deployment, you may have to
manually reconfigure settings or remove files. This section provides the following
workaround methods, in order of complexity:

Method 1: Rename a DC in a single-DC domain

Method 2: Rename DCs in a multi-DC domain
Method 3: Rename DCs and remove all stored SRV records

） Important

Before using any of these methods, review the following articles. These articles
provide detailed steps to follow to rename a DC. They also provide information
about additional cleanup tasks that you may have to perform after you demote or
rename a DC.

Renaming a Domain Controller and its subtopics

Demoting Domain Controllers and Domains
AD Forest Recovery - Cleaning metadata of removed writable domain
controllers

７ Note

If you encounter any issues after you rename a DC, revert the DC name to its
original content.

Method 1: Rename a DC in a single-DC domain

If you have one DC, use the steps in Renaming a Domain Controller to change the DC's
computer name to a new name that contains only lowercase characters. In the case of a
single DC, you do not have to demote and repromote it.

） Important
 We strongly recommend that any domain contain at least two DCs. If you have only
one DC, any time that DC experiences an issue, your domain may become
unavailable.

Method 2: Rename DCs in a multi-DC domain

If you have more than one DC in your domain, follow these steps for each affected DC:

1. Demote the DC, and clean up the related metadata. For more information, see
Demoting Domain Controllers and Domains and AD Forest Recovery - Cleaning
metadata of removed writable domain controllers.

2. Rename the computer, giving it a name that contains only lowercase characters.

3. Promote the computer to a DC again.

By the time all the DCs are back online, the duplicate (mixed-case) SRV records should
be gone.

Method 3: Rename DCs and remove all stored SRV

records
If Method 1 and Method 2 do not provide satisfactory results, follow these steps for
each affected DC:

1. Demote the DC, and clean up the related metadata. For more information, see
Demoting Domain Controllers and Domains and AD Forest Recovery - Cleaning
metadata of removed writable domain controllers.

2. On the demoted computer, follow these steps:

a. Rename the computer, giving it a name that contains only lowercase characters.
b. Stop the netlogon service. To do this, open an elevated Command Prompt
window, and then run net stop netlogon .
c. Delete the following files in the C:\Windows\System32\config\ folder:

netlogon.dnb
netlogon.dns

3. On one of the other DCs, open Server Manager, select Tools, and then select DNS.

4. In DNS Manager, inspect the containers under Forward Lookup Zones and then
delete the SRV records for the DC that you demoted.
 5. On the renamed computer, start the netlogon service. To do this, open an elevated
Command Prompt window, and then run net start netlogon .

6. Promote the renamed computer to a DC again.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS scavenging setup
Article • 12/26/2023

This article discusses how to set up Domain Name System (DNS) scavenging and gives
an example of setting scavenging up on a pre-existing zone.

Scavenging cleans up (deletes) stale records in DNS. As deletion is involved, many safety
valves are built into scavenging, which takes a long time to enable scavenging.

７ Note

This article focuses on the most common Windows DNS scenario: Windows Server
DNS servers hosting Active Directory (AD)-integrated zones.

In Windows Server, scavenging should be set in all the following three places:

1. On the individual resource record to be scavenged.

2. On a zone to be scavenged.
3. On one or more servers performing scavenging.

Scavenging settings on the resource record

In the DNS Microsoft Management Console (MMC), select View > Advanced and check
the properties of a resource record to see the scavenging settings. For example:
Scavenging on a resource record can be set in three methods:

The first is checking the Delete this record when it becomes stale checkbox and
selecting Apply. When you select Apply, the current time is rounded down to the
nearest hour and applied as the timestamp on the record. The timestamp of static
records is 0, indicating they aren't scavenged.
The second way is when a record is created by a client machine registering using
dynamic DNS (DDNS). Windows clients dynamically update DNS every 24 hours. All
DDNS records are set to scavenge. When a record is first created by a client that
has no existing record, it's considered an "Update," and a timestamp is set. If the
client has an existing host record and changes the IP of the host record, this is also
considered an "Update," and a timestamp is set. If the client has an existing host
record with the same IP address, this is considered a "Refresh," and whether the
timestamp changes depends on zone settings.
The third way to set scavenging on records is using the dnscmd /ageallrecords
command. If you run this command against a zone, it will set scavenging and a
timestamp for all records in the zone, including static records that you don't want
to be scavenged.

Once a timestamp is set on a record, it will be replicated to all servers that host the
zone.

７ Note
 If the zone that hosts the record doesn't enable scavenging, it won't scavenge, so
the timestamp is irrelevant. The timestamp may be updated on the server where
the client dynamically registers, but it won't be replicated to other servers in the
zone.

Scavenging settings on the zone

Before a server checks a record to see if it will be scavenged, the zone should have
scavenging enabled. To access the scavenging settings of a zone, right-click the zone,
select Properties, and then select Aging on the General tab.

７ Note

The screenshot is the same on any DNS server where this zone is replicated.

When you first set scavenging on a zone, the timestamp (seen at the bottom) is set to
the current time of day (rounded down to the nearest hour) plus the Refresh interval.
This setting is also reset whenever the zone is loaded or dynamic updates are enabled
on the zone.
 ７ Note

If you don't see The zone can be scavenged after timestamp, reload the zone.

The zone can be scavenged after timestamp is the first safety valve. It gives clients time
to update their record timestamps. Since new record timestamps aren't replicated when
zone scavenging is disabled, this also gives replication time to keep things in order.

Refresh and No-refresh intervals

The next safety valves are the Refresh and No-refresh intervals. After both intervals have
elapsed, a record can be deleted.

The No-refresh interval is a period of time during which a resource record can't be
refreshed. A "Refresh" is a dynamic update where you don't change the host resource
record; just touch the timestamp. If a client changes the IP of a host record, this is
considered an "Update" and is exempt from the No-refresh interval. The purpose of a
No-refresh interval is to reduce replication traffic. A change to a record means the
change should be replicated.

After the record timestamp plus No-refresh interval has elapsed, you can enter a Refresh
interval. The Refresh interval is the time when refreshes to the timestamp are allowed.
The client is allowed to come in and update its timestamp. This timestamp will be
replicated, and the No-refresh interval will start again. If the client fails to update its
record during the refresh interval, it becomes eligible to be scavenged.

７ Note

When you set the Refresh and No-refresh intervals, allow enough time for clients to
make several registration attempts during the Refresh interval. If you don't do this,
a record may become eligible for scavenging due to a failed refresh attempt.

If you right-click your server and select Set Aging/Scavenging for All Zones…, you'll see
a screenshot similar to the one above. This option sets the default settings that will be
used when this server creates a new zone. Unless you select the Apply these settings to
the existing Active Directory-integrated zones checkbox, the setting doesn't affect
existing zones.

Scavenging settings on the server

To set scavenging on the server, right-click the server in the MMC and select Properties.
Then, select the Enable automatic scavenging of stale records checkbox on the
Advanced tab as follows:

The Scavenging period value is how often this server scavenges. When a server
scavenges, it logs a DNS Event ID 2501 to indicate how many records are scavenged. If
no records are scavenged, Event ID 2502 is logged. Only one server is required to
scavenge since the zone data is replicated to all servers hosting the zone.

 Tip

By getting the timestamp on the most recent Event ID 2501 or 2502 and adding the
scavenging period to it, you can tell exactly when a server will attempt to scavenge.

Although you can set every server hosting the zone to scavenge, we recommend just
having one set. If the server fails to scavenge, it won't have a serious impact. You'll have
one place to look for the suspicion and one set of logs to check. If you have many
servers set to scavenge, you have many logs to check if the scavenging fails.

To control which server is scavenging for a zone, you can use the dnscmd command to
specify exactly which servers may scavenge. For example, the dnscmd
/zoneresetscavengeservers contoso.com 192.168.1.1 192.168.1.2 command allows only

DNS servers with IP addresses of 192.168.1.1 and 192.168.1.2 to scavenge on the

contoso.com zone.

Scavenging process and final checks

You can also manually initiate a scavenging attempt by right-clicking the server and
selecting Scavenge Stale Resource Records. Note that manual attempts won't bypass
the safety valves.

Check the following before you delete the stale records:

Is scavenging enabled on the zone?

Is dynamic update enabled on the zone?
Is the scavenging server listed as one of the scavenging servers for the zone?
Is the "zone can be scavenged after" timestamp on the zone exceeded?
This allows the clients and AD replication to be prepared before you start.
Has it been longer than the refresh interval since this zone was last replicated in
Active Directory?
If scavenging is enabled on a server that has replication issues, this can help
prevent unnecessary tombstoning of records that may still be valid on other
servers.

If all the above checks are passed, the zone is ready for scavenging. At this point, the
scavenging server checks the timestamp on each resource record. If the current date
and time is greater than the timestamp plus No-refresh and Refresh intervals, the record
is deleted.

Example: Setting scavenging up on a pre-

existing zone
Here's an example of setting scavenging up on a pre-existing zone. This procedure is
designed for maximum safety. If using default settings, this process can take four to five
weeks (two weeks for the sanity check phase and two to three weeks for the enable
phase).

Setup phase
1. Turn off scavenging on all servers. You can use the dnscmd
/zoneresetscavengeservers command to limit scavenging to a single server, and
 then ensure this server has scavenging disabled.
2. Turn on scavenging on the zones you want to scavenge. Set the Refresh and No-
refresh intervals as desired. To scavenge more effectively, we recommend lowering
the No-refresh interval and leaving the Refresh interval at the default.
3. Add today's date plus the Refresh and No-Refresh intervals. Come back in a few
weeks when this time has elapsed.

Sanity check phase

Look for any records older than the Refresh plus No-Refresh interval in your DNS
records. If you see any, there's a problem with the dynamic registration process, which
should be corrected before proceeding. A thorough check at this point is the most
important step in the setup.

Things to check if you find old records:

Does the ipconfig /registerdns command work?

Who is the owner of the record (see the Security tab in the record properties)?
Is the record statically created by an administrator and then enabled for
scavenging? If so, you need to delete the record to clear the ownership and run
the ipconfig /registerdns command to update it.
Is the server's Active Directory replication functioning properly?

Don't proceed unless you can explain any outdated records. In the next phase, they'll be
deleted.

Enable phase
You can use the dnscmd /zoneresetscavengeservers command to enable scavenging on
a single server.

Once scavenging is enabled, create a new test record and enable it for scavenging.
Then, map out the point in time when this record disappears. Here are the steps:

1. Start with the timestamp on the record.

2. Add the Refresh interval.
3. Add the No-refresh interval.
4. The result will be your "eligible to scavenge" time. The record won't disappear at
this time, though.
5. Check your DNS event logs for Event IDs 2501 and 2502 to find when the DNS
server will run the scavenging.
 6. Based on your "eligible to scavenge" time, find the most recent Event ID 2501 or
Event ID 2502 event, and add the server's scavenging period (from the Advanced
tab of server properties) to it.
7. This is the point in time when the test record disappears.

For example:

A zone is set to a 3-day Refresh interval and a 3-day No-refresh interval.

The server scavenging period is set to three days.
The last DNS Event ID 2501 or 2502 occurred at 6 am on 1/1/2008.
You have a record with a timestamp of 1/1/2008 at 12:00 (noon).

Given these assumptions, you can predict that the record will be deleted at
approximately 6 am on 1/10/2008. Here's a diagram of the example.

Once scavenging is enabled, you can check periodically to look for the Event ID 2501
and 2502 events to see how things are going. You can also come back at the predicted
date and time and see if your test record has disappeared.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS Server becomes an island when a
domain controller points to itself for the
_msdcs.ForestDnsName domain
Article • 12/26/2023

This article provides a solution to an issue where DNS Server becomes an island when a
domain controller points to itself for the _msdcs.ForestDnsName domain. For more
information, see the Microsoft Support Lifecycle Policy.

Applies to: Windows 2000

Original KB number: 275278

Symptoms
You're using a Microsoft Windows 2000-based domain controller that is running the
Domain Name System (DNS) Server service. The domain controller is authoritative for
the _msdcs.ForestDnsName domain. This domain is the forest root. In this scenario, your
domain controller may not replicate to Active Directory. When you open the Active
Directory Users and Computers snap-in, you notice that the focus of your domain
controller is set to a different domain controller. If you run Netdiag.exe, you receive the
following error message:

DNS test . . . . . . . . . . . . . : Passed

Interface {BA748513-436B-4768-9D8C-8B3C5C8A0DCA}
DNS Domain:
DNS Servers: <IP address1>,<IP address2>, <IP address3>
IP Address: <IP address1> Expected registration with PDN (primary DNS domain
name):
Hostname: a.b.c.d.
Authoritative zone: b.c.d.
Primary DNS server: a.b.c.d. <IP address1>
Authoritative NS:<IP address1>,<IP address1>.<IP address1>
Verify DNS registration:
Name: a.b.c.d.
Expected IP: <IP address1>
Server <IP address1>: NO_ERROR
Server <IP address2> Error 9003 RCODE_NAME_ERROR
Server <IP address3> Error 9003 RCODE_NAME_ERROR
 ７ Note

Error 9003 RCODE_NAME_ERROR means that the host name a.b.c.d. doesn't exist in
the DNS servers that are listed in the error message.

The behavior that is mentioned in the Symptoms section can occur under the following
circumstances:

In the forest root, there are several domain controllers that are running the DNS
Server service.
The domain controller that is running the DNS Server service is a primary DNS
Server for the _msdcs.ForestDnsName domain.
The domain controller that is running the DNS Server service points to itself as the
preferred or alternative DNS server.

Cause
This behavior may occur because a DNS server for one domain controller may not have
the required domain controller locator CNAME record for
DsaGuid._msdcs.ForestDnsName in its zone for another domain controller.

Resolution
To resolve this behavior, read the following scenario. Then, use either of the following
two methods, depending on your server load and network considerations.

In this scenario, two domain controllers that are in the forest root, DC1.example.com
and DC2.example.com, aren't replicating. Both of the domain controllers are running the
DNS Server service. Both of the domain controllers are authoritative for the
example.com domain.

Both of the domain controllers' NetLogon services try to register their DNS records, and
find that their preferred DNS servers, which are themselves, are authoritative for the
example.com zone. Both of the DNS servers register the DNS records with their local
DNS Server service. One of these DNS records is a domain controller locator CNAME
record for DsaGuid._msdcs.ForestDnsName. When DC1.example.com tries replication
with DC2.example.com, DC1.example.com queries its local DNS server for the CNAME
record for DC2 example.com, but doesn't find it. So the replication process is
unsuccessful.

Two possible methods for resolving this behavior are as follows:

Method 1
Select a DNS server that is in the forest root, and point all of the other domain
controllers in the root domain to it as their primary DNS server. Each domain controller
that is in the root domain may also be configured with an alternative DNS server, if the
alternative DNS server doesn't point to itself as the alternative DNS server. The domain
controller that functions as the primary location for the other domain controllers in the
forest root should point to itself for DNS resolution.

７ Note

This method may not be appropriate if the primary DNS server is subject to heavy
loads, or if the other domain controllers that are in the forest root are
geographically dispersed.

Example
Domain = example.com (first domain in the forest).
Three domain controllers with the DNS Server service = DC1, DC2, DC3.example.com is
an Active Directory integrated zone.
DC1 is designated as the primary location for this configuration.

DC1 is configured to point to itself for DNS server settings in TCP/IP properties.
DC2 points to DC1 as the primary location and DC3 as an alternative.
DC3 points to DC1 as the primary location and DC2 as an alternative.

Method 2
When you install Active Directory on the member server that is in the forest root, you
must configure its primary DNS server as a domain controller, or as a DNS server that
has the following domain controller locator CNAME record for all the other domain
controllers in the root:
DsaGuid._msdcs.ForestName.

Install the DNS Server service and enable the integrated Active Directory DNS zone to
replicate to the new domain controller. Then the new domain controller may be
changed to point to itself as the primary or alternative DNS server.

If there are any IP address changes for the domain controllers that are in the forest root,
you may have to follow the steps in Method 1 until no longer required to do so. When
you've verified that the IP address changes have replicated to the DNS zone of the new
domain controller that is in the forest root, the domain controllers may be configured to
point to themselves as the primary or alternative DNS server again.

More information
You can configure a domain controller to point to itself as a preferred or alternative DNS
server. The only reason that the domain controller may not replicate to Active Directory
is if that domain controller is also the primary DNS server for the
_msdcs.ForestDnsName domain.

After the domain controller has registered the DsaGuid._msdcs.ForestDnsName CNAME

record with its local DNS Server service, the domain controller may then be configured
to point to itself as the preferred or alternative DNS server. An administrator must know
that the domain controller locator CNAME record for another domain controller could
accidentally be deleted because of human error. Although the NetLogon service
automatically registers this domain controller locator CNAME record, it can only be
created on the domain controller. Active Directory replication by this domain controller
of the domain controller locator CNAME record for another domain controller may not
occur if this domain controller is also the primary DNS server for
the_msdcs.ForestDnsName domain.

The following example is a scenario in which pointing a domain controller to itself as a

preferred DNS server may cause a problem with Active Directory replication.

DC1.example.com is the first domain controller in a forest. It's configured to point

to itself as a preferred DNS server that is authoritative for the example.com zone.
Server2 is a Windows 2000-based computer with a local DNS server. Server2 is
configured to point to itself as a preferred DNS server. Server2 has a forwarder that
is set to DC1.example.com.
Promote Server2 to an additional domain controller, DC2.example.com. During
promotion, the Active Directory integrated example.com zone replicates to
DC2.example.com.
Restart DC2.example.com. When the DNS Server for DC2.example.com starts, that
DNS Server loads the example.com zone from Active Directory. The DNS Server for
DC2.example.com then becomes the primary location for the example.com zone
and the _msdcs.example.com zone. The domain controller locator CNAME record
that is registered by DC2.example.com is added to the local copy of the
example.com zone. However, the domain controller locator CNAME record that is
registered by DC2. example.com can't be replicated to DC1.example.com. This
behavior may occur because DC1.example.com queries its local DNS server that is
authoritative for the example.com zone, but the DNS server for DC1.example.com
 doesn't contain the domain controller locator CNAME record that is registered by
DC2.example.com.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS server geo-location policy doesn't
work as expected
Article • 12/26/2023

Applies to: Windows Server 2019, all editions Windows Server 2019 Datacenter: Azure
Edition - Preview

Symptoms
Consider an organization that uses an AD-integrated zone (default zone scope) that's
named contoso.com for their internal workstations and servers. The organization wants
to implement a geo-location DNS structure for their branches so that the clients in a
specific site can access intranet services from their local subnets.

The configuration of the DNS zone resembles the following structure.

ﾉ Expand table

Subnet IPv4 address space Zone scope name

NorthAmericaSubnet 192.168.3.0/24 NorthAmericaZoneScope

CentralAmericaSubnet 192.168.6.0/24 CentralAmericaZoneScope

SouthAmericaSubnet 192.168.7.0/24 SouthAmericaZoneScope

The organization uses the following Windows PowerShell cmdlets to register host
address (A) records:

PowerShell

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www" -

IPv4Address "192.168.3.40" -ZoneScope "NorthAmericaZoneScope"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www" -
IPv4Address "192.168.6.40" -ZoneScope "CentralAmericaZoneScope"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www" -
IPv4Address "192.168.7.40" -ZoneScope "SouthAmericaZoneScope"

The organization uses the following PowerShell cmdlets to define the policies:

PowerShell
 Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW
-ClientSubnet "eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -
ZoneName "contoso.com"
Add-DnsServerQueryResolutionPolicy -Name "CentralAmericaPolicy" -Action
ALLOW -ClientSubnet "eq,CentralAmericaSubnet" -ZoneScope
"CentralAmericaZoneScope,1" -ZoneName "contoso.com"
Add-DnsServerQueryResolutionPolicy -Name "SouthAmericaPolicy" -Action ALLOW
-ClientSubnet "eq,SouthAmericaSubnet" -ZoneScope "SouthAmericaZoneScope,1" -
ZoneName "contoso.com"

The desired outcome is that a client tries to locate a requested resource first in the local
zone scope and then in the default zone scope. However, after the organization
configures these policies, clients from the defined subnets can't successfully resolve
records that are hosted in the default zone scope (contoso.com). For example, clients
can't resolve hostA.contoso.com. When it receives such requests, the DNS server
returns a "Server Failure" message.

Cause
In this situation, incoming authoritative queries are evaluated against the appropriate
set of zone-level policies based on their order of precedence. It seems intuitive that any
query that doesn't match a policy would be automatically serviced from the default zone
scope. However, this isn't true. Instead, any non-matching query triggers a name
resolution failure. That is, if the DNS server receives a name resolution query for
hostA.contoso.com from a client that's specified in a client subnet policy, the DNS
server examines only the related zone scope.

Resolution
To configure the policies so that the DNS server checks the default zone scope in
addition to the local zone scope, use a more precise DnsServerQueryResolutionPolicy
statement, such as the following:

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW

-ClientSubnet "eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -
ZoneName "contoso.com" -FQDN "www.contoso.com"

７ Note
 You have to create a DnsServerQueryResolutionPolicy statement for each record
that the appropriate zone scope contains.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS Server Logs Event 7062: "DNS
Server Encountered a Packet Addressed
to Itself"
Article • 12/26/2023

This article provides a solution to solve the DNS server logs event 7062.

Applies to: Windows Server 2012 R2

Original KB number: 218814

Symptoms
After you apply Service Pack 4, the DNS server begins logging Event 7062:

DNS Server encountered a packet addresses to itself -- IP address w.x.y.z. The DNS
server should never be sending a packet to itself. This situation usually indicates a
configuration error.

Check the following areas for possible self-send configuration errors:

1. Forwarders list (DNS server should not forward to themselves).

2. Master lists of secondary zones.
3. Notify lists of primary zones.
4. Delegations of subzones.

Must not contain NS record for DNS server

Example: -> This DNS server dns1.microsoft.com is the primary for the zone
microsoft.com . -> You have delegated the zone bar.microsoft.com to

bardns.bar.microsoft.com and are NOT running the bar.microsoft.com zone on this

DNS ( dns1.microsoft.com ). Note, you should make this check (with nslookup of DNS
manager) both on this DNS server and on the server(s) you delegated the subzone to. It
is possible that the delegation was done correctly, but that the primary DNS for the
subzone, has any incorrect NS record pointing back at this server. If this incorrect NS
record is cached at this server, then the self-send could result. If found, the subzone
DNS server admin should remove the offending NS record.

Cause
This error is caused by a configuration error or is the result of a delegation of a domain
(or subdomain) to a server for which there is no zone file.

Resolution
To resolve this issue, check for the following conditions:

Forwarders
DNS can be configured to forward off-site queries to designated servers. Be sure that
the DNS server is not configured to forward these off-site queries to itself:

1. Select the server, click DNS, and then click Properties from the menu.
2. Click the Forwarders tab.
3. If the server's own IP address is listed, select it and click Remove.
4. After you make this change, make sure to stop and restart the DNS service.

Master List of Secondary Zones

A secondary zone is configured with a list of the master or primary server(s). Be sure that
the server's own IP address is not listed as one of the IP master(s):

1. Select the secondary zone, click DNS, and then click Properties from the menu.
2. Click the General tab.
3. If the server's own IP address is listed in the IP Master(s) section, select it and click
Remove.

Notify Lists
Microsoft Windows NT DNS Server allows the Administrator to specify (on the primary
DNS server) any secondary DNS servers that should be notified immediately of changes
to the Zone file. Be sure that the DNS server is not configured to notify itself:

1. Select the primary zone, click DNS, and then click Properties from the menu.
2. Click the Notify tab.
3. If the server's own IP address is listed, select it and click Remove.

Delegation issue
The delegation issue is defined as having a domain or subdomain delegated to a server
that is not authoritative for the domain (in other words, a zone file does not exist for the
domain on the server). There are two possible causes:

Delegating a Child Domain to Itself

If a child domain is created on a server and an NS record is added to that domain
that resolves to its own IP address, an Event 7062 is generated. The following is an
example:
DNS server ns1.domain.com is the primary DNS server for the domain.com zone .
A child domain is created named child.domain.com and an NS record is added
to child.domain.com for ns1.domain.com . This results in a child domain being
delegated to itself. To resolve this issue, remove the NS record from
child.domain.com . Only add NS records to child domains if you wish to delegate

it to another server (that is, to delegate it to ns2.domain.com ).

Domain Delegated to Server with No Zone File

If another DNS server has delegated a domain (either a forward lookup or reverse
lookup domain) to a server and there is no zone file on the server for that domain,
an Event 7062 is generated. The following are examples:
Your Internet Service Provider (ISP) has assigned you the Class C network of
192.168.1.0 and has delegated the 1.168.192.in-addr.arpa domain for reverse
lookups to your DNS server. If there is no zone configured on your DNS server
for that domain, event 7062 will be generated every time a query is made for
that domain from the server. The DNS server will step through the DNS
hierarchy starting at the root servers and eventually receive a response from the
ISP's DNS server indicating that the server itself is authoritative for the domain
and attempt to query itself. To resolve this issue, either create a primary or
secondary zone for that domain, or have the ISP change the delegation.
Your ISP has delegated a domain to your caching-only DNS server. Because
there are no zone files on a caching-only server, any queries that it makes for
hosts that reside in domains for which it has been delegated authority will result
in an event 7062 error. To resolve this issue, either create a primary or secondary
zone file for that domain, or have the ISP change the delegation.

More information
Due to the informational nature of this warning, the severity type has been reduced
from a "Stop" (red) event to a "Warning" (yellow) event in Windows NT 4.0 Service Pack
5.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS server reverts to listening on all IP
addresses instead of the configured NIC
Teaming IP address
Article • 12/26/2023

Applies to: Windows Server 2019, Windows Server 2016

Symptoms
Consider the following scenario:

The DNS server computer has multiple network adapters that you use in a NIC
Teaming configuration.
You configure the DNS server to listen on the IP address of the teaming network
adapter.
On the Interfaces tab of the DNS server properties dialog box in DNS Manager,
you can configure the IP address that you want to use.
In this scenario, when you set this configuration, Windows stores it in a registry value
under the HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ListenAddresses
subkey.

After you restart the DNS server, Windows deletes both the setting and the registry
value. The DNS server starts listening on all IP addresses again.

When this change occurs, Windows logs Event ID 410 in the DNS server event log:

The DNS server list of restricted interfaces does not contain a valid IP address for
the server computer. The DNS server will use all IP interfaces on the machine. Use
the DNS manager server properties, interfaces dialog, to verify and reset the IP
addresses the DNS server should listen on. For more information, see "To restrict a
DNS server to listen only on selected addresses" in the online Help.

Cause
As indicated by DNS Event ID 410, this behavior is expected.

When the DNS server starts, it checks the IP addresses of the available network adapters
and notes that none of the addresses match the configured NIC Teaming address.
Because of this mismatch, the DNS server determines that the configuration isn't valid.
The DNS server then deletes the configuration, and reverts to listening on all available IP
addresses.

NIC Teaming isn't available until after the physical adapters have come online. The issue
occurs because the DNS Server service starts after the physical adapters come online.
However, it doesn't wait for NIC Teaming adapter to become available.

Resolution
To resolve this issue, change the startup type of the DNS Server service to Automatic
(Delayed Start). This setting delays the startup of the service so that the NIC Teaming
adapter is available.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Windows Server 2008 and Windows
Server 2008 R2 DNS Servers may fail to
resolve queries for some top-level
domains
Article • 12/26/2023

This article provides a solution to an issue where Domain Name System (DNS) Servers
may fail to resolve queries for names in certain top-level domains when name resolution
is provided by root hints.

Applies to: Windows Server 2012 R2

Original KB number: 968372

Symptom
When name resolution is provided by root hints, Windows Server 2008 DNS and
Windows Server 2008 R2 DNS Servers may fail to resolve queries for names in certain
top-level domains. When this problem happens, it will continue until the DNS Server
cache is cleared or the DNS Server service is restarted. The problem can be seen with
domains like .co.uk, .cn, .biz, and .br, but isn't limited to these domains.

When the problem is happening, a nslookup command issued for an affected name will
return the error "server failed". A network trace will show that the DNS server doesn't
send any traffic for such a request to the Internet. No events related to a problem are
reported in the DNS Event Log.

This problem doesn't happen if DNS Server is configured to use forwarders for Internet
name resolution instead of root hints.

Resolution
To resolve the issue and continue using root hints, change the MaxCacheTTL registry
value to two days or greater.

７ Note

Serious problems might occur if you modify the registry incorrectly by using
Registry Editor or another method. These problems might require you to reinstall
 the operating system. Microsoft cannot guarantee that these problems can be
solved. Modify the registry at your own risk.

1. Start Registry Editor (regedit.exe).

2. Locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

3. On the Edit menu, select New, select DWORD (32-bit) Value, and then add the
following value:

Value: MaxCacheTTL
Data type: DWORD
Data value: 0x2A300 (172,800 seconds in decimal, or two days)

4. Select OK.

5. Quit Registry Editor.

6. Restart the DNS Server service.

７ Note

The .biz top level has a TTL of 6 days for its NS and A records. Thus, you may need
to set the MaxCacheTTL to 518400 for 6 days or even 604800 for 7 days.

Disclaimer
Rapid publishing articles provide information directly from within the Microsoft support
organization. The information contained herein is created in response to emerging or
unique topics, or is intended supplement other knowledge base information.

Microsoft and/or its suppliers make no representations or warranties about the

suitability, reliability, or accuracy of the information contained in the documents and
related graphics published on this website (the "materials") for any purpose. The
materials may include technical inaccuracies or typographical errors and may be revised
at any time without notice.

To the maximum extent permitted by applicable law, Microsoft and/or its suppliers
disclaim and exclude all representations, warranties, and conditions whether express,
implied, or statutory, including but not limited to representations, warranties, or
conditions of title, non-infringement, satisfactory condition or quality, merchantability
and fitness for a particular purpose, with respect to the materials.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS Server vulnerability to DNS Server
Cache snooping attacks
Article • 01/12/2024

This article provides a solution to an issue where DNS Server vulnerability to DNS Server
Cache snooping attacks.

Applies to: Windows Server 2012 R2

Original KB number: 2678371

Symptoms
What is "DNS cache snooping" and how do I prevent it? describes DNS cache
snooping as:

DNS cache snooping is when someone queries a DNS server in order to find out
(snoop) if the DNS server has a specific DNS record cached, and thereby deduce if
the DNS server's owner (or its users) have recently visited a specific site.
This may reveal information about the DNS server's owner, such as what vendor,
bank, service provider, etc. they use. Especially if this is confirmed (snooped)
multiple times over a period.
This method could even be used to gather statistical information - for example at
what time does the DNS server's owner typically access his net bank etc. The cached
DNS record's remaining TTL value can provide very accurate data for this.

DNS cache snooping is possible even if the DNS server is not configured to resolve
recursively for 3rd parties, as long as it provides records from the cache also to third
parties.

Security audits may report that various DNS Server implementations are vulnerable to
cache snooping attacks that allow a remote attacker to identify which domains and
hosts have [recently] been resolved by a given name server.

Once such cache snooping vulnerability report reads:

DNS Server Cache Snooping Remote Information Disclosure

Synopsis:
The remote DNS server is vulnerable to cache snooping attacks.
Description:
The remote DNS server responds to queries for third-party domains that do not
 have the recursion bit set. This may allow a remote attacker to determine which
domains have recently been resolved via this name server, and therefore which
hosts have been recently visited. For instance, if an attacker was interested in
whether your company utilizes the online services of a particular financial institution,
they would be able to use this attack to build a statistical model regarding company
usage of that financial institution. Of course, the attack can also be used to find B2B
partners, web-surfing patterns, external mail servers, and more. Note: If this is an
internal DNS server not accessable to outside networks, attacks would be limited to
the internal network. This may include employees, consultants and potentially users
on a guest network or WiFi connection if supported.
Risk factor:
Medium
CVSS Base Score:5.0
CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N
See also:
http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

Solution:
Contact the vendor of the DNS software for a fix.

Cause
This error is typically reported on DNS Severs that do recursion.

Resolution
There's no code fix as this is a configuration choice.

There are three options:

1. Leave recursion enabled if the DNS Server stays on a corporate network that
cannot be reached by untrusted clients

2. Don't allow public access to DNS Servers doing recursion

3. Disable recursion

More information
By default, Microsoft DNS Servers are configured to allow recursion.
Name recursion can be disabled globally on a Microsoft DNS Server but can't be
disabled on a per-client or per-interface basis.

The majority of Microsoft DNS Servers are coinstalled with the Domain Controller server
role. Such servers typically host zones and resolve DNS names for devices | appliances,
member clients, member servers, and domain controllers in an Active Directory forest
but may also resolve names for larger parts of a corporate network. Since Microsoft DNS
Servers are typically deployed behind firewalls on corporate networks, they're not
accessible to untrusted clients. Administrators of servers in this setting should consider
whether disabling or limiting DNS recursion is necessary.

Disabling recursion globally isn't a configuration change that should be taken lightly as
it means that the DNS server can't resolve any DNS names on zones that aren't held
locally. This requires some careful DNS planning. For example, clients cannot typically be
pointed directly at such servers.

The decision to disable recursion (or not) must be made based on what role the DNS
server is meant to do within the deployment. If the server is meant to recurse names for
its clients, recursion cannot be disabled. If the server is meant to return data only out of
local zones and is never meant to recurse or forward for clients, then recursion may be
disabled.

Related links
Disable Recursion on the DNS Server
Disable recursion on the DNS server
How DNS query works
Recursive and Iterative Queries
Recursive Name Resolution

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS zone transfer fails when using the
"Only to servers listed in the Name
servers tab" setting
Article • 12/26/2023

This article helps resolve an issue in which Domain Name System (DNS) zone transfer
fails when using the Only to servers listed in the Name servers tab setting.

You configure multiple IP addresses on a network adapter, and the DNS server is
configured to listen to all IP addresses. If you allow zone transfers with the Only to
server listed on the Name Servers tab option enabled under the Zone Transfers tab of
a DNS zone, incremental zone transfer (IXFR) doesn't occur. In addition, when the Notify
option is enabled, creating records on the primary server doesn't replicate to the
secondary server unless you force Authoritative Transfer (AXFR). When the DNS zone is
paused or resumed, you receive the following error message:

Zone Not Loaded by DNS Server

The DNS server encountered a problem while attempting to load the zone. The
transfer of zone data from the master server failed.
Correct the problem then either press F5, or on the Action menu, click Refresh.
For more information about troubleshooting DNS zone problems, see Help.

Change the "Allow zone transfers" setting

To work around this issue, set the Allow zone transfers setting to one of the following
options:

To any server
Only to the following servers

Use zoneresetsecondaries command to set the

zone transfers to name servers only option
You can use the following steps to set the zone transfers to name servers only option for
the zone.

1. Close the Microsoft Management Console (MMC).

2. From an elevated command prompt, run the following command:

 Console

dnscmd <servername> /zoneresetsecondaries <zonename> /securens

3. Wait for 60 seconds, and then open the MMC.

4. Select Refresh to refresh the settings.

5. Open the zone transfer settings and check the settings. If the settings are correct,
select Cancel and close the MMC.

6. Wait for 60 seconds and the transfer will be performed successfully.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS zone transfer options are reset
after you change zone replication scope
in Windows Server 2008 R2
Article • 12/26/2023

This article provides help to solve an issue where DNS zone transfer options are reset
after you change the zone replication scope.

Applies to: Windows Server 2012 R2

Original KB number: 4050194

Symptoms
Consider the following scenario:

A domain that is named contoso.com contains two domain controllers,

DC1.contoso.com and DC2.contoso.com.

Both domain controllers are Domain Name System (DNS) servers that host the
Contoso.com zone.

The zone replication scope is set to the following value:

To all domain controllers in the domain (for Windows 2000 compatibility):

contoso.com

The contoso.com zone on DC1 and DC2 is configured to Allow Zone transfers to
secondary servers.

You set the zone replication scope to the following value:

To all DNS servers running on domain controllers in this domain: contoso.com

 This change is replicated to DC2, and then the contoso.com zone is reloaded by
the DNS service on DC2.

In this scenario, the zone transfer settings on DC2 are removed. The following changes
occur:

The Allow zone transfers check box is cleared.

The list of servers to which zone transfer was previously allowed is removed. The
server values are also removed from the registry.
 ７ Note

When this issue occurs, the zone transfers settings on DC1 are not affected.

Cause
This issue occurs because the existing zone object is deleted from the partition, and a
new object is created in the corresponding partition when the replication scope is
changed. This change is replicated across all domain controllers.

When the polling thread on DC2 pulls the change from the new partition, the registry
settings for are reset. Zone transfer is disabled because the value of SecureSecondaries
is set to 3. Also, any configured servers in the zone transfer list are removed because the
SecondaryServers value is removed. From a DNS perspective, this process resembles
creating a new zone in a different partition.

Resolution
Before you change the replication scope, note the zone transfer settings. Reconfigure
the zone transfer settings after the replication scope is changed.
You can also use the following scripts to back up and restore the settings.

７ Note

These scripts are provided on an as-is basis. We recommend that you thoroughly
test these scripts before you use them in a production environment.

Backup script
Save the following code as a file that is named BackupZoneTransferSettings.ps1.

PowerShell

# Begin Script
param([string]$ZoneName = "test2.com")
#Build the vars
$TargetRoot = "HKCU:\DNSZoneConfigMigration\"
$TargetKeyPath = $TargetRoot
$SourceRoot = "HKLM:\Software\Microsoft\Windows Nt\CurrentVersion\DNS
Server\Zones\"
$SourceKeyPath = $SourceRoot + $ZoneName
#Copy the Item
#Check for the presence of the item
Get-Item HKCU:\DNSZoneConfigMigration -ErrorAction SilentlyContinue >$null
if($?)
{
"DNSZoneConfigMigration key present already!"
}
else
{
New-Item -Path HKCU:\DNSZoneConfigMigration -ErrorAction SilentlyContinue
>$null
}
if($?)
{
Copy-Item -Path $SourceKeyPath -Destination $TargetKeyPath -ErrorAction
SilentlyContinue >$null
if($?)
{
"Key backed up in registry (Current User Hive) successfully!"
}
else
{
"Key Backup Failed.Error Code is " + $Error[0].Exception.Message
}
}
else
{ "Unable to Create Backup Key.Error code is " + +
$Error[0].Exception.Message + ".Exiting"
 }
# End Script

Restore script
Save the following code as a file that is named RestoreZoneTransferSettings.ps1.

PowerShell

# Begin Script
param([string]$ZoneName = "test2.com")
#Build the vars
$SourceRoot = "HKCU:\DNSZoneConfigMigration\"
$SourceKeyPath = $SourceRoot + $ZoneName
$DestinationRoot = "HKLM:\Software\Microsoft\Windows Nt\CurrentVersion\DNS
Server\Zones\"
$DestinationKeyPath = $DestinationRoot + $ZoneName
#Copy the ItemProperty Values
Copy-ItemProperty -Path $SourceKeyPath -Destination $DestinationKeyPath -
Name "SecureSecondaries" -ErrorAction SilentlyContinue >$null
if($?)
{
"SecureSecondaries Value Successfully Restored for " + $ZoneName
Copy-ItemProperty -Path $SourceKeyPath -Destination $DestinationKeyPath
-Name "SecondaryServers" -ErrorAction SilentlyContinue >$null
if($?)
{
"SecondaryServers Value Successfully Restored for " + $ZoneName
"Restore Successful! Deleting the backup" Remove-Item -Path $SourceKeyPath
if(-Not $?)
{
"Unable to Delete Backup Key. Delete Manually. Error :" +
$Error[0].Exception.Message
}
}
else
{
"Failed to restore SecondaryServers value. " +
$Error[0].Exception.Message
}
}
else
{
"Failed to restore SecureSecondaries value. " +
$Error[0].Exception.Message
}
# End Script

The backup script backs up the zone transfer settings for a particular zone. (For
convenience, the backup is stored in the registry under the HKEY_CURRENT_USER hive.)
 ７ Note

You can run the Set-ExecutionPolicy PowerShell cmdlet to allow unsigned scripts.

The second command (highlighted) in the following screenshot takes a backup of the
zone transfer settings for the zone that is named "test3.com."

Where the settings are backed up to in the registry

Running the script to restore the zone transfer settings (the

restore script restores these two values only)

Zone transfer settings in the registry before the restore operation

Zone transfer settings in registry after the restore operation

 ７ Note

After you run the restore script, you must restart the DNS service to apply the
changes.

More information

Zone transfer settings storage

The zone transfer settings are stored in the registry on the DNS server in the following
path:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\<domain name>

When zone transfer is set to specific servers or IP addresses, the following values are
populated:

SecureSecondaries is set to 0x2. This corresponds to the Only to the following

servers option.
A multi-string value that is named SecondaryServers is created by using the IP
addresses of the servers.

Settings
Registry

７ Note

The zone transfer settings are not stored in Active Directory. Therefore, the settings
don't replicate as part of Active Directory replication.

DS polling thread
The DNS service maintains a DS polling thread that periodically polls partitions and
retrieves the list of all zones. For more information, see How Often Does the DNS Server
Service Check AD for New or Modified Data?
By default, the DNS service polls Active Directory for changes every 180 seconds (3
minutes). You can control this process by using the DsPollingInterval registry key or the
dnscmd /dspollinginterval switch.
 ７ Note

The switch accepts values from 0 to 3,600 seconds. However, values from 1 to 29
are not allowed. The minimum acceptable value is 30 seconds.

For more information, see Dnscmd config .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

DNS zones don't load and event ID 4000
and 4007 are logged
Article • 12/26/2023

This article solves an issue that event IDs 4000 and 4007 are logged when the DNS
zones aren't loaded on the DNS console.

Applies to: Windows Server 2012 R2

Original KB number: 2751452

Symptoms
One of the DNS servers in your environment starts showing an issue that the zones
aren't loaded on the DNS console. And Event IDs 4000 and 4007 are logged in the DNS
event logs:

Event ID 4000:

Output

The DNS server was unable to open Active Directory. This DNS server is
configured to obtain and use information from the directory for this zone
and is unable to load the zone without it. Check that the Active Directory
is functioning properly and reload the zone. The event data is the error
code.

Event ID 4007:

Output

The DNS server was unable to open zone \<zone> in the Active Directory from
the application directory partition \<partition name>. This DNS server is
configured to obtain and use information from the directory for this zone
and is unable to load the zone without it. Check that the Active Directory
is functioning properly and reload the zone. The event data is the error
code.

Also when you try to open the DNS console you get a pop-up giving Access Denied.

You notice that the DNS Server service is up and running.

When you try to perform any operation on the AD-integrated zones using DNSCMD,
you receive the Access Denied error message.
Cause
This issue happens when that particular DC/DNS server has lost its Secure channel with
itself or PDC.

This issue can also happen in a single DC environment where that DC/DNS server holds
all the FSMO roles and is pointing to itself as Primary DNS server.

Resolution
In case you have other Domain Controller/DNS server present in the environment, then
configure the server experiencing the issue to point to other active DNS server in TCP/IP
properties.

1. Stop the KDC service on the DC experiencing the issue.

2. Run the following command with elevated rights:

Console

netdom resetpwd /server:<PDC.domain.com> /userd:<Domain\domain_admin>

/passwordd:*

It will prompt for the password of the Domain Admin account that you used, enter
that.

3. Once the command executes, reboot the server.

DNS zones should load now.

If it's the only domain controller in the environment and there are no other DNS Servers
available, follow the same steps but replace the PDC.Domain.com with the server's own IP
address (since it itself is the PDC).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event ID 4015 is logged and the DNS
server encounters a critical error
Article • 12/26/2023

This article helps to resolve the issue in which Event ID 4015 is logged and the Domain
Name Service (DNS) server encounters a critical error.

Applies to: Windows Server 2012 R2

Original KB number: 969488, 2733147

You receive Event ID 4015 in one of the following scenarios:

If you're running the DNS role on a Read-Only Domain Controller (RODC) and a
writable Domain Controller (hosting DNS) isn't accessible, the following event is
logged on the RODC.

Output

Log Name: DNS Server

Source: Microsoft-Windows-DNS-Server-Service
Date: date time
Event ID: 4015
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <ComputerName>
Description:
The DNS server has encountered a critical error from the Active
Directory. Check that the Active Directory is functioning properly. The
extended error debug information (which may be empty) is "00002095:
SvcErr: DSID-03210A6A, problem 5012 (DIR_ERROR), data 16". The event
data contains the error.

The DNS server can't access the Active Directory object, and the following event is
logged frequently in the DNS server's event log.

Output

Type: Error
Source: DNS
Category: None
Event ID: 4015
Description:
The DNS server has encountered a critical error from the Active
Directory. Check that the Active Directory is functioning properly. The
 extended error debug information (which may be empty) is "0000051B:
AttrErr: DSID-xxxx, #1: 0:0000051B: DSID-xxxx, problem 1005
(CONSTRAINT_ATT_TYPE), data 0, Att 20119(nTSecurityDescriptor)". The
eventdata contains the error."

In a forest or domain located in Active Directory integrated Domain Name System

(DNS) zones, some domain controllers that have the DNS Server role installed have
been promoted and demoted. Some promoted domain controllers can't register
the SRV, Host A, Pointer (PTR), or Name Server (NS) in the Active Directory
integrated DNS zones, and the following event is logged:

ouput

The DNS server has encountered a critical error from the Active
Directory. Check that the Active Directory is functioning properly. The
extended error debug information (which may be empty) is "00002024:
SvcErr: DSID-02050BBD, problem 5008 (ADMIN_LIMIT_EXCEEDED), data
-1026". The event data contains the error.

RODC logs DNS Event ID 4015 every three

minutes with error code 00002095
When an RODC locates a writeable DNS server to perform ReplicateSingleObject (RSO),
it performs a DSGETDC function with the following flags set:

DS_AVOID_SELF
DS_TRY_NEXTCLOSEST_SITE

DS_DIRECTORY_SERVICE_6_REQUIRED
DS_WRITEABLE_REQUIRED

Once a DC is returned from the DSGETDC call, it uses the result to search for the NS
record in DNS. If the DSGETDC call fails or it fails to find the NS record of the DC
returned from DSGETDC, Event ID 4015 will be logged.

Possible causes of Event ID 4015:

No writeable DC is accessible, or none returned from the DSGETDC call.

The DSGETDC call was successful, but the DC returned doesn't have the DNS
Server Role installed or doesn't register an NS record in DNS.

The following command can be run from the RODC to check which DC is returned from
the DSGETDC call:
 Console

nltest /dsgetdc: DOMAIN.COM /WRITABLE /AVOIDSELF /TRY_NEXT_CLOSEST_SITE

/DS_6

Where DOMAIN.COM is your domain name.

For more information about the DSGETDC function, see DsGetDcNameA function.

To resolve either of the causes above, ensure that a writable DC is accessible from the
RODC, that the DNS Server Role is installed on that DC, and that the NS record is
registered in DNS for the writable DC.

Event ID 4015 is logged with error code

0000051B
This issue occurs because of permissions issues. SYSTEM isn't the owner of the DNS
zone. You can enable the Field Engineering diagnostic logging to identify the DNS zone
and change the owner.

Set DNS zone owner to SYSTEM

To resolve this issue, follow these steps:

1. When you see the DNS error in the DNS server event logs again after the logging
is enabled, stop the AD diagnostic field engineering logging by setting the
following registry value to 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field

Engineering

2. Correlate the exact time of Event ID 4015 to the Directory Service Event ID 1644,
and identify the DNS application directory partition.

3. Open the ADSI Edit (Adsiedit.msc) tool, and go to the LDAP location of the object
identified in Event ID 1644, which correlates to Event ID 4015.

4. Right-click the zone, go to Properties > Security > Advanced, and make sure the
Owner is set to SYSTEM.
Event ID 4015 is logged with an extended error
code (ADMIN_LIMIT_EXCEEDED)
This issue occurs when the DNS Server service reaches the dnsRecord multi-valued
attribute limit for the dnsNode object in Active Directory. In Active Directory integrated
DNS zones, DNS names are represented by dnsNode objects, and DNS records are
stored as values in dnsRecord attributes of dnsNode objects. DNS resource records (RRs)
of demoted domain controllers won't be deleted automatically from dnsRecord
attributes of dnsNode objects in the corresponding zone of the related Active Directory
partition. For example:

Output

DC=..TrustAnchors,CN=MicrosoftDNS,DC=ForestDnsZones,DC=xxx,DC=xxx

When additional records are added to dnsRecord attributes of dnsNode objects, the
orphaned entries of demoted domain controllers result in the ADMIN_LIMIT_EXCEEDED
error.

To check the current number of records in each partition, run the following repadmin
commands:

Console

repadmin /showattr . "CN=MicrosoftDNS,CN=System,DC=contoso,DC=com" /subtree

/filter:"(objectclass=dnsnode)" /atts:"dnsRecord" /allvalues
>c:\temp\dns_Domain.txt
repadmin /showattr . "CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com"
/subtree /filter:"(objectclass=dnsnode)" /atts:"dnsRecord"
/allvalues>c:\temp\dns_DomainDnsZones.txt
repadmin /showattr . "CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com"
/subtree /filter:"(objectclass=dnsnode)" /atts:"dnsRecord" /allvalues
>c:\temp\dns_ForestDnsZones.txt

The output displays the current number of entries in dnsRecord attributes of the
corresponding Active Directory integrated zone. For example:

Output

DN:
DC=@,DC=..TrustAnchors,CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com
1280> dnsRecord: <48 byte blob>;
Delete orphaned entries of denoted domain controllers
To resolve this issue, remove all orphaned entries of the denoted domain controllers
from the zones. To check and selectively delete the entries, run the following Windows
PowerShell cmdlets:

PowerShell

Get-DnsServerResourceRecord -ZoneName trustanchors -RRType Ns

Remove-DnsServerResourceRecord -zonename trustanchors -RRType Ns -Name “@” -
RecordData DC.contoso.com

If you need to delete multiple resource records (RRs) for a single host, run the following
cmdlets:

PowerShell

$AllNsRecords = Get-DnsServerResourceRecord -ZoneName “trustanchors” -RRType

Ns
Foreach($Record in $AllNsRecords){
If($Record.recorddata.nameserver -like "*dc2*"){
$Record | Remove-DnsServerResourceRecord -ZoneName trustanchors
}
}
$AllSrvRecords = Get-DnsServerResourceRecord -ZoneName “_msdcs.contoso.com”
-RRType Srv
Foreach($Record in $AllSrvRecords){
If($Record.recorddata.domainname -like "*dc2*"){
$Record | Remove-DnsServerResourceRecord -ZoneName _msdcs.contoso.com
}
}

Enable debug logging with TroubleShootingScript (TSS)

To start traces on the DNS Server by using TSS , run the following cmdlet:

PowerShell

.\TSS.ps1 -Scenario NET_DNSsrv -Mode Verbose -WaitEvent Evt:4015:'DNS

Server'

７ Note

The trace logging will stop automatically after Event ID 4015 is logged.
For more information, see Gather key information before contacting Microsoft support.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Event IDs 4016 and 4004 when DNS
updates time out
Article • 12/26/2023

This article helps resolve an issue in which Event IDs 4016 and 4004 are logged in the
Domain Name System (DNS) when DNS updates from the Lightweight Directory Access
Protocol (LDAP) to Active Directory (AD) time out.

In AD-integrated DNS zones that are hosted on domain controllers (Windows Server
2012 R2 or later versions), DNS can't enumerate the zones or intermittently fail to create
or write records. Additionally, Event IDs 4016 and 4004 are logged in the DNS event log:

Event ID 4016

Output

LogName: DNS Server

Source: Microsoft-Windows-DNS-Server-Service
Date: <DateTime>
Event ID: 4016
Task Category:
Level: Error
User: S-1-5-18
Computer: Contoso.com
Description:
The DNS server timed out attempting an Active Directory service
operation on DC=xx.x,DC=xxx.xx.in-
addr.arpa,cn=MicrosoftDNS,DC=ForestDnsZones,DC=xxx,DC=com. Check Active
Directory to see that it is functioning properly. The event data
contains the error.

Event ID 4004

Output

LogName: DNS Server

Source: Microsoft-Windows-DNS-Server-Service
Date: <DateTime>
Event ID: 4004
Task Category:
Level: Error
User: S-1-5-18
Computer: Contoso.com
Description:
The DNS server was unable to complete directory service enumeration
of zone xx.xxx.xx.in-addr.arpa. This DNS server is configured to use
information obtained from Active Directory for this zone and is unable
 to load the zone without it. Check that the Active Directory is
functioning properly and repeat enumeration of the zone. The extended
error debug information (which may be empty) is "". The event data
contains the error.

If Event IDs 4016 and 4004 are logged, the DNS records are updated on other domain
controllers and visible in ADSI Edit (adsiedit.msc). However, the records can't be written
and the DNS updates stop until the DNS Server service is restarted. During this period,
records can be created at the same time by using ADSI Edit on the problematic domain
controllers. These records are then replicated to all domain controllers, which means the
AD is working properly. The memory usage of the dns.exe process is low. Meanwhile, the
CPU and memory usage on domain controllers is also low, but they remain
unresponsive.

By checking the DNS audit logs, event logs and packet captures, DNS updates stop on
the server even though DNS queries are responded to quickly. In addition, error 0x55 is
logged.

Restart DNS Server service and delete Kerberos

ticket cache
To work around this issue, restart the DNS Server service after deleting the Kerberos
ticket cache by using a Windows PowerShell script. See the following script for an
example:

７ Note

Because the default $EventIntervalMinutes and $NumberOfEvents values may not

be optimal, adjust the values accordingly.

PowerShell

#NOTE