Putting a PC on a Diet

Where I work, we have a fairly large VMWare View deployment, primarily for publicly facing devices such as library patron kiosks, digital signage, and computing labs; we mostly use Zero Clients for the front end.  I found that we were deploying more and more View desktops and didn’t have enough Zero Clients to fill the need, so we turned to looking for a temporary solution.  I scoured the web looking for options, I figured, “Why reinvent the wheel?”  There is some nice software out there on the market to turn a physical pc into a thin client, but I really didn’t want to spend any more money when I was going to replace them with Zero Clients eventually, so I looked at thinning down desktops that were already in place.  With a virtual desktop, one of our biggest challenges of deployment was with user acceptance.  To have a user grasp the concept that their desktop really isn’t physically in front of them and is in a datacenter across town wasn’t on my agenda, so this setup helps bridge that gap.  The end user still sees the PC that they have been accustomed to, its big, bulky, hot, loud, and when they turn it on, it works with expected results but this case much faster.

I found a great blog post on the web that offered up a great solution to our project.  By utilizing Windows 7 ThinPC, which we had available to use through our Software Assurance Agreement, and some scripting, coupled with some secret sauce, this project moved forward very quickly.  I felt that to make the experience for our end users more what they are used to, I needed to tweek the view command line scripts that were initially provide.  By design of the author, the end user was required to manually connect with the client, a step I feared my end users would balk at.  It’s change; change is bad for productivity and the help desk unless implemented properly, anything we can do ease the blow.  I had two difference scenarios where I would need to have two different launch scripts.  The first, a shared computer lab where the view clients were provisioned to multiple pools, the second a pure Kiosk that could be entitled to a floating or dedicated pool based on the specific need.

Scenario 1 – Computing Lab with multiple View Pools entitled:

“C:\Program Files\VMware\VMware View\Client\bin\wswc.exe” -desktopLayout fullscreen -desktopProtocol PCOIP -connectUSBonStartup True -connectUSBOnInsert True -domain YOURDOMAIN -username YOURUSERNAME -password YOURPASSWORD -serverURL YOURCONNECTIONSERVERFQDN

The user that you define in the in the command will need to be entitled to the pools in your Admin Portal, if you assign the user to multiple pools, you will get the following expected result:

The user need only to choose the desktop they wish to use, if they hit exit or log out of a desktop, it comes right back to this screen.  I found that if you didn’t include all of the options for name, password, and domain, that it would not auto-connect to the View Connection Server, requiring extra input from the end user.

 Scenario 2 – Kiosk with a single View Pool entitled:

“C:\Program Files\VMware\VMware View\Client\bin\wswc.exe” -unattend -serverURL YOURCONNECTIONSERVERFQDN

 By changing the launchview script to have the above command, you can utilize VMWare View’s Kiosk Mode, which in my mind is an under utilized feature.  In a previous post I outlined a script that I threw together that helped facilitate the creation of Kiosk Accounts on a View Connection Server; don’t forget to prepare your systems first.  You will need to entitle the account that is created with the scripts to a single pool to which the device has access to.   We have a few different situations in which floating or dedicated pools are being used in conjunction with disabling SSO to achieve the desired result.  Here are a few examples:

  1. A computing lab or user workstation with a dedicated pool and SSO disabled
    This would allow you to have a one to one relationship with a physical device and View desktop
  2. A computing lab with a floating pool and SSO disabled
    This would allow you have a better transition time between log offs in a busy environment; coupled with a refresh on logoff, provide a clean desktop every time someone sits down to the workstation.
  3. A computing lab or public computer with a floating pool and SSO enabled
    If logins were not of concern, such as walkup kiosks that are always on, elementary school computer labs where students may not have a login this is a good choice.  The user that the desktop will login as is the kiosk user defined by the scripts, so plan accordingly for network security should you go this route.
  4. A digital sign with a dedicated or floating pool and SSO enabled.
    This would be a special use case where there wouldn’t be an end user sitting in front of the device, and it’s used to launch some soft of signage or powerpoint view on login of the View Desktop.

As you can see, putting a PC on a diet and thinning it down has it’s benefits, and I hope this provides some help should someone need to go down that route.

Posted in View, Vmware

Leave a Reply

Your email address will not be published. Required fields are marked *