Bulking Up an ADAM Test Instance
Published Sep 06 2018 06:26 PM 580 Views
First published on CloudBlogs on Aug, 14 2009

This week I’ve had the need to do some testing around ADAM (also known by it’s shiny new name of Active Directory Lightweight Directory Services or AD LDS).  The tests themselves are not directly relevant to this blog post, but in order for the tests to have some validity the ADAM instance needed to be a larger than the default install.

In the absence of a nice bulky backup or other directory instance to take previously created objects from I needed a quick method to bulk that bad boy up.  This can be useful in creating objects and monitoring as they replicate among your instance replicas, testing for scaling of your ADAM back end solution given your hardware and network topology.

When I looked around for some pre existing script which could do what I needed I found plenty of scripts….but none that could do the trick in a small number of iterations.

The best script repositories for ADAM that I could find are the original “Madam, I’m ADAM” article and The Script Center .  But none of these were made with the intention of creating a high volume of arbitrarily named objects.  So a little bit of thought was required (unfortunately).

There are different ways to provide named object creation in that way, but the only ones I could think of offhand used a “for” loop.  Rather than providing an “answer” file of names to pipe into the script I tried to keep it simple and put the for loop within the script and instantiated a variable i to do the job.

Here’s the script, which is set to create 100,000 user class objects.

'**************************************************
' This script adds i = n users to a specified OU or CN.
'  Alter as needed.
'**************************************************

' If the application NC  DN is "ou=adamou,c=us" and the server is "adamhost" and the port is 389. Then the parameter 'OUName   should be passed
' as follows:  "LDAP://adamhost:389/ou=adamou,c=us"

Set ou = GetObject("LDAP://localhost:389/OU=Users,DC=treyresearch,DC=com")

For i = 1 To 100000

set usr = ou.Create("user", "cn=" & "Test" & i)

usr.Put "displayName", "Test" & i
usr.Put "userPrincipalName", "Test" & i & "@treyresearch.com"

usr.SetInfo

Next

wscript.echo "100000 users created successfully"

Just call the script from command line using cscript.exe.

After the script runs you should have a container or organizational unit with stuff in it…

and consequently a larger ADAM database file (in the case below about a million user objects added)…

A few ‘scripting for ADAM’ caveats came up whilst doing this.  Some are documented in various places, others may not be so I”m putting them here for all to see.

  • Each object creation (each iteration of the for loop in the script) is an LDAP Create against the directory.  It is possible to run this script from a remote host against your ADAM instance if your alter your LDAP URL accordingly.  You could also run multiple, simultaneous renditions of this script against your ADAM instance.  Just watch out that you don’t bog your ADAM server down.
  • You cannot bind successfully to the RootDSE in an ADAM directory instance to do things so don’t try it in your scripts.  Instead pass in the complete DN path with your LDAP URL.
  • If you intend to use this script multiple times, even against different destination organizational units, keep in mind that there is uniqueness required in these objects.  Since the objects are created named Test n you will need make sure that if you run the script more than once your i value covers a new range of numbers.  For example, if you start with 1 To 100000 then the next time you run the script choose 100001 to 200000.
  • There is some value to not choosing the biggest number range you can think of and placing that into the script.  The reason for this is in part dependant on hardware and whatever methods you will choose to use to review that information (provided that is your intention).  Consider that ADAM-ADSIEdit will only display a certain number of records in a container before simply displaying an error to give context to this idea.  You can always get around this by using LDP.EXE and altering your query size limit, but it’s just something to keep in mind.  Additionally, on a not-so-beefy x32 Windows Server 2003 computer, having the script create 700,000 objects in a single OU took greater than an hour-though the time it takes depends on hardware and preexisting load on the server.
  • Make sure and create your instance with a distinguished name (DN) path that initially contains DC or CN rather than something else.  The reason for this is not so well documented in the help file but will basically prevent you from creating OUs or other child objects successfully.
  • This is something that is a good thing for testing.  If you ran a script or scripts like this against a live, production ADAM instance you might provide yourself with an inadvertent denial of service attack.  That’s the IT equivalent to shooting yourself in the foot.
  • Finally, you could alter the script to create other type of objects.  It all depends on what you need, and what attributes are mandatory for that class object when it is created.  Just alter the user parameter

set usr = ou.Create("user", "cn=" & "Test" & i)

to the class object you need, alter the usr.Put verb to match, and make sure you pass in the info that different class needs.

Hopefully this will help out people who are in a “proof of concept” or other testing phase and need to bulk that directory up in a hurry.

Version history
Last update:
‎Sep 06 2018 06:26 PM
Updated by: