vSphere 6.5, Important items 2 months after Official Release

What you should know now that vSphere 6.5 has been out a couple of months...

UPDATE: It figures, as soon as I click Publish on this article, I found out that Veeam released Update 1 for all their 9.5 products on 1/24/2017 making them all compatible with vSphere 6.5!

Well, vSphere 6.5 has brought hundreds of major and minors updates to the venerable virtualization platform from VMware.   Many of the changes are significant.

Realistically, for the small to medium vSphere organization, many of these changes will go unnoticed or unused.  But, there are goodies that need to be considered by all.

The most significant change has to be the re-energized focus on moving to the VCSA or vCenter Server Appliance.  In vSphere 6.5, this appliance now runs on VMware's own Photon OS, a Linux distro that they own & maintain in-house.  The first major advantage this appliance has over the previous ones is speed.  Having eschewed SUSE Linux provides VMware the opportunity to tune & tweak their Linux to provide the best performance possible for their specific needs.

The VCSA 6.5 gains significant speed advantages over its predecessor as well as the current Windows based vCenter Server 6.5, just because of this change to the underlying appliance OS.

As with the previous appliance in 6.0, VMware has parity with sizing and maximums between the VCSA 6.5 & the Windows vCenter Server 6.5.  A monumental change comes in the fact that the current VCSA 6.5 ONLY supports the embedded PostgreSQL database from VMware.  They no longer support an external Oracle database for vCenter!  

A major focus for VCSA 6.5, following the initial introduction of vSphere 6.0 Update 2M, is the ability to migrate from previous versions of Windows vCenter Server and VCSA to the current version, pulling in the database information from any of those previous platforms.  This current design obviates the need for an external database from previous designs.

This practice of embedding the database is followed up with the brand new inclusion of Update Manager 6.5 as part of the appliance as well.  In other words, the new VCSA 6.5 is a complete solution for vCenter and Update Manager and their databases in a single VM.  That design allows for the other major feature introduced in 6.5 of High Availability for the VCSA (VCHA) without the need to use a host based HA cluster solution.  No more worries about losing your vCenter.  There is a 2nd VCSA copy that is passive and up to date with a 3rd witness VM, all of which are cloned from the original.

The final VCSA 6.5 addition that benefits all organizations, is the ability to backup the appliance from within the appliance, no dependency on 3rd party or VDP backup solutions... more on that in another post.

So what do we need to be wary of before upgrading to the latest and greatest vSphere?

Compatibility of 3rd party products is the most important for many organizations.  Many are using Veeam Backup & Replication, which in its current (1/25/2017) version of 9.5 has not released support for vSphere 6.5 yet.  It is rumored on their site to be forthcoming in an Update 1 release for 9.5.  For many, that's the deal breaker for now, but all your linked or dependent 3rd party apps need to be checked.

Currently, NSX is not supported on vSphere 6.5 either.  If you are currently running a 6.x version of Horizon View, that needs to be updated to at least 7.0.  So make sure you carefully plan your upgrades to all 3rd party products designed to support vSphere 6.5 before you jump to upgrade your base virtualization platform...

Exchange 2016 and Windows Server 2016

I am currently updating our Exchange 2013/2016 Ultimate Bootcamp and while searching the web have come up with a few neat things to add to the course.  One of the things I have been looking at is of course the release of Windows Server 2016 and compatibility features of Exchange 2016. 

As of right now Exchange 2016 is not supported to run on Windows Server 2016.  That is no surprise, but here is what I found interesting.  Exchange 2016 is not supported if you have Windows Server 2016 Domain Controllers.

Here is a list of supported OS's and Supported Domain environments at the time of this posting.





Will there be support added in the future.  Probably, but not sure when. 

Moving the VMware vCenter Server 4.x/5.x/6.0.x SQL database

A simple necessary task that isn’t so simple.  So the scenario plays out like this.  Customer is running vCenter, Update Manager and SRM databases on a SQL server that is running Windows 2003 with SQL 2005 – not extremely uncommon.  With the impending end of Windows 2003 looming we decide to migrate to Windows 2008 R2 and SQL 2008 R2.  

For the most part we followed KB 7960893 from VMware.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=7960893

Now this KB will get you close, which is nice.  And what does close mean.  It means that we had databases up and running on the SQL server.  It means that we had ODBC connections that were connected and tested OK.  And then….It means that we couldn’t get the service to start – WTF.

So let’s look at the process and the final resolution.  First off it’s a pretty common task and I was doing this for a customer in their DR site, but it is something that everyone will run into at some time. 

Several steps in the process.

1.       Backup the databases on the old SQL server.  Simple enough go into SQL management studio right click the database and back it up.  Stop all of the VMware services on vCenter and SRM first.
2.       Copy the databases over to the new server – Really easy.
3.       Restore the databases to the new SQL server.
4.       Yeah this next step is a little harder.  Permissions.  We had to set the proper permissions.  The customer wanted to use a different service account and instead of having separate accounts for vCenter, UM, and SRM they wanted to use one account for all of them.  Not a huge deal, so whatever, let’s make it happen.  We used a local account in SQL with SQL server authentication.  We then granted dbo permissions to the vCenter, UM, and SRM databases.  You also have to give it dbo for the msdb database.  OK, all of this sounds pretty straightforward so far.
5.       Edit the vcdb.properties file to change the server name – Really easy.
6.       I didn’t update the SQL server agents just yet, because I didn’t care about performance statistics.
7.       Go to ODBC and ODBC32 on the vCenter server and change them to point to the new server and the correct database using the proper username and password.  Then test it.  BOOM, everything worked.  Start the vCenter and UM services up.  And…It failed.  WTF.

Troubleshooting Time

8.       So to do a little troubleshooting I looked in event viewer, got a whole bunch of nothing. 
9.       So what next?  I decided to start the vCenter service using the executable in standalone mode.  Open an administrative command prompt and the run vcdb –s.  Hmmm.  Interesting error.  Login failure and it was related to a DSN, which is telling me SQL login failure.  But the ODBC connections all tested positive.
10.   So I did a registry search and each of the 3 databases all have a section with a DB entry in it.  In that section I looked in there, and it still had the old entry for the name in there.  In the picture it is entry 2.  So I changed it.  DANG IT, the service still wouldn’t start.
11.   Well the line right below the username in the registry is the password hash for the old username, in the picture it is entry 3.  To change that password hash you have to go back to that administrative command prompt and run the vcdb –p command and then enter the new password twice.  And now.  BOOM the service starts.  WOO HOO.

12.   So now let’s start the Update Manager service.  It fails.  WTF.

13.   This was pretty easy.  I ran the Update Manager Utility and change the database in there and it started up fine after that.  Update Manager Utility is mentioned in KB 2011327, and it is located under Program Files (x86), because it is still a 32bit program, also have to update the ODBC32 as well.  So start the service and it worked.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2011327






14.   OK so now 2 of the 3 databases are connected and running.  Go to the SRM server and start that service up.  DANG IT, no go.  On to troubleshoot that.

15.   Went through several troubleshooting steps, and actually worked with VMware technical support, but since nothing was really set up in SRM we just did a full uninstall/reinstall.  It wasn’t pretty and if there had been any data on there I would have definitely taken the time to get it working, but…I didn’t so this was the easy way out.

So in a nutshell, it wasn’t as easy as I thought it would be.  But it is done, consulting is never quite as easy as it seems, but I still enjoy it.