There are three principally different approaches:
- Have the applications pull the configuration every time.
- Have a tool to push the configuration to the applications when it changes.
- Make sure the configuration does not change.
In increasing order of preference. So
3. Make sure configuration does not change.
This is the preferred option. Create suitable aliases for everything that don't need to change.
Domain name for mail server should never change. The host can, but you just redirect the
mail.inranet1 to the new host. The same applies for all other network locations. Just create suitable DNS names for them. The same goes for
self-service.company.com etc. Each web service and web application should have it's own vhost too, so you can move each independently without having to change the dependent applications.
The only case where the host names would change is when when you for example split the database server to two separate databases, but then you have to configure different applications differently, so the central configuration isn't going to help you anyway.
Similarly, each application should have separate account to the database, named as the application and limited to only the operations the application needs. This is for security reasons to minimize the damage if some of the applications is compromised. As a side-effect, it gives each application it's own username and password that don't need to change often, so no more reason for central configuration. Quite contrary; you want to limit the number of places that have each password so when somebody cracks one, the other applications and their accounts are not compromised.
In a sense, it is a shared configuration, but stored in the DNS server. And don't forget DNS can store various other information. There is the SRV record for recording ports where services run, records for storing various kind of encryption keys etc.
2. Have a tool to push the configuration to the applications
There is various configuration management software. These are tools that take care of installing software and deploying configuration across networks. Any non-trivial network should use one to ensure installing security updates.
If you have one, just add appropriate rules to deploy the properties file to all servers that run some application. If you don't, pick one2 and do the same, plus configure it to take care of the security updates.
Note, that these tools can also take care of restarting the application servers when they deploy new configuration or otherwise notify the applications that they need to reload the configuration.
So this is a good option, because such tool is very useful for administering the network in general.
3. Have the applications to pull the configuration.
This requires changing each application in advance. And it won't solve the issue completely anyway, because it suffers the chicken-and-egg problem. You still have to configure the location from which you should pull the rest of the configuration.
File sharing is obviously easiest regarding size of changes to each application. Just remember you'll have to restart the applications too or implement some mechanism for notifying them when configuration is changed, which also reduces the usefulness of the solution.
So I would definitely not recommend this approach of which all your original options are variations.
1You can use arbitrary non-existent top level domain in internal network and it has the advantage that you won't have to change it even if the company is renamed. Just don't use
.local, which is reserved for mDNS.
2Or ask your system administrator to pick one; they are the one who will interact the most with it.