Install AD\AM Using an Unattended Method
While installing AD\AM is easy via the UI, you don't have to do it all the time. You can actually install AD\AM using an unattended file, similar to installing SQL Server or Windows.
The following code configures your AD\AM instance in exactly the same way as you did with the manual install:
; Specifies to install a unique ADAM instance.
; If Show then ADAM setup displays progress information during installation.
; Specifies the name to be assigned to the new instance.
; Specifies the communications port to use for LDAP.
; Specifies the SSL communications port to use for LDAP.
; Specifies the application partition to create.
; Specifies the directory to use for ADAM data files.
DataFilesPath=C:\Program Files\Microsoft ADAM\DevX\data
; Specifies the directory to use for ADAM log files.
LogFilesPath=C:\Program Files\Microsoft ADAM\DevX\data
; Specifies the Service Account that AD\AM runs under.
; Attempts to add the specific privileges that the AD\AM service account needs to run.
; Specifies the password for the service that AD\AM runs under.
; Specifies the Administrators within the AD\AM instance.
; Specifies whether to show AD\AM in the Add Remove programs in Control Panel.
; The following line specifies the .ldf files to import into the ADAM schema.
Save this code as a .txt file, such as DevXADAM.txt, in the %SYSTEMDRIVE%\ADAMInstall directory (I use this path in an upcoming code sample).
Now, you just launch your installation, which you can do from either a batch file (if you want a repeatable installation method) or as a once off from the command line with the following code:
://Change to the directory where our installation and unattend files are
://Launch our AD\AM installation
adamsetup /c:"adaminstall.exe /answer:%SYSTEMDRIVE%\ADAMInstall\DevXADAM.txt"
The command line parameters for ADAMSetup.exe are:
- /Q Quite Mode (no UI)
- /C Extract files only; must use /T with this command
- /T: Temporary working directory to extract the files to
- /C: Command to execute specified by user (This is how you launch your installation.)
For the ADAMInstall.exe (embedded within the command shown) the parameters are:
- /answer: The filename (and path) to the unattend file
- /adv Used to set up ADAM replicas between instances
- /strict Causes all warnings to be treated as errors (This will cause your installation to fail if a warning is returned.)
The sample install code shows the progress of the installation (with the ShowOrHideProgressGUI option) to highlight when the installation process launches and completes. However, if you have any problems with your installation (for example, the progress of the installation never shows), the AD\AM installer will write to one or more of the following six registry keys:
The keys generated will probably be only a subset of the keys presented here. For example, when I first ran the script, I found that my password was incorrect, so the only keys I had in the registry were ADAMInstallErrorCode and ADAMInstallErrorMessage.
So it's up to you how you install AD\AM, but my recommendation is to use the GUI first, so you know how the installer works. Then when you are comfortable use the unattended method, as it is very slick!
Connect to Your Instance
It's all well and good having an LDAP database, but what good is it if you can't manage it? Well, for exactly that purpose, AD\AM ships with some tools for connecting to the AD\AM instance. The tools allow for basic tasks such as creating users, groups, organizational units, etc.
You can access these tools in a number of ways, but by far the most common is through the start menu, as shown in Figure 18.
|Figure 18. Access Tools Through The Start Menu|
Additionally, you can go to the path, "%SYSTEMDRIVE%\Windows\ADAM", which has all the tools, most of which are command line-based tools. Notice that the tools installed into a different directory than your data files. This is so that the tools are not replicated each time you install a new instance of AD\AM on your machine (i.e., each instance of AD\AM shares the same tools).
I use ADSIEdit, but not the version that ships with Windows. The ADAM-ADSIEdit.msc is specifically designed for AD\AM, and the use of the standard ADSIEdit.msc is not supported for maintaining an AD\AM instance.
When you launch ADAM-ADSIEdit.msc, you are presented with a blank MMC console. Right click on "ADAM ADSI Edit" and select "Connect to...", which will present a dialog window similar to Figure 19.
Fill out the fields with the following information:
- Connection Name DevX (or another name with which you wish to recognize your DevX AD\AM instance)
- Server Name localhost (or the name of the machine on which you installed AD\AM)
- Port 389 (or whichever port you set the install to in Figure 7)
- Connect to the following node Select "Distinguished Name (DN)" and enter the full name of the DevX AD\AM instance (i.e., CN=Corp, DC=DevX, DC=COM)
Connect using these credentials The account of the currently logged on user; alternatively, specify another account that has administrative privileges within the AD\AM instance
When done, click Ok. You will see a screen similar to that shown in Figure 20.
The AD\AM instance that you have installed has a very basic structure, without any Organizational Units, Groups, or Users. This is very similar to when you have created a new database within SQL Server; you have to fill in the blanks.
Have a look around, but perhaps the most interesting component of your AD\AM instance is the Roles container (CN=Roles). If you expand this container you will see three roles defined:
- CN=Administrators. This role has full administrative privileges within your AD\AM instance. The role members can create users, containers, groups, modify the password policy, etc.
- CN=Readers. This role has read-only access to the objects within your AD\AM instance. Role members can read certain attributes of users, groups, and containers.
- CN=Users. This role has limited write access to the objects within your AD\AM instance. Role members can update their own attributes, read certain attributes from other objects, and change their passwords.
If you take a look (double-click) at the CN=Administrators role, you should see a screen similar to that shown in Figure 21.
Scroll to the "member" attribute and click the "edit" button. You should see a screen similar to that shown in Figure 22.
|Figure 22. Click the "Edit" Button on the "Member" Attribute|
This is actually a pointer to the Administrators role within the Configuration Partition for your AD\AM instance. To see the members of that role, you need to establish a connection to the Configuration Partition (done via the ADAM-ADSIEdit.msc tool). It will contain the Security Identifier (SID) of the Administrators group that you added in Figure 12.
In case you are wondering how you resolve external users (known as foreign security principals within AD\AM) to the security identifiers (SIDs) shown in AD\AM, the following snippet of code will help:
'Change the strComputer name for your machine
strComputer = "WGTN-ROBHAWTH-P"
'Change the strUser for the user SID you wish to retrieve
'Establish a connection to the WMI object
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
'Retrieve the values from the WMI service
Set objAccount = objWMIService.Get _
("Win32_UserAccount.Name='" & strUser & "',Domain='" & strComputer & "'")
This code returns the SID of the user, which is a specific value for each machine.
Save this code as a .vbs file, such as GetUserSID.vbs, in the %SYSTEMDRIVE%\ADAMInstall directory. Then simply launch the script from the command prompt, and you should see the user SID returned.
Author Note: A big thank you to the Scripting Guy for his help in solving this little problem.