AutoCorrect hell – VMware

 

If you are like me and can’t stand it when Office Applications change the casing of Pronouns such as “VMware” to “Vmware” for example, there is a quick fix you can do. Most may already be aware, but this has hassled me one too many times today, and I therefore sought out the option to prevent it from happening. I was using Excel 2010, however similiar steps should apply to all Office Applications.

 

  • Go to the File -> Help -> Options -> Proofing menu.
  • Click “AutoCorrect Options” -> make sure the tickbox for “Correct two INitial CApitals” is either off, or alternatively and the better option, click “Exceptions”.
  • Add an entry called “VMware” under the “INital CAps” tab.
  • Apply

For a fun list of VMware spelling derivatives be sure to check out Darren Woollard’s “VMware, it’s all in the name” blog post.

 

Kwikfit – Avoid if you value your safety and money

So this is a bit of a change to my normal subject matter, but I felt like I should post this up, as this is shockingly bad service that should not go unnoticed.

 

Around 5 or 6 weeks ago I noticed a scraping sound coming from my car’s braking system on the way in to work. I finished the trip, and arranged to have the braking system checked out at lunch time at the nearest Kwikfit branch – Bracknell, in Surrey (closest at the time as I was on client site). I took the car over, and explained to the person at the counter that I had heard a loud, scraping noise coming from the front of the car whenever I applied brakes lightly. They did their standard “free” brake check and called me back about 40 minutes later to say that everything had passed and was 100%, nothing to worry about. They then explained that the scraping sound was probably just a bit of dirt and that they had cleaned the  brakes out after removing everything to check them.

 

On the way back I still noticed the slight scraping sound and thought I would give it a while in case it was in fact dirt, and just needed to come loose – like a small stone for example. Fast forward a few weeks and the noise is still there. I trust Kwikfit’s diagnostic report and advice, as this is their area of expertise – how hard can it be to check brake pads anyway? Things at work have been, and are getting very busy, so I kind of forget about the brake noises for a couple more weeks.

 

Today I thought I better get a second opinion, as the noise has been getting progressively worse over the last couple of days. I send the car over to my trusted mechanic and he comes back to me straight away to say that the front left brake pad is completely worn through and it is plainly obvious that this is what is causing the noise. Aside from that, the brake disc has of course been worn down by the metal-on-metal wear. I need to replace both front brake discs and pads as a set. £200 later I have replaced everything and at the end of today I got my car back – no more noise, and the brakes feel great. I pulled out my Kwikfit diagnost report from around a month back to double check – as I remembered, everything is marked off as “OK” on the brake pad and other components. At the top of the report, you can even see where they marked down that I had reported “Noise” coming from the brakes!

 

I am appalled with the service and bad advice I received. Not only did Kwikfit’s service cost me more money in the end – having more components to replace because of damage, but they also put me and my family’s safety on the line by telling me that there was nothing wrong with my brakes, when in fact, they were completely worn down! I most certainly won’t be using their services in the future, and sincerely hope that they can correct things like this from happening in the future.

For those interested, here is original diagnostic report they gave me – scanned in colour. I have of course blanked out my personal details, but you can see where they marked down the symptoms I had reported, and where they give everything a nice big “OK”.

 

 

Live Migrating a VM on a Hyper-V Failover Cluster fails – Processor-specific features not supported

 

I have been working on setting up a small cluster of Hyper-V Hosts (running as VMs), nested under a bunch of physical VMware ESXi 5.0 hosts. Bear in mind I am quite new to Hyper-V, I have only ever really played with single host Hyper-V setups in the past. Having just finishing creating a Hyper-V failover cluster in this nested environment, and configuring CSV (Cluster Shared Volume) Storage for the Hyper-V hosts, I created a single VM to test the “live migrate” feature of Hyper-V. Upon telling the VM to live migrate from host “A” to host “B”, I got the following error message.

“There was an error checking for virtual machine compatibility on the target node”. The description reads “The virtual machine is using processor-specific features not supported on physical computer “DEVHYP02E”.

 

So my first thought was, perhaps there is a way to mask processor features, similar to the way VMware’s EVC for host physical CPU compatibility works? If you read the rest of the error message it does seem to indicate that there is a way of modifying the VM to limit processor features used.

 

So the solution in this case is to:

  • First of all power down your VM
  • Using Hyper-V Manager, right-click the VM and select “Settings”
  • Go to the “Processor” section and tick the option on for “Migrate to a physical computer with a different processor version” under “Processor compatibility”
  • Apply settings
  • Power up the VM again

 

Processor compatibility settings - greyed out here as I took the screenshot after powering the VM up again.

 

So now if you try and live migrate to another compatible Hyper-V host, the migration should work.

 

Changing Registry entries on multiple systems with PowerShell and Remoting

 

A few weeks ago, a colleague asked if I knew of a way to script the change or modification of the Registered Owner / Organization information on a Windows Server system (2003 or 2008). I knew that this could be achieved with PowerShell and had some initial ideas, so I spent a few minutes whipping up the script below.

For this to work, you should ideally have all systems on the same Windows Domain and have enabled PowerShell remoting on each system that needs to be changed. Of course you could also just run the script on a single workstation/server on its own without the need for PSRemoting.

 

# On all remote machines that need their info changed
Set-ExecutionPolicy RemoteSigned
Enable-PSRemoting # Say yes to all prompts
#region This part only needed if machines do not belong to the same domain...
# Note: This can be a security risk, only use if you are sure you want to allow any host as a trusted host. (e.g. fine for lab environments)
cd wsman::localhost\client
Set-Item .\TrustedHosts * # Say yes to all prompts
#endregion
# Run on your management machine/machine you are using to update all others...
$computers = @("SERVER1","SERVER2","SERVER3")

foreach ($computer in $computers) {
    Enter-PSSession $computer
    cd 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion'
    Set-ItemProperty -Path . -Name "RegisteredOwner" -Value "Auth User"
    Set-ItemProperty -Path . -Name "RegisteredOrganization" -Value "Lab"
    Exit-PSSession
}

 

So the above should update your registered owner and organization details for each server listed in the $computers array. (Specify your own host names here). The above script should be easy enough to modify if you are looking to change other registry entries. Finally, don’t forget that you should always be careful when updating registry, especially via script – make sure you have backups!

 

HP P2000 G3 FC MSA – troubleshooting a faulty Controller (blinking Fault/Service Required LED)

Setting up a new HP P2000 G3 FC MSA with dual controllers over the last couple of days for a small staging environment, I ran into issues from the word go. The device in question was loaded with 24 SFF disks and two Controllers (Controller A and B).

 

On the very first boot we noticed a fault (amber) LED on the front panel. Inspecting the back of the unit, I noticed that Controller A and B were both still flashing their green “FRU OK” LEDs, (which according to the manual means that the controllers were still booting up), even after waiting a number of hours. On Controller A, I could see a blinking amber “Fault/Service Required” LED. Following through the troubleshooting steps in the manuals lead nowhere as the end synopsis was to check the event logs. Even the Web interface was acting up – I could not see the controller’s listed, could not see any disks and the event logs were completely empty. Obviously there was a larger issue at hand preventing the MSA and even the Web interface from functioning properly. To further confuse matters, after shutting down and restarting the device, controller B starting blinking the amber LED instead of A this time, both still stuck in their “Booting up” state. Refer to the linked LED diagram below and you’ll see that the LED flashing green is labelled as 6, and the amber blinking LED is the one labelled as 7 on the top controller in the diagram.

LED Diagram

HP Official documentation

After powering the unit down completely, and then powering back up again, the MSA was still stuck in the same state. Powering down the unit once more, removing and reseating both controllers did not help either. Lastly, I powered it all off again, removed controller A completely, then powered up the device with just Controller B installed. Surprisingly the MSA booted up perfectly, and LED number 6 (FRU OK) went a nice solid green after a minute or so of booting up. No amber LEDs were to be seen. Good news then! Hot plugging controller A back in at this stage with the device powered on resulted in both controllers reporting a healthy status and all the disks and hardware being detected. A final test was done by powering off everything and powering it back up again as it should be from a cold start. Everything worked this time.

 

Here is a photo of the rear of the device once all was resolved showing the solid green FRU OK LEDs on both controllers.

 

 

Bit of an odd one, but it would seem that controllers together were preventing each other from starting up. Removing one then booting up with this seemed to solve the problem, and at the end of the day all hardware was indeed healthy. After this the 24 disks were assigned and carved up into some vdisks to be presented to our ESXi hosts!