Welcome to Kraft Kennedy

Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.

Kraft Kennedy | Technology Blog

Tag: XenDesktop

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.

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.


Continue reading…

My last post Citrix Provisioning Services Part 1 – What Is It? served an introduction to what exactly Citrix Provisioning Services is capable of. Below I hope to open people’s eyes to using PVS for something other than VDI, as it is often thought of as a part of the XenDesktop suite. However PVS is actually independent of XD or VDI, and can be utilized in combination with XenApp to bring single-image benefits to the Terminal Services world.

Provisioning Services allows for server consistency, easier maintenance, dynamic servers, and aids in disaster recovery.

  • Consistency – As a best practice every XenApp server delivering the same applications should be 100% identical to the rest of the farm. However, obtaining this is easier said than done.  By streaming the same image to every server, each server is inherently and 100% the same as the rest.
  • Maintenance – Updating and patching large farms can be a very time consuming task, and anything done to one server must be repeated for the entire farm to maintain consistency. With PVS, patches and software installations are applied once to the master image and on next reboot, each XenApp server boots the new updated image. In addition to software patching and installation, Terminal Servers need to be completely refreshed periodically to keep them clean and performing optimally; they are used by dozens of different users, reducing performance and resulting in inconsistent servers. A typical server refresh requires the server to be re-imaged and the software redeployed, a time consuming process that can be prone to error, leaving a server in an unusable or inconsistent state. Operating system streaming with PVS results in a completely fresh and optimized server on every reboot.
  • Dynamic – PVS allows for a dynamic XenApp farm instead of a static one. As load rises and additional servers are needed, they can be quickly brought online in seconds instead of hours. Conversely, as load drops, un-needed servers can be powered off or repurposed as needed. A server becomes a vessel for different workloads and can be a XenApp server one day and an IIS server another if need be. Since Provisioning Services is capable of streaming to both physical and virtual servers, administrators have the ability to utilize different types of resources all from the same master image(s).
  • Disaster Recovery – Creating a disaster recovery plan for the XenApp environment often requires complex processes, scripts and configurations. Assuming a PVS server has been built in the DR site, and that the master image has been replicated as well, quickly bringing an entire farm of XenApp servers online becomes a simple task.

Creating a XenApp environment that is more dynamic and easier to maintain is a goal for many XenApp administrators. The addition of Provisioning Services to a XenApp implementation can go a long way to achieving those goals. By leveraging the single-image management capabilities of PVS, administrators can dramatically reduce the costs involved with deploying and maintaining their XenApp farms. While at the same time, guaranteeing consistency between and ensuring peak performance of each server in the farm. All while being capable of quickly adapting to changes in load and disaster scenarios.

One of the great features of desktop virtualization (VDI) being touted by the industry is the ability to manage and update all of your desktops from a single central master image.

Citrix’s solution to the single image process is accomplished by a product called Provisioning Services (PVS). This software is the result of their purchase of a company called Ardence back in 2007. Provisioning Services is an often misunderstood piece of software, and its great benefits and potential are not necessarily apparent to everyone.

PVS works by streaming a master (read-only) image from the server to a target server or workstation. Any subsequent writes are then sent back to the PVS server and written to a cache file. The reads and writes are sent back and forth between the PVS server and target in a constant stream over the network. The easiest way to grasp this is to imagine that the cable connecting the hard disk inside of the server to the motherboard (and thus the CPU and RAM) is replaced by a network cable running back to the PVS server. The operating system sees the PVS disk as though it were a normal hard disk, and everything is done entirely transparent to the OS. The magic happens when the server is powered up; instead of booting from a local disk it is instead set to boot to the network card (PXE, BOOTP) which talks to a service on the PVS server, which streams the assigned operating system image to the target. The target device starts up immediately, as though it was booting from a local disk.

The beauty here is that this single read-only image can be simultaneously streamed to multiple diskless targets, both physical and virtual. This central image can now be maintained in one place. This makes tasks such as installing updates or new software quick and easy. After installing an update into the master image, all machines running that image will boot up into the updated image on next restart. To put that in perspective, think of the time and effort required to push out something such as a service pack to Windows or Microsoft Office to your entire firm. Now imagine simply installing that update once and having every machine in your environment receive that update on next reboot, without any additional effort.

Look for a follow-up post discussing the benefits that Provisioning Services can bring to a XenApp implementation.

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.

; The [ApplicationServers] section contains the name of the
; application server entry used to describe the connection.
; The name below (Access) appears in the title bar of the client window.
;
[ApplicationServers]
XenApp=
; The Application section describes the attributes of the Access entry.
; The name in the square brackets must match the name above (Access).
;
[XenApp]
TransportDriver=TCP/IP
Address=SERVERNAME.DOMAIN.COM
ProxyType=auto
WinStationDriver=ICA 3.0
Username=
Domain=
Password=
InitialProgram=
WorkDirectory=
ClientAudio=On
;
; Use either ScreenPercent or DesiredHRES and DesiredVRES to specify
; the size of the client window.
; If both ScreenPercent and DesiredHRES and DesiredVRES are specified,
; only ScreenPercent is used. ScreenPercent is not available with the
; WinFrame 1.6 Client, only the Web Client.
ScreenPercent=100
DesiredHRES=1024
DesiredVRES=768
DesiredColor=8
; The WFClient section describes the WinFrame Client.
;
[WFClient]
Version=2

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.