How to remove the NetApp Host Utilities hotfix check


Update 2018-10-18Check out this comment. Looks like a much easier method than my MSI editing one.


Sick of the hotfix requirements for NetApp Host Utilities? Me to.

On a test/dev server I have I’ve been experimenting with Veeam, iSCSI, ReFS and Server 2016. I wanted to run the NetApp Host Utilities against my Server 2016 box and was told I was missing Q3197954:

Problem is this 2016 server is fully patched and if I go manually download Q3197954 (which appears to be a previous rollup) I can’t install it on my fully patch server.

On a hunch I figured I might be able to crack open the MSI and find a way around the hotfix check and I was right. Here is how you do it:

  1. Download and installĀ Orca MSI Editor (Alternate Download)
  2. Download the NetApp Host Utilities package from (v7.1 as of this writing)
  3. Launch Orca and open the MSI file with it
  4. Select ‘InstallUISequence’ on the left and then click the ‘Sequence’ column on the top right to sort by lowest value first
  5. Locate ‘CheckMSHotfixes’, right click on it and choose ‘Drop row’
  6. Click ‘Save’
  7. Close Orca
  8. Copy the edited MSI to your server and run the installation as per normal

Digging around the MSI a bit I found references to “IGNORE_HOTFIX_CHECK” listed. I suspect it’s some kind of flag or environment variable that could be set to accomplish the same thing but I was unable to find any documentation on how and a few guesses around using environment variables didn’t pan out so I decided to stick with the above solution.

A note of caution. This is likely 100% unsupported by NetApp and if they found out you did this to get the Host Utilities on your server you might run into support issues.

Importing a OVF exported from vCloud into VMware Workstation fails

We’re backing out of a vCloud provider and trying to drag our VMs back into our local vSphere cluster.

I’ve used ovftool to export our VMs from vCloud into OVF templates. I then import the OVF into VMware Workstation 14 and from there drag/drop the VM into our vSphere cluster. There is likely a way to get the ovftool to export in a format that will work directly with vSphere but since this is working I’m just going with it.

This process worked fine on all of our VMs until I got to a group of them that had access to an extra network in vCloud. When trying to import these VMs into VMware Workstation I get the following error:

The source contains more than one network. This target supports at most one network.

I cracked open the ovf file in a text editor and found this near the very top:

In here you can see two networks, “myorg-it-pa-protected” and “server-net” on Line 3 and 6

The networking configuration doesn’t really matter to me since it doesn’t match with our vSphere deployment all I want to do is get these VMs imported. I’ll edit their networking afterwards.

I ended up deleting “myorg-it-pa-protected” by taking out lines 6-8 and lines 29-45. I then save/closed the OVF file and ran it through a hashing app to get the files SHA256 value.

I then opened the .mf file that sits in the same directory as the OVF file and updated the SHA256 entry for the OVF file. I was then able to import my VMs into VMware Workstation.

On Mac/Linux you can use “sha256sum <filename>” to get the SHA256 value of the edited OVF file. On Windows I use tools like HashTab and HashCalc OR if you have the Linux Subsystem installed on Windows 10 you can just use “sha256sum <filename>”.