Active Directory Scalability limits

Have no more than 1200 DCs in your domain..say new scalability limits.

I wonder if anyone realistically has reached that limit without a need to break down the domain into multiple domains/forest, this limitation lies in FRS’s ability to keep things sane with the SYSVOL replication. The new Active Directory Maximum Limits – Scalability recently published has very interesting pieces of information. I am highlighting below some key bullet points.

  • Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.
  • There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain.
  • Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups.
  • Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.).
  • The maximum length for the name of an organizational unit (OU) is 64 characters.
  • There is a limit of 999 GPOs that you can apply to a user account or computer account.
  • The recommended maximum number of members in a group is 5,000. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.(Thanks to LVR).
  • 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.

Even though this technet-published-content puts Windows Server 2008 in context as identified in the applies to section, unfortunately details do not dive into direct scalability improvements for native Windows Server 2008 and R2 Forests. All in all even with a Windows Server 2003 forest, the limitation mentioned here are rarely to be hit in a production environment.


What’s the Schema version of Windows Server 2008 R2 ?

t is version 47 in RC and it may very well change when R2 gets RTM. You can check the objectVersion attribute of your current forest on the Schema Naming Context (NC) via ADSIedit.msc.


Here are some older Schema versions.


Here is more detail of schema changes in Windows Server 2008 R2 RC.

How do I perform an offline domain join in Windows Server 2008

As briefly discussed before, a feature to offline domain join machines is available in Windows Server 2008 R2. The utility is called “djoin.exe” which is used to perform this task. Here is an official blurb on what the offline domain join is what it would be used for and then I will show you how to perform this simple task.

“Offline domain join is a new process that computers that run Windows® 7 or Windows Server® 2008 R2 can use to join a domain without contacting a domain controller. This makes it possible to join computers to a domain in locations where there is no connectivity to a corporate network. For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time required for wide-scale virtual machine deployments.

A domain join establishes a trust relationship between a computer running a Windows operating system and an Active Directory® domain. This operation requires state changes to Active Directory Domain Services (AD DS) and state changes on the computer that is joining the domain. To complete a domain join in the past using previous Windows® operating systems, the computer that joined the domain had to be running and it had to have network connectivity to contact a domain controller”

I created the metadata as known as “blob” on one of my DC for a Server named 2008R2RC2 that I wanted to join to domain offline (i.e the target machine not connected to the network) and saved it to a txt file called computer_prov, then as usual I run the help on the utility to learn what syntax it has available. Here is the command syntax I ran to provision the computer account and to create the metadata.

djoin /provision /domain techevan.lab /machine 2008R2RC2 /savefile c:computer_prov.txt


I then jumped on the target machine, copy the txt file over and try to run needed syntax with the djoin utility

djoin /requestODJ /loadfile c:computer_prov.txt /windowspath %SystemRoot% /localos

I get an error that I am not running the Shell with elevated privileges, I get out and get back in with the “run as administrator” option, and get the same error.


Perhaps its a bug in RC release, I then tried the same syntax from the conventional CMD line window and was successful.


I then restarted the target computer and machine had been joined to the domain.

For more information please see,

PowerShell : How to lookup Schema version of your forest ?

The schema version is revealed via the objectversion attribute off of the schema object from your configuration head of the forest i.e “cn=schema,cn=configuration,dc=yourdomain,dc=int”.

So using Quest Cmdlets, you can run this query :

Get-QADObject "cn=schema,cn=configuration,dc=yourdomain,dc=int" -ip objectversion | select objectversion


The –ip is the alias for includedproperties.

And, when using the native AD Cmdlets of Server 2008 R2 (ADWS), the syntax is slightly different ;

Get-ADObject "cn=schema,cn=configuration,dc=r2,dc=lab" -properties objectversion


Above, you see the query ran with Quest Cmdlets resulting in objectversion 31 which is against a Server 2003 R2 Forest, whereas the latter is for a Server 2008 R2 Forest i.e Schema version 47.

PowerShell : How do I check Active Directory Tombstone Lifetime ?

What is Active Directory Tombstone Lifetime (TSL) ?

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

Directory Services veteran and MVP Joe Richards has published a short blog entry demystifying the confusion a technet article has caused in regards to how to go about figuring a TSL on a particular domain. Note that new forests that are installed with Windows Server 2003 with SP1 and up have a default tombstone lifetime of 180 days.

Joe shares his ADFIND tool to lookup the current value of the TSL attribute (irrespective of what OS was used to build the forest). Note that as Joe pointed out if this attribute is not set (i.e empty value) then the TSL is 60 days. Here I show you how to lookup the TSL with PowerShell.

Using Quest cmdlets :

Get-QADbject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=int” includeallproperties | Select TombstoneLifetime

And with using native AD cmdlets (of ADWS) in Windows Server 2008 R2 :

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -properties tombstonelifetime


Also within PowerShell, you can also use ADSI to lookup the TSL value.

[ADSI]$config=LDAP://cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,DC=R2,dc=lab


Also, here is how you can use DSQUERY from the Windows Support Tools to lookup the TSL.

dsquery * “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -scope base –attr


Note that I have used my test forest’s DN of R2.lab in above examples, be sure to replace the values with your forest’s DN. Above query should be typed in one line.

Memory Limits for Windows Releases

Active Directory 2008: Root Hint Facts

Root Hint Facts

Root hints are pointers to top level DNS servers on the Internet.

  • The Cache.dns file holds the 13 root hint   addresses for the Internet root servers. The Cache.dns file can be found in two locations:
    • %SystemRoot%\system32\dns\Cache.dns (the copy in use)
    • %SystemRoot%\system32\dns\backup\Cache.dns (the copy reserved in the backup location)
  • The Cache.dns file normally lists the NS (name server) and A (host name)   records for the Internet root servers. You can change this file to list the   records for your own internal root DNS servers if you are using DNS on a   private network.
  • You can configure root hints through the   properties of a DNS server or by configuring   the DNS server’s Cache.dns file. If the server is configured to load   data from Active Directory, you must configure   root hints using the DNS snap-in because   the local Cache.dns is not used (the root hints data is stored   in Active Directory).
  • The root zone is at the top of the DNS hierarchy,   and is named . (dot).
  • If you have a root zone configured on a DNS   server, the server will act as a root zone   server. A DNS server configured as a root   zone server will never use the root hints   file (Cache.dns). It considers itself authoritative.   Consequently, the server won’t access the   Internet to forward DNS queries.
  • If you want the DNS server to access the   Internet, delete the root zone in the DNS   console.
%d bloggers like this: