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!

Managing FSMO roles with PowerShell in Server 2012 R2

Powershell was released some time ago but it feels to me like it was just yesterday.  Part of that is because as time moves on Microsoft is adding more and more features.  With Windows Server 2012 R2 now in full effect and quite stable, it's clear PowerShell is taking over as the primary Windows scripting language of choice.

I am a firm believer that everything in Windows Server 2012 R2 that can be done in the GUI can also be done in PowerShell.  Case in point, I just upgraded one of our network Domain Controllers from Windows Server 2012 to Windows Server 2012 R2.

Since this server was a DC the first thing I needed to do before the upgrade was to ensure the server was not running any of the five FSMO roles on our network.  To do this I ran the following command in PS on the server.

netdom query FSMO

This will return which DC or DCs on your network contain the FSMO roles.  Since the server I was upgrading had none then I had none to move before the upgrade.  Once the upgrade had completed I now wanted to make sure the newest DC on the network had the roles while others were being upgraded.

To transfer all five roles you can simply run this command in PS:

Move-ADDirectoryServerOperationMasterRole -Identity “Target_DC_name” –OperationMasterRole 0,1,2,3,4

For reference the command line syntax replaces the role number for the full name of the FSMO role.

• PDC Emulator = 0
• RID Master = 1
• Infrastructure Master = 2
• Schema Master = 3
• Domain Naming Master = 4

If you find yourself in a situation where the DC you want to transfer roles from is offline and cannot be brought back then you'll need to seize the roles.  Here's the command for that:

Move-ADDirectoryServerOperationMasterRole -Identity “Target_DC_name” –OperationMasterRole 0,1,2,3,4 - Force

 Finally to transfer or seize just one role you would run the exact same command and just use the number of the role you need to move.  These commands work on Server 2008 R2 and up or Windows 7 with the RSAT (Remote Server Administration Tools) installed.

I don't find myself moving FSMO roles often but when I need to this is much easier than using the GUI.  A great reference on PowerShell is Learn Windows PowerShell 3 in a Month of Lunches.  It's a great read and has tons of great PowerShell information.

Good luck.

Renewing the Self-Signed Certificate: Exchange Server 2007

This is another perfectly written article that I have borrowed on this subject.  I got it from Exchangepedia and the author Bharat Suneja deserves all the credit.

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need – securing communication paths for Exchange services by default. Nevertheless, one should treat these certificates as temporary. Although the self-signed certificates work perfectly well for internal SMTP communication between Hub Transport servers, and between Hub Transport and Edge Transport servers, it’s not recommended to use them for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

Should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these will need to be renewed when they expire — just as you would renew certificates from 3rd-party or in-house CAs.

 1. To renew the certificate for server e12postcard.e12labs.com, a server with CAS and HT roles installed:

Get-ExchangeCertificate -domain “e12postcard.e12labs.com” | fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:

Get-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F” | New-ExchangeCertificate

To create a new certificate with an exportable private key, use the PrivateKeyExportable parameter. For example:
New-ExchangeCertificate -PrivateKeyExportable $true

If the existing certificate is being used as the default SMTP certificate, you will get the following prompt. The default SMTP certificate is used to encrypt SMTP sessions between transport servers in your organization.

Confirm
Overwrite existing default SMTP certificate,
‘C5DD5B60949267AD624618D8492C4C5281FDD10F’ (expires 8/22/2008 7:20:34 AM), with certificate ’3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E’ (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is “Y”):

Type y to continue. A new certificate is generated.

Thumbprint   Services   Subject
———-   ——–   ——-
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   …..   CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:

Get-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” | fl

2. The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP – IIS is missing.

You can enable the certificate for IIS (in addition to any other services it may already be enabled for — it adds to existing values of the certificate’s Services property).

Note: Once you enable a certificate for a particular Exchange Server service, there’s no way to disable it (for that service). You must remove the certificate (if the certificate is CA-issued, export the certificate along with its private key before you do so), import it again and enable it for the services you need to. This is generally not a concern with self-signed certificates— you can generate additional self-signed certificates and optionally remove the old one, since there’s no CA interaction or costs involved.

Setting the Services parameter to None does not do anything in this case.

To enable the certificate for IIS:

Enable-ExchangeCertificate -thumbprint “3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E” -services IIS

3. Test services are working with the new certificate. If it works as expected, the old certificate can be removed:

Remove-ExchangeCertificate -thumbprint “C5DD5B60949267AD624618D8492C4C5281FDD10F”