XP end-of-life is among us, and I am being booked on several OS deployment projects to get ready for this! One of the most useful features available in MDT and SCCM is hardlinking– the ability to run a USMT scanstate/capture and keep the files local on the actual system being migrated instead of shooting them up into network storage.
There’s some great advantages to using hardlinking. The biggest is that USMT data, when captured, is stored on the local drive instead of the SCCM State Migration Point. Think of it as being set aside on the drive. The hard drive of the migrated system won’t actually be erased, but “wiped” in SCCM terms. Basically, everything except the USMT data will be erased. The SCCM task sequence will put an OS back down, and then USMT loadstate will move the migrated files back into place, making for a really quick migration! You don’t have to worry (as much) about network bandwidth, SMP space, or concurrent deployments, because everything is done local.
There’s some inherent risk, though. With data being stored locally and not backed up on a server, it’s more severe when a task sequence fails. I’ve hit a couple of these- sometimes hard drives are corrupt, but you wouldn’t know this until you’re in the middle of the task sequence, usually the Apply OS stage. When this happens, recovering the data may be very difficult, or at least very manual. You should really test and trust your task sequences when using hardlinking!
Another negative of hardlinking is that you won’t be able to run it on an encrypted drive. If you have BitLocker or another disk encryption product, you must decrypt the drive first, then you can stage the partition with a WinPE boot image and proceed with your hardlink deployment. Usually, the easier alternative to this is to have 2 separate task sequences: one that does a USMT scanstate/capture only within the booted OS, and then a second that you load from boot media, where the drive is erased, an OS is deployed, and the USMT loadstate/restore is run to bring migrated files back down from the network. Decrypting a drive usually takes so long that this is the easier alternative.
Shortly, I will post the step-by-step configuration for one of these hardlink task sequences, so you can enjoy them in your environment.