Hello all, I have been asked by the moderator to recreate this topic in the Exchange Forum after previously asking in the Directory Services Forum (http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/68f6cf46-438c-436c-9b2a-fc3a689d19a8/) I was performing an Active Directory domain rename for a client over the weekend and ran into an issue with the XDR-Fixup tool which is used to update the Exchange attributes in Active Directory after the domain rename. I was unable to get past this issue which meant I had to revert the changes I made and rename the domain back to its original name. Here is an outline of the environment: Domain Controllers: Windows Server 2003 SP2 Exchange server: Microsoft Exchange 2003 Standard SP2 Renaming from a single label DNS name to a two-part DNS name. NETBIOS name remaining the same. I have followed the domain rename procedure as per Microsoft Technet documentation and the domain rename using rendom goes through successfully with no issues. The issue I run into is with the XDR-Fixup tool. When running the tool with the following commandline: XDR-fixup /s:domainlist-save.xml /e:domainlist.xml /trace:tracefile /changes:changescript.ldf /restore:restorescript.ldf I get the following error: Operation failed: No other details are displayed. The changescript.ldf file does not end up being created. The restorescript.ldf file is created but at 0kb with no content. If I look at the tracefile, the following is listed: ===== XDR-FIXUP TRACE LOG BEGINS AT 3/28/2011 3:12:19 PM +08 ===== Using GC: DC1.companyname Malformed entry in domainlist file: guid=2b5cc218-e6c0-47cd-b2c9-93568b7b22bb, dns=DomainDnsZones.companyname, netBios= Malformed entry in domainlist file: guid=41859596-5131-4fbd-852a-e8edd51c44ab, dns=ForestDnsZones.companyname, netBios= 9ee4ac53-d720-408f-bbf1-04565637e8d6: dns(local) netBios(COMPANYNAME) Malformed entry in domainlist file: guid=2b5cc218-e6c0-47cd-b2c9-93568b7b22bb, dns=DomainDnsZones.companyname.local, netBios= Malformed entry in domainlist file: guid=41859596-5131-4fbd-852a-e8edd51c44ab, dns=ForestDnsZones.companyname.local, netBios= 9ee4ac53-d720-408f-bbf1-04565637e8d6: dns(vicpark.local) netBios(VICPARK) DNS mapping: companyname -> companyname.local NetBios mapping: COMPANYNAME -> COMPANYNAME Org container: LDAP://CN=companyname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=companyname,DC=local Specified argument was out of the range of valid values. Parameter name: Index was out of range. Must be non-negative and less than the size of the collection. at System.Collections.CollectionBase.System.Collections.IList.get_Item(Int32 index) at System.DirectoryServices.PropertyValueCollection.get_Item(Int32 index) at Microsoft.Exchange.Tools.ExRenDom.QueryDCsInForest() at Microsoft.Exchange.Tools.ExRenDom.Main(String[] args) The malformed entry warnings just seems to be because the NETBIOS name is not listed in my domainlist.xml file under ForestDNSZones and DomainDNSZones (auto generated by rendom /list and then modified for new domain). Manually adding the NETBIOS name between the <NetBiosName> tags in the xml file removes the errors but the command still errors out. Hence I assume the malformed entry errors can be ignored and are not part of the issue as the domain rename itself went through without issue. Below is an example of what occurs, just for reference. ===== XDR-FIXUP TRACE LOG BEGINS AT 3/26/2011 11:28:54 AM +08 ===== Using GC: DC1.companyname 2b5cc218-e6c0-47cd-b2c9-93568b7b22bb: dns(DomainDnsZones.companyname) netBios(COMPANYNAME) 41859596-5131-4fbd-852a-e8edd51c44ab: dns(ForestDnsZones.companyname) netBios(COMPANYNAME) 9ee4ac53-d720-408f-bbf1-04565637e8d6: dns(companyname) netBios(COMPANYNAME) 2b5cc218-e6c0-47cd-b2c9-93568b7b22bb: dns(DomainDnsZones.companyname.local) netBios(COMPANYNAME) 41859596-5131-4fbd-852a-e8edd51c44ab: dns(ForestDnsZones.companyname.local) netBios(COMPANYNAME) 9ee4ac53-d720-408f-bbf1-04565637e8d6: dns(companyname.local) netBios(COMPANYNAME) DNS mapping: DomainDnsZones.companyname -> DomainDnsZones.companyname.local DNS mapping: ForestDnsZones.companyname -> ForestDnsZones.companyname.local DNS mapping: companyname -> companyname.local NetBios mapping: COMPANYNAME -> COMPANYNAME Item has already been added. Key in dictionary: "COMPANYNAME" Key being added: "COMPANYNAME" at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) at System.Collections.Hashtable.Add(Object key, Object value) at Microsoft.Exchange.Tools.ExRenDom.CreateDnsAndNetBiosMaps(String startDomainFile, String endDomainFile) at Microsoft.Exchange.Tools.ExRenDom.Main(String[] args) The errors seem to be .NET errors that don't make much sense to me but I have tried running the XDR-Fixup tool on multiple computers with .NET 1.1 installed so I'm fairly certain this is not the issue. I have now made a test environment and cloned the appropriate servers as new virtual machines so I can perform testing. Although the production environment has multiple DCs at different sites, I have honed the test environment down to a single DC, an Exchange server, and a control station. This environment produces an identical error when running XDR-Fixup. During testing, I ran Process Monitor filtered on the XDR-Fixup process and the program does appear to establish an LDAP connection with the domain controller but I couldn't really read from it why the XDR-Fixup process was failing. As to what data (if any) goes across that connection, I don't know. I'm not sure if its possible to do more advanced monitoring/tracing of LDAP connections from an Active Directory service perspective to try and see what attributes XDR-Fixup is trying to modify or where the connection is bombing out (if this is in fact the case)? I am thinking of trying Network Monitor to rule out any connection issues. With everything now in a separate test lab, I am happy to try things which would not be recommended for production to try and find the answer!

Please ignore the "malformed entry in domainlist file" in the trace log. As long as DNS mapping is successful, the old domain name is being mapped to the new domain name successfully “Found DC” traces should appear under the line below, please run “NLTEST /DCLIST:<domain>” command to get all DCs Org container: LDAP://CN=companyname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=companyname,DC=local The exrendom.cs file does a search for NTDS objects in the “Configuration” container, and then checks the dNSHostName attribute on the parent object of each NTDS object. So, please do the same search via LDP 1. Launch LDP 2. Bind in with Domain Admin credentials 3. Click “View” > “Tree”, leave “Base DN” blank, click OK 4. Expand the domain in the left window, and select the “Configuration” container 5. Right-click the container, and choose “Search” 6. In the “Search” dialog, click the drop-down arrow beside “Base DN” and select the “Configuration” container 7. For the filter value, use “objectClass=ntDSDSA” 8. Select the “Subtree” option, then click the “Options” button 9. Clear the Attributes value in the “Options” window, then enter “DN” 10. Select “Sync.” In the “Search Call Type”, also select “Attributes Only” and “Display Results” 11. Click OK, then click RUN After get the list of DCs, please check each server to verify that it has a “DNSHostName” attribute value via LDP. If any DC does not have a “DNSHostName” entry, or an invalid “DNSHostName” entry, correct it (KB 240942), force DC replication, and run the XDR-Fixup tool again Resource: Exchange and Domain Rename Operations James Luo TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com 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.

Hi James, Thanks for the tip. The DNSHostName attribute was configured correctly for all DCs. The client has opted to log a support call with MS so we'll see how things go!

Please keep us posted.

How's the issue currently? Any further information?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.

The Microsoft support engineer was able to fix the issue in the client's test lab environment. We will be implementing the change in the production environment this weekend so I will update this thread once we know it has succeeded! Sam

Thanks for sharing updatePlease 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.

Blogged the fix here: http://blog.samkendall.net/2011/04/14/fixed-xdr-fixup-issue-during-active-directory-domain-rename/ The cause of this problem was that some NTDS objects had been removed to the LostAndFoundConfig container in the Configuration partition of Active Directory. For some reason, when orphaned objects are in this container, the XDR-Fixup process is unable to complete successfully. The solution to this issue was to deny access to any objects in the LostAndFoundConfig container for both the Domain Users and Domain Computers groups. This can be done as follows: On a domain controller, run adsiedit.msc Add Configuration partition to this tool. Expand it, and locate the CN=LostAndFoundConfig folder to see if there is anything in it, if yes, Select each object in this container View its properties, In security tab, click “Add…”, to add Domain Users and Domain Computers groups into list and Deny them “Full Control” Then, try XDR-Fixup again. Thanks to Microsoft support for this fix!

Thanks for sharing the resolution!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.