Shawn Done
asked on
problem extending schema on domain controller to prep for sccm
Hello,
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?...is 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.
Shawn
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?...is 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.
Shawn
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
JohnB442
One other comment - You do have good DC backups (other than VM snapshots), correct? :)
ASKER
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.
Shawn
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.
Shawn
ASKER
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=Configur
<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-
<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-Boundari
<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-Managemen
<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-P
<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
<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
schema-mismatch.txt
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=Configur
<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-
<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-Boundari
<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-Managemen
<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-P
<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
<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
schema-mismatch.txt
ASKER
Well,
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.
Shawn
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.
Shawn
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.
-JB
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.
-JB
ASKER
JB was really knowledgeable and took the time to walk me through a first time frightening schema upgrade. Thanks again.