Skip to content

December 11, 2011

4

Deployment Blocker No. 5: Separate partitions for applications and/or data

by Shelly Bird

Some of my customers swear by the value of having separate logical partitions on their desktops.  Typically, they want to establish two partitions, one for the system files, and one for the data.  Some customers go so far as to separate applications and program files from system files, upon a third partition.

I’m not convinced there is any value in this, and rather doubtful there ever was.  The argument for partitioning rests mainly on two ideas:

1)   Security will be improved because you can protect the valued assets (data or executables) more easily:  one protects the partition with additional file permissions

2)   Deployment will be easier because you just wipe and load the system partition, leaving data in place.

Back in Windows NT days, there was indeed a slight security advantage.  The Anonymous SID included the Everyone security context, and this was potentially dangerous.  However, starting with XP SP2, this issue was eliminated.  With Vista and Windows 7, file permissions tightened up to the point where it is probably a lot more secure to keep everything on the same partition.  The main problem is when people start shifting things around in order to partition, then someone has to start to playing around with file permissions.  This is where the human element leads to inevitable slip-ups.

And what about the argument that multiple partitions simplify deployment?  This one always floored me, because in my experience it greatly complicates deployments.  There are a host of issues, but I’ll summarize the two top assumptions behind this argument, and why I don’t think they hold much water:

  1. Application and data information can be neatly sliced and diced into their respective partitions.  I wish this were true, but current standards don’t force developers to be so careful.  Unfortunately, it takes a lot of research with each application to determine precisely where the application information, preferences, and key files are stored.  Data keeps popping up on the system drive, hard coded by those legacy and even newer applications which barely acknowledge Windows profiles exist.  Your packagers will be spending a lot of time on all the little details that this partition decision kicks up, time that would be better spent upon developing packages more quickly and securely.
  2. System partition can be wiped and new operating system loaded, and everything just works.  No, sorry.  Again, I wish this was true.  All the applications need to be re-loaded and re-tuned because the load information is in the registry, not just in the Program Files folder.  Profiles have to be primed to point to the new data location.  Oh, and your users had better be running with User not Administrator rights, because otherwise you’re going to have no idea where the data and applications are really stored.

Additional partitions come with a lot of hidden support costs and do not guarantee a clear security boost.  They add a lot more work for packagers and support personnel.  It leads you down the path of an exceedingly custom-crafted solution for the enterprise, which is always an invitation for trouble.

I’ve also observed multiple partitions leading to unexpected incompatibilities with updates, with the installation of new applications and even key components of Windows, including remote access.  This led to unnecessary fire drills for that already overworked packaging teams, who had to jigger applications that would have worked right out of the gate, had the partitioning NOT been added to the mix.  Try hard to resist the temptation to partition.

The better way:  Once you get to managed desktops, you can start identifying important data, and work with your users to extract and move it into a private or public cloud.  Use application virtualization to distribute your applications wherever possible, to decouple the applications from the system and stream them from a centrally controlled point.  Voilà:  partitioning the smart way.  Just understand it takes some time to move any traditionally organized enterprise to that model.

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

Advertisements
Read more from Uncategorized
4 Comments Post a comment
  1. Dec 12 2011

    Hi Shelly – just to add that the Windows 8 could also block upgrades from Windows 7 with two partitions to Windows 8! I did find the info within the Win8 Dev Preview documentation but cannot find it again! Maybe your MS colleagues will be able to dig it out?

    Regards,

    Sunny

    Reply
  2. Dec 12 2011

    Sorry really meant to say “if Users folder is on a different drive e.g. D vs system files” then upgrade may be blocked – anyhow, why complicate things? I ue the Keep It Simple Sunny method!

    Reply
  3. Alex
    Dec 20 2011

    You use the term “packaging teams” what does this mean? I am assuming it is the group of people who set up to deploy your software. I googled it and found nothing related to IT.

    Reply
    • Jan 13 2012

      Thanks for the question. I wasn’t clear about the definition. When I say packaging team, I mean the people who actually construct the installation package for an application, including all the configuration changes the customer wants, such as preferences as to where the application stores it data, things like that. Most customers have at least one or two people doing this work, usually using Wyse Installer. There are a number of companies I know of who come in and do a massive number of applications, such as Compucom and Flexera (former AdminStudio). Flexera has a neat little automated method to package up MSIs and other executables, to speed their service. Basically the goal of the packaging team is to provide an application that is self-installing, can be pushed and applied non-interactively to the desktops or servers, as needed. They are often also packaging up the updates to those applications. Usually packaging team is associated with or sits near the deployment folks (the SCCM, Tivoli, and Altiris types), but they tend to have their own peculiar identity. It takes a special type to do this kind of work, someone very familiar with the innards of the systems (registry, files), scripting, and one step to the side of a dev.

      Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

You are commenting using your Google+ 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: