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:
http://repurpose.vmwarecloud.at/
Enjoy!
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.
Features
- 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
Hovering over a profile now shows detailed information
Fixes
- 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
Enhancements
- 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.
Download
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.”