Skip to content

Posts from the ‘Tools’ Category


PCoIP Log Viewer Updated for View 5.2

First off, an apology.  This update took way too long to get into your hands, but here it is… In this post, I’ll explain the new update, and then likely dive into far more detail than anyone ever wanted to know about the new parsing framework included in this release.

Update for View 5.2

Goodbye standalone parser

With this release the PCoIP Log Viewer now supports parsing View 5.2 logs.  There’s a pretty major change in how this functionality is provided – View 5.2 log files should only be parsed directly from the Viewer.  Let me repeat that – the standalone parser will not work for 5.2 log files, you now parse these directly in the Viewer.  For any log files prior to View 5.2 you will still need to use the standalone parser. I realize this is likely to cause some confusion and frustration, but I had to make a break from the “legacy” parser if I was going to maintain my sanity. It also sets the stage for some future development I hope to do, and which I’ll talk more about later.  This also means, for the moment, if you depend upon embedding the parser into your VDI images to pre-process the log files before opening them in the Viewer (and I know some people have scripted this) that you are out of luck.  There’s two ways to look at this – I am the Dark Lord Satan out, specifically, to ruin your life, or, your scripting is now simplified in that you no longer need to pre-process the files or add an executable to the master image/clones. Keep the logic that moves the log files out, and then just open THOSE in the Log Viewer.  However, if I get enough hatred and anger, I am certainly open into looking at making a new standalone parser based off the new framework.  The catch with that is that it may require Java as a pre-req, or need to be wrapped into a much larger executable, so it’s not a perfect replacement.

Opening View 5.2 log files

With the log file parser now integrated into the Viewer itself, using the new View 5.2 support is as easy as dragging and dropping a “raw” logfile into the Viewer window, or opening the file via the Open Log file menu option.  Just to be clear by “raw” logfile, I mean the ‘pcoip_server_<year>_<month>_<day>_<id>.txt (pcoip_server_2013_05_17_00000b90.txt) file.  You can still open regular XML files from the standalone parser the same way you always have. Once opened things should look and work more or less as they always have, no new changes to learn there. Here’s a video of the basic usage (except you now CAN open files from the file dialog, and the parser warning is gone):

 Getting the Update

All you should need to do is launch the PCoIP Log Viewer while connected to the internet and it should auto-update. If you don’t have the Log Viewer installed already you’ll need Java 6.x or greater installed, then you can go here to get it: PCoIP Log Viewer Webstart


This was a big update, while it doesn’t look like it on the surface the underpinnings of the parser are a major update (as you’ll see below) so I expect there to be bugs.  Please let me know what you run into. If you can please include a link to the log file causing the issue.  Contact me here (via comments) or on twitter @rexremus and I’ll do my best to get things fixed up. I hope you enjoy this update and get some good use out of the tool.  If all you care about is the update – stop here, the rest of this post is going to dive into the details of the new parser and why I wanted to make this change.  If that doesn’t sound interesting, get out now while you still can!

New Parsing Framework

The Need for Modular and Extensible Parsing

The previous standalone parser rapidly grew into a mess. Why?  Because I had developed an unhealthy desire to have one singular parsing “engine” that could handle anything thrown at it.  There are several ways to do this, and the least desirable among them is really what the parser had become over the years – it was a singular parser instance with a ton of exception/quirk-checking to be able to deal with all variants of the PCoIP log files.

This is a trap that many of us fall into. You begin by writing what you expect will be a quick and dirty solution to a problem with no real thought of modularity, flexibility, or maintenance.  Then people actually start using it, so now you have a community to support.  A minor change needs to be made (like a small change to the content you are parsing) and you just lay it in, no need to refactor things for such a small change, right?  Well, one small thing becomes 12, and some of those end up being pretty significant changes that are made worse because of previous changes that required some really hacky workarounds.  And next thing you know, you are maintaining a complete mess.

This is where things were at in the standalone parser after the release of View 5.1.  That was a major update and required jumping through so many hoops in the existing code I had vowed (to myself anyway) I would not do it again.  If I had to change the parser again I was going to build it new, and take the lessons I learned from supporting the original version to make something easier to maintain going forward.  I’d given up all hope of the log files staying consistent at this point – and by consistent I don’t mean never adding new data, that’s always to be expected; by consistent, I mean not altering the way existing data is presented and/or ordered so that only new data was required to be dealt with on a new release.

So once I had the time to deal with an update to 5.2 (after hearing from many people that 5.2 logs were not working) I began working out a simple, I hope, to maintain parsing framework.

The New Framework

The basis of the new framework isn’t anything new or exotic, it’s just a few changes that should help make things much more flexible going forward.  At a really high level, I just decomposed the monolithic parser into a few component parts as shown below:

No magic here, ok, maybe a little

No magic here, ok, maybe a little

Here you can see a parsing component, a log file “model” component, and a formatting/output component.  The flow of running a document through here works mostly as it’s shown – the parsing component is responsible for converting the “raw” input into an intermediary container – the PCoIPLogFile object – which can then be fed into a formatting component that takes the intermediary container and “renders” it out to a new form.

All of these steps existed in the monolithic parser, but there was no easy way to extend or change any of the individual pieces.  Here, each component represents a unique entity and much better encapsulates the specific functionality it is responsible for.  Next we’ll break down some of the individual pieces and talk about how they are implemented

PCoIPLogParser Component

The log parser box in the high-level diagram really represents a base class which can then be extended to create version specific parser instances.


Parsers are built in a SAX-like fashion and can be built for new log formats much more easily

Parsers are built in a SAX-like fashion and can be built for new log formats much more easily

I decided to base the parsing side of the new framework around a SAX-like implementation.  If you are unfamiliar with SAX I will give a mangled, tremendously abbreviated breakdown of it here- SAX is used to parse XML documents and uses an event-based model.  Rather than trying to load the entire contents of an XML document into memory (that is DOM parsing), SAX defines a set of methods that will be called at various meaningful points as the document is parsed such as startDocument(), endDocument(), and startElement().  These allow you to take action within the context of the event, for example creating your intermediary object in the startDocument() method, and cleaning it up in the endDocument() method.  For extracting specific information from XML elements startElement() methods get passed information about the element that triggered the event which you can then examine and determine if it’s an element you care about.  SAX is great when you have to parse very large files as it’s much more memory efficient than a DOM parsing implementation, and it gives you flexibility in that you can extend existing classes that implement all required methods (far more than I covered here) and only override the ones you care about – which may be as simple as just implementing the startElement() method.

When creating the new parsing framework I decided to use an abstract base class so that I could provide a handful of methods that I don’t see changing very much, as well as house a few data structures and constants that I knew from prior experience would be used throughout the framework.  I could have (maybe should have?) gone with an interface here and then created a base parser class off of that and then have all “real” parser implementations extend that base class, but it seemed like a wash in the end as I was not sure the extra flexibility would be of significant benefit.  Building a parser for these log files is a non-trivial exercise, it’s not just 1-2 methods you might tack onto another class and quickly flesh out.  So in this case, I went with an abstract base class and handled as much core functionality as I could there.

Looking at a PCoIP log file we see that lines have a basic structure:

06/13/2013, 03:28:01.456> LVL:2 RC: 0 MGMT_SYS :UDP port values: base=4172, range=10, set=4172
06/13/2013, 03:28:01.456> LVL:2 RC: 0 COMMON :load_crypto_lib: FIPS mode enabled=0
06/13/2013, 03:28:01.488> LVL:2 RC: 0 MGMT_SSIG :(tera_xml_init) -- Software Build ID: soft_pcoip_rc_3_12
06/13/2013, 03:28:01.503> LVL:2 RC: 0 COMMON :Initializing Winsock2
06/13/2013, 03:28:01.519> LVL:2 RC: 0 SCNET :PCoIP Soft Crypto Module Build ID: trunk
06/13/2013, 03:28:01.846> LVL:2 RC: 0 MGMT_ENV :Setting ENV variable[ 7]: pcoip.tcp_port = 4172

If we break this down a little we see that every line starts with a timestamp, followed by a logging level, an RC code, a line “type” or category, and then the actual data or content of the line. I decided to model my SAX-like parsing around the line type element.  The base parser will run through the file and call specific methods for each line type encountered  (COMMON, MGMT_SSIG, SCNET, etc.) as well as methods for the file start and end.  Each of these methods are defined as abstract in the base parser class and must be implemented in any concrete classes.

I then created a default implementation of a parser (DefaultPCoIPLogParser) that is based around parsing a View 5.2 log file.  In this class I provide implementations of the methods for every line of “interest” in the log file needed to display it properly in the Log Viewer.  This base implementation can then be extended when the log file format changes again, and only the methods that deal with the lines (really, the line types) that changed will need to be updated.  This greatly simplifies dealing with new formats because there’s no need to worry about backwards compatibility as there was in the monolithic parser – you can do whatever hacky, ultra-version-specific  parsing tricks that make dealing with the current log file as easy as possible without any concern of breaking the parsing of a previous version and then let the existing methods of the parent class deal with everything else that didn’t change.  In fact, if the inherited method doesn’t blow up or cause any other “damage” to the data placed in the intermediary object, you can call it from your overridden method, and then come back and “correct” or populate only the data pieces affected by the new log format – this way you don’t need to copy/paste or otherwise replicate the existing parsing from the parent class and it saves you more time when creating the new parser version.

PCoIPLogFile Component

This is an intermediary object used to store the important data parsed from the log file.  It’s purpose it’s really just to be a bridge between the input and output of the parsing process – a parser generates a log file object, and a formatter uses it as input.

Simplified view of the contents of a log file object

Simplified view of the contents of a log file object

This isn’t to say the log file object is just a dumb container. It does contain a few methods, the most important of which is the validate() method.  Because of the move to a SAX-like parsing front-end it became harder to determine if a log file was “good” or “bad” from within the parser alone.  Certainly things like an individual line can be validated, but does one missing line, or one malformed entry mean the entire file is useless?  Probably not, but it might, it just depends on which line it is and possibly the context around it.  Rather than trying to put that kind of logic into what essentially amount to “stateless” methods within the parser (or going  through a lot of effort to give them state) it made a lot of sense to just encapsulate the notion of “validity” into the object storing the entire document state itself.  Once the parsing is done, the parsing workflow validates the log file object before passing it to a formatter.  If the file is invalid, an exception is thrown and can be dealt with.  This greatly simplifies error checking in that parser methods need only check for validity of a specific line (as that’s all the context they can be guaranteed to have) and the log file object itself can check for overall validity given that it can assume the point where the validate() method is being called, it should be considered a “complete” representation of a valid file.

PCoIPLogFileFormatter Component

Just as the parser box in the high-level diagram represented an extensible component, the same is true for the formatter box. In this case though, I did go with an Interface as there’s only a singular method to be implemented and it’s quite possible to just tack it onto an existing class if the formatting required is not terribly complex.  For more complex formatting it’s likely a dedicated class will be built which can then be sub-classed as required to tweak or change behavior.

A log file formatter has a very simple interface

A log file formatter has a very simple interface

As you can see there’s just one method – format() – that returns an InputStream containing the formatted output.  This allows the resulting formatted content to be pretty easily stored to a physical file, or to be piped around and read from in memory.  Java’s streams (and all their variants) are fairly rich and well understood at this point so this seemed a pretty low-level and flexible result to get out of the formatter.

For the sake of the current work, I’ve created an XML formatter to allow for the existing visualization chain to be used in the viewer.  But I can easily imagine an Excel based formatter to generate a physical file, or a JSON formatter to allow the parser/viewer to move to a cloud-based application and send data down to a browser or mobile device.  All of these should be fairly easy to implement.

Gluing it all together – The Factory

Well, saying “all” might be a bit of a lie, but I wanted an easy way to make sure you always get the “right” parser, despite there only being one that’s of any use right now. So I decided to build a ParserFactory to do that.

Basically, the Factory will scan the classpath looking for PCoIPLogParser implementations and then register them with itself to build a catalog of all available parsers.  Within the app, when we need to parse a file we can then call the cleverly named getParser(logFile) method.  This method examines the raw log file and extracts the “version” of the file based upon certain elements, it then queries every registered parser for it’s supported log file version.  When it finds a match, it returns that parser.  Currently there’s not much thought given to conflict resolution, e.g. what if more than one parser can handle a given version of file? But my thought on that is, within any given project, you probably wouldn’t need more than one way to “parse” a file – you might want more than one way to format it, but really you only care about getting it into the PCoIPLogFile object and then working with it from there.  So while  more than one parser capable of dealing with a View 5.2 log file might exist, it isn’t likely that you’d see them together in the same project where they might cause collisions.

This is a terrible diagram. You know it, I know it, let's just move on

This is a terrible diagram. You know it, I know it, let’s just move on

The horrible diagram above shows (poorly) the basic flow of parsing a file:

  1. Get the file
  2. Ask the ParserFactory for a parser, passing it that file
  3. The factory determines the version of the file
  4. The factory queries all the registered parsers for their ability to parse it
  5. A valid parser capable of parsing the file is returned from the factory
  6. The parse() method is invoked on the file and the PCoIPLogFile object is returned
  7. The PCoIPLogFile is validated (this is where you can bail out before trying to format)
  8. If the PCoIPLogFile object is valid, it is formatted
  9. The returned InputStream is used as required – written to disk or passed to another method/process for display or further manipulation.

I might also consider a factory for the formatter classes as well, something where you can pass in a desired format and get the right formatter back – or be informed no such formatter exists – and go from there.  But it seems rare outside of a web context (RESTful service) that any individual usage of this would require such flexibility so it wasn’t high on my list. For now, you know what format you need and can just go with that.  Anyway, I digress…

Wrapping it up

With the completion of this new parsing framework, parsing PCoIP log files going forward should now be easier to deal with.  Still frustrating, but easier.  At the very least, there is now a level of encapsulation and separation of duties that was missing from the organically “grown” monolithic parser that started it all.  The real test will be when the log viewer breaks again, as it inevitably will, and I am required to make the first updates.  That’s when I’ll know if this was worth doing.  But in my view, it’s fun to make updates like this.  Is my design perfect?  Hardly.  Are there probably a dozen libraries/frameworks I could have tapped to build this in?  Almost certainly.  But they often add a lot of baggage and “weight” and if you didn’t build your entire project against those frameworks it often means the benefits are limited or that you end up starting over.  Building this from scratch was satisfying on multiple levels.  It’s something I had wanted to do for a while, so I have the satisfaction of completing it.  It’s only as large and complex as it needs to be – which isn’t very much of either.  And lastly, it should allow me to support the users of this app better than I have been able to do in the past.

In the end, that’s all I really wanted.


PCoIP Configuration Utility Release – Version 1.0

At VMworld US 2012 in the EUC2620 session, I spoke about both the PCoIP Log Viewer, and PCoIP Configuration Utility. Unfortunately, the “cool” stuff in the PCoIP Configuration Utility that I showed in that session wasn’t publicly available.  Those features were/are being utilized inside a few select VMware customer environments to gather some feedback but I had not posted the code here at MindFlux – until now.

So, here it is! The new and improved PCoIP Configuration Utility.

I have decided to remove the beta moniker and call this code drop Version 1.0.  I consider this a decently “feature complete” drop of the code, but as with all software, it’s never done, and bugs almost certainly remain.  Unlike Google though, I feel compelled to take things out of beta after a reasonable amount of time :)

What’s new

You saw some of this in my previous sneak peek post but I’ll recap it all here. For the original feature list please review the initial launch posting here.


  • PCoIP Connection Health Monitoring (See screenshots)
    • Monitors various PCoIP connection stats and determines an overall health score
    • Health status can be easily determined via the systray icon with states ranging from “green” to “red”
    • A new health status popout that shows the metrics being tracked and their current health “scores”
  • Profile Tooltips
    • Hovering over a profile within the “Apply Profile” menu will now show a tooltip with the detailed settings for that profile


Profile Tooltips

Hovering over a profile now shows detailed information


  • PCoIP Server CPU Utilization
    • This should now be accurate, previously, as load increased this value would scale out of proportion to the actual load leading to inflated CPU utilization values


  • Session disconnect awareness
    • The utility now detects when there is not an active PCoIP session and when there is not, it enters a  ”sleep” mode that will consume less CPU than the active polling mode. Why burn CPU if there’s no user connected right?
    • Upon re-connection the utility will cleanly reset and resume stat collection in active polling mode. Previously, stats were not properly reset after a disconnection event causing some ugly numbers in the stats popout window.


Requirements, Issues, Implementation details, etc.

  • .NET 3.5 is required
  • VMware View 5.0 or 5.1
  • Tuning profiles and last used profile are stored in HKCU and in theory should be able to roam with a user to whatever desktop they happen to land on – if you have something setup to allow the profile to roam, that is.
  • The utility will request admin access – it needs this to be able to write to HKLM which is where the PCoIP settings are read from. You may need to get clever while launching it if you want to avoid UAC nagging you about it.
    • This seems to come up often in the comments and in other feedback, right now there’s not an easy fix for this. I have reached out to Teradici to get these settings moved under HKCU – we’ll have to see where that leads. This CAN be fixed but most options are kind of a “cure worse than the disease” solution that I’m not ready to move towards just yet.
  • GPO Conflicts
    • If you plan to use this tool to manage the tuning settings of a desktop you should avoid also setting tuning parameters via GPO on that desktop. GPO can still be used for things like clipboard sharing policy, or USB device policy, just avoid any of the settings controlled via a profile.



You can grab a copy of the utility here: PCoIPConfig.exe

Next Steps

There are a lot of existing enhancements left for the current tool. But the biggest issue still remains the required disconnect/reconnect. There are some potentially promising developments along that path though, so stay tuned. Please share your thoughts for enhancements and/or bugfixes in the comments.


PCoIP Log Viewer Updated for VMware View 5.1 GA

I have updated both the parser and the Log Viewer so that they should work with VMware View 5.1 GA log files.

To update the viewer simply launch it while connected to the internet and it should auto-update.

The updated parser can found here. It should report version 1.0.0134 when passed ‘-h’.

If you need to freshly install the viewer you can find it here.

One item of note – it seems that delta bits and delta build bits have been removed in this release so there will be no data reported for them in the graphs.

As always please report issues in the comments and PLEASE provide some feedback on my previous post: A note on View 5.1 Support for the PCoIP Log Viewer


A note on View 5.1 Support for the PCoIP Log Viewer

Some of you may know by now that the PCoIP log files are the bane of my existence. Since I began building the log viewer almost 2 years ago now, I have been in a constant battle to try and build a parser that can handle these ever-changing files. So far I’ve managed to make it happen with each release, thought not without much fighting, clawing, and gnashing of teeth.

Once again, with View 5.1 I find myself in a position of chasing a new file format that clearly was never intended to be machine parsed. Data is randomly placed, and formats and positioning data are altered from previous releases – seemingly for no good reason.  New data is mingled with old and some data has simply vanished entirely.

With the 4.x series of releases the changes were there but relatively minor from release to release. With the move to 5.x and the introduction of the APEX2800 card, the changes are much more significant. I assume this is because someone is making the assumption that if people want to monitor PCoIP they’ll use the WMI counters to do so and that the logs are irrelevant. However, it’s not always feasible to get direct access to be able to monitor via WMI and in some areas the logs do contain more information than the WMI counters have available. So it’s been a worthwhile struggle to keep updating the parser to get meaningful data out of the logs.

At this point though, the changes for both View 5.0 and 5.1 look to be quite significant. And updating the existing parser for these formats while retaining the old formats is becoming a significant challenge. I am thinking it might be time to reconsider the entire parser framework to make it more easily expandable and maintainable for future releases. This means, without question, a longer downtime before View 5.1 support will appear. It also quite possibly means the end of a standalone parser as my direction would be a cloud-based design and/or integration of the parser into the viewer directly.

I’d like to try and solicit some feedback on these new directions, so here’s a few questions, please respond in the comments:

  • Do you currently use, and see value in, the continued support of a standalone parser executable?
  • Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files)
  • If you  had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first?
  • Do you see the need for continued log file parsing support or is WMI support alone enough going forward?

I will determine the future course of Log Viewer development based upon your answers (or lack thereof).





Introducing the PCoIP Configuration Utility (beta)

Let’s get this out of the way – I’ll be the first to admit this tool needs a better name and I’m open to suggestions but for now let’s talk about what this tool does.

For quite some time internally I have been pushing for some way to dynamically adjust PCoIP tuning parameters while a session is still active. I have a host of ideas that this capability would allow for both admin and end-user, and I would be happy to build the tools to enable those ideas, if only the capability were there. But alas, currently the best we can do is tweak parameters across a session disconnect/reconnect.

“Wait a minute!”, you say, “I thought PCoIP AUTOMATICALLY adjusts session parameters already! Why do we need a tool to do this?”

Well, it does automatically adapt. But sometimes it can use a little help. There’s a reason vSphere exposes advanced parameters, or that sysctl exists on Linux – while both of those products do an excellent job of adapting to workloads in real-time, sometimes you can tune them to better fit a given workload in advance if you know what you’re doing. PCoIP is no different there. It actively measures network conditions and adapts within the envelope it’s given as defined by a handful of parameters. The “art” of tuning PCoIP is knowing how to control those parameters at a macro level and then letting PCoIP adapt itself within them at a micro level. So while the protocol does well on it’s own, we can help it out in certain circumstances when we’re already informed about the network conditions the VDI session is running on.

This need or desire to control PCoIP a bit better often shows itself in a use case where a user works on their VMware View desktop all day in their corporate office (on the LAN), and then they need to access that same desktop remotely (WAN). In this use case, it’s often desirable to reduce certain PCoIP settings when accessing the desktop via the WAN – which in turn reduces the overall “fidelity” of the desktop experience – but allow the settings to remain at their defaults (very high fidelity) when the desktop is accessed via the LAN.

And that’s the catch…

Currently VMware View only allows an either/or method of setting PCoIP parameters on a given desktop. You put the desktop in an OU, you assign the PCoIP GPO to that OU and then you tweak – if you want different settings, well, you create another pool in a different OU, assign the PCoIP GPO, and tweak (differently). Then you entitle the user to both (possibly identical) desktops, and hope that they choose the right one at the right time. Now, there are ways to mitigate this a bit, and I am making it sound as bad as it can possibly be but I’m just trying to prove a point – it’s not easy or pretty to support a use case that requires multiple PCoIP profiles for a given user on a given desktop in VMware View today.

So what can we do?

Well, we know we have to deal with a disconnect/reconnect, so let’s take that as a given. It’s not ideal (some might say it sucks – someone like me for example), but it’s what we’ve got. With that in mind, what we’re looking for here is a tool/utility that will allow us the ability to select a PCoIP profile easily and quickly from inside our desktop. Ideally it should also allow the editing and creation of new profiles so that if conditions should change – WAN could mean 3G, WiFi, W@H – a user has the ability to create an appropriate profile. Lastly, it should probably have some way to measure/show the performance of the connection as it behaves within a given profile.

It just so happens that the PCoIP Configuration Utility does just those things! Rejoice!


PCoIP Configuration Utility

This tool is intended to be dropped into a virtual desktop – and probably started at boot/login if it’s not already running – and it will allow the desktop user to select from a list of PCoIP profiles. The profiles are “applied” by editing the registry and setting the desired values for the PCoIP parameters. You then need to disconnect/reconnect and the new profile will take effect. The tool comes pre-loaded with a few default profiles which you can delete or edit as you see fit. Don’t read too much into the names at this point :) It also allows you to take any existing profile, customize it and then save it under any name you wish.

The utility runs as a systray application so you may need to tweak your settings to insure the icon is always visible (if you want it to be) and all major functionality is accessed via a right-click on the systray icon.

Systray Icon and active profile tooltip

Systray Icon and active profile tooltip

Menu and profile list

Menu and profile list



Operation of the tool is fairly straightforward but I’ll cover the menu items here in order for completeness sake:

Activate Profile

This menu option will pop out a list of all available PCoIP profiles and you can then simply click on the profile you wish to activate.

Manage Profiles

This option opens a new window allowing you edit/create/delete profiles:

The Profile Editor window

The Profile Editor window

Profile selection within the editor window

Profile selection within the editor window

The values you can adjust here relate directly to the GPO settings (though the wording varies a bit).

  • To edit an existing profile just select it from the drop-down list, adjust any parameters as needed, and then click ‘Save Profile’.
  • To create a new profile begin with an existing profile, edit it, then type in a new name within the drop-down list and click ‘Save Profile’.
  • To delete a profile, select it, and click ‘Delete Profile’
  • To remove all existing profiles and reset to the default profile list, click ‘Restore Defaults’
  • To close the Profile Editor window, click the close button in the upper right.

Clear Profile Settings

Clicking this menu option will remove all currently applied profile settings, and clear out the value of the “last used” profile that the app will try to re-apply when it is launched. In effect this just reverts to the View defaults OR if followed up by a gpupdate /force will allow for easy reversion to the GPO defaults (if any are applied – it may not be wise to apply a GPO if you are using the utility, more on that later).

Show Session Stats

This menu option will popup a small monitor that will poll the PCoIP WMI sessions stats to provide some general information about the current session:

Session Stats Monitor window

Session Stats Monitor window

The window will be “always on top”, can be dragged by clicking it, and is slightly transparent to be less intrusive. Selecting the menu option a second time will hide the monitor window.

A few notes on the stats displayed in the window:

  • PCoIP CPU utilization is not showing accurately in the status monitor – it’s higher than it should be when comparing against taskmgr measuring the same process. I am looking into this – it is beta code people :)
  • The status monitor only shows “Tx” stats for items where it is relevant. The two values shown are current Tx/Peak Tx, for other items the values are the same – current/peak. In most cases Tx is what you really care about anyway and I didn’t want the window to be any larger than it needed to be.


I am assuming we can all figure out what this menu item does.


Requirements, Issues, Implementation details, etc.

  • I developed and tested the app on Win7 64bit but it should work on 32bit systems including XP – if it doesn’t, I need you to tell me.
  • .NET 3.5 is required
  • You should really only use this with VMware View 5.0 or the 5.1 beta
  • Tuning profiles and last used profile are stored in HKCU and in theory should be able to roam with a user to whatever desktop they happen to land on – if you have something setup to allow the profile to roam, that is.
  • The utility will request admin access – it needs this to be able to write to HKLM which is where the PCoIP settings are read from. You may need to get clever while launching it if you want to avoid UAC nagging you about it.
  • This really is beta-class software. I threw this together in 2-3 days right before I left for PEX. There will be bugs. Find them, get me the steps to reproduce them, and I will fix them. Understand that YMMV, and that you assume all risk for any damage this utility may cause to your VDI environment! Back things up before messing with it please!

GPO Conflicts

So, how does a tool that writes directly to the local registry compete with GPO settings? In this case quite well for the most part. GPO will always “win” eventually, so whatever settings you apply, if they are different from a GPO that is also applied to your desktop, will get overwritten at the next policy refresh. BUT! since the PCoIP server process only reads parameters at session connection, so long as you activate a profile, and disconnect/reconnect BEFORE a policy refresh happens the server will load it’s config from the profile and happily go about it’s business. If a policy refresh comes down and changes the registry settings it won’t matter one bit to the PCoIP server – unless you disconnect (or get dropped). If that happens you need to re-activate the profile you want and disconnect/reconnect again (it sucks, I know). But generally, that should be an infrequent event unless your policy is set to sync quite frequently.

Still, the best advice is to avoid applying a PCoIP GPO to the desktops where you plan to use the utility.

I imagine there are a few ways I can detect if the settings have been changed by a policy refresh and then immediately re-apply the currently active profile but that’s low on the list right now. Thoughts are welcome on this though.



You can grab a copy of the utility here: PCoIPConfig.exe


In Closing

I am releasing this tool because I hope that some people may find it useful, but also to solicit feedback. In a way I am hoping to foster an angry mob to help me push for truly dynamic configuration of the PCoIP server process. I have described this as wanting people to say “This tool is awesome! But it sucks!” – in reference to it’s perceived usefulness, and the disconnect/reconnect requirement accordingly.

Knowing there are people (customers, partners) who see value in a tool like this will carry much farther than my one, lonely voice. So please, if you find the tool useful, but hate having to disconnect – be vocal.  Not just here, but elsewhere too – get on the VMware communities, talk to your VMware reps – show them the tool, explain the issues it attempts to solve, and how it’s close, but not quite ideal.

If truly dynamic configuration of the PCoIP server can be added it opens the door to automatically switching profiles based upon location awareness, new tuning toolsets where you can see the impacts of tuning settings in real-time, new tools for an automated PCoIP health-check, and many other things! I already have the ideas, but until we can avoid the disconnect they’re just not viable. Until then, let’s see where this goes…