Skip to content

January 2, 2012


Deployment Blocker No. 4: Promise to capture all data everywhere

by Shelly Bird

Like the promise to bring all applications over to the new environment, this is a promise that cannot be kept, especially if the users have been running unmanaged, which means they are storing their data—um, where? And does anybody  really know which data is important to keep in these unmanaged or even the managed environments? Not bloody likely.

There is no data transfer tool in the world that can read people’s minds.  And if there was, you probably wouldn’t really want to know what was in there.

Accordingly, there are two methods that data transfer tools use:

Location specific:  Instruct the data transfer tool to go to a specific location, and back up all files there.  For instance, Microsoft’s User State Migration Tool by default will automatically capture all profiles under c:\Users, or C:\Documents and Settings, and (not surprisingly) is excellent at capturing all the preferences of Microsoft products, including Microsoft Office.

Vacuum cleaner:  based on a list of file extensions you give the data transfer tool, it hunts through the entire disk, or disks, to find those file extensions no matter where they exist, gather them up, and dump them into a new target directory.

The problem with the location specific approach is that in unmanaged environments, where each individual user has the ability to save anywhere they want, you don’t really know which locations to direct the data transfer towards.

The Vacuum Cleaner approach is effective, but you have to know what file extensions you have to  capture—and if you don’t really know much about the applications users are running, you aren’t going to be able to guess what those file extensions are (see mind reader comment above).  The vacuum cleaner approach can also produce an exceedingly messy result on the other end.  The target directory on the
new system can be organized with the same file folder structure the original file was discovered in upon the old system, and this is helpful, but it is still rather confusing to many users.

Worst of all, regardless of which method (or both) is used, application preferences may get lost if you don’t capture them too.  It is not always blazingly obvious where those files or registry entries are, it can take quite a bit of research to track them down.

Then there are certain customers that do have legal or contractual requirements to maintain data for extended periods of time.  But even in those situations, I have occasionally discovered that the regulations are a lot less onerous than the lawyers’ interpretation.  People who are unfamiliar with the tools think it makes sense to gather up everything “just in case”, not realizing the huge hit to time and storage this will cause.

The point is please don’t promise the moon here, because users will inevitably be disappointed somewhere along the line.  Until you get to a managed environment, you cannot in conscience guarantee capture of all the data.

A Better Way:  Set expectations with the users up front, and push as much of the data backup and cleanup responsibility toward them.  Only they know where their important data is, so work with them to help them put where the data transfer tool will capture it.  Also, after identifying all applications that will be moving to the new environment, research where those applications store personal preferences and what their data extensions are (e.g. *.trm).  If an application is poorly written, and it has user’s preferences for the application configuration stored in the system or Program Files directories rather than the users’ own profile, you’ll have to dig that fact out application by application.  Finally, use file copy technology for the image, so you can move data in place on the local partition as you wipe and load to the new system, rather
than being forced to move it over the network to a remote location.  I’ll write more on this shortly in another blog; this is a huge time saver and limits the risks of massive data transfers.

This is part of a ten part series of blogs “Top Ten Deployment Blockers”

Read more from Uncategorized
2 Comments Post a comment
  1. Drewfus
    Jan 26 2012

    “The problem with the location specific approach is that in unmanaged environments, where each individual user has the ability to save anywhere they want, you don’t really know which locations to direct the data transfer towards.”

    ‘Anywhere they want’, essentially means anywhere on C: drive. If the profiles directory were to be moved to another drive (ex: D:\Users), then C: drive could be hidden in Explorer. This would greatly limit (effectively) the number of odd places that users could save data. However, your last blog indicates that you don’t support partitioning drives and configuring systems in this manner.

    • Mar 21 2012

      Anywhere they want could mean anywhere, on the C: drive, on another drive, on and on. Trying to hide C: in explorer is harder to pull off than you would think. Just hiding something from a user’s view doesn’t mean the applications understand that no data should be stored on the C:\ drive. Then there are the applications get very upset, kicking up errors, when it can’t find something that is normally there out of the box, or, as was the case with several of my customers, when permissions are blocked to things that are normally available. For instance, this is the reason we still have Power Users as a kind of an empty shell of a group, for legacy reasons: so when an application checks for that, it is there. In my experience, it simply doesn’t pay to start changing these things. I’ve noticed that even if people have no problems initially, eventually something pops up, usually when they are trying to move on to the next version. Stick to the middle of the road, and concentrate on saving yourself time and effort for other more important things, is the general rule of thumb.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: