users have the same Start screen, same capabilities, and same ability to run the same
applications, and each user can still have a unique IP address (a feature of RDS that
enables IP virtualization, giving each session or a specific application within the
session a unique IP address, required for some applications). The same RDP protocol
is used to connect to both environments, which means the same client devices can be
used. User settings and data virtualization plus application virtualization can and
should be used with both session virtualization and VDI.
The key difference is that with session virtualization, each user has their own session
on a shared operating system, while with VDI each user has their own operating
system instance. Fundamentally, the difference is in the level of isolation users have
from other users. I think of session virtualization as being many people sharing an
office, each having their own cubicle, but because they share a room, they have to
behave, can’t sing loudly, or run about changing the office because it would affect the
other users sharing that office. They can do their work in the cubicle and customize
their cubicle with pictures on the cubicle walls. I think of VDI as each user having
their own heavily padded office; the users can run around, bouncing off the walls
screaming, and they won’t affect users in other offices.
Session virtualization is a good fit for task-based workers who run things like Internet
Explorer, Office, and line-of-business applications but who don’t need to customize
the operating system. They can still perform customizations of their desktop
wallpaper, shortcuts, and applications. A user in session virtualization needs to be
locked down so they can’t install and uninstall applications or reboot the operating
system, which would affect everyone else on the server.
VDI is a good fit for power users, for developers, or for users who run applications that
will not run on a server operating system. Basically, if the user needs to modify the
operating system or reboot the operating system, then VDI must be used. If you ever
hear someone talking about using VDI but needing to heavily lock down the
environment because it’s being used for task workers who shouldn’t change the OS,
then they should probably be using session virtualization instead. If there are
applications that run only on a client operating system, which is rare, then VDI would
also have to be used.
This is why often you will see a mix of session virtualization and VDI being used—
specifically, session virtualization for most of the user population and VDI for those
power users. The next question is, “Well, wouldn’t VDI work for everyone? Why use
two solutions if VDI works for all?” That brings us to the other differences between
session virtualization and VDI.
Session virtualization uses a server operating system that hosts large numbers of
sessions for many concurrent users. This could be hundreds of users on each session
host, depending on the applications being run and the amount of memory needed.
Each session may use a couple of hundred megabytes of memory, assuming a fairly
heavy application workload for each user. If I have a server with 64GB of RAM, I can
probably get around 300 users on that box. That’s one operating system instance with