views:

91

answers:

1

My company has a large customer that has many regions/sites/offices. Each location can have its own set of servers with its own data. The users of the system are centrally administered thru a domain. The computers in this network are locked down with only http access to the internet. There is a company wide Sharepoint portal. All servers and computers are Windows based (mostly XP, Server 2003).

We have written a number of utilities for them. Some are loaded from the network, but an increasing number of these are installed directly to a users machine. Typically we have been configuring these tools thru ini's or xml's. However, this is becoming cumbersome to update if a server is updated or settings need to be tweaked.

While I'm not concerned with how the data is stored, I'd like to have a common way to find or locate this data. The method will have to contend with certain knowing what office/region the user is on and return an appropriate location. I'll have to cache this data locally on the machine in case the network fails (seems to happen every so often).

I've already thought of a couple of ideas, but have no idea how effective or practical these are:

  • Use Sharepoint.
  • Use ActiveDirectory/LDAP.
  • Use Bonjour/Zeroconf.

What tools and/or technologies can I use enterprise wide to configure locally installed applications?

+1  A: 

If your customer uses active directory already, then you can use a logon script to download the master configuration files they might need.

This would only occur when they login while connected to the domain so your connectivity requirement is met, and since it'd only be downloaded at that time all your client apps could load the data locally satisfying the locality requirement.

Then, when you deploy an updated configuration file, all users would need to do is login again while connected to the network.

This script would not be unlike the scripts often used to mount available network shares or configure local printers. In each case, you can determine where a user is located and thus what config file they should download.

That is of course presuming that these config values don't change very often. If it's likely that they will change so often as to make a logout/login inconvenient, you'll have to go with another approach.

Michael Haren
The customer is already using logon scripts, which is good, but they don't seem to like them. I'll probably push for this as it seems a far more simple idea than anything else.
Joel Lucsy