This article provides detailed information about our rollout and implimentation of Citrix. Please keep in mind that our utilization of each Citrix product is based on our understanding of each Citrix product, how we are already using thinclient, and how each Citrix product could work for us. As our understanding and experience with each product grows, we will definitely adapt our implementation accordingly.
Toward the end of the 2009-2010 school year, the majority of our non-thinclient computer labs had machines that were getting older and couldn’t run the latest OS (Windows 7). It seemed more advantageous to push forward with our thinclient project (click here for more details on that project) than spend a lot of time and money in new/refurb machines and end up in the same boat in a couple years.
That said, there were a couple of hurdles we had to overcome.
1. utilizing a Linux kernel on the client-side meant that there were a lot of USB Flash drives that weren’t supported, especially if they had any kind of security software enabled.
2. There is a huge delay between the audio and video with streaming any kind of video content in Terminal Services on Server 2003. The release of Server 2008 r2 gives us the ability to stream over what is now called Remote Desktop Services. Unfortunately the Thinstation kernel can’t support the new version of Remote Desktop.
Having a working thinclient environment gave us a wealth of information in regards to usage and server saturation each school (site) could encounter.
Taking all that into consideration, we did a lot of research, and found that Citrix offered everything we were looking for, and then some. In addition, Citrix being a partner of Microsoft, the licensing scheme meshed well with our Microsoft Campus Agreement.
Understanding what Citrix has to offer
* This was our first major hurdle. *
Following is a layout of the major Citrix products we are looking at.
(we aren’t using
at this point)
Set up a single virtual desktop for each user
Benefit: Assign resources to each vm.
XenApp Publish an application or desktop for many users.
Benefit: Resources are shared by each connection. This will allow a lot more users to access the server at the same time.
Provisioning Services All similar computers can share the same network-based hard drive. Benefit: Many similar machines can share the same provisioned hard drive, reducing imaging time
Our Rollout – Getting down to details
When we re-evaluated the needs for our student machines. we realized there were two scenarios we needed to address.
We had a lot of machines that just weren’t powerful enough and/or couldn’t support the latest OS (Windows 7). Among the Citrix products we looked into, both XenDesktop and XenApp would have worked. We ultimately decided to go with XenApp for one primary reason:
With XenApp, all machines that connect to a given server/farm share the resources of the server. That means that we can potentially get more connections out of one server than if we allocated 1 or 2 gigs of memory for each connection like we would using XenDesktop.
Details of Scenario 1 (Citrix XenApp)
The machines that are in the majority of our labs have the resources to run Windows 7 natively. It seemed like a waist of resources to use these machines as a dumb terminal to connect to a XenApp server. However, leaving them running locally meant a lot of work every time a change was needed to the lab. Citrix Provisioning Server fits this bill perfectly.
Provisioning Services works by storing a “shared” drive image that a group of similar machines can all use. Imagine taking the hard drive out of the local machine and putting it in the Provisioning Server, then converting the hard drive cable for a network cable. That’s in a nutshell what Provisioning server does. Here’s a brief overview of how it works:
First you must build a machine with the OS and apps you want for the lab. Once you have it built, you install an app that takes an image of the machine and copies it to your Provisioning Server. At that point, the image is only available to that machine.
Next, you lock the image down so it can be shared by many.
Finally, you set each client machine to pxe boot, which then gets its bootup instructions from the Provisioning Server.
That means that if a change needs to be made to the lab, it just has to be done to that image, not on all the machines in the lab.