Store Application Data in Active Directory

Question

We're going to be moving lots of computers round in the fairly near future, and I thought I'd get all prepared by migrating all my application connection strings into one central location, so that I can update them in one fell swoop when the time comes.

I thought: "I know, I'll store them in the Active Directory"

Unfortunately, my knowledge of Active Directory is so slim as to be almost negligible. I can read groups and detect which users are in those groups, and basic things like that, but I would not know how to go about structuring Active Directory to hold this information.

I thought it might be good to have a "ConnectionRespository" place, with lots of named "Connection" objects in it, but I have no ideas how to go about setting up such a thing. Ideally, I'd like an application (in C#) to manage it, adding and removing Connection objects as necessary.

Any ideas greatly appreciated.

Answer 1

The specific functionality you are looking for is an "Active Directory Application Partition". There's a great blog with a book's worth of information and code samples as well.

I would discuss this with your Systems Architecture/Operations group before proceeding. You are going to have to modify your AD schema, and I know that process can take a long time at many organizations.

Answer 2

serviceconnectionpoint objects are designed for this kind of thing. They are generic data objects that dont mean anything to Windows. No schema change needed

However its not clear to me that you need to put this stuff in AD. Connection string info logically belongs to the app servers; AD is for stuff that everybody needs

Answer 3

Extending Active Directory means you quickly hit lots problems, as even rebooting your AD server will need the approval of lots of people in most companies.

I would just put all your sheared config data in a XML file that you download from a web server.

Or put the config info in the registry of every machine on your network with an Active Directory Group policy.