These days I work together with many top-notch developers, dealing with very different projects, solutions and applications (not only with SCOM management packs :)). And what I like most of all about being in this very diverse community is the variety of questions whose folks bring onto the table. Here is the most recent one:

Can we store configuration information for our application in AD? If yes, then how?

I was dealing a lot with the Exchange Server during last months, so for me the answer for the first question was obvious – yes, you can store the configuration information in the Active Directory. Finding the answer for the second question was tricky – I hadn’t enough knowledge about implementing this kind of stuff. So I made a dive into the theory and ended with a bunch of links and some samples written in PowerShell. Here it goes.

Disclaimer

All samples provided here are provided As Is. You may use them at your own risk.

Note, that any changes you apply to AD Schema are not reversible – consider testing any changes in the lab first.

All samples are written in PowerShell, so both IT Pros and developers can use them. (I do believe that professional developers can read the code in any language and are able to easily convert PowerShell samples into C#.)

Some theory

Many modern applications have multi-tier architecture. To be able to act as a whole, some application components might need to share configuration information with other ones. Exchange Server is a good example of such application – the typical deployment includes a number of servers, holding different roles (client access server, mailbox server, edge transport), distributed across entire organization.

The Active Directory suites that need in a very good way – everyone within organization can access the information when required and permitted, also AD infrastructure is usually highly available.

There are zillion ways to store the required information and it is up to software developers to decide how exactly they want to implement that. Here are some common points of consideration:

What information should be stored?

Who should be able to access the information?

Is that information sensitive?

Where do we need that information (anywhere in the forest, anywhere in the domain, selected Domain Controllers)?

Can we (do we want to) extend the schema?

It is impossible to discuss and illustrate all possible options in a one blog post, so let’s concentrate on just one example.

Here are the functional requirements:

Application has 3 deployments: Development, QA and Production;

Each deployment has a connection point, which is served by one application server at a time;

Clients for development, QA and production deployments cannot be placed into the same Organizational Unit (so we have at least 3 OUs – one per deployment);

In future we may want to introduce more deployments;

In future we may want to have more granular OUs.

The configuration should serve the entire forest.

And here is how we can translate that into implementation design:

We need to store configuration information for our application in the “Configuration” Directory Partition (so it will be replicated across the forest);

We want to store configuration details for each deployment separately;

We do not want to have multiple copies of configuration information (i.e. we need one and only one object per deployment);

We want to assign the deployment to the OU.

Extending Active Directory Schema

Extending Active Directory Schema is required only if there is no existing class and/or attribute which can fulfill your particular requirements. When making a decision, you should keep in mind that schema extension impacts entire domain forest in a number of ways.

In our case we want to be able to assign the deployment directly to the Organizational Unit, so we need either an object within the OU or some extra attribute. Object can be moved, attribute can’t. Thus we decide to extend the schema. (As I have already mentioned, there are many ways to implement the same thing, it is up to developer to decide).

Now, when we have our configuration details in place, we can set the property of Organizational Units to point to our configuration objects. Of course, any inconsistencies like missing configuration or unavailable service should be properly handled by the application itself.