Schema Version registry subkey

Posted on 2006-07-04
Last Modified: 2013-11-19
I have what I think is a simple question but I can't seem to find the answer.  I have a parent domain (2003 SP1) and several child domains (2000 SP4).  I want to extend the forest-wide schema with the second CD of 2003 R2 using adprep/forestprep via the Schema Master domain controller in the parent domain.  I ran this in a test lab and received a successful completion message.  To make sure the schema version number was updated from 30 to 31 I looked at the Schema Version subkey under HKLM\System\CurrentControlSet\Services\NTDS\Parameters. The problem is that there are two registry entries:  "Schema Version" and "System Schema Version".  The "Schema Version" subkey has a value of 31 and the "System Schema Version" subkey has a value of 30.  I waited a couple hours but the second value never changed to 31 (I also tried a reboot).  I do not intend to install the R2 capabilities on this domain controller.  I just want to update the schema so that the R2 capabilities can be used downstream (the child domains 2000 DCs will be updated to 2003 R2 later).

If I run forestprep in my production system will the schema change replicate forest-wide even though I don't actually install R2 on the schema master?

I'm also worried as to why the "System Schema Version" did not change from 30 to 31, however, the "Schema Version" did change from 30 to 31.

Thanks for any advice you can provide.

Dave Garner
Question by:davidgarner
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 51

Accepted Solution

Netman66 earned 500 total points
ID: 17039736
Yes, the Schema will replicate Forest-wide.

Did you run adprep /domainprep /gpprep ?


Author Comment

ID: 17039802
According so some other docs I read the /domainpep is not necessary on a domain that is already 2003.  As a test though I did run "adprep /domainprep" and received a response that domainprep was not needed (it did not run).   I then ran "adprep /domainprep /gpprep" and it did run that command successfully although I'm not sure why.  The Microsoft docs expalin that if the pre-SP1 version of adprep is run when you migrate from 2000 to 2003 that the function of the (future) gpprep switch is performed anyway.   It said that the adprep version supplied with SP1 added the "/domainprep /gpprep" so that this latter command could be run later to apply the group policy permission changes.  Here is a snippet from Microsoft - it's kind of a convoluted read so read it carefully:

>>>> begin quote from Microsoft >>>>

In the version of Adprep.exe that is included with Windows Server 2003 SP1, the adprep /domainprep command performs the same operations as in the earlier version of Adprep.exe. However, the updated command does not modify permissions on GPOs unless you use the new /gpprep switch. After you install the updated version of Adprep.exe, you receive the following message when you run the adprep /domainprep command:
The new cross domain planning functionality for Group Policy, RSOP Planning Mode, requires file system and Active Directory permissions to be updated for existing Group Policy Objects (GPOs). You can enable this functionality at any time by running ?adprep.exe /domainprep /gpprep? on the DC that holds the infrastructure operations master role.

This operation will cause all GPOs located in the policies folder of the SYSVOL to be replicated once between the domain controllers in this domain. Microsoft recommends reading KB Q324392, particularly if you have a large number of Group Policy Objects. • adprep /domainprep /gpprep

The functionality of the adprep domainprep /gpprep command depends on the state of the domain. If the updated adprep /domainprep command has not been run, this command is the functional equivalent of the adprep /domainprep command in the original release of Windows Server 2003. In these circumstances, the command performs all the domain operations that are listed in Microsoft Knowledge Base article 309628. These operations include setting the permissions for GPOs in the SYSVOL. If the updated adprep /domainprep command has already been run, the adprep /domainprep /gpprep command adds only the inheritable access control entries (ACEs) on GPOs in the Sysvol shared resource. The additional ACEs give enterprise domain controllers read access permissions on GPOs. These permissions are required to support Resultant Set of Policy (RSoP) functionality for site-based policy.

>>>> end quote from Microsoft >>>>

So this still leaves my original question:  Why are there two incarnations of the Schema Version subkey in the registry and why is one at 30 and the other at 31?

LVL 51

Expert Comment

ID: 17041899
I believe the System version is held because you still have some 2000 AD servers in the Forest - athough I can't be completely certain.

I checked my server and both values are 31.  I had one 2000 server in the domain that I have since removed - it might have been interesting to see if this value was the same as yours with that server still in the forest.

What happens if you run this?:  Schupgr.exe (c:\Windows\System32)

You should get a bind error then it should update.

Let me know.


Expert Comment

ID: 17654438
New Title: Worrisome registry subkey values when extending schema from w2k3 sp1 to w2k3 r2

I was faced with the same question and believe I've found a much better answer, described below.

First, note that we are dealing with two separate registry subkeys,
  "Schema Version" (Reflects the Version of the Schema container within the Schema Partition of the AD database shared by all DCs  in an existing AD Forest)
  "System Schema Version" (Reflects the Version of the souce files contained in an instance of the OS used for creating an initial copy of the Schema when promoting a server to become the first DC in an AD Forest. Updating the OS updates these source files.)

These two values do not change in tandem in all circumstances. I am confident that this is only a documentation problem, not a  software problem. My lab tests forced me to question both Microsoft's documentation and their premier support personnel, who told  me there are errors in kbid=917385, but that the correct information for the registry subkeys related to the schema extension for R2 can be found at:

NOTE: On the TechNet web page, click the "Data Store Group Policy Settings" link and then scroll up a few lines to see the two  registry entries in question, which are at the bottom of the list in the preceding section. They are the last two entries in a  list of registry settings associated with the data store. The information there is provided as a reference for use in  troubleshooting or verifying that the required settings are applied.

Like the original poster of this question, what I saw and read also made me initially question the success of the schema  extension I did in my lab, because a registry subkey value (System Schema Version) did not increment from 30 to 31 as described in kbid=917385. Several other blogs and newsgroups contained the same observation, but they did not contain a definitive explanation for the discrepancy. I would feel comfortable doing the schema extension now that I have used due diligence to test  it, but I would still like to see Microsoft correct and clarify this issue since neither Microsoft explanation for when that
value would change to 31 proved true in the lab. I did get it to change, but only as described below.

I performed the schema extension at the console on one DC in the forest. This incremented to 31 the value of the first registry  subkey, "Schema Version", on all DCs in the forest. The Schema conatiner (distinguished name is  cn=schema,cn=configuration,dc=<domain>), which is within the Schema Partition, is replicated to all DCs in an existing AD Forest  because it is part of the AD database. Do not confuse this with the Configuration Partition nor the Schema Partition. Using
ADSIEdit, you can view the properties of this container by right clicking it. If you don't see the properties option when you  right click it, you are probably looking at the Schema Partition. Drill down one level to right-click the Schema container, then  click Properties. There, I found the value of the objectVersion attribute also to be 31. Subsequently, I upgraded the OS  on a DC in the same forest to W2K3 R2, which incremented the value of the second registry subkey, "System Schema Version", but  only on that server.

So starting with a DC with W2K3 SP1, and then entering "ADPREP /forestprep" at a command prompt to update/extend the schema for  R2 did change the value of the registry subkey "Schema Version" from 30 to 31. Afterwards, I looked at the contents of  schupgr.log (attached) and it reads,
  Current Schema Version is 30
  Upgrading schema to version 31
but it does not mention that this is also the name of a registry subkey.
Nothing in this first set of log files refers to a value called
  "System Schema Version."
Also, the registry subkey called "System Schema Version" was still at 30 after the schema was extended.

When I subsequently ran R2AUTO.EXE (on CD 2 of the two R2 CDs) to start the setup wizard to upgrade the OS on that DC from w2k3 sp1 to w2k3 R2, even before I clicked the Finish button in the setup wizard, the "System Schema Version" registry subkey went from 30 to 31 on that server only. Afterwards, I looked at the contents of windows_r2setup.log (attached) and it reads,
  Updating the System Schema Version
but again, it does not mention that this is also the name of a registry subkey.

This is how
reads regarding this key:
  "You can verify the operating system support level of the schema by looking at
  the value of System Schema Version registry subkey on a domain controller.
  You can find this subkey in the following location:
Again, Microsoft personnel acknowledge that this article is flawed, but the article they cited with the "correct" information,, seems weak too, at least under the conditions I described above. Performing these steps in the order listed above, my experience indicates that "System  Schema Version" registry subkey shows, among other things, whether w2k3 R2 setup has been run on just the local server or not,  and does not show the "support level of the schema". I humbly suggest that Microsoft make the following correction where  appropriate, if it proves to be totally accurate:
  Change to: "You can verify the latest version of an existing AD forest’s schema
             that is known to a DC by looking at the value of the registry subkey  
             'Schema Version' on that DC".

There really is a subkey called simply "Schema Version" and it does change from 30 to 31 at the time the schema is extended  (allowing time for replication to other DCs, where you can then see the new version). Notice the absence of the work "System" in the name of this subkey. This is true at least on a DC that is running w2k3 in w2k3 native mode. I have not yet tested any of the other 100 possible scenarios. I humbly suggest  that Microsoft also make the following addition where appropriate, if it proves to be totally accurate:
  Add: "You can verify the operating system’s corresponding schema version,
       but only for a particular computer, not the forest, by looking at
       the value of the 'System Schema Version' registry subkey on just that
       computer. Successfully running R2AUTO.EXE (on CD 2 of the two W2K3 R2
       CDs), to upgrade to W2K3 R2 on that computer, will update the 'System
       Schema Version' registry subkey on that computer. This value reflects
       the Version of the souce files contained only in this computer's
       instance of the OS that would be used for creating an initial copy of the Schema
       when promoting a server to become the first DC in an AD Forest. If
       the forest already exists, these files will not be used in this forest
       because the schema also already exists."

If this does not prove to be accurate in general, then I request that Microsoft clearly state the conditions and explain the scenarios under which each of these keys should be at a value of 30 or less, and when it will change to 31.

The same article (kbid=917385) also says:
  "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 System
  Schema Version registry subkey and the objectVersion attribute are in decimal."
The test I did in the lab shows that these two items do not always increment in tandem, although the text of the article implies that they do.

The same article (kbid=917385) also says:
  System 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
There appears to be no problem with the list of values themselves, but the description of what causes them to change still needs work.

This is how
reads regarding these keys:
'Schema Version'
    Registry path

      Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server;
      Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows
      Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

      Contains the schema version for which a particular operating system is configured.

This seems to be an error for the "Schema Version" subkey, but it seems to be more-or-less true of the "System Schema Version" subkey described below.

'System Schema Version'
    Registry path

      Domain controllers running Windows Server 2003, Standard Edition;
      Windows Server 2003, Enterprise Edition;
      and Windows Server 2003, Datacenter Edition.

      Contains the version of the schema at the time that a backup is taken.
      This value is used to prevent an incompatible schema version from being
      restored from backup.
I saw no evidence that the value changes "at the time that a backup is taken" for either key, but I did see evidence that this value changes, on just that one computer, to 31 when the OS is upgraded to R2 (run R2AUTO.EXE, found on CD 2, the second CD of  two R2 CDs). After the upgrade, I suppose it would be important to prevent an incompatible version of the files used to create the schema from being restored from backup.

Hope this helps. jcsontag

Expert Comment

ID: 25944500
Jcsontag, you are absolutely right! From my own observation in my Windows 2003 server environment, I believe you have explained "Schema Version" and "System Schema Version" very well in details. Well done!

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Shoutout to Emily Plummer ( for giving me this article! She did most of it, I just finished it up and posted it for her :)    Introduction In a previous article (http://www.experts-exchang…
A quick step-by-step overview of installing and configuring Carbonite Server Backup.
Viewers will learn about if statements in Java and their use The if statement: The condition required to create an if statement: Variations of if statements: An example using if statements:
The viewer will learn the basics of jQuery including how to code hide show and toggles. Reference your jQuery libraries: (CODE) Include your new external js/jQuery file: (CODE) Write your first lines of code to setup your site for jQuery…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question