Month: August 2014

HomeLab: Installation and Configuration

Hey All!
If you saw my previous post, I identified components that would make a pretty decent beginning to a home lab.
I made those purchases via Amazon, and assembled the components. Luckily everything worked fantastically out of the box – I was secretly worried that my lack of recent computer building experience would bite me when it came to assembly: it seems that building computers is an awful lot like riding a bike in that regard.

Alright. So now we have two black boxes that power on and display the friendly message:
Operating System Not found.

Now what?

Note: I assume everyone reading this blog is a VMware vExpert and Microsoft MVP and get licensing that way. Otherwise, license VMware and Microsoft products as you normally would. Both also offer trial periods of their software. 

  1. Install ESXi on our new hosts:
    The decision was made to use USB flash for ESXi and dedicate the internal drives to running VMs, so the time has come to mess with the USB Flash drive.We don’t have any internal optical drives in our set-up, nor did I have any externals readily available. Turns out we can do this entirely without wasting a disk!

    1. Download RUFUS Windows utility. RUFUS = Reliable USB Formatting Utility (with Source)
      Similar tools exist for other Operating Systems. For what it’s worth, I ran RUFUS on a Windows VM on my Mac. 
    2. Download ESXi ISO from VMware Download page.
    3. Load the ISO into RUFUS.
    4. Replace Menu.C when prompted by RUFUS.
    5. Click ‘Close’ when complete.
    6. Boot ESXi Host using USB key (You may need to modify boot order for this step)
    7. When ESXi installer loads, perform a normal ESXI installation. Install to USB Flash (This will wipe out the installer ISO)
    8. When complete, you have a working ESXi system. Hooray! In my case I did this to both boxes.
  2. Configure a management network on each host
  3. Use the vSphere client to connect directly to a host
  4. Create a new VM for vCenter
    1. Mount your Windows Server ISO in your new vCenter VM
    2. Configure machine to VMware best practices (You can probably get by with less for this sized environment)
    3. Install Windows
    4. Mount the vCenter installation media (From VMware’s Downloads page)
    5. Perform a simple install of vCenter
  5. Create a new VM for Active Directory
    1. Mount your Windows Server ISO in your new AD DC VM
    2. Follow this tutorial

This is the very beginning of the home lab. In future posts, I’ll detail the AD Configuration and other Lab related things!


UPDATE: VM with Console Interaction Issues- RESOLVED.

Hey All, 

In my last post, I presented an “Unsolved Mystery” where a VM lost keyboard and mouse control at the console and via PCoIP. The client spent time over the weekend and resolved some registry conflicts in his virtual machine. The issue always seemed to be a driver conflict, but I couldn’t resolve it in the time I had budgeted for resolving upgrade-related issues on this project…. I’m glad it ended up resolved! I can’t claim victory on this issue, but I can present his results:

From the client:


Not exactly sure, but I think I know how.  I uninstalled VMTools.  Left the agent installed.  Under the keyboard and mouse class in the registry, there were folders; 0000, 0001, and 0002.  I deleted all of these, including 0000.  I also added back the UpperLimits key and used the default values, not the VMTools values.  I restarted the VM and the keyboard and mouse worked.  The mouse was a little quirky, but at least they worked.  I shut down the VM and made a snapshot, just in case.  I brought it back up and installed VMTools and restarted.  It works great now.  Mouse is working properly.  I have restarted a couple of times and even connected thought View and it all works great.  So, I am assuming the 0000, 0001 and 0002 folders were holding some old driver info or something.  Not really sure, but that is what I did and it works great now.” 

So there you have it. Hopefully nobody runs into this again but if you do, clear out any and all entries in the keyboard and mouse class in the registry and restart. In my own troubleshooting I left the 0000 folder thinking it was a default,  but that didn’t resolve it. 

Go Mr Customer! 

From the Field: Uninstalled VMware View Agent, lost the war

Hey again!

This post will start a new blog tag for me: Unsolved Mysteries.

I migrated from SQL Express to SQL 2008r2 and upgraded View and vSphere to 5.3/5.5 for a client this past week. Everything went exactly according to the plan I had outlined prior to the beginning of the engagement.

Excited by the progress and the new features available in View 5.3, the client uninstalled the View Agent 5.0.1 that he had installed in his own personal Win7-32bit View desktop. Once uninstalled, he had no mouse or keyboard control in the vSphere console.

He came to me the next morning and explained what he had done the previous night – I suggested RDP which worked as expected. He installed View Agent 5.3 from within the RDP window, and Windows blue screened. Upon reboot, he still had no keyboard or mouse control. He hadn’t taken a screen shot prior to making the changes. The issue was passed to me to see if I could salvage the machine.

In short, the answer was no.
I cloned the machine off and started troubleshooting.

I had keyboard in the BIOS and the windows bootloader.
I noticed that the PS/2 Keyboard and mouse had yellow exclamation marks on them… traditionally this is driver related. 
Have console video throughout.
Definitely a Windows issue- Same issue on web and “fat” vSphere client.

In the course of a day, I had:

  • Uninstalled and reinstalled VMware Tools
  • Upgraded to VM Hardware version 10 and installed tools
  • Ran a selective startup and narrowed down to essential items for statup
  • Manually removed the “UpperLimits” DWORD value on the keyboard and mouse objects in the registry
  • Changes the DWORD value for start key on i8042 PS/2 KB and Mouse (From 3 to 1) in the registry
  • Ran a Virtual to Virtual conversion- Problem remained in converted machine

This will bug me for quite some time- it isn’t often that I leave a mystery unsolved. The client is okay using RDP until he gets around to rebuilding this machine. 

The twist? This has happened to another administrators desktop in the environment, and a VMware support case concluded that the desktop was lost and needed to be redeployed from template.


At least the other desktops were upgraded without this issue recurring… although we took snapshots before making changes after this ordeal!

Has anyone else run into anything similar to this?