How to verify ADLS (ADAM) Configuration?

How to verify ADLS (ADAM) Configuration?

How to manage DRA ADAM Instance?
How to manage DRA ADLS Instance?
How to verify the ADAM containers?
How to verify the ADLS containers?

1. Logon to each DRA Server's Windows Console, Starting with the Primary DRA Server, as the DRA Service Account
• This account must be a member of the LDS Administrator Group as configured when DRA was initially installed. The value used during the installation will be stored in the Windows Registry , locally on each DRA Server:.
• The value is stored as AdminAccount under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mission Critical Software\OnePoint\Administration\Modules\ServerConfiguration\ADAMConfiguration
2. Launch the ADSI Editor
• This a Windows Server Feature included with the Remote Server Administration features for AD / LDS Command line tools.
• This is located in the Start -- All Programs -- Administrative Tools -- ADSI Edit location.
3. Within ADSI Edit ,setup the Connection with the following properties as follows:
• Name: Leave this at the default value.
• Connection Point type: Distinguished
• Server Name is DC=DRA,DC=COMComputer Name: LocalHost:50000
4. Expand the tree to view all the containers below the DC=DRA,DC=COM Partition to verify the container layout:
1. The default configuration of ADAM / ADLS prior to any modifications by DRA will contain three base containers:
• CN=LostAndFound
• CN=NTDS Quotas
• CN=Roles
2. The DRA Service will create additional containers, after the service initialization is complete
• CN=CredentialStorageRoot -- Use to store the Domain and Exchange access account details for all managed domains, on all DRA servers. Without this key (and subsequent sub-keys) the Accounts Cache will fail.
1. CN=CredentialAccessor
   
2. CN=CredentialVault
   
• CN=DraApplicationConfigurationRoot -- Used by DRA 9.2 and latter to store external application configuration settings
1. CN=ApplicationConfig -- Used to store the Workflow Automation Server connection configuration.
   
• CN=DraDomainConfigurationRoot, -- Used to store the link between each DRA Server and each managed domain
1. CN=DRACloudTenants -- Used to list each managed cloud tenant
   
2. CN=DRADomains -- Use to list each managed domain
   
3. CN=DRAServerCloudTenantLink -- Used to store to link each DRA server to a managed cloud tenant
   
4. CN=DraServerDomainLink -- Used by DRA to link each DRA server to each managed domain.
   
5. CN=DraServerExchangeLink -- Used by DRA to link each DRA server to each manged domain's Exchange Server(s)
6. CN=DraServerSkypeLink -- Used by DRA 9.1 and latter to link each DRA server to a Skype for business server
7. CN=DraPublicFolders -- Used by DRA 9.2 and latter to store the Exchange On Prem public folder connection details
   
• CN=DRADynamicGroup, -- Used to store dynamic group memberships which only exist within DRA
• CN=DRAQueriesRoot -- Used by DRA to store custom search queries 
• CN=DRAVARoot  -- Used by DRA to store Virtual AD Attributes which only exist within DRA. These are different than Custom AD attribute extensions.
1. CN=ReportingConfigurationRoot -- Used by DRA to store DRA Reporting Services and DRA Audit reporting configuration data
2. CN=ADCollectors  -- Used by DRA to store configuration data related to the DRA Reporting AD Collector jobs
3. CN=CollectorStatus  -- Used by DRA to store configuration data related to the DRA Reporting AD Collector job run time status.
4. CN=DRA_DatabaseInfo  -- Used by DRA to store configuration data related to the DRA Reporting database and SQL Sever
5. CN=DRACollectors  -- Used by DRA to store configuration data related to the DRA Reporting DRA Configuration Data Collector jobs
6. CN=DRAServers -- Used by DRA to store a list of all DRA Servers. This list is used by the DRA Reporting Collectors as well as the Audit history reporting within DRA
7. CN=TenantCollectors  -- Used by for Office 365 tenant collector job configuration
8. CN=TRACECollectors  -- Used by DRA to store configuration data related to the DRA Management Reports collector configuration.
   

DRA utilizes Microsoft Active Directory Lightweight Directory Services (ADLDS) as a secure storage location for various configuration settings. The LDS instance on the Primary DRA Server, serves as the Primary LDS instance; and then is able to replicate it;s data to all other LDS instances running on Secondary DRA Servers.Microsoft ADSEdit can be used to view data stored within LDS. The configuration data stored within LD is as following:

• Managed Domain Access Account configuration
• Managed Domain Exchange Access Account configuration
• Managed Cloud Tenant Access Account configuration
• DRA Reporting Services Configuration
• DRA Workflow Automation Server connection configuration
• Last Logon statistics
• Dynamic Group details **
• Virtual Attributes **
• Custom DRA LDAP search queries **

Note: Items with ** indicate the data stored here only exists inside DRA, and is not re-created if the Primary LDS instance is recreated. All other data is either able to be reconfigured using the DRA Delegation console or is collected again the next time a specific collector job runs.

DRA includes a DRA Health check utility. This utility will had multiple checks to verify the ADLDS configuration on the local DRA Server. The utility must be run in the context of DRA Service, or other member of the LDS Admins Role; in order to validate the LDS configuration.
Before starting a DRA full version upgrade, its recommended to install and run the DRA Stand Alone Health check first.
If a manual rebuild of ADLDS is done, the DRA health check utility will be needed to re-create the instance.
It is strongly recommended to NOT modify any content within ADLDS, nor re-create ADLDS; without specific instruction from Technical Support