Shawn Bass

Asking Citrix for answers about the XenDesktop VDA is like a “Who’s on First” Abbot & Costello routine.

Shawn Bass — Mon, 04 Feb 2013 06:20:00 GMT

Practically everyone knows about the classic skit from Abbott and Costello titled "Who's on First?" The skit is a hilarious exchange between the two men where Costello is merely trying to understand who the correct player is in each field position. It’s made funny because all of the players’ names are words like "Who", "What" and "I don't know," so during the course of the conversation each question is answered with a name that leaves the person asking the question feeling as though they didn't get the answer. Some recent situations with the Citrix Virtual Desktop Agent (VDA) from XenDesktop makes me feel a bit like Abbott.

What is the VDA?

Citrix XenDesktop is comprised of multiple architectural components. While many XenDesktop architectures will involve hypervisors, SANs, PVS servers, and various other infrastructure components, it's also possible to build XenDesktop without using virtualization technology at all. That flexibility in the architecture makes it both incredibly flexible and powerful but can be quite confusing at times. Here’s an example of the simplest XenDesktop architecture you can create (not considering VDI-in-a-Box of course):

Notice that the above diagram doesn’t specify any hypervisors since all of these machines could be physical servers if we wanted. Also, I haven't included Secure Access/Netscaler, PVS, MCS, Profile Management, PVD, Edgesight, Password Manager or any of the other pieces that *may* exist in a full blown XenDesktop Platinum implementation. So this is as simple as it gets. A client PC with Citrix Receiver installed connects to Web Interface Storefront where the user provides their credentials. The WI/Storefront server talks to the Desktop Delivery Controller (DDC) to authenticate the user (assuming WI/Storefront isn't authenticating them) and then the DDC server performs calls to the SQL Datastore to retrieve information on what Desktop Groups the user is entitled to use. The DDC then passes the information back to WI/Storefront where a set of icons is displayed to the user. Once the user clicks on a desktop to launch, WI/Storefront passes that back to the DDC which instructs the physical PC or VM to begin listening for the HDX/ICA on (TCP/1494) or, if you’re using Session Reliability, via CGP (TCP/2598). One of the key pieces of infrastructure that makes all of this work is the "Virtual Desktop Agent" or VDA. The VDA is a set of drivers and services that are loaded onto each host machine you want to connect to. The VDA registers itself with the DDC to make it available to users based upon which Desktop Groups/Catalogs have been defined in the SQL Datastore. The VDA is what allows XenDesktop to connect to desktop operating systems, period. Without the VDA, none of this works. For a complete history of the VDA, see these articles on PortICA.

XPDMs on First, WDDMs on Second...

The issue with XenDesktop (or any other VDI technology for that matter) is that we're in a particularly bad transition time when it comes to Operating Systems. Many people are well on their way to move to Windows 7. Windows XP leverages a Windows Driver Model (WDM) called XPDM. When Microsoft released Windows Vista (and later Windows 7) they introduced a new display driver model called WDDM (Windows Display Driver Model). WDDM is required to drive the 3D Aero display model within Vista and Windows 7. (Look here for more details about how XPDM and WDDM differ.) The bottom line is if you want Windows Aero, you need WDDM drivers.

As you can begin to understand, if you had a product that straddled support for both Windows XP and Windows 7, it would need to be capable of supporting both XPDM display drivers as well as WDDM display drivers. In Citrix’s case, XenDesktop did not fully support WDDM drivers (and Windows 7) until XenDesktop 5.6 Feature Pack 1. XenDesktop 5.5 supported Aero redirection from VMs to physical PCs with GPUs, but that's not the same as supporting WDDM drivers when installing on a physical PC with an existing WDDM driver. So if you're building a XenDesktop 5.6 FP1 environment with its associated VDA, it can now be deployed with either XPDM drivers or WDDM drivers—The XPDM driver for the Windows XP VMs and the WDDM driver for the Windows 7 VMs where you want Aero.

The on ramp to VDI?

When Citrix released XenDesktop 5.6 Feature Pack 1, they introduced a feature called RemotePC. RemotePC essentially allows you to install the VDA onto physical endpoints for the purpose of brokering XenDesktop sessions to physical PCs. Keep in mind that the RemotePC features isn't really doing anything that couldn't be done before. The VDA has been able to be installed on physical PCs since XenDesktop 3.0—the first "real" XenDesktop release. Citrix never marketed XenDesktop towards physical PC use cases because (like many other vendors) they had the VDI horse blinders on. However once the industry recognized the analysts were wrong and VDI wasn't going to take over the world, Citrix and many other vendors started warming up to the fact that Physical PCs aren't disappearing tomorrow. So the RemotePC idea was born.

Now while I don't necessarily agree with Citrix marketing RemotePC as an “on ramp” to VDI, it’s perfect for many key use cases like telecommuting, working from home, DR scenarios, etc. For companies who have fully invested in the Citrix stack, RemotePC is a no brainer. (By “Remote PC,” I'm not even necessarily referring to the automatic registration bit that the RemotePC feature actually enables, I'm just talking about slapping the VDA on physical machines and making them accessible via XenDesktop. And by the way, I'd still love to see some HDX Connect under the Christmas tree for 2013 ;)

The issue with bringing a whole bunch of physical PCs into the environment is those physical PCs have Windows 7 (if you're doing your migration right). And of course those physical PCs also have GPUs in them since even those low-end crappy integrated graphics chips can do Aero). Plus toady’s users have adapted to Aero and now expect to see it even though there isn’t any practical use to Aero whatsoever. So now we get to the crux of this article (thanks for sticking with me!).

Who's VDA is on first?

When rolling out a VDA, you take the MSI and push it out with your ESD/PCLM tools. The question then becomes, “Which VDA do I rollout?” Here's the kicker in the VDA decision process: According to CTX134196, the supported method of installing the VDA is to deploy the XenDesktop 5.5 or 5.6 VDA and then upgrade it to the XenDesktop 5.6 FP1 (version 5.6.100) or the latest 5.6.200 VDA. The article states that this is the proper method because the 5.6.100 and 5.6.200 packages are update packages intended to be applied on top of the existing VDAs—they are not stand alone VDA installers.

Here's where the complexity kicks in. If you're deploying Windows XP, this isn't a problem because you'll just roll the XD 5.5/5.6 VDA followed by the 5.6.100/200 VDA and you're good. Remember this is okay because XP uses XPDM and XenDesktop 5.5/5.6 supported XPDM. No problem. But if you're using physical Windows 7 PCs with Aero enabled, when you install a 5.5/5.6 VDA you'll notice that upon reboot the Windows 7 machine is now in Windows 7 basic mode. That's because the 5.5/5.6 VDAs didn't support WDDM drivers. So if the "correct" and "supported" mechanism is to use 5.5/5.6 and then patch 5.6.100/5.6.200, you now have a dilemma. Do you want Aero or not? If you have Windows 7 with physical PCs, the recommendation is to use the 5.6.100/5.6.200 VDA and use the RemotePC feature. First of all, you don't really need to use the RemotePC feature if you only have a small number of machines to support. Just build a physical PC desktop group, import the machines to the DDC, deploy the 5.6.100/5.6.200 VDA, and away you go. But whether you use the RemotePC feature or not is irrelevant.

What the really confusing part about this is, what happens for customers with mixed environments? What if a customer has some Windows XP or Windows 7 VMs and some Windows 7 physical PCs that they want to retain Aero on? Should a customer really be forced to certify and deploy two separate VDA implementations? One method for VDI and one method for physical PCs? That's crazy! By the way, CTX134196 was only updated to reflect the appropriate "supported" paths about two weeks ago and that was because I had a customer burn a support ticket to get Citrix to indicate the proper supported path of deploying in these two scenarios. Prior to this KB being updated, the only reference Citrix had anywhere was this which indicates, "Upgrade to XenDesktop 5.6 Feature Pack 1 Virtual Desktop Agent only from XenDesktop 5.5 or 5.6 Virtual Desktop Agent. Those are the only supported upgrade paths."

How Citrix could have made this better?

There are several things that Citrix could have done to avoid the whole situation that we're currently in.

1) Citrix could have taken the appropriate installer engine code from the 5.5/5.6 VDA and baked it into the 5.6.100 and 5.6.200 VDAs such that they would have the pieces from 5.0/5.5 so that you didn't need to apply them on top as a patch. That would have meant that customers could have used 5.6.100 or 5.6.200 as an upgrade (for existing XPDM systems) or are a complete installer regardless of whether something was XPDM-based or WDDM-based.

2) Citrix could have placed a warning in the 5.6.100/5.6.200 VDA installer indicating that it was intended to be an upgrade only and not a standalone installer. Of course for Physical PCs with Aero it's meant to be a standalone installer, so I'm still not clear on what exactly the differences are between the "supported" 5.5/5.6->5.6.1/2 upgrade versus installing 5.6.1/2 straight away.

3) Citrix could have released 5.6.100 and 5.6.200 as MSP patches if they were truly intended to be patches. Of course this would have completely screwed up the RemotePC stand-alone scenario.

4) Citrix could have disclosed exactly why it's necessary to treat 5.6.100 and 5.6.200 as patches. In other words, why can't a person use 5.6.100/5.6.200 as a stand-alone installer? The only difference I've seen at all between the two deployment paths is that things are all jacked up in Add/Remove Programs and you can't leverage the Repair feature of Windows Installer to reconfigure the VDA. Personally I couldn't give a crap about that because I stopped using the MSI config tool as well as AD OU-based discovery since Citrix patched XenDesktop 3.0 at my request to include the ListofDDCs values.

So is this issue resolved? Not in my opinion. What Citrix needs to do is put out a comprehensive VDA that supports both deployment scenarios or at a minimum fully explain to people why they should perform dual certification deployment scenarios. For me personally, I'm recommending all customers use ONLY 5.6.200 VDA code regardless of whether they are using XP or Windows 7 and whether it's VMs or Physical. So far no problems as a result of that, but the deployments of 5.6.200 are just beginning so we'll see if I end up regretting that decision. Anyone else been bitten by this nonsense?

How persistence affects security: VDI and TS are not more secure than physical desktops, Part 5 of 5

Shawn Bass — Tue, 14 Aug 2012 13:42:00 GMT

If you read the last part of my "VDI and TS are not more secure than physical desktops" series, I left off discussing the various ways of performing isolation and how each approach works. I spoke about some of the challenges with each of these isolation approaches, particularly around usability. To continue this conversation, it's important to discuss persistent vs non-persistent operating system instances. If you missed the first parts and need to catch up, check out the previous articles:

Before we dig into the details into the security ramifications of Persistent vs Non-Persistent VDI or Terminal Server, I think it's important to spend a bit of time describing what the difference is between Persistent and Non-Persistent operating systems. Keep in mind that the ideas behind persistent vs non-persistent applies equally well to VDI and Terminal Services and can even apply to physical desktops.

Persistent Desktops

Persistent Desktops are desktop operating systems whereby the file system of the computer (the C: drive) is configured in a fully read/write supported model. This does not necessarily imply that the user of this system is an administrator, and in fact they should not be. Rather the model implies that the contents of the file system and the registry are persistent between reboots of the operating system.

There are several benefits of having a fully persistent disk model:

If you need to install operating hot fixes, you deploy them using a tool like SCCM, LanDesk, Altiris, etc and the hot fixes install on the OS. When the OS is rebooted, those operating system hot fixes are still in place. If you A/V agent needs to update it's signature files (aka DAT files) it does so throughout the day and upon rebooting the PC, the most current DAT files are in place.
If you need to have unique pieces of software on a per user or per working team basis, persistent disk images help. For example, if only 5 people in my organization need Adobe Creative Suite then I can push the installation package of Adobe Creative Suite to their 5 desktops (whether physical or virtual) and the software will exist only on the C: drive of their computers and not on any other system. Proponents of non-persistent images would argue that this could easily be accomplished through the use of Application Virtualization and/or OS Layering technologies. I would agree that this is true sometimes. However, Application Virtualization / Layering both have performance overhead and they won't necessarily work for all types of software (depending on the solution) and therefore they are not a 100% solution. Pushing software for direct installation is still the most broadly acceptable solution to support all needs.
If you need to stagger deployments of software it's pretty easy to update machines within dynamic collections of systems and slowly complete the rollout of a new piece of software.

There are also several disadvantages to having a fully persistent disk model:

Since each system has it's own persistent copy of it's C: drive contents, you can have a massive disk footprint within your data center. Think about it, if each VDI desktop is a 50GB disk image and you have hundreds or thousands of these, then you will require 10s or 100s of Terabytes of storage to support your VDI project on persistent disk images.
As each system is built up of multiple software installs followed by uninstalls follows by new installs in various different patterns you can run into situations where individual desktops experience problems with failed software installations or failures in removing software cleanly.
Deploying new software updates requires the software to be packaged and pushed to each machine individually. Depending on whether the machines are powered on when the distribution is to occur and various issues related to the health of the machines could result in less than 100% success in the rollouts.

Non-persistent Desktops:

Non-persistent desktops are desktop operating systems whereby the file system of the computer (the C: drive) is configured in a way such that writes to the file system are not preserved. This can be accomplished in a variety of ways, but generally speaking there is either a write filter within the VM that redirects writes to an alternate location where they are not preserved upon reboot, or this is done at the hypervisor level by creating a snapshot/clone/differential disk whereby the changes are discarded upon reboot. Non-persistent desktops are often associated with a term called Common Image where multiple non-persistent desktops are leveraging the exact same image file. In this circumstance, all desktops built from this template have the exact same file system contents and upon reboot they all revert back to this clean slate.

There are a few benefits of having a non-persistent disk model:

Since each system reverts to clean slate each time it's powered on, you never have to worry about an end user breaking an application by deleting important files or removing important registry keys. Even things as simple as a user reconfiguring an application can be reset back to the application's proper configuration with a simple reboot.
Since each system is leveraging the same disk image as it's starting point, you can save substantial amounts of storage space. In the persistent model above we talked about 10s or 100s of Terabytes of storage. In the event you had 1,000 desktops sharing the same non-persistent disk image, then you would only have 50GB of storage on the back end to support those 1,000 desktops. You can achieve massive storage space savings as well as IOPS reduction since the blocks of data that make up this disk image can be cached by the hypervisor or storage subsystem.

There are also several disadvantages of the non-persistent disk image model:

If you deploy all desktops off of a common image, then all of those systems need to contain the exact same set of applications. You could theoretically include additional software and control access to the various executables using a Software Restriction Policy or AppLocker, but your software vendors may decide that the mere installation of the software in the disk image constitutes license consumption. If this is the case and you can't handle the one-off application needs via Application Virtualization or other technologies, then you will be forced to create multiple different images per permutation/combination of unique applications. In low complexity environments, it's very likely you can support 10s or 100s of users with 1-10 unique images. When you try to scale a solution like this to environments that contain thousands or tens of thousands of desktops and hundreds or thousands of applications, it will be extremely difficult to support these systems without having tens to hundreds of different unique desktop images that you need to maintain.
Since non-persistent disk images revert to a clean slate with each reboot you'll need to be careful with respect to how you manage operating system hot fixes and anti-virus updates. If you revert to a two month old image, the OS will boot up with out of date OS hot fixes and A/V signatures. You may have processes to update the DAT files, but that won't work well for A/V software updates or OS hot fixes since those will typically require an OS reboot to apply. If your organization has audit requirements to report back on OS hot fixes an A/V updates you will be constantly updating your disk images to keep them currently. If you have many disk images to maintain this can be quite cumbersome.
Since non-persistent disk images revert to a clean slate with each reboot, you'll also have to be concerned with any type of user-based preferences or user installed apps that will be lost each time the system reboots. There are methods to preserve some of this content, but those methods don't apply to a pure non-persistent desktop, but rather creates a new category of systems that are a hybrid persistent / non-persistent desktop.

NOTE: You don't need to implement VDI or Terminal Server to achieve non-persistent desktops. You can easily support non-persistent desktops by using a local Hypervisor with snapshot revert capabilities or even on a physical PC with a write-filter software solution or system restore solution like Deep Freeze.

Hybrid Persistent / Non-Persistent Desktops:

We've previously talked about the benefits of both persistent desktops and non-persistent desktops. Some of the weaknesses of non-persistent desktops can be reduced by implementing a limited form of persistence within the model.

Here's a few examples of how you can achieve a hybrid approach:

Implement a profile management solution that allows you to backup and restore user settings for Microsoft Office, IE and other third party apps. This allows you to keep the benefits of a clean slate desktop while still preserving some basic application customizations to minimize user frustration.
Implement a disk layering solution to provide the ability to support user installed applications. If the user wants to install their own copy of iTunes, Google Chrome, etc. these can all be supported by leveraging a disk layering solution because the user installed components get installed into a differential disk that is layered on top of the common disk image. Some would argue that this level of persistence destroys the benefits of single common image non-persistent images, but that isn't necessarily the case. You can still achieve storage savings, IOPS reduction and a common set of OS files that will make it easier to update the underlying OS across multiple systems.

Security in the Persistent vs Non-Persistent vs Hybrid world:

Many proponents of the non-persistent disk image model insist that it is a superior solution from an information security perspective because of the idea that if the operating system is exploited and ownership is established, the machine can be recovered simply by rebooting and the OS would be clean again. While I do agree with this statement, I think it places a thin veil of ignorance around the concept of what is truly secure.

Let's analyze this argument in a few ways:

Is it better than a persistent disk that would keep the malware / infection over a long term period?

Yes, absolutely.
Does it mean you're safe?

No. If a hacker compromises your system even for 8 hours your data can already be stolen in that time. While giving the hacker 24 months is certainly going to make it easier, make no mistake that the data could be siphoned in much shorter duration than that.
Is resetting a system an effective means of dealing with virus/malware/trojans?

No. There's plenty of people out there who have said "You don't need A/V software on this thin client OS because you just reboot it and the infection is gone." Tell that to someone who has suffered from an Internet worm like Nimda, SQL Slammer, Nachi, etc. By the time that you have rebooted the system, it is already reinfected by another node on the network. There are no arguments from me that having a non-persistent OS does in fact make it easier to recover, but I'm not willing to go as far as to say it's the right way to deal with things. In addition, when we talk about the hybrid model where we are persisting some forms of application data in order to balance clean slate reboots with usability we introduce possible attack vectors where allow re-infection. Take for example, Office document templates. If you were to backup/restore Office document templates to provide higher usability, you create a location where malware can infect a clean system upon reboot as it reads it's normal.dot in from the restored template folder. The hybrid model does provide a better security benefit over the persistent model as there will inevitably be less locations of persistence, but if there is any persistence at all then we open up holes.
Will I get clean desktops every single day with the non-persistent model?

That depends. Some organizations are very good about forcing users to log off daily. Other organizations allow users to disconnect from their desktop and leave applications in a running state. I've worked in some customer environments where a user remained logged into their virtual desktop for nearly four weeks. If you don't have tight controls over user's getting out of the environment then those non-persistent desktops are effectively persistent for weeks on end. Again, while this is still better than a desktop that is always persistent, it's a far cry from the "new PC every day" that vendors often tout.

In summary, there are many different technologies that can be used to improve desktop security. Hopefully this series has helped you understand what the different options are and what some of the pros and cons of each approach are. While I personally love the concept of non-persistent desktops it's also something that is incredibly difficult to achieve within large organizations where I spend most of my consulting time. Also, non-persistent desktops only solve part of the problem and really doesn't address the core problem of trust and protection from malicious code. When the Internet browser and/or email client can be run offsite, it provides a nice level of isolation and abstraction for an organization but it also introduces it's own set of usability issues.

Today there is no perfect solution. There's a bunch of different options. You need to look at all of the options and balance them against your organization's level of risk acceptance and usability impact to determine what the right solution is for you. Nothing is guaranteed to be secure. All we can do is strive to make it more difficult for the hackers. At the end of the day, time is money. The more difficult it is to hack something the less inclined a hacker will be to spend the time to do so (unless you are a REALLY attractive target - then you need to rely on your information security practices to help you). Good luck…you'll need it!

Security by isolation methods: VDI and TS are not more secure than physical desktops, Part 4 of 5

Shawn Bass — Fri, 10 Aug 2012 04:01:00 GMT

If you read the last part of my "VDI and TS are not more secure than physical desktops" series, I left off discussing security by isolation. I promised that I'd discuss the different methods of security by isolation and how they help and hinder our two primary security issues: the Internet browser and the email client. If you missed it and need to catch up, check out the previous articles:

Matryoshka Dolls (aka Inception)

You may be wondering why I'm talking about Matryoshka dolls in a conversation about desktop security? Well, everyone knows what these dolls are. They are those cute painted wooden dolls that nest inside each other until you get to the very smallest doll inside. You can think about desktop security in the context of isolation in the same way. Isolation can be done at many levels and therefore there are potentially many isolations nested inside each other. So given that, let's talk about some of the ways in which security isolation can be provided to solve our issue of the security issues we face with the Internet browser and our email client.

There are four primary ways that security isolation can be provided. They are sandboxing, Microkernel virtualization, OS Virutalization, and Offsite OS Virtualization.

Sandboxing:

Sandboxing is a technology whereby the software developer creates an isolation container where untrusted documents / attachments can open. This isolated container is often a limited subset of what the rest of the application provides. This is done on purpose to limit the number of lines of code (or attack surface) that a malicious piece of code can exploit. Essentially the sandbox is assumed to contain malicious code and therefore it needs to be designed as restrictive as possible in terms of what code runs there.

Often the sandbox will also implement a policy engine of sorts that indicates what types of resources a sandboxed document at a particular level of trust should be allowed to access. Sometimes this is a restriction on operating system resources and sometimes it's implemented as an OS API hook to restrict or redirect API calls that are made by the sandbox in order to limit the damage that could occur as a result of malicious code that would otherwise infect the machine.

Sandboxing isn't perfect technology. It does, however, go a long way to provide a higher level of security. It is much less likely that the sandbox code will have as many vulnerabilities as the main application. Even though sandboxing does improve security, they are not flawless. There are ways to escape the sandbox and several hackers have done this on a variety of sandboxed applications.

Some examples of modern apps leveraging sandboxing are Google Chrome / Chromium, Adobe Acrobat 10.1+ Protected View, and Office 2010 Protected View. If we apply this concept to our two primary security issues of the Internet Browser and email attachments, we find that can provide some improved security, but since the sandboxes still run on top of an exploitable operating system we are only as protected as the sandbox can provide. Once something escapes the sandbox, the regular rules apply.

Microkernel:

Microkernel virtualization is a solution that leverages a hypervisor technology to create isolation environments in which application code can run completely isolated from the rest of the operating system. The hypervisor technology leverages hardware virtualization support from Intel and/or AMD and therefore provides lower level access controls than a typical software level virtual machine implementation or sandboxing. If done correctly, this means that the isolated code will have no way to escape the isolation environment unless it somehow compromises the hypervisor code itself.

A modern day example of microkernel virtualization is Bromium. Given that the microkernel code is much leaner than the entire monolithic operating system and given that the hardware assisted virtualization provides a hardware enforced isolation, it's much less likely that this solution will be compromised unless one of three things happen:

Someone discovers a weakness in the product's trust model. Like all products Bromium has a model that allows specific "trusted sites" to bypass the Bromium microkernel virtualization. If someone is able to compromise that trust model, then it's game over. This is the most probable attack vector because it can be done outside of the Bromium code weaknesses (i.e. within the host Windows OS). I'm unsure what specific protection mechanisms Bromium plans to leverage to prevent such an attack and I have not had the time to pursue how vulnerable the product is against this specific attack in my testing.
Someone discovers a weakness in the microkernel virtualization stack. This is the second most probable attack vector given that this software product is entirely new code and could of course have vulnerabilities itself.
Someone discovers a weakness in the hardware virtualization stack provided by Intel/AMD. This is the biggest risk not only to products like Bromium, but to all virtualization solutions and even to regular run-of-the-mill operating systems. This means that there is some vulnerability within the Intel-VT or AMD-V code itself that allows for either local privilege elevation and/or guest-to-host hypervisor escape. This sounds like a far-fetched reality, but in June a vulnerability (within Operating Systems and Virtualization stacks that run on Intel CPUs) was discovered and reported by Rafal Wojtczuk who currently works for Bromium. Details of this vulnerability are being presented at the Blackhat Security conference in Las Vegas this week.

If we apply micro-kernel virtualization to our original challenge with protecting the operating system from the Internet browser and email attachments we find that we can provide a much higher level of isolation that is far less likely to be compromised because of the added isolation provided by the hardware virtualization assist. That's not to say that this implementation model is impervious to an attack, but it provides a much better level of protection vs standard sandboxing.

OS Virtualization (or monolithic kernel isolation):

OS Virtualization or monolithic kernel isolation is a technology that should be familiar to everyone. It's your basic hypervisor implementation to completely isolate a running instance of Windows, Linux, etc. from other running instances of the Operating System. It covers both Type-1 (bare metal hypervisor) and Type-2 (host-based hypervisor). The basic premise of OS virtualization is that you run a completely separate copy of an operating system on the same piece of hardware. If we apply this concept to our original challenge with protecting the operating system from the Internet browser and email attachments we find that we could run out Internet Browser and our Email client within a completely separate instance of the operating system. If we do this, then that running instance of the operating system could be compromised without impacting our parent/host operating system.

Think about this for a moment. You can take a copy of Windows 7 and place it on your host hardware, then load up your favorite hypervisor and install another copy of Windows 7 inside the hypervisor. Now, perform all Internet Browsing and Email client attachment work inside this additional copy of Windows. If this additional copy of Windows is compromised, it will not affect your host operating system instance (assuming the exploitation isn't a guest-to-host escape as we talked about above. In addition, you could leverage snapshot/revert technology or write-filter VMs to ensure that every time this VM boots on your machine it is booting to a clean operating system.

This does not eliminate the chance that this VM will get compromised, it only means that if it does get compromised, you can power it off and power it back on and the malware code will be gone. Of course, if you continue to visit the same sites and open the same documents that caused the infection, then you will be continually "owned" every day that you use the VM. There are some weaknesses with this approach that you should be aware of as well:

Additional host PC performance impact - Any time you run a hypervisor with another copy of the operating system on it you are going to have CPU/RAM/DISK performance impact. You will want to have Dual/Quad core CPUs, at least 4 GB of RAM and preferably SSD drives to make performance acceptable.
Data interoperability - In the event that the attachments you've downloaded via email or the data that you're seeing on the Internet needs to used within the host operating system you will need to find a way to get that data out of the "insecure" VM and into the "secure" host OS. There are many ways to exchange data between host OS and guest VM, but the nature of doing this compromises the very model of security you were hoping to achieve by implementing OS virtualization for insecure resources in the first place. You may end up compromising the secure host OS by moving data from the insecure OS into it.
User Preference retention - While the email client may not be a big deal when it comes to retaining preferences, the Internet browser will be a bigger challenge. If you leverage the VM snapshot/revert technology or write-filtered disks then each time you power on the "insecure" browser OS you will lose Internet history, cookies, bookmarks/favorites, browser add-ons, etc. For most people, this is exactly what you want to have and it's the purpose of providing the isolated operating system. Still for the average user, this isn't very friendly and they will not appreciate the inflexibility provided by this approach. To combat this, you can implement a variety of technologies that allow you to persist specific pieces of data, but any amount of data persistence provides one more vehicle for a compromise to survive the "clean reboot" approach we are seeking.

Offsite OS Virtualization:

Offsite OS virtualization implies the exact same principles we outlined above with respect to leveraging a hypervisor solution of some sort to provide an insecure Internet browser and/or email client. The key difference with the offsite solution is that the running virtualized operating system is provided physically offsite from your hardware. This offsite location could be as simple as a separate network VLAN that has a security perimeter (or a DMZ) or it could be entirely offsite from your premise in a third party Cloud/DaaS provider.

A few examples of such a solution might be Desktone or Tucloud (both of which are DaaS solutions) or for a browser-only solution could be something like Authentic8. These solutions have one major distinct advantage and that is if the browser or email client is compromised, the vulnerable code is not running within your data center or on your local PCs. That code is executing in someone else's datacenter and therefore doesn't have an easy way of finding it's way to your important data. These solutions are designed to work over a display remoting protocol and therefore may have no direct network route back into your data center or PCs.

While these solutions provide a good level of isolation, there are a few things that you should be aware of as potential usability issues with these approaches:

User experience with display remoting protocol - Generally speaking display remoting protocols have improved a ton over the last few years and as long as you have decent internet bandwidth (2Mbit+) and low latency (<100ms) you should generally have a good user experience. However, if you are watching a large amount of fast moving content such as Flash, HD videos, etc. the experience may be less desirable than if that content were running locally. This should not deter you from these solutions though because there are many ways to address these issues. Speak to the vendors about your needs and try it out yourself to see if it works for you.
Data interoperability - Just as above, if we are leveraging this offsite hypervisor as a way of providing access to an insure VM, this isolation becomes a risk should be need data exchange between our host operating system and our remote insecure OS instance.
Application Interoperability - Often times in large organizations there will be line of business apps that need to interoperate with an email client or web browser. While there is absolutely nothing wrong with providing this integrated into the "secure" browser on their host PC, you may need to implement an additional piece of technology in order to control which websites can be accessed by the onsite "secure" browser vs the offsite "insecure" browser. The last thing you want is someone reusing a local secure browser to visit an insecure site. There are many ways to accomplish this and it's outside of the scope of this article.

Stay tuned for Part 5 of this article where I'll discuss the facts and myths around Persistent vs Non-persistent desktops.

Mitigation strategies for data security: VDI and TS are not more secure than physical desktops, part 3 of 5

Shawn Bass — Wed, 08 Aug 2012 04:01:00 GMT

If you read "Part 1: There's Only Two Types of Data" and "Part 2: Centralization Helps in Other Ways: of my "VDI and Terminal Server are not more secure than physical desktops" series you may have noticed that I ended them without providing advice on how we can reduce the data security risks. Your wait is over!

Look at this cool wooden horse we made for you…

According to Greek folklore, during the battle of Troy the Greeks withdrew from Troy after delivering a large wooden horse. The Trojans believed it to be a peace offering of sorts and towed it inside the city walls of Troy. After the Trojans went to sleep, approximately 40 Greek soldiers emerged from the giant wooden horse and opened the gates of Troy where the rest of the Greek army was waiting. The army easily overran the Trojans and claimed victory over Troy.

In modern day terms a Trojan Horse is a piece of computer software that the end user believes is a legitimate piece of software or a document that they actually wanted. Instead the software or document has malicious intent that can range from stealing information such as software licenses, banking account information, website passwords, etc. Trojans often will control the PC from that point forward (becoming a "zombie" PC) receiving command/control instructions from central system(s) on the Internet. Collections of these "zombie" machines are called Botnets and in many cases contain millions of PCs.

How computers get compromised

Most computers will get compromised by one of the following methods:

Downloading software that contains a virus/trojan horse. This method can largely be prevented by not allowing users to install software and locking down their PCs.
Inserting a removable storage device that contains a virus/trojan that executes automatically upon insertion of the drive. Even though the user may not intend to invoke the software there are many ways to compromise various operating systems simply by inserting media into a PC.
Opening an infected document. A very common exploitation vector for viruses / trojans over the last few years has been opening documents such as Office documents, JPG/PNG images, PDF Documents or ZIP libraries. There has been massive investments by Microsoft, Adobe and other vendors to try and sandbox their software to reduce the likelihood that their software will cause the compromised entry point of the PC. This remains the largest security concern for targeted attacks since an attacker can do research on people that work at a particular organization, discover their email addresses and then deliver a spearphishing attack via email. Through some effective social engineering, this can be a highly effective means at getting directly to the source of information you are trying to obtain. Also, through the use of new unknown zero day attacks, the recipient of said exploit will be largely unprotected against it by any means of A/V, HIPS, IDS, etc.
Visiting a compromised website. Drive-by downloads, client-side Javascript, XSS, CSRF, etc are all forms of web-based attack mechanisms. While each of these attacks differs by the amount of potential damage it can cause on a system, in all cases information security when it comes to browser is completely compromised.

Of the above methods, the opening of a document file (usually delivered via email) and the attack delivered via the web browser are the most common security risks we face today.

Does it matter where the PC is located for these attacks?

It is almost completely immaterial where the PC is located for one of these attacks to be successful. A user could be on a VDI desktop in the data center or they could be on a laptop connected over a 3G connection via a tethered cell phone. If the exploit code is a few megabytes worth of content embedded into an email attachment it will execute the same way whether it has a Gigabit connection in the data center or a latent crappy mobile network connection.

Once the machine has been compromised, the data center connection certainly makes it easier for the attacker to reach hundreds if not thousands of other machines inside the corporate network (assuming you don't isolate systems). However, these machines could also be accessed over a 3G connection or a home DSL/Cable connection as well. Modern day attacks will often be created to not port scan a network aggressively because attackers know that serialized port scanning at a high rate will be caught by an IDS system. Instead the attacker will use randomized port scanning or even manual efforts to avoid detection. So while there are people out there that insist that being in the data center increases your risk, that's just plain FUD.

So how do we improve security against the email/browser threat?

Joanna Rutkowska has a great blog article that talks about the three main ways to implement security. I encourage you to read the whole article, but in short here's a summary of the three ways we can try to implement security.

Security by Correctness - Security by correctness means we shouldn't create software bugs in the first place. This is obviously a very difficult thing to do. If it wasn't hard to do then there literally would be no security software/hardware companies in the first place because there would be nothing to prevent attacks against. Software developers are human and they make mistakes. Because of that, we can't count on this resolve our issue.
Security by obscurity - Security by obscurity is all about creating methods to make it more difficult for an attacker to compromise a system by known weaknesses. Examples of this method are things like code obfuscation which makes it more difficult for an attacker to reverse engineer someone's code by mangling it so it's execution is not as easy to follow within a debugger. Another example of a security by obscurity solution is Address Space Layout Randomization (ASLR) which is designed to allow code to load in "somewhat random" addresses within memory in order to prevent a predictable memory loading address which would allow an attacker to more easily perform buffer overflows, etc. While security by obscurity solutions do improve security, we can hardly count on this to resolve all the issues.
Security by isolation - Security by isolation is exactly what it sounds like. Find a way to isolate the resources that would be exposed to an attacker when the code in question executes. If you find a way to create a secure perimeter around a piece of code, then you potentially mitigate the risks of running that code on your system.

Security by isolation provides the best method of defense and can be implemented in a number of different ways. Stay tuned for part 4 where I'll discuss the dif ferent methods of security by isolation and how they help (and hinder) our end users.

VDI and TS are not more secure than physical desktops, Part 2 of 5: Centralization helps in other ways

Shawn Bass — Fri, 03 Aug 2012 04:01:00 GMT

If you read Part 1 of my "VDI and Terminal Server is not more secure than physical desktops" series you may have noticed I left off discussing how VDI/TS doesn't improve data security. So if centralization doesn't help with security, what does it help with?

If you are able to centralize your data there are several benefits, they are:

Collapse branch infrastructure - If you are successful at deploying VDI/TS at large scale you can probably collapse branch office file/print servers, email servers and maybe even app servers.
Data sharing - If all over your data is in one location, it will be much easier to share data among users without needing to worry about delays transmitting that data over WAN connections or having to worry about replicating data in multiple sites.
Data backup - If you data is located centrally it will be much easier to backup data and configure offsite data backups. If you data was spread over 100 different sites, you would potentially need multiple backup systems and multiple DR strategies.
eDiscovery - If you organization requires eDiscovery for audit purposes, having the data in one place makes this slightly easier. You will still of course need to address eDiscovery on any laptops, smartphones, tablets, etc. But it does make it a bit easier.
Proactive response to security incidents - If you deploy VDI/TS and all of your desktop operating systems are running in a centralized data center (or regional data centers throughout the world), then patching those Windows instances is able to be done more rapidly, distributing A/V signatures, HIPS agent updates, etc can be more rapidly accomplished than if those assets were spread over WAN links or frequently disconnected from the network as in the case of laptops.

The problem is, data centralization is really tough to achieve these days…

In the first part of this article, I said I've been working with this technology for 20 years. Twenty years ago, few people had personal computers at home. Even fewer had any form of hooking those computers up to other computers. I've been around a long time and had multiple different models of modems all the way from 300/1200 baud up through 56k baud modems before I moved into ISDN/DSL/Cable, etc as the Internet started ramping up. Back in early 90's there was very little exchange of files between people. Most data was exchanged on floppy disks, there was no Internet at that time and the only public exchange mechanisms that existed were BBS's, CompuServe, AOL, Prodigy, etc. The threat of viruses/trojans were minimal. Obviously the Internet changed that. The Internet changed it fundamentally in two ways:

It was much easier to share data with people (especially sharing data [read: malware] with people who should be smart enough to know that they shouldn't be opening your attachment.
An always online state for computers.

Since the advent of the Internet, most computers are always connected. Unsolicited emails come by the thousands. Web site drive by downloads are commonplace. But these things are only half of the data security problem that we're talking about. The other issue is loss of control of data. The rise of web/cloud technologies like cheap email (Gmail, hotmail, etc), SaaS-style applications like DropBox, Box, SpiderOak, Skydrive, SugarSync, etc means that it's trivial for a user to get data outside of your organization and into locations where you can't possibly protect it, much less audit its use. The rise of smartphones and tablets means that your end users are going to want to have access to their data when and where they want it. Whether you think you can control their use of data or not, chances are you will fail at this.

It's really a matter of trust...

Trust is a term that is tossed around the technology world every day. Do you trust this EXE to run on your computer? Do you trust this website to have more privileged rights on your PC? Do you trust this Word document I'm emailing to your computer? It also extends beyond the desktop that we try to secure. Do you trust your users to not take company data off company computers? Do you trust employees to use best practices to secure their home PCs that you provide remote access from? Do you trust your A/V vendor is keeping up with the latest threats? Do you trust your banking institution is doing everything possible to protect your financial information? Do you trust Apple, Google, Amazon, etc. with your credit card information (for App Store purchases as well as NFC implementations), your email security, your browsing experience?

The problem is the trust model is broken. It's not broken a little, it's broken a lot. The entire SSL/CA infrastructure is flawed and has already been exploited multiple times. The simple reality is that we can't rely only on Anti-virus companies or security vendors to install software that will try to intercept bad software before it can cause damage. If we take this approach, it's already too late. Two factor authentication is a really good security practice that can improve the probability that the person using an operating system or website is in fact the real user. Well that's true as long as we can be sure that our two factor authentication solution hasn't been compromised *cough* RSA *cough*. Again, it's all about trust. If we trust our two factor vendor, then we make an assumption that this two factor vendor has security practices in place to prevent the two factor security solution from becoming compromised. If that's not that case, then we've placed too much trust.

By the way, I want to make absolutely clear so that no one thinks I'm picking specifically on RSA or Windows here. Windows has had it's share of security issues over the years, but Apple OS X, Linux and other operating systems are not flawless either. They have their own security faults and incidents. The reason why Windows is such an attractive attack target is because is had 90% market penetration. If you are an exploit writer and you want to be able to compromise a remote company, of course you're going to write an exploit for the operating system they are most likely to be running. As Apple's popularity increases over the years and as smartphones become the dominate access device I'm sure you'll see tons of OSX, iOS and Android exploits become the norm going forward.

So if we can't trust anyone, what do we do?

Stop using the Internet.

All joking aside, this would fix the trust problem. If you never opened an email, never opened an attachment or never browsed and website and turned off your network connection you'd probably be good. Since most people are probably rolling their eyes at this point because they recognize that this isn't practical, we need to start discussing ways that we could potentially reduce this risk. Notice I say reduce and not eliminate because I think information security is all about providing the least probable attack surface. You'll never completely eliminate security risk. Where there's a will there's a way.

Stay tuned for Part 3 where I'll talk about mitigation strategies for data security...

VDI and TS are not more secure than physical desktops, Part 1 of 5: There's only two types of data!

Shawn Bass — Wed, 01 Aug 2012 04:01:00 GMT

For almost 20 years now, I've been implementing Terminal Services and VDI solutions. During that time, I've spent a good deal of time speaking to people about the benefits of these solutions as well as implementing it for customers. There are numerous benefits of a centralized compute model and I'm not going to go into all of the benefits in this article. When presenting or consulting on TS/VDI I'm often telling people that centralized compute (be it Terminal Services, VDI or even a PC farm) does not implicitly provide any higher level of security than doing distributed compute model of standard desktops and laptops. This often puts me in the crosshairs of all sorts of TS/VDI related vendors who are using security as one of their main selling points of their solution. Hopefully after reading this series of articles, you will have a better understanding of where I'm coming from when I make these statements.

There's really only two forms of data

To start off, I will grossly over simplify security and focus solely on that of data security. To me, data security is what we're ultimately concerned about. It doesn't matter how someone breaks into a system, because at the end of the day all we are concerned about is what that person (the hacker or thief) makes off with. Whether they acquire one's banking account number, passwords, social security numbers, plans to latest Air Force jet, etc it's all data. Data is important to us and should be the primary thing we are most concerned with protecting. To that end, in my oversimplified version there are only two forms of data:

1. Data at rest

Data at rest refers to data stored on some form of medium whereby the system that would access that data is currently powered off. The best way to think of data at rest is a desktop or laptop with data contained on the C: drive of the system, but that the operating system is powered off. Data at rest could also refer to data stored on removable media that is not inserted into a system, or it could refer to data stored on a centralized file server of SAN that is powered off.

NOTE: It is particularly important to focus on the fact that the system accessing this data is powered off because if it is in a sleep/hibernate state then this potentially means that disk encryption keys can be compromised on this system which ultimately will provide access to this data at rest. Centralized compute solution like Terminal Services and VDI can provide a model in which the endpoint system accessing the centralized compute has no data stored on it's local disk. If this is the case, then there is no data at rest on the endpoint and therefore VDI/TS improves data security at the endpoint by not having the data there in the first place. This is the main selling point that VDI/TS vendors make when promoting their solution. However, it's honestly the smallest piece of data security that one needs to be concerned with. It's a gross exaggeration for a few reasons:

Whole disk encryption products have been out for years now and given that a majority of federal, state, local governments require disk encryption on endpoint systems this is becoming less and less likely as a vehicle for loss of data when an endpoint is lost/stolen.
The proponents of improved security through centralized data often ignore the fact that while they *think* the users do not have any data on their endpoint, they can leverage things like Client Drive Mapping through TS/VDI, email forwarding, Dropbox like Cloud storage solutions, Evernote/OneNote, etc as a means of get data out of the central secured corporate environment and onto a platform where the end user can access it. Therefore, by *assuming* you have data security because it's centralized, you're simply living a lie. Pundits would say "You could just use firewall/proxy blocking, web filtering software, Systems Management Agents, DLP agents, and this and that ad naseum" and to those people I'll just say "Good luck with that and let me know how that works out for you" ;) Not surprisingly the people advocating this approach probably work for one of the vendors of said "security" software/hardware.

2. Live data

Live data refers to data stored on some form of medium whereby the system that would access that data is currently powered on. Given the scenario that we're talking about a VDI or TS desktop that is powered on with a user connected to it, then everything on the C: drive of that system as well as anything that system has access to on the network becomes Live Data. The data is called live because even if you have a whole disk encryption solution active on the disk volume that system is using, the data must be live unencrypted in order for the operating system to access it. There are ways of having separate data encryption that protects file systems after the operating system is booted, but again once I decrypt the data volume to read or write data to it, then the data becomes live data and can be compromised by anyone who controls my operating system. Compromise of live data security is the biggest information security risk that we face today.

The data loss that happens from the "data at rest" scenario above is just due to people doing stupid things like not putting whole disk encryption on their laptops. When it comes to live data security compromises, it becomes a much more difficult thing to protect against. Look at any of the recent high profile compromises in recent years and they are all being identified as an "Advanced Persistent Threat" or APT. APT isn't a new concept necessarily, it's simply a new term to describe a high level of sophistication of attacks.

Years ago, the biggest threat that the virus/malware companies were protecting us against were things like Internet worms, mass mailers, trojans, etc. There's still tons of that going on today, but the A/V companies have a good handle on this for the most part. If, however, you are a financial services firm, a Government Defense contractor, etc you have something more valuable than a bunch of zombie PCs. You have data that worth a lot of money to thieves, competitors or even foreign nation states. Live data compromise is without a doubt the biggest information security risk we face today. Deploying VDI/TS in your own data center, doesn't provide any innate benefit that addresses this particular threat. A Windows PC can be compromised in a data center just as easily as it can be compromised in the field.

At best, VDI/TS provides additional places where security *may* be able to be improved. But again, centralizing the data doesn't bring those benefits. Only after applying several defense in depth measures will you reach any higher level of detection/response capabilities. Let me very clear too that all these measures do is provide detection/response. They don't prevent the security risk, they only help you assess and respond faster.

Check out part 2 of this article where I'll discuss what benefits VDI/TS does provide

Citrix revises end of life dates for XenApp, but what does that really mean?

Shawn Bass — Thu, 05 Jul 2012 04:01:00 GMT

Back in January I wrote a blog article called "Citrix plans to end support for XenApp 6.0 in 2013. What's that? You're still migrating to 6.0?" which received over 20 comments and over 15k views. For some, it was a bit of an eye opening as they were not aware of Citrix's lifecycle retirement plans for XenApp. For others who knew about the plans, it was an opportunity to voice their concern over early retirement of the XenApp add-on for a Windows Server product that still had plenty of life left in it. I highly encourage you to read through that blog to get a better understanding of what was happening with XenApp product lifecycle. The best part of this blog article is that Citrix did take notice and did post a response to my blog openly seeking feedback from customers.

Not long after that blog went live, I had several private conversations with people from Citrix who wanted to better understand what the concerns were from the community with respect to these end of life dates. I tried to make it clear that the primary issue with the lifecycle is for larger enterprise organizations where a XenApp upgrade project might occupy anywhere from 6-18 months of effort and the frustration level that once that upgrade is complete you're immediately launched into another upgrade to move yet again. Let's face it, there's a lot of frustration out there that isn't entirely Citrix's fault, but has more to do with the industry in general struggling to figure out the move to 64-bit Windows as well as dealing with security enhancements in Windows that are causing lots of problems for old, legacy crappy applications. As someone who has spent many years working in large organizations I can bring out hundreds of horror stories of bad applications, but that's for another blog.

Citrix Responds!

After having the private conversations with Citrix, I half expected it to fall upon deaf ears and never go anywhere. To my surprise, the exact opposite happened and Citrix did actually take this into consideration and in May 2012 released a revised Product Lifecycle for XenApp on their website. This revision to the product lifecycle was accompanied by a blog article by David McGeough named "XenApp Lifecycle Policy Extended" explaining the basics of the revised policy. Given the revised dates involved, it may be a little difficult to understand where a Citrix product ends support vs. where a Microsoft server OS ends support and therefore it may be helpful to view all of this in an overlaid form. Gabe Knuth put out a great blog article "Citrix XenApp and Windows Server support and End of Life timeline" that helps to visually understand where these overlaps occur.

A rose by any other name would smell as sweet...

While I'm personally thrilled that Citrix reviewed their lifecycle policy and has extended their support phases to be more inline with Microsoft's policies, I think it's important to look at what these policies involved to see whether or not they match functionality.

Citrix End of Life

According to Citrix's lifecycle milestones definition website, End of Life is defined as "The date that signifies when security related hot fixes, technical support and product downloads will no longer be available. Technical support for other issues will be limited to information contained in the Citrix Knowledge Center and Support Forums. If the issues cannot be corrected through this method, then an upgrade path or migration to the latest version or product replacement is recommended. The EOL date will be a minimum of six months from the EOM date; however, Citrix reserves the right to change the timeframe at its sole discretion based on business needs or technical risk for customers." Which basically means that you won't get any security hot fixes, nor will you get regular paid support. In order to get support on the product, you will need to enter an extended support contract with Citrix. This means it will cost you a lot of money to get support on the product.

Citrix End of Extended Support

According to Citrix's lifecycle milestones definition for EOES website, End of Extended Support is defined as "This milestone signifies when a specific product release will no longer be covered under the Extended Support Program. The EOES milestone for a Citrix product version is intended to align with Microsoft's current End of Extended Support milestone for the corresponding server OS version. This should enable customers to plan their XenApp migration as part of the underlying OS migration planning. The Extended Support Program puts customers in control of their upgrade strategy by offering technical support and maintenance after the End of Maintenance (EOM) milestone. Refer to the Software Support Programs page for details on the Extended Support Program and other Technical Support programs applicable to this product." Which basically means this is the complete end of any form of support for this product, whether under a special paid support contract or not. The verbiage here seems to indicate that the Citrix EOES is aligned with Microsoft's end of support on the core server platform product, so let's look at that next.

Microsoft Mainstream Support

According to the Microsoft Support Lifecycle website, Mainstream Support entitles a customer to the following items: Request to change product design and features, Security Updates, Other hot fixes (bug fixes), Complimentary Support (when included with product or license program), Paid Support (per incident or Premier/Essential Support). Basically everything is up for grabs during the mainstream support lifecycle.

Microsoft Extended Support

According to the Microsoft Support Lifecycle website, Extended Support Phase entitles a customer to the following items: Security Updates, Paid Support (per incident or Premier/Essential Support). So the key differences between Mainstream Support and Extended Support is that in extended there is no longer any free support provided, there are no non-security related hot fixes offered and a customer cannot offer suggestions to change product design (duh!). If there is any ambiguity about this, review this TechNet blog article "An explanation of the Extended Support phase for Business & Developer products"

Now that we've broken down each of these support phases, let's take an example of how this might apply to a product such as XenApp 6.5 (I won't pick on XenApp 6.0 as I realize everyone seems to want that one to die).

Citrix lists the End of Life for XenApp 6.5 as January 4th, 2016. That seems like a nice end of life date and means we have another 3.5 years of working with XenApp 6.5 before it goes away. However, come January 2016 we won't have any security hot fixes for XenApp 6.5 nor will we have any per incident paid support options. You could certainly choose to purchase an Extended Support contract from Citrix, but that would be your only way to receive support on this product after that date. XenApp 6.5 runs on Server 2008 R2. From a Microsoft perspective, that product receives it's end of mainstream support on July 9, 2013 (so next year right around this time). However, Microsoft provides Extended Support for Server 2008 R2 until July 10, 2018 (6 more years from right now). What is the key difference between what Citrix is providing vs. what Microsoft is providing? It's two things: 1) Security related hot fixes. 2) Per incident paid support. If you're not a huge organization that can't afford a very expensive extended support contract it's nice to know that you can still get per incident paid support from Microsoft even if it costs you a few hundred dollars each time.

This doesn't necessarily mean that Citrix has to change their policy on this subject. We all want Citrix to continue to innovate as fast as possible and move this technology forward. I do think it's important for people to understand exactly what support they are able to receive on the product and how those support offerings are different between Microsoft and Citrix. Microsoft has probably one of the best Tech Support groups in our industry bar none. It would be extremely difficult for Citrix to compete with that. However, you should be aware of what you receive with both parties in order to ensure you can support whatever platform you deploy within your organization and that you plan appropriately to move off the products in time to retain the support that you need. Hopefully this article helped you better understand those positions.

Why thin clients and zero clients haven't lived up to the "last PC you'll ever buy" hype. (Part 1 of 2)

Shawn Bass — Mon, 06 Feb 2012 05:01:00 GMT

I've been collecting thoughts on this blog article for a few weeks now. It seems this was quite timely given Brian & Gabe's recent interview with Tom Flynn from HP where they talked about thin clients, zero clients, etc. Here are my thoughts on the topic.

If you've been around the SBC / VDI industry for any length of time, you should know all about thin clients. Thin clients were the devices that were going to usher in the end of the PC industry as we know it. The benefits of a thin client over a full-fledged PC are numerous (in principle), including:

Less moving parts = less component failures

Not having a spinning hard disk is one major reason why thin clients should have a longer life. If you look at the failure rates among PC components, hard disks rank as one of the highest failure rates among the components that make up a typical desktop PC. Look at this chart from a Carnegie Mellon University paper on the topic of component failures in PCs published in 2006:

Source: Parallel Data Laboratory - Carnegie Mellon University

While hard drive manufacturing practices have improved since 2006, the rate of failure vs other system components is still pretty much the same. Changing the spinning hard disk to an SSD drive may ultimately improve the reliability (though that is currently being debated as to whether or not it actually reduces failure rates) but it certainly won't help the cost of the PC devices. Thin client manufacturers must keep costs down in order to be competitive against a common PC that it's attempting to replace. By a thin client not having a hard disk means they have one less component that has a high failure rate and ultimately it means less power consumption as well.

Less Power Consumption

Typical thin client devices consume anywhere from 2-10 watts. With a typical PC systems consuming anywhere from 20-60 watts it's pretty clear why an organization would want to standardize on thin clients vs full blown PCs because power consumption translated to real cost savings. Now, in order to say that thin clients are more cost effective than PCs when looking at power consumption one must also compare the back end infrastructure power costs when calculating power savings, but in most cases you can still save power even with the back end infrastructure considered.

Less Cost for i.m.a.c.

No I'm not talking about Apple's latest all in one PC. i.m.a.c. is an acronym that stands for Install, Moves, Adds, Changes. Arguably a thin client substantially reduces the amount of time it takes to deploy an asset, move it from one place to another, swap out a failed one, etc. Just because you've made the endpoint device super easy to manage does not mean you necessarily have made the desktop management method any better. Therefore, implementing thin clients to replace PCs does not eliminate the burden associated with managing the Windows instances unless you've take steps to minimize the administration of your windows instances through things like PVS, Common Image, Layering, App Virtualization, User Virtualization, etc. That being said there will still be time saved in the actually effort require to deploy the asset itself.

"The Last PC you'll ever buy!" Really?

"The last PC you'll ever buy" was a common sales tactic among early thin client manufacturers and yet that never did happen. There are several reasons why this never happened:

Relative Immaturity of Remoting Protocols and Fragmentation

In the early days of Citrix WinFrame, Citrix did a pretty efficient job at remoting basic Windows applications. The reason for this is a majority of Windows applications were made up of GDI objects painted on the screen with a handle of bitmap graphics here and there. Animation and video were almost non-existent and even graphics were fairly simple in terms of dpi and color depth. Citrix had a technology within ICA that allowed for a Terminal Server host to send down graphics commands a primitives to the endpoint device. You can think of GDI primitive remoting like this. Let's say you want to create a Window in a Windows app that creates a display area that is 800x600 pixels with a scroll bar, maximize/minimize/close buttons, etc. When that Window is displayed (or painted) it's done so using a set of Windows APIs used for painting GDI objects. Once those items are to be painted on the host system, you need to find a way to get them to display on your remote client device over your remoting protocol. This can be done one of two primary methods:

Intercept the API call to paint the window and transmit it to the client device where that local operating system will in turn process the API call to paint that object in that position. This is GDI primitive remoting.
Bitmap Remoting is the other method for getting host screen content onto the client device.

Bitmap remoting is, for a lack of a better term, taking a screen scrape of the host side system and then sending that graphical image down the the client device to be displayed. GDI primitive remoting turned out to be the best way to display static screen content onto a remote system and it worked very well over limited bandwidth connections that were quite popular in the days of dial-up modems.

The ability to do GDI primitive remoting only worked on a system that could understand painting GDI objects. Windows-based thin clients could do this. Linux thin clients could not and therefore Linux thin clients would always receive a host rendered bitmap object rather than a GDI primitive. This took more bandwidth on the wire and didn't look quite a fluid as GDI primitive remoting. In my opinion, this is the reason why Linux-based thin clients never really took off well early on. Having multiple different client operating systems with different rendering capabilities also leads to fragmentation in terms of what is capable on which operating system. This fragmentation creates a lot of confusion among customers about what capabilities of the remoting protocol they are going to be able to take advantage of. This fragmentation is also present in areas like printing support, too.

Application & Web UI Complexity

Application and Web UI in the early days was quite simple. It was often quite easy to achieve very efficient rendering of ICA traffic with very little bandwidth. However, in the early 2000's more an more of the web started to contain animated GIFs, video, Flash, etc. Years later other technologies like Silverlight, HTML5, etc continued this trend. Due to this graphical richness, the capabilities of the endpoints needed to evolve in order to cope with the demands of this higher level of graphics performance. Unfortunately in the case of thin clients, the CPUs weren't up to the task and since most of them lacked a GPU there was no ability to offload to GPU to assist in the graphics processing. Thin clients were hardly the last PC you'd ever buy.

Commoditization of the PC

When PC devices were selling for $1000-$1500 and thin clients were available for around $600-1000 it seemed quite compelling to go the route of thin clients and get rid of those fat clunky PCs. However, something remarkable happened to the PC market. It quite literally collapsed. PCs became commodity. With that commoditization, the market for thin clients eroded. It's not uncommon today to have a full blown business PC available for purchase for around $400-600. The thin client market is all over the place and there are some thin clients available for as low as $100-200, but the premium thin clients are still in the $400-$800 range. Given that a PC is quite cheap and the desktop management tools are quite good, it becomes a difficult struggle to recommend thin clients in the face of a well-managed desktop. What doesn't help this fact is that thin clients still require management themselves. Thin clients still have software on them. Software that has to be updated for security vulnerability as well as software enhancements to support the latest /greatest enhancements from Citrix and other vendors. The software process to update thin clients is of course completely different than the process of updating software on existing desktop PCs. Unless you were successful at switching to thin clients for 100% of your users, you now have a fragmented management strategy where you now have to keep two systems management products in place. Also, some thin client manufacturers charge additional money for their thin client management platform.

Thin Clients are NOT future proof 

One of the long standing myths about thin clients is that they are "future proof" and have a 7-10 year life vs a PC that only has 3-4 years of life. Ask the people who bought the Wyse Xenith felt when the Xenith Pro was launched. The bottom line here is that a thin client is only as future proof as the components contained in the system. If the thin client manufacturer cuts corners and puts a low performance Via, ARM, Intel chip in the system or a low end graphics processor chances are that thin client has no greater lifetime than that $300 Dell PC you can buy online. In reality, the Dell PC probably has a long life from a capabilities perspective.

Enter the HDX Ready Thin Clients

Given the concerns I outlined above, Citrix embarked upon a marketing campaign in 2009 that included a component called HDX Ready to denote thin clients that met a minimum set of system specifications that would result in a good user experience when used with XenDesktop 4. Citrix began calling these thin client devices Desktop Appliances to separate them from the perception that a thin client was an underpowered device. All the HDX Ready certification really means is that the thin client device has a higher level of CPU/GPU power to support modern "high definition" desktop experiences. Again, this was really a marketing campaign about distancing HDX Ready thin clients from the legacy bunch of thin clients that were not high powered enough to run a "high definition" user experience. The biggest issue that plagues these "HDX-ready" thin clients depends on your definition of HDX. The important thing to take away from this is that "HDX is not HDX and not HDX". What I mean by this is several of these "HDX" thin clients only support a subset of features present in HDX. Check with your vendor to see whether or not they support UPDv3 printing. Since that solution is based on a Windows EMF driver, chances are that Linux based thin client won't support it. Maybe a big deal to you, maybe not. What about Flash redirection, etc? Do you homework carefully. Bottom line, HDX ready is nothing to see here folks.

Enter the Zero Clients

What's a zero client you ask? Ummm that's kind of a difficult thing to answer because it sort of depends on whom you ask. In reality there's two types of zero clients out there today.

True Zero Client

A hardware thin client device that does not contain firmware (aka software) that you need to update. One device in this class is the Pano Logic devices.

Psuedo-Zero Client

A hardware thin client device that does contain firmware, but doesn't leverage the traditional firmware update procedure but rather updates its firmware by receiving it via PXE. Wyse introduced the Xenith Zero Client at Citrix Synergy in 2010 that was this category of Zero client. This doesn't technically qualify as a zero client as there is still a software stack on the devices that you need to update. However, given the ease at which you can update the software it certainly makes it simpler than the traditional firmware update methods that have made thin clients difficult in the past. One big risk that you need to be willing to accept when adopting this form of zero client is that you thin client infrastructure is now heavily dependent on availability and health of your PXE services for their updates.

Enter the Citrix HDX SoC (System-On-Chip) Thin Clients

Lots of clients and associates have been asking me for my thoughts on the recently announced HDX SoC design. That will have to wait for Part 2...

Stay tuned..

Citrix plans to end support for XenApp 6.0 in 2013. What's that? You're still migrating to 6.0?

Shawn Bass — Tue, 17 Jan 2012 06:04:00 GMT

A few months ago Andrew Wood wrote a nice blog article about the end of life of a number of key XenApp-related products, and it reminded me of some conversions I've been having with a number of my customers about this topic.

Like all big vendors, Citrix maintains a product support lifecycle policy for XenApp (as well as all of their other products). The current lifecycle timelines are available at CTX122442. I'm not going to spend any time in this post discussing the differences between End of Sales (EOS), End of Maintenance (EOM) and End of Life (EOL) as Citrix's Jeff Muir wrote an excellent article describing all of this in great detail.

Instead, the main point of this article is that Citrix would like all of their customers and partners to cease using XenApp 6.5 Beta (err, I mean XenApp 6.0) by July 2013. In addition, they'd also like you to stop using XenApp 4.5 and 5.0 as well. What does this mean to us?

It means that you have exactly 17 months from right now to architect and migrate your existing Citrix infrastructure from XenApp 4.5, 5.0 and 6.0 over to XenApp 6.5.

I see several major problems with this and I'd like to break the discussion down into three separate parts. They are:

End of life of XenApp 4.5 on Server 2003

End of life

Server 2003 SP2 is officially end of life by Microsoft on July 14th, 2015. Citrix ends support for XenApp 4.5 on March 31, 2013. This means there's a 27 month window between when Citrix drops support for XenApp 4.5 and when Microsoft stops supporting the core platform. There are some legacy apps out there that won't run on Server 2008 in 32-bit mode let alone on Server 2008 R2 which is 64-bit only. For the customers stuck with these legacy apps your solution is either to migrate to a pure RDS environment or migrate away from Citrix and over to Quest or another competitor if you can't get your legacy apps off XenApp 4.5 by then. Of course you can buy extended support from Citrix for 4.5, but I'd rather migrate off from XenApp and buy a few Ferraris with the spare change left over ;)

Server 2003 is rock solid!

I've been happily running XenApp 4.5 on Server 2003 in many customer environments and the reality is that is that it is just a rock solid platform. Barely any Citrix related stability issues, barely any OS-related stability issues (ok ignore print drivers for a moment). XenApp 4.5 just runs and runs. Compare that with XenApp 5.0 on Server 2008 and XenApp 6.0 on Server 2008 R2 which were substantially poorer code quality from my perspective and XenApp 4.5 on 2003 looks like the platform of choice as long as one can milk it for.

IE6

Perhaps a small problem for small and medium customers, but quite a bit problem for Enterprise customers with old crappy apps. IE6 is a big problem because it only runs on Server 2003 and isn't available to install on Server 2008 or Server 2008 R2. So if you have some legacy apps using IE6 your only option is to stay on Server 2003 with those apps. For that situation, I'd strongly recommend talking to Quest about their extremely low cost RDS solution specifically designed to support IE6 dependent apps.

Migration

As long as you're running HRP5 for XenApp 4.5 (ok "XenApp 5.0" is what Citrix calls it, but it's 4.5 seriously), you can leverage Citrix's XenApp 6.0 migration tool CTX125471 if you're planning on moving to XenApp 6.0. The migration tool will help you move over published applications, policies, etc into XenApp 6.0. It's command-line based rather than GUI-based, but it does the job. Alternatively, if you want to move right to XenApp 6.5, the built-in Migration Center utility is a GUI based system that allows you to migrate from XenApp 4.5 HRP5+/2003, XenApp 5.0/2008 or XenApp 6.0/2008R2 to XenApp 6.5.

These utilities are designed to be used in parallel farm migrations. You cannot mix farms between 4.5/5.0, 6.0 and 6.5 so you must build the systems in parallel and then use Web Interface to aggregate the two farms together. There is one other option for migrating XenApp 6.0 to 6.5 in place, but I'll discuss that in the XenApp 6.0 section below. By far the most difficult part about a migration from 4.5 to 6.0/6.5 isn't the actual Citrix pieces because you probably could reconstruct all of your published apps and policies in a weekend if you really needed to. The biggest challenge in this migration is whether or not your apps are compatible. Moving from XenApp 4.5 where a majority of farms were deployed on 2003 32-bit to 2008 R2 which is 64-bit presents a number of challenges such as OS compatibility, 32-bit vs 64-bit challenges and new security technologies within Windows Firewall, UAC, DEP/ASLR, UI0Console Detection, Windows Resource Protection, IE8/IE9 compatibility and security restrictions, CredSSP, architectural changes to service privileges, etc. Most likely you'll spend a bulk of your project time just testing and remediating your applications. BTW, it might be a good time to look into the recently acquired Citrix's AppDNA solution or Quest's Changebase as tools that can help you with some of this analysis and remediation work. Neither tool is perfect, but if you have a ridiculous number of apps and no time to conduct full blown testing, then the tools will be of great value to you during your migration.

End of life of XenApp 5.0 on Server 2008

End of life

Server 2008 is officially end of life by Microsoft on July 10, 2018. Citrix ends support for XenApp 5.0 (2008) on July 15, 2013 (yeah 3 months after 4.5!). This means there's a 60 month (or FIVE YEAR!) gap between when Citrix drops support for their platform versus when Microsoft ends support for the core platform.

Not a big surprise

Not too many customers adopted XenApp 5.0 on Server 2008 and ultimately that was probably a good thing. It wasn't the most stable platform and 2008 R2 was so quickly behind Server 2008 with a completely different architecture that it was only a matter of time before this platform would be doomed to be replaced by 2008 R2. I feel like this would have happened very rapidly if 2008 R2 wasn't 64-bit only which I think severely limited it's uptake in the early days. Ultimately XenApp 5.0 on 2008 is sort of the ugly duckling at Citrix that never turned into a swan. Why was 5.0/2008 such a bad platform? Aside from what I've already mentioned regarding 2008 R2 being right behind it, it still suffered from some architectural changes that introduced app compatibility issues along with the fact that Citrix was late delivering XenApp 5.0 by about 3 months past their intended release date and about 6 months after the release of Server 2008. Also, several new enhancements/features that were delivered in XenApp 4.5 lagged behind on their 2008 counterpart until later Feature Releases. I believe all of those things contributed to slow adoption of XenApp 5.0 on 2008, but the heads up that 2008 R2 was right around the corner was really the nail in the coffin.

Migration

Well hopefully you don't have anything on XenApp 5.0 on 2008, but if you do the same general migration strategies apply as listed above for XenApp 4.5. From an application compatibility perspective there are still some challenges moving from 2008 to 2008 R2, mainly from an improved security perspective, etc. but if you're already running on 2008 you've dealt with a lot of the OS security improvements, UAC, etc. so moving your apps to 2008 R2 will really be mostly about 32-bit vs 64-bit and a handful of other challenges. The app migration issues from 2008 (especially if you're on 64-bit 2008) to 2008 R2 are substantially less than moving from 2003 (especially 32-bit) to 2008 R2.

End of life of XenApp 6.0 on Server 2008 R2

End of life - Server 2008 R2 is officially end of life by Microsoft on July 10, 2018. Citrix ends support for XenApp 6.0 (2008 R2) on July 15th, 2013 (again 3 months after XenApp 4.5). This means there's a 60 month (or FIVE YEAR!) gap between when Citrix drops support for their platform versus when Microsoft ends support for the core platform. Citrix has XenApp 6.5 available which has a longer lifecycle on Server 2008 R2, but even that product is end of life on July 24, 2015. So even the latest XenApp 6.5 still ends support three years prior to Microsoft ending support for Server 2008 R2. The biggest issue I have with the retirement dates of XenApp 5.0 and XenApp 6.0 having the same expiration is two fold:

XenApp 6.0 is a much more challenging platform to migrate to vs XenApp 5.0/2008. Due to this factor, many customers have been experiencing a very long migration cycle to get their applications onto Server 2008 R2 / XenApp 6.0. I know of several customers who are partially through their migration to XenApp 6.0 right now and based on these timeframes they'll be doing it all over again soon (albeit a quicker migration in most cases).
XenApp 5.0 was launched on September 10, 2008. This means that it will have been on the market for almost seven years when retired. XenApp 6.0 was released on March 24, 2010. Therefore, XenApp 6.0 will have a total lifetime of just over three years when it's sunset. How can this be that a substantially more difficult platform to migrate to has less than half the lifetime of a product that is much easier to migrate to? The reason is that Citrix has introduced XenApp 6.5 and has decided that they would much rather support that platform ongoing. XenApp 6.5 was released in August, 2011 which gives it a total of just under 4 years of life. Better than XenApp 6.0, but probably at least a year short of what most Enterprises would be looking for.

Stability

I joked earlier that XenApp 6.0 is sort of like XenApp 6.5 Beta. Anyone that reads this who was an early adopter for XenApp 6.0 probably knows exactly what I'm talking about. Between Server 2008 R2 and XenApp 6.0 there were loads of issues. Heck we're up to well over 100 hotfixes and HRP1 was just recently released for this platform. For a while there I was wondering if HRP1 would ever come out, or if Citrix would just keep pumping out hotfixes.

Migration

If your applications are already running on XenApp 6.0 that means they are already on Server 2008 R2 64-bit. Therefore, you should have almost no app compatibility challenges moving to XenApp 6.5 on Server 2008 R2. However, XenApp 6.0 and 6.5 cannot be part of a mixed farm. Therefore, you must take one of three migration strategies:

Build two farms and aggregate through web interface and manually move your applications over through publishing changes.
Leverage the XenApp 6.5 Migration Center to move your farm objects (published applications, etc) between the farms. You will still need to install all your applications on XenApp 6.5, etc but this can save a lot of time instead of manually re-creating farm configurations. This also still requires Web Interface farm aggregation.
Leverage the XenApp 6.0 to 6.5 In Place Upgrade Utility. It may not be quite fair to call this an in place upgrade utility as Citrix doesn't directly support an in place upgrade from 6.0 to 6.5. Rather what this utility does is automate what would otherwise be a manual process of uninstalling XenApp 6.0 off of a server and re-installing XenApp 6.5 on that server. If you have an existing XenApp 6.0 footprint and you're not sure how your applications were installed on your XenApp 6.0 servers, this can be an effective way of getting you to XenApp 6.5 without having to deal with figuring out how to re-install your apps. This utility does not help you get your farm resources over to 6.5, you would still need to use Migration Center to do that or manually re-publish apps, etc but this will help you get from 6.0 to 6.5 on exiting server builds. All of the same rules apply with respect to farm aggregation through Web Interface.

This topic is something that I have been discussing with a number of my customers over the last 6-12 months and I hope it's something that many of you have been thinking about as well. I know that there has been a quite heated discussion about this topic within in private CTP mailing list over the last year. In those conversations there are some CTPs with a "Good riddens!" opinion. There are others like myself and Pierre Marmignon @pmarmignon who spend a large portion of our time with large enterprise accounts who take a very long time to complete migration projects like this. It's particularly frustrating to be half way through a large migration project like this only to tell the CxOs that now that this project is almost to a close we're going to have to start up the next Citrix-related migration project. Let me be the first person to say that I truly do understand how difficult it is for Citrix to maintain developers on multiple platforms, and none of us want Citrix to be at a standstill from an innovation perspective simply to hang on to the legacy stuff. However, it's also of vital importance that with an Enterprise product comes a responsibility to provide an Enterprise level support lifecycle. What would I like to see Citrix do? Simply support any kind of Enterprise related product with a minimum of 4-5 years of product support. No need to match Microsoft's 7-10 year support lifecycle, but ending things at just over 3 years is a difficult pill for large customers to swallow. Should XenApp 6.0 be sunset this soon? I say no.

So am I blowing things out of proportion here or is this a real problem for customers out there?

Is Microsoft finally closing in on Citrix? (With a look back at ten years of "Microsoft is going to kill Citrix" stories.)

Shawn Bass — Mon, 31 Oct 2011 04:09:00 GMT

If you've been around the server-based computing industry for any length of time you're no stranger to the Citrix rumor mill. At one time there were stories about Citrix being doomed as a company, acquired by Microsoft, acquired by Oracle and even IBM or Cisco acquiring them. Of course none of these rumors came true, however the Microsoft killing Citrix rumor continues to have the most weight because they are the most likely company that actually could replace the functionality in XenApp into the native RDS functionality.

Citrix's Demise in 1997?

One very interesting rumor (almost a fact) was that of Citrix's demise in 1997. That year was when Citrix's license to the NT 3.51 source code was up and Citrix needed to obtain a license of the NT 4.0 source code or they were sunk as a company. Microsoft was noticing Citrix's rise in profitability and began to wonder if they should take a bigger piece of the pie and not let this company keep reselling a modified Windows product quite successfully. Citrix stock tanked and it certainly looked like they might be doomed. After much negotiations, Microsoft later decided to strike a deal with Citrix. They would pay Citrix $175 million to incorporate Citrix's MultiWin technology into a Microsoft Windows Terminal Server product. Microsoft would supply it's own protocol RDP and Citrix would retain rights to ICA. This was a defining moment in Citrix's future. Had that deal not come along, Citrix would quite possibly not exist today. An interesting bit of trivia on this topic is that there was a person who was critical in the negotiations of this deal at Microsoft. That man, Paul Maritz is now public enemy No. 1 at the helm of VMware. However, if it weren't for him there might not be a Citrix to compete with today. Interesting trivia, but getting off topic.

Microsoft to release "Citrix-killer" in 2003 R2

If you look at the history of RDS and Citrix products, there have been various "Citrix-killer" rumors over the years. None of the rumors were more crushing and realistic than the Project Bear Paw announcements in 2003. Microsoft had already successfully launched Server 2003 and were in the planning / execution phases for 2003 R2 and they made it known that they were planning on making some substantial improvements in Terminal Services. Back in the Server 2003 timeframe there was very little that could be done with native Terminal Services as it lacked application publishing, seamless windows, good web interface, load balancing, enterprise management, etc. In June of 2003 a Program Manager for Terminal Services named Adam Henderson presented a deck at TechEd called "Terminal Services in Windows Server 2003 Technical Overview". The presentation was largely a rehash of existing known info, but it did contain a roadmap slide indicating what Microsoft was planning to do with Terminal Services. The short list of items includes:

Application Publishing
Remote Apps Integrated Locally (RAIL) - Basically start menu integration
Collaboration
Single sign-on
Multimedia redirection
etc

Brian has blogged about the announcements related to Bear Paw and further analysis of what it means to Citrix. There is also a document containing info from a Citrix FAQ regarding their responses to the Bear Paw announcement.

Bear Paw never happened. So what's your point?

Bear Paw never was released, though Microsoft did incrementally improve TS/RDS over the years. Let's look at Server OS releases since then and talk through their major enhancements:

Server 2003 R2

This server OS release focused on core infrastructure improvements to AD, branch office server deployment, etc. Unfortunately, nothing really improved in 2003 R2 related to Terminal Services which is why I advised many customers to just keep deploying Server 2003 unless your organization standardized on 2003 R2 Server images. Pure RDS/TS folks were just able to skip this release.

Server 2008

This was a big release for Microsoft. There were lots of core OS changes that ultimately improved the situation for RDS like:

Hard resource quotas for shared critical resources - To protect things like paged pool memory allocations
Page file optimizations - Reading and writing the page file in larger blocks of memory
Low priority I/O - Allows for things like disk defragmentation and anti-virus scans to run only when low disk I/Os are occuring
SMB 2.0 - Can improve read/write speeds to file servers where user documents and profile data are stored
Kernel Transaction Manager - Provides better reliability of application of server hot fixes, etc.
Windows System Resource Manager - Provides mechanism to control resource consumption of user processes (works with RDS sessions)
Group Policy Preferences - Removes the need for most logon scripts.

Specifically for Terminal Server functionality, the following features were added:

TS Remote App - Seamless windows and locally integrated apps in the start menu.
TS Web Access - Web user interface to TS Remote App Published applications.
TS Session Broker - Limited, but functional brokering of user sessions.
TS Gateway - RDP over SSL tunneling/proxying of RDP sessions. Single point of access through public firewall.
TS Easy Print - A least common denominator fall back software printer similar to Citrix's Universal Print Driver v1 / v2
Higher screen resolution - Up to 4096x2048.
Parallel session creation - Prior to Server 2008, only a single TS session could be logged on simultaneously. Session Manager improvements now brings a minimum of 4 simultaneous sessions.
Dynamic System Address Space - Dynamic balancing between Paged Pool, Nonpaged Pool and System PTEs. In 2003 these boundaries were determined at boot time and were static.
Built-in User Profile Hive Cleanup Services - No more need for UPHClean (at least for stuck registry handles)

While these are some great features for Server 2008 Terminal Services, the reality is that they were quite limited. Limited enough to prevent most people from deploying this without Citrix as some add-on middleware. Brian blogged about this release and his assessment was "Citrix has nothing to worry about" and it was largely true. However, this release pretty much adds the rumored features of Bear Paw. There were plenty of companies wondering if this release had just enough that would allow them to shake the extra Citrix licensing. In most cases, it didn't deliver enough.

Server 2008 R2

Yet another huge release for Microsoft and lots of changes for TS (now called Remote Desktop Services). Let's look at some core additions:

Hyper-V 2.0 aka R2 baked in - Hyper-V 1.0 was much too poor performing for most to consider it. Hyper-V R2 is right up there with vSphere and XenServer
Direct Access / Branch Cache - Great new technologies for enabling branch office users and mobile laptop users to provide access to files, etc in an WAN friendly way.
IIS 7.0 - Yet a more secure IIS web server version

Specifically for TS/RDS, the following features were added:

Broker now integrates VDI (RDVH - Remote Desktop Virtualization Host) and TS (RDSH - Remote Desktop Services Session Host)
Improvements to RDS Web Access and RD Gateway
True Multi-monitor support (prior to this Microsoft only supported spanning - now you can have up to 16 independent monitors in any shape and resolution)
Improved multimedia support and bidirectional audio support (for VoIP applications)
Aero Glass supported over RDS
Windows Installer Engine properly supports multiple simultaneous logons and processing of self healing by queuing actions (this use to fail completely)
RDS Powershell Provider - For automating RDS via PowerShell

Server 2008 R2 with SP1

Server 2008 R2 Service Pack 1 added two primary features:

Dynamic Memory - A method of dynamically allocating memory to VMs to provide higher density while allowing good performance.
RemoteFX - New method of providing virtual GPU access to VMs on Hyper-V. Provides a content agnostic host-side rendered RDS model. RemoteFX is the future direction for RDS, however it's currently a LAN-only technology.

In looking at all of these incremental improvements to RDS, it's clear that Microsoft continues to improve the platform. So what is it about Citrix XenApp that continues to lead the pack against Microsoft and RDS?

Star Wars aka "Where Microsoft Loses"

Brian blogged back in 2005 an article named "Do you need Citrix or is Terminal Server enough?" It's a good read and I suggest you take some time looking it over. What's interesting is that Brian highlights two misconceptions in the beginning of the article. In summary, they are:

Misconception #1: ICA is better than RDP.

Brian states that this is false and that RDP has made significant strides with the protocol, etc. While I would agree with Brian that RDP has come along way, it's all about the WAN man! The WAN is one area where Microsoft loses big time and anyone who's run RDP over 200+ ms will tell you that. The blocky tiles painting one by one will only reach about 15 tiles before you're ready to murder someone. Working on a RDS session like this for any length of time is not likely to be well received as a practical solution. So I'll disagree with Brian here and say that ICA is king on the WAN. If Microsoft wanted to pose a serious threat to Citrix, they'd have to make RDP almost as good if not as good as ICA to compete here.

Misconception #2: f you have 50 (or 75, or 100, or whatever) number of users or less, you can use pure Terminal Server. With more users you need Citrix.

Brian states that this is false and that the number of users you have or the number of RDS servers has nothing to do with whether you use RDS or Citrix. This too is an area where I'll disagree with Brian. RDS has RemoteApp and it does work. Try maintaining that at scale with hundreds of published resources across many silos of servers and unless you develop some of your own tooling, it's painful.

In my years of consulting I'm often asked "Can we get rid of our Citrix licensing yet and just use pure Microsoft?" After I go through the many different aspects of what Citrix does for the customer it ultimately comes back to these two items for most people. Sure Citrix has smooth roaming, workspace control, smart access, etc. But to be honest, what brings most customers back to Citrix every time is the above two items. These are the lynchpins of Citrix being entrenched into customers.

The Empire Strikes Back

At Microsoft's BUILD conference a few weeks ago, Microsoft provided a sneak peek at what might be coming in the next release of Windows for the desktop systems as well as Server OS release. Currently known only as Windows 8, Microsoft seeded developer builds for the desktop OS and Server OS. While there were some interesting things disclosed about Windows 8 Desktop OS, it's all largely a "Meh!" to me as it seems to be little different than Windows 7 for the Corporate user. I do think that Windows 8 will have a big impact on the tablet market with it's Metro user interface. However, that's largely off topic so I want to focus on the Server OS preview and talk specifically about what it means for RDS.

Microsoft shared a video of a presentation at BUILD regarding RDS enhancements in Windows Server 8. In this presentation Nadim Abdo and Gaurav Daga lead an hour long presentation that provided some details about what Microsoft is doing with RDS in Server 8. And for me, this is the Bear Paw Citrix should be worried about. I highly recommend you watch the entire presentation as there is some good visuals that you'll want to see rather than just reading about. If you're short on time, here is a quick breakdown of the items that are covered and my thoughts on them:

New Metro Style RemoteFX Client - Of course this has to exist. Microsoft is investing heavily into the Metro UI in Windows 8, so they are introducing a Metro-style RDS client. This will likely only apply to Windows 8 clients, but it does look pretty cool. Aside from that, it's Meh! One nice feature of the Metro style client is snapshot previews of your existing RDS sessions. That's a pretty cool feature.
RemoteFX for WAN - RemoteFX is quite impressive on the LAN, but up until now was limited to that scenario. Microsoft is making improvements to RemoteFX that will allow it to function well on WAN networks. Recall from the previous section that this is one of the key reasons why Microsoft loses today. RDP and any other TCP-based protocol tends to have problems when you run those protocols over a network that has packet loss or high latency. The issue is due to the fact that TCP is a connection oriented protocol and as such attempts to maintain packet order and retransmits lost packets. UDP does not have this problem as it's a connection-less protocol that effectively broadcasts content. Microsoft is adding UDP transport support to RemoteFX to accommodate better performance for RDP over wide area networks. They are still providing intelligent fallback to TCP capability in the event the host/client can't establish UDP communication (think firewalls!). In addition to the transport changes, Microsoft is introducing something called Adaptive Graphics that will help reduce required bandwidth for rich content over WAN networks. Microsoft has improved RD Gateway to add support for RDP, so connections via UDP-base RDP are secured through RD Gateway just as they are with TCP-based RDP.
RemoteFX Adaptive Graphics - Microsoft is breaking up content into different types and rendering them differently. This was always the case with traditional RDP whereby some content could be GDI primitive remoted while others were bitmap remoted and audio/video content was redirected. Historically under RemoteFX you only had host side rendering for all content with just audio/video content being redirected. It appears Microsoft is improving this so different types of content are rendered differently. For example, text might be rendered with one codec and delivered quickly with extremely low bandwidth. Meanwhile, image content is delivered using a progressive rendering technique that I'll assume is quite similar to that of Citrix's Progressive Display. Lastly any animated content or fast moving images will be rendered using a video codec (I believe Microsoft said H.264) and sent that way. Between the RemoteFX for the WAN and this Adaptive Graphics, these two features sound like they will finally level the playing field in the RDS/RemoteFX vs HDX game.
RemoteFX Media Remoting - Microsoft has developed some new H.264 codecs that they are using to process video and compress it about 10:1 vs what was possible on 2008 R2 / Windows 7 via RemoteFX. Really excited to get a chance to place these new video codecs in the multimedia tests that Benny Tritsch and myself perform. As far as I know these video codecs are not specifically limited to Windows Media types as it was demonstrated using Flash. Can't wait to dig into this more.
RemoteFX Multi Touch - Microsoft will offer 10-finger multitouch remoting for applications running over RDS. While this is quite limited today, it's clear that much of the PC/device industry is moving towards touch. I was quite impressed to find that Microsoft is supporting full multi-touch and not a limited one or two finger touch solution. It remains to be seen if this technology will work well over the WAN, but it is quite impressive. It's also important to note that this technology will not be limited to the Metro-style RemoteFX client, but will be available in the regular client as well.
RemoteFX USB Redirection - While Citrix and others have long supported USB device redirection in their VDI solutions. USB device redirection and isolation was always something that has plagued multi-user Terminal Server or RDSH systems. Due to the inability to redirection and isolate USB devices, some applications have needed to go the route of VDI because there was no way to redirect the device within Terminal Services. Now before anyone says "We've been redirecting USB Printers, Thumbdrives and Scanners for years", that's absolutely true but those devices were not being redirected at the USB Bus level, they were redirected via device dependent redirection virtual channels for printing, drive mapping and TWAIN. What Microsoft has done with Windows 8 is not only provide redirected, isolated USB device support within their VDI product RDVH, but also within RDSH (Traditional Terminal Server). This is incredible news and as far as I'm concerned opens up so many more applications that are now possible in Terminal Services. Being that this is a platform play, it will of course be beneficial for Microsoft ISVs such as Citrix and Quest, etc. Very exciting news.
Software or Physical GPU - One of the biggest limitations with Windows 7 SP1 + Hyper-V is that is required a physical GPU in the server to support any 3D graphics (unless you were planning on using 2008 R2 RDSH which didn't use a physical GPU). Microsoft has added some capabilities to Windows 8 Server for VDI scenarios to now support RemoteFX capabilities either with or without a physical GPU. If the physical GPU is available, RemoteFX can use it. If you don't have a physical GPU, there will be a soft GPU where the GPU instructions are emulated in CPU. So now RemoteFX will be support in VDI scenarios without or without a GPU and on physical machines. One has to wonder if this was always in the plans or if this is something Microsoft did in reaction to VMware shipping soft GPU support in View 5. All I know is things are getting very exciting between VMware and Microsoft having soft GPU support, Citrix having DX primitive remoting for Aero as well as GPU-based HDX3DPro (including GPU passthrough) for high end graphics. Very exciting times for rich graphics in remoting scenarios.
Published apps and desktops via email - Microsoft seems to have improved the RemoteApps publishing and Web Access scenario by making it more like the Outlook Anywhere / Exchange Autodiscover process. When you setup a modern Outlook client for corporate use all you need to do is specify your Corporate email ID and password and Outlook will behind the scenes query autodiscover.domain.com and if Autodiscover is setup, Outlook can configure itself for RPC over HTTPS and connect you to your mailbox. It seems that the Metro-style RDS client and Server 8 is supporting similar functionality where a user can just enter their email address and password and automatically get a list of the published apps and desktops that are assigned to them. This is true even with a non-corporate asset. I really want to dig into this feature more and figure out how it's working. I'll plan on putting up an article on that later.
Bandwidth and Round Trip Latency Info - Microsoft has demo'd the Metro Style RDS client having a Connection Info window where the end user can see their estimated network bandwidth and round trip latency. I'm hoping Microsoft provides this via server side PerfMon counters since latency was never something that one could easily record for performance metrics and such. Citrix had this for years now.

I'm hoping to get more time to work with Server 8 / Windows 8 hands on so I can provide further details on the specifics of the above items.

Will there be a Return of the Jedi?

What will Citrix do in response to these improvements? Well, first of all we should assume they already know about these enhancements as they work very closely with Microsoft. My general gut feeling is that Microsoft will continue to improve RemoteFX, but there will still be use cases where HDX outperforms it in certain WAN conditions, etc. Also, Microsoft is very focused on the latest greatest client side OS (because that's how they earn revenue). So there's a huge opportunity there for Citrix to provide a Windows 8 experience on down level operating systems and alternative operating systems. How well this will work or not depends largely on how good Microsoft's RemoteFX thin clients are. If they are good enough, no one in their right mind is going to consider repurposing a PC or buying new thin clients that are non-RemoteFX if they can acquire a bad ass RemoteFX thin client for $100. Given that we make the assumption that Citrix will find ways to stay ahead in the protocol space, but we assume that Microsoft will continually play catch up, there's only one area that I discussed where Citrix maintains the lead and that is in enterprise management. Citrix does a much better job of this right now than Microsoft does. I'm pretty confident at this time that Microsoft won't nail this as Citrix has largely because Microsoft has a tendency to try and glue everything to SCCM and SCVMM. If they do that, they'll fail miserably. If they find someway to improve management of large environments and it's inbox, then lookout Citrix.

Shawn Bass

Asking Citrix for answers about the XenDesktop VDA is like a “Who’s on First” Abbot & Costello routine.

What is the VDA?

XPDMs on First, WDDMs on Second...

The on ramp to VDI?

Who's VDA is on first?

How Citrix could have made this better?

How persistence affects security: VDI and TS are not more secure than physical desktops, Part 5 of 5

Persistent Desktops

Non-persistent Desktops:

Hybrid Persistent / Non-Persistent Desktops:

Security in the Persistent vs Non-Persistent vs Hybrid world:

Is it better than a persistent disk that would keep the malware / infection over a long term period?

Does it mean you're safe?

Is resetting a system an effective means of dealing with virus/malware/trojans?

Will I get clean desktops every single day with the non-persistent model?

Security by isolation methods: VDI and TS are not more secure than physical desktops, Part 4 of 5

Matryoshka Dolls (aka Inception)

Sandboxing:

Microkernel:

OS Virtualization (or monolithic kernel isolation):

Offsite OS Virtualization:

Mitigation strategies for data security: VDI and TS are not more secure than physical desktops, part 3 of 5

Look at this cool wooden horse we made for you…

How computers get compromised

Does it matter where the PC is located for these attacks?

So how do we improve security against the email/browser threat?

VDI and TS are not more secure than physical desktops, Part 2 of 5: Centralization helps in other ways

The problem is, data centralization is really tough to achieve these days…

It's really a matter of trust...

So if we can't trust anyone, what do we do?

VDI and TS are not more secure than physical desktops, Part 1 of 5: There's only two types of data!

There's really only two forms of data

1. Data at rest

2. Live data

Citrix revises end of life dates for XenApp, but what does that really mean?

Citrix Responds!

A rose by any other name would smell as sweet...

Citrix End of Life

Citrix End of Extended Support

Microsoft Mainstream Support

Microsoft Extended Support

Why thin clients and zero clients haven't lived up to the "last PC you'll ever buy" hype. (Part 1 of 2)

Less moving parts = less component failures

Less Power Consumption

Less Cost for i.m.a.c.

"The Last PC you'll ever buy!" Really?

Relative Immaturity of Remoting Protocols and Fragmentation

Application & Web UI Complexity

Commoditization of the PC

Thin Clients are NOT future proof

Enter the HDX Ready Thin Clients

Enter the Zero Clients

True Zero Client

Psuedo-Zero Client

Enter the Citrix HDX SoC (System-On-Chip) Thin Clients

Citrix plans to end support for XenApp 6.0 in 2013. What's that? You're still migrating to 6.0?

End of life of XenApp 4.5 on Server 2003

End of life of XenApp 5.0 on Server 2008

End of life of XenApp 6.0 on Server 2008 R2

Is Microsoft finally closing in on Citrix? (With a look back at ten years of "Microsoft is going to kill Citrix" stories.)

Citrix's Demise in 1997?

Microsoft to release "Citrix-killer" in 2003 R2

Bear Paw never happened. So what's your point?

Server 2003 R2

Server 2008

Server 2008 R2

Server 2008 R2 with SP1

Star Wars aka "Where Microsoft Loses"

The Empire Strikes Back

Will there be a Return of the Jedi?

Thin Clients are NOT future proof 