Since Active Directory was included as part of Window Server 2000, administrators have often asked for  a simple way to roll back mistakes, whether that is the incorrect deletion of the wrong user account to the accidental removal of thousands of objects by deleting an OU. Before the release of Windows Server 2008 R2 there were a number of ways using built-in or third-party methods to restore Active Directory objects, but typically they were not as quick or complete as say retrieving a deleted email or file.

Microsoft has included with their release of Windows Server 2008 R2 the facility, under the correct conditions, to enable a Recycle Bin for Active Directory and allow simple restoration of objects which have been erroneously removed. In this article we will briefly cover some of the options prior to 2008 R2 and then examine how to enable the new Recycle Bin and restore objects from it.

Pre-Windows Server 2008 R2

The 2008 R2 Recycle Bin for Active Directory is a great motivating point for upgrading your forest and domain(s) to the latest version, but this is not always a quick process in many enterprises so it is worth knowing what options are available prior to this version. Like many things it’s a lot better to examine and plan for possible resolutions before a significant mistake happens that you need to deal with. Retrieving Active Directory objects typically falls into two available categories, authoritative restore from a backup or tombstone reanimation.

Authoritative Restore

The Microsoft KB article 840001(http://support.microsoft.com/kb/840001) details how to perform the restoration of a user account using a system state backup of a domain controller. Typically, you would use a global catalog so that you can also restore all group membership information.

Tombstone Reanimation

The above article also details how to recover an account when you don’t have a system state backup by using tombstone reanimation which was introduced with Windows Server 2003 – you can retrieve objects from the Deleted Objects container where they are kept after deletion until their tombstone period expires. Obviously regular system state backups of Active Directory are critical for your full disaster recovery procedures, but taking advantage of tombstone reanimation means you can get objects back quicker than having to go through the full authoritative restore process.

You could use the procedure in the article which utilises the ldp.exe tool, but there are other methods around which you may find simpler.

• The article itself links to a Sysinternals tool, ADRestore (http://technet.microsoft.com/en-us/sysinternals/bb963906.aspx), which is a command line tool for reanimating objects.

• The free ADRestore.Net, a GUI tool made by Microsoft PFE Guy Teverovsky. http://blogs.microsoft.co.il/blogs/guyt/archive/2007/12/15/adrestore-net-rewrite.aspx.

• Quest produces a freeware product Object Restore for Active Directory, an easy to use GUI tool. http://www.quest.com/object-restore-for-active-directory/ (Note: there is a commercial version with more features, Recovery Manager for Active Directory.)

• Quest also produces a cmdlet library for managing Active Directory with Windows PowerShell (http://www.quest.com/powershell/activeroles-server.aspx). As of version 1.2 a number of the cmdlets had a Tombstone parameter added to them so that a search of objects would also include items which have been tombstoned. These results could then be piped through to the new cmdlet Restore-QADDeletedObject to undelete the object represented by the tombstone.  For instance the command Get-QADUser –Tombstone -LastChangedOn  ((Get-Date).adddays(-1)) | Restore-QADDeletedObject would restore all user accounts deleted yesterday.

The drawback with tombstone reanimation is that because most of the object’s attributes are removed at the time of the object’s deletion, a restored object using this method requires many properties of the account, such as address fields and group membership, to be manually repopulated. Whilst this is obviously preferable to re-creating an account from scratch it does not make for a quick overall process. However, you will at least get back the objectGUID and objectSid attributes which means there would be no need to re-configure a user’s workstation profile.

The original release of Windows Server 2008 introduced snapshot backups for Active Directory. You can take point-in-time snapshots of your Active Directory with the NTDSUTIL command line utility which utilizes Volume Shadow Copy to provide a snapshot. It is then possible to mount this snapshot using different ports on the same domain controller as the live Active Directory database and use standard tools to compare the two. This could really make the tombstone reanimation a lot simpler because after restoring the object you could view two versions of Active Directory Users and Computers side by side and view the properties of the restored object from a previous time, so making it simpler to repopulate properties.

The Directory Service Comparison Tool (http://lindstrom.nullsession.com/?page_id=11) takes advantage of these snapshots and makes the repopulation process more streamlined.

For those with Microsoft Exchange messaging environments, once you have the Active Directory account back, you can use the Reconnect Mailbox feature within Exchange to tie the restored account back up with the mailbox. This is of course providing you have a similar tombstone retention period for mailboxes that you do for AD accounts.

Active Directory Recycle Bin

The real reason you decided to read this article though was not so that we could spend time going over all the possible options for how you can piece together restored AD objects, but rather to find out how the Recycle Bin is going to make your life as an Active Directory administrator easier without necessarily the need for these different tools. The key differences from previous versions of Windows Server are that by default you get all of the attributes back and the tools to use are PowerShell cmdlets, which are quickly becoming a more essential part of every Windows administrator’s standard toolkit.

Firstly though the Active Directory Recycle Bin is not enabled by default and has certain domain and forest wide requirements before it can be enabled.

• Firstly, all domain controllers within the Active Directory forest must be running Windows Server 2008 R2.
• Secondly, the functional level of the Active Directory forest must be Windows Server 2008 R2.

Naturally organizations are typically cautious when upgrading Active Directory and these types of infrastructure projects don’t tend to happen quickly, but the Recycle Bin could be one of the features which gives you more weight behind a decision. You should also be aware though that enabling the Recycle Bin is a onetime only move, there’s no easy way to disable it again, so careful consideration of this decision must be taken.

It’s worth noting that if you are making a fresh forest install of Windows Server 2008 R2 the Active Directory schema will already include all of the necessary attributes for the Recycle Bin to function. If however you are upgrading your domain controllers from previous versions of Windows Server then you will need to run the well known procedure of adprep /forestprep and adprep /domainprep (for each domain) and possibly adprep /domainprep /gpprep (for Group Policy preparation)

before you can introduce Windows Server 2008 R2 domain controllers into the environment.

So let’s go ahead and run through all the steps we need to get the Recycle Bin enabled. Firstly, ensure that all of your domain controllers are running Windows Server 2008 R2 and then we need to use PowerShell; the great news with Windows Server 2008 R2 is that version 2 of PowerShell is installed by default and is placed directly on your taskbar.

After you have installed Active Directory Domain Services the Active Directory specific cmdlets are available to use via a module; modules essentially are the evolution of snapins from version 1 of PowerShell. To access these cmdlets you can either open the Active Directory specific version of the PowerShell console from the Administrative Programs menu, or the method I would prefer, use the Import-Module cmdlet. (Tip: You could add the below expression to your PowerShell profile so that the cmdlets are available every time you open PowerShell)

PS> Import-Module activedirectory

Once complete all of the Active Directory cmdlets will be at your fingertips. As previously discussed we now need to get the functional level of the forest up to the level of Windows Server 2008 R2. The most common way to do this previously was through Active Directory Domains and Trusts.

Now though we can do this through PowerShell. The Get-ADForest cmdlet will return information about your forest and the Set-ADForestMode cmdlet will enable you to raise the current functional level – since it is such a significant change to your environment you will be prompted to confirm that you wish to go ahead.

Now that our forest is at the correct functional level we can enable the Recycle Bin, to do so we use the Enable-ADOptionalFeature cmdlet. This must be either run on the DC with the Domain Naming Master FSMO role or directed at that server with the –server parameter. Again you will be prompted to confirm your command since the action is irreversible.

Now that we have the Recycle Bin enabled it’s time to go check out how we recover some deleted objects. In this environment we have a very simple AD structure with a couple of test accounts to illustrate the example.

Let’s take the situation where an administrator accidently deletes the Users OU. One of the most common reasons this can happen is because it is actually possible to delete OU’s from the Group Policy Management tool, not just Active Directory Users and Computers – so an administrator might think they are removing a GPO and in a bad moment delete the wrong item and remove a whole OU. The administrator is prompted for what they are about to do, but I have seen it happen more than once!

The initial release of Windows 2008 Server actually included a new checkbox ‘Protect object from accidental deletion’. In the example of the OU below any attempt to delete the OU will be met with an Access is denied response and the administrator will actually have to remove the tick from that checkbox before the OU can be deleted.

However, what you would naturally expect to happen as a consequence of the Protect object from accidental deletion would be any user or computer account created in that protected OU would also be supported by the same mechanism. Unfortunately by default they are not, so as a good practise you would either need to build that into your account creation process or programmatically check and set that checkbox on all accounts in the OU on a regular basis.

Consequently, in the above example if we accept the warning to delete the OU we are greeted with an Access is denied message since the OU has protection set.

So we were saved from deleting the OU, but all of the unprotected child objects were deleted.

(For the purposes of this article I now remove the Users OU by first clearing the checkbox for protecting the object from accidental deletion.)

We can browse the current contents of the Active Directory Recycle Bin using the Get-ADObject cmdlet, directing it at the Deleted Objects container and using the –includeDeletedObjects parameter.

We can see from the resultant output that we have both the Users OU in there and the two user accounts. So let’s try restoring one of the user accounts back, to do so we need the Restore-ADObject cmdlet and supply the ObjectGuid property of the user account.

Oh dear, it failed to restore, but PowerShell tells us that it failed because the object’s parent no longer exists either, i.e. we need to first restore the Users OU. (Note: an alternative would be to use the  -targetpath parameter and re-direct the restore to a different OU)

To restore the Users OU we can use the same cmdlet (Restore-ADObject) as to restore users, just supply the ObjectGuid of the OU.

The Users OU returns.

Now we just need to get those user accounts back. Rather than have to type out the ObjectGuid for each account we wish to restore we can instead create a search which will match all of the accounts we wish to restore and then use the PowerShell pipeline to send those results to the Restore-ADObject cmdlet.

The user accounts are back in the Users OU.

If we check the properties of the account we can confirm that different from tombstone re-animation we get all of the properties back.

Active Directory Recycle Bin PowerPack for PowerGUI

Although the Recycle Bin is a great new feature within Windows Server 2008 R2 Microsoft is already getting feedback that there is no GUI for managing it. Whilst a lot of administrators are comfortable with PowerShell, some may still prefer to use a GUI based management tool for these tasks. Fortunately a great tool to plug this gap has already been provided by the community; PowerShell MVP Kirk Munro has created the Active Directory Recycle Bin PowerPack for PowerGUI (http://www.powergui.org/entry.jspa?categoryID=21&externalID=2461). This free tool has bundled up scripts using the previously demonstrated Active Directory PowerShell cmdlets and provides a graphical front end for administration.

Simply download the PowerGUI tool plus the Active Directory Recycle Bin PowerPack and import it into PowerGUI. Open up the PowerPack and you will have a graphical view of the current contents of the Recycle Bin with the ability to drill down through Organisational Units. Options for restoring single items or recursively are provided in the Actions column as well as alternate restoration paths and emptying items from the Recycle Bin.

It is also possible to use the Configure recycle bin action to set the values for DeletedObjectLifetime, the amount of days objects reside in the Recycle Bin, and TombstoneLifetime, the amount of days objects can be restored using Tombstone Reanimation after they have left the Recycle Bin. In Windows Server 2008 R2 both of these values default to 180 days, in some earlier versions of Windows Server this value was 60 days and if you upgrade those domain controllers it will remain the same so you may wish to change the values – you can use the Modify action to do this.

For this example I have deleted from Active Directory the Resources and Users containers and the two user accounts which you can see nicely in the below screenshot using PowerGUI.

This time we will restore the account Joe Bloggs, but to an alternative location using the Restore to…. Action. (Remember: this is done in PowerShell using the –targetpath parameter of the Restore-ADObject cmdlet) Simply input the path to the Organisational Unit you wish to restore the object to. In this example we use the default Users container as the target location.

The user has been restored to the alternate location; this is particularly useful if we did not wish to bring back the entire OU(s) as we did previously.

If however, you do wish to bring back the contents of an entire OU and everything below it there is an action, Restore (recursive).

Using the Restore (recursive) action in this scenario brings back both the Resources and Users OU’s as well as the single account remaining in it, Jane Smith.

Hopefully in a future release of Windows Server this functionality will be provided out of the box, the most natural home would be a viewable container within Active Directory Users and Computers, until then the Recycle Bin PowerPack for PowerGUI will prove very useful.

Summary

One of the most requested features for a long time with Active Directory has been a Recycle Bin. Microsoft has finally delivered this with the release of Windows Server 2008 R2. It may not be a feature that enterprises get to use for a little while given the system requirements of all 2008 R2  Domain Controllers and your Active Directory Forest at 2008 R2 functional level, but it could be one of those compelling reasons that enables you to pursue an upgrade.

Administration is via the new Active Directory PowerShell cmdlets which Microsoft is using to provide a consistent command line interface across all of their products. Although currently there is no native GUI for these administration tasks, the Active Directory Recycle Bin PowerPack for PowerGUI enables administrators to leverage the underlying PowerShell functionality and provide a graphical interface for carrying out these tasks.

Ways to migrate

As shown last time upgrading your Windows Server 2003 Active Directory environment to Windows Server 2008 can be done in three distinct ways:

• In-place upgrading
  Windows Server 2003 and Windows Server 2003 R2 can both be upgraded in-place to Windows Server 2008
• Transitioning
  Migrating this way means adding Windows Server 2008 Domain Controllers to your existing Active Directory environment. �
• Restructuring
  A third way to go from Windows Server 2003 Domain Controllers to Windows Server 2008 Domain Controllers is restructuring your Active Directory environment. This involves moving all your resources from one (Windows Server 2003) domain to a new and fresh (Windows Server 2008) domain. Tools like the Active Directory Migration Tool (ADMT) are priceless in these kind of migrations.

Reasons to upgrade in-place

In-place upgrading is the path of the least investment. You can simply reuse your existing Windows Server 2003 and Windows Server 2003 R2 Domain Controllers as Windows Server 2008 Domain Controllers.

Just like transitioning In-place upgrading means you get to keep your current Active Directory lay-out, contents, group policies and schema.

In-place upgrading is good when:

• You worked hard to get your Active Directory in the shape it’s in.
• Your servers are in tip-top shape.
• There’s really no budget to buy new servers.

Be sure your current Windows Server 2003 Domain Controllers will last another three to five years when you intend to upgrade them in-place. Transitioning isn’t really any harder compared to in-place upgrading. So if you’re going to do either, please make sure you’re not heading for double work . It would be sad to see you upgrade Domain Controllers now and see you transition in a year from now, while you could’ve easily transitioned in the first place.

Remember: You’re the one with the advantage in negotiations when your boss wants you to go to Windows Server 2008 and really doesn’t want to buy new servers.

Reasons not to upgrade in-place

While I can find two main reasons to perform in-place upgrades, I can find a lot of reasons not to perform them: (and choose another migration path)

• Your servers do not meet the required patchlevel for in-place upgrading
  (The Windows Server 2003 patchlevel should be at least Service Pack 1)
• You want to upgrade across architectures (between x86, x64 and/or Itanium)
• You’re running Windows Small Business Server 2003 or Windows Small Business Server 2003 R2 (upgrade scenarios for Small Business Server are uncertain at this moment)
• You want to switch Windows Server edition (to obtain clustering for instance)
  • Standard Edition can be upgraded to both Standard and Enterprise Edition
  • Enterprise Edition can be upgraded to Enterprise Edition only
  • Datacenter Edition can be upgraded to Datacenter Edition only
• You want your Windows Server 2008 Domain Controllers to be Server Core installations of Windows Server 2008. Upgrading to Server Core is not possible
• Your Windows Server 2003 Domain Controllers are equipped with a boot drive which has less than 14062 MB of free space (solution here ) or your your Windows Server 2003 Domain Controllers do not meet the Windows Server 2008 (recommended) System requirements .
• Applications on your existing Domain Controllers are not tested with or certified for usage on Windows Server 2008.
• Applications or installed components on your Windows Server 2003 have known problems when upgrading in-place to Windows Server 2008. PowerShell and thus Exchange Server 2007 are such programs!

If these considerations leave you with an undesirable outcome (for instance you wanted to migrate from 32bit Domain Controllers to 64bit Domain Controllers) choose to transition your Windows Server Active Directory environment to Windows Server 2008 .

Steps to upgrade in-place

Upgrading your Windows Server 2003 and Windows Server 2003 R2 Domain Controllers in-place to Windows Server 2008 Domain Controllers consists of the following steps:

Before you begin

Avoid common mistakes
There is a very good Microsoft Knowledge Base article on Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain , written by community experts.  I suggest you read it. (twice) Most of the contents also apply to transitioning from Windows Server 2003 (R2) to Windows Server 2008

Plan your server lifecycle
It’s not uncommon for a Domain Controller to sit on your network for a period of five years. I believe you should take this in mind when selecting and buying a server. You should plan your partitions (or volumes) carefully and place the Active Directory files on separate volumes when your needs justify it. The Windows Server catalog helps you pick systems that will run Windows Server 2008 with ease.

Assess your readiness
Microsoft has kindly provided a tool to scan systems to assess whether systems are capable of running Windows Server 2008, whether drivers are available (either from Microsoft update or on the installation media) and what problems you might encounter when upgrading to Windows server 2008. I recommend checking your systems with this tool, which is called the Microsoft Assessment and Planning Solution Accelerator (MAP for short).

Backups
Make backups of all your Domain Controllers and verify you can restore these backups when needed.

Documentation
It is a good thing to know exactly what you’re migrating. When things go wrong you might need to be able to revert back to the old situation. This might require the Directory Services Restore Mode (DSRM) password and credentials for service accounts, which might not be written down anywhere. In multiple Domain Controller, multiple domain, multiple forest and multiple sites scenarios it’s very wise to make a table containing the relevant information per Domain Controller in terms of Flexible Single Master Operations (FSMO) roles, Global Catalog placement, domain membership, site membership, replication topology, routing tables, IP addressing, etc.

Communication
When done right your colleagues might not even suspect a thing, but it’s important to shed some light on what you’re doing. (Make someone) communicate to the end users that you’re going to mess with the core of their infrastructure. This might result in colleagues understanding you’re (really) busy and might also result in problems being reported fast. Both are good things if you’d ask me…

Prepare your Active Directory environment

Before you can begin to upgrade the first Windows Server 2003 Domain Controller to a Windows Server 2008 Domain Controller, you first have to prepare the Active Directory.

Microsoft provides a tool called adprep.exe to facilitate this preparation. You need to run the following commands on the following servers in your Active Directory environment:

You need to run the following commands on the following servers in your Active Directory environment:

* Optional when you want to deploy Read Only Domain Controllers.

After preparing your Active Directory for Windows Server 2008 be sure to check the process. Breadcrumbs to failures may be found in the event viewer, but real men will check the adprep.log files.

Allow sufficient time for proper replication to all your Windows Server 2003 Domain Controllers. (In large environments with specific replication needs this might take hours.) When you feel all changes have been replicated use the replmon and repadmin tools to check and optionally troubleshoot Active Directory replication.

Choosing which Domain Controller to upgrade first

When your Active Directory forest consists of many Active Directory domains, begin your upgrades in the forest root domain.

Flexible Single Master Operations (FSMO) roles are key in your Active Directory environment. When your environment allows it, it is recommended to :

• Transfer all the Flexible Single Master Operations (FSMO) roles from the root domain (3) and the entire forest (2) to a single Active Directory Domain Controller
• Make all Domain Controllers Global Catalogs

Perform an in-place upgrade of the Domain Controller holding all the Flexible Single Master Operations (FSMO) roles first. This will ensure the first Windows Server 2008 Domain Controller is a Global Catalog and all the Flexible Single Master Operations (FSMO) roles are on Windows Server 2008.

After you have upgraded the Domain Controller holding all the FSMO roles in the forest root domain, you can upgrade the Domain Controllers for additional domains in your forest. Place the domain-wide FSMO roles (3) on a single server and upgrade it in-place.

When you’re done upgrading other servers you can redistribute Flexible Single Master Operations (FSMO) roles across other servers, although it is a best practice to keep your Flexible Single Master Operations (FSMO) roles on as little servers as possible.

Upgrade the first Domain Controller

After preparing your Active Directory environment you can start the in-place upgrade on your first Windows Server 2003 Domain Controller. Simply enter the Windows Server 2008 DVD, corresponding to the architecture (x86, x64 or Itanium) and the Edition (Standard, Enterprise, DataCenter) you’re migrating from and to.

In the initial Install Windows screen press the Install Now button to begin installation of Windows Server 2008.

The screen Get important updates for installation gives you the option to either go online and get the latest updates for installation or to skip going online. I recommend choosing Go online to get the latest updates for installation (recommended) , since Microsoft might enhance the Windows Server 2008 installation wizard by adding additional support for drivers and scenarios.

Note:
These updates are not related to the updates your accustomed to receive through Windows or Microsoft Update. These updates relate to the Windows Server 2008 Installation process only. Microsoft may choose to enhance the installation experience between Service Pack releases.

Depending on your media type you will see the Type your product key for activation window. If you do, simply type your Windows product key and tick the Automatically activate Windows when I’m online option.

In the Which type of installation do you want window select Upgrade .

The Compatibility report window will be displayed telling you what hardware might not function once upgrade is completed , also to check with software vendors to check if their software are compatible with Windows Server 2008. click Next .

The Installation wizard will now perform an in-place upgrade of your Windows Server 2003 Domain Controller. After multiple restarts, the Upgrade process will be completed and you will be able to start using your Windows Server 2008. Your upgrade might take hours to complete.

Upgrade additional Domain Controllers

Upgrading additional Domain Controllers in place is as easy as repeating the steps for in-place upgrading the first Domain Controller.

If you want to deploy Read Only Domain Controllers (RODCs) in the same domain as your upgraded Domain Controller, make sure:

• You have deployed at least one Windows Server 2008 in each domain you want to deploy Read Only Domain Controllers, before you deploy the first Read Only Domain Controller.
• Both the Forest functional level and Domain functional level are Windows Server 2003 at minimum, before you deploy the first Read Only Domain Controller.
• You have run adprep.exe /rodcprep on the Domain Controller holding the Domain Naming Master Flexible Single Master Operations (FSMO) role for the forest you want to deploy Read Only Domain Controllers in, before you deploy the first Read Only Domain Controller.

Raise the domain functional level

After you’ve successfully upgraded the last Windows Server 2003 Domain Controller for a specific domain (or you don’t feel the need to ever add pre-Windows Server 2008 Domain Controllers to your Active Directory environment) you’re ready to raise the Domain functional level of that domain.

Upgrading the domain functional level to Windows Server 2008 adds the following features to your environment:

• Distributed File System Replication (DFS-R) support for SYSVOL, which provides more robust and detailed replication of SYSVOL contents with minimal replication traffic compared to FRS.
• Advanced Encryption Services (AES 128 and 256) support for the Kerberos protocol.
• Last Interactive Logon Information, which displays the time of the last successful interactive logon for a user, from what workstation, and the number of failed logon attempts since the last logon.
• Fine-grained password policies, which make it possible for password and account lockout policies to be specified for users and global security groups in a domain, instead of per domain only.

Note:
Raising the functional level is a one way procedure. Once you’ve raised your domain functional level there’s no way to return to the previous domain functional level.

Raising the domain functional level in Windows Server 2008 looks remarkably similar to raising the domain functional level on Windows Server 2003 :

1. Log on to the Domain Controller holding the PDC emulator FSMO role with a user account that is a member of the Domain Administrators group..
2. Open Active Directory Domains and Trusts.
3. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level .
4. In Select an available domain functional level , click Windows Server 2008, and then click Raise .

Raise the forest functional level

After you’ve successfully raised the domain functional level of all the domains in your Active Directory forest you’re ready to upgrade the Forest functional level. This will not add any features, but will result in all domains that are subsequently added to the forest will operate at the Windows Server 2008 domain functional level by default.

Note:
Raising the functional level is a one way procedure. Once you’ve raised your forest functional level there’s no way to return to the previous forest or domain functional levels.

To upgrade the forest functional level to Windows Server 2008 perform the following actions:

1. Log on to the Domain Controller of the forest root domain holding the PDC Emulator FSMO role with a user account that is a member of the Enterprise Administrators group.
2. Open Active Directory Domains and Trusts .
3. In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level .
4. Under Select an available forest functional level , click Windows Server 2008, and then click Raise .

Concluding

In my mind in-place upgrading is more tricky than transitioning your Active Directory environment. If at all: it’s the same amount of work. With transitioning you need to perform the right steps at the right time. With In-place upgrading you need to check more prerequisites before you can actually slap in the disk.

With transitioning being inevitable (since hardware ages) and 64bit computing looming on the horizon I feel In-place upgrading is the right migration scenario only on rare occasions.

Please note however Microsoft supports in-place upgrading many Active Directory technology specialists do not recommend upgrading Domain Controllers.

Further reading

In-Place Upgrade from Windows Server 2003 Domain Controller to Windows Server 2008
Identifying Your Windows Server 2008 Functional Level Upgrade �
What Does the Upgrade Landscape Look Like for Windows Server 2008 �
Screencast: How to Upgrade In-Place 2003 DC
What You Need to Know About In-Place Upgrades �
Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain
Flexible single master operation
How to create or move a global catalog in Windows Server 2003
TechNet Forums – In-place upgrade of W2k3 to W2k8 �
TechNet Forums – Migrate AD users from 2003 to 2008 �
TechNet Forums – migration from windows 2003 to windows 2008 �
[Podcast] Windows Server 2008: To Upgrade or Not to Upgrade

Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.

Each Active Directory domain controller has a unique identifier that is specific to the individual domain controller. These identifiers, which are called Distinguished Name Tags (DNTs), are not replicated or otherwise visible to other domain controllers. The range of values for DNTs is from 0 through 2,147,483,393 (2³¹ minus 255). As objects are created on a domain controller, a unique value is used. A DNT is not reused when an object is deleted. Therefore, domain controllers are limited to creating approximately 2 billion objects (including objects that are created through replication). This limit applies to the aggregate of all objects from all partitions (domain NC, configuration, schema, and any application directory partitions) that are hosted on the domain controller.

Because new domain controllers start with low initial DNT values (typically, anywhere from 100 up to 2,000), it may be possible to work around the domain controller lifetime creation limit—assuming, of course, that the domain is currently maintaining less than 2 billion objects. For example, if the lifetime creation limit is reached because approximately 2 billion objects are created, but 500 million objects are removed from the domain (for example, deleted and then permanently removed from the database through the garbage collection process), installing a new domain controller and allowing it to replicate the remaining objects from the existing domain controllers is a potential workaround. However, it is important that the new domain controller receives the objects through replication and that such domain controllers not be promoted with the Install from Media (IFM) option. Domain controllers that are installed with IFM inherit the DNT values from the domain controller that was used to create the IFM backup.

At the database level, the error that occurs when the DNT limit is reached is “Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.”

Maximum Number of Security Identifiers

There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain. This limit is due to the size of the global relative identifier (RID) pool of 30 bits that makes each SID (that is assigned to user, group, and computer accounts) in a domain unique. The actual limit is 2³⁰ or 1,073,741,824 RIDs. Because RIDs are not reused—even if security principals are deleted—the maximum limit applies, even if there are less than 1 billion security principals in the domain.

When all the available RIDs are assigned for a domain, the Directory Service log in the Application and Service Logs of Event Viewer also displays Event ID 16644 from an event log source of the Security Accounts Manager (SAM) that reads “The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain.”

A partial work-around to this limitation is to create an additional domain to hold accounts and then migrate accounts to the new domain. However, you must create a trust relationship to migrate accounts in advance of reaching the limit. Creating a trust requires the creation of a security principal, which is also known as a trust user account. For more information about this limit, see articles 316201 (http://go.microsoft.com/fwlink/?LinkID=115211 ) and 305475 (http://go.microsoft.com/fwlink/?LinkId=115212 ) in the Microsoft Knowledge Base.

Group Memberships for Security Principals

Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups. This limitation is due to the size limit for the access token that is created for each security principal. For more information, see article 328889 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115213 ).

FQDN Length Limitations

Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.). As an example, the following host name has 65 characters and therefore is not valid in an Active Directory domain: server10.branch-15.southaz.westernregion.northamerica.contoso.com. This is an important limitation to keep in mind when you name domains. For more information about naming limitations, see article 909264 in the Microsoft Knowledge Base (http://support.microsoft.com/kb/909264 ).

File Name Length Limitations

The file system that Windows operating systems uses limits file name lengths (including the path to the file name) to 260 characters. That limitation applies also to physical files that Active Directory components use, such as SYSVOL and database file paths. When you are determining where to place your SYSVOL and database files during Active Directory installation, avoid nested folder structures that might make the full file path to the SYSVOL folder longer than 260 characters. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115219 ).

Organizational Unit Name Length

The maximum length for the name of an organizational unit (OU) is 64 characters. This limitation prevents an OU name from surpassing the file system limit of 260 characters when Universal Naming Convention (UNC) paths are constructed for Group Policy. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115219 ).

Maximum Number of Group Policy Objects Applied

There is a limit of 999 Group Policy objects (GPOs) that you can apply to a user account or computer account. This does not mean that the total number of policy settings on the system is limited to 999. Rather, a single user or computer will not be able to process more than 999 GPOs. This limit exists for performance reasons.

Maximum Number of Accounts per LDAP Transaction

When you write scripts or applications that perform Lightweight Directory Access Protocol (LDAP) transactions, the recommended limit is to perform no more than 5,000 operations per LDAP transaction. An LDAP transaction is a group of directory operations (such as add, delete, and modify) that are treated as one unit. If your script or application performs more than 5,000 operations in a single LDAP transaction, you are at risk of running into resource limits and an operational timeout. If that happens, all the operations (changes, additions, and modifications) in the transaction are rolled back, which means that you lose all those changes.

For example, if you are using Active Directory Service Interfaces (ADSI) to write a script, the SetInfo method completes a transaction. For more information about ADSI Methods, see Active Directory Service Interfaces (http://go.microsoft.com/fwlink/?LinkID=4487 ).

As another example, when you use the System.DirectoryServices (S.DS) namespace in the Microsoft .Net Framework, the DirectoryEntry.CommitChanges method completes an LDAP transaction. For more information about the DirectoryEntry.CommitChanges method, see DirectoryEntry.CommitChanges () (http://go.microsoft.com/fwlink/?LinkId=115220 ).

Recommended Maximum Number of Domains in a Forest

For Windows 2000 Server, the recommended maximum number of domains in a forest is 800. For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200. This restriction is a limitation of multivalued, nonlinked attributes in Windows Server 2003.

Recommended Maximum Number of Domain Controllers in a Domain

Because the File Replication Service (FRS) is used to replicate SYSVOL in a Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to ensure reliable recovery of SYSVOL.

If any Active Directory domain in your network is expected to exceed 800 domain controllers and those domain controllers are hosting Active Directory–integrated Domain Name System (DNS) zones, review article 267855 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115222 ).

For more information about FRS limitations, see the FRS Technical Reference (http://go.microsoft.com/fwlink/?LinkId=115302 ).

[ad#post]