• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Consulting Blogs
Insights and ideas shared by the Consulting team.
Permalink | Twitter Post to Twitter | Comments (2) | Views (414) |

posted by Florian Becker

I recently talked about HIPAA and HITECH compliance and how application and desktop virtualization can be an effective means for protecting against security breaches.

Today, I came across a whitepaper by another vendor that speaks about some of the same challenges and it struck me that there is still confusion between Security Breaches and Privacy Breaches.

The author opens by citing privacy breaches in the healthcare industry (improper access to "Octomom's" medical records, and doctors improperly accessing celebrity patient records at UCLA), but then proceeds to describing solutions that prevent only security breaches, but not privacy breaches.

Privacy breaches occur when properly authenticated and authorized users look at a patient record that they have no business looking at... at least not at the time when they are looking at it. For example, a doctor pulls up a record (celebrity, athlete, their neighbor's kid etc.) to review information although they are not treating the patient at the time. This is a privacy breach that may have to be disclosed under HITECH. The same user may have a perfectly legitimate reason to pull up the same record and review the same information a week later when the patient is coming in for a visit, in which case the access would not constitute a privacy breach.

Preventing security breaches can be accomplished through two-factor authentication at the workstation, locking terminals to prevent improper viewing of data, and other authentication and authorization approaches for clinical users and database administrators, who have sometimes direct access to the raw data. The latter would be important to prevent privacy breaches, but it is more difficult to accomplish. Even the implementation of access logging mechanisms alone cannot stop all technical personnel with the right kind of low level access to circumvent the logging layer and go straight to the data.

So, the vendor of the whitepaper I mention earlier states the HITECH problem correctly, but positions the authentication and authorization solutions that only protect against security breaches, which is necessary but not sufficient. 

Now, here's a thought:
One healthcare organization spoke at HIMSS 2010 about leveraging sophisticated data mining techniques to flag improper access by otherwise authorized clinical staff.

If the Electronic Medical Record application is delivered via Citrix XenApp, organizations can use the Smart Auditor feature to review recorded user sessions to verify user behavior. This could even be employed to watch the technical IT staff by presenting the terminal emulator windows to go to the heart of the data exclusively over XenApp. Given that one would not be able to review the sessions of thousands of users, this would need to be implemented in conjunction with data mining of the logs to flag suspicious data access. Yes, it sounds like "big brother is watching you", but there mere knowledge that any system interactions are recorded at the user session level will provide an additional deterrent to privacy breaches through employees.
This is another way that virtualization techniques support data security and patient privacy.

Please share your thoughts and comments.

Florian Becker

Follow me on twitter @florianbecker

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (634) |

posted by Daniel Feller

One office with one type of desktop... Easy.  Hundreds of offices with any type and age of desktops... Difficult but not impossible.
 
Most organizations find themselves in the difficult camp. A user's desktop can be completely different (in terms of hardware, resources, applications and configuration) than the person sitting next to them doing a similar job. As the environment includes users from different departments, in different offices, with different requirements it becomes clear that the understanding of the user topology for an organization is critical before one can create a desktop virtualization solution.
 
In previous blogs, I've discussed how understanding the underlying standards, applications and storms plays an important role in creating a successful virtual desktop design.  The fourth requirement is to understand the organization's user topology. More specifically, one must get a grasp of the endpoints and user locations.
 
First, the endpoints. Most organizations follow a 3-5 year desktop refresh cycle.  At a minimum, there will be 5 different hardware configurations for each of the 5 years (in actuality, there will likely be many, many, many more configurations). Also, the desktops that are less than 2-3 years old have hardware configurations that  can easily support Windows 7 and the latest applications.  These newer desktops have more virtual desktop options than an endpoint that is 5+ years old.  Newer desktops have the processing power to support the Local Streamed Desktop FlexCast model instead of the hosted VM-Based VDI desktop model.
 
With Local Streamed Desktop, the desktop is still virtualized and centrally managed, the desktop still receives the virtualized applications, and the users still have their personalized settings applied. The difference is that instead of using resources on a physical server in the data center, the local desktop resources are used. Because local desktop resources are consumed, fewer data center servers are required to support the same number of users
 
This is but one example of how understanding the endpoints helps determine the type of virtual desktop a user requires.  However, just knowing the endpoints is only one aspect of the user topology.  The second aspect, user's location, also plays an important role in selecting the most appropriate virtual desktop. 
 
Certain desktops require a high-speed connection to the infrastructure while other options can allow slower networks with higher latency. By assessing the user locations and the connections to the data center, the proper solution can be put into place to support the virtual desktop FlexCast model.

  • Hosted shared desktop: Can be used on networks with low speeds and high latency
  • Hosted VM-based VDI desktop: Can be used on networks with low speeds and high latency
  • Hosted blade PCs: Can be used on networks with low speeds and high latency
  • Streamed local desktop: Requires a fast, low latency network to the physical desktop for optimal performance
  • Virtual Apps to Installed Desktops: Can be used on networks with low speed and high latency. If application streaming is used (as compared to hosted applications), slower networks will delay application startup time, but users have the ability to work disconnected.
  • Local VM-based desktop (not yet available): Can be used on networks with low speed and high latency, although the slower the network the longer it will take to sync the image to the endpoint. Images can be tens of GBs in size. But once delivered to the end point, all communication remains local to the desktop.

 
When deciding on the appropriate virtual desktop type, the endpoint and the user's location matter.  Without taking both into account, a user might end up with a fast virtual desktop that takes 5 minutes to start Microsoft Word. Gather all the information before deciding on your virtual desktop type.

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 Fan Page: Ask The Architect

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (4) | Views (1321) |

posted by Bhumik Patel

One of the common questions that Citrix customers implementing XenDesktop 4 for Branch Offices ask is "How much Bandwidth is required to deliver XenDesktop 4?" Even though the typical answer to such a specific question is "It depends" and it is based on available bandwidth, latency, WAN congestion and user/application activities, customers still need some sort of guide or range to help them plan for a large scale XenDesktop deployment. So, I am happy to announce that Citrix Consulting Solutions recently performed extensive testing to provide guidance to customers to help determine how much Bandwidth is required for delivering XenDesktop 4 over the WAN. The report Performance Assessment and Bandwidth Analysis for Delivering XenDesktop to Branch Offices aims to provide customers with bandwidth requirement guidance for standard user workflows such as Office 2007, internet browsing, printing and video executed in a XenDesktop virtual desktop delivered over WAN. Along with the guidance for native XenDesktop bandwidth requirements, Citrix Consulting also integrated Citrix Branch Repeater with XenDesktop to utilize its WAN optimization techniques for optimizing XenDesktop connections. Citrix Branch Repeater provides significant reduction in the amount of bandwidth required to deliver XenDesktop over a WAN and hence provides customers with a cost effective alternative to a WAN upgrade.

Let me give you a brief snapshot of the testing methodology and results of this Citrix Solution Center project. We leveraged Login VSI Pro, a benchmarking tool designed for SBC and VDI solutions, to execute our standardized Office workflows. By using this publically accessible tool, customers can now perform similar in-house tests to obtain more specific results for their customized workflows and answer the "it depends" question. Login VSI Pro was also used to launch simultaneous XenDesktop connections over a simulated WAN to determine the average bandwidth required for each workflow under utilized WAN conditions. This is important in performing accurate bandwidth requirement measurements as the underlying ICA protocol optimizes itself in a utilized WAN scenario. We also monitored end user experience to identify any degradation in performance while increasing the number of simultaneous XenDesktop connections.

The following graph provides a summary of the Average Bandwidth consumed for native Citrix XenDesktop and the performance benefits gained when Citrix Branch Repeater is integrated into the Citrix XenDesktop solution. All the numbers shown below are for the respective workflows over a WAN connection of 1.5 Mbps, 80ms latency and 1% packet loss (with the exception of the HD video which required a 10Mbps connection based on the high data rate of the video).

The testing results show that Citrix Branch Repeater provides dramatic bandwidth savings allowing customers to add up to twice the number of users executing similar workflows on existing WAN connection. Now customers can accelerate the ROI in their XenDesktop 4.0 investments while providing a rich desktop experience to branch office users. For more details on the testing approach and results please refer to the document here. Also for customers interested in performing similar testing specific to their implementation, please contact Citrix Consulting Services for assistance or email me with specific questions or comments at bhumik.patel@citrix.com

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (1) | Views (938) |

posted by Stefan Drege

Introduction

How often have you found that there is a lot of "How To" or run-book style documentation out there, but none of them seem to completely address the combination of your requirements? And while you have expertise in one or more product areas, have you found that making the pieces work together seems challenging sometimes?

I ran into such an example not too long ago. I had to configure an Access Gateway SSL VPN to a XenDesktop environment, accelerate the traffic, and support Single Sign On. There was not a comprehensive document out there that I could leave behind with the customer.

So I took a different approach. Rather than create an exhaustive document, I just listed the steps and referenced only the specific sections in existing product documentation, knowledge base documents, and some custom information.

For my specific project needs, (User/AGEE PlugIn/Repeater PlugIn > NetScaler AGEE > Repeater > XenDesktop) I came up with the following set of instructions that I left behind with the customer.

Step One - Create the XenDesktop Environment

I, personally, was OK with setting this up. Otherwise I would have used the Evaluating XenDesktop section (Section 4) of the XenDesktop product documentation available from the Citrix eDocs site. This can be retrieved from http://support.citrix.com/proddocs/index.jsp and selecting XenDesktop.

Step Two - Install the Citrix Repeater

To insert the Citrix Repeater into the data flow, I simply performed the steps outlined in the Citrix Repeater Quick Installation Guide. This document comes with the product, or can be downloaded from the Citrix product download site(http://citrix.com/English/ss/downloads/index.asp in my case.

One note was that on the second page of this guide, the "Gateway" address referred to is the default gateway that is used by the management dialogs - not the default gateway for user traffic.

Then I added the licenses to the Repeater. The licensing process is driven by the "License Host ID" that is shown in the Repeater Management GUI. I found the details of this procedure in the Citrix Branch Repeater Licensing Guide, which was part of the product documentation set I downloaded.

Lastly, I set up the Signaling IP address. This is the Repeater-hosted IP address that the client-based repeater plug-in-in connects to in order to establish acceleration with the repeater appliance. This is discussed on page 7-84 of the Citrix Branch Repeater Family Installation and User's Guide document available from the product download section of the Citrix web site. This IP address is set in the Repeater GUI > Configure Settings > WANScaler Client panel. Note that this Signaling-IP must be enabled in the menu as well.

Step Three - Configure the NetScaler Access Gateway

In this step, I added the configuration elements to the NetScaler Access Gateway such that it would allow the Repeater to optimize the traffic to the XenDesktop infrastructure behind it. I used the instructions in the "Turbocharge Access Gateway" document which is available for download from: http://support.citrix.com/article/CTX121035.

Since I was using NetScaler Access Gateway Enterprise Edition, I used only Section 7 for the details of how this is done.

Section 9 of this handy document pertains to customizing the Repeater Client software - used at the remote user's laptop, etc. - in order to pre-populate the signaling IP address. In volumes, this is good to do for ease of distribution. Because mine was a simple, limited-user configuration, I chose to let the user customize the parameter after installing the Repeater Plugin.msi (from the Citrix product download site(http://citrix.com/English/ss/downloads/index.asp in my case) on their own.

Then they simply do the following:

• Open the Receiver and right click the Acceleration Plug-in in the list.
• Selecting Manage Acceleration will present a menu to specify the Signaling-IP address.

Also, since my configuration goes straight to the XenDesktop system and not to a landing page, updating the NavUI home page as discussed on page 25 in the above document, was not required.

Lastly, because the acceleration traffic policy set above breaks the Single Sign On process, I needed another Access Gateway Traffic Policy. This traffic policy causes Repeater-specific optimization to be bypassed for all http traffic sent to the XenDesktop Desktop Delivery Controller.

I simply repeated the steps on pages 18-19, but using SSO-Policy and SSO-Profile. The specific overrides will include:

• Policy -> DestIP == <IP address of DDC> Netmask 255.255.255.255
• Profile-> Protocol = HTTP; WanScaler = OFF

Then I bound the two policies to the Traffic section in the Virtual Server's Policies tab. There I made sure that the exclusion policy is set to a higher priority (lower numeric value) than that of the generalized traffic policy. This causes optimization to be turned OFF for http (the SSO traffic) requests to the Desktop Delivery Controller only.

Acceleration is performed, however for all other (TCP) traffic to the rest of the subnet because this traffic does not match the criteria of the first policy in the list.

Summary

In following the above steps, I quickly created a configuration which authenticated and accelerated user traffic to the XenDesktop virtualized environment.

Furthermore, using the Repeater Plug-in dialogs, the user can see the actual acceleration realized.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (647) |

posted by Florian Becker

There are two interesting trends going on in healthcare at this time (no, I am not talking about the current debate in congress). One is that we will see more and more healthcare providers use electronic medical records - a trend that is fueled by financial incentives through "stimulus money". The other is one of the consumerization of IT - specifically healthcare IT.
We see this trend in other areas as well - like employees using their personal cell phones of choice to access corporate email, or even bringing their personal laptops to work.
In healthcare, doctors are already heavy users of mobile technology - cell phones, smart phones, the ubiquitous pager etc. But today we're at a point where the consumer technology is good enough to be used for clinical purposes and can actually contribute to giving doctors a little bit of their free time and their personal life back.
Case in point: The patient calls their on-call doctor after hours with a rash or burn. In the old days, it would have required the physician to drive a possibly long distance to see the patient in order to recommend treatment. Today, she can simply ask the patient to take a picture of the ailment with a smart phone and simply email it over. In many cases, the image quality is good enough to recommend treatment and help the patient immediately.

This trend is obviously troublesome for healthcare administrators. Many actually recommend against their physicians employing "unapproved" avenues to make remote diagnosis out of fear of litigation and legal compliance violations. The dilemma is that both patients and doctors use technology out of convenience where it makes sense. It is against doctor's nature to hold back care if it is obvious how the patient can be helped right then and there.
However, I stipulate that this is actually nothing new.

  • For a long time, doctors have consulted their patients over the phone and gathered enough information to diagnose and make a recommendation for treatment, so the digital information exchange actually reduces risk in many cases.
  • The patients are the only rightful owner (note that I am not saying the only legal owner, this would be a different discussion) of their medical data. If they choose to share some of it over less than secure connections with their physician, it's their choice. In the age of social media and Internet-based commerce, people have become accustomed to giving up some privacy and security in exchange for faster and better service online.

So, can both groups - doctors and their patients on one side and privacy advocates, regulators, and lawyers on the other side be happy? Yes.
Some electronic medical record system vendors incorporate an internal, secure messaging feature that allows patients to communicate with their doctors and nurses directly, but through the established channels of an existing EMR implementation. In addition (or in lieu) of this capability, healthcare providers can use their smart phones, netbooks, tablets, home computers etc. to securely connect to their employers system to upload data, annotate patient notes in real time etc, check for potentially harmful allergies, etc. If the EMR implementation does not expose a fully functional web based user interface, both desktop and application virtualization technologies can make it so.
Instead of getting into the cold car and driving 50 miles through snow and ice to see a patient, the doctor on call can simply pause the movie on the living room TV, switch the set to the connected PC and securely connect to the patient's medical record, review pertinent information, write a prescription electronically (a must have under the proposed "meaningful use" criteria) and finally go back to being a private person. More personal life for caregivers, faster service for patients - enabled through technology.

Follow me on twitter: @florianbecker

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (5) | Views (1089) |

posted by Daniel Feller

Install, stream, host, Oh My!!! 

Many of you have heard me talk about the different ways to deliver applications into a virtual desktop: installing, streaming, hosting and VM-hosting.  As with all options in life, each one of these has their pros/cons.  However, I recently found a way to remove one of the cons out of the equation for installed applications.

Although we like to say "No" to installing applications, for some organizations and applications it might still makes sense. It is easier (because we are used to it), installing supports every application, and it gives the fastest application launch time compared to any other option.  My recommendation has been to install your common applications in your golden desktop image.  If everyone needs the applications, then just install it to give the users the fastest experience possible. 

Makes sense so far. But what about those applications that we want to run on the desktop but do not stream?  We would install them. But unfortunately, when you install an application into a desktop image, everyone who uses that image will see the application - D'oh!  This is probably not something most people will want to happen.  Why am I seeing this application if I don't need it? Most administrators when faced with this situation, would take the most logical course of action... Build a new desktop image for a particular group of users.  Sounds reasonable, but this now requires you to maintain a different image with additional locally installed applications.  The maintenance requirements starts to increase exponentially. 

BUT, what if you could use a single image and put all of your installed applications into that image while still allowing the users to see only what they need to see?  Seems like we could reduce the number of desktop images.  It is possible and it can be summed up in two works: Published Content.

Published Content is a little used feature in XenApp. Instead of publishing applications, you essentially publish content which are links, URLs, shortcuts.  If we publish a shortcut link to the installed application, we can determine which users will see icon.  When a user selects the icon, which is pointing to the executable file on the desktop, the application starts immediately.  And with the use of Dazzle, we can allow the users to configure their start menu with the icons as they see fit. 

Of course this doesn't do anything for those users who are smart enough to go searching on the local virtual desktop C: drive and can find the physical executable file.  But you can use Active Directory policies to disable certain users from executing certain applications.  (User Configuration - Administrative Templates - System - Don't run specified Windows applications)

Of course to set this up, you have to get the application installed, publish content, and set an Active Directory security policy. But once it is configured, you have one less desktop image to maintain and adding/removing users to a particular application just involves adding/removing users from a particular Active Directory group membership. 

Now you have another option in your bag of tricks.  Hope it helps

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 Fan Page: Ask The Architect

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (1021) |

posted by Daniel Feller


Are you using Windows 7 yet? Has your organization migrated yet?  Have you been reading all there is to know about Windows 7 migrations?  Then I must ask why you didn't attend the Ask the Architect TechTalk on February 25th.  Not only did we talk about the expected challenges most will face during the migration, but we also focused on how we can overcome these like we've never been able to do before, thanks to advances in technology like desktop virtualization and application virtualization. 

First, if you want to hear what was discussed, it's not too late. You can watch the Windows 7 Migration recording.  The great thing about the recording is that you can repeat sections over and over again. To get an idea of the topics covered, the following is the Q&A from the live event:

Q: How do you suggest we migrate from physical profile to virtual profile as we have no virtual desktops yet

A: You can' migrate from Win XP to Win 7 profiles. You have to pull sections from the old profile and import them into the new profile via with tools like Citrix Profile Management or AppSense.  Of course, you have to test as some of the locations might change between OS versions. If you want a lot more information regarding profiles, then I suggest you attend this upcoming Ask the Architect TechTalk about Profiles.

Q: How does USMT tool fit into migrating with XenDesktop?

A: The User State Migration Tool would be difficult to use in this scenario.  As I've seen it used, it essentially snapshots your Windows XP image and then has Windows 7 link into the old image.  This means we would have to store all of the Windows XP items from all of your users, this could be a lot of space.  Also, I always prefer to start users with a clean slate when moving to a new operating system to help optimize their environment.  Of course, we would pull a few important items over, but it is still more optimized than if you would try to reuse the entire environment. 

Q: In my company (tele-marketing) we are using an application which requires the use of audio-resources, will it work fine with virtual desktops ?

A: Sound does work with XenDesktop virtual desktops. You can even use microphones and have 2-way conversations within the virtual desktop. However, not knowing the applications/audio requirements you will really need to test the application to make sure it performs as expected.

Q: What about IE6 to IE8 app incompatibility when you move to Win7.  We find lots of apps not compatible with IE8.  Same for vendor apps.

A: Unfortunately, you will need to find a way to run IE6. Since Windows 7 already has IE8 installed, you really can't move backwards.  You have two other options:

Option 1: Use a hosted IE6 from a Windows 2003 XenApp server.

Option 2: Use published IE6 from a Windows XP desktop that is delivered as a VM Hosted Application via XenApp.

Q: what are the software options for streaming apps?

A: The two most common application streaming options are to use XenApp Application Streaming or Microsoft App-V.  Both can easily be integrated within the XenDesktop images.

These were just a few of the questions discussed during the Ask the Architect TechTalk.  If you want to hear more, then feel free to listen to the recorded webinar.

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 Fan Page: Ask The Architect

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (2) | Views (1259) |

posted by Florian Becker

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (1119) |

posted by Florian Becker

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (2) | Views (2331) |

posted by Paul Wilson

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.

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.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (683) |

posted by Florian Becker

Recently, Radio Magazine had an interesting cover story. A patient at home uses a multi-function device to take her vitals and communicates in real time via a video conference with her doctor. The physician gets instant access to the data and can visually inspect the patient through a two-way camera. All communication is wireless and covers long distances - wow.
Well, the article wasn't published quite as recently, but in April of 1924.
85yrs and 11 months later, I am at the annual gathering of the Healthcare Information Management and Systems Society (HiMSS) in Atlanta and notice that wireless medicine is still a hot topic. There are numerous iPhone apps, like the mobile bedside ICU monitor in this picture:
So, we're right now at the point of having a small set of patient data elements at the finger tips of providers on a mobile application. Add to that remote sensors and diagnosing capabilities, and the landscape will look more like the 1924 idea. The blood sugar sensor in your body sends information via your cell phone to the physician's Electronic Health Record application and she gets an instant notification in case your numbers are off. Pretty cool.
Sophisticated high def imaging is another thing that will go mobile in the near future.
I attended Dr. Bria's presentation on mobile computing today. He's the CMIO of Shriner's Hospital and he  specifically mentioned the iPad as a delivery vehicle for high def ultrasound and radiology images. While smart phones and iPhones are preferred due to their "always on the person" form factor, the larger iPad has the ability to deliver more detail on its larger screen while maintaining the cool factor. 
However, how long will it take the vendors to develop the special applications for those devices? How much data will need to be transmitted via wireless networks to render an image where the quality is "good enough" to be useful?
While I see a lot of motion towards secure mobile patient data access at HIMSS this year, I also see more systems in the healthcare IT enterprise, not fewer. For example, there are vendors who offer solutions to extract data from various other vendor's clinical applications, stick the data into a separate database, and then have an iPhone application connect to it. All for the purpose of providing mobile access to providers - cool,  but the increasing complexity could be a roadblock.
Thanks to desktop and application virtualization, the native imaging modules of EMR applications are likely to come to the iPad and other devices pretty much right away without CIOs having to worry about yet another platform and yet another application.... 1924 - here we come.

What else is new at HIMSS? Stay tuned....

Follow me on twitter: @florianbecker

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (909) |

posted by Daniel Feller

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (3) | Views (1629) |

posted by Kevin Bacon

Are you looking to optimize a Windows XP image for use with XenDesktop and Provisioning Services?  Have you read several guides with various tweaks and build steps, but didn't know which ones actually worked?  Well, when Citrix Consulting began designing and implementing large-scale VM-hosted VDI desktops, we found that none of these documents provided a comprehensive view on the subject.  To address this, I have written a new Citrix Consulting white paper, Optimizing Windows XP for XenDesktop, which includes all of the necessary information to actually optimize a Windows XP image for XenDesktop with or without Provisioning Services.  This document:

  • Offers a better alternative than replacing the default user profile (which isn't supported and doesn't help for users that already have profiles)
  • Makes a distinction between private mode (1:1) and standard mode (1:many) desktops
  • Provides the actual registry keys/values for all optimizations (to ensure that all settings can be set by Group Policy or login scripts)
  • Gives best practices for optimizing the user profiles (like installing UPHclean)
  • Excludes configurations and steps that don't help (like defragmenting a disk before performing a volume copy)
  • Details what registry changes are included in the XenConvert Optimizer tool (so you know what all those checkboxes are doing)

Enjoy the full white paper, which is now available for download at http://support.citrix.com/article/CTX124239.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (7) | Views (1480) |

posted by Daniel Feller

IOPS. One of the core design areas that will impact the overall performance and usability of a desktop virtualization solution.  How do we estimate IOPS? What impact will a user have on the storage infrastructure? Is estimating 30 IOPS per user good enough? Is it too high? Too low? This is the question Doug asked in the latest Ask the Architect Viewer Mail.  

If you use the 30 IOPS per user to design your storage, you should have enough capacity, but you are probably wasting a lot of money on capacity that you will not fully utilize.  

A user's impact to IOPS is based on four phases of a desktop's life cycle:

  1. Boot
  2. Logon
  3. Work
  4. Logoff

Each one of these phases has a different impact and they are discussed in the latest Ask the Architect Viewer Mail:

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect.

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (2) | Views (1086) |

posted by Florian Becker

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (1) | Views (1319) |

posted by Daniel Feller

A great question came into the Ask the Architect email recently focused on storage and RAID configuration for XenDesktop environments. Essentially, what RAID configuration is most appropriate for XenDesktop:

  • RAID 0
  • RAID 1
  • RAID 5
  • RAID 10

As with most good things in life, the answer is it depends. It depends on reading/writing operations, fault tolerance requirements and storage space allocation.  Instead of writing about it, watch the latest Ask the Architect video below

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (845) |

posted by Daniel Feller

Let's talk scalability again.  Scalability. One of my favorite topics (insert sarcastic tone here).  I like the scalability topic so much that I recently blogged about it when talking about the possible size of a XenDesktop farm.

But a new question came into the Ask the Architect wanting to know about scalability for XenDesktop. I'm happy to see that this question wasn't simply how many desktop can I get on a hypervisor, but actually wanted to understand the things that should be monitored to help guide you when you should add a new server or component. BRAVO!!!

Citrix Worldwide Consulting recently published a new white paper discussing how to design the XenDesktop environment in a modularized fashion.  This allows one to add components as the environment scales up. There aren't numbers in there because as with most things in life, you mileage will vary.  But to do an architecture correctly, one must understand what should be monitored so better decisions can be made regarding the allocation of additional resources. 

This Ask the Architect video explains these areas of focus. 

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (1) | Views (1082) |

posted by Daniel Feller

I recently received a question regarding the integration of Microsoft App-V with a hosted-VM based VDI desktop within a XenDesktop infrastructure.  App-V, just like XenApp Streaming, creates an application profile where portions of the profile are delivered to the endpoint as needed.

The challenge is with this particular set of applications, they undergo frequent updates (daily).  Integrating the application layer requires:

  • A configuration that keeps the cache intact across reboots (as this will speed up the application delivery aspect)
  • A configuration that allows for seamless updates without requiring reboots or virtual desktop image updates

Because the virtual desktop is delivered from a single Provisioning services image, a persistent disk should be allocated for each VM as explained in the following Ask the Architecture Q & A video. 

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (1255) |

posted by Daniel Feller


The migration to the new operating system was a challenge. We had a mass of people going to each user's desktop to copy their data and rebuild the operating system.  We thought we planned appropriately but ran into all sorts of issues like:

  • We didn't have the correct hardware drivers for some of the computers, which required searching the Internet and oftentimes using try and error until we found the right driver.  There were too  many occasions where we were unable to find a driver for the new operating system.  We just hoped the user wouldn't notice.
  • We sometimes found out that not all of the hardware was compatible with the new operating system so we had to quickly find a new computers for some of our users. 
  • During the application install, we often came to realize that some of the applications were incompatible.  Once we figured out how to get the application installed, we thought the mission was accomplished and moved onto the next user.  This took about an entire day to complete for 1-2 users. 
  • We thought we finished with the user but because this was a new interface for the user and a new way of doing things the user ran into many issues. Many of their settings were gone and so were their icons.  So while we continued to migrate more users, we had to backtrack and help teach the users.
  • When the next upgrade comes along, I'm going to take a sabbatical. 

This is not an example of a migration to Windows 7.  This is an example from Windows 3.1 to Windows 95.  The same could be said for migrations from Windows 98 to Windows 2000 or from Windows 2000 to Windows XP. 

Guess what?  Migration season has arrived again.

By all accounts, 2010-2011 will be the time when many organizations investigate how to move all of their users to the new Windows 7 operating system. We have to ask ourselves if we plan to follow history and repeat our steps, or will we try to do something different so the migration isn't as painful and long.  Let the past be our guide. We know what challenges we will encounter, so let us solve them before they hit again:

  • Hardware: Desktop virtualization and Citrix FlexCast can solve these challenges because the virtual desktop is either hosted on a hypervisor (thus having the same configuration) or delivered to the newer generation of desktops via a local streamed desktop.  The images are pre-built and implemented in a matter of seconds instead of hours.
  • Applications: We aren't limited with local installed applications on the desktop operating system.  We can install, stream or host the applications.  And in the rare event that these three options are not enough, we can use VM Hosted Applications on an older operating system.  The point is that from the user's perspective, the applications operate seamlessly.
  • Personalization: We want to save the critical user data while discarding the irrelevant.  With personalization solutions, we can help ease the user's transition to Windows 7 by migrating portions of the personal environment. 
  • Support: Once the migration is complete, users will have questions and issues.  We need to see what the user sees.  We need to detect issues before they impact the users.

We know we will migrate, but the question is how will we migrate to Windows 7. We already know the challenges we will face by doing the manual, physical migration. We know that desktop virtualization can solve these challenges.  So let's investigate desktop virtualization further by attending a one hour Ask the Architect TechTalk on Windows 7 Migration

Remember, the distance between insanity and genius is measured only by success.  So if you want to be a genius, you need to know how to effectively create a desktop virtualization solution that can ease your Windows 7 migration. 

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (1189) |

posted by Florian Becker

Mario Andretti, the great race car driver, was once asked by a reporter if he was ever afraid when driving a formula one car and pushing the envelope through the duration of a race. Andretti answered: "If you're not uncomfortable, you're not going fast enough."
How quickly can you move your organization to a virtual desktop computing paradigm? At what speed are you comfortable and can you afford to do it slowly and gradually?
A little while ago, I read Brian Madden's piece on why customers DON'T want to implement VDI (http://bit.ly/8lE8YF), which made me think about these questions. After skimming through some of the comments, a pattern appears to emerge. Apart from the (perceived) technical complexities of a VDI solution, there is a lot of angst and politics involved, according to the commentators.
Today's IT departments are often organized along technical silos that reflect the departmentalized technical responsibilities of the client-server computing model.
Adding virtual desktops to a "classic" IT environment requires touching multiple silos. Technical architectures are spanning client and server operating systems, server virtualization, storage, application integration (or virtualization), thin client computing etc.
This is where the perception of complexity is coming from. In reality, building and running a virtual desktop solution is easier than the traditional model in many respects, but requires broadening one's knowledge to cover the areas unknown today. IT professionals are encouraged to embrace the relevant new areas as it positions them to assume leadership roles once the organization moves towards virtual desktops.
CIOs face a slightly different challenge. They must get the right skill set together in order to design and build a virtual desktop solution and then change the organization to align with the new computing model. This will inevitably involve retraining or replacing current employees and restructuring of the org chart. These are sometimes painful changes to make and should not be taken lightly. However, most CIOs and their C-level colleagues in an organization look at the promise of cost reductions associated with moving to virtual desktops. The ROI benefits of such a solution are based largely on reduced operating costs and cheaper hardware at the end point.
I stipulate that the most effective (from a cost / ROI point of view) way to implement virtual desktops is to go all out and shoot for a big-bang , wall to wall transition into virtual desktops. Instead of thinking about a small IT "project", think about "Phase 1" of the virtual desktop adoption. This approach has several distinct advantages over the often practiced, tippy-toe approach to a few users here and there:

  1. If you are a CIO, it requires you to get your leadership together and plan a project carefully. Discipline in clear thinking at this stage makes all the difference - just like a smooth landing is preceded by a well executed approach. Enlist the help of outside consultants who have done this a couple of times to avoid re-inventing the wheel . This planning phase also allows for the identification of key people in the organization who have acquired some knowledge in the field and are positioned to run the operational aspects after the initial go-live.
  2. While the actual go-live and the associated cultural transition is bigger, the big-bang approach limits the time of pain and suffering (lots of initial user questions, 24/7 user support, working the bugs out of the system and processes) to a relatively short period of time, compared to years of singing the roll-out blues.
  3. Cost savings: If ROI is a major driver towards desktop virtualization, here's where the gravy will be. The faster the transition to a new organizational model, the faster the old silos can be broken down and support personnel can be reduced in number or retrained. Otherwise, the organization would need to keep most PC support technicians on staff for the large number of physical desktops and hire ADDITIONAL resources to support the virtual desktops.

In this context it is important to state that ROI benefits must be based on the actual CAPEX and OPEX reality, which is different in each company. Generic ROI calculators often assume industry-standard values for server and desktop support costs per unit and can vary significantly between organizations. Examining those operational costs closely can also help identify current areas of unnecessary redundancy and duplication.
In summary, the IT department leveraging virtual desktops as the primary and de-facto way of delivering applications and data to users features an org chart which is fundamentally different from today's reality in most organizations. The change can be painful - therefore, the successful transition is swift, well executed, and is planned with the end in mind.

I can already see some of our friends in the industry replying to this blog by stating that Citrix requires a risky wall-to-wall go-live in order for promised ROI/TCO benefits to materialize.
No, that's not what I am saying. ROI calculators are great tools if used properly in the context of actual values in an organization. Generic statements are often based on industry averages and must be validated before delivering realistic projections. Some of our friend's VDI solutions actually don't significantly reduce or eliminate the desktop support team at all - it just moves their work to the datacenter. Unlike the virtual desktop approach supported by Citrix FlexCast (as little as one desktop image for all users, solid application virtualization, streamed operating systems to the end-point, etc.), VDI still has one desktop for every user and doesn't leverage the "power of one". The problem just moved to the datacenter, but didn't fundamentally change. Not bold enough! I am not even saying that your organization will achieve a specific ROI on your virtual desktop implementation. Too much depends on your current operating model, cost structure, and use cases. All I am saying is that whatever ROI /TCO you calculated , you should strive to changing the computing model fast - otherwise you risk cost overruns and therefore reduced ROI benefits.
Again - start with the end in mind and pledge to replace all physical desktops with virtual ones by a certain date .

Citrix actually offers a couple of things that support you in your resolution:

  • XenDestkop 4 Trade-up program for XenApp customers: Get a better trade-up ratio if you trade ALL of your XenApp licenses: http://bit.ly/4EIM0u
  • 1,000 Desktops. 90 Days. In production: A fast deployment methodology offered exclusively by Citrix Consulting to get a scalable architecture in place and have a significant number of users in production in a short period of time: http://bit.ly/4E4iih
  • A modular design approach to the virtual desktop solution provided by Citrix Consulting Solutions: http://support.citrix.com/article/CTX124087
  • Enterprise Licensing Program. Specific discounts - the more you buy, the larger the discount. This should help with the wall-to-wall approach: http://bit.ly/8TNoJS
  • Citrix Consulting architects will continue to cover topics on planning and executing the transition on these pages in the future.

Please share your thoughts and comments.
Follow me on twitter @florianbecker

Expand Blog Post

1   2     3     4     5   Next >>