I was on-site last week with one of our large Systems Integrator partners and they asked what recommendations we had for organizing the devices within the Provisioning Services console. Of course, working for Worldwide Consulting Solutions, I answered, “It depends”. Seriously, though, I reviewed their proposed XenDesktop design from a Provisioning Services view and developed a model which would work well as a XenDesktop farm scales. Keep in mind that this suggested organization is based on their design. Your design may work better with a different organization methodology.
Since the organization is design-dependent, before explaining the Provisioning Services organization model, let me share with you the XenDesktop design that will be used for this model.
The design discussed here is referred to as the Modular Management (MM) design and the architecture is based on building a single XenDesktop farm out of smaller self-supporting Desktop Delivery Modules (DDM). Each DDM contains a group of virtual desktop hosts, a block of shared storage, and a set of provisioning servers to support the number of desktops hosted. This design also provides smaller units that can be managed through delegation. For the purpose of this blog, the example DDM contains four provisioning servers organized as a single site for fault tolerance, 20 XenServer hosts, and shared storage on a SAN. The diagram below provides a visual representation of a single DDM.
Taking that DDM structure and replicating it multiple times within a single XenDesktop farm provides a scalable platform for large XenDesktop installations. The multiple DDMs can then added to an existing XenDesktop farm infrastructure which would include Desktop Delivery Controllers, a Citrix license server, a clustered SQL database, and pair of Web Interface servers. The diagram below provides an example of what this Modular Management design might look like at the farm level.
Changing gears, a Provisioning Services farm is separated into several logical partitions that can be used to adapt to almost any environment. The highest logical partition is the farm. Within a farm are common components such as a SQL database server, a Citrix license server, a PXE server, and usually shared storage for vDisks, such as a SAN. Farms are partitioned into one or more sites. Each site contains provisioning servers, device collections (groups of target devices with common characteristics), and vDisk pools. The diagram provides a visual mapping of the different partitions and their relationships.
One of the reasons Provisioning Services was redesigned was to allow delegated administration at each of the partition levels. Most customers have a separation of duties between farm administrators, server administrators, desktop administrators, and help desk personnel. With this new partition design, the permissions can be granted at the farm, site, and device collection level. The delegation of duties in a customer environment will influence the design. The design in this blog supports delegated administration at all four levels: farm, server, desktop, and helpdesk.
Now all the core architecture is understood for both XenDesktop and Provisioning Services, we can begin to look at the organization of the items within the console. To simplify this, we will focus on a single XenDesktop farm that has three DDMs: DDM 1, DDM 2, and DDM 3 (Notice the space in the name of each DDM to distinguish the XD DDMs from the provisioning services objects which are named without the space). Each of these DDMs supplies a different operating system image. DDM 1 supplies Windows XP desktops, while DDMs 2 and 3 supply Windows Vista and Windows 7 desktops respectively. In the XenDesktop Access Management Console (AMC) the administrator has configured three Desktop Groups: Windows 7 Desktops, Windows Vista Desktops, and Windows XP Desktops as seen in the screen shot below.
Ideally, a single Provisioning Services farm is used to support a single XenDesktop farm, such that you have a 1:1 mapping between the two farm types. In the screen shot below of the Provisioning Services console, depicts the Provisioning Services farm name (XenDesktop3) that matches the name of the XenDesktop farm name as shown above.
The screenshot above shows clearly the different objects available. Below I will discuss each one and explain how it maps to a DDM for management.
Sites: Sites are created in the Provisioning Services console for each of farm DDMs. The sites names will correspond to a single farm DDM. In the example, the site names are DDM1, DDM2, and DDM3 per our farm architecture above. In other words, in this configuration the terms site and DDM can be used interchangeably when referring to objects within the Provisioning Services console.
Servers: The provisioning servers that are assigned to service a single farm DDM are then added to the appropriate site DDM in the Provisioning Services console.
Device Collections: Device collections contain all the target machines that are delivering a specific desktop image. Group similar images into a one device collection such that the entire group can be managed as single entity. This grouping will simplify management later when images need to be versioned or updated. In the example, since DDM 1 is responsible for delivering only Windows XP images, a single device collection, named Windows XP Desktops in the screen shot, can be used for all the hosts in DDM 1. If DDM 1 had multiple images being delivered, then multiple device collections would be created.
Stores: vDisk stores are created for each of the DDMs: DDM1, DDM2, DDM3. The vDisks are then added to or created in the store for the DDM. The key here is that the corresponding servers in the DDM are assigned to the vDisk store so the vDisks are visible within the site. In the example, the DDM1 store would have the four provisioning servers assigned to DDM 1 would have check marks next to their names for that store. This will allow any of the provisioning servers for the DDM to serve up the vDisks contained in the store.
vDisk Store: The vDisk pool will include all the vDisk images that will be used by a site and shared among the provisioning servers supporting the DDM. The vDisk pool displays any images that are managed by a server in the site. In the example, vDisk pool DDM1 would contain the Windows XP images used for DDM 1 and Windows XP Desktops group. Likewise, vDisk pools DDM2 and DDM3 would contain their respective images for Windows Vista and Windows 7.
Keeping DDMs at the site level will allow administrators to leverage the partition-level delegated administration of the Provisioning Services console. Server administrators can be granted permissions over the DDMs they manage at the site level. Desktop administrators can be granted administrator permissions for the devices they manage by assigning them to device collections. Help desk personnel can be granted operator permissions on the devices at the farm, site, or device level. From a higher perspective, desktop farm administrators can be granted permissions for all the farms managed. The best part is that if an administrator has multiple farms to manage, they can use a single Provisioning Services console to manage all of them.
I hope you found this information useful. Follow me on twitter @pwilson98 to keep abreast of design and architecture tips for Citrix XenDesktop, Provisioning Services, and Password Manager (SSO) products.