Users are objects in Windows.
There is no limit specific to number of users but there is a limit for the total number of objects.
And objects are almost everything in Windows; users, user groups, computers, printers, domains, organizational units, group policies, etc.
Microsoft assigns 30 bit for the number of objects. It means 2 to the power 30 objects, approximately 1 billion objects can be created.
And if this number is not enough, you can add an additional bit to raise the number to 2 billion. It is more than enough.
But, can we actually create this many objects?
Or, do we have some practical limitations restricting the number to a much less quantity?
We have an example: NTFS file system.
Microsoft says that an NTFS volume may be up to 12 ExaBytes but in reality you bump into many limits like partitioning of the hard disk; MBR vs GPT.
To see the limits, I decided to create as many users as possible.
I installed a fresh new Windows 2016 and promoted it to a DC.
A fresh DC has only a few users.
Then I started creating users using the simple PowerShell script:
[long]$number=1
while($true){
$name=$number.tostring()
new-aduser -name $name
$number=$number+1
}
As you can see, it is and endless loop.
I interrupted it many times for doing some trials and maintenance.
If you happen to try this script, you can also break it when you want.
To start again, just change the first assignment statement, and start from where you left.
To see where you left, you can use Security log. Event ID 4720 shows the creation of the new users and top 4720 event will display the last user created by the script.
By the way, System log displays many 16647 and 16648 events that show new account-identifier pool requests and pool assignments.
When you create a new user, Windows must create an SID (Security ID).
Security ID consists of a constant domain ID part and RID (Relative ID).
Relative IDs are created by the RID Operations Master and assigned to DCs in groups of 500 RIDs.
At first, I used a laptop computer with i5 cpu and SATA hard disk. Script created close to 50 thousand users an hour.
To speed it up, I changed the Power configuration in Control Panel, from Balanced to High Performance.
This change resulted in an approximately 100% performance increase and number increased to 100 thousand an hour.
Then I decided to use paralellel execution in workflows to see if it will affect the procedure.
I wrote the following script:
workflow Create
{
$numbers = 4997970..5200000
foreach -parallel ($number in $numbers)
{
$name=$number.tostring()
new-aduser -name $name
}
}
Create
The result is nothing but disappointing: The parallel script created 8 thousand users an hour!
The creation of users may be something that cannot be parallelized.
After that, I switched to a laptop with i7 processor and SSD disk and continued to the original script.
Switching to new computer raised the number to 150 thousand users an hour.
One thing I noticed that creation process adds 2.2 KB of info into Active Directory (AD) database.
It is strange because I create an object with only a name, nothing else and we know that AD keeps info about objects as attribute based.
So, the AD database shouldn’t be so big but it does not listen to me and it gets bigger and bigger.
I decided to defrag AD database to see if it is a result of defragmentation of the database.
After Windows Server 2008, domain service (Active Directory Domain Service) can be stopped and you can do some maintenance tasks on the AD database.
After stopping the service, I switched to the classical command prompt and changed to \Windows\NTDS folder, where, by default, the AD database, ntds.dit resides.
I issued the following command:
esentutl /d ntds.dit
The database was 45.1 GB before the defrag procedure.
Defrag procedure decreased it to mere 43.8 GB. Not a brilliant result!
It means that AD database has not been fragmented at all.
Microsoft’d better consider this point.
The gigantic database restricts many things. For example, you cannot get the number of the AD users using the following command:
(get-aduser –filter *).count
After half an hour, the above command fires an error message: The server has returned the following error: invalid enumeration context.
Get-aduser command talks to “Active Directory Web Services”, and this service has a timeout value, “MaxEnumContextExpiration” and it is 30 minutes by default.
If your query takes more than 30 minutes, command returns the error.
Solution is said to be increasing this timeout value in this service’s configuration file, “Microsoft.ActiveDirectory.WebServices.exe.config”, under \Windows\ADWS folder.
But, after increaing this value to 300 minutes, I still got the same errors.
I tried to save the result of the command to a variable with this command:
$users=get-aduser –filter *
And it also failed.
The strange thing is that you can get the list and number of the users using classical command “net user” as in the following:
$count=invoke-command {net user }
I issued this command when the number of the users is approximately 11 million and the command completed in 50 minutes.
$count.length command displayed the number of the lines: 3860947.
We know that “net user” command displays three user names in a line so if you multiply 3860947 by 3, you get the number of the users.
After that, I issued the following command to export the users to a text file:
$count | out-file listusers.txt
A 567 MB file is created, containing the names of all users; 11 million users.
It’s a shame that 30 year-old command was executed successfully whereas the Powershell commands failed.
After running smoothly for 14 days, and creating 67 million users, my Windows crashed.
I got a BSOD stating that a critical process died.
I tried restarting the computer to Safe Mode options, especially Directory Services Restore Mode option so I can see if the Active Directory database caused this error but all options failed.
To see if a hard disk error caused the crash I used chkdsk command, “chkdsk /f”. Command completed without displaying any disk error.
sfc /scannow command failed and displayed “Windows Resource Protection could not perform the requested operation” message.
Also, “DISM /image:C:\ /cleanup-image /revertpendingactions” command failed with error 3.
So, I gave up fixing the Server 2016.
For the time being, the limit is 67 million users for me:)
Update (12/11/2018): At the beginning of October, I installed Windows Server 2012 R2 and tried the same thing on the i7-SSD laptop. This time I received no error and after 40 days, was able to create more than 100 million users after that I stopped the experiment because so little space left on my 256 GB SSD. I think the problem in the first experiment is not related to the OS (2016 server). Testing again on 2016 server would take another month so, it is left to the reader:)
By the way, you can buy this 256 GB SSD disk with 100 million users on it to do your tests. Its price is $500. Drop a mail to murat@muratyildirimoglu.com.
You can also read the following articles:
https://muratyildirimoglu.wordpress.com/2017/12/12/resetting-local-administrator-passwords/
https://muratyildirimoglu.wordpress.com/2014/03/05/how-to-determine-which-user-added-a-computer-to-the-domain/
https://muratyildirimoglu.wordpress.com/2013/03/15/my-experience-with-exchange-server-after-domain-rename/
https://muratyildirimoglu.wordpress.com/2017/12/22/a-new-powershell-command-structure-is-necessary/
https://muratyildirimoglu.wordpress.com/2013/03/15/excel-heals-defects-of-powershell/
