Understanding How MDT 2010 Automatically Determines a Backup Location

I’ve always wondered, since I first saw MDT’s deployment wizard,  how exactly it automatically selected a location. Having someone else do my work is nice when needed, but I disliked the idea of not knowing specifics. I never knew exactly what to expect! The documentation in several places never really cleared this up enough for me. So I spent some time with the code to decipher the pure logic of this. The code is mildly commented, but I found I really had to understand the code to get the feeling of it.

I will be discussing the computer backup portion (mainly ZTIBackup.wsf) of the wizard and its logic here. The backup user settings uses a completely different code file, however I believe it would be somewhat safe to assume the essential logic is the same.

Deployment Wizard

It all starts here at the selection: ‘Automatically determine the location’. When working with the Automatic backup selection, this will carry forth one of two options to the code: AUTO or NETWORK. You’re likely already familiar with these values, as this selection is essentially just setting the ComputerBackupLocation variable. All the checkbox for using a local backup is doing, is swapping the value between AUTO and NETWORK. Similarily, the other backup screen for user settings uses the comparable variable: UserDataLocation. Check MDT’s help file out for any variable reference to get a good idea of their purpose.

Determining What to Backup

When the code is reached it must figure out what needs to be backed up.  It does this through a various set of attempts. Once it finds anything, it skips over remaining code and continues to the next section. It looks for a single drive.

1. First it looks to see if you have BackupDrive set within CustomSettings.ini or the Deployment Database. If not it checks to see if you filled out the similar variables BackupDisk and BackupPartition.
2. Uses DestinationLogicalDrive variable if set, which is essentially the drive you are deploying to.
3. Nothing still? Then it loops through all fixed drives until it finds a drive that contains \windows or \winnt. It excludes x: drive which would be the PE ram-drive.

Determining the Backup Requirements

The script then loops through the drives to figure out the total file usage. It loops through every drive, however it appears it will only use the destination drive as a backup store — unless you have BackupDrive set to ALL. During each drive test, if passed, it will add the total size of the data on it that needs to be backed up. The requirements to add to this value are below:

• Must be a fixed drive (no cdroms, usb drives, not a ram drive)
• Must be in a ready state (in the odd case the fixed drive is no longer available)
• Must be formatted
• Must be the same path as the drive being backed up UNLESS BackupDrive is set to ALL.

Now that the total size is known, it compares it against the drive that currently contains the MININT (StateStore). If the drive has more available space than the backup total size, the script has determined it can use the local path.

Figuring out the Paths and Additional Logic

After all this, MDT still needs a bit of working out the path to store to, though the bulk of it is done:

• If its a deploymenttype of NEWCOMPUTER, REPLACE, or CUSTOM it forces the local store to not be permitted.
• Assigns network store path if set via BackupShare and BackupDir.
• Confusing piece here for me, but here’s a shot: If using SCCM, it sets thet network store path to OSDStateStorePath or to the StatePath (not quite sure on the workings of StatePath as I do not use SCCM, using MDT StatePath resolves to the MININT folder). If USMT sees that there is not enough local space for USMT (see USMTLOCAL) it will deny local usage. USMTLOCAL will be set to true if the earlier section (backup requirements) found it had enough space. Though I suspect it may be true even if the earlier section failed to find enough space, as this variable is also governed in ZTIUserState.wsf.

Wrapping it Up

By now the script is set in its ways. It does some reporting (if you look into your logs there is a fair bit of reporting that helps understand all this better). The reporting is simply:

1. Allow Local Set (“AUTO”): If it has determined enough space and found space to use, and then the additional logic did not deny local backup, it will confirm it can use the local path. Otherwise at this point were using the network path.
2. Allow Local Not Set (“NETWORK”): If there is no network path set by this point it will error out here and not continue. This can happen if local backup is not possible, and there is no BackupShare/BackupDir set or if SCCM doesn’t get it filled with its OSDStateStorePath.

To finish it off it validates everything to ensure it will work smoothly, and then follows up with the commands.

That Was too Much Work

But well worth it. It’s nice to now have much more of a grasp on how exactly this works. If you have anything to contribute on creating more clarity for this article please post. I don’t have experience with SCCM so I can’t guarantee I understood the code completely!