Store Connection/App settings in A/D

[milop]

Hello.

I originally posted this to the A/D group, but thought this might be a good
place too.

What are the pros/cons of storing connection strings and global app settings
in A/D.

We have a lot of applications (Windows, ASP.Net, Add-ins for Office Apps,
etc) and each need to retrieve connections strings, global app settings,
etc.

I want a central location for this stuff and don't want to include it with
every app, nor do I want to add it to each Machine.config file.

I was thinking of using A/D for this. On app start up I would get the info
and cache it.

Any and all suggestions/comments are welcome.

Thanks in advance,

Mike

 

[Jani Järvinen [MVP]]

Hello Mike,

What are the pros/cons of storing connection strings and global app
settings
in A/D. We have a lot of applications (Windows, ASP.Net, Add-ins for
Office Apps,
etc) and each need to retrieve connections strings, global app settings,
etc.

To me, the Active Directory as a storage location for application settings
sounds too complex for generic use. Yes, you can use it as a central store
for the settings you mention, but accessing and updating (and maintaining)
the settings requires too much coding in my opinion.

So the question is: is there a specific requirement for you to use AD? If
not, then have you thought of using a simple SQL database for this task?
Some (if not all) your applications are likely to use an SQL database (SQL
Server, Oracle, etc.). The server is also probably in a central location on
your network, and thus you could access is easily.

Additionally, there are many easy programming methods to access SQL database
data. It might prove to be a better central storage for your settings than
the Active Directory.

Hope this helps!

--
Regards,

Jani Järvinen
C# MVP
Vantaa, Finland
E-mail: (e-mail address removed)
Business: http://www.nimacon.net/
Personal: http://www.saunalahti.fi/janij/

 

[milop]

Hi, Jani. Thanks for the response.

The specific requirement is that there is a central store for common
configuration settings.

A/D seems like a logical place. Using directory services makes querying
simple.

As for the adminsitration of it, we would use a management console, so the
coding for that end of it doesn't exist.

The solution, which was supplied by Richard Mueller in the A/D newsgroup, is
going to be a combination of A/D and SQL Server and A/D Connection points.

Here's what Richard wrote:

If you store the information locally, perhaps in the registry, then if
anything changes you must update all clients. If instead the information is
saved in AD you just update the one location. AD has connectionPoint objects
that are saved in computer objects. SQL Server, for example, has stored
procedures for publishing server instances and database as connection point
objects in AD. The application can easily query AD for the connectionPoint
object and retrieve connection string information from the object. If the
server where the database is installed changes, for example, only the
connection point object must be modified, not the registry on every client.
Even if the location of the connection point object in AD changes, the
client finds it by searching by application name.


Thanks again Jani,

Mike

 

[Jani Järvinen [MVP]]

Hello Mike!

The solution, which was supplied by Richard Mueller in the A/D newsgroup,
is going to be a combination of A/D and SQL Server and A/D Connection
points.

Okay, sounds good to me! Maybe it's a personal preference, but I find using
SQL database a snap, so that's the reason I was questioning your need to use
Active Directory.

In any case, the main thing is that you got a solution you can use. Let us
know here in the groups if you need further assistance.

Thanks!

--
Regards,

Jani Järvinen
C# MVP
Vantaa, Finland
E-mail: (e-mail address removed)
Business: http://www.nimacon.net/
Personal: http://www.saunalahti.fi/janij/