Citrix Developer Network
The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
Citrix Ready
Share ideas and integration techniques with Citrix Products and our Alliance Partners.
Blogs
Learn the latest from the Citrix employees who are
building application delivery infrastructure technologies.
Blogosphere
The Citrix Blogosphere is a window into the thousands of conversations
taking place about Citrix and Application Delivery.
The XenDesktop Setup Wizard allows an administrator to quickly create a pooled desktop group with virtual desktop VMs for their XenDesktop environment. I wanted to share more information on what the XD Setup Wizard does along with promoting it as we have had several customers unaware of the benefits of this wizard. If you are going to create a desktop group of pooled desktops then you should seriously consider using the XD Setup Wizard as it will save you a tremendous amount of time. Trust me on this as I needed to create 300 virtual desktops on VMware ESX two years ago which led to me creating this wizard. But I will save that talk for another time.
First let's cover the prerequisites and initial configuration...
Before the XenDesktop Setup Wizard is run you need to have a virtual desktop VM template and a base OS image (aka Provisioning Server vDisk). For detailed setup information on how to accomplish this please refer to the XenDesktop Getting Started Guide. This guide describes the configuration for the XD Setup Wizard as well as the other components of XenDesktop.
When you create your virtual desktop VM template you specify the VM hardware parameters for your base virtual desktop VM. When the XD Setup Wizard is run it reads this VM configuration information and then creates X number of VMs using the same virtual hardware configuration. For example if you created a VM on XenServer that has 512MB of RAM, 1 virtual CPU, 1 virtual NIC and no virtual hard drive all your new virtual desktop VMs would have that same configuration. Keep in mind that you do not need to have a nice round number in terms of RAM. You could try using something like 460MB of RAM per desktop to try and squeeze one or two extra desktop VMs per server. Of course that would only help if RAM was your bottleneck. No virtual hard drive for the VM is possible because Provisioning Server (PVS) dynamically streams the base OS image to the VM which does not require a hard drive in the VM.
However, in advanced cases you may want add a virtual hard drive to the VM that will cache information from the streamed base OS image. This virtual hard drive will be used as the write back cache for the Provisioning Server (PVS) base OS image and will typically be 1 to 2 GB. Whether or not you want a virtual hard drive depends on your network configuration and storage. By moving the write back cache off the network storage that also has the PVS base OS image you reduce the load on your network storage and you balance your network load. However having your PVS base OS image and the write back cache for each desktop on the same storage device makes the configuration easier and can result in better storage utilization. These are some of the trade offs to consider when you want to have virtual desktops deployments for thousands of users. If you need to scale your virtual desktop environment to over a thousand users email me at sunil.kumar@citrix.com.
When you create your virtual desktops you will be asked for the base VM template, the base OS image (Provisioning Server virtual disk), the base host name along with the number of virtual desktops to create, and the name of the desktop group. In our case let's use
"CXD_VM_TEMPLATE" as the base VM template
"CXD_IMAGE" as the base OS image
"CXD1, CXD2, ... CXD100" as the name of the virtual desktops.
"CXD_GROUP" as the desktop group name.
You will be asked for all this information when you run the wizard to create a desktop group. The attached video walks you through this configuration.
Now let's look at what happens when the wizard starts creating virtual desktops ...
Step 1: Connect to the hosting infrastructure and create new virtual desktops
The XD Setup Wizard connects to the XenServer resource pool via the master XenServer. It instructs XenServer to create X number of VMs. In our case we created 100 VMs. A new MAC address is created for each VM that corresponds to the virtual NIC for the VM. The XD Setup Wizard stores this newly created MAC address for each VM along with the host name specified (CXD1, CXD2, ... CXD100). The XD Setup Wizard uses the first MAC address for the VM if multiple NICs are used. However I would avoid this configuration because bad things could happen if you try it. Well actually the worst that could happen is that your virtual desktop would not boot, but because of the complexities of having multiple NICs I would avoid this configuration unless you could not live without having multiple NICs. We now have 100 VMs created with the XD Setup Wizard storing the host name for each VM along with the MAC address.
Step 2: Configure virtual desktops in Provisioning Server
The XD Setup Wizard adds a target device in Provisioning Server for each of the virtual desktops. The client name for each of the target devices is the host name. When the VM boots it replaces the host name of the base OS image with this client name. Each target device is uniquely identified by the MAC address which is why we stored the MAC address for each VM in the previous step. Each target device is then set to boot from the specified base OS image (CXD_IMAGE). In addition Provisioning Server adds each target device to active directory. You can either let the XD Setup Wizard add computers to the default location or you can specify a custom OU. We now have 100 provisioning server target (client) devices that correspond to each of the VMs created in the previous step.
Step 3: Add virtual desktops to a new Desktop Group in a Desktop Farm
The wizard now creates the new desktop group we called "CXD_GROUP". The 100 virtual desktop VMs created above are now added to this desktop group on the Desktop Delivery Controller (aka the Connection Broker or DDC). The DDC identifies each of the VMs by their AD host name, but when the VMs are added the DDC can only see the VM name and UUID (Universal Identifier). The wizard knows the host name for each VM so it informs the DDC of this automatically. Otherwise the administrator would need to manually associate each VM name / UUID with its corresponding AD host name. We now have a newly created desktop group with 100 virtual desktops.
Readying the desktop group for use
Once the desktop group is created, the Desktop Delivery Controller takes over and starts the initial setup for the desktop group. This includes starting the idle virtual desktops. These idle desktops are used to quickly connect a user to a virtual desktop because the virtual desktop is already running and only the profile needs to be applied when the user logs in. The DDC informs the XenServer resource pool to start a virtual desktop VM. When this virtual desktop is started it streams down the base OS image using the Provisioning Server component. The virtual desktop loads the Virtual Desktop Agent as part of the OS boot process which then registers with the DDCs in the XenDesktop farm. The desktop group is now ready!
In addition to the XenDesktop Setup Wizard automating all of this for you it only takes seconds per desktop. Are you now convinced to use the XenDesktop Setup Wizard as opposed to doing everything manually? You can now run the XD Setup Wizard again to either create a new desktop group or add new VMs to an existing desktop group. To modify advanced options of the desktop group such as idle pool settings you can run the Access Management Console on the DDC.
The button was removed because we did not have a reliable way of storing the relationship between the virtual desktop VMs and their provisioning server client entries without requiring this information to be stored in a file or groups of registry keys. This would also force the administrator to delete virtual desktops from the same computer where the wizard was run to create virtual desktops. I requested a few changes to the next release of Provisioning Server (PVS 5.0) which were accepted that will allow us to store this association. Our product development team is currently looking at how to resolve this issue and may find a more creative way to solve the problem. The bottom line is that we recognize the need to delete groups of virtual desktops and we will be addressing this issue.
Sure, I'm convinced that the wizard knows best. But still, Workflow Studio could give us some "flex" during creation. The strength (and weakness) of wizards is that they do "something" very well, but are closed processes. Thank you.
We wanted to minimize the number of items to install in order to create virtual desktops and to make creating groups of virtual desktops as easy as possible. But I definitely agree that Workflow Studio can provide many more options for administrators. Bigger customers and partners may want to leverage Workflow Studio to create virtual desktops on demand as part of the new employee process.
When will we see the ability to use VMWare VI3 with XenDesktop Setup Wizard? In addition to the API, the PowerShell toolkits for VMWare could easily be leveraged for this immediately. I'm surprised someone hasn't created one in the community yet to perform the same function to handle this enormous shortcoming.
Have you found 512MB to be enough for a desktop os? What apps do you run on such a VM? If it is all XenDesktop apps, what is the point of using a VM? Is there a good resource you can point me to for such questions? I want to sell XenDesktop but the memory utilisation is the biggest issue. I can't justify the hardware (RAM) to support hundreds of XenDesktop VMs over a couple of XenApp servers...
For WinXP 512MB of RAM is enough for a desktop OS, but you will want more for Vista. I would run as many application as possible hosted via the XenApp for Virtual Desktops component in XenDesktop to minimize the RAM required for each VM.
XenDesktop is designed as desktop replacement. As such it provides items such as administrator like control of the desktop, native client OS interface (WinXP or Vista), and increased user personalization. If your customers do not need any of this functionality I would stick with XenApp. However I have found a large number of users that need more functionality beyond what a published desktop via XenApp provides. XenDesktop is targeted at this user group that previously required a desktop PC.
After the virtual desktops have been created, can you go back in and change their memory settings without issue. I tried that in an esx 3.5 environment and changing the memory setting in the virtual desktops properties yeilded a blue screen when we launched the desktop.
You can go back in and change the memory settings for both pooled and assigned desktops. However for pooled desktops you will want to change the memory settings for all virtual desktops in the desktop group.
I wish there was a way to remove or change the name/prefix seperator (e.g. DESKTOP1 instead of having DESKTOP_1). This does not work in accordance with our DHCP template (we use QIP). Is there any plan to add the functionality in the future?
The XenDesktop Setup Wizard in the next release of XenDesktop will remove the underscore "_" when creating virtual desktop VMs. If you need more functionality beyond that such as reading hostnames from a file or typing them in a list let me know. This is a feature we are considering for a future release and feedback from customers and resellers such as yourself helps us determine how and when to add this functionality.
Posted by 
Great blog...At one point, there was a delete desktops button during the TPK...any thoughts?