20

Let me start by giving a bit of a background. On Linux systems, I frequently rely on the fact that as long as I can get all files over from one hard drive to another, and as long as I fix up the boot loader, I'll be left with an identical, bootable, fully functional system. Same thing works for backups and restores (no special system state backup required, just the files) ... even MySQL is recoverable sometimes even when it wasn't frozen at the time of the backup

On Windows, I've never had luck with cloning the system by doing it at a file level. I always need a tool such as VMWare Converter, Ghost, diXML etc .. they are based on taking the image of the drive as a whole. At first I assumed that this was mainly because of the special/magical way windows does it's registry and I didn't question it (it worked). Until today. I realized that this kind of thinking was dumb, and that in reality Windows is also just a collection of files. So as a test I took an offline Windows 2003 server drive, I copied the files over to a blank hard drive, made the drive active and .. it worked perfectly!

Or did it? Why do I have this irrational fear that it will fail just because it's not a verbatim clone like I would have expected with Ghost? Should I be scared? Why was it so easy? Are AD servers any different? Are there cases where this method will fail?

If file-by-file copy is the way to go, why is it that when I tried to do the same thing with VSS (exposing shadow copied C: drive as an S: drive) the same approach failed. More specifically I got a booting system all the way to the login screen. It even accepted my password, but then immediately logged off my user with no error in the GUI. I even tried shutting off all but un-stoppable services before copying ... same result.

By the way I'm using robocopy /E /SEC for all these copy operations

Am I just looking for trouble by using these methods? I know that Ghost etc are proven .. so why reinvent the wheel? ... I get all that ... but as a professional I want to know why the things work the way they do. That's why it's important for me to figure this out. (not to mention a rare possibility of having to do a bare metal restore on a system where I never had system state backup)

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
ixnaum
  • 203
  • 1
  • 2
  • 4
  • 2
    Addressing the particular case of domain controllers: note that there is no safe way to clone a domain controller, because doing so messes up the Active Directory replication. I'm fuzzy on the details, but basically each DC has a unique identifier that is essential to keeping the sequence of AD changes consistent. If two DCs try to use the same identifier the whole system collapses in a screaming heap. – Harry Johnston Jul 23 '12 at 05:27
  • Additionally, note that it is not safe to promote a cloned server to a domain controller. If an instance of Windows is going to be a DC, it *must* be installed via Windows Setup. Failing to follow this precaution can cause a variety of very odd symptoms. – Harry Johnston Jul 23 '12 at 05:29

3 Answers3

7

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.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 1
    But ntfsclone and ImageX are image based much like Ghost ... what about file-by-file copy? – ixnaum Jul 22 '12 at 16:20
  • 1
    ImageX does not generate a block-level copy of the disk, it is definitely file-based. (It does, of course, generate an "image file" but this is more like a zip file than, say, an iso.) ImageX is the one and only support way to do this. – Harry Johnston Jul 23 '12 at 05:20
5

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
)
Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • You are right. Junction points are the main problem. From doing more research on this, it's not only AD servers that use junctions. Windows 7 uses them heavily too. Robocopy doesn't know how to copy junctions "Robocopy may encounter Junctions ... These may be Volume Mount Points created using the MOUNTVOL command, or Directory Links created using the LINKD command. Robocopy handles Junctions in the source by creating a normal Directory of the same name in the destination, because it may not be possible to replicate the Junction in the destination." ... Is there a file copy tool can? – ixnaum Jul 23 '12 at 01:44
  • 1
    [here](http://answers.microsoft.com/en-us/windows/forum/windows_7-files/how-to-copy-a-directory-with-all-permissions-and/373353a9-7bc2-468e-ac20-04850c105e3f) is more detail on robocopy failing to copy junctions on Windows 7. [fastcopy](http://ipmsg.org/tools/fastcopy.html.en) can supposedly copy junctions ... will try that next – ixnaum Jul 23 '12 at 01:52
  • 1
    Another potential issue, Windows 7 (probably 2008 also) has a circular junction in each user profile folder under C:\users\\AppData\Local\ for "Application Data". If you run Robocopy using an account with the Backup privilege, or alter the folder permissions, it's possible to go into an infinite loop on that junction. – Greg Askew Jul 23 '12 at 03:17
4

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:.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Chris Griffiths
  • 41
  • 1