Jeroen van de Kamp's Blog

New free tool lets you manage Citrix XenClient with Microsoft SCCM

Jeroen van de Kamp — Tue, 25 Oct 2011 04:01:00 GMT

Citrix Synergy has started, and after a couple of previews XenClient 2.0 is ready to be officially released. XenClient is maturing and on its way to become an enterprise solution. By design, Citrix offers management of XenClient systems through the XenClient Synchronizer solution. However, the XenClient Synchronizer does not facilitate in the automated bare metal deployment of XenClient onto physical hardware.

Enterprises already have invested heavily a desktop/laptop deployment infrastructure is in place. Many enterprises use Microsoft System Center Configuration Manager 2007 (SCCM or Config Manager) as their primary deployment and management product for desktops and laptops. Requiring enterprises to include an additional/second deployment infrastructure within highly distributed environments for XenClient is not always feasible and realistic.

My colleague Henk Hofs already did a few ‘cool’ articles on how to perform an unattended installation of the XenClient Hypervisor on his blog www.ithastobecool.com. When Henk got in contact with Citrix about this, the idea was born to develop a true Microsoft SCCM 2007 R3 integrated solution for XenClient 2.0.

Together with the XenClient team, Henk developed an add-on for SCCM2007 that allows the deployment of the Citrix XenClient to end-user systems via the well-known task sequencer. With this add-on it is possible to:

Deploy XenClient to end-user systems using the existing SCCM 2007 infrastructure
Pre-create an empty Virtual Machine during installation.
The entire chain from Deploying XenClient to getting the Corporate Image in the VM that runs on XenClient can be made zero-touch through the use of Unknown Computer support in Config Manager.

The Administrators Guide accompanying this download has detailed steps on how to configure your Config Manager environment to enable these scenarios.

To better understand what the ‘XenClient Integration Toolkit for Config Manager’ is all about, review this 5 minute video (no sound):

(Please visit the site to view this media)

This is the first public (beta) release of the ‘XenClient Integration Toolkit for Config Manager’. It converges conventional desktop management solutions like SCCM with the client hypervisor. In the long run, this is in my opinion the only way to go for client hypervisors and essential for true enterprise adaptation. Brian made some interesting comments in this article, to which I agree in many ways. As usual, this download is completely free and can be found here (registration required).

Bring Your Own Application with Microsoft App-V

Jeroen van de Kamp — Mon, 19 Sep 2011 04:24:00 GMT

Once in a while you encounter a simple but brilliantly refreshing idea. This happened to me a couple of weeks ago. My colleague Matthias Wessner was in the Amsterdam HQ for a visit, and dropped by my office. He asked if I had seen the movie he mailed me two weeks before. I shamefully admitted I completely missed it.

“Ok, I will show you” he said, and popped open his laptop. After the VM’s were up and running he started the demo. “See this GUI? Just select the MSI you want to install from that GUI, and wait for it…” One minute later the desktop shortcut appeared and he could start the application.

Wait a sec… it is virtualized with App-V!

This was only one week after Briforum Chicago and one week before Citrix announced the RingCube acquisition. One of the hotter topics today is clearly User Installed Apps. Matthias just demoed User Installed Applications utilizing Microsoft App-V! “Interesting!” I said, “This is very, very interesting, and that is an understatement… Do you realize how everyone in our industry tries to tackle this problem… and you just did with App-V… Wow!”.

So what did Matthias show me?
(Please visit the site to view this media)

The concept is not too complicated: Matthias created a tool called ‘Login BYOapp’. Within BYOapp you can select a MSI and it will prepare the MSI for a sequencer VM which is ready and waiting. Once the MSI is available to the sequence VM, automatically it starts in silent mode the sequencing of the MSI. Once this is finished, automatically the now virtualized app is added to the App-V cache of the desktop the user is working on.

Although this implementation is in its most early form, we thought the concept is so cool we should share it with you. There are real benefits, and like any other solution in this world, there are limitations.

Lets first discuss the benefits:

With Login BYOapp you can introduce User Installed Apps if you are using Microsoft App-V, without introduction of a new virtualization technologies and management tooling/infrastructure.
These user installed applications are potentially reusable for other users! (This is not specifically implemented in this version, but we already have a user installed app store/catalog in the works.)
You can easily back-up and re-import the applications when the desktop VM is refreshed. (Also not implemented yet, but surely part of future versions.)
From an administration point of view, you can easily track and copy which applications users have added. (Again, this is planned for future versions…)
The application is fully virtualized, so there is no risk of any conflict or corruption of the OS and other personal or business applications. Off course, this is fundamental to using App-V.

The current version (and the concept in general) also have some limitations:

You need an MS App-V license.
It does not work with RDS/XenApp/SBC/TS etc, it only works with (semi-) stateful VDI, PC’s and Laptops.
The automatic addition of the virtualized app to the local App-V cache is only working when App-V is not integrated in SCCM: we are currently investigating if this is possible.
This version of BYOapp only does silent installs. This can be an issue when for instance the default file type associations are not correct. However, we are working on a solution where the interactive setup is remoted. As a result, the user can customize the installation to it’s own needs, including FTA.
The current version only accepts MSI, but future versions will probably accept any format.
This only works with apps, this is not a layering solution that also captures changes on an OS level.
Login BYOapp will never replace enterprise application packaging/sequencing.

Please remember, this is the first release of Login BYOapp. It is basic, but we thought the concept is interesting enough to share with you.

We have many ideas where we want to go with BYOapp: an interactive install is absolutely critical to it usability in enterprise environment. But also, a ‘user installed app store’ and tracking/back-up/import functionality is high on our feature list. In addition, we are working on the fully automated management of the sequencer VM’s (reset after sequencing) and the possibility to have a pool of sequencer VM’s. Lastly, we are also investigating the use of other application virtualization solutions.

I always assumed Microsoft would innovate much more with the Softgrid/App-V technologies than they are doing now. For instance, developing it as a replacement for MSI and using it as a technology to allow user installed apps. Matthias beat them to it...

You can download this first and free version of ‘Login BYOapp’ from our website (registration required).

Two new free tools from Login Consultants: SCCM Status Indicator and App-V Package Analyzer

Jeroen van de Kamp — Sun, 11 Sep 2011 08:00:00 GMT

While Brian (and maybe you) might disagree, I believe that BrianMadden.com should be more about the "enterprise desktop" and end user client computing in general. The current focus on server-based computing and desktop virtualization is too limiting. The reality today is that the vast majority of enterprise desktops are still classic PC's or laptops (as they should be). And even though a lot of people in our industry are talking about "post PC Era," it will be a very, very, long time before classic computing becomes a true "legacy" solution within the enterprise. So as a result, I wouldn't mind if BrianMadden.com also investigated and reported more on conventional desktop models and management solutions.

[Last minute edit: Be sure to check out Brian's latest article on desktop transformation: I wasn't aware of his article when I wrote this one, but it's nicely linked to the concepts I'm talking about here.]

Let me give a small example that I get excited about: Many of our customers use Microsoft System Center Configuration Manager 2007 (SCCM), andmany complain about the lack of transparency for admins and end-users in the product. As a result of this, Login Consultants recently released another free tool. This time instead of App-V, we've decided to create one for SCCM 2007.

The idea of this tool came when my colleagues Dennis Geerlings, Ryan Bijkerk and Ment van der Plas (@mentvanderplas) were migrating the desktop environment of one of our customers. This customer, like many others, has chosen SCCM 2007 as their primary deployment solution for applications (both traditionally installed as well as virtualized with App-V). While the design and implementation of the distribution environment went smoothly and the applications were tested in the new environment, my colleagues stumbled upon an very inconvenient habit of SCCM in the migration phase of the project.

Users would receive their brand new laptops from us that had most of the corporate applications already installed as part of the image. While the departmental apps were presented to the user as soon as they logged onto the machine, they required a user action to actually install. But when they clicked the button to continue with the install, most users were presented with an error that an installation was already in progress:

This is a very common error in SCCM environments and basically means that the SCCM client is busy running another program in the background.

We quickly identified this as "by design" because some software (like OS patches) had been updated in-between the time the image was created and when the user first logged on. So when the SCCM client was busy updating the system to the latest software level, it prevented other installations to take place. Although we could tell the migrated users to "try again later," that just led to confusion.

We didn't want to enable the user interaction components of our OS patches since they weren't too user-friendly and we didn't want to change the application deployment configuration in the middle of our migration. Instead, Ryan and Dennis had the idea to come up with a user-friendly way of interaction with the users: A traffic light.

So we developed the System Center Configuration Manager Status Indicator (CSI) Windows gadget as a user-friendly interface between the SCCM client and the user. CSI displays information about application installation or uninstallation and informs the users about required reboots or logoffs. Most importantly, it tells the user when the SCCM client is not doing anything and when user-initiated installs can take place.

CSI comes in three flavors:

The CSI User gadget is a simple gadget that shows the status of the SCCM Client with a color. Users can hover over it to get a message with more status information. The CSI Power User gadget shows more advanced information, such as a time-stamped list of recent application installs.

And finally, the CSI Client was developed for OSes that don't support gadgets (like Windows XP), although it can be installed on higher OS versions as well. The CSI Client displays a tray icon that changes color depending on the activities SCCM Client.

You can find more information about installing and configuring this new tool in the admin guide that is included in the download (which, did I mention, is free?) You can download both x86 and x64 versions from LoginConsultants.com (registration required).

While we're on the topic of free tools for desktop application delivery, my colleagues Falko Greafe (@kirk_tn) and Matthias Wessner released a very elegant tool for analyzing App-V packages.

Sequences are not always easy to distinguish from one another and can therefore cause conflicts. (Funny that this seems like a contradiction with application virtualization, right?) So in order to get a quick overview of an existing Microsoft Application Virtualization software set, Falko and Matthias developed the App-V Analyzer.

The App-V Analyzer generates a list of all available virtual applications (including orphaned items) as well as their key App-V characteristics. The tool validates the existence of important publishing and execution properties and performs a conflict check of the most critical application and package properties, including published and unpublished applications. This way the tool helps to solve conflicts proactively and by doing so reduce pressure on support.

The App-V Analyzer is created to work in any deployment scenario, works independent from the publishing approach, and does not require specific backend software. Again, the free download can be found here (registration required).

Project VRC: a deep dive into VDI performance tuning

Jeroen van de Kamp — Mon, 27 Sep 2010 20:49:00 GMT

Ruben and I are pleased to announce we finally can release the long awaited Phase III whitepaper. As promised: this one does a true VDI deep dive. We think we have interesting new content, and more importantly, many new insights.

More and more organizations are planning a move to VDI. Experience in many VDI projects has proven so far that the performance and sizing issues are still a major hurdle to overcome. Often, VDI results are disappointing because the VDI environment is not properly sized and tuned. In practice, storage remains the number one challenge in today’s VDI deployments.

In this whitepaper Windows XP and Windows 7 are extensively compared. Specifically, the I/O behavior of Windows XP and Windows 7 is investigated in detail. By evaluating the different phases of a desktop workload, completely new insights are given.

Windows 7 has a much bigger disk footprint and consumes more memory than Windows XP. It would be reasonable to expect that Windows 7 requires more resources than Windows XP. Although this is certainly true, several tests in this whitepaper prove that Microsoft managed to optimize Windows 7 disk I/O behavior in specific phases of a desktop workload in comparison to Windows XP.

Many best practices are available to optimize Windows 7. Project VRC performed tests with the default optimizations configured by VSI (referred in this document as ‘VSI optimizations’) and additional optimization best practices that are specific to Windows 7 (referred as ‘VRC optimizations’). Both from an I/O and VSImax (maximum capacity) perspective, these ‘VRC optimizations’ proved to have a significant positive impact.

Project VRC also investigated the performance impact of topics like ‘Page file configuration’, ‘Address Space Layout Randomization’, ‘VM logging’, ‘ESXTOP’, ‘1 vs 2 vCPU’s’, ‘ESX 4.0u2 vs ESX 4.1’, and ‘Overcommitting Memory’. There are many lessons to be learned here, but the impact of disabling ASLR was striking. It is difficult to blindly recommend disabling such an important security feature, but the impact is large enough to consider it.

All tests were performed with either vSphere 4.0 U2 or 4.1 as the hypervisor and all VDI tests were performed using View 4.0. Apart from specific recommendations for vSphere, all Windows related conclusions are valid for any kind of hypervisor or VDI solution.

The ‘Project VRC phase II version 2.0’ whitepaper evaluated the impact of configuring a higher HaltingIdleMsecPenalty value on vSphere with Terminal Server workloads. This setting improved hyper-threading performance considerably for vSphere under high loads. Although no specific hints were given by VMware or the community, Project VRC investigated if a higher HaltingIdleMsecPenalty value would benefit VDI workloads. Surprisingly, a significant performance increase (more than 20%!!!) was witnessed for both Windows 7 and Windows XP workloads. The difference was so high that Project VRC internally started to call this the ‘Red Bull setting’.

Project VRC highly recommends to evaluate the data in this document carefully. Project VRC realizes there are always valid reasons not to use a specific settings mentioned in this paper. Real world VDI environments will always be different from the test-setup in the Project VRC labs. More importantly, Project VRC must emphasize that it is crucial to test and validate these optimizations in your own VDI deployment.

As usual, you may download the paper from www.virtualrealitycheck.net.

Follow Ruben on twtter: @rspruijt

Follow Jeroen on twitter: @theJeroen

New and still free: App-V Adm add-on 2.0 and ACDC 1.1

Jeroen van de Kamp — Mon, 21 Jun 2010 06:54:00 GMT

Cool, while Wilco was presenting a session at BriForum about free App-V tools, my colleagues Ment van der Plas and Ruben Koene released new versions of ACDC and the App-V Template with new features and to support App-v 4.6.

App-V ADM template 2.0
The App-V ADM template configures client setting for the App-V Windows Desktop Client and for the Remote Desktop Services Client. The ADM template centrally manages common client configurations by using an existing Group Policy infrastructure and includes settings for communication, client interface and permissions. The App-V Add-on ADM Template is an extension to Microsoft’s “App-V ADM Template”. Together, Microsoft’s and Login Consultants ADM Template allow a comprehensive management of various App-V Client settings.

The new App-V Add-on ADM Template is designed for Microsoft Application Virtualization Client version 4.5 and 4.6. It includes two ADM files; one for 32bit Operating Systems and one for 64bit Operating Systems. Other changed features includes:

Modified and Removed Features:

Virtual File System: This option has been removed because it is included in the Microsoft ADM.
Require Authorization If Cached: This option has been removed because it is included in the Microsoft ADM.
Cache location: Changed to App-V Client Cache File Location and included VDI shared cache (read only FSD).
Cache Size: This option has been removed because the cache size can’t be modified by just changing this registry key. Instead, you either have to flush/clear the cache by setting the “State” registry value to “0” before rebooting the client machine or you have to use Microsoft’s “App-V Cache Resizer Tool”.
Global Data Directory: This option has been removed because controlling it by a GPO setting is not very useful. Tests showed us that changing only the Global Data Location through registry resulted in a “hanging state” of the App-V client. Preferably this setting should be changed through the Client Management Console.

ACDC 1.1
The App-V Client Diagnostic and Configuration tool is now compatible with 4.6 andc makes it possible for administrators or users to troubleshoot virtual applications and the environment they run in:

Launch predefined and custom commands within the virtual environment of each application.
See the impact of the App-V Client and the available virtual applications on your system by calculating package size, cache size, user delta file size, log file size etc.
Diagnose problems with App-V applications by parsing the App-V Client log file (in real time) and search any message online.
Configure settings that are not visible in the App-V Client GUI, such as "Predictive Streaming", "Allow Stream from File", "Max Package Age" and many more.
Give an overview of application and package information by merging important WMI, registry and OSD information in one single window.
ACDC can be run both as an Administrator and as a Limited User. Running as a limited user will limit the functionality of the tool due to the fact that it has less permission on the system.

As usual, these App-V tools are free and availabe from the Login Consultants download section. (registration required)

With last week's VECD licensing change, is Windows 7 now the cheapest client?

Jeroen van de Kamp — Mon, 22 Mar 2010 04:01:00 GMT

The VECD licensing changes Microsoft recently announced made me wonder: is a Windows-based client with SA cheaper than a non-Windows non-SA client in a VDI scenario? (Since VECD is mandatory, the math becomes interesting.) This is something I've discussed before, but these fresh license changes have an interesting consequence: if you need a VDI solution with an optimal desktop experience, a Windows 7 PC is now easily the cheapest solution.

VECD licensing changes

In case you missed it, Microsoft radically changed their VECD licensing scheme last week. First, when a client device (PC) has SA on the desktop (~$50 per year), the VECD license is now included at no extra charge. Second, the VECD license for non-SA client devices has been renamed to VDA, and has a 10% lower annual list price ($100 per year).

Luckily--and this was a real show stopper before--Microsoft now allows users to work from devices other than their primary client device (like a home PC or kiosk) without a need to purchase additional VECD/VDA licenses. Although this is a very welcome change in VDI licensing, it's not important to our discussion today.

Time for some math

Let’s calculate a VDI scenario with the following assumptions:

Assumption #1. There's a need to have full PCoIP, HDX, or RemoteFX capabilities. For instance, this is driven by multimedia, Flash, or VoIP requirements. Ultimately the VDI solution must give users a mature and future proof-desktop experience.

Assumption #2. The VDI solution (including clients) is built to last five years.

To get the most out of HDX you need to run real Windows (not CE) on the client. This may be Windows Embedded or native Windows 7. To fully support VMware View PCoIP, you need either a Windows client or a native PCoIP device.

So how much would this cost for the device? After a quick glance around the Internet I found these cheapest clients which can fully support PCoIP, HDX, and RemoteFX:

Type	OS	Protocol	Warranty	List Price	VECD license
HP t5740	WES 2009	HDX RemoteFX	3 yrs limited	$ 429	VDA
Wyse P20	HW PCoIP	PCoIP	3 yrs limited	$ 499	VDA
Dell Optiplex 160	Win 7 Pro	PCoIP HDX RemoteFX	3 yrs NBD	$ 488	SA

Let’s do some calculations:

HP t5740 plus 5 years VDA license: $429 + (5 * $100) = $925

Wyse P20 plus 5 years VDA license: $499 + (5 *$100) = $999

Dell Optiplex 160 plus 5 years SA license: 488 + (5 * $50) = $749

You could argue the license costs of the management platform for Windows 7 are missing. However, the Microsoft Core CAL (which is typical for most organizations since it's cheaper than separate Windows Server and Exchange CALs) also comes with a MS System Center Configuration Manager license which you can use for the management of a Windows 7 client.

Thinking VDI? Use a Windows 7 PC!

Here's the deal: no matter what VDI platform, the Windows 7 Professional PC option with SA is the cheapest solution when you have full rich functionality requirements (which is not a bad idea if you want a future proof desktop solution). Until there's a ultra-cheap (probably Linux-based) thin client solution out there that can 100% support PCoIP, HDX, or RemoteFX, Windows seems like a cost effective solution for client devices in a VDI world. The weird thing is it's likely that super cheap RemoteFX Linux / WinCE clients will emerge pretty soon, but then you're stuck to VDA.

It makes you think, doesn’t it? Seems like Microsoft wants you to stick to using Windows as a client OS. (Or to at least consider it...)

Choosing the right App-V delivery model

Jeroen van de Kamp — Fri, 19 Feb 2010 05:00:00 GMT

Organizations who move towards Microsoft Application Virtualization often wonder what the best delivery infrastructure is for their environment. In the days of SoftGrid there was only one way of delivering your virtual applications to the end-user: you built a dedicated SoftGrid infrastructure. But since the introduction of App-V 4.5, the possibilities have been extended, making the product suitable for almost every environment.

Due to the number of architectural possibilities, it’s hard to decide which is the right one. Each of the currently available scenarios has its pros and cons, and available functionality depends on the scenario that's chosen.

My collegue Ment van der Plas decided to investigate the integration details and describes all these in a new white paper: Choosing the right App-V Delivery Model (App-v integration: possibilities and impossibilities).

Let’s first discuss some architectural basics. Any App-V infrastructure consists of two key elements:

How the (virtual) app sandbox is configured and how the apps are executed. (This could be thought of as the "virtualization" part.)
How the (virtual) apps are physically delivered to the end-user workplace

The virtualization part of App-V is a client component only which is established through the App-V Client. All virtual App-V applications run in a sandboxed execution environment where they're unable to change the system or interfere with other applications. Even though the App-V client is available via two separate installers (the App-V Client for Windows Desktops and the App-V Client for Remote Desktop Services), the virtualization aspect is exactly the same in both installers.

The delivery component of App-V can work in a few different ways, including scenarios that have server-side App-V components. (The App-V server-side components enable efficient streaming application technology, delivering only the bits needed to run the application.) The number of different delivery options has grown with the introduction of Microsoft Application Virtualization 4.5, which now includes:

App-V full infrastructure model
Configuration Manager 2007 R2 Integrated model
Standalone Deployment model

App-V full infrastructure model

In the App-V Full Infrastructure model application, delivery is instant. The App-V client uses a mechanism called “publishing refresh” to receive the authorized applications from the Management Server for a particular user. By default, refreshing happens during logon and / or every certain interval, which can be customized to your needs.

After the client refreshes, the authorized applications are displayed directly for the end-user as if they were installed locally by showing shortcuts, file types associations, etc. When the user starts a given application it's streamed to the client and launched.

When a user is deauthorized for an application they can no longer use it, and after a client refresh the shortcuts and file types associations are removed. Applications can also be centrally disabled meaning that no additional applications startups are allowed, even on machines that have the application already available.

Configuration Manager 2007 R2 integrated model

The Configuration Manager 2007 R2 integrated model requires Microsoft System Center Configuration Manager (SCCM) 2007 SP1 R2 or higher as a delivery infrastructure. Configuration Manager 2007 is comprehensive management solution able to deploy, manage and assess Windows client, server and mobile systems.

Functionality of SCCM 2007 includes Operating System deployment, software update management, asset inventory and application management.

SCCM 2007 manages both traditional installations (including MSI) and virtual applications (App-V). All application management is presented and done from a single console, making adoption and use for IT administrators easier. Many of the advanced capabilities available to manage MSIs are also available for virtual applications, like building complex queries in collections to define which devices are targeted.

Unlike the App-V Full Infrastructure delivery method, the SCCM-integrated model can target machines in addition to users.

Standalone model

The third delivery model is referred to as the “Standalone model”. It’s called standalone because the App-V client is not configured to connect to any App-V server delivery infrastructure whatsoever. Instead applications are delivered to the client through a wrapper (which is an MSI package).

The MSI package holds all metadata of the packaged application (OSD files, icons etc.) except for the large binary file that makes up the actual application (SFT file). The SFT file is not inside the MSI because of size limitations of Windows Installer. (Unfortunately this means that OSD files can only be edited via the Sequencer, which is the software that admins use to build their packages.

Using the standalone method of deployment, if you edit an OSD you have to recreate the MSI file and distribute it to the clients since the clients don’t refresh. (Although luckily there is an option in the sequencer that can generate the MSI without saving the project al together.)

Choices...

Ment's "Choosing the right App-V Delivery Model" white paper addresses these differences in available deployment architectures and their level of functionality. With this information, organizations (you) can make more solid choices when designing and integrating App-V...Highly recommended stuff!

Out now: New VRC paper "TS on next-gen hypervisors and hardware"

Jeroen van de Kamp — Tue, 16 Feb 2010 05:00:00 GMT

Wow, this took a little longer than expected. No.. actually this actually took a lot longer. Ruben Spruijt and I can finally announce the official release of the Project VRC Phase II white paper. This is the biggest release so far and is now available on Projects VRC’s dedicated website www.virtualrealitycheck.net.

This white paper focuses on Terminal Server workloads running on the latest generation Intel processor: the Xeon 5500 series (Nehalem). We did things a bit differently this time, as we now chose to publish the results of the big three hypervisors in a single paper. Ruben and I hope you will find this interesting, even though it should not come as a surprise that Intel’s Nehalem is a fantastic performer with virtualized TS workloads. (Although we still feel we have a couple of interesting angles.)

In this paper we tested Terminal Server 2003 (x86 an x64) workloads on the latest hypervisors from Citrix, Microsoft and VMware with the latest version of the Login VSI benchmark. We also discussed the impact of Office 2007 SP2, Internet Explorer IE7 versus IE8, Citrix CPU Fairshare, the impact of the vMMU settings in vSphere, and much more.

On a side note, Ruben and I learned a big lesson for future Project VRC papers: The next papers will not be this big anymore. There are so many interesting things we can investigate and report on, but is logistically too challenging to put so much in single paper. As a result, the next releases of the project VRC white papers should come at a higher interval. The upcoming series will not focus on TS anymore, but completely on VDI. Ruben and I are really looking forward to this as there are many fascinating topics we can investigate. (But more on this in the future.)

For now, Ruben and I hope you enjoy this latest chapter in the VRC story, and we're looking forward to your thoughts and feedback. You can follow Project VRC on twitter: “ProjectVRC”, “TheJeroen” & “rspruit”.

"A fool with a tool is still a fool"--words of wisdom in IT

Jeroen van de Kamp — Mon, 25 Jan 2010 19:00:00 GMT

When you've been building desktop and application virtualization solutions for so many years, you have to be blind not to spot the typical patterns which re-occur in almost every project. Actually, it's fun to identify them when you talk to your peers who've been in the same business for so long.

The same themes repeat themselves: bloated expectations of virtualization, how projects are managed, the business case for automation and management tools, how people perceive IT, clichés that seem even truer in IT, etc…

Before you know it, you end up in the conversation with the “Zen”-like one liners, quotes, and wisdoms: Some are brutally boring but painfully truthful, while others are just plain funny (and also painfully truthful).

Here's a small collection of quotes / one liners / Zen wisdoms / that we came up with (in no specific order):

“A fool with a tool is still a fool.”

“Beware of the IT guy who won't be bothered with details.”

“IT is simple but it’s difficult to make IT simple.”

“Virtualization is NOT a management solution: it can only simplify management.”

“Image-based deployment is deployment, NOT management. (Not even close).”

“100% automation brings extreme scalability: what is difference between full automation of 10 or 10000 computers?”

“Golden rule of server management: only apply changes after a reboot.”

“It is cost effective to automate repetitive tasks; it is expensive and complicated to automate everything.”

“Nothing is permanent, except for temporary solutions.”

“Installing a new environment is easy. Making it capable of change is the tricky part.”

“Know what you are automating before you automate it.”

“Real men don't click.”

“Assumption is the mother of all f**k-ups... and not checking afterwards is the mother-in-law...”

“IT marketing is more hyped than next season's fashions colors and the MTV awards combined.”

Now, most of us at Login Consultants are not native English speakers, so I'm quite confident that the Brian Madden visitors (you) can easily expand the list with way more funny and interesting ones...

New Free App-V Self Support Tool (and how to make friends at the helpdesk)

Jeroen van de Kamp — Wed, 20 Jan 2010 02:54:00 GMT

When you deploy App-V applications on laptops and pc's, expect a lot of helpdesk calls. While App-V is a mature application virtualization solution, it is interesting to see that a simple design decision does actually not make a lot of sense…

One of the things that you will find out early on when actual users start working with App-V, is that sometimes they manually need to reset, preload and refresh their virtualized applications. As a result, you will need to give users access to the App-V client MMC plug-in.

The problem is, the MMC is typically off-limits for normal users in the enterprise because of security policies on desktops and laptops. And even when users have access, try explaining non-technical users how to work with the App-V client MMC plug-in. The App-V client configuration is simply way too clunky for normal users.

This may seem like a minor issue, but imagine how much helpdesk calls the App-V client can generate in a 100.000 App-V user environment…

This is why Rodney Medina and Peter Nap, my colleague from Login Consultants with some decent coding skills and smart ideas, decided to develop a light-weight, super user friendly tool which does not require MMC access.

This App-V Self Support Tool consists of a single .exe (App-V SST.exe) and a XML config file (App-VSelfSupportTool_settings.xml). Just copy these to the PC/Laptops and make sure user can access the tool through a shortcut on the desktop or start menu. You can change the banner to your liking and the other languages can easily added in the XML file.

The interface is deliberately simplified, so users can find their way around. There are only a few options: View, Language, Repair, Cache, Start and Refresh. Users do not need anything more, and more importantly, they are not required to ask the helpdesk to support them.

The tool is so simple, documentation is overkill. All information you need is condensed into a 5 minute video included in the download.

The App-V Self Support Tool is free and available in the tools download section of www.loginconsultants.com (registration required).

PS: We tried virtualizing the App-V tool itself, but this did not work like expected: so, virtualization of the App-V Self support tool is not recommended. ;-)

Best practices for virtualizing terminal servers, from Project VRC Phase 2

Jeroen van de Kamp — Sun, 10 Jan 2010 04:00:00 GMT

Ruben and I are getting close to the release of the Project VRC phase 2 white paper. (Here's a primer on Project VRC if you haven't heard of it.) Although we've been discussing and presenting the best practices from the first paper around the world, it's still important to understand Project VRC’s methodology and how the results should be interpreted. This article is a preview of the next VRC whitepaper:

Virtual CPUs (vCPUs)

A Terminal Server is similar to a highway--it's shared by its users. And just as a highway with multiple lanes is more efficient than a single lane, so too is a Terminal Server with multiple vCPUs. Besides the obvious advantage of increasing capacity, adding a second lane means that the impact of an accident or slowdown is greatly reduced as traffic can still get through via a free lane. In other words, having more than one lane means a single slowdown doesn't impact everyone.

This is not fundamentally different with Terminal Server workloads. Configuring each VM with a single vCPU could theoretically be more efficient (or faster). But in the real world of Terminal Server workloads, this is highly undesirable. Such workloads vary greatly in resource utilization and are typified by hundreds or even thousands of threads in a single VM, so a dual vCPU setup gives Terminal Server users have much better protection than a single vCPU against congestion issues.

This means that a minimum of 2 vCPUs per VM were configured for all tests for Project VRC, even when a single vCPU has been proven to be more efficient. This best practice is also valid for practically all real world Terminal Server-based workloads. (This also applies to Terminal Servers running third-party add-ons such as Citrix XenApp.)

vCPU Overcommit

Another important best practice which is valid for all tested hypervisors is not to overcommit the total amount of vCPUs in relationship to the available logical processors on the system. For example, on a system with eight logical cores, no more than eight vCPUs should be assigned in total to all VMs running on the host. (Well, technically this is only important when the primary goal is to maximize user density. )

Various tests in phase 1 of Project VRC have proven that overcommitting vCPUs negatively affects performance. This is not completely surprising since overcommiting means that multiple VMs must share individual logical processors which creates additional overhead.

As a result, Project VRC will not overcommit vCPUs in any tests since the maximizing user density is the primary goal. But it's important to understand that overcommitting vCPUs is not prohibited in every case. For example, when the main goal is to maximize the amount of TS/XenApp VM’s (good old fashioned server consolidation), overcommitting vCPUs is no problem at all. (In these cases, however, configuring two vCPUs per VM is still recommended because the “highway” principle still applies.

Transparent Page Sharing

vSphere’s ability to overcommit VM memory and memory de-duplication through transparent page sharing (TPS) is highly useful for the consolidation of many VMs onto a single server. Nevertheless, one of the older Terminal Server best practices floating around the Internet communities was to disable TPS. And in fact Project VRC phase 1 showed that disabling TPS actually improved performance by 5-10%. This makes sense since TPS is made possible via a background process which scans and reallocates memory, consuming a modest amount of CPU in the process.

When it is the primary objective to maximize the amount of users with Terminal Server workloads and there is enough physical memory available, we still recommend disabling TPS. As a result, all Project VRC tests were conducted with TPS disabled, unless stated otherwise.

However, this VRC recommendation should not be understood as an overall recommendation to disable TPS. For instance, when the main goal is to maximize the number of VMs is (which is quite common, e.g. VDI and rather typical server consolidation efforts), TPS can be very helpful and is recommended.

Interpreting Project VRC Results

Lastly, Project VRC uses the product-independent Login Consultants VSI 2.1 benchmark to review, compare, and analyze desktop workloads on TS and VDI solutions. The primary purpose of VSImax is to allow sensible and easy to understand comparisons between different configurations.

The data found within Project VRC is therefore only representative for the VDI & TS workloads. Project VRC results cannot and should never be translated into any other workloads like SQL, IIS, Linux, Unix, Domain Controllers, Network, etc.

Also, the “VSImax” results (the maximum amount of VSI users), should never be directly interpreted as real-world results. The VSI workload has been made as realistic possible, but it always remains a synthetic benchmark with a specific desktop workload. Real world TS and VDI performance is completely dependent on the specific application set and how and when these applications are used. To include specific applications or customize the VSI 2.1 workload, VSI PRO must be used.

It is important to stress that no benchmark or load testing tools can 100% predict the real-world capacity of an environment, even when the specific applications are used. Real-world users are simply not 100% predictable in how and when they use applications.

Do you virtualize TS/XenApp workloads?

Nowadays, there are many reasons to virtualize TS/XenApp workloads, and there are reasons not to virtualize TS/XenApp. Do you agree with the Project VRC best practices? Do you virtualize TS/XenApp? Why (not)? Have you been succesful with it?

The fundamental flaws of thin clients

Jeroen van de Kamp — Wed, 28 Oct 2009 18:00:00 GMT

Sorry, I have to get this of my chest. As you might suspect after reading the not-so-subtle title, there is something fundamentally wrong with thin clients.

Let me be specific here: I am NOT talking about good old trusty SBC (Terminal Server/XenApp) or the hot and sexy VDI as a concept. I'm talking about the actual "desktop appliance" or "access point" or "thin client" itself.

This discussion is not new, but now that VDI has made hosted desktops an attractive option again, there's a sort of revival of thin clients in our market space.

Thin clients can be discussed from two angles:

First, there is the typical Citrix user who's been doing SBC for years already and has been pretty successful with it.
Second, there are the organizations venturing into the VDI space who are interested in the power, manageability, and cost advantages of thin clients.

From either perspective (both SBC and VDI), that the only logical choice for the thin clients is not to use typical thin client solutions, whether Linux, Windows CE or Windows XP embedded.

To understand that logic, let's look at the constants we need to deal with in the context of thin-clients:

1. Organizations are required to build a mature and fully automated management infrastructure for PCs and laptops, even when 90% of the clients are “thin.”

The majority of distributed organizations with 1000 desktops or more are often required to support conventional PCs (for rich media editing, 2D/3D design, etc...) and laptops (mobility). This is today’s reality of Enterprise IT. Deploying 100% thin clients is still not feasible in the typical heterogeneous IT environment, even if you're considering all innovations we currently see in remoting protocols from all major vendors.

The problem is that it's not economic to neglect the management aspect of the remaining 10% (or whatever) of devices that are laptops or PCs. You can't ignore patching them just because they're the minority. And manual configuration of PCs and laptops is just too costly in distributed environments, even if you perform only one change every year. So this means that unless you can go 100% thin clients (which I don't think you can), then you have to build a management system for your non-thin clients.

The good news is PC management has matured considerably over the past few years. Building an effective management solution for laptops and PCs is not rocket science anymore.

And by the way, BYOL (Bring your own laptop) doesn't this fix this problem. BYOL is a cool concept, but the majority of organizations still require full management of the desktop/laptop for practical, legal, or security reasons. In most cases BYOL is not an option.

2. When it comes to the support of innovation and new features within remoting protocols such as RDP and ICA (HDX), traditional Windows (XP+) is, by a big margin, the best platform to choose.

All the cool features, especially those which require client-side rendering, are first developed for Windows. Quite often such innovations demand the availability of CODECs, the .NET framework, WPF, the Windows USB or printer driver architecture, and more.

The fact is that Linux or Windows CE as a thin client OS seriously lacks the rich media and user experience optimization support we see being developed first for the Windows client. This is relevant because any user experience- and performance-related innovations are very important to our end users and ultimately, the acceptance of any SBC and VDI solution.

3. A thin client is not a “fire and forget” solution. Thin clients require a mature deployment and management infrastructure.

Don’t believe me? Talk to all the IT admins who've been supporting thin client for years. They'll tell you from experience that a management infrastructure is required to deploy security fixes, client/application upgrades, root certificates, firmware updates, and configuration changes. Those who don’t probably have a very static IT environment.

In comparison to conventional fat clients, the rate of changes and updates on thin clients is considerably lower. However, one single update already justifies the investment in a management infrastructure, as manual configuration of all your thin-clients is extremely expensive.

The reality of thin devices, regardless of protocol, and even hardware embedded solutions (e.g. “PC-over-IP” devices), is that you need to be able to centrally manage and update them. The minute a bug is discovered, a security fix is required or a configuration change is needed--you need a management infrastructure where you can automate such changes.

4. Windows XP Embedded is not a thin OS at all...

Windows XP Embedded is surely more light weight than conventional Windows, but it's far from thin. Even when the OS is stored on a read-only flash disk, you still need to apply the monthly security updates and virus scanner/firewall updates to ensure the client doesn't become a broadcast station for worms within your network. In practice there are just too many examples of unmanaged XPe devices being the “source of all evil.” Remember Blaster and Sasser?

You could argue that there are a far fewer security updates required for XP Embedded. Unfortunately it's fairly common to use Internet Explorer to provide a web portal front-end to authenticate and access the SBC or VDI desktop. This means that, many of the monthly security updates are also valid and important for Windows XP embedded clients.

Finally, the reality of XP Embedded management solutions that they're very similar to the management infrastructure for PCs and laptops. These XP embedded management solutions have a lot of the same functionality and share the same complexity.

5. And all these other “little things” that we tend to forget or overlook:

What about the standard vendor lock-in when using thin clients? Or do you want to support five different thin client devices with three different management tools from two different vendors after five years? You have no choice: in contrast with PC hardware, thin client management tools are vendor-dependent.
Does the thin client vendor still provide updates for that five year “old” thin-client?
How quick is the thin client vendor with making client bug fixes available for your client device when Citrix/Microsoft/VMware releases a new version of their client software?
Cheap thin clients are clearly much slower when displaying remoting protocols: just compare the protocol display speed performance of Internet Explorer, PowerPoint, PDF and Excel to the protocol display speed performance on entry level PC hardware.
Do you need the Full Monty when it comes to remoting protocol and user experience? The high-end thin client will be anything but “cheap”.
Are doing VDI and using a non-Windows thin client? A VECD license is your only option. This will cost you $110 (The list price, per year, per “access point.”)

Considering these constants, are we truly aware of what the long term impact of a thin client is? Surely, traditional thin clients can be a very successful when the requirements are low, but when the latest and greatest is required, you have another option.

The solution: a thin PC

A smart client, slim client or thin PC--it's just a name--but this is basically a PC with OEM Windows Professional (XP to 7) configured as a thin client. This thin PC can be easily built on the same image and same deployment infrastructure used for PCs (and laptops). However, in “thin mode” this desktop is automatically logged on with a local generic account which is completely locked-down. In this mode only IE and the client software can be started to authenticate the user and provide access to the SBC/VDI environment. Functionally it's identical to Windows XPe.

Just secure the thin PC the same way we learned with XenApp / Terminal Server and configure software restriction policies (or now applocker with Windows 7) to lock down the machine even further. Additionally, use the free Steady State tool from Microsoft with is specially created for a read-only kiosk mode: http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx

Consider this:

Chances are high you already have a deployment and management infrastructure for your PCs and laptops. What is the extra effort is required to also use this infrastructure for thin PCs? Let me rephrase this: if you already (properly) automated desktop deployment/management, how much effort would it cost you to upscale PC management from 100 to 1000 desktops?
If you were to switch PC vendors, or when your current vendor introduces a new model, you can just continue managing the new devices using your existing deployment infrastructure.
How expensive is a basic, entry level, slim-line, Windows Professional PC including 3 years support (or even netbooks and Atom-based devices when green IT is important)? Is it more expensive than a high-end XP Embedded client? Isn't it not much faster and far more functional than a high-end Windows XP embedded device?
How good would a 3 year “old” PC perform as a thin PC?
Would you use the option to install local client applications such as VoIP?
Want to provide all the latest and greatest multimedia and user experience innovations, the latest protocols, and newest client software/codecs/drivers to your end users? How difficult would this be of you can manage the PC the way you want?
SA on Windows ($50) and VECD for SA ($23) will total $73 per year if you get SA within 90 days of purchase of a PC with OEM Windows Professional. How does this compare to the going rate for standard VECD license of $110/year for non-Windows clients?

Is the thin PC the only way to go? No, but in many cases it seems the only logical long-term solution, especially when you need to support a heterogonous desktop environment which includes PCs and laptops.

Sure. there are plenty of scenarios and reasons--especially in organizations with no diverse desktop requirements--to go the traditional thin client route. But organizations considering thin clients should at least be aware of the choices now possible. And in many cases the most logical thin client option is actually quite fat.

PS: I got the VECD pricing from this article, feel free improve this information when needed.

New Project VRC Whitepaper: "VRC, VSI and Clocks Reviewed"

Jeroen van de Kamp — Mon, 14 Sep 2009 06:25:00 GMT

Ruben and I just released a new Project VRC whitepaper called “VRC, VSI and Clock reviewed”. The content of this whitepapers is quite academic, but very relevant to Project VRC. We describe in detail the things we have learned, and how we improved VSI along the way. We also investigated the impact on VRC results: it is interesting to see how results changes when comparing hypervisors.

“This whitepaper is a review and reflection on previous Project VRC publications, the benchmark: “Login Virtual Session Indexer (VSI)” and Windows clock behavior within virtual machines. This discussion is fueled by the fact that results from the individual Project VRC whitepapers are set side-by-side to compare hypervisors. Project VRC has been in discussion with both vendors and community, and performed additional research in this context. Before Project VRC can publish new results, it is important to address any questions, review the impact of this discussion and improve VSI where possible. “

“For Project VRC to move forward and publish new results, it is important to fully understand the impact of this conversation and improve the methods used where possible. In this document the following topics are addressed:

1. The Login VSI Methodology;
2. VSI 1.0 Optimal Performance Index;
3. “Stuck” Sessions;
4. Response time measurement method and clock drift;
5. Using Microsoft SQL Server 2005 as a reference clock;
6. Login VSI 2.0;
7. Reviewing Citrix XenServer and VMware vSphere 4.0;”

As usual, download the whitepaper from www.virtualrealitycheck.net.

VSI 2.0 Beta 3 now public

Jeroen van de Kamp — Wed, 09 Sep 2009 03:09:00 GMT

We have been working on VSI 2.0 the whole summer. Login VSI 2.0 is the second iteration of Login VSI 1.0: the free and specifically designed benchmark for SBC and VDI environments. VSI 2.0 introduces completely new workloads, and a improved and more accurate index called VSImax. Overall, VSI 2.0 will be a much smoother experience, many best practices and lessons learned from project VRC are now included in this release. The free version will now be called “VSI 2.0 Express”, the advanced version is called "VSI 2.0 PRO”. The most important new 2.0 features are:

Workload(s) re-build from scratch:

New, more realistic, medium workload (now 12 instead of 18 minutes)
Real-world end-user websites (with rich flash content)
Windows 7 and Windows 2008 r2 support
IE 8 support
New Zip and PDF printer (BullZip)
Highly improved robustness (even under extreme loads)
Improved response timer mechanism and index: VSImax

VSI 2.0 PRO features:

Multilanguage Support (Express only support English OS and Office)
Detailed logging
Runtime calibration of timed events and response time measurement using an external SQL server clock (important for hypervisor comparisons)
Office 2003 and Office 2010 support
Customization Support (ad your own apps to the VSI workload)

Analyzer Changes:

New VSImax calculation: much more precise
Automatic renaming of excel files to “testname.xltm”
Remember settings from last session

AD Setup Changes

Split system / user policy objects / added Computers OU
Improved setup user objects (no password expiry etc)

Launcher:

New pre-launch naming of test: no more archiving of tests needed

This beta can be downloaded from Login Consultants download section: http://loginvsi.com/en/downloads/downloads.html.

"Because we can!" Distribute App-V apps via USB stick with our free new tool.

Jeroen van de Kamp — Thu, 27 Aug 2009 22:09:00 GMT

Cool, finally we released it. My colleagues Peter Nap and Rodney Medina (www.softgridblog.com) made the free App-v USB tool available for download. With this App-V USB Tool you can distribute your apps via USB sticks.

The App-V USB Tool is an add-on to the App-V 4.5 Client. It makes it possible to automatically, or by request, import and register App-V enabled (sequenced) applications into the App-V Client from any USB storage device. Note: This will only work with applications that are sequenced with App-V 4.5 sequencer or above.

When the App-V USB tool is running it displays an icon in the system tray.

As soon as you insert a USB storage device, the App-V USB tool detects this and shows the following options.

When you select “Scan and Auto-Import all Virtual Applications” it will scan the complete USB storage device for App-V 4.5 sequences and import these automatically.
When you select “Scan and show list of found Virtual Applications” it will show a list of these applications. You can then select which applications you would like to import.

Once the tool is installed, there is also an option to right-click on any folder (local or USB storage) that contains App-V 4.5 sequences, and Auto Import.

Download here.