problem extending schema on domain controller to prep for sccm


Well it's the start to a 3 day weekend so I thought it would be a good time to try and extend the schema in my Windows 2008R2 environment which is required for SCCM.  This is a Single Domain environment and the DC i'm extending on has all 5 FSMO roles meaning one of those is Schema Master so that is the box that I tried to extend on.  First, this is a virtual server and I wanted to get a backup prior to attempting the schema change so I powered it down, captured a snapshot, "disabled the nic on power up" in vCenter and powered it up so it cant replicate a bad schema to other DCs if it went bad.  I then ran ExtADSch.exe which is the tool which you are supposed to run to extend the schema.  It flashes a black cmd screen then I go an check extadsch.log which is the only indication of how it turned out.  I get the following error messages in the log (see attached).  Basically a lot of Error Code = 8224 and Error Code = 8202.  I ran the .exe as a domain admin which is a member of schema admins.

So my dilemma now is that I just need to start back up the primary DC so the domain is running again the way it needs to be because this is also my print server.  I am wondering if the log message I got indicates that some of the schema has been altered and turning the DC back on with an ENABLED nic so it can replicate would be bad or did nothing really get altered in the schema according to the log message? it an all or nothing deal?  If part of the schema got altered do I need to revert to my VMware snapshot of the Primary DC?  

Does anyone know why I was getting the error message in the log when trying to extend?  Perhaps I can still make it a successful schema update and then can connect my primary DC back into the network so it can replicate with other DCs.

So 2 questions really:
Did i alter the schema partially or did the log just indicate that the schema extend did not work and nothing happened.  I would l really like to plug my DC back into the network but am afraid it might replicate a partially bad schema.
And, any idea what might be causing the schema to not extend.

Any help would really put my mind at ease.

Thank you very much.

extadsch log
Shawn DoneAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Here is one quick thing to try: Run ExtADSch.exe from an administrative command prompt ("run as administrator") and see if that allows the schema updates to proceed.

If that does not work, it could be failing due to a replication issue since the DC is now disconnected. A few posts on other sites where users have encountered the same issue have stated that once the DC was successfully replicating with its partners, the update succeeded.

In regards to your questions, I don't think any schema was updated. Here is a power shell script to run a schema update report: - Although, I don't think this will show partial updates.

When upgrading schema, I prefer to leave all the DCs online, and use the "old/original" schema update method to prevent replication. Microsoft endorsed this at one time (Win2000-to-2003), but they stopped because people forgot to turn replication back on and thus more calls to Microsoft support. The command is: repadmin /options <ServerName> +DISABLE_OUTBOUND_REPL to *STOP* outbound replication. You can stop inbound replication as well using the repadmin /options  <ServerName>  +DISABLE_INBOUND_REPL. Change the [+] to a [-] in these commands to enable replication once the schema updates have been successful.

I have had conflicting schema IDs (with third party schema updates) prevent schema updates from finishing, and the schema was left partially updated for a period of time. I had the outbound/inbound replication stopped, and resolved the issue after locating the duplicate ID, and actually modifying Microsoft's update file with a new ID for the object that had the duplicate ID. Even if I did not have the inbound/outbound replication stopped, I don't think there would have been an issue.

Hope that helps.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
One other comment - You do have good DC backups (other than VM snapshots), correct? :)
Shawn DoneAuthor Commented:
Hi JB,

I did previously try the "run as administrator" on cmd and that gave the same error results when trying to extend.

I also read that other people left their DC connected while running the schema update and that fixed it for them.  If I'm reading your post correctly, your command disables replication between other DCs, (same as me disabling the NIC) so the DCs wouldn't be able to talk as well.  How would the ExtADsch.exe run successfully if replication was disabled by using "repadmin /options <ServerName> +DISABLE_OUTBOUND_REPL"?

It almost seems like you just need to leave the DC that is schema master on and allow replication and just go for it.  If the DC needs to replicate in order for ExtADSch.exe to run successfully, what else can you do?  Then if something horrible goes wrong you have to use your backups.  I do have backups of the VMs other than the snapshot.

So my thought now is to power up the DC with the NIC enabled so it can talk to the other DCs and try to run ExtADSch.exe again.  Hope I get a successful log report and go from there?

Sound good JB?
Thank you for the reply.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Shawn DoneAuthor Commented:
Hey JB,
So this is where I'm at now:
I ran the "repadmin /options +DISABLE_OUTBOUND_REPL" and then I rebooted the DC1 (schema master) and enabled the NIC so it was back online but no outbound replication.  I ran the ExtADSCH.exe and the log files showed this:
<08-31-2014 09:27:33> Modifying Active Directory Schema - with SMS extensions.
<08-31-2014 09:27:34> DS Root:CN=Schema,CN=Configuration,DC=DOMAIN,DC=GOV
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Site-Code.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Assignment-Site-Code.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Site-Boundaries.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Roaming-Boundaries.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Default-MP.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Device-Management-Point.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-MP-Name.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-MP-Address.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Health-State.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Source-Forest.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Ranged-IP-Low.
<08-31-2014 09:27:35> Defined attribute cn=MS-SMS-Ranged-IP-High.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Version.
<08-31-2014 09:27:35> Defined attribute cn=mS-SMS-Capabilities.
<08-31-2014 09:27:36> Defined class cn=MS-SMS-Management-Point.
<08-31-2014 09:27:36> Defined class cn=MS-SMS-Server-Locator-Point.
<08-31-2014 09:27:36> Defined class cn=MS-SMS-Site.
<08-31-2014 09:27:36> Defined class cn=MS-SMS-Roaming-Boundary-Range.
<08-31-2014 09:27:36> Successfully extended the Active Directory schema.

<08-31-2014 09:27:36> Please refer to the ConfigMgr documentation for instructions on the manual
<08-31-2014 09:27:36> configuration of access rights in active directory which may still
<08-31-2014 09:27:36> need to be performed.  (Although the AD schema has now be extended,
<08-31-2014 09:27:36> AD must be configured to allow each ConfigMgr Site security rights to
<08-31-2014 09:27:36> publish in each of their domains.)

So I took that to be a good sign so then I ran "repadmin /options NSCDC1 -DISABLE_OUTBOUND_REPL" to enable Outbound replication again and got this message:
New DSA Options: IS_GC

Not sure what that means but I ran repadmin /showreps and I got the following about "replication failed because of a schema mismatch between servers involved" and now I'm frightened. (see attached)

Any thoughts on what to do from here.  Now I have a schema mismatch and items are fully replicating.  I'm not sure if there's more I need to do or does this mean I officially have a messed up domain and need to pull from backups?

Thank you again for any help.
Shawn DoneAuthor Commented:
It seems if you wait long enough, that schema mismatch will go away.  I guess the schema itself needs to replicate between DCs as well.  After about 15 minutes and trying the command again, it did not show and adding a user account on one DC it would show up on the other DC shortly after.
I guess I'm good now.  That's not a fun process to go through your first time.
Any thoughts on anything else I should check or do you think i'm good?
Thanks for all the help.
Hi Shawn,
From my experience, schema updates (at least the ones from Microsoft) usually go pretty smooth. You just have to take precautions so you can recover. It can certainly be scary the first time.

What you described seems normal where the schema had to replicate to other DCs. I suspect if we had also issued the repadmin command to stop inbound traffic, we may have been able to avoid those error messages, but, as you've seen, they will all clear up in time once inbound/outbound replication is back on.

I'm not sure what other tools you have at your disposal to check the health of your AD, but you could run a "repadmin /replsum" to do a quick check of replication results. If that shows no errors, then I think you're good. If you wanted to go further, you could even dump your schema to a file using the 'ldifde' command (ldifde -f <file> -d CN=Schema, CN=Configuration, DC=<Domain>, DC=<gov,com,etc>) and then look for the attributes/objects that should have been created. Prior to your next schema update, run the 'ldifde' command and it will show the number of entries that exist. Run it again after the update and you'll be able to quickly see the difference.

One other note regarding AD backups: I would actually stop both inbound and outbound replication, shut down the DC, prior to creating a snapshot to revert back to, that is *IF* you wanted to rely on that method, I really don't like the revert-to-snapshot for DCs - It's just too risky for me, and Microsoft's official guidance is NOT to do it... There is too much potential for a USN roll-back, etc. That doesn't mean that you couldn't be successful in using the method, but I'm not sure the level of support you'd get if you contacted MS support for help.

Let me know if you have any other questions, but I think you're good if you see no replication errors.
Shawn DoneAuthor Commented:
JB was really knowledgeable and took the time to walk me through a first time frightening schema upgrade.  Thanks again.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.