It took five years and probably lots of customer complaints, but finally one of the most important technologies introduced with XP/Server 2003 is available over the remoting protocols RDP and ICA: font smoothing aka ClearType.

If you have read other articles on this blog you know that I deem font smoothing indispensable on today’s LCD monitors. For some reason Microsoft included the technology in Server 2003, but decided not to make it available over RDP. This put Citrix in a difficult position – they could not enable font smoothing over ICA either because some key system component was missing. They had to wait for Microsoft to make the first move.

What You Need – KB946633…

Now, finally, this has happened. Microsoft released a hotfix that enables font smoothing over RDP by default. If you want to restrict your users to not being able to use font smoothing (maybe because of bandwidth considerations) you can set the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\TSEnableFontSmoothing=0

At least service pack 1 is needed in order to install hotfix KB946633 on Windows Server 2003. On the client side you need at least RDC 6.0.

In order for ClearType font smoothing to work it must not only be enabled per computer (see above, TSEnableFontSmoothing), but also in the remote desktop client and the user profile on the terminal server.

…Which You Can Even Get Online…

A while back Microsoft changed its policy with regards to “semi-private” hotfixes. In the past one had to call MS support, talk to them for a few minutes and would then get an e-mail with URLs to password-encrypted hotfix files which had then to be downloaded and unpacked with the current password contained in the e-mail. Sounds tedious? It was! Luckily this changed – a bit. “Semi-private” hotfixes like KB946633 can now be requested online without having to call MS support. Be sure to look out for the text “Hotfix Download Available” near the top of the KB article. But you still get an e-mail with the URL to the password-encrypted hotfix…

…and PSE450R02W2K3037

Just yesterday Citrix released its own hotfix for Presentation Server 4.5 on Windows Server 2003 that enables font smoothing. It needs to be installed on top of MS KB946633. Apart from making font smoothing available it fixes various issues in Presentation Server 4.5 R02 (rollup pack 2).

The post Finally! Font Smoothing Over RDP/ICA on Server 2003 is original content of Helge Klein - Power Tools for IT Pros.

With the release of the hotfixes KB946633 and PSE450R02W2K3037 ClearType font smoothing is finally available on both the current and the upcoming Citrix flagship products Presentation Server 4.5 and XenApp 5.0. Remains the question of how to configure it.

Disabling Font Smoothing #1

First of all, font smoothing over RDP and ICA connections can be disabled altogether by setting the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\TSEnableFontSmoothing=0 [DWORD]

This applies to all connections to the server but unfortunately only works on Windows Server 2003. I have not yet found a way to disable font smoothing on Server 2008.

Disabling Font Smoothing #2

On XenApp 5.0, font smoothing can also be disabled in the web interface. Unfortunately that applies to the whole site.

To disable font smoothing for a “XenApp Web” site:

• In the access management console (AMC) go to Citrix Resources -> Configuration Tools -> Web Interface
• Right-click on the appropriate “XenApp Web” site name and choose “Manage session preferences”
• Navigate to Remote Connection -> Display
• Uncheck “Allow font smoothing”

To disable font smoothing for a “XenApp Services” site:

• In the access management console (AMC) go to Citrix Resources -> Configuration Tools -> Web Interface
• Select and expand the appropriate “XenApp Services” site name by clicking on the plus sign
• Right-click on the sub-item “config.xml” and choose “Change session options”
• Navigate to “Display”
• Uncheck “Allow font smoothing”

Configuring Font Smoothing #1

Once you made sure that font smoothing is not disabled per computer or per web site, you can start worrying about how to configure it – per user. The following registry value sets the font smoothing type:

HKEY_CURRENT_USER\Control Panel\Desktop\FontSmoothingType [DWORD]
 
Possible values:
 
0:	Font smoothing disabled
1:	Standard font smoothing (designed for CRT monitors)
2: ClearType font smoothing (designed for LCD monitors)

The default value is 2, i.e. ClearType font smoothing is enabled. The default value originates from the default user profile (typically C:\Users\Default\NTUSER.DAT).

ClearType font smoothing is also enabled on the logon desktop. This is stored in HKEY_USERS\.DEFAULT\Control Panel\Desktop\FontSmoothingType.

Configuring Font Smoothing #2

Windows has a GUI for configuring font smoothing (well hidden in the display properties). XenApp does not.

Each user of a published desktop can use the Windows GUI for configuring font smoothing. But what about the majority of XenApp users who only use published applications and do not have access to a published desktop? I do not know. Of course, the admin could set the font smoothing type in the registry for them. But even then users have no means of changing their setting.

Enter XenApp 5.0 and ICA client 11. If and when those two are at the server respectively client end of an ICA connection, the whole thing works the other way round: The ICA client reads the font smoothing type of the Windows client and transmits it to the server who then activates the client’s setting for the current session. This even works across reconnects: During a reconnect from a different machine the new client’s setting is read and transmitted. If it is different from the previous client’s setting the font smoothing type of the session is changed on the fly.

This approach clearly has its advantages: No problems with published applications. Additionally, remote applications always have the same look as local programs.

But wait: What if the client is not a Windows client? Then we are back to the pre-XenApp days: Configuration on the server.

Configuration Overview

Just in case you got confused: The following table lists all requirements and configuration options:

Disclaimer: Font smoothing might also work with ICA clients older than 10.

Where is the Policy?

Enabling ClearType font smoothing increases the bandwidth required by ICA connections. On a LAN the increase is small enough to be negligible. But the same is not true for low-bandwidth WAN links.

The logical step would be to disable font smoothing for users coming in over slow links. There is only one problem: How to do it? The natural place for configuring this would be a Citrix policy. The release preview of XenApp 5.0, however, does not come with such a policy setting. Hopefully Citrix will add it in the final release.

If not, only one option remains: Setting up two web interface sites, one for LAN users and another for WAN users. But that is far from elegant and user-friendly.

The post How to Configure Font Smoothing on Presentation Server and XenApp is original content of Helge Klein - Power Tools for IT Pros.

It seems the Citrix community had only had one topic recently, albeit one discussed hotly: licensing. Now that Citrix has given in and practically allowed all conceivable license types, everybody is happy?! It seems so, although CCU licenses have doubled in price, as Shawn Bass points out. But is this really the happy ending of a short but wild story? Maybe, maybe not. Let me explain.

Shawn Bass writes in his article, “it’ll be interesting to see how these licenses get deployed, allocated, revoked and troubleshot”. There is much truth in that. The new flexibility comes at a cost, and in two different areas.

Understanding It

Citrix licensing used to be fairly simple (and simply fair, though not cheap). One license for each user while accessing the system. No license for inactive users not using the system. Now customers have to choose between per user, per device, campus-wide and VDI edition. Although choice is great, clarity and simplicity are not bad either. That brings me to my first point: Who wants Citrix licensing to be as complex as Microsoft licensing, where only select few specialists fully understand it, even at Microsoft!?

Coding It

But not only customers may suffer from the new flexibility: there is a technical side to licensing, too, at least if it is enforced. If what I have been told is true, the current version of XenDesktop 4 has no licensing enforcement built in. Good for customers, but managers do not appreciate such a state of “uncertainty”. That makes it likely that enforcement will come in a future version of XenDesktop. But how to do it? I can only guess if the current architecture of licensing server can cope with the changes that come with XenDesktop 4. Maybe it can, but it will not be simple to code all these options. And then there is offline usage on the horizon. How do you take a CCU license offline? If you remove it from the CCU pool and assign it to the user or device going offline, it is not a CCU license any more, but gets transformed into a user/device license. So here is my second point: As Shawn indicated, license enforcement requires software for a large number of processes, from purchase to tracking to upgrading. This software needs to be written and maintained, all the while rather becoming (hopefully) than remaining user-friendly. This has not become easier with the recent changes.

And here is a third point disguised as a question: Microsoft has had no enforcement of per-user terminal server CALs since Server 2003 – did it hurt them financially?

The post New XenDesktop 4 Licensing Model: Flexibility? Yes, but at what Cost? is original content of Helge Klein - Power Tools for IT Pros.

I just returned from my first CTP (Citrix Technology Professional) meeting and thought I might share a few experiences.

The meeting took place in one of Citrix’s headquarter buildings in Fort Lauderdale, Florida. The meeting itself ran over two days, which means that most attendees were away from home and work for four. While that is certainly nice to know, the question you probably have is: “What does actually happen during such a meeting?”

It basically goes like this: You sit in a room with the other CTPs and a roughly equally large number of Citrites and listen to presentations where program managers outline roadmaps and major new features of their specific product. When a thought strikes you, you make a comment that sometimes becomes a major discussion. All this goes on for two days, from 8:00 to 18:00 with practically no break at all, because everything happens at staccato pace. Why so fast? Citrix has so many products and technologies by now, that even with (short!) 30 minute slots per presentation time is extremely scarce. The net effect is – shallowness. Sure, all people in the room are very clever and experienced and can sometimes spot deficiencies in mere seconds. But…

Many topics are complex. And complex needs time. Add to that the facts that good discussions need a “seed time” of probably 15 minutes to get started, and that most problems do not have a single “best” solution but several potential solutions that all have their merits. All these points hint at the following: less topics with more time for each single one.

A Suggestion

Why not divide the time available into halves: a first half where product managers can pitch all they like in a short timeframe. This half would be like most of this week’s CTP meeting.

But then there would also be the second half, in which key topics that are most interesting to both Citrix and the CTPs are discussed in-depth. The agenda for this second half could be voted for by both Citrites and CTPs – that way, both the company and its community would have a say in what needs discussing.

Disclaimer

Why do I make these comments publicly and not on some internal forum or mailing list? I see my role as a CTP as being a representative of the community of Citrix users. Obviously the members of the community have a right to know what their representatives are doing while representing them.

Please note that I wanted to highlight a specific problem in this post – lack of time. That does not mean that we did not have good discussions at all. There were several of those, too, both during the day and during the after hours program. And it was great to meet and talk to all these very smart people. I just have a hunch that it should be possible to make CTP meetings more valuable for everyone – for Citrix, the CTPs and also the whole community.

The post What is a CTP Meeting all about? is original content of Helge Klein - Power Tools for IT Pros.

What would Joe, a Citrix admin, put on his Christmas wish list? Here are some guesses in no special order.

XenApp

• A version of XenApp that runs on Windows Server 2008 R2
• One console only, at least for XenApp
• PowerShell SDK for managing XenApp
• Realtime audio/video so that, for example, Microsoft Office Communication Server can be used well
• Migration tool that exports an old farm’s settings and imports them after optional transformation into a new farm

Support for XenApp in SCCM (Microsoft System Center Configuration Manager)

• XenApp collections
• Add application hosting information to SCCM package
• Autonomic server load management to allow SCCM software distribution

VM Hosted Apps

• Session sharing (multiple applications per session/VM)
• Real application publishing

XenClient

• Release a first version, if only for enterprise volume laptops initially
• Make it run on any system that supports VT-D and TXT (trusted execution technology)
• Provide a private image mode: copy a VM to a client initially and then sync back differentially by creating snapshots that are stored on a server. A user would “own” a VM in this scenario and could store data and install applications in it, but updates/application installs could not be easily centrally managed.
• Provide a shared image mode: copy a VM to a client initially that is reset to its original state when powering off. Provide a second disk (VHD file) for persistent user data. In this scenario, users could not install applications, since the OS VHD gets reset constantly, but administrators could manage updates to the OS VHD centrally by distributing snapshots containing new applications or patches to the clients. All user data would have to be stored on a second partition.
• Optionally encrypt VHD files on the client (we are talking about laptops)
• Map the GPU to any VM. That way we could use a private VM (with GPU, for games, etc.) and a more secure business VM.
• Run applications from one VM seamlessly in the other VM (over ICA)

XenDesktop

• Make HDX media stream for Flash optionally work in such a way that we do not need internet access in the client’s site. Stream Flash through ICA from the server to the client and only render it on the client.
• PowerShell SDK for managing all aspects for XenDesktop

Image Management for Provisioning Server

• Give us a tool for automating the management/patching of PVS images
• Make it run in one of three modes:
• • Monitoring: Monitor external ESD server to determine if updates have been assigned to a machine
  • Scheduled: Periodically start the VM and allow the machine to update itself
  • Manual: Admin initiates VM start/stop for manually updating
• Give the tool a PowerShell SDK so we can program it

Various

• Release Branch Repeater as a virtual appliance. Better make it available for all three important hypervisors.
• Release a virtual appliance version of Access Gateway that can serve as a true replacement for CSG (Secure Gateway). For that, it needs to be free or very cheap at least. And better make it available for all three important hypervisors.

The post Citrix Products 2010: A Wish List is original content of Helge Klein - Power Tools for IT Pros.

The script published in this article was kindly contributed by Bo Riis, a sysadmin working at Danish hosting company dandomain. Here is what he writes about it:

Recently I had some issues with MS Office getting really slow on some of our customers’ terminal servers. After some intensive debugging we came to the conclusion that when users disconnected a session they left behind their open printer ports. It seems like that these ports don’t get cleaned up after a while, like the session they belong to. These ghost ports linger and use more and more resources in the print spooler and Office does not react well to a busy print spooler. One of our servers had more than 3000 of these orphaned ports. [Whoa!]

After searching a little we found one reference to this problem on Brian Madden’s forum. From the scripts there I compiled a script that works on Windows XP and up.

We now have this running on almost 200 TS and the users have given positive feedback on performance gains. Depending on how well or bad behaved they were in logging off in the first place.

Bo runs this script weekly on their terminal servers under the system account. There are two versions which are identical except for the logging capabilities.

Download

CleanupOrphanedPrinterPorts.zip
CleanupOrphanedPrintersWithLogfile.zip

The post Script Deletes Orphaned Printer Ports is original content of Helge Klein - Power Tools for IT Pros.

I just returned from Citrix’ bi-annual Synergy event in Barcelona. I am not going to summarize the event here (others have done that better than I could, e.g. Gabe Knuth or Nico Lüdemann). Instead I have a few pictures to share. I would like to mention, though, that Synergy is the best way to connect with the many great people in the Citrix “universe”, along with E2EVC.

The venue, CCIB:

People enjoying the sun after a session:

Working and connecting, everywhere (in the background CTP Pierre Marmignon and Jim Moyle):

The first two days I spend in the CTP meeting, getting updated and discussing with Citrites:

In this picture (from front to back): Jason Conger, Wilco van Bragt, Timco Hazelaar, Rick Delinger, Ruben Spruijt, Pierre Marmignon, Thomas Krampe, Rick Rohne, Alaa Jallad, Nico Lüdemann, Thomas Kötzing, Chris Rogers, Benny Tritsch and Denis Gundarev:

The famous Secret Demo Room (whose existence is not so secret, or they would not have put such a big sign on the door):

The expo hall:

Conference flair:

The Geek Speak Live track which had by far the best sessions:

And my personal highlight:

Thanks to everybody who helped make this event what it was – and till next time!

The post Pictures from an Exhibition is original content of Helge Klein - Power Tools for IT Pros.

This is a very personal recommendation of what to read to become and stay an expert in Citrix XenApp.

Learning the Basics

Terminal Services for Microsoft Windows Server 2003, Advanced Technical Design Guide
Brian Madden and Ron Oglesby
Available online free of charge

By far the best resource to learn about Terminal Services. This should be the first thing you read. Even though the cover is ugly and “Windows Server 2003″ sounds dated, the book definitely is not – most concepts still apply and you won’t find better explanations of the key concepts anywhere.

The second thing to read could be Carl Webster’s 7-part series Learning the Basics of Citrix XenApp 5 for Windows Server 2003 which introduces you to the world of Citrix.

Up until XenApp 5 Citrix published comprehensive Administrator’s Guides, PDF manuals one could read from beginning to end and claim to have a solid understanding of the product afterwards. Beginning with XenApp 6 the Admin Guides have been replaced with eDocs, a smorgasbord of pages with information on all kinds of topics, good for looking up specific information, but impossible to use as learning material.

Farm Administration and Design

Articles explaining how to architect, size and maintain XenApp farms:

• Rick Dehlinger and Roddy Rodstein: Citrix XenApp Reference Design
• Wilco van Bragt: Basic principles of designing XenApp environments (part 1 and part 2)
• Citrix: XenApp Planning Guide – Virtualization Best Practices
• Citrix: Introduction to Storage Technologies
• Citrix: XenApp 6.5 Enterprise Scalable XenApp Deployments
• Citrix: Technical Guide for Upgrading/Migrating to XenApp 6.5
• Brian Madden: Terminal Server and Citrix MetaFrame Server Sizing Techniques

Independent Blogs

Blogs with content relevant to XenApp in no particular order:

• Original blogs on brianmadden.com
• Carl Webster’s blog
• Simon Bramfitt’s blog
• Jason Conger’s blog
• Thomas Kötzing’s blog
• Nicholas Dille’s blog
• Citrix Things!
• XenAppBlog
• Andrew Morgan’s blog
• Archy.net by Stéphane Thirion
• Neil Spellings’ blog
• Kees Baggerman’s blog My Virtual Vision

(Mostly) Tools

Sites with free admin tools:

• CitrixTools.net
• Ctrl-Alt-Del IT Consultancy

Syndicated News

Sites that aggregate news from around the web:

• Syndicated Industry Blogs from around the Web at brianmadden.com
• Virtualization and Cloud Computing News at dabcc.com
• Ervik.as (Alex also writes original articles)
• Wilco van Bragt (Wilco also writes articles and reviews)

Company Blogs

Official vendor blogs:

• Microsoft Remote Desktop Services Team Blog
• The Citrix Blog

How to Get on This List

• I only considered content relevant to Citrix XenApp
• Blogs were considered only if still maintained and updated regularly
• Only English content was considered

If you have content that matches these criteria let me know by commenting below.

The post XenApp Reading List is original content of Helge Klein - Power Tools for IT Pros.

Shadow keys have been around forever, since way before Terminal Services were renamed to Remote Desktop Services (does anybody use that name?). It seemed they would stay in the OS forever, too. Yet, when installing applications on Server 2008 R2 many people notice that the shadow key area does not get populated. Let us find out why that is the case and if shadow keys still work in Server 2008 R2.

Background

A quick refresher what I am talking about: badly written applications create the registry settings they need to run at install time and only for the user currently logged on. Two capital sins Microsoft tried to work around by creating shadow keys. The main idea is that writes to HKCU during setup are captured and replayed for every user logging on individually.

Terminal Servers operate in two modes: install and execute. In the wild old days one had to manually switch to install mode (using the command change user /install) before every installation, but for a long time the operating system has been clever enough to do that on its own reliably enough.

If install mode is enabled for a session, any changes to HKEY_CURRENT_USER are mirrored to the shadow key areas HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software (64-bit processes) and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software (32-bit processes).

In execute mode during logon, timestamps are compared to determine if application settings stored in HKLM need to be copied to HKCU. This happens for every application key individually.

To sum this up, shadow keys are a mechanism to distribute initial application configuration values to all users on a Terminal Server.

Experiment

In order to find out if the shadow key functionality is still present in Server 2008 R2 I executed the following commands:

1. change user /install
2. reg add HKCU\Software\Test /v test /d “test”
3. change user /execute

This adds a registry key “Test” with a value of “test” in install mode. I checked the shadow key areas mentioned above for the Test key and found – nothing. Looks like shadow keys are gone, right?

Then I tried something else:

1. change user /install
2. tcmd757a.exe
3. change user /execute

This runs the installer for Total Commander. The installer creates the key HKEY_CURRENT_USER\Software\Ghisler. I checked the shadow key areas for the Ghisler key and found – an exact copy of the key in HKCU. Apparently shadow keys are still functional.

But why did my first experiment fail?

TSAWARE

With the help of my new free tool IsTSAwareApp I found that reg.exe has the flag TSAWARE (i.e. a special bit in the header of the executable is enabled). This means that the developer of reg.exe says it is aware of terminal services. The installer for Total Commander, on the other hand, does not have the TSAWARE flag.

The conclusion is that shadow keys are enabled only if an executable is not marked as Terminal Services aware. To prove my conclusion I used the Visual C++ tool editbin to remove the TSAWARE flag from reg.exe – and, bingo, I could use the modified reg.exe to create shadow keys during install mode.

The reason why the shadow key areas in the registry are often empty today: most modern applications have the TSAWARE flag which tells the operating system they work correctly on Terminal Servers without crutches like shadow keys.

Windows 8

Is the shadow key functionality still present in Windows 8? I have bad news for some of you: nothing was changed. Shadow keys work the same way in Windows 8 (Beta) as in Server 2008 R2.

Further Reading

Brian Madden: How Applications use the Registry in Terminal Server Environments (Part 2 of 3)
Nicholas Dille’s three articles about shadow keys

The post Do Shadow Keys Still Work in Server 2008 R2? is original content of Helge Klein - Power Tools for IT Pros.

Udamin.exe is a handy tool for managing Citrix user/device licenses.

To get a list of currently issued licenses run it like this:

C:\Program Files\Citrix\Licensing\LS>udadmin.exe -list
Usage data is 15 minutes old. Next update in 1 minutes.
 
Users:
username1 XDT_PLT_UD 2013.0815
username2 XDT_PLT_UD 2013.0815
 
Devices:
computername1 XDT_PLT_UD 2013.0815
computername2 XDT_PLT_UD 2013.0815

You can delete individual license assignments like this:

udadmin -f FEATURE [-device | -user] NAME -delete

Unfortunately there is no built-in command that deletes all issued licenses. A one-liner batch script adds that missing functionality for device…

for /f "tokens=1,2" %i in ('udadmin -list ^| find /i "_ud"') do @udadmin -f %j -device %i -delete

…and user licenses:

for /f "tokens=1,2" %i in ('udadmin -list ^| find /i "_ud"') do @udadmin -f %j -user %i -delete

If you have both types of licenses, just run both commands one after the other.

The post Batch Delete Issued Citrix User/Device Licenses with Udadmin is original content of Helge Klein - Power Tools for IT Pros.

Know this problem? You try to start a XenDesktop session, Desktop Viewer opens … and closes. Then nothing.

When you look at the machine in Desktop Studio you find that everything looks good: it is registered with the DDC and it is not in maintenance mode. However, you find an event with the following properties in the application event log:

Source:        Citrix ICA Service
Event ID:      1260
Type:          Warning
Description:   ICA connection is cancelled because auto-logon is enforced and auto-logon failed.
               For more information, see 
               http://support.citrix.com/proddocs/topic/online-plugin-121-windows/ica-sson-enable.html.

Hugh?

Clicking the URL given in the event does not help much:

Solution

As always, the solution is simple – once you know what it is: the user right allow log on locally was missing. This can be configured through Group Policy here: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

By default the following users & groups are granted the right to log on locally on Windows 7 and 8:

• Guest
• Administrators
• Users
• Backup Operators

The post XenDesktop Logon Failure: Desktop Viewer Pops up and Closes is original content of Helge Klein - Power Tools for IT Pros.

This article is part of a mini-series. You can find the other articles here.

One of the first things you need to do after starting a XenApp farm upgrade project is to answer the obvious question from management: how much will it cost? In order to be able to answer, you need to have a good understanding of the resources required. In other words, you need to size the farm.

Sizing = Gut Feeling + Caution?

The process of sizing a XenApp farm in many cases is more a mixture of gut feeling and caution than solid engineering.

Gut feeling

I know my way around our current farm, so of course I am qualified to say how many of today’s 6 core CPUs we need as a replacement for yesterday’s 2 core models!

Caution

I’ll add some more servers, just to be on the safe side.

The result of such an approach to sizing very often is overcapacity in some areas and resource shortage in others. Your brand-new farm might sport 1 physical CPU core per user but lack enough RAM to host all those applications users tend to start.

Without proper sizing you are likely to spend more money than necessary, and spend part of it on things you do not need instead of investing it where it really improves performance.

In this series of articles I will explain how to investigate an existing XenApp farm, determine its load and calculate the capacity of a future farm from that data.

Methodology

We will start by dividing a farm into components that can be analyzed individually. The four system components most relevant to the performance of a XenApp farm are: CPU, memory, storage and network. For each of these components we need the total capacity as well as the load. When we have that information we can derive sensible values for the future farm easily.

As an example, let us assume we have a farm consisting of 10 servers. Each server has the following hardware configuration: 2 CPUs with 4 cores each, 4 GB RAM, 2 15K hard drives as RAID-1, 1 Gigabit network connection. The total net capacity is as follows:

• CPU: 80 cores
• Memory: 26 GB
• Storage: 1,500 IOPS
• Network: 1 GB/s

If the farm is regularly used by 100 concurrent users we get the following per-user capacity:

• CPU: 0.8 cores / user
• Memory: 266 MB / user
• Storage: 15 IOPS / user
• Network: 10 MB/s / user

After performing measurements we know that the typical maximum load is as follows:

• CPU: 10%
• Memory: 90%
• Storage: 50%
• Network: 1%

Looking at those load values it is obvious that we have overcapacities especially with network and CPU, and that memory is scarce. It seems sensible to set the following factors for the new farm:

• CPU: 0.25
• Memory: 2
• Storage: 1
• Network: 0.1

With those factors established, we can calculate the capacity of the new farm. In our example, it needs to be sized for 200 concurrent users because the company is growing. Here are all numbers in one table:

Great, But Where to Get That Data?

This was just a simple example to whet your appetite. In the course of this series I will show you exactly how to get all the relevant data for sizing your next XenApp farm.

Read on!

The post XenApp and RDS Sizing Part 1 – Methodology is original content of Helge Klein - Power Tools for IT Pros.

This article is part of a mini-series. You can find the other articles here.

As we have seen in part 1 of this series, when sizing a new farm the first thing we need to know is the capacity of the existing farm. Armed with data on capacity and additionally load, we can easily calculate the capacity of a new farm. In this article I describe how to determine capacity of the four relevant hardware components of a XenApp server: CPU, memory, storage and network.

CPU Capacity

If you only have one CPU model, determining the total CPU capacity is simple: just add up the total number of cores. But what if you have different models? How do you add the performance of, say, a Xeon 7100 and a Xeon E5640? Simply adding Gigahertz values does not cut it; modern CPUs are more efficient per Herz than older ones.

Normalization

You can add numbers from two different systems only after you normalize them, i.e. make them comparable. One method of making CPUs comparable is to run benchmarks. I did not want to do that, though. Way too cumbersome. There had to be a more elegant solution. And there is.

Moore’s law states that the number of transistors – and thus performance – doubles every 18-24 months. That gives us a simple way to calculate the relative performance of two processors. The only things we need to know are the CPUs’ release dates. Easy enough. But wait! How can Moore’s law be universally true? It is nothing more than one man’s prediction dating back to 1965!

It can easily be shown that Moore’s law is true, at least has been for the past 40 years:

Transistor Count and Moore’s Law – 2011 by Wgsimon under CC

As to the why: Reality conforming to Gordon Moore’s prediction would be entirely by chance if many of the important players in the semiconductor industry had not started to use his law to time their product releases, making Moore’s law a self-fulfilling prophecy.

Calculating with Gordon Moore

Adapted to our situation Moore’s law states:

CPU B is twice as fast as CPU A if B was released 18-24 months after A and both CPUs are from the same price segment.

As a formula, it looks like this:

In words: the performance of CPU B, released t months after CPU A, is equal to (e to the power of 0.033 times t) times the performance of CPU A.

Normalized CPU Cores

When applying above formula to a typical set of server CPUs we get the following table:

As you can see, we set the oldest CPU’s performance index per core to 1.0. Moore’s law gives us performance indices for other CPUs.

By calculating the performance index per CPU core we normalized CPU performance values. As a result, we can now directly add the (normalized) performance values of different CPU models. In our example, with 10 Xeon 7100 3.0 GHz, 16 Xeon 7100 3.4 GHz, 6 Xeon E5440, 8 Xeon X5550 and 6 Xeon 5640, the table looks like this:

Memory Capacity

Determining RAM capacity is easier than determining CPU capacity because we can simply add RAM values from different servers. Different speeds (DDR, DDR2, DDR3, etc.) do not matter in practice. However, there is one thing that makes this a little more interesting: we need the amount of free RAM. Only RAM that is available for user sessions is relevant for farm capacity. Calculate it like this:

with:

• RAM_installed: Physical RAM in the server
• RAM_invisible: Memory that cannot be accessed by the operating system
• RAM_OS: Memory used by the OS

Physical RAM installed in the server can be invisible to the OS for several reasons, technical as well as licensing. Especially on 32-bit platforms a relatively large part of the 4 GB address space is needed for device drivers to communicate with the hardware. The following table illustrates this for several generations of popular HP servers:

The amount of memory used by the OS should really be called memory used by the platform because it includes add-on software components like Citrix XenApp, antivirus, user environment management and so on. In short: everything that not directly belongs to a user session. Here are some values I compiled for Server 2003 and 2008 R2 (your mileage can – and will – vary):

File system cache is very important. If it gets too small performance goes down, response times go up.

Did you ever notice how much memory you wasted with yesterday’s 4 GB 32-bit servers? Out of the 3,5 GB that were actually usable, more than 25% was required by the OS alone. Less than 75% of all RAM could be used for its main purpose, hosting user sessions!

Continuing our example from above, we calculate total memory capacity for our 23 server farm as follows:

Storage Performance

I deliberately do not use the term capacity with storage lest people only think in terms of size. Much more relevant for multi-user systems with hundreds of concurrent processes each depending on mass storage is throughput – no, not how many bytes per second the storage system can read or write, but how many different IO operations it can process per second. IOPS is by far the most important storage metric in our field of work, and for that reason I used it to characterize a farm’s storage performance.

How do we determine the total number of IOPS an existing farm can process? Although we can simply add IOPS values from different hard drives we still need the numbers for each type of drive. Unfortunately measuring IOPS is not easy because the result greatly depends on how you measure (transfer request size, queue depth, random vs. sequential, read vs. write). Luckily we are bound to find traditional spinning disks in the servers of older farms (and probably also in most new farm servers) whose IOPS values depend mainly on rotational speed. Ballpark numbers that are good enough for our purpose can be found in Wikipedia:

With this data total IOPS calculation becomes dead simple. Continuing our example, we probably have 15 K disks even in older G4 servers, each equipped with 2 disks configured as RAID-1 mirrors. Since only one disk is active in a two-disk mirror we use only one disk per server in our calculation. With an average value per disk of 190 IOPS we get:

Total IOPS per farm = 23 * 190 = 4,370

Notice how small this number is compared to SSDs? Even a cheap consumer SSD easily outperforms those 23 active server hard disks by a factor of two – and that is in the more difficult discipline of writing data.

Network Capacity

For our purposes network capacity is equal to throughput in bytes per second. The XenApp servers in our example are equipped with one active gigabit network connection. Gigabit ethernet is capable of transferring roughly 100 MB/s.

Total network capacity: 23 * 100 MB/s = 2,25 GB/s

Being able to transfer 2,25 Gigabytes per second is pretty impressive and very probably this is much more than we need for XenApp.

Capacity per User

Server capacity values are certainly nice to have, but what we really need are values per user. Continuing with our example, our 23-server farm was designed for a maximum of 250 concurrent users. That is also the number of Citrix XenApp licenses the customer purchased. Farm capacity per user can be calculated by dividing total farm capacity by the user count:

Preview

In this article I have shown how to assess the computing power you have in your datacenter. The next article will be about determining how that hardware is used, in other words: determining the load.

The post XenApp and RDS Sizing Part 2 – Determining Farm Capacity is original content of Helge Klein - Power Tools for IT Pros.

This article is part of a mini-series. You can find the other articles here.

In the previous part of this series we saw how to determine the capacity of a server farm. This time we will look at how that capacitiy is utilized, in other words at farm load. As before we will do that for the four main components of a XenApp server separately: CPU, memory, storage and network.

Observation

Before spending lots of time with Perfmon you should try to get a feel for the farm. The easiest way to do that is by opening Task Manager on a few servers and taking a good look. Task Manager is probably a bit underestimated when it comes to monitoring a system, yet it can help answer many important questions:

• How many users per server?
• What is the utilization of CPU, memory, network?
• Are there individual processes with high CPU/memory usage?

After adding a few additional columns, Task Manager happily displays IO counts, too.

Having examined several systems like this, you should have a rough idea of the utilization of each of the four key system components (CPU, memory, storage and network). For example you might have come to the conclusion that the servers are memory-constrained, CPU load is rather low, disk IO is high mainly during logon hours and the NICS are heavily underused (that is a combination I have seen lately).

In the next step, we will verify the initial assessment with measurements.

Measurements

Perfmon is the way to go here. The most relevant counters for understanding system performance are listed below.

General System Activity

These are self-explanatory:

Terminal Services\Active Sessions
Terminal Services\Inactive Sessions
Terminal Services\Total Sessions

Hard Disk Activity

Measuring hard disk load is difficult, as there is no single number telling you what a disk is doing. To have all the data we might need later on we will measure overall utilization (% Disk Time), queue length (requests waiting to be processed, Avg. Disk Queue Length), IOPS (requests being processed, Disk Reads/sec and Disk Writes/sec) and latency (Avg. Disk sec/Transfer):

PhysicalDisk(_Total)\% Disk Time
PhysicalDisk(_Total)\Avg. Disk Queue Length
PhysicalDisk(_Total)\Disk Reads/sec
PhysicalDisk(_Total)\Disk Writes/sec
PhysicalDisk(_Total)\Avg. Disk sec/Transfer

CPU, Memory and Network Activity

Compared to storage, the activity of the other system components is simple to measure. We need but one counter per component:

Processor(_Total)\% Processor Time
Memory\Available MBytes
Network Interface(*)\Bytes Total/sec

However, there is one caveat: Windows does not tell us the amount of memory that is used (which is what we really want to know) but the amount of memory that is available. Calculation of consumed memory requires knowledge of the total amount of memory installed in a system. See the previous article for that.

Automation

Obviously nobody wants to log on to dozens of servers setting up eleven counters manually in Perfmon (Perfmon’s horrible UI does not exactly help this). Fortunately, nobody needs to as this can be automated easily. Create a text file containing the names of all servers you want to collect data on (one name per line) and save it as Servers.txt. Paste the names of the counters you want to include into another text file and save it as Counters.txt. Run the following command (line breaks for readability only):

for /f %i in (Servers.txt) do 
    logman create counter TSPerf -f csv -cf C:\PerfLogs\Counters.txt 
                                 -o C:\PerfLogs\%i.csv
                                 -si 60 -rf 24:00:00
                                 -s %i

This creates one data collector set on each server in the list, adds all the counters from Counters.txt to the set, sets the output format to CSV, the output file to Servername.csv, the sampling interval to 60 seconds and the total runtime (collection duration) to 24 hours.

Analysis

Once performance data from a typical work day is available, analyze two or three individual servers. Perform the analysis per component (CPU, memory, storage, network). For each component, create a chart that depicts total session count and the counter for the component.

CPU

A CPU chart could look like this:

The yellow graph represents CPU utilization in percent, the red graph the total number of sessions (multiplied by 10 to fit into the same scale). It is obvious that during the morning logon time as the session count increases, CPU utilization is noticeable, though not high. During the rest of the day CPU utilization is negligible. This machine is obviously not CPU-limited.

Repeat the single server analysis with another machine. If you feel that you understand the component’s load in the farm, verify your analysis by overlaying many servers’ graphs in a single chart like this:

This is very good evidence that the farm’s CPU load is light, rarely crossing the 40% threshold, often being below 20%.

Memory

Memory charts look like inverted CPU charts because Perfmon monitors available, not free RAM:

When analysing such a chart do not fall into the trap of thinking that there is lots of RAM available because the graph does not reach zero. If you want a snappy system (and happy users) you need several hundred megabytes for the file system cache. This server could do with a little more RAM, for example.

Again, verify your analysis by creating an overlay like this one:

[Above chart spans a longer time frame than the other charts - it includes the logoff time in the evening.]

Storage

Load

The average disk queue length is a good indicator for the load of a storage system:

The blue graph shows the disk queue length multiplied by 100. A queue length of 2 is considered full load for a single active disk. In a typical RAID-1 configuration, only one disk is active, so the value of 200 in the chart represents full load. As disk performance is critical for application responsiveness this server’s disks should be considered being under medium load.

As before, the overlay confirms the analysis.

IOPS

In addition to determining the load of the disk subsystem it is often necessary to have the number of IO operations per second (IOPS). We can use an overlay chart with disk reads and writes:

With the system in steady state (i.e. booted up), the number of writes (blue) is much higher than the number of reads (red). We want a good reaction time from the system, so we use peak values instead of averages. The combined peak read and write IOPS of this machine is at around 60.

Network

When looking at the network chart please note that a value of 200 corresponds to only 2 MB/s.

The average network utilization of this system is less than 200 KB/s – which is practically nothing. The overlay chart confirms that the same is true for all servers:

This is an extremely light load.

Summary

Now that we know each component’s capacity and load, we can go about calculating the size of the new farm. That is the topic of the next article.

The post XenApp and RDS Sizing Part 3 – Determining Farm Load is original content of Helge Klein - Power Tools for IT Pros.

This article is part of a mini-series. You can find the other articles here.

In the previous articles in this series we saw how to calculate a farm’s capacity and then how to determine its load. With that information and knowledge of our methodology we can go about calculating the capacity of the new farm, in other words doing the actual sizing. Which is dead simple, by the way.

Required Information

In order to calculate a new farm’s capacity based on usage data from an existing farm, we need to fill the fields of the following table:

Capacity Old Farm

We’ll start by entering the capacity numbers determined in part 2:

Scale Factor

Next we’ll take the load results determined in part 3 and set a scale factor. The scale factor governs how much more we need of a component per user in the new farm.

Additional Factors Influencing Load

At this point you need to consider additional changes between the old and new environment that are relevant to capacity, e.g.:

• higher RAM requirements because of the move to 64-bit software
• RAM requirements generally increasing with each new software generation
• CPU and RAM overhead incurred through virtualization technologies like App-V or Personal vDisk

Setting the Scale Factor

We now set the scale factor for the new environment:

With the scale factor known, the capacity calculation table looks like this:

Result: Capacity of the New Farm

Per User Capacity

By multiplying the old farm’s capacity values with the scale factor we get the new farm’s per user capacity:

Total Capacity

The number of users using the environment might be different between the old and the new farm. That is the reason why we broke the calculation down to per-user values. Now we only need to multiple the per-user capacity values with the new farm’s planned user count to get the total capacity. Assuming an increase in CCUs from 250 to 350 we get these values:

What to Buy

CPU

Before we can go and buy servers we need to convert the resulting normalized CPU cores to actual physical cores. Using Moore’s Law as discussed in part 2 we can calculate the performance index of a modern CPU like the Xeon E5-2670 CPUs as follows:

Difference between release dates of oldest CPU Xeon 7100 and Xeon E5-2670: 67 months

Performance index of Xeon E5-2670 = e ^ (0.033 * 67) * 2 = 18.26
(we multiply by 2 because we set the perf index of the oldest CPU to 2, not 1, so that its index per core would be 1)

Performance index of Xeon E5-2670 per core = 18.26 / 8 = 2.3

So each core in a modern Xeon CPU is roughly 2.3 times faster than its 2006 ancestor.

We need: 122.5 normalized cores = 53.3 Xeon E5-2670 cores = 6.7 Xeon E5-2670 CPUs = 3 or 4 dual processor servers

Memory

256 GB RAM in 3-4 servers is not much by today’s standards. I would go for something in the area of 128 GB per system.

Storage

The storage subsystem must be able to constantly deliver nearly 10,000 IOPS. That is quite a lot. It can be achieved either by connecting the machines to a SAN (expensive) or by going for local SSDs. Another option would be 12-16 local 15K drives in a RAID-10 configuration supplemented by an IO optimization tool like Atlantis Ilio.

Network

The NICs must be capable of transferring 322 MB/s. That is roughly the capacity of 3 Gigabit NICs. Since we need 3-4 servers anyway, we already have got those 3 NICs.

Conclusion – and Spreadsheet

I hope you liked this series. To help with the calculations I have created a spreadsheet: Helge Klein – Farm sizing.xlsx.

Have fun sizing!

The post XenApp and RDS Sizing Part 4 – Calculating the New Farm’s Capacity is original content of Helge Klein - Power Tools for IT Pros.

Even if you only have a moderately sized VDI deployment chances are high you will face the problem of getting USB smart card readers to work on the virtual desktops. Given that this is such a basic requirement it is astonishingly hard to implement correctly. To save you the pain of having to start from scratch here is my description of how to do it.

Basics

Smart card readers are USB devices, so the only thing you have to do is plug them into the thin or fat client sitting on your desk and Citrix XenDesktop auto-magically makes them appear in your virtual desktop, right? Wrong. We are going to get to that magic, but we have got a bit of configuring to do first. To auto-map smart card readers like the Reiner SCT or Omnikey devices into virtual desktops we need:

1. USB redirection must be allowed
2. A redirection rule for the device type smart card via Citrix policies
3. A redirection rule for the device type smart card on the end user device
4. The USB redirection module must be enabled on the end user device (applies to some Linux thin clients)
5. Smart card hooks may have to be removed on the virtual desktop
6. The Windows Smart Card service needs to be started

The following chapters elaborate on these points.

Allow USB Device Redirection

Configure a Citrix user policy to allow USB device redirection by setting ICA -> USB Devices -> Client USB device redirection to allowed.

Smart Card Redirection Rule in Citrix Policies

Add a redirection rule for smart cards to the Citrix policy setting ICA -> USB Devices -> Client USB device redirection rules:

Allow: Class=0b # smart cards

Make sure there is no deny rule overriding it.

Smart Card Redirection Rule on the End User Device

Funnily, some people seem to think that smart card readers are typically used on the end user’s device, not the virtual desktop. While this just might be true for fat clients it is downright ridiculous for thin clients. When I connect a smart card reader to a thin client I most definitely want to use it in the remote session, not on the device itself.

However, the thinking that the endpoint comes first has led to the situation that the ICA client also has redirection rules. In contrast to the rules in the Citrix policy the endpoint’s rules are even preconfigured, and in such a way that redirection of smart card readers is disabled. Obviously, we need to get rid of this.

Thin Clients with Linux ICA Client (Citrix Receiver)

USB redirection rules are stored in the file usb.conf which is located in the directory /setup/ica on Fujitsu eLux thin clients. The default content of usb.conf includes the line:

DENY: class=0b # Smartcard

Either delete that line or comment it out by putting a hash (#) in front of DENY.

Windows ICA Client (Citrix Receiver)

On a Windows machine USB redirection rules are stored in the registry value HKLM\Software\Citrix\ICA Client\GenericUSB\DeviceRules. The format of that multiline string is identical to the file usb.conf on Linux. As described above locate the entry that denies smart card redirection and either delete it or comment it out.

Enable USB Redirection Module (Linux Thin Clients)

Some Linux thin clients have a modular ICA client. Thus it is possible that the component for accessing XenApp and XenDesktop is installed, but the HDX Plug-n-Play module is missing. In case of eLux make sure to install HDX Plug-n-Play USB 2.0.

Optionally Remove Smart Card Hooks

If you have followed the steps above you have done everything that is required to get smart card readers working in your virtual desktops – theoretically. In practice it can happen that the readers do not work reliably. In that case Citrix’s smart card hooks may interfere with the redirection. This can be resolved by deleting the hooks. To do that delete the following registry keys on the virtual desktop:

• HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Smart Card Hook [32-bit and 64-bit systems]
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Smart Card Hook [64-bit systems]

Windows Smart Card Service

Make sure the Windows Smart Card service is started on the virtual desktops or all of the above will have no effect.

Tested Platforms and Devices

I have tested this configuration with Citrix XenDesktop 5.6. The virtual desktops were running Windows 7 x64 with the XenDesktop VDA 5.6.200. Smart card readers tested were Reiner SCT cyberJack e-com and Omnikey CardMan 3121.

More Information

CTX132716: Case Study: Preventing or Allowing Mapping of Specific USB Devices to Virtual Desktops
CTX129558: How to Redirect USB Devices in XenDesktop

The post Getting USB Smart Card Readers to Work with Citrix XenDesktop is original content of Helge Klein - Tools for IT Pros.

When you buy a new HP server it comes with the BIOS setting HP Power Profile set to Balanced Power and Performance. That sounds good but is bad – at least for CPU performance in a VDI environment.

When we prepared our servers for use as virtualization hosts for Citrix XenDesktop we took great care to configure the HP Power Profile for Maximum Performance:

That fixed the problems with really awful CPU performance we had in the beginning. But still – some VMs were performing worse than others. When I looked at the problem I soon found a VM with bad CPU performance. I ran some benchmarks, comparing it to a “good” VM:

Test setup:
CPU: Xeon E5-2670 2.6 GHz
Hypervisor: VMware ESXi 5.0 Update 1
VM OS: Windows 7 64 Bit
VM configuration: 2 vCPUs

Depending on the benchmark, the “good” VM is between 28% and 244% faster than the “bad” VM. That is a lot!

I suspected the power profile setting of the server hosting the “bad” VM to be wrong, but how to check without rebooting the server and accessing the BIOS? These are production systems and we cannot use vMotion to move the VMs off the server because the VMs are on local storage. Luckily the power profile setting is not only available from the BIOS, but from the iLO console, too. It can even be changed from iLO, taking effect immediately:

Sure enough, the “bad” VM was on a server with incorrectly configured power profile. Switching it to HP Static High Performance Mode fixed the issue. Strangely, the settings are named differently in BIOS and iLO.

If you want to know more about power profiles and power regulator: HP has a whitepaper on the topic.

The post The Effects of HP’s Power Profile on vCPU Performance is original content of Helge Klein - Tools for IT Pros.

When you move users from a physical PC to a VDI environment you may find that they are not too happy with their new machine’s performance – it happened to me. To quantify things I took a series of measurements comparing the old PCs we migrated away from with both VDI machines and the new PCs available to some.

Test Procedure

There is no objective CPU benchmark. Depending on the tool you run you will get widely differing results. For that reason I used four very different benchmarking tools. I chose these four for no other reasons than that they were readily available and different in nature:

• NovaBench 3.0.4 CPU test: Synthetic benchmark tool.
• CineBench 11.5 CPU: 3D rendering tool turned into a benchmark.
• SunSpider 1.0 in IE8: Measures JavaScript performance.
• Super Pi Mod 1.8 WP 1M: Calculates Pi.

Some tools are multi-threaded and take advantage of more than one CPU core while others do not. That is just like in reality. Single-thread performance is still extremely important today, which is why Intel enabled their CPUs to optionally run only one thread at a high speed instead of multiple threads at normal speed (“Turbo Boost”).

All measurements were run twice. The result shown below is the average.

HyperThreading was enabled where available.

The virtualization hosts running the VDI machines were oversubscribed in terms of virtual to physical CPU allocation. The system with the Xeon E5-2670 had an oversubscription ratio of 4:1, the system with the Xeon X5690 had 6:1.

The virtualization hosts’ power profile was set to maximum performance. At the default setting (“balanced”) CPU performance is noticeably worse.

The virtualization hosts were running VMware ESXi 5.0.

Test Results

Analysis

We can learn several interesting things from these tests. These conclusions are, of course, only applicable to similar scenarios, so things may be different for you:

VDI vs. old PC: A VDI machine running on Intel’s newest server CPU is not that much faster than a physical PC with a 5.5 year old CPU.

VDI vs. new PC: Even a laptop CPU outperforms the Xeon in nearly all tests. Given that desktop PC CPUs are faster than laptop CPUs it is safe to assume that a VDI machine does not stand a chance against a PC.

Single-thread performance on VDI: As the SunSpider and Super Pi tests show, single-thread performance on a VDI machine is not great.

Xeon Westmere vs. Sandy Bridge: Probably due to its much higher clock speed the older Westmere-EP CPU performs better in most tests than the newer Sandy Bridge-EP CPU (the fastest Sandy Bridge-EP, the E5-2690, might be on par or even better, though).

Closing Thoughts

When moving power users (aka knowledge workers) from a PC to a VDI machine CPU performance is a topic that needs as much attention as IO performance. In your project, do not rely on benchmarks alone – those are always synthetic and may or may not match what you see in reality – but have real humans test the applications they use in the way they use them. I have seen “harmless” Excel sheets turn out to be massive CPU hogs running for hours or even days. Differences in performance were noticed immediately by the users.

The post Comparing the CPU Performance of Physical and Virtual PCs (VDI) is original content of Helge Klein - Tools for IT Pros.

The post How-to: XenApp/RDS Sizing and Capacity Planning with uberAgent for Splunk is original content of Helge Klein - Tools for IT Pros.

I just had a situation where I was facing an empty desktop with no way to logoff, start a program or do anything else. The only thing left to do was to log the session off from an admin session. This got me thinking: how many ways are there to create such a situation? I am writing down all the ways I know of and ask everybody to contribute. Can you come up with a way to end up with a completely empty desktop I and no one else thought of before?

This is what I am talking about:

My Solutions

Explorer Killed

If you kill Explorer and have no other graphical application running, you are left with a blank screen.

Please note that if the shell is not stopped manually but crashes instead, it is restarted by default. This is governed by the registry value AutoRestartShell.

Custom Shell Closed

You can specify a custom shell through the Group Policy setting Custom User Interface. Such a shell is run on top of the default background – and can be closed by pressing ALT+F4 or by clicking the red cross in the application’s upper right corner (if available). After closing the custom shell application all that remains is the background.

Nice Try, But Does Not Work

Configuring an Invalid Custom Shell

This is tempting, but the developers at Microsoft are not stupid enough to fall for this one: specifying a custom shell through group policy that does not exist; in other words, specifying something like kasjdfljskdf. If you do that, the regular shell (Explorer.exe, of course) will come up.

The post Contest: Why Is This Desktop Empty? is original content of Helge Klein - Tools for IT Pros.