Deployment Blocker No. 5: Separate partitions for applications and/or data
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:
- 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.
- 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”