The end of support for Windows Server 2003 is coming, and a lot of organizations are scrambling to migrate their production systems before the July 14, 2015 deadline. Many groups are still running the vCenter (5.0 or 5.1) that VMware View utilizes on Windows Server 2003, and I was recently asked about the migration path. For a vCenter/Windows OS compatibility matrix, click here.
There are two scenarios: One where the vCenter server maintains the same hostname and IP address, and one where the name and IP change. Today’s post deals with the first scenario and tomorrows will address the second.
Migrating vCenter to a new host without VMware View downtime
IMPORTANT NOTE: Proceed at your own risk. This operation is not supported by VMware. Click HERE for the KB.
- Export RSA Keys from old server
- Open an administrative command prompt and navigate to navigate to the %windir%\Microsoft.NET\Framework\v2.0xxxxx directory
- The ASP.NET IIS registration tool exports the RSA public-private key pair from the SviKeyContainer container to the keys.xml file and saves the file locally. Type: aspnet_regiis -px “SviKeyContainer” “c:\keys.xml” -pri.
- Copy the .XML file to the new server or network storage.
Document Database user names and passwords
Shutdown Virtual Center Services (And Composer if co-existing) on the vCenter server being replaced
Log into the View Administrator portal and disable virtual machine provisioning.
- Expand View Configuration
- Go to Servers\vCenter Servers
- Select the vCenter that will be migrated, and select ‘Disable Provisioning’
- Perform end-to-end backups of your environment (vCenter, Composer, ADAM). KB for that HERE.
- Shutdown old vCenter Server.
- In Active Directory, delete the old vCenter computer object.
- On the new vCenter Server, Rename the machine to the same as the old vCenter Server, Assign is the same static IP as the old vCenter, and join to the domain.
- Migrate RSA Keys to New VCenter Server
- On the destination computer, open an administrative command prompt and navigate to the %windir%\Microsoft.NET\Framework\v2.0xxxxx directory.
- type: aspnet_regiis -pi “SviKeyContainer” “path\keys.xml” –exp
- Install SQL Native Client (sqlncli.msi)
- Configure ODBC System DSN Connection for VCenter (Native 64-bit) and View Composer (Native 64-bit).
- Perform a simple installation of the vCenter Server and components (same version as what was running on old VCenter Server)
- If View composer is not standalone, Install View Composer. This may be a good time to split View Composer off of the vCenter server if that’s your ultimate goal.
- Ensure that all services started and are running.
- Connect to vCenter using either the vSphere client or Web Client (Depending on version). Ensure that hosts have reconnected and everything looks as you’d expect.
- In View Administrator, you may need to go to the Dashboard and Verify the SSL Certificates for the new VCenter.
- Enable Provisioning in View Administrator (should just work)
- Double-check any customization specs in the new VCenter Server.
- Test Recomposing and Provisioning of new Linked Clones.
User experience and expected behavior
It’s not exaggerating to say that this is an intense change-the-tires-while-doing-60-on-the-highway kind of operation, but in my testing of an 25 linked clone environment there was no impact. Any existing desktop connections or new connections to existing desktops should observe little or no disruption of service.