Here is a short „how-to“ if you want to move your vCenter Server 5.5/6.0 and Update Manager SQL database to a new SQL database server.

There is a KB article from VMware covering this topic (KB 7960893 – Moving the VMware vCenter Server 4.x/5.x/6.0.x SQL database).

In this blogpost I have added some sidenotes from my experience and you can find some screenshots, too.



1. Stop Services:

Stop the following services on your „old“ vCenter Database Server:

  • VMware Update Manager
  • VMware VirtualCenter Server
  • VMware VirtualCenter Management Webservices

2. Export SQL Agent rollup jobs:

vCenter Server offloads some maintenance tasks to the database.

If you move your vCenter database to a new server you have to take care that you recreate these jobs. The easiest way is to export them from your „old“ server and import them to the new one.

Export the following jobs (Microsoft SQL Server Management Studio):


To export them into a .sql file just right click the jobname, select „Script Job as“ – „Create to“ and „New Query Editor Window“:


Right click the SQLQuery.sql and select „Save SQLQuery.sql“ to save the file:


Repeat this for every job and remember the folder where you save the .sql files.

3. Perform a database backup:

Now you have to backup your vCenter Server database and your Update Manager database:

  • open your MS SQL Server Management Studio
  • right click the database you want to backup
  • select „Tasks“ – „Back up…“
  • select a destination and wait until the backup has successfully finished

4. Copy data to the new DB Server:

Copy the database backup files and the SQL Agent rollup jobs to the new database server…

5. Database restore:

  • open the MS SQL Server Management Studio and connect to your new DB Server
  • right click „Database“ and select „Restore Database…“
  • select „Device“ and enter the path to your .bak file
  • click OK to restore the database
  • perform these steps for your Update Manager DB and your vCenter DB

6. Import SQL Agent rollup jobs:

  • doubleclick the .sql files and execute them
  • check if all jobs are available (see screenshot Step 2)

7. Update the file:

  • connect to your vCenter Server
  • update the file with the new SQL server

You can find the file at the following location:

vCenter Server 5.x:

Windows 2008 – C:\ProgramData\VMware\VMware VirtualCenter
other Windows versions – C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\

vCenter Server 6.x:


8. Update the ODBC connections:

The last task is to update the ODBC System Data Sources at your vCenter Server:

32bit ODBC: C:\Windows\System32\odbcad32.exe
64bit ODBC: C:\Windows\SysWOW64\odbcad32.exe

  • select „System DSN“
  • select the System Data Source (eg. for vCenter)
  • click „Configure“
  • change the SQL Server name
  • follow the wizzard (eg. enter the password to connect to the SQL server)
  • test the Connection
  • repeat these steps for both ODBC connections (Update Manager and vCenter Server)

9. Start the Services:

Now it is time to start your VMware VirtualCenter Server and VMware Update Manager services.

If you made no mistakes your vCenter should now access the databases on your new MS SQL Server.

Update 26.11.2015: This issue is resolved in VMware ESXi 6.0 patch ESXi600-201511001. For more information, see VMware ESXi 6.0, Patch Release ESXi600-201511001 (2137545).

Not long ago VMware fixed a CBT bug in vSphere ESXi 6.0 (fixed since build 2715440 – read KB 2114076).

Today VMware posted a KB article describing a new CBT issue with ESXi 6.0:

Backups with Changed Block Tracking can return incorrect changed sectors in ESXi 6.0 (2136854)

So if you use vSphere ESXi 6.0 and a backup solution that is relying on CBT (changed block tracking) you should take care of this KB article, as your virtual machine backup might be inconsistent. And maybe you know it for sure when you need your backup most.

Here is what VMware writes about the issue:

This issue occurs due to an issue with CBT in the disklib area, this causes the change tracking information of I/Os that occur during snapshot consolidation to be lost. The main backup payload data is never lost and it is always written to the backend device. However, the corresponding change tracking information entries which occur during the consolidation task are missed. Subsequent QueryDiskChangedAreas() calls do not include these missed blocks, hence a backup based on this CBT data is inconsistent.

At the moment there is no real resolution for the issue.

VMware offers three workarounds – but i guess none of them will make you happy:

  • downgrade your ESXi hosts to 5.5 and the virtual hardware from 11 to 10
  • do full virtual machine backups instead of incremental backups
  • shutdown the virtual machines before doing an incremental backup

Nice, isn’t it?

Number one is a lot of work depending on the size of your environment of course. And – above all it means downtime to your virtual machines when you downgrade the virtual hardware.

Number two may be a possibility if you only have to backup a small number of VMs/small amount of data. Otherwise your backup window may be too short and/or you will blow up your backup pool.

Number three: shutdown during incremental  backup = downtime = bad… maybe a workaround for some not so important VMs but definitely not a resolution for the bulk of your VMs.

Hopefully VMware brings a hotfix/resolution for this issue very soon… check back to the KB articles and this blog post and you will not miss any news.

In a branch office I recently had the demand to deploy an OVF template that is stored on the local datastore of an ESXi host.

If you try to deploy the ovf template using the webclient/vSphere Client, you can specify a location accessible from your computer (hard drive, share, CD drive,…) or a URL to the ovf file.

Specifying the path to a local source on your computer is easy: start the „Deploy OVF Template“ wizzard, click „browse“ and select the path to your ovf file:


But how can you identify the path to an ovf file stored on a local ESXi datastore?

Here is the how to:

Open a browser and enter the following address: https://IP_of_ESXi_Host/folder
Probably you will now see a link to „ha-datacenter“:


Select „ha-datacenter“ to get a list of the local datastores:


Now select the datastore and if necessary the folders until you can see the ovf file in your browser:


Copy the URL path to your ovf file displayed in your browser and note the OVF filename itself, too (eg: AAA01.ovf):


In a last step you have to merge the filename (eg. AAA01.ovf) into the URL path:

Now you can use the „Deploy OVF Template“ wizzard to deploy your ovf file from the local ESXi datastore. Just enter the URL from above and follow the wizzard:

URL from example above would be:



Of course you can also use this method to deploy an ovf file stored on the local datastore of another (remote) ESXi host if you want.

The installation fails and you see an internal error 28173 when you install vCenter 5.5 or  vSphere Client 5.5?


To resolve just install .NET Framework 3.5 – this is a Minimum requirement for vCenter 5.x and vSphere Client 5.x.

How to install the .NET Framework 3.5:

  • open the Windows control panel
  • select „Turn Windows Features On or Off“


  • click 4x „next“ button in the wizzard
  • select the .NET Framework 3.5 Features Checkbox


  • click „next“
  • if necessary provide a source for the installation files

When the installation of .NET Framework 3.5 has successfully finished try the vSphere Client or vSphere vCenter installation again.

Now it should work without any 28173 errors.