Backup and Restore ESXi Host Configuration

Today's post involves something I haven't done before which is backing up and then restoring an ESXi hosts's configuration.  

In my examples today I am going to use the tools directly built into ESXi and vSphere to get this done.  I'm going to use PowerCLI 5.5 (latest version as of this writing) to get this done.

PowerCLI is one of the many tools that are bundled for free with the vSphere environment.  I highly recommend you have it installed on your management server or workstation and if you're running vCenter on Windows it's even better to place it there.  You can download PowerCLI from the VMware website.

The process of backing up and restoring the configuration is pretty simple so here we go.

Before running any of these commands you should run this command in PowerShell on Windows to make sure PowerCLI has the ability to execute the commands needed for this process to work.

Set-ExecutionPolicy RemoteSigned

Open PowerCLI and use the Connect-VIServer IPAddress command to connect to the server.

Next run the command below to backup your host's configuration.  Make sure you create the backup location folder before you run the command.

Get-VMHostFirmware -VMHost ESXi_host_IP_Address -BackupConfiguration -DestinationPath “Output_Directory”

When the process completes you'll have files that look like this:

That's all there is to backing up the configuration of your ESXi host.  Now for the really cool part.  

If you're upgrading hosts to new hardware there a couple of things I've done and the restore has went off without a hitch.  Make sure you have the VMware install on the new host at the exact same version as the host you backed up.  If not this isn't a supported process but you can use the "-force" command at the end of the restore to make it do it anyway.  The next thing is to ensure you have the network cables in the exact same port numbers as the old host.  In other words port 0 on the old host should get the cable for port 0 on the new.

If you're unsure which cables correspond to which port, once you've migrated all VMs off of the old host you can look at the network configuration in the vSphere client and pull the cables one at a time.  From there just label each one so you know where to put it in the new server.

Once you've got the new box cabled up, on the same build of VMware as the old server, and powered on here's all you need to do.

First put the host into maintenance mode.  This is required or the next step will not work.  You can use the hostname, IP address, or FQDN if you want.

Set-VMHost -VMHost esx1 -State “Maintenance”

Next enter the restore command.

Set-VMHostFirmware -VMHost -Restore -Force -SourcePath

Once you do this the host will immediately restart.  During the restart it will import the backed up configuration prior to completing the loading process.

After the host has fully restarted you will be able to see that all of your prior settings have been restored including those many times complicated network, VLAN, and MTU settings.

On the hosts I have performed this on if they have local storage I have had to configure the large datastore again but given how much time this saves that's a minor thing to get the new server online much, much quicker.

Good luck with your upgrades!

Exchange 2013 Blank ECP/OWA Screen, Showing Event ID 15021 HttpEvent System Log

I hit this one today after switching out an expired UCC certificate on two Exchange 2013 servers in a DAG.  Both the ECP/OWA screens after login just went to a white page and never load.  The servers were both showing hundreds of ID 15021 in the system event log that says "An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data."

Here's the steps to fix it:

1. Open a command prompt.

2. Enter netsh http show sslcert  This will show the certs on the server.  Copy and paste this information into notepad.  Copy this info "IP: port: 127.0.0.1:443".  Note that this information contains the certificate hash and the application ID.  This is the information needed.

3.  Run this command:  netsh http delete sslcert ipport=0.0.0.0:444

4.  Next run this command:  netsh http add sslcert ipport=0.0.0.0:444 certhash=123443211234321123 appid="{ab34k32abkr3252jsnekgljw}"  Make sure to include the quotes around the appid.

5. Finally restart the server.

This is all it takes to correct the issue.  Apparently this glitch is specific to Exchange 2013 as a web based ECP doesn't exist in the earlier versions.

Simple fix to a real inconvenience.

Good luck!

Certificate Not Showing After Importing Into Exchange 2013

I ran into this one today with two servers in a DAG.  This is caused by the certificate you're using not having the private key.  Here's how I fixed it:

Go to the 1st server -> Start -> Run -> MMC -> File -> Add/Remove Snap Ins -> Certificates -> Computer Certificates -> Local Computer

Browse to the personal certificate store, right click on the correct certificate, select All Tasks, and then Export.  Make sure here you choose "Export Private Key" and assign a password.  Click Next and then name the file and where you want to save it.  The file will have a .pfx extension.

From there on the 1st server inside ECP you can go to Servers -> Certificates -> Choose the server you want and then import the certificate.

Once this process is done just assign the services to the certificate (SMTP, POP, etc) and then restart the server if possible.  If not some say you can do an IISRESET from the command prompt and then you'll be good.

Good luck!

Unable to scan IIS status - The IIS Common Files... Server 2012/2012 R2

I ran into this issue today while trying to run the Microsoft BPA (Best Practices Analyzer) 2.3 on a Windows Server 2012 R2 box with IIS 8.5 installed.  Below is the full text of the error:

"Unable to scan IIS status - The IIS Common Files are not installed on the local computer.  Refer to the system requirements list under the Microsoft Business Security Analyzer Help."

Here's the short fix:

Go back into Roles and under Web Server (IIS) and install IIS 6 Management Compatibility --> IIS 6 Metabase Compatibility.

Apparently from what I find this is a Windows Server 2003 item that hasn't been updated in the current server platform documentation on the MBSA to reflect the need for this additional set of files.

The longer explanation is that in order for the MBSA to be able to scan IIS properly it needs to have IIS 6 Management Compatibility turned on and more specifically the IIS 6 Metabase Compatibility.

I hope this one helps as it took me quite a bit of research to run this issue down.

Good luck.

Manually Applying Updates to Trend IMSVA

Whenever Trend issues an update for these virtual machines the GUI interface isn't always able to apply the patches to the VM.

 This is where a bit of time and patience have to come in to get them updated. Below is how I get it done quickly without much headache to keep these VMs current.

1. Download the patch or hot fix to your computer (Ex: imsva_90_en_criticalpatch1560.zip).

2. Extract the file.  You'll see a couple of files extracted such as readme_en.txt and imsva_90_en_criticalpatch1560.tar.gz listed.

3.  Use a program to upload the files to the IMSVA virtual machine.  I choose to use WinSCP.  Upload the file to the /tmp folder.

4.  Login to the IMSVA using root privilege using Putty or another program via SSH.  NOTE: You have to use SCP on WinSCP as the protocol and the root account for the VM.  If not it won't connect with the standard "admin" and password the web browser login uses.

5.  Run the following commands:

   # tar -zxvf /tmp/imsva_90_en_criticalpatch15160.tar.gz -C /tmp
   # cd /tmp/imsva_90_en_criticalpatch15160
   # ./imssinst

6.  Allow the installation to run and when the install completes you'll see something similar to this:

   Installation is complete and related services are started.

Just a note when you are done you can delete both the *.tar.gz file and the folder it created off of the IMSVA virtual machine to save space.

Login to the web interface and verify with the "About" option the new build version of your IMSVA.

I have found that not every hot fix or patch raises the build level in the web interface but if you try to apply it again to the IMSVA you'll find out it has already been installed.

For those of you that are not great in the Linux/Unix world I hope these instructions help you keep your critical infrastructure system patched and up to date.

It's Friday afternoon now so I hope you all have a great weekend.