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)
Best Answer
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:
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:
You can use the following script in a file to get a an output of the links for a location (for example, systemroot):