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:
- Download and install Orca MSI Editor (Alternate Download)
- Download the NetApp Host Utilities package from https://now.netapp.com/ (v7.1 as of this writing)
- Launch Orca and open the MSI file with it
- Select ‘InstallUISequence’ on the left and then click the ‘Sequence’ column on the top right to sort by lowest value first
- Locate ‘CheckMSHotfixes’, right click on it and choose ‘Drop row’
- Click ‘Save’
- Close Orca
- 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.
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:
<ovf:Info>The list of logical networks</ovf:Info>
<ovf:Info>The configuration parameters for logical networks</ovf:Info>
<vcloud:ParentNetwork href="" name="server-net"/>
<vcloud:ParentNetwork href="" name="test-net"/>
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>”.