Using Pre-Release Software Not Always A Great Experience

Over the years in the industry, I've had the opportunity to use pre-release software. Some of it has been pretty awful, while others perfect or nearly so – and more in between. Using software that has not been richly tested is always a bit of a gamble, although some vendors are better than others. Of course, issues during pre-release typically get resolved prior to general release – so these errors really only affect those of us mad enough to use beta code!

With that in mind, I downloaded the latest build of PowerShell V5 as soon as it was released. I was anxious to see what, if anything, had become of the Chocolatey provider for Find-Package (OneGet) as it had been removed in an earlier beta version (as previously noted!). So my first test was to do both Get-Module and Get-Package to see the two 'get' package managers in action.

Much to my surprise, running Find-Module produced a ton of errors:

Weird, to say the least. I tried to see if other beta testers were seeing this issue the ones I was able to chat with did not see this error. Then I was having a Skype conversation with Aleksander Nikolic who asked me what culture I was using. As you can see in the above screen shot, I'm using my home culture (en-GB). He suggested it was culture related. To test this, I spun up an Azure VM, loaded the new version of PowerShell V5 and, as if by magic:

Just as I expected! This looks to be another culture issue – one that will no doubt be sorted out by the time RTM comes around (or, hopefully, a newer build is released that works with En-GB).

It's easy to understand this issue, but I guess I'd have been less surprised and frankly less disappointed, if the issue had been mentioned in the otherwise excellent release notes (or possibly even acknowledged in the release notes). One for the future perhaps.

So for the foreseeable future, I'm stuck with using a partly broken beta build. I can live with OneGet being broken in exchange for the other goodies in V4. And yes, this bug has been reported on Connect (https://connect.microsoft.com/PowerShell/Feedback/Details/1037088). Feel free to vote it up!

The joys of using Beta software!

Technorati Tags: Bug in PowerShell,PowerShell V5

Windows 8.1 Can’t Import VMs Exported from earlier OSs.

Like many, I’ve been experimenting with Windows 8.1. It’s a nice improvement in many ways to Windows 8, but there are still some bugs. Unfortunately, as I have discovered, MS is no longer planning to ship this OS when it’s ready. Instead, they plan ship it when they ship it – warts an all. This post documents another example of that.

Like a lot of Microsoft Certified trainers, I have a huge library of training course related sets of Hyper-V VMs. These are issued by Microsoft Learning (MSL) and are an important part of the classroom experience. Some of these sets are huge (over 20 VMs with a few courses with even more). The VMs are delivered in an ‘exported’ state – the user (the MCT or training centre) just unpacks them, moves the files to the right place then imports the VM into Hyper-V.

In playing with Windows 8.1 Preview, I discovered something pretty nasty with this new OS: you can not import an existing Windows 8/Server 2012 (or earlier) VM that was exported from an earlier OS. This is a nasty bug for many, particularly MCTs and CPLSs (Microsoft’s partners for learning).

The basic issue is that you cannot import an old (exported) VM into 8.1/2012R2. The reason is that there is no support for it – even after this weakness was discovered. The "technical" reason for this is that the MOC VM export files (exp files) use the Hyper-V WMI v1 namespace. In Win8.1 and Win2012 R2, the Hyper-V WMI v1 namespace is no longer present, only the Hyper-V WMI v2 namespace - and the product does not contain a conversion option. Thus you can not import VMs.

The work around is to create all new VMs and use the existing VHDx(s). That sounds ok in principal, but there is a significant legal problem here: namely Microsoft partners are contractually prohibited from ‘fixing’ any of the VMs shipped by Microsoft Learning. Of course, folks can and do do this all time to fix the bugs which MSL cannot and do not fix. But it’s against the CPLS contract. This means that every Hyper-V VM shipped by MSL today can not be run under Windows 8.1, and Server 2012 R2.

I filed a bug on this. You can see it at: https://connect.microsoft.com/WindowsServer/feedback/details/794215/windows-8-1-can-not-import-older-hyper-v-vms#tabs although not everyone has access to this part of connect. The answer posted by Microsoft was “it would not be possible to make this change in the product. Our only option right now is to reach the MS learning teams and explain the situation and escalate it in their levels to get this content re-issued. The teams here are backing me for escalation with MS learning.”

So the Sinofksy approach of ignoring the reported bugs and shipping on time no matter what seems to live on. This is really gong to bite a lot of CPLSs – and I can honestly imagine a law suit here. It’ll also make a total mockery out of MSL’s “you can’t change shipped VMs no matter what’ stance.

All things considered, I’d prefer Windows 8.1 and Server 2012 R2 to ship when it’s ready and to ship a set of features that contain good upwards compatibility. Sadly, that is not what MS will ship. This summer is really turning out to show Microsoft in a bad light. First, scrapping TechNet subscriptions and now making my life as a trainer just that much more difficult.