Skip to content

Recent Articles


PCoIP Config Utility Download Errors

This is just a quick update – I know the link to download this is dead. I am currently tied up at VMware Partner Exchange but I know something is screwed up on my web host. I can’t dig into it now but will get it sorted as soon as I get home (this weekend). Apologies for the mess, this just blew up at a time where I don’t have the tools and access I need to fix it.

Stay tuned for more info this weekend.


Updated TinyCore Builder Link

For those hoping to find a simple and quick method to create a small, bootable Linux installation for PC repurposing – look no further…

TinyCore Builder allows you to fill out a simple form, and get a very compact bootable Linux image with the VMware View Client out the other end. The image provided is ideal for USB or PXE booting a repurposed PC againbst a VMware View environment.

The TinyCore Builder recently moved so if you were already aware of and using this tool, please update your links to the following URL:



PCoIP Configuration Utility Release 1.0 – Update and Shame!

Well, this is the kind of post I don’t like to make.  After getting a few responses and doing some additional troubleshooting (thanks Ed) I’ve found an issue with the new session disconnection detection that can cause the app to basically fail right from launch if you provide admin level credentials to authorize the app.  I believe this is related to the process elevating and then HKCU being visible to the app via the elevated user vs. the actual logged in user.  I’m going to do some tweaking and testing and hopefully get a fix for this up soon.  Clearly not everyone will be hit by this (I was never prompted to provide credentials in my testing so never caught this) but I have to think a good number of people will be, so for now, if you see an error about not finding the Volatile Environment – you have my sincerest apologies!

I’ll update the blog as soon as a fix is found.


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.


Thought’s on Apple’s New Dock Connector

I realize this is a bit out of character for the typical posts I do on here, but I just felt compelled to change it up a bit and relate my thoughts around a discussion I’ve been having with some friends regarding the rumored new dock connector for the next iPhone. In a way this is a response to the article found here (ugh, how it pains me to link to them), as that is what sparked the discussion.

At the end of that article the author concludes that the reasons for designing a new connector are not “control for the sake of power” but instead because it’s the only way to do it “right”. A committee could only produce an inferior product.

And this is where I disagree.

While I do believe in the power of the “individual” to be more bold and take greater risk in a design, I wholly believe this move by Apple is entirely about control for the sake of power – at least as far as power = money.

Any of the capabilities of the current dock connector can be handled by microUSB and/or analog audio jack and/or Bluetooth. You can bicker about the details but I’m sorry – the current generation of standard ports and technologies CAN provide equivalent functionality. Possibly “different”, but no less capable. So while Apple could work within the standards of today, they choose not to. If their concern really was to make a better connector for all of us, why couldn’t they go to the existing standards bodies and propose changes. Yes, it’s a committee, but if your goal is to really improve things, you’d tough it out. Apple could have massive influence on any standards body, don’t be fooled into thinking they couldn’t. So they could say “We would like to propose the following changes to the microUSB standard, connectors shall be omni-directional, tolerances shall be X, electrical characteristics need to be Y, additional data busses need to be provided for Z, and the following control protocols will need to be implemented. And by adopting this standard we can all benefit by enabling a broadly compatible ecosystem of devices and peripherals that allows for consumer choice, while also improving ease of use, and lowering costs through economy of scale.”

But that will never happen. That is why I can only see this as another power grab and tactic to control the cash flow around the Apple ecosystem. Even with a “standard” Apple could contract out and make the highest quality version of that connector, and the highest quality cables – better quality than anyone else. But they know that no one would pay their premium if Uncle Jimmy’s World of Connectors could make the same thing and only make it “good enough” for half the cost. Without creating an artificial scarcity via control of the hardware spec and licensing, Apple would have to fairly compete with everyone else – and that ain’t gonna happen.

I find it ironically amusing that Apple has gone into traditional media and completely busted up their model – a model based ENTIRELY upon artificial scarcity. That is/was the premise for music, movies, TV, and print.  Control the distribution channels and you control the pricing.  But no one ever looks at Apple and sees that they are doing the exact same thing with this forced ecosystem of proprietary connectors and ports. So it’s OK for them to bust up everyone else’s business, it’s just not OK for anyone else to bust up their racket.

My point here isn’t that microUSB is the “best”, my point is that everyone would benefit from an improved connection STANDARD – and in far more ways than just making the physical connection easier to use. Perpetuating proprietary connectors and then selling adapters to make them compatible (as the EU requires) does far less good. People still end up with the confusion/complexity of an inferior standard, and they have to pay more on top of it. How is that good for me? How am I benefiting from the improvements of the proprietary connector then?  Or, ok, go make your connector, but license it fairly – how do you think Apple would feel about letting Samsung license their new connector?  Motorola? LG? HTC? Asus? Acer? Intel? Microsoft? Yeah. Exactly.

“But why should Apple license it?! Why help those other guys? They did all the work designing it! They deserve to reap the rewards from it.”

Well, even licensing it, they would still profit from it. They could sell their “top-tier” versions, and also make money on every lower quality version sold. But I think they know they couldn’t compete there and while they would make some money from Uncle Jimmy, they make much more margin when they control all the pieces on the board.
 All of those companies I mentioned previously have managed to get by just fine with the existing standards, whereas somehow Apple cannot. And Apple refuses to take part in a way that would make their designs a new standard. This SO reminds me of 1990′s Sony. Sony had their own everything, even when it was the exact same stuff – functionally – as everyone else, it just HAD to be different. Different form factor, different pinout, different socket. It just seems like that strategy eventually loses. People get sick of it.
When I look at 20 devices and they all work together and then I look at the one device that doesn’t, no matter how great that device is, I’m going to be upset that it can’t just work like the rest of my stuff. The benefits need to be substantial not to be outweighed by cost, and frustration. I realize Apple still has a halo right now – just like Sony did in the 90′s – but it will get tiresome at some point.  Buying an adapter to gain compatibility to the standard, means you could have just been using the standard all along.
And for those who say microUSB sucks and it’s too confusing to get the connector in properly (seriously guys?) what about the existing display connectors on all Macbooks? Those are directional. You know how the problem of getting them plugged in properly was solved? By leaving one side blank, and silk-screening an icon on the other. The icon always faces up. I haven’t heard the outrage for a better connector standard there. Seems like a very elegant method of insuring proper connector insertion. One that, had any existing “directional” standard been implemented could have been carried over. Just look for the side of the cable that says “This end up” and we’re golden. Omni-directional connectivity is a nice perk, but it’s merely a mask to cover up the real reason Apple wants a new standard – control over distribution and pricing (margins). Good on them. Shame on the masses who can’t look for a label on a connector and are willing to pay not to have to learn how.