Cleanup from issues experienced with Exchange Server 2019 CU15 PrepareSchema and PrepareAD

Question

Cleanup from issues experienced with Exchange Server 2019 CU15 PrepareSchema and PrepareAD

Brad Hunt 30

Over this last weekend, I decided to run the PrepareSchema and PrepareAD steps for CU15 since, up until now, it has been a fairly quick and straightforward process. Both seemed to complete without issue, but then I noticed that repadmin was reporting schema mismatch errors domain-wide. The problem turned out to be that some of the schema attributes had duplicate values... I'll explain. In most cases, the attribute name was "auxiliaryClass", and the value was showing as {msExchBaseClass, msExchBaseClass} when it should have simply been {msExchBaseClass}. Changing the values on 67 attributes corrected the schema mismatches. In checking each domain controller just to be sure, it turns out that one domain controller still has the duplicated values. Being a classSchema object, it can only be edited from the schema master, and the issue is on a domain controller at a remote site. Is anyone aware of a way to make these edits on a non-schema master DC? The DC seems fully functional, but I expect that correcting the duplication issue now will prevent issues down the road. Thanks for any assistance!

Accepted answer

2 additional answers

Your answer

Answer 1

Hi @Brad Hunt

We've received your report regarding the schema mismatch issue after running the PrepareSchema and PrepareAD steps for CU15. We understand that some schema attributes, specifically auxiliaryClass are showing duplicate values, and while you've resolved this on most Domain Controllers, one remote DC still has these duplicated values. We apologize for any inconvenience this has caused.

As a forum moderator, I'm here to offer guidance and point you toward reliable resources. While I can't directly access or perform technical operations on your system, I can provide a clear explanation of the issue and outline the standard steps for resolution.

The root of this problem lies in how Active Directory Schema objects, such as classSchema (which includes the auxiliaryClass attribute), are managed. Any modifications to these critical schema objects can only be performed directly on the Domain Controller holding the Schema Master FSMO (Flexible Single Master Operation) role. This is a fundamental design principle of Active Directory, ensuring that the schema remains consistent and authoritative across your entire forest. Attempting to directly edit these attributes on a Domain Controller that isn't the Schema Master simply won't work.

Your situation strongly suggests that the Active Directory replication process between your Schema Master and the problematic remote Domain Controller hasn't fully completed or is encountering an issue. The primary goal here is to ensure that this remote DC successfully receives the corrected schema information from your Schema Master.

Resolving this type of issue typically involves ensuring proper Active Directory replication. These actions require administrative privileges and should be performed by an experienced IT professional:

1. Identify the Schema Master

Determine which Domain Controller currently holds the Schema Master FSMO role in your environment.

Microsoft Docs Reference: Flexible Single Master Operations roles in Windows Server

2. Check Replication Health

Use tools like repadmin /showrepl to verify the replication status between your Schema Master and the remote Domain Controller. This will help identify any replication errors that might be preventing the schema from synchronizing correctly.

Microsoft Docs Reference: Diagnose AD Replication Failures

3. Force Schema Replication

If no severe replication errors are found, your technical team may attempt to force replication of the Schema partition using repadmin /syncall or repadmin /replicate from the Schema Master to the affected Domain Controller.

Microsoft Docs Reference: Troubleshooting Active Directory Replication Problems

4. Verify the Schema

After attempting replication, it's crucial to re-check the auxiliaryClass attribute on the remote Domain Controller using tools like repadmin /showattr to confirm that the duplicate values have been successfully corrected.

For detailed assistance and direct intervention on your system, I strongly recommend reaching out to your internal IT team or a professional technical support provider specializing in Active Directory and Exchange Server. They have the necessary expertise and tools to accurately diagnose and safely implement the corrective actions.

For your complete understanding and to aid any technical team you engage, here's a curated list of relevant official Microsoft Learn documentation:

I hope this detailed explanation and the provided resources will help you navigate this issue effectively. Please let me know if you have any further questions as you proceed.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Jade-T 3,520 Reputation points Microsoft External Staff Moderator

2025-07-14T09:05:32.2+00:00

Hi @Brad Hunt

It’s great to hear that replication completed successfully after you addressed the schema mismatch on the Schema Master, that’s definitely a key milestone.

As for the remaining duplicate values still visible on the remote DC, since edits to classSchema objects can only occur via the Schema Master, a full AD database copy between domain controllers isn’t natively supported. Typically, replication ensures consistency, so if it's already showing as successful, this may be more of a display or lingering metadata issue.

In situations like this, some environments may explore advanced options like forcing metadata cleanup or even (as you mentioned) considering a demote/promote, though that’s understandably more disruptive. If available, your AD team might be best positioned to evaluate those paths in a way that fits your setup with minimal impact.

Hope everything continues to run smoothly on your end!

Answer 2

Thank you for the reply! After I had remove the duplicated values from the schema master and corrected the schema mismatch errors, syncall completed with no issues. It basically ends with "SyncAll terminated with no errors" which is what we want. The only reason I know that the duplicated values are still there on the one remote domain controller is because they show up in ADSI Edit as well as via a PowerShell query I wrote. I'm thinking that active directory may not recognize the difference between "{msExchBaseClass, msExchBaseClass}" and "{msExchBaseClass}". However, the duplicated values definitely caused replication issues when they were on the schema master. Is there a way to basically do a full copy of the AD database to our problem domain controller to fix this issue? I realize I could probably demote the domain controller and then promote it, but I'm hoping for a less drastic approach if possible.

Answer 3

Brad Hunt 30

I was able to get this last DC fixed by basically following the same approach as I did for solving the widespread schema mismatches. In our topology, one DC was in between the schema master and the DC showing the duplicate values. For most of the 67 values duplicated after the PrepareAD, I had to one at a time use ADSI Edit on the schema master to remove the value so that it showed "<not set>", then use repadmin /syncall to make sure the change replicated far and wide, then I reentered the value and ran repadmin /syncall again. After this, the value on the problem DC was no longer duplicated. At this point, the 67 values are matching across all domain controllers, no duplication of values is present, and replication continues to complete without error. While it was a mind-numbing process to reenter the values, I definitely preferred it to demoting and re-promoting the domain controller.

Brandon Poindexter 71 Reputation points

2025-08-02T06:48:54.79+00:00

Do you still have your powershell script for finding those duplicate msExchBaseClass values?

I am having almost this exact problem. The details of my environment are slightly different. I am in the process of 1) upgrading to Exchange Server SE and 2) retiring our Server 2016 DCs and replacing them with Server 2025 DCs. I'm going site by site. I did the site that hosted our Exchange Server, so I spun up a VM and installed Exchange Server SE. I am seeing the duplicate msExchBaseClass value in auxiliaryClass in at least one attribute now, and probably more, and I also have broken replication due to schema mismatch errors happening.

The one wrinkle with my environment is that replication is only failing between my HQ Server 2025 DC and Server 2016 DCs (we have hub and spoke arrangement. All DCs replicate with HQ Server 2025 DC). Replication between HQ Server 2025 DC and the other Server 2025 DCs is working as far as I can tell. This may be a case that Server 2025 is able to 'work it out' when it sees the duplicate value there where Server 2016 chokes on it. I have 4 2025 DCs up and running and only 3 2016 DCs left, so I contemplating just trashing the 2016 DCs with forced removal and meta data clean up and moving on...though I will have a couple of sites that will have to reach through VPN to our HQ location's DC for logon, DNS, and NPS services for a bit, whcih makes me slightly nervous. But doing surgery on my Schema with ADSI Edit also makes me nervous. I am also unsure if I can promote a new DC while this problem is ongoing; I haven't tried that yet, have no idea on that one.

I'd feel better if someone had a fresh installation of Exchange Server 2019 or SE in an environment with only newer Server OS DCs in place to see if the duplicate value is normal or not.
Brandon Poindexter 71 Reputation points

2025-08-03T02:51:22.3966667+00:00

I am experiencing almost exactly the same issue. Replication is failing between my Server 2025 DC and Server 2016 DCs (of which we don’t have many left). However replication is working fine between Server 2025 DCs.

I am extremely uneasy at the idea of fixing this manually with ADSI Edit. Do you still have your powershell script that found the troublesome attributes? I wrote a quick script that found the objects with the auxiliaryClass attribute where it had two values, both msExchBaseClass. I found 61 such objects. If you still have your script id like to compare results.
Brad Hunt 30 Reputation points

2025-08-04T12:49:20.1166667+00:00

Brandon,

Sorry you're seeing this issue as well. When we were working through this, I found that I could check for event 1203 in the directory service event log, and it would point me to the object that was causing the schema mismatch. Once I fixed that object by changing the duplicated value to a single value, I would see another 1203 event pointing me to the next problem spot. After going through this process to come up with the list of 67 objects, I did write a script I could run for each DC to check the 67 values for duplicates. I did have one DC that was a bit more isolated that still had the duplicated values, and the script helped me find it. Otherwise, just going through those 1203 events fixed everything else. I'm happy to provide the script, but I'm not positive if it will let me attach it here?
Brandon Poindexter 71 Reputation points

2025-08-04T13:36:29.78+00:00
No problem on the script. I have been writing my own script.

I do have some questions about your environment. I've been testing in a lab and have replicated the issue. It appears there's some specific conditions needed for this problem to setup; I don't know all of them, but I can specify a lab environment that will replicate the issue.

Setup Server 2016 DC.

Install Exchange 2016.

Add a Server 2025 DC to the test domain

Add an Exchange SE server to the domain

Problem occurs

I know that if I install a Server 2025 DC and then an Exchange SE server in a lab domain the problem does not occur. There's something about having an existing Exchange server, or existing 2016 DCs (which we are actively retiring) that creates this problem.

For an additional piece of informaton: my Server 2025 DCs (of which we have 4) are working and replicating fine. They don't seem to be failing on this duplicate multi-valued attribute. It's ONLY my two remaining Server 2016 DCs that are having problems. I have those powered down for the moment and out of the loop, and network settings altered to keep things like NPS authentication, Windows logon, etc, running normally.

I have a ticket open with Microsoft support as well. I am probably going to talk to them about it before I start manually editing the AD Schema, just out of caution, and I'm not in a full emergency situation here yet, so I have some time to consider the issue before proceeding.

I am going to test your method in a lab environment to see what happens though, so I can at least establish if your fix is going to work for us.

I will update this thread for posterity, because it seems like there's a very specific condition your domain can have that gets you into this trouble, and I'd like to have it documented out here for anyone else who encounters it.
Brandon Poindexter 71 Reputation points

2025-08-04T20:48:57.6966667+00:00

I tested your solution in the lab and it did, in fact, restore replication and got everything working as far as I can tell. At least there were no replication errors due to schema mismatch. I need to test more to see if it has had any effect on Exchange functions.

Worth noting. auxiliaryClass is not the only attribute where I had duplicate values though it was the vast majority. possSuperiors was another that came up with duplicate values. I worked through all of them. I found about the same number of total objects you did.

Since things are otherwise working I am going to take the time to discuss with Microsoft support. I’m also going to deploy a healthy lab environment and compare the unhealthy lab’s objects to the healthy labs objects just for thoroughness.
Brad Hunt 30 Reputation points

2025-08-05T19:29:10.0433333+00:00

FYI, I also had 5 possSuperiors as well as 1 mayContain that were duplicated. I'm attaching the full list in case it is helpful... hopefully it comes across ok. I'll be interested to hear what Microsoft support has to say about the issue.

DuplicatedAttributes.txt
Brandon Poindexter 71 Reputation points

2025-08-06T12:30:57.28+00:00

I compared your list to mine. Mine are formatted slightly differently so it's possible we have a slightly different list, but if we do it, it's 99% the same. I think they are 100% identical, I just haven't fine tooth combed it enough yet to know with certainty.

Here's an interesting update. I spun up another lab environment that had a single Windows Server 2025 DC and a single Exchange Server SE running on Server 2025. Ran schema prep. Looked good. Ran schema prep again (which you are generally supposed to be able to do; otherwise it would be impossible to properly upgrade a domain from, say, Exchange 2013 to 2016, then to 2019, etc) and what do you know...duplicate values in multi-value attributes. Exact same ones.

This has nothing to do with migration from older Exchange/Windows Server to newer. There are only two possibilities in my mind: either Microsoft is adding this to the schema intentionally to support some forthcoming feature, or this is a bug in Exchange Server SE's schema prep step. There are no other reasonable possibilities.

To confirm this, I spun up another lab with a Server 2016 DC and Exchange Server 2016 and repeated the same steps. Install Exchange 2016, the run schema prep a second time. No duplicate values.

I think I am going to see if Microsoft has a bug report submission tool and just submit it. It really looks buggy from here especially in light of how schema prep behaves in other versions of Exchange.
Brandon Poindexter 71 Reputation points

2025-08-07T14:48:48.32+00:00

Update. I have not gone through your list of attributes and mine line by line yet, but your list contained exactly 68 records, and so does my list. I suspect they are identical. I am confirming this.
Brandon Poindexter 71 Reputation points

2025-08-07T15:15:36.3566667+00:00

Further update: I think it was actually 67 records, not 68. In any case, I compared my list to yours, and they are identical down the record, attribute, and duplicate value.

I have things on hold that need to not be on hold for the moment. Since I have an exact listing now of affected objects, I am going to finally dispose of my old DCs and get things back into a semblance of normalcy, and continue to try to get MS support to look at this.
Brad Hunt 30 Reputation points

2025-08-07T15:38:58.96+00:00

I do appreciate you trying to track down the issue, and glad to know it wasn't something specific to our environment. I had opened a case with Microsoft over the July 4th weekend when I first encountered the problem, and I didn't hear anything back for a week or so. In the meantime, I managed to Google my way through it. Hope your experience goes a little smoother!
Brandon Poindexter 71 Reputation points

2025-08-07T15:44:32.0966667+00:00

For me, one of the big hints was some of Microsoft's own guidance: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/schema-mismatch-error-ad-installation-wizard-dcpromo

See the seciont Method 1, Part 4. The money quote is from step 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.

This article is in the context of schema mismatch occurring during promotion of a new DC, but it's the same error with the same cause. It makes me wonder if this was happening often enough in previous Exchange versions that Microsoft finally modified Windows Server 2025 to just kind of "work it out" and that's why 2025 DCs are good to go and my older are having a problem.

And who knows. I'm not just retiring my old 2016 DCs, they are being replaced by newly created 2025 DCs. If promotion for the new DCs fails, I may fall back to manually editing the schema after all.
Brandon Poindexter 71 Reputation points

2025-08-12T18:52:12.84+00:00

Small update. I finished performing forced removal and metadata cleanup on my remaining 2016 DCs late last week and promoted new 2025 DCs to replace them. This process worked completely normally with no issues. All DCs in production are now on Server 2025 and are working normally at Server 2016 DFL (we may or may not bother changing the DFL and FFL later. I prefer not to make those kinds of changes until there’s a need in order to gain access to a specific feature).

The duplicate values remain in place in the AD schema, but in a pure Server 2025 environment (in terms of DCs and Exchange SE being run on Server 2025) this has not caused any problems yet. I did have some major issues migrating arbitration mailboxes from our old Exchange Server to the new one, however, this appears to be a result of database corruption on the old server (we use Exchange on premise solely for managing mailboxes in Exchange Online. Though our deployment is “hybrid” we host no mail functions on premise whatsoever. Loss of the arbitration mailboxes to mailbox database corruption was a non-event for us that we simply didn’t care about. We made new arbitration mailboxes to keep Exchange happy and moved on).

I do not know if this duplicate value / schema replication problem will afflict Server 2019 or Server 2022 DCs. I’m a bit busy this week but if I can find time to lab test, I will, and post back results.

Share via

Cleanup from issues experienced with Exchange Server 2019 CU15 PrepareSchema and PrepareAD

2 additional answers

Your answer