Well, both reasonable ideas, although both rely on configuration settings that are per machine. I don't see how I could handle mobile users that travel from site to site, particularly when two sites that are physically close are in different telecom regions, thus in different regional networks. That's the real problem that I see, since AD is often split on admini-political boundaries that have little to do with the WAN connections.

Here's what I'm doing (so far) and it seems to be working out OK..

I define custom SRV records in DNS. A SRV record provides service information - a FQDN host name, service name, port number, and arbitrary weight and priority values. Take a look at your AD-DNS and you'll find SRV records representing your DCs, the PDCe, GC, LDAP, and several other network resources.

I create a custom SRV record called "_swdist" under the "_tcp" group when the application server service is installed. The installation script asks the user for the size of the network that this host serves, so a branch office (1024 addresses) would get a "22" representing 22 bits of netmask.
This value is placed in the Weight field of the SRV record, and the priority is set to 2 for a branch, 1 for a region, and 0 for the master. The one assumption is that the network is heirarichal within regions (that is, branches within a region are all subnets of the regional network.)

I use a UDF that takes 3 parameters - IP address, "Short" flag, and Type. If you specify the type, the IP and flag are ignored, and all SRV records matching the defined type are returned. This allows you to locate all DCs, GC servers, and the like. If the Short flag is true and type is null, the standard processing is short-circuited and all _SWDIST tpye records are returned without sorting or prioritizaiton. If only the IP is specified, a list of all _SWDIST records is collected. The network of each server is determined based on the Weight/Netmask value. The IP address is compared to this range and - if it matches - the record is added to a "consideration" list. After the complete list of records are processed, the Consideration list is sorted based on the number of subnet bits - a greater number being more specific (thus closest). Note that the netmask value in the SRV record is not necessarily that of the actual server's subnet - it instead represents the "supernet" of networks served.

The application processes the list, trying the closest server first. If the resource is unavailable, the next (regional) server is queried if a regional (Priority 1) server exists. Since network architecture could preclude defining regional servers by subnet, regional servers could exist without a SRV record. Before checking the master server directly for the resource, a lookup table on the master server is queried to determine if a regional server exists without a SRV record (exception process). If so that server is queried. If it doesn't exist, or does not contain the needed resource, the resource is obtained directly from the HQ Master server.

It might sound complicated, but it's actually quite simple in practice. Creation of the SRV record is automatic during the installation with just 3 questions to the installer -
1. Regional or Slave server?
2. Create SRV record?
3. Size of network served (bits) or list of CIDR networks served?

Question 3 changes based on how Q2 is answered. If a SRV record is created, you can specify a single netmask bits value. If no SRV record is created, you can specify a list of CIDR networks that this system will serve, and the central "exceptions" table is updated. Of course, if a Slave server is created, the SRV record is always created and Q2 is skipped.

With this method, I can walk into a branch with my laptop, run the application, and it will automatically connect to the local, regional, or HQ server where the resource exists. No custom configuration or settings on the client system. I can even have the app installed on a flash drive and run it without local installation - there's no software or configuration prerequisites.

I'll post my UDF and some example code in a few days. Of course, you'd need to create a few SRV records to really test the functionality, but custom SRV records can be created and deleted without any impact to the environment. For testing, I created a master on one subnet, and the regional and slave on my PC subnet (pointing to other valid PCs that had no resources). The resources can have arbitrary netmasks, unrelated to their local subnet size, so it's easy to test the heirarchy.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D