Well, not quite, but as a physicist working on the grand unified theory would say: The arrows are pointing into the right direction.
While patient care is not delivered virtually quite yet, the experts in the field of Health Information Management and Systems will have their annual gathering in Atlanta in early March (http://www.himss.org) to ensure we'll get there in the future. If you haven't been to the HIMSS show yet - it is an exciting conference with well over 20,000 attendees.
Questions on health record portability, privacy, interoperability, and the plain old task to get physicians to warm up to the idea of using a computer as the primary means of documenting clinical information will be at the center of the discussions, while musings on whether the federal government is going to pay for your healthcare IT initiative are sure to be overheard as well.
I myself will make my way up to Atlanta to find out what's going on in the industry and I seek to speak to many attendees and presenters on application delivery challenges in this unique field. Stay tuned on these pages for regular updates and follow me on twitter for a play by play of my HIMSS journey.
Before I pack my bags and decide whether or not to include foul weather gear and snow shoes, please let me know what specific topics around healthcare IT you are interested in.

Twitter: @florianbecker

Florian

The American Recovery and Reinvestment Act of 2009 (ARRA) contains a whole chapter called HITECH. This catchy acronym stands for Health Information Technology for Economic and Clinical Health and makes you wonder if "they" construct the acronym before deciding on what information to convey. It basically mandates a number of fairly stringent disclosure requirements for HIPAA covered entities and their business associates  in the case of privacy  breaches leading to the disclosure of patient data. The act is intentionally aggressive in order to entice health care providers and insurance companies to be really cautious about patient privacy and record security.
I am at HIMSS in Atlanta this week and I notice that ARRA, HITECH, HIPAA and other related topics are front and center in many sessions and for many vendors on the floor.
Under HITECH, the burden of proof is on the side of the covered entity to prevent a breach, discover the breach, and then disclose the breach to the patients and - in some cases - to the secretary of health and human services. If the breach is affecting 500 or more patients in a state or region, the covered entity must notify the patients via public media and notify HHS immediately. 
So, let's define what a breach really is, and then what you can do to never having to call your local newspaper for the disclosure ad.

Under HITECH, a breach is an "unauthorized acquisition, use, or disclosure that compromises the security or privacy of the health record". There's also something in the language that this must pose a significant risk of financial, reputational, or other harm to the individual. Note that I am not a lawyer, but I did stay in a holiday..... tonight. Kidding aside, I did listen to Gerry Hinkley and Deven KcGraw during their HIMSS session this week - both are legal experts in this field.

So, having a laptop with unencrypted, and personally identifiable patient information stolen would be a breach. If, however, the data is secured with federally accepted levels of encryption (and the security of the key is not compromised), OR the data does not include certain items such as DOB or the patient's ZIP code, it's not a breach.
As you can see, the devil is in the detail. So, how can you take steps to avoid that painful disclosure? For one, ensure that the patient information never leaves your data center. Leverage desktop or application virtualization and disable clipboard and local disk access on the client device. Many electronic health applications can only print through the server, so that client connected printers are not needed and can also turned off without compromising functionality. If mobile access to the data is needed, consider the Citrix Receiver for the iPhone or mobile access platform of your choice to deliver the information without delivering the data.
Even without HITECH, these are important considerations for any Electronic Medical Records (EMR) rollout. When done correctly, you could allow your doctors, nurses, and staffers to use the laptop, netbook, tablet, iPad of their choice without having to worry about IT managing the myriad of devices or any of them leaving the premises.

Now, unfortunately, this is only one aspect of HITECH. The other aspect involves the unauthorized access  of patient records by employees who have legitimate access to the systems, but are basically snooping around. HITECH covers privacy breaches, not just security breaches.  Looking up your own lab results, or the chart of your friend's sick kid is an example of a well intentioned, but illegal breach. Looking up the local football player's records to determine if that hamstring injury has healed before Sunday's game is also an illegal breach, but not an innocent one.  Identifying those scenarios actually requires intelligent data mining to assess whether access was justified for a person to do their job or constitutes a breach. While you can't fix the latter category through application or desktop virtualization, you can confidently use virtualization technology to prevent breaches through the loss of devices or data without restricting mobility. One less thing to worry about in the complex world of healthcare regulation.

Questions? Comments?
Follow me on twitter: @florianbecker

No doubt you have heard about the iPad by now and you may be already pondering whether or not you will be buying one. Chances are you have a Laptop or PC and a Smartphone already so you need to rationalize how you will use it beyond e-books and browsing. Well if your company has XenDesktop or XenApp you will be happy to know you will be able to use your iPad for real work as well. It turns out the 9.7 inch display on the iPad with a 1024x768 screen resolution works great for a full VDI XenDesktop. Windows applications run unmodified and securely in the data center, and even multiple applications at once. The advancements that were made for the Citrix Receiver for iPhone will carry over to the iPad, however the iPhone restrictions of screen size and small keyboards are overcome with the iPad. It's a beautiful thing ! The iPad looks to be an ideal end point device that can empower users to be productive were ever they are and IT will be able to safely deliver company hosted virtual desktops and apps without worry.

So tell us if you want Citrix Receiver for the iPad and let us know how your going to put it to work. ( even it's just to rationalize buying another gadget )

Learn how to make the iPad work for your organization at Citrix Synergy. 

http://twitter.com/chrisfleck

While most discussions on successful Electronic Medical Record (EMR) implementation and adoption circle around the proper implementation of clinical workflows, standard order sets, diagnostic codes, and the all important CPOE (Computerized Provider Order Entry), little time is spent on thinking about how the applications actually make it to the users. I have talked to CMIOs this week at HIMSS who mentioned that the improper application delivery actually constituted a significant roadblock or bottleneck towards adoption.
Healthcare organizations have tried anything from Computer's on Wheels (COWs) to tablets to smart phones and iPhones. Each modality has its own merits and risks. Let's have a look:

COWs: With large screens and full keyboards, using the system is as easy as using a desktop computer in the office. However, there are some distinct challenges associated with COWs: They are used by many different people. Although the carts are adjustable, users don't adjust them in the interest of time on the floor and are therefore experiencing ergonomic problems. COWs are wireless, so the 802.11x infrastructure must be 100% reliable with good signal strength. Map out every patient room using the all familiar "Can you hear me now?" method of assessing signal strength in every place the COW might be used. Check with your facilities manager whether the COWs in the hallways would violate any fire security.

Tablets: Overcome some of the bulkiness of COWs. Same challenges with wireless networks though. Check with your users first. Doctors carrying the tablet in one hand and the stylus in the other hand don't have a hand left to touch the patient. The success of tablets also depends on the specific EMR application you are running. Entering data via the virtual keyboard of the tablet is very time consuming and therefore prone to error. Applications that let users click through selection lists are much more tablet friendly. Consider specialized tablets for the healthcare industry that include scanners and interfaces to diagnostic equipment while maintaining the mobility.

iPhones, SmartPhones: Awesome. Barely larger than a pager with a user interface made for the device. Can't replace a full application though as many apps are just for vitals, bedside monitor virtualization, results review etc. Smart phones are complimentary to other access modalities - not a full replacement.

iPad: It's coming. I talked to several EMR vendors at HiMSS 2010 in Atlanta this year, who are already working on their user interfaces to make them friendly for user interaction sans keyboard. Of course, the Citrix Receiver will be able to deliver any windows app or desktop directly to the iPad.

Finally, there are the good old thin clients. These units combine the best of all worlds: Large screen, yet small form factor. Don't require wireless networks and several incorporate a smart card reader to facilitate two factor authentication. Have one in each patient room, nursing station and several in the hallways (neatly wall mounted and tucked away while not in use) and you have a solution that allows doctors to use both hands on the patient and use a familiar keyboard for data entry. Use desktop and/or application virtualization so that you can eliminate the end point support team. Depending on the EMR application, consider generic windows logon and light or no profiles to speed up logon times to the windows environment. Authentication happens on the application itself in this case. Smooth Roaming capabilities are essential to cut logon time down to a few seconds and provides full mobility on the floor without carrying a device.

Some of the access modalities in your healthcare facility depend on provider preference (yes, doctors do prefer some devices over others and yes, please make your doctors and nurses happy). Use application or desktop virtualization wherever possible to avoid end-point support. Citrix XenDesktop can deliver remarkably high quality application fidelity and image resolution even over longer distances thanks to the bundle of HDX technologies.

What is your experience with EMR implementations and application delivery?

Follow me on twitter @florianbecker

I'm debugging a good one lately, Discretionary Access Control List (DACL) programming with Citrix App Streaming.  Recall from a previous post that Citrix App Streaming dynamically adjusts user access rights for the execution cache as a function of running applications in sandbox and as a function of terminating application isolation spaces.  This is very cool stuff - but it is presently creating some headaches.  This post describes the headaches.

The quick review of the earlier post is that users on a XenApp Server are allowed to see the application installation content ONLY for the applications that they are presently running.  Applications that they are not running, they cannot see, even if those applications are presently running on that machine, right now, supporting other users.

From the layers of glass, I'm talking about the middle layer here.

 
The middle layer is SHARED across all of the isolation spaces.  If multiple users are on the machine, only one copy of the installation image exists for all.  This space is stored below \Program files\Citrix\RadeCache.  It SHOULD be below the streaming client subdirectory, but it isn't - I digress.

At installation, the streaming client installer sets permissions on the RadeCache space so that the Streaming Service user account (Ctx_StreamingSvc) has "full rights" and "users" have no rights, not even file scan.   At runtime, the streaming client grants the specific user Read+Execute rights to the GUID_V subdirectory that holds the execution content for this specific application.  This means that if a XenApp server has  100 users on it, but right now, you are the single user running "Toontown", then ONLY you will be able to see the Toontown bits.

It's even more restrictive than not being able to see the bits, you can't even see what folders exist below the RadeCache because you never have file scan for that space.  Interestingly, you CAN "CD" into the subdirectory if you know the GUID_V, though this works only while the application is "running".

Compare this to locally installed apps.  On a XenApp Server, a USER can "file open" and browse to \program files and then view all of the applications that are installed on that server.  For App Streaming delivered apps though, things are more locked down, the user cannot "see" application bits for applications that they themselves are not running.

This is very elegant.  Elegant can be problematic.  The user rights are granted using the Windows API SetNamedSecurityInfo.  This is the Windows API version of ICACLS.exe.  The headache starts in how this API implements ACL assignment.

Around 4 years into this App Streaming thing and all this DACL stuff has existed since the beginning - 4 years clean, I have seen it break down twice in the last 6 months.  

Problem #1: Customer has some really massive servers and when the individual user count hit 900, the DACL set failed and the Application Launch failed. Hum.  Why failed?  DACL size limited to roughly 64KB and the SIDs of all the authorized users started to add up.  Customer didn't have 900 users on the server, they had many hundreds, but also had a few "blowed up" sessions where the service didn't have a chance to remove rights so the DACLs built up - over months until hit a full DACL space.  The streaming client didn't notice the failure on the DACL set, but it did fail to CreateProcess the application, launch failed.  Solution: Purge the DACLs on regular basis.  This isn't today's conversation.

Problem #2:  Citrix internal IT folks implementing layers of cake; observing "slow" streamed application launch for the first App Launch, while 2nd time launch is fast as they would expect.  WHY is first slow?  It shouldn't be slow, the RadeCache is "mounted" into the space making all apps close to a 2nd time launch.  Sure the registry would need population, but that shouldn't be too bad.  Good news on that one by the way, on 5.2, the registry needs population.  On not yet released Mako, the registry load is a hive MOUNT which is much more efficient.

The suspect configuration has Citrix Provisioning Server, XenServer, XenDesktop, App Streaming and Microsoft Office 2007.  Variants of this profile have been used for stream to physical machines for 1000 users for a year or so now, including the stuff I'm using to write this post.  We know the profile is "good".

First time app launch slow

Launch debugger: Observe source code and binaries as it steps through, see a few neat things.

1) Streaming client is doing a DIR /S on the RadeCache for each sandbox create.   Wow!  That sucks and shouldn't be there, but it doesn't explain things being slow.  For those wanting to know more, it is this code that calculates the cache utilization and decides when to dispatch the cache reaper.  Ignore this - more digression.

2)  Streaming client is setting DACL to grant user access to the cache.  Wholly crap, how long did that take!

In WinDBG, you hit "F10", "F10", "F10" to step over code.  It usually takes about as long to get to the next line of code as it does to release the F10 key.  In the case of the API to set the DACL, the machine "froze".  I mean, NOTHING - for many seconds!  Wassup?

I left the room all happy with myself telling the IT guys that something is completely hosed in your enterprise disk stuff because that should be "instantaneous".  The DACL addition is a SINGLE DACL addition for a SINGLE user, for a SINGLE directory, there's no way that should have taken SECONDS.

Recall that the RadeCache space was already populated, the streaming system was merely granting a user access; but easier than that, it was only setting a single DACL on a GUID_V sub-directory, which would propagate into the Device\C\Program files\... spaces of the execution image.  SECONDS!  Your joking.

Being smart people, the IT folks didn't let it go.

One of my favorite books

One of my favorite books is "The Zen of Code Optimization", by Michael Abrash.  Yes, that's "Zen" with a 'Z'.  I haven't had the chance to meet Michael, but when I do, well - Beer will be on me, this dude knows his stuff.  He is behind a bunch of neat things like the graphics libraries for Doom and generally, he knows how to make a computer do things efficiently. 

One of the best pieces of the book is "Chapter 3 - Assume Nothing".  Yes, this is a whole chapter.  The gist of this is that just because you THINK it will be fast doesn't mean that it is fast, you must MEASURE IT.  The corollary is that just because you have 4 years of a product in the field saying that it is fast, doesn't mean that it really is.  In this case, I've paid the penalty for "The Costs of Ignorance".  This outlined in excruciating detail on page 27. 

DACLs and Inheritance  

The ICACLS command and the streaming code of reference have the same behavior.  It comes down to this:

• icacls GUID_V /grant domain\username:(CI)(RX)

In THEORY, this sets a SINGLE inherited right at the top of the execution cache to permit the named user the ability to read files in that space, directory scan and execute content.  This is SUPPOSED to be what happens.  In theory, any CreateFile access to a file/directory below that space will then be influenced by the inherited rights from the higher directory, where we set the DACL.  This is what inheritance means - the higher directories have it - and this means that the subdirs do too.  Start at the root and work your way down, and permissions follow!  SIMPLE!.   Four years of hindsight now says that this isn't actually what happens! 

I'm amazed - chapter 3 coming to bear.

What really happens 

First - I checked with a bunch of certified smart people and none could find a hole in the programming of the DACL set.   The code is "perfect" as coded - but it's slow...

Instead of doing what you tell it to do, the Windows API gets "elegant".  I didn't ask it to inspect the subfolders and files, but it does!  That is stuff that should exist in the Windows Explorer shell and maybe in icacls.exe, but it dag gone tootin shouldn't happen automatically in the API version!  I already KNOW that the DAClS for the sub-directories and files are good, don't help me out by fixing stuff that ain't broke!!!

Instead of adjusting the rights of a single subdirectory, the system RECURSES to all files and subdirectories.

In the ITDev case, the subdirectories of the indicated space contain the mounted, FULL installation image of MS Offfice 2007, over 7000 files!
On a local machine, as in true physical hardware with true physical disks, you hardly notice; it's "short" time.  On a Virtual Machine, ... it matters!  I mean, it doesn't matter for one file, but if you multiply by 7000, it adds up!

Recall that the execution machine is Provisioning Server booted, XenServer execution, some fancy disk system, everything is virtual to the end.  The files that "exist" as local in the RadeCache don't really exist, they are merely described to the virtual machine as local, indeed, there's no such thing as "local", ever for virtual machines.

For each of these files, the Windows API performed it's stuff, and recursed into all the subdirectories.  It read the DACLs for each file/directory, compared them to the DACLs for the directory that we were setting up via the commanded API, determined that "all was good" and then made no adjustment.  BUT - merely reading DACL information from the files, caused disk blocks to get "paged in" and CPU wise, this is painfully "slow", even for virtual CPUs!

For small apps, nobody will ever notice.  For a monster like 2GB MS Office 2007 at 7000 files, they notice!

Recall - this only happens on sandbox create and destroy, so it effects FIRST time app launch and not second time app launch.

Solution 

Step 1: Prevent the streaming service from adjusting rights to the GUID_V directories.  I did this with a code change, but the same thing can be simulated by removing a "right" from the streaming service user on install.  Not for the feint of heart. To know, the service will "push on" should the DACL adjustment "fail".  You can read that as "it doesn't check the return code".

Step 2: Grant "everyone" R+X access, (CI) for the whole RadeCache directory.  This allows users to see and execute the contents of the RadeCache - eliminating the security advantage of hiding this space, but it also allows users to RUN THINGSs if the DACLs aren't adjusted. 

Conclusion

Getting the layers of cake going on XenDesktop takes work.  It also takes experiment and "doing it" yourself to experience some of the problems that arrise at scale.  We're doing that work and doing it with some pretty massive applications. 

For small apps, you'll never notice that this delay exists, but for large apps, it's a noticeable delay.  We're attacking it.  Look for changes in this area in a Parra/Mako + 1 streaming client.  Notice I didn't say Mako.

The good news near term is that it only comes up on a FIRST time app launch.  Second app launches are "fast", like on real hardware.  The bad news is that on pooled desktops, the first app launch of each logon is a first time app launch.  Populating the RadeCache makes most of that time disappear, but parts still exist.  Sandbox reuse helps, but isn't the only part of this puzzle.

The other thing to observe is that some of the delay in first time app launch is loading the installation image registry content.  This is a registry load operation on 5.2, which was the test environment.  In Mako/Parra, if you load/save the profile targets, this will be a registry MOUNT - which is much more efficient - even more importantly, it doesn't involve registry "writes", which is a winner.

My compliments to the Citrix IT folks for not letting go.  

Fun for your experiments

Create a directory with no files.   Time this command

• icacls pathtodir /grant localmachinename\username:(CI)(RX)

It will be fast.
Add 7000 files to the directory by copying \program files.  Repeat the experiment.  Amazing results...

Offline, I have received some compliments for sharing some of the "faults" in the streaming system.  I hope this post contributes positively to your XenDesktop implementations and to your understanding of exactly how things are running.  I find it helps to really know what's going on. 

Joe Nord

Citrix Systems Product Architect - Application Streaming

If you have read some of my recent blogs, you know that I have been spending time testing XenDesktop 4 and Microsoft Windows 2008 R2 Hyper-V. I thought I would take a moment and highlight the top seven things I have learned during this testing. Some of these items I briefly mentioned in my previous blog Optimizing Windows 7 for FlexCast Delivery posted a few weeks ago.

1. Use Fixed-Size VHDs for the Drives

This tip perhaps has the greatest impact on performance. Quite honestly I had no idea about how much of a difference disk alignment influences performance until I started testing with a dynamic VHD. When using local disks for storage, this is generally not noticeable. However, when using block-level SAN storage, the difference could be significant. Using a fixed disk VHD prevents both fragmentation and disk alignment issues by pre-allocating all the required space when the file is created and not requiring that extra footer at the end of the file and effectively creating a SAN friendly file.

Numerous resources are available on internet to discuss this topic, but for the sake of simplicity, I will try to give a brief synopsis here. The smallest block of data written by the SAN is called a "stripe" and it normally crosses several sectors on the underlying LUN. The NTFS file system is formatted with blocks of data or clusters. A file is written to a cluster, which in turn causes a write to the SAN "stripe". When the data block written from the virtual hard disk aligns with the SAN stripe, then only one disk is affected during the write. If that SAN stripe resides on a RAID1 or RAID10 array, then two writes will occur (a 2x write penalty) because the writes will be written on the primary disk and then again on the mirror disk. If SAN is on a RAID5 array, a three data disks and a fourth parity disk will be accessed causing four writes (4x write penalty) in a single parity RAID5 configuration.

When the data block is out of alignment with the SAN, that same single disk write is spread across multiple disks. For instance, if that write is on a RAID1 or RAID 10 array the single write operation becomes four write operations on the SAN. If it is on a RAID5 single parity array, the write operation becomes eight operations on the SAN. As you can see, a single write operation can quickly create a backlog of write operations on the SAN.

Unfortunately, the dynamic VHD file format needs to manage the size of the file, so at the end of each VHD file, is included a 512 byte footer. Every time a data block is added to the dynamic VHD, the footer is moved to the end of the file. Since the VHDs are normally written in 2MB blocks, the addition of this footer is virtually guarantees alignment issues with underlying SAN storage as it changes the offset of the file next to it. To further add to the overhead, as the file expands, the additional data blocks will be placed at the next available location on the NTFS partition, causing fragmentation of the file across multiple stripes.

2. Format VHDs with the Windows 7 Diskpart Utility

Windows XP setup and Diskpart utility create the boot partition with a 31.5 byte offset that causes misalignment with block-level disk subsystems. The Diskpart utility included with Windows 7 / Server 2008 has been corrected to create the boot partition at a more alignment-friendly offset. In essence, if the disk is over 4GB the utility will set the offset to 1024KB by default. If it is under 4GB, which is the case for most write-cache drives, it will set the offset to 64KB by default. I recommend manually creating the partition for VHDs and verifying it as well. To learn more about Windows Server 2008 disk alignment and how to configure it correctly with Diskpart, see the Microsoft KB #929491.

h2. 3. Include the .BIN File in the Disk Space Calculations

Microsoft Hyper-V always allows a machine to be placed in a suspended state, such that the contents of the machine's RAM is saved to disk for later retrieval when the machine is resumed, similar to hibernation on a laptop. In order to prevent possibility that disk space is not available in the future for saving the RAM contents, when a virtual machine is started, Hyper-V creates a .BIN file that is equal in size to the RAM configured for the virtual machine. This .BIN file cannot be disabled or deleted and must be present for the virtual machine to start. The file is also stored in the same folder as the virtual machine's configuration file. Therefore, when calculating the necessary disk space on a SAN to support virtual machines, be sure to add in space equal to the RAM of the virtual machines.

4. Configure Two Network Interfaces When Using Provisioning Services

The default network adapter for a Hyper-V virtual machine is the synthetic adapter, which is optimized for a virtualized environment. However, this adapter is purely virtual and cannot be associated with any BIOS-level hardware, virtualized or not. Since PXE booting requires a BIOS-level interface, the synthetic adapter cannot be used. Instead, Hyper-V includes a legacy network adapter that includes a BIOS-level integration and that supports PXE booting. The legacy network adapter must be added to the virtual machine and set as the default boot device.

To provide the best performance, the guest image should include both adapters so that the legacy adapter is used for PXE booting and the higher-performing synthetic adapter is used to pass the network traffic after the operating system boots. Both adapters can be connected to the same logical network since the synthetic NIC has precedence over the legacy network card in the route table.

5. XenDesktop Integration with VMM is Still Developing

The System Center Virtual Machine Manager (VMM) server provides numerous APIs for integrating with Hyper-V. XenDesktop supports the standard APIs for starting, suspending, resuming, and creating virtual machines. However, XenDesktop 4 does not utilize the Microsoft VMM GetRating API for any desktop-related operations. Without the support for the GetRating API, the XenDesktop infrastructure cannot intelligently placing virtual machines when creating or starting them.

When creating virtual machines with the XenDesktop Setup wizard, the wizard retrieves a list of hosts managed by the VMM server and then evenly distributes newly created machines across all the hosts that VMM has registered with it. In situations where the machines are being created on identical host hardware and for the first time, this behavior is desirable. However, if the host capacity is not identical or if they already have virtual machines the Setup wizard may overburden the host.

If you need to deploy additional virtual machines to unequally loaded hosts, one option is to use a VMM staging server, which has only servers of equal capacity registered with it. The XenDesktop Setup wizard can then be pointed to the VMM staging server. After the wizard completes, re-register the Hyper-V hosts with their permanent production VMM server, and adjust the desktop group properties as appropriate in the XenDesktop farm.

6. Virtual Machine Manager Design is Critical

Microsoft recommends protecting against failure by virtualizing the VMM Server and placing it on a highly-available cluster. However, this approach only protects against hardware failure, not against software failure. In situations where the VMM server is running but the service fails to respond communications between XenDesktop and VMM Server come to a halt. When the communication link is broken, the XenDesktop DDC stops sending connections to the desktops hosted on that VMM Server. As of now, protection against this type of failure is currently not available without the creation of custom detection and complex failover routines. For the time being, the best approach is to limit the number of desktops managed by a single VMM Server to around 1,000 so that it will not get overloaded.

7. Windows 7 Behaves Well When Virtualized

Windows 7 is a virtualization-aware operating system. Windows 7 includes several features which improve its performance in a virtualized environment. First, Windows 7 includes the Hyper-V Host Integration Services as part of the base operating system. Second, Windows 7 notifies the hypervisor when it is idle so the hypervisor does not schedule guest operations. Finally, Windows 7 provides improved storage and optimized page file management. When compared to Windows XP, an operating system that has no idea it is being virtualized and is supposed to reach end-of-life this year, Windows 7 is an attractive solution.

If you found this blog useful and would like to be notified of future blogs, please feel free to follow me on twitter @pwilson98.

Citrix Support is focused on ensuring Customer and Partner satisfaction with our products.
One of our initiatives is to increase the ability of our Partners and Customers to leverage self-service avenues via our Knowledge Center.

Find below the Citrix Knowledge Center Top 10 for February 2010.

Top 10 Technical Articles

Top 10 Whitepapers

Top 10 Hotfixes

Top 10 Presentations

Top 10 Tools

David
Twitter - http://twitter.com/citrixreadiness
Citrix Support on Facebook - http://www.facebook.com/citrixsupport

Choosing a thin client OS for your desktop virtualization deployment can be tricky.  Windows embedded thin clients offer the latest features, but they cost more and have additional security implications and maintenance compared to Linux based thin clients.  Wyse ThinOS clients are often easier to secure and manage than Linux clients, but often lag in features.  This has changed with the use of the Wyse TCX software, but because of the "thin" nature of ThinOS a few key features are not possible.  Let's take a look at the latest features available when using the latest Citrix clients.

Common features across the thin client operating systems include support for multiple monitors, bi-directional audio, USB flash drives and web browser acceleration.  Many of the Wyse TCX features work out of band which means they will not work with Citrix Secure Gateway or a Citrix Access Gateway running in Secure Gateway mode. 
 

For more information you can read this white paper on selecting thin clients for XenDesktop 4.
You can also check out this Wyse software pdf file on Wyse TCX and other Wyse software.
 

Sunil Kumar

Principal Architect, Desktop Virtualization

CSC Consulting

Cloud computing challenges many long-standing paradigms of the PC computer era. In my last post, I discussed the technical challenges facing the OVF standard in virtual system portability. Even if we assume that OVF will overcome the technical barriers, an even larger one looms: licensing.

The dominant licensing model for PC software over the last 25 years centers on hardware systems. Whether a vendor strictly enforces their license or not, the EULA for desktop software typically permits installation and use on a single computer. The paradigm example of this remains the Windows and Office products from Microsoft - the license key is tied to various properties of the hardware through "product activation".

In response to the complex problems this model presents to businesses, Microsoft offers the volume licensing paradigm. Even in this model, the license counts are still tied to hardware characteristics. The most obvious example is the licensing of Windows Server by number of processors on a target system. However, in a cloud infrastructure, the underlying hardware is inherently shared with other tenant virtual systems. It becomes impossible to accurately determine the actual processing power available to a given virtual system. Volume licensing was never conceived as a virtual system licensing scheme, nor has Microsoft ever claimed it as an appropriate solution.

The applicability of traditional licensing models to cloud infrastructures is questionable at best. An obvious limitation it creates for OVF is its use in software distribution. Imagine a world where most ISV's distribute their data center software as ready-made, bootable OVF images. When it comes time to update or upgrade systems, customers can apply updates or simply migrate to a new self-contained and fully validated image. The cost savings across the industry to ISV's and customers avoiding costly installation and basic configuration steps would probably be on the order of billions of dollars over the typical software lifecycle.

Such a world cannot exist today for Windows-centric data centers or application developers. The only redistributable Windows OS is the trial version that cannot be converted to a permanent license. If Microsoft supported a "bring your own license" (BYOL) model, such images could be converted to permanent installation status. Vendors could then leverage the vendor-neutral OVF standard to distribute turn-key products.

More generally, licensing requirements still impede adoption of Virtual Desktop Infrastructure (VDI) built around OVF to host employee desktops as virtual systems in the data center. IT departments are starting to consider the cost and security advantages of VDI. Citrix is starting to see more substatial uptake with our XenDesktop offering in this area. However, broader adoption of VDI is impeded by the cost of licenses. Part of the cost for Windows is that Microsoft requires the special subscription Virtual Enterprise Centralized Desktop (VECD) license on top of other costs. The situation for Mac OS X is more dire - Apple simply doesn't support virtualization of the desktop OS.

The existence of legacy licensing models that use dongles, MAC addresses, processor identifiers, and the like are less common today, but we still see customers foiled by such problems. This is particularly true when it comes to migration of existing systems into the cloud. However, even if most ISV's change EULA's and licensing schemes to officially support a cloud-based world, the optimal use of OVF as a tool of the IT cloud will remain impeded by the realities of how the OS components are licensed.

How do these licensing concerns impact your use of virtualization technologies? Have you encountered licensing problems trying to migrate to a cloud platform? Would you use a ready-made OVF images if Citrix or other vendors made them available?

Total power often leads to corruption. No, I'm not talking about business or politics. I'm talking about desktops.  Have you been in a meeting where people talk about giving users admin rights to workstations. I have two words for you... Be afraid... Be very afraid...  OK that was 5 words, but the point is clear. Be afraid.

Many of the challenges with the traditional, distributed desktop operating environment are the lack of standard definitions and enforcement.  Most organizations strive for a secured and locked down desktop environment, but over time users were granted exceptions. Throughout the months and years, those exceptions became the new de facto standard.

Now, users have local admin rights. Thousands of unique applications are installed throughout the organization.  Every desktop configuration is unique.  This is an almost impossible situation for any IT organization to support.  This environment did not happen overnight; it took time.  Standards slipped because it was simply easier and faster to circumvent the standards instead of troubleshooting the issue.  Because of the lack of standards, the environment is so convoluted and complex, it is excruciatingly difficult to make any changes or updates without causing mass confusion.

That being said, can these types of organizations still use desktop virtualization? Yes. And they will see many of the benefits with desktop virtualization that have been discussed over and over again. It will just be more difficult to achieve than an organization who has the desktop standards in place and actively followed.

Many organizations look at desktop virtualization at being the solution to simplify the desktop operating environment.  Desktop virtualization is an enabler.

If done to the fullest extent, desktop virtualization is an enabler towards better IT management.  Desktop virtualization can enable an organization to discard the bad habits of the past  and replace them with best practices that can help an IT organization survive and succeed within an ever increasingly complex computing environment. In order to simplify the management of the desktop, reduce desktop operating costs, and achieve desktop virtualization success, the organization must have alignment in terms of:

• User rights: Users must have enough abilities to do their job, but this does not mean users should be a local administrator.  IT must be able to provide the users with the correct applications and resources when requested. If modifications are required, IT must be able to accommodate in a reasonable amount of time. If IT is unable to meet the agreed upon time frames, alternatives must be made available so users can continue to be productive, which might require an open, and temporary virtual desktop playground area where users can utilize these applications until IT integrates them into the mix. I discussed this in a previous blog about a virtual desktop playground.
• Applications: Allowing users to install their own applications into the corporate desktop image increases complexity and reduces the security of the system.  IT has no visibility into the application and is unable to plan upgrades, updates, or hardware refreshes. The applications could open up holes in the infrastructure that others could exploit.  The organization must gain control of the applications if the organization is going to be more flexible.
• Operating Procedures: IT must deliver the resources users require in an adequate amount of time. This involves the development of new IT processes and ways of working.  If a user requires an application, IT must find a way of either incorporating the application into the environment, or finding the user an acceptable alternative while working within the confines of the corporate standards.  

Simply moving to desktop virtualization will help us solve some of our challenges, but if you want to make a significant improvement in the way IT is seen within your organization, there must be a new approach.  Without clear definition of the operating standards, moving to a desktop virtualization solution will result in many of the same challenges observed with the traditional, distributed desktop operating model. Chaos.  Except this time it will be virtual chaos.

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect