Here is a little secret… Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase greatly.
You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is supported on a standard set of controlling components all running on some type of hardware combination.
So why is desktop virtualization so complex? Because we made it that way by believing that every deployment must start from scratch.
Think about if you were going to have a house built. You would start with a high-level blueprint. The first thing you do is figure out what type of house you want built: a rambler, split level, 2-story, etc., but it will have the same fundamental components (HVAC, electrical, plumbing, framing, roofing, etc). However, the first things you think about shouldn’t be the electrical wiring. It would be insane to start here because you don’t even know where the walls are going to be located that will contain the wires. So tell me why when doing desktop virtualization do people start with storage or servers?
This is why we have a XenDesktop 7 blueprint. To guide you on your way towards creating a desktop virtualization solution, every XenDesktop 7 solution has 5 parts:
1. User Layer – Defines the unique user groups and overall requirements.
2. Access Layer – Defines how each user group will gain access to their resources with a focus on secure access policies and desktop/application stores.
3. Resource Layer – Defines the virtual desktops and applications assigned to each user group
4. Control Layer – Defines the underlying infrastructure required to support all users accessing their resources
5. Hardware Layer – Defines the physical implementation of the overall solution
This is the framework to understand how all layers build upon the previous layer. When you begin to develop your solution’s conceptual architecture, it begins to resemble the following:
As we work through the layers in future blogs, we will see how this structure will take shape and what decisions you really need to make.
Daniel – Lead Architect