Multi-client application deployment problem.

I'm trying to figure out a solution to the following problem, but I'm encountering annoying problems with it.
Mostly, it's lack of knowledge because I know it's possible. Maybe someone can point me in the right direction on how to get this done.

I have an application built in .NET which will be deployed over 100+ machines at the client via an MSI package which will be deployed across the network. ( I have no idea how that is done, but our network guy tells me that is how they are going to do it. )
Each of these applications needs to connect to a central MS SQL 2000 Database server, and each of them has their own database on this server.
So far, so good. I've come up with a scheme to utilize the name of each individual PC to create a naming scheme for each of these databases. This way we'll be able to use a small setup application to create and prepare all those databases on the server, and also have a database name in the client application to connect to.
My problem is the database server name. I cannot make any assumptions on this, nor can I stuff it inside an app.config file, because this will be pre-packaged in the MSI.
So is there a way to do something that while the MSI is installing at all the workstations to also add something that will tell the client application what the database server name will be?
I don't have any experience with building install packages or MSI files, but I assume something like that should be possible.
I don't want to have them change 100+ app.config files, nor do we want to have to repackage the whole thing every time we deploy this application to change the app.config inside with the proper server name of the specific client's database server.
Ideally, it would be a question asked while starting the install process from the master server from where the package will be deployed onto the workstations. ( I'm assuming this is possible )
Can anyone help me how to build something like this?

One change I would make is to have each client talk to a web service rather than directly accessing the database.

If you need to guard against concurancy, you can do this much easier from a single point (i.e the web service) rather than from each client.

As far as contacting the web service, you will need to have the location of the web service available for the msi package (or update the config file remotely post install). Just pass in the user name, computer name and any other info to the webservice and the webservice will decide how to form the database connection.

Building a webservice to talk to the database isn't an option, this would require rewriting the whole data access layer, aswell as the business layer which is interwoven with it. Might aswell build the whole application from scratch if we do that. ( yes, it was an id-ten-t that built it. The code is horrible and almost unreadable, the dataobjects are cumbersome and almost impossible to use easily, but we're stuck with it until we create a new version of this application from scratch and do it properly )

Quote:

---

Originally Posted by KrisSimonis

So far, so good. I've come up with a scheme to utilize the name of each individual PC to create a naming scheme for each of these databases. This way we'll be able to use a small setup application to create and prepare all those databases on the server, and also have a database name in the client application to connect to.

---

If you have a naming scheme which uses the client machine name as the database, why don't you get the machine name and generate the connectionstring accordingly on the client?

.net has a 'click once' install feature which checks the server to ensure it has the latest version each time the app starts up. If not, it downloads the new version and overwrites itself before restarting. Pretty cool feature.