Shawn Bass - All Comments

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

Eric Feldman — Wed, 06 Feb 2013 16:08:43 GMT

Great article, I wish I had seen it about two weeks ago. :)

If you happen to use MCS on VMware hosts for/with XenDesktop.....you have to install from the original agent off the XenDesktop CD (getting the "Citrix Virtual Desktop Agent" part) in order to get the under-the-hood MCS components that allow for customizing images after they are cloned and spun up by XenDesktop.

Found that out the hard way when I totally uninstalled the old VDA and then installed the 5.6.200 version in my new base image, thinking that was the right way to go based on some older documentation. Then I spent a long afternoon trying to figure out why my MCS-provisioned desktops from that new base wouldn't change names and register themselves with the DDC.

Lessons learned (one of many Citrix Lessons I have been learning of late).

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

Shawn Bass — Mon, 04 Feb 2013 22:00:26 GMT

Martin,

Thanks for providing some excellent additional info. I guess the frustration in all of this for me (and my customer) is that there was clearly an indication from Citrix that there was only one supported installation method which clearly conflicted with usage of Windows Aero / RemotePC. I think they could have done a much better job putting out a good VDA that had all of the necessary bits in it and I think they definitely could have amended documentation to indicate that standalone VDA was perfectly fine to use and exactly what things you would sacrifice by using it instead of the other upgrade path. I just think there were far too many things wrong with the approach taken and I think it's a result of far too much emphasis on putting new code out and not enough emphasis on quality control. But that's my opinion.

Again, thanks for sharing. Some great stuff in there.

Shawn

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

Martin Sheppard — Mon, 04 Feb 2013 21:33:11 GMT

Hi Shaun,

I've examined the install files from both versions and as best I can tell, there are two parts to the install. There is XenDesktopVdaSetup.exe which creates the "Citrix Virtual Desktop Agent" entry in add/remove programs referred to by support.citrix.com/.../CTX134196 and there is XdsAgent_x64.msi which creates the "Citrix Virtual Desktop Agent Core Services" entry and is the actual meat of the VDA. The 5.6.100/5.6.200 updates are full copies of the VDA Core Services component and as such are right to be distributed as MSIs, but they don't include the "Citrix Virtual Desktop Agent" component because this hasn't been updated.

So what does the "Citrix Virtual Desktop Agent" component actually do? As far as I can tell it just provides a GUI to configure the actual VDA and prepare a VM with optimizations such as disabling last access timestamp and so on. Deploying the VDA without this component is supported since that is exactly what Citrix recommend if you want to distribute it with group policy: support.citrix.com/.../ctx127301.

In support.citrix.com/.../CTX134196 they don't actually say you can't install it standalone, just that it is not "meant" to be installed that way, but it must be OK to do so because that's exactly what you would do for a GPO deployment which is supported. The only caveats being that you need to find other ways of applying any optimisations (the group policy article has methods for many of them) and you don't get the configuration wizard mentioned in support.citrix.com/.../CTX134196, but you wouldn’t want that for an automated install anyway. If you are happy with them then I can't see a problem, although it would be nice if Citrix would make that clear in their documentation.

If you do want the wizard and the updated VDA without going through two installs then you should try using the original XenDesktopVdaSetup.exe with the original XenDesktop installation source, but replace the XdsAgent_x64.msi (or 32-bit equivalent) with the updated version from the download. You'd need to test that yourself and certainly wouldn't be a supported scenario by Citrix, but it nevertheless has a high chance of working successfully. You'd need to judge for yourself whether that made sense to do. Bear in mind that this is exactly what Citrix did themselves in updating from 5.5 to 5.6 since the XenDesktopVdaSetup.exe part stayed at version 5.5 for that release.

While Citrix certainly could and should have documented this better, I feel bad picking on them for this given that the state of the Linux Receiver makes this look wonderful by comparison. To just get the linux receiver installed on a 64-bit system I have to first modify the installer to remove the check that stops it from installing on a 64-bit system! I'm totally stumped how Citrix can manage to release a download for the 64-bit Linux agent that actually has a check in the installer that means it cannot ever install on any 64-bit system without modification. How could that possibly get through QA? Did they never test it at all? There's other issues as well that I won't go into now, but that one just seems incredible.

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

Bob Nolan — Fri, 28 Dec 2012 17:04:05 GMT

hi, Good to see arguments being tendered both for and against SBC/VDI. I accept most, if not all, of what you say, Shawn, but the points raised are ultimately points already laboured hard and long by many dyed-in-the-wool anti-SBCs (not meaning to tar you with that bruash at all).

in our own case, we only recently replaced 8 year old Wyse terminals (non-HDX ready!) on our recent migration to XenApp 5. Any self respecting infrastructure manager would easily regard eight years as a pretty good service for any piece of kit. As it turns out, we probably did not need to replace the Wyse devices, as it seems some staff are actually still using them on the XenApp platform, much to our bemusement.

On management of these devices, we use manufaturer supplied management software (IGEL UMS) to easily deploy firmware and config changes. We can even switch a user to a new platform without them knowing anything has happened. Works a treat. We can set up a thin client in minutes and our users all enjoy a 10 second bootup to login screen...each and every time...!

One downside, however, to going thin client is the whole user perspective thing. Once something doesnt work, no matter how small that may be (a website wont load or there is a 5 second delay opening a file or email - cos, hey, the file or email server is busy!), word spreads like wildfire that its the fault of this crappy little thing IT stuck on my desk...and user perception takes another hit.

I believe, if anything, that user acceptance is the bigger pain point, and ultimately a big drawback, for IT managers looking to implement SBC/VDI.

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

Meko_Siluka — Wed, 26 Sep 2012 15:02:07 GMT

I enjoyed this series because it brings to light perceptions and misunderstandings of VDI as a solution. It also gets the community talking about security or information assurance. I'm all for that and think it's a great thing.

My opinion however has not been swayed. Many of the pros and cons mentioned throughout this series never speak to to risk in general. More specifically, risk likelihood. Nor do they look at threat mitigation.

The series fails to even highlight incident response in a virtual world vs. a PC world or the resources required to properly implement them. Instead much of what has been talked about seems to boil down to one thing:

You can still be hacked in a VDi world just as you can in a PC world.

While I do not disagree with that statement, unfortunately this is not how you should look at the two from risk and information assurance standpoint. I feel the author of this series fails to understand Confidentiality, Integrity, and Availability (CIA) when looking at data. In fact, information assurance of data was never looked at properly in the first place (citing Part 1 here).

I again make mention of my original comment. If you do not understand the 3 types of data, then you cannot properly understand how to protect data.

Everything said, I don't want people to think I'm preaching VDi here as the most secure environment for everyone. It's not a silver bullet as some may think. Each organization has it's own risks and challenges to mitigating those risks. VDI can be more secure than PC's. Whether or not you make it more secure begins and ends with understanding your risk. Talk about non-persistent clones, malware, and viruses is only talk. Where the rubber meets the roads is in attack vectors and strengthening/hardening your posture around 'data' from a CIA point of view.

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

help4ctx — Mon, 20 Aug 2012 19:01:04 GMT

Great series of articles Sean.

I can't help but wonder whether the complexity that we engineer into software these days which requires the development of additional software products such as that which Bromium are developing, highlights a key failing in our fundamental approach to security.

More complexity at the OS/App layers requires more complexity at the 'prevention' layer, this compound spiral of complexity leads many of us who dont understand the complexity to trust the products at the 'prevention' layer implicity, as we have no choice but to do so. This trust leads to a commonly blase acceptance that we are protected. So, should we trust, or should we be paranoid or simply just not care!

I think the Flame virus highlighted to me that it is possible for those with detailed knowledge to silently intercept and forward data which can be used quietly to achieve no end of malevolence. The threat which no one is aware of is the greatest threat!!

I have said for years that Windows has become a huge monstrous and untamed beast which requires constant vigilance to keep watertight and secure, I'm sure Linux and Mac have some similar shortcomings. We really need to break down the monolithic OS, seperate it into trusted blocks of code and only call those functions which are necessary when we need them. All of these security approaches are merely 'band-aids' which temporarily address a flawed approach to computing.

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

Meko_Siluka — Mon, 20 Aug 2012 18:48:22 GMT

I'll have to wait until part 5 is posted before going into detail on the points made here as it appears there's much left yet to cover.

That being said, Part 1 was a complete miss due to the utter lack of understanding of what data truly is and the forms it takes. If we cannot use industry standard terms when speaking to information assurance in general, then the discussion has no place going in that direction in the first place.

This blog is a respected interest of many. Choosing to omit rather than speak to defined terms leads me to believe that there can be no objective conclusion drawn from what I have and will read. I will of course still lend an opinion in the hopes that someone will one day read it and be able to properly draw their own conclusion whether it be to the same or contrary.

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

help4ctx — Mon, 20 Aug 2012 18:34:49 GMT

I believe there is are a couple of dimensions to TS/VDI which makes it's centralised nature more secure. It is certainly easier to attach a physical 'listening' device such as a keyboard logger or network tap to a desktop PC 'out in the wild' than it is to compromise a centralised, or virtualised desktop in the same way. This kind of threat has been responsible for several multi million dollar frauds which have occurred at major banks in the last 10 years. In addition, physical access to a desktop provides a headache for data disposal, as distribution of data across hundreds of corporate PC's and their internal disks has been used many times to steal data and use it to nefarious advantage, even in government environments. I would also argue that it is easier to encalve and baseline a centrally hosted desktop to the point where usage 'out of the ordinary' can more easily be spotted and dealt with!!

I'm not disagreeing with you, your article is well measured and gives pelnty of food for thought, but there are many arenas where the centralised model provides distinct security advantages

I think this certainly provides more weight to the argument that any IT solution should be designed and implemented based on specific corporate requirements and not on anecdotal evidence that one solution is more secure/scalable/cheaper/manageable than another. One mans secure/centralised solution might be anothers management nightmare!

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

appdetective — Fri, 17 Aug 2012 13:38:31 GMT

@Icelus, oh jesus, WTF with all this Bromium group think. It's got so much to prove.

Security as this series has pointed out is applied at many levels. Modern data exploits go after all of them and sit there while they figure out the next. If you work with any big bank or government which I think you do, you will also know that the amount of money invested to exploit these is plenty. There will be no silver bullet. It may help, and let's face it Bromium would be all over trashing VDI if their stuff worked on a virtual instance in the data center. I'm sure that is a hardware limit, but not my point.

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

appdetective — Fri, 17 Aug 2012 13:33:23 GMT

@Andy Wood,

We're actually in more agreement that you think. Agree on idiot PC people won't just auto fix it. However those are so often the failed the VDi implementations and they deserve it.

Where we disagree is that I believe security is part of better management. VDI is a catalysts in many projects to rethink where in the desktop it is the same old way and no reasons to change. When that happens combined with the right reasons to do VDI which are about business enablement and done right, you end up with better security. Of course the argument can be made for PCs if you focus on that part, but my point is people won't in practice.

I'll reserve my Sunderland comments :-)

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

Icelus — Tue, 14 Aug 2012 17:49:41 GMT

I must add that in addition to the management elements of RDSH, SHVD, CHVD, and Traditiona PCs, the security vendor ecosystem around each solution determines how truely "secure" they are.

You really could have just created one article with a tilte called "Why Traditional PCs will be more secure than VDI and TS." and linking to Bromium's website.

I wonder if Cisco will do anything neat with Virtuata to help the security industry of SHVD, CHVD, and maybe even RDSH.

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

Icelus — Tue, 14 Aug 2012 17:36:32 GMT

@Shawn

Great series, but after reading the articles I still don't know your points that prove "VDI and TS are not more secure than physical desktops"

VDI and TS are management technologies that are architectured completely differently than Traditional Desktops which can introduce security benefits or even problems as well. Remember, SCCM, LanDesk, Altiris, etc don't make you more secure either.

RDSH, SHVD, CHVD, and Traditional Desktops are not security solutions, they are very unique and distinct client architectures and can be managed and secured very differently.

I believe this "which is more secure" argument originated when people were claiming that VDI is inherently more secure than Traditional Desktops. Then people ran off with the notion claiming that VDI is more secure than Traditional Desktops which is wrong.

I also think people misunderstood what "secure" meant. Security is an illusion and just because you may be more "secure" in one solution doesn't mean you're safe.

Personally, I never claimed a solution is more secure, but I did say that VDI is provides more security out of the box for many reasons that many people have constantly outlined. Once you virtualize something it makes it easier to consume and sometimes manage. Control and security are attributes of better management.

It all boils down to use cases and how your desktops are managed. The better they are managed, the more secure you are. If you have a large organization with complex requirements, then you start off out of the gates with a very tough and insecure business to protect. VDI may not be a good candidate, but since you are a big org chances are you have invested heavily in the current Desktop Management technologies anyway.

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

Shawn Bass — Tue, 14 Aug 2012 14:35:18 GMT

@Helge - ACK! I just fixed one other typo and missed that one. Fixed now.

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

Helge Klein — Tue, 14 Aug 2012 14:24:45 GMT

In the second to last paragraph you wrote "While I personally love the concept of non-persistent desktops it's also something that is incredibly different to achieve within large organizations".

Surely that should be "incredibly DIFFICULT" instead?

Thanks for writing this series of articles!

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

Gabe Knuth — Tue, 14 Aug 2012 14:06:16 GMT

Deep Freeze...right! I can't believe I forgot to put that in my "Doing it without VDI" session. I use that around here and I love it.