Screen savers and virtual desktops

If a tree falls in the forest and no one’s around, does it make a sound? If a screen saver is running and no one is watching, does it matter? You can debate me on the first question, but the second one is a definite YES.

You remember long ago when fancy screen savers were all the rage? You remember the flying toasters right (if not either I’m too old or you are too young)? What about the fish swimming leisurely across your big (14 inch) CRT monitor? We don’t put as much thought into screen savers as we used to, but they are still there. Most of us simply use the default ones within Windows 7, that is, if we have one at all. But what does the screen saver have to do with virtual desktops? Actually, screen savers have a lot to do with desktop virtualization, especially in the hosted VM-based VDI model (at least if you are trying to optimize your environment).

First, the value of the screen saver is that it locks your desktop after so many minutes (assuming you configured it that way). In fact, many types of organizations have guidelines on how long the desktop can remain unlocked for fear of people seeing sensitive data like medical records, financial records, or even a cheesy poem you are writing to your significant other. Using a screen saver that does crazy things on your monitor is like watching videos constantly on your desktop. This not only consumes a massive amount of bandwidth but it also consumes valuable CPU resources. Remember, we are using virtualized desktops. We are sharing CPU resources with other users (check this out to see screen saver’s impact on CPU). We use network bandwidth to deliver screen updates to the end point. Seems a little crazy to do all of these things when chances are high no one is around to view them. So what’s the solution? Don’t use them. Well that is a little harsh, but try to do the following:

  • Within the virtual desktop, use an Active Directory group policy to
    • Enable the screen saver
    • Prevent changing the screen saver
    • Password protect the screen saver
    • Set Screen saver timeout
    • Force specific screen saver (Blank screen saver is “scrnsave.scr”)

No bandwidth and no CPU consumed. What if there is massive outrage from the users because they can’t configure their flying toasters anymore? How about doing the following

  • Use the end point device’s screen saver to give the user the fancy graphics but keep the virtual desktop as the blank screen saver. User is happy, the network is happy, the CPU is happy. Everyone is happy (well, maybe not those toasters) J

Honestly, if there is this much hysteria around the screen saver, people might have too much time on their hands. In the end, disabling the fancy screen savers is a huge savings you don’t want to miss out on. Remember though, that even if you enable the user password to come out of the screen saver, if the user still has an active connection to Web Interface on their end point, anyone can simply click on the desktop icon and be logged back in. So make sure your Web Interface timeouts are in line with your screen saver timeouts.

Now, time to watch my toasters fly.

Daniel – Lead Architect

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.