The XDR-Fixup tool runs in two modes. The default mode is a mainline rename of Exchange attributes in the Active Directory (AD), and the verification mode checks that all changes made were appropriate. You might be wondering what this verification step is for. Well, it is necessary because of servers whose DNS name is configured not to change when the server’s domain membership changes. (This can be configured via the "Change primary DNS suffix when domain membership changes" checkbox at the My Computer > Properties > Computer Name > Change... > More... window.) So you’d think that XDR-Fixup could just ignore all statically configured DNS names when it tries to rename attribute values in the AD, but it turns out that remotely determining whether a particular server is configured this way a priori is close to impossible.
So XDR-Fixup does the next best thing: it checks which servers refuse to be renamed by the Windows RenDom procedure. On startup, each machine publishes its DNS name to the servicePrincipalName attribute of its computer object in the AD (for example, CN=SomeComputer,CN=Computers,DC=MyDomain,DC=com). So by checking this attribute before and after the RenDom procedure, we can determine which servers have statically configured DNS names. In the default mode, XDR-Fixup remembers the old and renamed DNS name of each server it renamed (it actually stores this in the RESTORE file). Then, in the verify mode, after RenDom is complete and all member servers have been rebooted, it checks whether the old or renamed DNS name shows up in the servicePrincipalName attribute with the filters
If the first filter succeeds but the second one fails, XDR-Fixup creates an LDIF clause in the VERIFYCHANGES file that un-renames every attribute where we replaced somecomputer.mydomain.com with somecomputer.myrenameddomain.com in the default mode.
Note that DCs do not have their DNS names changed by RenDom, but XDR-Fixup is smart enough to identify the DCs and avoid renaming their DNS suffixes throughout the AD.