How do web front ends find the configuration database (moving whole farm to new AD forest)

Question

We are exploring, as a possible course of action, moving our SharePoint 2007 medium farm to a different Active Directory forest (2008). There is a two way transitive trust between the source and target domains.
I have established that with such a trust it's possible to add content databases on a SQL instance in another forest, so moving content is not a big issue; we'd stand up new instances and move them: the user accounts are almost all in the target domain anyway.
However, we have a good deal of customization, including a third-party application that no longer has any support and has historically been appallingly difficult to upgrade/install fresh.
How do web front end servers find the SQL instance containing the configuration database? If the farm credentials had been previously changed to an account in the target domain, all services stopped and the configuration database moved to a new instance
with a DNS alias, would the database appear to be in the same location when SQL and SharePoint services were started on (logically) moved web front ends?

Answer 1

Here is more or less the high-level process for SharePoint 2007:
Mid- to high-level steps.
0. Full farm backup
1. Move users to new domain (in AD). Use stsadm -o migrateuser to migrate the old domain accounts to the new ones in SharePoint
2. Move service accounts to new domain, or create new service accounts
3. Update the farm to use the service accounts in the new domain
stsadm -o updatefarmcredentials (service accounts)
stsadm -o spsearch -farmserviceaccount
stsadm -o spsearch -farmcontentaccessaccount
stsadm -o editssp -ssplogin (for each ssp)
stsadm -o osearch -farmserviceaccount
SSO and any other remaining service accounts (CA -> Ops -> Service Accounts)
Default content access account (SSP -> Search Settings -> Default content access account)
Customizations (if there are service accounts associated with these)
3.5 Manual steps
Application pool accounts
Update permissions for SQL Logins to make sure the new accounts match the permissions for the old accounts
Add the appropriate new accounts to the DCOM IIS WAMREG Admin Service
4. Update the SQL Server service accounts. If SQL Server is shared with other applications you'll want to update the SQL Logins for these other applications as necessary and the SQL Server service accounts (DB Engine, DB Agent, Reporting Services, etc.). Might
not be necessary if this has already been done or if the SQL server is not changing domains. 
5. Shut down all services on all servers in the farm (this includes SQL if you are moving to the new domain).
6. Change domain membership of all farm servers, reboot or perhaps shutdown and bring back up in the following order:
1. SQL. Verify SQL Server is running and accessible. Check event logs. Resolve any issues.
2. Central Admin server. Verify CA is accessible, check event logs. Web apps and some services may not be available if they are on servers that are currently turned off. Don't worry about these (yet).
3. Application servers, search servers, index, query, other. It's likely some or all of the WFEs will go on at this step. Verify services are accessible as expected. Check event logs. Resolve issues.
4. Any remaining WFEs. Wash, rinse, repeat.
7. Assuming everything is running as expected, users can access the sites, the sky did not fall, etc. take a full farm backup.
Hey look, here are some low-level steps too.
# updates the account used to run the CA app pool and the timer service
# must be run on the server that hosts CA
stsadm -o updatefarmcredentials -identitytype configurableid -userlogin NEWDOMAIN\farm_service_account -password Password123
# spsearch
stsadm -o spsearch -farmserviceaccount NEWDOMAIN\search_service_account -farmservicepassword Password123 -farmcontentaccessaccount NEWDOMAIN\crawl_service_account -farmcontentaccesspassword Password123
# osearch
stsadm -o osearch -farmcontactemail [email protected] -farmserviceaccount NEWDOMAIN\search_service_account -farmservicepassword Password123
# ssp service accounts
stsadm -o editssp -title SSP -ssplogin NEWDOMAIN\ssp_service_account -ssppassword Password123
# Manual steps
SSP Admin -> Search Settings -> Default Content Access Account
Application pools: CA -> Operations -> Service Accounts -> Web Application Pool (or use gl-updateapppoolaccount if available)
iisreset /noforce
Copy SQL permissions to the new accounts. Not sure why this doesn't happen.
SSP Service Account
Farm Account
Setup Account (not copied because it doesn't own anything, just used to kick off the DB for the other accounts)
Search Service
Add accounts to DCOM not sure why this didn't happen
Component Services -> Computer -> My Computer -> DCOM Config -> IIS WAMREG Service
Farm account
Application pool accounts
Search Service
SSP Service
SSP Admin
Then the fun part. Move the server into the new domain.
Check for AAMs to see if they reference the current domain. If so, change to the new one.
Stop all SP services. Join new domain.
The computer name is a netbios name in SP, this should be painless.
Some general notes from my experience doing this:
1. There is no way to update application pool identities with stsadm (I haven't explored using Powershell). You have to go through CA -> Service Accounts to update these.
2. Some SQL logins and permissions were not created. I compared the permissions before to the permissions after and copied the ones that didn't transfer. This resolved all database access issues.
3. Had to grant permissions for the service accounts in the DCOM configuration for the IIS WAMREG admin service. I expected this to happen automatically but was not surprised given the history of CLSID 61738644-F196-11D0-9953-00C04FD919C1.