Skip navigation
1 2 Previous Next

Gunnar's Blog

23 posts

Step 1:

Add this to the system path:

C:\Program Files\Vmware\Vmware View\Server\jre\bin





Don't try and make the CSR yourself, just go to this site and have one auto created:


That should return a keytool command like this:

keytool -genkey -alias server -keyalg RSA -keysize 2048 -keystore star_gunnarberger_com.jks -dname "CN=*,OU=Information Technology,, L=Athens, ST=Georgia, C=US" && keytool -certreq -alias server -file star_gunnarberger_com.csr -keystore star_gunnarberger_com.jks && echo Your certificate signing request is in star_gunnarberger_com.csr.  Your keystore file is star_gunnarberger_com.jks. Thanks for using the DigiCert keytool CSR helper.


NOTE: The keytool command I used above was for a wildcard cert so it was *, had I wanted the tool would have been different (I just wanted to explain why my example has a astrick in it).


After you execute this command you will have to type in a password for this file 3 or 4 times.  For simplicity just keep the password the same throughout.


The command you just issued is going to give you a CSR file and a JKS (Java Keystore).  I put both of these files into a directory on the root of my hard drive. C:\cert



Step 3:


You'll need to go to your CA of your choice and upload the CSR.  I used because its cheap and I'm cheap.


All CAs have different steps you have to take before they will generate a cert.  The more expensive the cert, the longer it takes (becuase it means that did more to make sure you are you.)  With RapidSSL, it took about 15 minutes, so they probably aren't the best CA in the world.  Eventually they will email you a link to download your cert which you will need to make sure and download this in PKCS7 format or (.p7s).


Now I you should have a file called <filename>.p7s


I go right ahead and drop that file to the same C:\cert directory


Inside the C:\cert directory you should now have three files






Step 4:

Now that you have all three of these you need to execute the following command


    keytool -import -alias server -trustcacerts -file <filename>.p7s -keystore <filename>.jks


Here is a screen shot of me executing this command.


If you don't get "Certificate reply was installed in keystore" I don't know what to tell you, call someone. 


Step 5:

Finally, we need to get the View Connection Server to actually use the cert we just added to TomCat.  Thankfully this is pretty easy.

Copy the <filename>.jks file into the following directory:


C:\Program Files\Vmware\VMware View\Server\sslgateway\conf\


Step 6:

While you are in that directory use notepad to create a new file that is called

Inside that file put the following (again using notepad)


keyfile=<name of keyfile>


Step 7:

Restart the VMware View Connection Server Service


It takes a few minutes for this to come back, even after the service says it is up.  It always takes just enough time for me to freak out and think I broke something.  So to ease my mind I learned to just look at the log file, so go ahead and open the following directory:

Inside that directory you will find a log file called, log-<DATE>.txt look for todays date.  Open that file and go to the very bottom.  Also, you can just search for "SSL" that tends to bring you to the line you are lookig for.
11:41:00,292 INFO  <Thread-1> [m] The Secure Gateway Server is using SSL certificate store <filename>.jks with password of 8 characters
NOTE: If you don't see your jks file but instead see vdm.p12, then it didn't work, this is the default certificate.  I had this happen on a couple servers and I ended up just rebooting the server and after the reboot it worked... no idea why, its Windows what more can I say.

Additional Server:

So you have more than one server to do, well good news, all you have to do is take the file and the <filename>.jks file and copy them to the new server.  Start at Step 5 above and work your way down.  You can repeat this over and over, if you use a wildcard cert at least, or if you are sharing a name like in your cert and just want to have that on each server.  Just make sure your DNS is setup correctly and you should be good.


This post is nothing special, but for some reason this information isn't documented anywhere except if you do a wswc /? once you have the View Client installed.  I personally like to run the View Client as a ThinApp (that way its portable) so it was annoying that this information wasn't out there in a document.  So here it is all the flags that are exposed for the VMware View Client for Windows:


VMware View Client 5.0.0 build-481677 command line usage:
-desktopName XXXDesktop to autostart
-domainName XXXDomain for server login
-file XXXFile with additional command line parameters
-languageId XXXLCID of language to use (if available), e.g. 0x409 for English
-nonInteractiveSuppress error message boxes for fully scripted startup
-password XXXPassword for server login
-smartCardPIN XXXPIN for smart card login
-desktopProtocol XXXAttempt to use the specified desktop display protocol
-desktopLayout XXXSpecify desktop screen size (e.g. fullscreen, multimonitor, windowLarge, or windowSmall)
-serverURL XXXURL for the View Connection Server
-logInAsCurrentUser XXXLog in as current user (true or false)
-userName XXXUser name for server login
-unattendedStart in unattended mode. Connects to the entitled desktop without user interaction
-connectUSBOnStartup XXXConnect all USB devices to a desktop when it is launched (true or false)
-connectUSBOnInsert XXXConnect a USB device to the foreground desktop when the device is plugged in (true or false)
-printEnvironmentInfoPrint information about the system
-rollbackRolls back a check out (need -desktopName)
-confirmRollbackConfirm rollback operation in non-interactive mode
-?Show this help
-standaloneThis is a hidden flag but what it does is it allows you to run multiple View Clients simultaneously
Option names are case insensitive.


So if I wanted to setup kiosk mode I'd juse the username, passwordk, URL, and desktop flag.  I'd probably throw in unattended to just to keep in clean.


Gunnar Berger

gunnarb Expert

PCoIP Log View 2.0 Released!

Posted by gunnarb Dec 20, 2011

Thought everyone here would like to know that an internal VMware tool has just been released publicly.  This tool is extremly helpful in working in PCoIP based View environments.  I've used it numerous times and have posted responses to forums and blogs using the tool.  I haven't been at liberty to discuss the tool in much detail in the past as it wasn't a public tool, however now it is and I encourage all of you to check it out.


Basically, this tool will give you both real time information on a running View session and it'll take previous session logs and put them into a nice graphical format so you can easily see how a VM performed over a period of time.


I use this tool on every single engagment I work on.  Often its that tool in the toolbox that brings the wow factor to my clients as it opens their eyes to what is going on in the background.  I'm excited and sad that the tool is released, excited becuase now everyone can see this thing, sad because I will look a lot less cool now. 


I do plan on shooting some videos of how to use the tool in the near future.


Gunnar Berger

So last week I asked for a favor from Teradici and Imprivata; I wanted to actually use a proximity card on a PCoIP Zero Client and see how difficult it was to setup and see how quick it actually worked.  They were both very open to this request and rushed me a couple proximity card readers and a card.  Thankfully I already have quite a few Samsung Zero Clients (from previous demos) to test them on, so here goes:


Imprivata Onesign:

The setup and install of OneSign couldn't have been easier.  One of the options is to download it as a Virtual Appliance which makes installation a snap.  In fact the download took longer than any other step in this process (it was 7GB).  Once you have the appliance, which comes as an OVF, you just import it, setup an IP address and away you go.  From that point on you go through a web interface to configure the rest.  My contact at Imprivata supplied me with a quick guide in configuring OneSign for use with a Zero Client.  Basically, I just had to connect the appliance to my AD, import the usernames I wanted, setup a policy (IE these people are allowed to authenticate with a prox card), and then I choose to set it up to automatically add Zero Clients as it sees them.  Very simple!


Zero Client Configuration:

I use the Teradici Management Console to manage my VMs.  I've done plenty of blogs on the MC and I won't make this blog about the MC.  However I will state that I had to do zero configuration on the client itself.  I just went into the MC changed the profile so that my clients where now setup to talk to the OneSign server instead of my View Connection Server (this is a setting as of Firmware 3.5 and MC 1.7), and within a few minutes my Zero Clients were auto-configured to talk to OneSign.


VM Configuration:

The final peice to this puzzle is the OneSign Agent, which needs to be installed in the VM itself.  Now in my lab I'm just using full VMs, not linked clones, so I would be interested to test this in production somewhere to see how it works when you provision VMs out with the OneSign Agent in the master VM.  I'm not sure if that's how it's designed to work or not (Imprivata if you are reading please feel free to comment below).  I'm sure in the next month or two I'll have an opportunity to test this.  In any case, I had to install the agent, which you do by going to the OneSign Virtual Appliance, then rebooting the VM.  That's it for the VM.


And done...

After I had all of the above configured, which took me all of 30 minutes, I was able to authenticate using a proximity card.  What I really liked is that the login process seemed identical (or slightly faster) than a typical log in.  I was suprised because for this to work it talks to the OneSign server before the VCS, but as you will see in the video below it works suprisingly quick.




Gunnar Berger

This is probably going to be the biggest single firmware release this year from Teradici.  I sware every time Teradici releases a major rev they do something else awesome that was previously "impossible" on a Zero Client.  Well Firmware 3.5 is going to blow your freakin' mind.


USB 2.0

I have to go straight to the big guy.  USB2.0.  That's right 2.0.  As a very strong Zero Client advocate do you know how much crap I've taken with the stinkin' USB 2.0 issue.  Never mind that hardly any devices use the throughput of 2.0, or even if you had that kind of throughput what it would do on the back end.  After all, that USB traffic is going through PCoIP, and PCoIP is compressed/decompressed inside a VM, and this VM is running on an ESX host with a hundred other VMs, and that ESX host probably only has a 2G backplane, AND that backplane would be maxed out by just four USB 2.0 running at full speed... Nevermind all of that!!! USB 2.0 is why I take a bunch of crap.  No more!


The wizards at Teradici in firmware 3.5 have through a simple firmware update made USB 2.0 possible.  How is that possible?  Because the physical interfaces have always been 2.0!  The code just hadn't been written to run it at those speeds, and honestly why would you!  If your users need 480mbs speed on USB I don't think they should be doing VDI... but I digress.


The real reason USB 2.0 is a good thing, and why giving me crap about my support for Zero Clients only running USB 1.1 is that transfers are slow... 8M is about the top speed and that's if the wind is blowing in all the right directions.  The fact is devices that have USB 2.0 transfer faster, often 2x as fast, sometimes more.  So that does put a hurtin' on those who love Zero Clients (yours truely) and the need for speed (also yours truely).  Well, early testing of firmware 3.5 and USB 2.0 show a 3x improvement in bulk transfer rates.  This means less waiting for something to copy to a USB drive, and something I think more people will care about... USB burners.  Yea, they work a hell-of-a-lot better in firmware 3.5.  Dare I say "supported"?


So ya, USB 2.0... it's kinda a big deal.


Imprivata SSO

It makes me sad that a year after I wrote a work around to get Imprivata to work on a Zero Client, Teradici has replaced me... with a fully supported Firmware that supports Imprivata OneSign.  If you work at a hospital this is going to be pretty big news for you.  Thin Clients can be problematic with HIPAA security requirements, after all there is an OS there so the potential for information being stored/stolen is a constant concern.  I know from personal experience (see my blog) that Zero Clients are the way to go in these types of highly secure environments, no OS, no way to keylog anything.  The one major hurtle has been to get proximity card readers to work on a Zero Client.  Sure you could have used my work around but it wasn't a real solution, you lost follow me desktop with my solution, but that is no longer the case.  Now you get all the functionality you need and no work arounds required.  I hope to see a lot more Zero Clients in a lot more health institutions in the near future.



I'm seeing this more and more, if you don't know what 802.1x is you may know what RADIUS is or Cisco NAC, Microsoft NAP.  Basically you can't plug anything into my network unless you are an authenticated user.  It's fitting that 802.1x showed up at the same time Imprivata SSO showed up, after all a lot of hospitals need this too.  Hospitals, Financial Institutions, Government... yea, many places have been waiting on this feature, well now its here.



Really?  This is one of those things that I know some people want but everytime I hear it I just think "really".  Why not just NAT your IPv6 traffic and keep your internal traffic IPv4, its not like there is some huge push for IPv6 anytime in the near future, but hey, I know people ask for this, now you have it... sure we could have had USB 2.0 sooner but someone had to give you (government institutions) IPv6. 


Helpdesk Support

More on this later I have yet to fully test it.  Basically with this firmware you can apparently give a zero client access to a helpdesk VM... interesting but I have to see for myself what this means and how I can abuse it.


I'm sure there are other bug fixes, and smaller things going on, probably another change in the log file format that I'll have to pick up on! (Yea thats for my friends at Teradici)   But honestly, this list is pretty freakin' impressive and I would like to say thank you to all at Teradici who have worked so hard on this release, its a big one.


Oh and BTW, if you have issues with Firmware 3.5 go to its free and is the best place to go for any zero client issue.



I just saw this on Teradici's site, thought it worth mentioning:

** NOTE If you use the PCoIP Management Console, upgrade to PCoIP Management Console release 1.7.0 prior to upgrading to Firmware 3.5.0 **


Gunnar Berger

I do my best to let people know how to contact me if they have issues with VMware View.  I like to learn as much as I can and getting my hands on as many deployments as I can keeps me sharp.  Well last week someone from across the globe reached out to me on a "PCoIP" issue they were having.  Naturally the first thing I asked was for them to send me their pcoip_server logs so I could review them.  After getting these logs and parsing them it only took a few seconds to discover the source of the problem.  Here is a graphical representation of those log files and some explanations of what we are seeing.


Bandwidth Limits


I look at a lot of these charts and I can tell just by looking at that chart that something isn't right.  A typical clean session looks like this:


In this session we see that I have a 7M limit (most likely because that is set via GP or its an AES hard limit).  The session is running sub 1000k with some spikes in TX over 1000k.  BTW, this is my actual session I am using right now as I write this blog, so my home lab is pretty clean.  When the limit isn't a straight line, be it 7M or 20M or whatever you limited PCoIP to, then this points to a problem with bandwidth.  If the limit decreases its because as PCoIP attempted to use that amount of traffic, it wasn't able to so the limit was decreased.  I've seen some very nasty logs where the limit constantly increases and decreases, the more muddy the network the more you'll see this.  However, in a typical LAN a log should look like what I show directly above.  The first log obviously has issues.  What I can interpet from this log is that there is something going on in the network and that whatever is going on in the session is using a lot of bandwidth.  This is in line with what the customer was telling me (they were attempting to test an HD video).


Packet Loss


Packet Loss is the single most important statistic I'm going to look at in any log.  In the log above we see not just a lot of packet loss (I consider anything 2% and above to be a lot), we see a lot of sustained packet loss.  Let's compare this to my LAN.


That's where we all should be, zero packet loss.  So as you can see this customer has a lot of packet loss, I don't know why yet, and I don't know why it seems so consistent.  My next question to the customer was wether this connection was running over a wireless access point.  That is the only thing that would make sense to me as to why this kind of packet loss would occur over a LAN.  The response that I got was that this was over a typical LAN, gigabit from the server to the client.  Obviously something is wrong here this shouldn't be possible.  Everything in the logs is pointing to a network issue, but based on the simplistic network this person has in place I couldn't believe that the network would actually be the issue.




Here we see network latency staying sub 5ms and spiking to 30ms.  Now its way below any latency I would normally worry about so the amount of latency isn't a concern, its the consistency of the latency.  After seeing this I asked the customer (again) if it was on a WAN (WAN latency is bound to be inconsistent), the answer was that this session was running over a LAN, so the fact that we see spikes on a LAN is a concern.  Most LANs will have a very consistent latency, again lets look at my network.


Now that may be a little hard to read but what you are seeing is that on my network I have very consistent latency, it is anywhere between 0 and 2ms.  This is very good as I don't have any spikes out of that range.



So as you see above everything appears to be a network issue.  I'm a PCoIP specialist so naturally the question comes to me as to what is going on in the protocol that would create this kind of issue.  The network is very simple, we are plugged directly into a Cisco 6500 switch (extremely common), there are no other reported errors on the network so "why is PCoIP so bad"!


Well, we are missing something very important in all of the logs I'm looking at, we aren't looking at the Infrastructure layer at all.  9 times out of 10 when I'm working on any performance issue, there is something going on in one of two areas, the SAN or the VM itself (antivirus being the biggest PITA).  In this case the customer started looking at errors on their iSCSI SAN.  Low and behold there were a multitude of alerts on the SAN.  Once those alerts where addressed the performance on the View Desktop went to what you would expect, HD video played perfectly, Windows was responsive, View was everything it was cracked up to me.


So there you have it, a lot of information on how you troubleshoot network and PCoIP issues only to find out it had nothing to do with either one.  This is a typical day in the life of a EUC Consultant.


-Gunnar Berger

I was brought into an engagement recently to showcase VMWare View 5.0 in a Citrix environment.  I was in charge of the View side of this bake off, so I do not have the specs on the Citrix side, all I know is that Citrix set it up (or so I was told).  The concept behind this bake off was to compare these products running over an iPad2 tablet.  The customer needs video to run through these devices and have an acceptable performance.  The reason this is not VMware View vs Citrix XenDesktop is due to the sales guys on the Citrix side just pushing XA and not pushing XD.  I completely respect this as VDI is not always the answer, sometimes just sending an application is enough, and VDI has a higher TCO than standard Terminal Services.  (And before that ticks someone off I'll also state that VDI can do 10x more than standard TS too!).


In any case, here is a side by side video showing the performance differences.  Its very rough as I was onsite and not at my home lab with my HD camera in it.


As you'll see in the video, PCoIP out performed ICA in this setup.  I believe this is due to the Citrix Receiver as in all other tests the Citrix video ran much better, only running it on a tablet did I see this drop in performance.


My next step is to repeat this test in my lab, but this time with XD5.5 and XA6.5.


Gunnar Berger

EUC Consultant


I had a pretty popular series of blogs entitled "How to deploy 120  Samsung Zero Clients without really trying?"  That blog is years old and frankly nothing in technology remains the same for very long.  In fact today, if I were to deploy those same 120 clients I'd do is completely different.  With the newest Teradici Management Console version 1.5.30 you can now completely deploy your Zero Client environment and never actually touch them.  This new feature is called Auto Config, and believe me, you SHOULD learn this.  It'll save you time, lots of it.

Before we begin!

I want to point out that all Zero Clients automatically look for a DNS SRV record in the form of pcoip-tool, this SRV record points to the pcoip-mc A record DNS entry.  Everything I say from hear on out assumes you are already using DNS SRV for having your devices automatically show up in your MC.  If you aren't doing this, DO IT!  Its a best practice for one, secondly what are you doing?  Manually discoverying?  Setting the DNS SRV takes about a minute and you'll never need to do a manual discovery again.  Get moving!

What is AutoConfig?

AutoConfig is a new feature in the MC found under Groups - Manage AutoConfig:



Inside this area you basically have three fields to choose from, I'll start from the back:


IP Range: Here you set the IP range of the Zero Clients.  Basically if the MC picks up a new ZC and if that ZC is in this range, we are going to automatically add it to this group.


Device Password: So we've chosen the range of IPs, now we need to type in what the passwords are for these Zero Clients.  Meaning most manufactures set a default password, in my case I was using a Wyse P20 so the default password is "Administrator".


Group: Finally, we need to set the group that these devices, in this range, with this password are going to connect to.


Now make sure you check "Enable AutoConfig"


That's it, when your devices are discovered you'll notice they get automatically added to the group you specificed.  To watch this process happen, click on "View AutoConfig Status"  I had to shoot the video I'm about to share twice because I forgot to set the default password.  Using this area showed me why it didn't work the first time around.


Setup the Group:

There is nothing new to review on the Group settings, basically a group ties to a profile.  So long as your Group is joined to a profile then AutoConfig will automatically apply the profile to the Device.  This could mean the device has to reset, take a look at your profile settings in order to tell if a reset will be required.


Setup the Profile:

There are a lot of new features put in the latest MC, however the coolest one is the ability to have the profile force a firmware version.


With this rule in place I basically ensure that all Zero Clients that are a part of this profile get updated to the firmware version I choose.  This is very VERY cool.


All that is left is to setup all the other profile rules, most importantly, the correct View Connection Server, SSL, Verbose Logging, Auto-Launch if only one desktop, enable DHCP, DNS-SRV discovery, etc.


Truly Zero Zero Clients!

With those settings in place, you can now ship a boxed ZC to an end user and so long as they can plug a network jack, mouse, keyboard, and power cable in.  All the management steps take care of themselves.  You/The Administrator, never have to touch a ZC.  And honestly isn't that the point!



To see a video of this in action click the link below!


Gunnar Berger


"I've been saying it, I've been saying it for ten damn years!  Ain't I been saying it?"

-Crazy guy from Independance Day

I thought that quote was fitting after reading the recent news from google:

If you've been following Google, you've known that this was coming but I'm happy to report that Google has a computing model that removes Microsoft from the equation.  I'm a VDI guru, I love VDI, what I don't like is that no matter what we do to get a desktop to an end user its always a Microsoft desktop, and Microsoft loves to make our lives difficult with their various licensing models.  Plus, they make a ton of money on every deal but when is the last time you had a Microsoft SE come onsite to help you with your implementation?  I've been saying for a while now that as soon as Google gives us an OS, Microsoft will finally have something to worry about, based on this article, Microsoft should get worried.

I love this Google model, its perfect for removing 90% of the headache that businesses have to deal with in IT and in a lot of ways its exactly what us VDI gurus have been saying for years.  Put it in the cloud, remove the end user headache but do that in a way so the user doesn't notice.  This model would be very noticeable, so it's not perfect, but its a good start.


There are two throught running around my head about how this announcement could drive a major change in VDI.


Virtualization of GoogleOS:
If Google OS is really just a small OS that handles Chrome, which is driven by HTML5 what's to stop them from virtualizing the Google OS?  Even under the Google model you need x86 to power that 1080p video from YouTube, which is what the laptop is for.  Under View with a Zero Client, you don't, it runs from within the cloud.  I guess I'm talking too much like a Teradici guy (makes sense if you know me - wink), we like the Zero Client model, where there is no OS at the end workstation its just a chip with firmware and that chip is capable of doing this:


That's 60fps every pixel on the screen is changing every frame, extremely high end and all being done on a Teradici Chip.  My point is if VMWare has an OS like ChromeOS let's virtualize it.  Not Linux with no real company backing, or Apple who despises the word "open" and won't let VMWare virtualize the OS - even though you can, but a company like Google that understands cloud computing and has the strength to take Microsoft on.  I had a talk about this recently with some buddies of mine and the argument I got was that ChromeOS is already small so what's wrong with having a ChromeOS end point.  We'll to me that fits the Citrix model of "client side rendering" basically I don't like the idea that my end client needs to have a processor, I like everything happening within the cloud.  The Teradici Zero Client model keeps EVERYTHING in the cloud, where it should be.



HTML5 App Delivery

The next step is to get Windows Apps to virtualize within the HTML5 model (pageing ThinApp team).  That model would have you ThinApp your current  Windows based application for HTML5 delievery... a licensing nightmare, but also I would have concerns about a low end ChromeOS laptop capable of handling a higher end ThinApp.  The app is web driven but doesn't the browser compile and display the HTML5 content?  I'm told that it'll all run within the cloud but my response to this was that Flash apps can kill my local process, how would HTML5 apps be different?  I honestly don't know anything about programming so I'll conceed that I'm probably just wrong on this point.


Highend App Delivery:

The other thought in my head is that even if ThinApp can deliever apps as HTML5 I don't it would be able to do everything this way.  What about high end apps that no one would ever think about deliverying via HTML5.  For those I start thinking about ways to deliver a applciation via PCoIP into a HTML5 client.  Ericom has already create an RDP version of the View Client that runs within HTML5.  Say you could do the same thing with PCoIP.  (After All Citrix is already doing it.)  Now with that same low end laptop you might be able to remotely deliever content never considered before, all within HTML5.  I've been against remote app delievery, as I think ThinApp is the future of app delievery, but with this change in model of computing app delievery into HTML5 may actually make sense.


Regardless of my random thoughts, I have to say this... Microsoft your days are numbered.

NOTE: This is a temporary workaround solution to enable proximity card readers on PCoIP zero clients and not a fully tested or supported solution from Teradici.  In other words: Use at your own risk!!! 


Hi everyone,


The last time I posted I shared with everyone how to setup Location Based Printing on a Zero Client.  I did this by changing some very basic settings, it wasn't a perfect solution (it broke Smart Card auth if you did it) but it worked for a decent amount of companies out there.  Today I'm going to show you how with a few simple changes you can get a prox reader to work on a Zero Client.  As with the last post this isn't fully tested in production, and is bound to have some gotchas... specifically:

  • You won't be able to do "follow me desktop"
  • You won't be able to have the same pool of VMs be connected from a soft client and a Zero Client.  (That is until I figure out how to properly setup a softclient and Kiosk mode - feel free to give me comments below on how to do this.)
  • Some highly secure environments may not like my work around, however the level of security I do here is identical to any environment that has the standard Windows "thick" clients, aka a normal workstation.


Before we begin:

First off I want to fix any misdirection that this article may put out there.  Recently Teradici did a press release with Imprivata, with plans to support Imprivata OneSign in the near future.  See here:


What I'm about to show you ISN'T THIS.  Teradici is working to support prox readers at a firmware level which allows pre-session authentication, and cool little things like follow me desktop.  My work around does not support that, but I think it will work for a lot of environments out there that want prox support now, and don't mind how I made it work.  With that said, I give you prox readers.


Step 1: Break SSO

To allow prox readers (or any authentication device) to work on a Zero Client I have to get connected to a Windows desktop.  The reason for this is that currently a Zero Client does not support these devices on a firmware level (see press release above).  My thought was, if I can get to the desktop prior to domain authentication then I can support the prox reader at a driver level, after all we support USB devices right!  The tricky part (which wasn't very tricky) was figuring out how to get the Zero Client to connect to a desktop in a pool but not have it log in to the desktop.  Well, had I read the manual I would have found this answer out a long time ago.


     Admin Guide:

     Page: 143


Basically we just set a GP to disable SSO, its a little too easy.


Step 2: Disable Virtual Channels

Virtual Channels are used in Smart Card authentication.  Because prox cards are very similar to a smart card we need to disable virtual channels so the Zero Client doesn't get confused and try and use the prox reader as if it were a smart card.  To disable virtual channels use the pcoip.adm file found on you VCS server, it should be found under Program Files\VMWare\VMWare View\Server\extras\GroupPolicyFiles.  Apply that ADM to your Group Policy and set it up like so:



You have to enable the policy to disable the channels.


Step-by-Step for Step 1 and Step 2:

  • Create a GPO and add the ADM Templates.  These templates are found on your View Connection Server (VCS) here:
    • install_directory\VMware\VMware View\Server\extras\GroupPolicyFiles
      • vdm_agent.adm
      • pcoip.adm
  • With these two ADM templates added to the GPO you should now see two new folders under Classic Administrative Templates
    • Computer Configuration – Policies – Administrative Templates – Classic Administrative Templates - PCoIP Session Variables
    • Computer Configuration – Policies – Administrative Templates – Classic Administrative Templates – VMWare View Agent Configuration
  • Expand PCoIP Session Variables, then select Overridable Administrative Defaults, finally double click Configure PCoIP virtual channels.
    • Enable the policy
    • Check the box “Disable virtual channels in PCoIP sessions”
    • Click OK
  • Expand VMWare View Agent Configuration, then select Agent Configuration, finally double click AllowSingleSignon
    • Disable the policy
    • Click OK
  • Exit out of the GP Object editor.
  • Link the Policy to the OU of VMs you wish to test this on.


Step 3: Bridge the USB Device

Now we need to bridge the USB device (the prox reader) in the Web Interface on the Zero Client.  To do this you must be running the latest version of Teradici's firmware version 3.3.0 or higher (  We have to do this because as this is a authentication device the Zero Client is going to attempt to terminate the device locally, like it does with keyboards and mice (and smart cards).  We don't want this because locally the ZC doesn't work with prox readers (it will eventually - see press release above).  Since we don't want it terminated locally we want to bridge the connect so it terminates on the VM itself.  To do this, log into the ZC's Web Interface, go to Info - Attached Devices (see below)


Take notice of the VID and the PID of the prox reader, in my case it is 076B and 5124.  With that written down go to Permissions - USB (see below)



Click on Add New under Bridge Devices, then type in the VID and PID you just wrote down.  That's it; the device is bridged.


NOTE: I've received many requests that this bridging be added to the Management Console as no one wants to go from device to device to bridge a Prox Reader.  I believe this feature is going to be added to MC version 1.5 due out in a couple of months.  Also, you may find that not all devices need to be bridged, some may naturally bridge, that's great, I recommend bridging here just so no one misses a step (but I also wanted to state it may not be required, it just depends on the device you are using.)


Steps 4: Use Kiosk Mode or Auto Connect Mode to initiate the desktop connection.

The account that is used in the Zero Client should be secured.  You may have your own best practices however a method that I've tested follows:

  • Create a new user in Active Directory called testuser
  • Create a new group in Active Directory called DenyAll
  • Add testuser to DenyAll
  • Set DenyAll as the Primary Group
  • Delete Domain Users group from the testuser account

By doing this we have just created an account that does not even have the basic Domain User credentials on the network.  In this case the only thing the user has access to is a group called DenyAll, which at this point hasn’t been assigned to anything.  This setup should only give the user enough access to authenticate.  (Please note: this user will eventually need to be added to the Group that is entitled to use whatever pool you are doing your testing on.)


To setup the user go to the Web Interface of the ZC and click on Configuration - VMWare View (Advanced)... see below: (Firmware 3.3.0 and above required).  This can also be done via the Teradici Management Console if you so choose.




Step 5: Setup your Prox Software

That's really all you need from me.  After this its just a matter of installing the proper software and drivers on your VM.  I'm sure all products vary as far as how this works.  I tested with Imprivata's OneSign product, it was simple enough, one thing that I noticed is that it takes the VM about 3-5 seconds to recognise the prox reader when you first boot, this is becuase Windows is seeing the device and having to do its plug and play thing.  Where I've tested this it hasn't been an issue becuase it does it pretty quick.


Wrap Up:

So that's it... see my video below for a real life demo.

VMWare View 4.5 Design Best Practices

It recently came to my attention that the VMWare View Architecture Guide does not provide the best design for a fully redundant VMWare View 4.5 deployment. To counteract this lack of documentation I’ve decided to create a document on my own. I call it VMWare View 4.5 Design Best Practices. I don’t care how big or small your environment is, if you are looking into View you need to immediately consider this fact, you are moving all of your desktops (or a portion of them) into a cloud that you maintain. If you are doing this how happy are your users going to be when one service, one server, one switch, one… whatever, knocks out all of these users. In my opinion it is a serious failure to consider moving to any VDI solution unless you have a fully redundant back end. Hopefully this guide will give you the basic building blocks required to have this type of redundancy.


I’m not going to get fancy here, I’m designing a basic View Deployment that will cover 100-500 desktops. To accomplish this goal I’m going to need these components:


vSphere Clusters:

This is a licensing requirement. You are not allowed to run Server VMs on the View Premier license, and let’s face it, if you are building 100+ VMs, you bought the Premier License (if not call your VMWare Partner)


View Connection Servers:

The View Connection Server is the brokering service, they establish the connection to the View Agent.


vCenter Servers:

You’ll need to use vCenter Heartbeat, as it’s the only way I know how to make vCenter Servers redundant, be prepared to freak out a little bit, its expensive. VMWare Documentation doesn’t say that you need to make the vCenter server redundant, however, if you have a linked clone VM shutdown and if this service is not running the VM will not boot!


SQL Servers:

Why make this redundant? Well, my vCenter DB is on this, my Events DB is on this, my View Composer DB is on this. Basically every component of a View setup has a DB, so I want these DBs on a redundant back end, and yes if Composer can’t access the DB you have problems.


Security Servers:

However, I’d hold off on deploying any security server as a future Security Server will support PCoIP over the WAN, if you were at VMWorld you probably saw this.


Everything I listed above I virtualize, this way I take advantage of further redundancies built into ESX (HA/SRM).





The good news is that most of this is simple stuff, you can do an NLB or Round Robin for your VCS Servers, or Security Servers; it really is going to pertain to your environment and what you are trying to accomplish. In the end you should have two clusters that look something like this:





This should be my second to last blog on this setup.  We are currently 15% virtualized having deployed zero clients in three clinics.  Within the next 2 months that number will become 33% as we deploy the rest of the zero clients.  The reason this should be my second to last blog on this project is that I expect to blog once more when I hit 33%.



One of the major issues that had prevented me from deploying globally was that I was running View 4.5 in Beta since May.  My blogs are spread out because I'm most likely dealing with tech support to discuss an issue I was having in Beta.  Of course I couldn't talk about those issues, NDA and all, so I would skirt around them in my blog.  Now that 4.5 is released I'm free to talk and free to deploy.



A major advantage I see to this technology is its simplicity.  Between the PCoIPMC and the View Administrator I can teach the technology to my helpdesk staff with ease.  I'm even gearing up to teach non-IT staff how to use View Administrator.  My reasoning for this is that by using zero clients I have removed the ability to reboot the VM from the end user.  By teaching selected end users how to use the View Administrator I can give them back that ability.  I might blog on how that process goes.  With View 4.5 its pretty easy to grant a user the ability to reboot a desktop without allowing them to recompose it or delete it, so I don't see this as a potential security risk.



One thing that I'd like to start focusing on is redundancy in the design.  I only have one VCS server, I'm not sure if this is a great idea.  I'll have roughly a third of my network all needing this server to be up just to log in.  The other day Windows Updates jammed the server and I had to reboot it.  Luckily the service was still running so no one even noticed, however it did scare me.  Had an update killed the server I could have had a third of my network down.  This design seems pretty obvious to someone reading this but remember this thing is growing out of beta.  I need to sit down and redesign my network now that this is getting real.  Good thing that View Administrator guide is well written.



Outside of a network redesign, some printer issues, and the loss of the ability to reboot a VM, things are going great.  Its absolutely amazing how quickly these things can be deployed and how quickly I can deploy the VMs.  After this project is completed, I'm going to wrap my head around ThinApp.



gunnarb Expert

VMWare View 4.5 Released

Posted by gunnarb Sep 10, 2010

Its been a long road to 4.5 and quite a fun one.  I was lucky enough to be involved in the beta to this outstanding product and finally today I can finally talk about it.  To download View 4.5 go to this link:




The first thing most everyone will notice with 4.5 is a completely new Administrator interface.  This has been much improved from 4.0.  Some of the best things are being able to sort by all kinds of different information, in my environment I use the sort by Snapshot all the time as this allows me to see what Desktops are running on what version of my snapshots.  (We use multiple snapshots to manage our desktop image, v5 will be the next version that will include the offical 4.5 release Agent, if that gives us issues we will recompose to v4 which has the RC1 of View 4.5.  My least favorite thing: its still flash based so you can't access it from an iPhone/iPad.  I'm not apple nut but I would like to reset a desktop from my phone, Adobe and Apple just don't get along.




In my implementation of 4.0 I had a lot of issues with composing.  I can tell you first hand that composing works very well in this latest version.  I have not done linked clones on Windows 7 yet, I'm still waiting for Teradici to release their graphics offload card before I go to 7 on a large scale, however I've pushed it pretty hard on XP and have found that if I get an error its my fault.  This is a great improvement from all the weird ssd and other errors I would get on 4.0.




Some other features people will love are:




Offline desktop:  Not something I need here in a Health Care environment, but something I could see as VERY helpful in other environments.  As the name implies, this is basically taking a View Desktop with you, on a plane or whatever, talk about cool and probably the area that could affect the industry the most.

Kiosk Mode: This is a must have for the Health Care environment.  I have a bunch of zero clients booting without any user intervention, very cool.  It removes the change factor for my deployment as most of my users just see a new monitor and don't even realize the change, which is exactly what I want.

Windows 7 Support: Windows 7 works great virtualized, I've been running it for six months now, and I'm writting my blog (and every blog I've written for the past six months) on my virtualized Windows 7 box running off a Zero Client.  Oh and yes it supports dual screen without a hickup.

Smart Card support: It does that too, however don't get your hopes up for those of you (like me) that are running a zero client shop.  The only card I know that works with the zero client is the CAC card (google it).  Although you could probably install the smart card software within the VM, but that defeats the purpose if you ask me.  (If someone has experience with this please comment below - also if you know anything about running a prox card on a zero client).
Role Based Administration: This is outstanding for those of us who allow helpdesk to support the View clients.  Now I can have them access the View Administator and have limited access to just reset or recompose a desktop.
Location Based Printing: Who doesn't love the sound of that?  Make sure to download the View Administrator Guide and search for "Location-based", it should be under  Configuring Policies.  This basically uses Microsoft Group Policy to automatically attach network printers that are near the desktop being used.  Very cool.

In my opinion your biggest issues will always be USB issues.  This is the case with all remote access technology.  While XenDesktop and VMWare View have made leaps with this level of support they still have a lot of work to do on USB support.   I know there are some big things coming down the pipe with regard to USB so stay tuned to those.






It's been awhile since my last post,  I appoligize I've had a major bug that made my deployment come to a stand still.  I'm on Beta code so this isn't a shot against View, I'm on Beta, Beta is supposed to be buggy.    In any case I think I got my bugged worked out last night, only time will tell.



So far I have terminals deployed in two clinics.  It may sound crazy to you but I like to see how a beta runs in a real world situation, especially since I need things in my environment that 4.0 just doesn't have.  One thing I can't get over is how much I love recomposing. 


I have recomposed our VMs 5 times, if you're not familiar with that term, think of recomposing as reimaging your desktops.  I have roughly 30 terminals deployed which would be the equivilant of 30 desktops.  Think about how much work you'd have to do to image all of those desktops.  Well for me all i have to do is double click my pool. (These are my pools)


And then select View Composer - Recompose  


I'll be asked which snapshot I want to recompose from, then it starts to roll.  Its close to magic how this stuff works.  I spend the next 15 minutes twiddling my thumbs as my vCenter Server goes nuts completely rebuilding every desktop in inventory. 


Above is a screen shot of 5 desktops in our Urgent Care clinic.  I really like that I can see what Image they are currently running.  The way we administer our images is with version numbers.  As you can see above this is version 5 of the WINXP-BASE desktop. WINXP-BASE is a workstation that we make changes to then we snapshot it.  I can easily revert back to v4 should v5 not work correctly.  Most of my version changes are simple things, some of them are application upgrades.


One thing I LOVE is that last night I  needed to recompose all of my desktops to put in a bug fix.  Well, I told the job to run at 7PM, and believe it or not, I didn't even stay late to watch it run (that's how much I trust this product).  I got an email from a doctor at 7:30 saying that everything is running properly.  Think about that, I reimaged everything without being present without issue.  If that doesn't sell VMWare View I don't know what will.


I'm stuck at 25% completion on this project.  I'm heading to VMWorld so it'll be a while before I move beyond that.  Right now I'm having fun putting terminals in places I didn't expect to put them, instead of Exam Rooms I've been putting them in people's offices, I'm surprised how much they are liked.  In any case give me a few weeks before my next update.  Hopefully by then View 4.5 will be officially released and I can start talking about the nitty gritty.  It's a great product, I can't wait for everyone to be able to use it.



Sometimes looking at an old idea in a new way completely blows your mind.  I just had such an experience.


I have a Samsung NC240 in my office and have been using it to be the first adopter of the View technology, as my previous boss at eGroup ( used to say "We eat our own dog food".  I use View primarily becuase I'm in the process of forcing my entire work force into using a VDI solution and I want everyone to see that I make myself use it as well.  One of the features I like about this technology is that I can go to any terminal, log in as me, and get my desktop; basically I'm more mobile than ever before.  I've used this feature and others to sell the technology up stream.


Today I happened to be working with a series of Nurses down stairs as I was deploying their new terminals (Samsung NC190) when I realized I made a mistake and setup the View Pool as Dedicated instead of Floating.  I'm so used to setting up office workstations I forgot that in the majority of areas in the building the desktops are actually shared between employees.  I was in the process of Recomposing my pool when I started to ask myself why I was doing this. 


Why do I need to make these desktops floating instead of dedicated? 

Because more than one user logs into them.


Why do multiple users log into the same workstation?

There is only enough room to put one workstation at each location.


What are the draw backs to having one workstation with multiple users logging into them?

The most common problem is that when a user locks the workstation another user can't walk up and unlock it.  Another issue is that these users move around a lot, and Microsoft roaming profiles isn't exactly the best solution for a roaming employee.


I'll come back to my point, I was thinking this way because we've always done it this way.  But my answers to my questions above are moot now.  With VMWare View I can setup 5 for 50 desktops with minimal changes on the back end.  Physically it doesn't require any additional space and it isn't that big of a change for me from an administration stand point.


My way of thinking changed, instead of setting up two VMs for these two zero clients I was deploying I decided to deploy enough VMs to cover every employee.  Now when my employees are moving between areas all they have to do is hit the disconnect button on the Samsung terminal and log in with their credentials.  They get their own personal desktop, not a shared desktop.  This means their bookmarks, backgrounds, even applications stay the same regardless of where they sit down to do their work. 


To me this is the same as when I go downstairs and connect to my VM, to them its a completely different way to work and solves a lot of little issues.  I really feel that this little change is going to empower my workforce, there are some major productivity benefits from this setup as a user can stop what they are doing and pick it up exactly where they left off, no log off needed.   Plus it gives them a feeling of ownership which IT has never given them before.  I made some people smile today just by looking at something a little differently.