Introduction

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.

Why Citrix?

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.

XenDesktop
(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. 

Scenario 1:

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) 

  • At the District Office we have a virtual server that handles Remote Desktop CALs as well as Citrix licenses for all schools.
  • Each school has one XenServer that is configured with two virtual servers. click here for server details
    • One virtual server is setup for Provisioning the hard drives of each of the client machines.
    • The other virtual server is setup to publish the desktop to each client machine.
  • Each client machine is configured to pxe boot to the provisioning server where the shared drive image resides (Windows XP).
    • The XP image used by the client box is configured with a custom script that is launched on startup, and is set to connect directly to the XenApp server and automatically log the client in with a preconfigured user and password. In the background, the custom script monitors the XenApp connection, and is set to shut the local client machine down when that connection is no longer there.
      This means that the end-user will have no interaction with the local XP image. The published desktop is running when they start the machine, and they hit the power button, or hit Start>Log Off (there is no shutdown option for a remote session) on the published desktop and the machine will automatically shut down.
Scenario 2:

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.


Coos Bay Public Schools

Webpage Questions or Comments?

* For notice of Non-Discrimination and contact person for
Title II, Title IV, Title VI, Title IX, Section 504 and/or Perkins, click here *