none
Domain Rename: Cleaning Up After

    Question

  • I have just completed a domain rename operation on a Windows Server 2003 R2 domain that apparently came down smoothly, without errors and with everything working at the end. Quick background: This domain has two DCs and a bunch of XP SP3 client members. Nothing else. No other server members (other than the Control Station server that I created and added to the domain for the purpose of running rendom). No Exchange, no Internet (i.e., no visibility to anything outside the domain). Simple. After renaming the domain, I renamed the two servers, and also changed the IP addresses of every system (including all members) in the domain. Everything (DFS, AD, Group Policies, everything) works. Apparently. As far as I can tell... so far.

    But I am bothered by the DNS structure and my clients (Windows XP members) are bothered by their default directory name. In DNS, I see entries for both the old domain name and the new domain name, and even though I set the new domain name to be primary via netdom, the old domain name records "appear to me" to be "in control".

    Under Forward Lookup Zone for .(root) -> local, I have a folder for 'old_domain_name' that contains two Host(A) records, one for each DC -and- I have a folder for 'new_domain_name' that contains a Name Server (NS) record pointing back to 'computername.old_domain_name.local'. So this looks to me like 'new_domain_name' is just an alias or a pseudonym for old_domain_name. I sort of expected that after completing this procedure and cleaning up everything, old_domain_name would no longer appear in DNS. The way things look to me suggests that if I did (and if I could) delete or remove DNS entries referencing old_domain_name, everything would break (because new_domain_name depends on old_domain_name for its definition). Apparently.

    But wait. Maybe not. Moving on down the tree, I have Forward Lookup Zone entries for old_domain_name.local and new_domain_name.local and _msdcs.old_domain_name.local and _msdcs.new_domain_name.local, and the entries associated with new_domain_name appear to be fully-populated, while the odl_domain_name entries are not. But there are still entries scattered throughout the tree that refer to old_domain_name.

    So my question here is: Is this a problem, and would everything break if I tried to delete all the DNS records that are defined in terms of old_domain_name?

    It might help here for me to add -- in case you were wondering why we changed everything, including the IP addresses of every system in the domain -- all of this operation is in preparation for a new domain, currently bearing the same names and IP addresses and structure as old_domain_name ... to join the forest.  In other words, we have two identically configured domains, each standing alone with no knowledge of each other or anything else in the world ... and we need to join them together as two DIFFERENT domains in the SAME FOREST. So ONE of the domains has to change its name, the names of its DCs, and all of its IP addresses. And my domain is the lucky one that gets to change.

    So... it is my assumption that in MY domain, I need to get rid of all remnants and vestiges of old_domain_name, as well as its computernames and IP addresses. Before we join our two extant domains at the hip in a common forest. So on this basis, I think the remnants of old_domain_name in my current domain could be a problem. Down the road and around the next corner.

    The other name problem -- and this is (I think) a completely separate problem and a problem in name only -- is that my Windows XP client members, all of which are well-aware of the new domain name, still associate with each computer user a default directory of the form

    C:\Documents and Settings\<username>.old_domain_name

    Is there a way to change this to C:\Documents and Settings\<username>.new_domain_name ??  Maybe just rename the directory and watch everything break? I think that this is just a name issue, not a functionality issue, but my users are picky. I'm less worried about this than about the remnants of old_domain_name in my DNS.

    Any suggestions about either of these "clean up" issues will be greatly appreciated !!


    Chris

    Friday, April 20, 2012 1:26 AM

Answers

  • After some consideration (with a dash of trepidation) I decided to walk the DNS tree and manually change or delete all the references to old-domain-name. Under new-domain-name.local. for example, if there was an SOA record that had Data referencing old-domain-name, I edited it to refer to new-domain-name. Where there was a branch in the tree (a domain) named old-domain-name.local or _msdcs.old-domain-name.local, I deleted it. Editing the domain definition for new-domain-name under local under .(root) was a bit more circuitous because it was defined as a delegate from old-domain-name. So I had to delete them both and then re-define (add) new-domain-name and add to it the Host(A) records for the two DCs in the domain (which formerly had been defined under old-domain-name). 

    The good news (at least for the moment) is that everything appears to work after doing all this, and DFS propagated the DNS changes through the domain. So... since I couldn't find any sequence of "standard" operations that would correct or remove the lingering DNS definitions, and given that I had (to the best of my knowledge and belief, then and now) followed all of the steps in Step-by-Step for Domain Rename and they had all executed successfully, I conclude that the Domain Rename procedure is not infallible with regard to fixing DNS, and that manual editing can, in some cases, be a viable method for cleaning up lingering errant and inappropriate DNS entries after all else has been done.

    I consider this case closed (with thanks to all who have contributed direction and suggestions).


    Chris

    • Marked as answer by VideoCowboy Sunday, April 29, 2012 12:16 AM
    Sunday, April 29, 2012 12:15 AM

All replies

  • Hi,

    Please not directly delete the old domain zone from the DNS console. You need to perform a cleanup to complete the domain rename operation.

    Quote from the following Link:

    Run rendom /clean to remove references of the old domain name from Active Directory

    Note: Perform this cleanup procedure only after all member computers in the renamed domains have been restarted as described in Restart Member Computers.

    Perform Attribute Cleanup

    http://technet.microsoft.com/en-us/library/cc794791(WS.10).aspx

    Completing the Domain Rename Operation

    http://technet.microsoft.com/en-us/library/cc794825(WS.10).aspx


    Best Regards,

    Aiden


    Aiden Cao

    TechNet Community Support

    Monday, April 23, 2012 1:57 AM
  • Aiden,

    Thank you for your message and reply to this issue. As a part of my domain rename operation, I did perform rendom/clean after all member computers had rebooted twice. As far as I know and as far as I can tell, all documented steps have been performed as described and recommended. The concern that I have now is that there are still present some DNS entries reflecting old-domain-name in each of five areas of the Forward Lookup Zones tree, as follows:

    1. .(root) -> local

        old-domain-name: A "normal" (closed) yellow folder with two Host (A) entries, one for each of 2 DC names

        new-domain-name: A grey folder with page icon overlay that has a single Name Server (NS) entry with Data (value) DC1name.old-domain-name.local.

    2. _msdcs.old-domain-name.local

        A yellow folder with page icon overlay that has 3 Data entries as follows:

        -  an SOA entry with Data [180], DC1name.new-domain-name.local, hostmaster.

        -  an NS entry with Data DC2name.new-domain-name.local.

        -  an NS entry with Data DC1name.new-domain-name.local.

    3. _msdcs.new-domain-name.local

        A yellow folder with page icon overlay that has 4 subfolders (all "normal" yellow folders) for dc, domains, gc and pdc -plus-

        Six "page icon" entries, as follows:

        -  An SOA entry having Data [65], DC1name.new-domain-name.local, hostmaster.old-domain-name.local

        -  An NS entry having Data DC2name.new-domain-name.local.

        -  An NS entry having Data DC1name.old-domain-name.local.

        -  An NS entry having Data DC1name.new-domain-name.local.

        -  A CNAME entry having Data DC2name.new-domain-name.local

        -  A CNAME entry having Data DC1name.new-domain-name.local

        Subfolders for dc, domains, gc and pdc, each with subfolders of their own that appear to be correctly populated with entries reflecting new-domain-name

    4. old-domain-name.local

        A yellow folder with page icon overlay that has one subfolder and 6 "page icon" entries as follows

        -  A grey subfolder with "page icon overlay" named _msdcs that contains a single NS entry for DC1name.old-domain-name.local

        -  An SOA entry having Data [340], DC1name.new-domain-name.local, hostmaster.

        -  An NS entry having Data DC1name.new-domain-name.local.

        -  An NS entry having Data DC2name.new-domain-name.local.

        -  An NS entry having Data DC1name.old-domain-name.local.

        -  A Host(A) entry having Data correct IP address for DC1name

        -  A Host(A) entry having Data correct IP address for DC2name

    5. new-domain-name.local

        A yellow folder with "page icon overlay" having 6 subfolders and 9 "page icon" entries as follows"

        -  A grey subfolder with "page icon overlay" named _msdcs having a single NS entry for DC1name.old-domain-name.local.

        -  Subfolders for _sites, _tcp, _udp, DomainDnsZones and ForestDnsZones  that appear to be correctly populated with entries reflecting new-domain-name

        -  Nine "page icon" entries, including one SOA entry reflecting old-domain-name and two NS entries reflecting new-domain-name and six Host(A) records reflecting IP addresses of DCs and Member computers

    So my present concern is that there are still, after all documented procedures have been run and performed without error, various DNS entries relfecting old-domain-name in this forest. At present, this forest is home to only the single (renamed) domain, which appears to be functioning properly despite the DNS entries that point to old-domain-name. HOWEVER, in the future a new domain will join the forest, and this new domain will have EXACTLY the same name (and IP addresses and other properties as the ORIGINAL name (and IP addresses and other properties) of the domain that I just renamed (and re-addressed). The plans for this are as described in my original posting for this issue.

    Just to clarify: The domain rename operation described in this issue is a Windows Server 2003 R2 domain (with domain and forest having 2003 functional level).

    A last note here: I don't know the meaning of the various icons that appear in the DNS tree, and I am not alone in this as I have seen postings in other forums from users who could not find information explaining the yellow-versus-grey folders, some with and some without "page icon overlays". The other postings that I have seen from other users never had a satisfactory answer about this, so if I don't find an answer in this forum, I should post a separate question about this so there will be a place for all users to find this information directly.

    Many thanks for your help with this issue about lingering DNS entries for old-domain-name and the proper way to remove them... !!


    Chris

    Monday, April 23, 2012 11:03 AM
  • Hi,

    Thanks for your detailed information,

    Is there any error log showing up which related to netlogon? I still suspect that the rendom /clean was not run correctly when performing domain rename. Please try to add a new member server in new.com domain and run random /clean against all the DSs again.

    Random /clean /dc:<DCname>

    Gpfixup /olddns:<old dns name> /newdns:<new dns name>

    Random /end

    If still no luck, please try to log on to the DC using an administrator account. Rename the following files in the %Systemroot%\System32\Config folder:

    Netlogon.dns to netlogon.old

    Netlogon.dnb to netlogon.old1

    Then, try to restart the DC if possible. If not available, please run the following commands to register SRV record in DNS:

    Ipconfig /flushdns

    Net stop netlogon

    Net start netlogon

    Ipconfig /registerdns

    After that, please check if the issue still persists.


    Best Regards,

    Aiden


    Aiden Cao

    TechNet Community Support

    Tuesday, April 24, 2012 2:59 AM
  • Aiden,

    Thanks for your message and suggestions. During the original domain rename procedure, I did of course do rendom/clean and gpfixup and rendom/end, and they all reported clean and successful completion. gpfixup wrote a log file that simply said it executed with success (without really needing to do anything significant because there weren't any group policies to fix).

    But following your suggestions, I did them all again (from the control station server). They again all reported executing with success.

    Then from the DC1 (1st of 2 domain controllers) I did flushdns, stop and start netlogon, and registerdns as you suggested. They all executed with success and registerdns reported nothing in Event Viewer (under DNS Server) after 30 minutes.

    Checking DNS (dnsmgmt) on DC1 showed no change. DNS still looks the way I described it in my entry from Monday, April 23, 2012 11:03 AM, above.

    I should explain that I am performing this domain rename on a "test" or "practice" configuration that mirrors the production configuration on which I plan to perform the "real" domain rename after I am confident that I know how to do it reliably and without errors. Both my test domain and my production domain are isolated or standalone domains (the only domain in the forest), and quite simple. Just two Windows Server 2003 R2 domain controllers with a bunch of Windows XP Pro SP3 client members. And, in each case, a 3rd Windows Server 2003 R2 system acting as Control Station for the domain rename operation. No Exchange, nothing complicated.

    One of my principal objectives for the present domain rename operation (in the test configuration) is to understand what's happening, how to recognize problems when they arise, and learn how to recover from them if they do arise. At the present time it appears to me like something we can't explain kept the update-and-clean operation on DNS from executing as it should. The result is that I have something of a "hybrid" or even "incomplete" update of DNS.

    I don't claim to know what the Forward Lookup Zones tree in DNS should look like, but comparing it to similar trees in other domains, I would expect that in the first level under Forward Lookup Zones I would find branches for _msdcs.new-domain-name.local and for new-domain-name.local. Instead, I find branches at this level for:

    _msdcs.old-domain-name.local

    _msdcs.new-domain-name.local

    old-domain-name.local

    new-domain-name.local

    So I might be tempted to delete the branches for _msdcs.old-domain-name.local and old-domain-name.local, but the problem is deeper than that because there are entries in branches and leaves under _msdcs.new-domain-name.local and new-domain-name.local that have values (Data) defined in terms of old-domain-name. One example:

    In _msdcs.new-domainname.local I expect to find an SOA entry with Data of the form

    [some-number], DC1.new-domain-name.local, hostmaster.new-domain-name.local

    But instead I find

    [some-number], DC1.new-domain-name.local, hostmaster.old-domain-name.local

    So I think... OK, I could edit the value of 'responsible person' to change hostmaster.old-domain-name.local to hostmaster.new-domain-name.local, but I have no idea how to tell if some-number (currently [65]) is correct or not. My bet is that it probably is, but that's just a bet.

    Making changes like this would in any case mean walking the tree and changing things from old-domain-name to new-domain-name or deleting entries that appear to be unnecessary duplications referring to old-domain-name.

    Is this a feasible way to "recover" from the sort of incomplete result that I have now?

    I could, of course, simply wipe the entire domain and recreate it and start all over from the beginning, but I sort of feel that I wouldn't have learned anything about "fixing it" if it happens again. And if it doesn't happen again (in my test configuration) I wouldn't have learned anything about recovery if it happens in production. If anything like this happens when I do the rename operation in production, I won't have the luxury of taking days to fix it.

    Any hints or suggestions you can offer will be much appreciated !!!


    Chris

    Wednesday, April 25, 2012 9:39 PM
  • HI,

    The domain rename process involves updating the DNS and trust infrastructure as well as Group policy and SPNs, and the operation will affect every domain controller in the forest. Before the operation, the domain is needed to require the requirements such as forest functional level, trust relationship, DNS zones, DFS issue, etc.

    the domain rename is a complex and systemic project. If you do want to change your domain name, please firstly ensure your network environment meets all the prerequisites and it is strongly recommended to make a good and considerate plan including creating a backup and rollback plan for use in the event that the unexpected error fails.

    Administering Active Directory Domain Rename:  http://technet.microsoft.com/en-us/library/cc794869(WS.10).aspx

    Generally, it is recommended that we create a new domain then migrate the old domain to the new one by using ADMT tools.

    ADMT guid" http://technet.microsoft.com/en-us/library/cc974332(v=WS.10).aspx


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, April 26, 2012 10:09 AM
  • After some consideration (with a dash of trepidation) I decided to walk the DNS tree and manually change or delete all the references to old-domain-name. Under new-domain-name.local. for example, if there was an SOA record that had Data referencing old-domain-name, I edited it to refer to new-domain-name. Where there was a branch in the tree (a domain) named old-domain-name.local or _msdcs.old-domain-name.local, I deleted it. Editing the domain definition for new-domain-name under local under .(root) was a bit more circuitous because it was defined as a delegate from old-domain-name. So I had to delete them both and then re-define (add) new-domain-name and add to it the Host(A) records for the two DCs in the domain (which formerly had been defined under old-domain-name). 

    The good news (at least for the moment) is that everything appears to work after doing all this, and DFS propagated the DNS changes through the domain. So... since I couldn't find any sequence of "standard" operations that would correct or remove the lingering DNS definitions, and given that I had (to the best of my knowledge and belief, then and now) followed all of the steps in Step-by-Step for Domain Rename and they had all executed successfully, I conclude that the Domain Rename procedure is not infallible with regard to fixing DNS, and that manual editing can, in some cases, be a viable method for cleaning up lingering errant and inappropriate DNS entries after all else has been done.

    I consider this case closed (with thanks to all who have contributed direction and suggestions).


    Chris

    • Marked as answer by VideoCowboy Sunday, April 29, 2012 12:16 AM
    Sunday, April 29, 2012 12:15 AM
  • Aiden,

    I added a Windows Server 2008 R2 domain controller to a Windows 2000 domain with a single name domain after updating the schema. I demoted the 2000 domain controller to a member server thus being left with a 2008 dc with a single name domain. I renamed the domain from old_domain_name to old_domain_name.local following the Appendix C: Checklist for the Domain Rename Operation and related documents in the TechNet library. The rendom /clean & Gpfixup commands did not cleanup my dns structure. I was left with a Forward Lookup Zone of old_domain_name & old_domain_name.local which is the new domain name. I manually deleted the old_domain_name FLZ from DNS since rendom /clean did not fix that (my mistake). After restarting the workstations twice, the DNS Search List showed the old_domain_name.local & the old_domain_name. The procedure you specified:

    Random /clean /dc:<DCname>

    Gpfixup /olddns:<old dns name> /newdns:<new dns name>

    Random /end

    Rename the following files in the%Systemroot%\System32\Config folder:

    Netlogon.dns to netlogon.old

    Netlogon.dnb to netlogon.old1

    please run the following commands to register SRV record in DNS:

    Ipconfig /flushdns

    Net stop netlogon

    Net start netlogon

    Ipconfig /registerdns

    sucessfully cleaned up the DNS structure and left me with a DNS Suffix Search List of old_domain_name.local & old_domain_name.local.

    Thank you for this procedure as it has been invaluable to me.

    I still have a problem with DHCP which I am working on that I think is related to the DNS structure but that is another problem. The Event log shows "The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain old_domain_name.local, has determined that it is authorized to start. It is servicing clients now." The DHCP manager shows the old_server_name.old_domain_name without the .local extension and I cannot view or modify it. When I try to remove that to add the .local entry, I am asked if I want to remove it to which I reply [Yes]. When I close the DHCP manager, I get a "MMC cannot initializ the snap-in" dialog. When I reopen the DHCP manager the old entry is still there.

    Regards,

    kacollier



    • Edited by kacollier Sunday, December 30, 2012 8:03 AM
    Sunday, December 30, 2012 7:45 AM