On a regular basis, top Microsoft executives answer readers' toughest technical questions about Windows-based systems. This installment of "Ask Microsoft" was answered by Brad Rutkowski, Microsoft IT Operations Analyst.
To submit a technical question for consideration, send an email to editor@SearchWinComputing.com.
Question: We are in the final stage of our NT 4.0 to Windows Server 2003 Active Directory migration to the point where we would like to decommission the NT 4.0 domain. (I will call it olddomain.com.)
Due to an error more than 18 months ago, many of the XP Pro workstations in our enterprise had their images built using a URL representing the URL of our enterprise intranet homepage, but under the old domain name. Additionally, the URL included the server computer name rather than the CNAME www. The URL of the intranet homepage under the old domain was http://web1.olddomain.com, where web1 was the machine name of the intranet server. We need to find a way to decommission the olddomain.com without having the XP clients unable to get to their IE homepage, which would happen if we just decommissioned olddomain.com.
We have found that the registry settings that govern the IE start page are complex and we don't want to "tattoo" the machine registries. Ideally, the solution would be completely transparent to end-users so that their machines would be free of the errant start page address but retain whatever existing start page they have. And if it is the enterprise intranet page, the address would be changed to the new URL in the form http://www.newdomain.com.
Is there is some kind of programmatic solution we could use in our logon scripts?
Answer: You might think that the registry is not the solution but through researching this, it turned out to be the easiest and cleanest. Without using the registry you would need to keep some delegations in place for olddomain.com and maintain DNS records that would map the hostname web1 to the new servers address(s). Using server-side redirection on an IIS server probably wouldn't work for this case either, since it is an FQDN for a domain that doesn't exist (or soon won't). "Tattooing" the registry is not an issue when using the value below, the "start page" value is a default registry setting and won't be removed if a user changes roles, so you're not adding static information to the registry. You're only changing the value that is present.
When a user logs on to their workstation their settings get stored in HKCU (HKEY_CURRENT_USER), so changing the start page value under that key will ensure that it is changed on only those users who have the old domain as their start page.
This is a working example of how simple the script could be to change the incorrect clients; this could then be pushed out via a logon script.
set %errorlevel% = 1
reg query "hkcusoftwaremicrosoftinternet explorermain" /v "start page" |findstr /i
if %errorlevel% == 0 (
reg add "hkcusoftwaremicrosoftinternet explorermain" /v "start page" /t REG_SZ /d
All we're doing here is querying the current start page value in HKCU and if we find http://web1.olddomain.com with the findstr utility, the errorlevel variable will be set to zero (success). In which case we add the corrected value to the registry and exit. If we don't find it then the errorlevel is set to one and we skip past the "if" statement and exit.
If the error level is set to zero then we know that the URL is pointing to the old address, at which point we can update it with the new address. If the user then changes their homepage the script will not affect them because it only changes those clients with the settings set to http://web1.olddomain.com.
Reg.exe and findstr.exe should be part of the base OS install image but if not, it wouldn't be difficult to copy them down in the beginning of the script.
-- Brad Rutkowski, Microsoft IT Operations Analyst