Wyse unveiled the “Xenith” thin client device last week at Synergy.  And unlike Wyse’s other thin client devices for Citrix that run Windows XPe or Windows CE, the “zero” client runs an ultra thin firmware (<5 Mb).  This thin firmware means the device boots up instantly and has minimal management.   A demo at Synergy last week showed the thing boot up in less than 5 seconds.  What else separates the Xenith from traditional thin client devices?   Full HDX support including HDX MediaStream (including Flash), HDX Plug-n-Play (USB redirection) and HDX RealTime (bi-directional audio). The expectation being that as Citrix upgrades and improves HDX features in the future, the Xenith’s firmware will be able to be upgraded to provide this support.  Firmware and asset management can be done through Wyse Device Manager and availability is expected in June with a price point at around $330.

The Xenith isn’t out yet, but seems very promising with HDX support, thin firmware, minimal management and an attractive price point.  If a firm is considering a VDI environment with XenDesktop in the next 6 months, the Wyse Xenith is definitely worth a look.

In Q4 last year, Citrix made its NetScaler physical appliances available as a virtual appliance.  Labeled as the “VPX”, the full featured virtual iteration of the appliance dropped its price point and made it more accessible to SMB customers.  Citrix has now made the Access Gateway (CAG) and Branch Repeater physical appliances also available as VPXs.  At this point, Citrix has made three of their ‘core’ Networking products available as VPX appliances, which are recapped below.

Citrix NetScaler VPX

• Released last year in Q4.  Initially, this virtual appliance was only released for XenServer, but now has full support for ESX.  Expected to support Hyper-V in the late summer.
• Licensed by throughput and available in 10 Mbit, 200 Mbit and 1000 Mbit flavors.
• Free “Express” edition with 1 Mbit throughput limitation available for lab and PoC environments.
• Standard NetScaler “Advanced”, “Enterprise” and “Platinum” flavors available.

Citrix Access Gateway VPX

• Released earlier this month.  Currently only supports XenServer. Support for ESX and Hyper-V expected in the next 6-12 months.
• Provides same feature as Model 2010 Access Gateway physical appliance.
• Free “Express” edition exists that provides access to 5 concurrent users that are valid for 12 months.

Citrix Branch Repeater VPX

• Released in Q1 of 2010.  Currently only supports XenServer. Support for ESX and Hyper-V expected in the next 6-12 months.
• VPX Appliance does not support the following features available in the physical appliance:
  • Group Mode
  • Ethernet bypass card
• Still requires Citrix Repeater appliance, which is not available in VPX format.

This week at Citrix Summit/Synergy, Citrix finally revealed details behind their much anticipated client (bare metal) hypervisor.  To recap, for the folks who are not following, this will finally bring “offline VDI” to XenDesktop.  It will also match (and potentially beat) VMware’s current offline VM checkin/check out functionality currently available in View.

XenClient 1.0 will be released later this week for download on MyCitrix and is being demoed and talked about at the conference.  After playing with it at one of the demo stations and talking with some Citrix Engineers, here are some details:

• Unlike VMware’s View, XenClient is a Type 1 hypervisor.  This means it lives above the client side OS (Windows).  Once installed, the user has the option to boot into whatever VMs are available on the laptop.
• At the moment, XenClient will only support a small subset of hardware types.  This includes Dell’s Latitude E series, Dell Optiplex 780, and  HP EliteBook laptops.  Full HCL to be published later in the week.
• Citrix Synchronizer is the server appliance that chats with the XenClient (over HTTP/SSL) to continuously sync and update the local running VM back to the Data Center.
• Synchronizer will be available as a virtual appliance running on XenServer.  According to Citrix, there is no planned version for ESX.  – I am sure this will change though.
• XenClient can be installed as a standalone or in conjunction with “Synchronizer”.
• XenClient supports paravirtualization to allow VMs direct access to hardware (using it’s native driver).  For example, a VM under XenClient can tap directly into a GPU for accelerated video playback and graphic intensive applications.  – This demoed very well with the engineer playing back an HD video file without skipping within a VM.
• At the moment, only a small subset of USB devices are supported through XenClient.

I am at Synergy all week, so I expect to learn more details about XenClient over the course of the week.  If you guys have questions, feel free to post them in the comments and I’ll try to get those questions answered while at the conference.

With Server Based Computing and consolidation becoming increasing prevalent along with the enormous buzz of VDI, I think it is worth debunking some of common myths of XenApp and Terminal Server.  Below are the most common misconceptions that I continue to hear from IT folks today on the limitations of XenApp/Terminal servers that I have debunked from real world experience supporting and working with different terminal server environments.

Myth 1: Application compatibility is a huge problem on Terminal Servers.
There might have been some truth to this myth a decade ago, but in reality this is just not a big problem in the 2003/2008 world.  From my first hand experience, I can say that an application that works on XP will work on 2003, what works on Vista, will work on 2008, etc.  Are there some exceptions?  Of course.  However, these applications are few and far between, yet the “application compatibility” myth continues to circulate. This myth was probably true in the NT/2000 OS where applications did not do a good job of differentiating between “user” and “computer” parts of an installation.  Since Windows XP, application developers have done a better job writing “user” specific information in the user profile and “machine” specific information in Program Files, or HKLM.  I would probably attributed to the “Fast User Switching” feature introduced in XP.  Whatever the reason, this is just not a problem anymore.

Myth 2: Printing is a BIG problem on XenApp.
Historically, printing in XenApp was a big pain.  Managing driver versions, ensuring the appropriate client printer drivers are installed, distorted print jobs, crashing print spoolers.  It was difficult for a very long time… I guess this myth still has legs because of the bad taste left by those old versions of Metaframe and Metaframe XP.  However, since Citrix released the Universal Print Driver (UPD) in Presentation Server 4.0, there is less and less hard evidence that printing is still a “BIG” problem in XenApp.  Furthermore, with updates to the UPD in XenApp 4.5 and 5.0, Citrix has all but stamped out printing/driver problems in XenApp.  Do problems with the Citrix Print Manager service crashing and the print spooler still happen from time to time?  Yes, but not often enough to be concerned about.

Myth 3: The user experience on a Terminal server cannot be configured with the look and feel of a “desktop” OS.
This one is just unequivocally false. I am not sure where this one started, especially because most IT administrators know that Windows Server 2003 is built on the same code base as Windows XP, Windows Server 2008 is built on Vista, and now Windows 2008 R2 is built on Windows 7.  With that out of the way, the “look and feel” of the desktop OS is controlled by the Windows “Themes” service.  This service is disabled by default on Windows Server OS (for obvious reasons).  However, there is nothing preventing an administrator to configure Windows Server 2003 with the Windows XP “Luna” Theme once this “Themes” service is started.  And both Windows Server 2008 and 2008 R2 can be configured with the Aero theme by enabling the “Desktop Experience” Windows component.  Of course these visual upgrades would result in more resources being consumed by the Terminal Server and a slightly lower user density, but it is possible to do.  I have seen this done first hand in a production environment without error.

Myth 4: A crashing process for a user, will impact other users on the Terminal Server.
This myth still gets kicked around a lot.  Specifically, when decision makers are comparing the benefits of VDI over Terminal Servers.  It is typically described or understood to the administrator that “a program or process crashing for one user, will impact the other users running that application on the Terminal Server”.  I am going to say from firsthand experience, this is just not true, at least in the sense it is described above.  And if this was any thread of truth to this, I don’t think anyone would be running Terminal Servers.  Windows isolates processes for users running in their session, so that they don’t impact other users on the server when some process crashes.  For example, if I am logged into a terminal server and kill the Outlook.exe process running under my user context, no other users on the Terminal Server running Outlook.exe would be impacted.  So where does this myth originate from?  I think it is most likely stirred up from situations in which a specific Windows system service crashes or if a BSoD is generated by a kernel mode driver on the XenApp server, which would impact everyone on the server.  These can typically be averted by ensuring hardware drivers/firmware, Windows Server and XenApp are fully updated and patched.

Last month, I posted my findings on the beta releases of XenApp 4.5/5.0 HRP5 for Windows 2003 and the 11.2 Plug-in.  Today, Citrix released the final Citrix XenApp Online Plug-In 11.2 (formally called XenApp client).  See my previous post on more detail on the new features and changes this client; another notable change in this client is the removal of the Program Neighborhood. 

Program Neighborhood (PN.EXE) was primarlily leveraged to create connections directly to XenApp servers (as opposed to connecting through a Web Interface or the PNAgent).  With the removal of the Program Neighborhood, Citrix has made it very clear that they do not want support this functionality.  Fortunately, there IS a way to work around this issue if you decide to upgrade to 11.2 client and are still required to make a connection directly to a XenApp server.  The trick is to create an ICA file. Copy and paste the template below into notepad and substitute the approriate server name denoted below as “servername.domain.com”.  Save the file with a .ICA extension and voilà.  You can now connect directly to a XenApp server with the 11.2 client.

Macs continue to gain traction in the personal computing space.  This in turn has required Windows administrators to become more familiar with Macs and the limitations they may have when connecting to a typical corporate Windows environment.  In the past, Citrix has done an OK job providing Mac support for XenApp through a basic ICA client.  Specifically, they created a functional no-frills client that supports the latest, as well as past, Mac Operating Systems.  The client primarily supported ICA connections through an ICA file.  The Program Neighborhood Agent functionality did not exist and published applications (not desktops) launched through Citrix Web Interface were presented in a kludgy window.  This changes with the release of the 11.0 plug-in (formally called client). 

Primarily, the 11.0 plug-in finally enables seamless functionality of published applications on Macs.  Seamless published applications (opposed from the desktop) present themselves to the user as if they are running locally.  This in turn allows the user to run published and local applications side-by-side for an improved experience.  More importantly, this seamless functionality opens the door for corporate environments who serve applications through the Program Neighborhood Agent or Citrix Web Interface to give Mac clients a user experience that is in line with what Windows clients have supported for years. 

Also included in this update is the introduction of Citrix’s Dazzle interface.  It looks like Citrix has larger plans for Dazzle suite, but from a client perspective, applications served through the Program Neighborhood website are presented in an iTunes like interface.  I think the logic Citrix is following is that users would be acclimated easily to an application delivery interface that mimics iTunes on the assumption that most users are already familiar with iTunes. The interface is clean, intuitive and even gives the user the ability to add the application to the OS X dock. The “Add” function threw an error for me when I was testing testing the client , but in theory it *should* work.  I’ll post the fix when I come across it, but this bug doesn’t takeaway from the huge functionality upgrade in this client.

It is unfortunate Citrix took years to finally give Macs the same support that the Windows client has had for years, but better late then never, right?  Download it here.

Dazzle interface of the 11.0 Mac plug-in:

A couple of months back I posted on Citrix’s HDX Media Stream, as well as my first hand results with the trial release of HDX Media Stream for Flash.  Today, I wanted to follow up on that post with the newly released betas of XenApp 4.5/5.0 Hotfix rollup pack 5 (HRP) and Citrix Online Plug-in 11.2 (formally called ICA Client).

To start, both of these releases feature the typical bug fixes on both the client and server.  The 11.2 plug-in will also replace both the XenDesktop receiver client (11.1) as well as the XenApp plug-in (11.0).  Citrix has finally unified the XenApp and XenDesktop clients into a single installation.

This client/HRP combo provides some significant functionality to enhance user experience in existing XenApp environments.  It will add HDX Flash redirection support in XenApp.  The functionality is disabled out of the box, but can be enabled and controlled granularly in GPO with a supplied ADM template.  Testing this in a lab environment checks out.  Very straightforward and the functionality works as advertised.

The other new feature as part of this client/HRP is and addition to what Citrix calls “HDX Plug-n-Play“.  I don’t care for the terminology, but this finally brings dynamic USB redirection to XenApp.  Previously, USB devices on the client needed to be connected prior to XenApp session creation.  If a USB device was plugged in after a session was already created, the user would be required to logoff and login for the newly added USB device to present itself within the ICA session.  This was not intuitive and very annoying to users. (Also, would generate a helpdesk call.) Citrix has a dynamic USB tool that provided some functionality around this, but it was never officially supported and buggy.  Like the Flash redirection, this functionality is enabled with little configuration.  Simply running the 11.2 client on a server with HRP5 will enable the functionality.

Both of these enhancements coming to XenApp are not surprising, however it is a pleasant surprise that Citrix will roll this functionality into a hotfix rollup and client release.  This will allow existing 4.5 and 5.0 environments to take advantage of these new features.  These enhancements also echo Citrix’s focus on continually improving the user experience amongst their solutions.

Grab the betas here: (Requires a My Citrix login)
HRP5 for XenApp 4.5 and 5.0
Plug-in 11.2

One of the challenges in maintaining and managing a large scale XenApp farm is automating application publishing. Servers may have dozens of applications published to them and manually managing these applications is time consuming and impractical. 

At the moment, organizations have the option of using Citrix’s Installation Manager or third party solutions such as Enteo’s Citrix Management Suite to assist in automating these tasks.  Both can introduce management overhead and can be tedious to maintain especially if the organization is invested in another software distribution platform. Management through scripting is currently possible leveraging MFCOM, but these scripts are cumbersome and not intuitive. Introduce, “XenApp Commands” (currently in Technology Preview).  XenApp Commands will give administrators the ability to manage a XenApp farm using PowerShell.

PowerShell scripting for XenApp introduces a potent method of managing and maintaining a XenApp environment.  Functions such as application publishing, policy maintenance, and load evaluator application can all be accomplished through PowerShell cmdlets.  Full list of cmdlets are available here, and a cursory look shows a fairly exhaustive list.  XenApp Commands will make automating tasks and functions significantly easier then in days past. More importantly, XenApp Commands will give organizations more flexibility in how they deploy and manage applications to their XenApp farm.

Obviously, maximizing the use of “XenApp Commands” will take working knowledge of PowerShell, but with Microsoft incorporating PowerShell in Windows Server, Exchange, SQL, and the System Center suite of products, administrators should already be exposed to this technology (or should already be familiar with this technology.).  XenApp Commands is still in “Technology Preview”, but looks to be released for XenApp 4.5 and 5.0.  Download it here (login required).

Among the benefits of a server based computing (SBC) environment, are the potential savings that exist when purchasing cheaper desktops or terminals on the client side. The logic being that because applications are being run on a server, the client just needs enough horsepower to present the server based applications to the user. Of course this might not be a driving factor of deciding to go to a SBC environment but it could result in some cost savings over a traditional desktop environment.

Organizations that start to design a SBC environment will most likely entertain Wyse terminals or other equivalent terminals that can run the ICA or RDP protocol to present a XenApp/VDI environment. These terminals have a small profile, are low power and reduce management overhead over traditional desktops. The obvious drawbacks are the lack of flexibility these terminals provide because they don’t run Microsoft Windows. In the scenario a Windows application does not run/will not run in the Terminal Server or VDI environment, there is no option to run it locally on a terminal. This variable is large enough for organizations to opt for traditional Windows desktops to serve as “thin clients” resulting in minimal or no cost savings on the client side (from a power and hardware perspective).

Recently, Dell released the Optiplex 160 series line of desktops. They are classified as “Tiny Desktops” because of their ultra small form factor. About the size and weight of a textbook, they can be configured with Windows (XP or Vista) and leverage the low power Intel Atom processor found in most netbooks. (Dell claims 87% power efficiency over traditional PCs.)

The 160 series bridges the gap between Wyse terminals and traditional Windows PCs with its low power draw and tiny form factor. However, it has a seemingly inflated price, which starts at $567. For some reason, Dell has priced it only a couple of hundred bucks less than a modestly configured traditional desktop. Price seems to be a limiting factor right now but does open up another option on the client side for an organization moving to a SBC environment.

Media playback within a XenApp or XenDesktop session has always been a challenge when designing a server based computing solution. The user’s experience is degraded through choppy playback and the host server is taxed processing the audio and video playback. Administrators have typically addressed this challenge by educating users to leverage their local client browser and media player whenever media functions were required. Not only does this introduce obvious training challenges in educating users, the experience is less than ideal having users switch between the “server” and “client” environments. Not to mention any new application integration issues that this generates.

Over the last few years Citrix has made incremental improvements to its HDX (formerly called SpeedScreen) technology to improve Flash and general media to solve this challenge. The improvements are significant over RDP, but playback overall is still not even close to “local” speed. Along with traditional improvements to HDX, Citrix has quietly included media redirection in XenApp and XenDesktop for certain media types. This is the mechanism in which media playback is offloaded to the client workstation for a more seamless experience. The server passes instructions to play the media to the client and the local audio and video codec is used for the actual playback. Media plays back seamless and the server processor is not taxed in the process. At the moment, XenApp and XenDesktop support DivX, XVid, MP3, among other media types. Check out this Citrix technote on all of currently supported media. From an administrator’s perspective, the requirements to enable this functionality are very straight forward. Enable SpeedScreen and ensure the client and server have codec installed and it will just work (given that the media type is supported).

As of last month, Citrix released a trial to enable Flash redirection (currently not officially supported). Flash has become the de facto standard for streaming video and multimedia on the internet, so the full release will be highly anticipated (tentative for Q3). Not that most users are doing this, but to test the technology, I was able to play back a 720p video through a XenApp server without any skipping or lag. Impressive stuff.