On Windows: is it safe to do a robocopy in order to clone the system?

AD Servers are different. A Domain Controller has a directory junction on the C:\Windows\SYSVOL\sysvol directory that points to the C:\Windows\SYSVOL\domain directory:

 Directory of C:\Windows\SYSVOL\sysvol

04/13/2011  01:22 PM    <DIR>          .
04/13/2011  01:22 PM    <DIR>          ..
04/13/2011  01:22 PM    <JUNCTION>     domainName.acme.com [C:\Windows\SYSVOL\domain]

Almost any type of a manual copy operation would result in a SYSVOL that does not come online due to a borked junction. Although to be accurate, this can occur in normal restore scenarios, so it is always advisable to check and re-create the SYSVOL junction if necessary.

Speaking of links, any Windows 2008/Vista/Windows 7 system may have thousands of links in the %SYSTEMROOT%\System32 folder for the binaries. These link targets actually reside in the %SYSTEMROOT%\Winsxs folder.

I haven't confirmed this, but Robocopy may copy the target instead of the link. Which would explain the switch /SL :: "copy symbolic links versus the target".

It's possible the system may appear to function correctly, but what would occur when it's time to perform a system update activity, that needs to maintain the files where the link targets usually reside? Perhaps it would re-create them, but that would be something worth testing.

If you're curious how these links transferred to the copied disk, you can take a before and after snapshot, then compare the files using Windiff or Notepad++.

You can use the following command to get an output the junction points on a drive:

dir C:\ /aL /s  >> junctions.txt  

You can use the following script in a file to get a an output of the links for a location (for example, systemroot):

for /r %systemroot% %%i in (*.exe,*.dll) do (
  echo Checking file: %%i >> file.txt
  fsutil.exe hardlink list "%%i" >> file.txt 2>&1
  echo . >> file.txt
)

I've performed file-level clones (using the Linux NTFS Tools ntfsclone utility) of Windows 2000 and Windows XP. I haven't tried ntfsclone with Windows Vista or newer versions but I wouldn't expect any problems. I use Microsoft's file-level cloning tool, ImageX, quite regularly with Windows XP and Windows 7 and have no problems there, either. I generally don't clone server computers, but I would expect ImageX to work fine with server OS's.

Copying a live filesystem is always going to be a challenge. Volume Shadow Copy is supposed to expose a quiescent filesystem but I think you're still taking your chances. (I can't tell you what happened with your VSS-cloned volume that wouldn't allow you to logon. W/o being able to see the failed clone it's really, really difficult to diagnose). I'd always advise you to clone systems that are offline, if possible.

Assuming you're copying a completely quiescent filesystem and able to get all files your only concerns are:

• Having a good master boot record (MBR) and partition boot record (PBR)
• Having a good bootloader

Microsoft's bootsect.exe can be used to write good MBRs and PBRs for older NTLDR-based versions of Windows NT (NT 3.5 thru Windows Server 2003) and BOOTMGR-based versions (Windows Vista and newer). Your Windows 2003 clone must have been to a disk that had an NT 5.2-format PBR (since it booted).

The NTLDR bootloader will be copied in a file-level copy, which explains why your Windows 2003 copy worked w/o issue. The BOOTMGR bootloader can be installed using the bcdboot.exe utility (included on BOOTMGR-based Windows setup media).

I wouldn't clone Active Directory Domain Controller (DC) computers this way. You don't want to boot a clone of a DC on the same network with the original DC because this is a wholly unsupported and, likely, unplanned-for scenario.

Edit (now that I have a few minutes on a real computer):

The tools I described above, ImageX and ntfsclone, are filesystem-level clone tools (as is Ghost if it's not run in raw sector mode). They interpret the NTFS filesystem rather than copying sector-for-sector. Both of those tools won't have problems with junction points or hardlinks like ROBOCOPY (w/o the /SL argument) and XCOPY (with any arguments) would.

In general, Microsoft is not planning for you to perform file-level copy-based cloning of systems. Yeah, you can do it, but if it breaks you get to keep the pieces.

The problem with copying a live filesystem from VSS is that that the existing Windows instance will probably have the signature of the new disk already in it's registry. When you boot the copy, the signature of the partition it is booting from is matched to the registry and mounted as D: or E:, rather than the C: it should be.

You can sort this out by mounting the registry file and updating HKLM\SYSTEM\MountedDevices Do this after the copy but before restarting. You just want to delete the \DosDevices\C: entry and change the entry for your new drive to C:.