I'm trying to use DFS Replication to keep a large file share synchronized between SERVER1 and SERVER2. The full dataset is closer to 80 TB, and the files have already been copied to the destination, so I'm trying to avoid DFS-R retransmitting everything from scratch. I created a small test replication group first. On SERVER1, I ran Export-DfsrClone for G:test3, copied the resulting clone files to SERVER2, and then ran Import-DfsrClone -Volume M: -Path C:dfsrclone-fromserver1. The import fails with error 0x00002397. The DFS Replication event log reports error 9111: "MSXML.DLL is not installed." Server 2022 does not appear to contain the legacy MSXML.DLL, although newer MSXML versions are present. I also noticed that Get-DfsrFileHash returns different values for identical files on the two servers, even though Get-FileHash produces matching SHA256 hashes. Is database cloning still supported on current Windows Server versions, and is there a reliable way to resolve this import error or pre-seed the replication without copying the entire dataset again?
3 Answers
The Get-DfsrFileHash result is not the same thing as a normal SHA256 file hash. Matching Get-FileHash values only proves that the file contents match; DFS-R also considers filesystem metadata. Differences in ACLs, attributes, timestamps, ownership, or other metadata can produce different DFS-R hashes. Re-copying with a tool that preserves the complete security descriptor and file metadata is worth testing, but it will not by itself explain or fix the MSXML import failure.
The comments don’t establish a confirmed fix for the 9111 error. The clone-database workflow was documented for older Windows Server releases, so I’d first verify that the exact Export-DfsrClone and Import-DfsrClone combination is supported on the installed Server 2022 build. Re-registering unrelated MSXML DLLs should not be treated as a guaranteed solution, especially when the error specifically refers to the legacy MSXML.DLL. Test this on a disposable volume and check the DFS-R event logs and Microsoft compatibility guidance before using it on the production data.
For a dataset this large, the safer fallback is to configure normal DFS-R and let it reconcile the existing files, preferably with the initial synchronization performed while the destination is offline or otherwise prevented from changing. That may take time, but it avoids depending on a fragile or unsupported database-cloning path. Since the destination already contains the data, also confirm that the files, timestamps, attributes, ownership, and NTFS permissions match before assuming DFS-R can treat the copy as pre-seeded.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures