Article ID: 322692 - View products that this article applies to.
This article was previously published under Q322692
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 roll back 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 levelCaution 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
(http://technet.microsoft.com/en-us/library/cc759280(WS.10).aspx). 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 the TechNet article that discusses this method
View and set the functional level manuallyThe 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 settingsThe msDS-Behavior-Version attribute is on the naming context (NC) head for the domain, i.e., DC=corp, DC=contoso, DC=com.
The following are the values that can be set for this attribute:
Mixed mode and native mode settingsThe ntMixedDomain attribute is on the naming context (NC) head for the domain, i.e., DC=corp, DC=contoso, DC=com.
The following are the values that can be set for this attribute:
Forest level settingThe msDS-Behavior-Version attribute is on the CN=Partitions object in the Configuration naming context (NC), i.e., CN=Partitions, CN=Configuration, DC=ForestRootDomain.
The following are the values that can be set for this attribute:
Quickly view the current settings by using the Ldp.exe file
Note The domain controller functionality represents the highest possible functional level for this domain controller.
Requirements when you manually change the functional level
Functional levels relevant to Windows 2000 ServerWindows 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 a number of 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)
Windows 2000 Server native
Windows Server 2003 interim
Windows Server 2003
Interim level - upgrade from a Windows NT 4.0 domainWindows 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:
Setting Windows Server 2003 interim forest functional levelWindows 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:
Best practicesThe 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:
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 increaseIn 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:
(https://support.microsoft.com/kb/216498/ )How to remove data in active directory after an unsuccessful domain controller demotion
Verify that End to End replication is working in the forestTo 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:
Prepare a back-out plan that includes of one of the following actions:
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 re-promote 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 levelIncrease 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:
Windows NT 4.0 upgradesWindows 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:
Special consideration for large groups in Windows NT 4.0In 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:
Version store issues with large groupsDuring 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 100megabytes. 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.
Article ID: 322692 - Last Review: February 18, 2013 - Revision: 18.0