Error while updating VMTools in Fusion 6

Like many Mac users, I run VMware Fusion so I can use Windows when needed. I've got a VM running Windows 8.1 that I use primarily for Visio and RDP sessions (I've never liked the native RDP client for OS X). And to be honest, it's one more machine for me to patch and update; this is therapeutic for my OCD.

I ran into a problem a few weeks ago while trying to update VMTools in my Windows 8.1 guest. It's an error I've seen many times over the years with various Windows applications, and when it popped up, I had flashbacks from regedt32 and blowing away keys on Windows 2000.

I figured this was a common issue, so I searched VMware's KB and found this article: Unable to upgrade existing VMware Tools (1001354). I ran through the section on Windows 8, but none of those steps applied to my installation. The last section (finding and deleting all occurences of vmware in the registry) was a little more than I needed. I didn't want to corrupt all of the VMware software I've got loaded (PowerCLI is a MUST!). So I tried something different.

In the error screenshot, you'll notice that the source field references a CLSID (it's the data that begins with {8AE43F1). The CLSID uniquely identifies the application that you're working with. I decided to search the registry for any data that matched the first portion of this CLSID. Here's the result of that search:

You can see that the search turned up an entry that referred to VMware Tools and the path to the installer. I decided to delete this whole key and then restart the VM. (This is where timid bloggers will say "make a backup." I say just delete it. I'm bold like that.)

Success! I was able to install VMTools without error after getting rid of that key.

Now VMTools is current and running. Don't waste time wondering if this is a Windows problem or a VMTools problem. You'll drive yourself mad in the process. Just fix it and move on. Nothing to see here.

A Hammer for Every Nail

I spend a lot of time at Home Depot. A lot.

You know how it is: every time you start a new project at home, you go out of buy a whole new set of tools specifically for that job, right? The hammer you bought to hang those picture frames can't possibly be used to attach wheels to a pinewood derby car. Or maybe advances in hammer technology have made your old hammers obsolete, so you're compelled to purchase a new one every few years. You still keep the others around, though. Just in case.

Note: Only insane people do this.

Tools perform tasks, not projects

You buy a hammer to drive nails, not just nails for a single project. When another project comes along, you use the same tools, as long as those tools are suited for the job. You certainly do not buy a hammer for every nail you drive.

Now take this approach to tools, and apply it to enterprise monitoring.

In large organizations, it's common for each application, service, or portion of infrastructure to have its own monitoring tools. Exchange is monitored by Exchange monitoring tools. Storage is monitored by storage monitoring tools. And so it is with all of the technologies in use. Each project has its own hammer. And thanks for institutionalized silos (both organizational and cultural) tools shall not be shared.

This doesn't sound so bad. Is this bad?

I took the photo of hammers at Home Depot to prove a point. Yes, if you are so inclined and well funded, you can absolutely buy a hammer for every nail. Load up a shopping cart with 100 hammers and go through the check-out. (On a side note, if you actually do this, please please please send me a picture.) Use each hammer for a single nail.

Or at the office, go ahead and buy a monitoring solution every time you stand up a new service. Load up your budget with Tivoli, BSM, SolarWinds, ManageEngine, Quest, and whatever else you can find. Total up the costs and get your manager to approve it. (On a side note, if you actually do this, please please please send me a picture.) Use each monitoring solution for a single service.

What's the point?

The point is this: if you approach enterprise monitoring differently for each service, you're doing it wrong. If you currently have a spreadsheet of the 40-50 "enterprise" monitoring tools you have in your environment, you're doing it wrong.

Instead, survey the services and applications that your IT department provides to your users. Build out requirements for a true enterprise monitoring solution (which will likely be a combination of tools, yes, but the combination should be intentional and complementary). Invest in a tool to monitor your enterprise. That's the perspective you'll want to have. You'll reduce costs and complexity by relying on fewer, more powerful tools.

HA vs FT

First things first: I'm not talking exclusively about vSphere here. I'm writing about concepts, expectations, and operations, not any one product in particular.

I'm wrapping up my first week at a new project. It was a first week like most others: spending time on administrative tasks, completing various applications for access to stuff, and meeting people that I'll be spending some quality time with in the near future. I even sat in on a few meetings that helped me start to wrap my head around the infrastructure, which is rapidly changing.

Dude, this picture doesn't even make sense.

One of the topics that came up in these meetings had to do with a pair of firewalls, and their configuration as a active / passive pair. From what I gather, the conversation (during the design phase) went like this:

Management - "Are the firewalls designed to be redundant?"
Engineer - "Yes."

A seemingly innocuous, normal exchange. But the difference was in the way the engineer interpreted management's question. Management, by way of redundant, meant that a failure at the hardware level will not affect flow of traffic. Not even for a second. The engineer, upon hearing redundant, meant that yes, there were two firewalls, and if one failed the other one would handle the load after a brief outage.

This is where HA vs FT becomes important. In a vSphere cluster, we know that HA will let us recover virtual machines, automatically, AFTER the hosts determine that a failure has occurred. In order to reduce unnecessary failover, there's some logic in HA that prevents VM recovery until multiple checks and heartbeats have failed. The effect of this logic is that VM restart can take a minute or two (or three, I don't have my vSphere bible (aka the Clustering Deepdive book) with me at the moment) to start. As vSphere people, we're accepting of this time. It's still WAY faster than any manual failover or recovery that we could do. But this does mean that there's an outage.

This truly is HA: High Availability. It's not the avoidance of outages; it's the rapid recovery from outages.

FT is a different beast altogether. Now we're talking active/active. And that brings up lots of other considerations (tracking sessions across devices, addressing, how to monitor, load balancing, et cetera). It's FT that management is expecting when they say "redundant," not HA. They're looking for a solution that has no impact to their business customers during a hardware failure.

Engineers will say, "But fault tolerant systems cost 10x more! Diminishing returns! Unnecessary complexity!" Those all may be true. But management needs to hear that and make the decision on whether pursuing fault tolerance is worth it. Don't assume that it's too expensive. Find out what the functional requirements are at the start of your project, document, and get approval. There's always money for a good solution, and there's rarely money for a bad one.

The management-to-engineering interface is always a challenge in the IT world. Learning to speak both languages helps to avoid the problem of miscommunicated and misunderstood requirements.