Upgrading to vSphere 5.1 has been a bit of a hot topic ever since it became a GA product in 2012. The problems some customers have experienced during the upgrade process to vSphere 5.1 have been well documented and VMware certainly received a lot of feedback which was taken on board. But many upgrades still went through without any major dramas at all. I completed a couple of small scale upgrades without any problem just after the GA. The real trouble was when you started to try and integrate into larger scale and more complex environments with more complex requirements. So is now the time to upgrade if you haven’t already?

The short answer is yes. VMware has released vSphere 5.1 Update 1 (and an additional patch) and vCenter 5.1 Update 1A. These updates provide fixes to the majority of problems that were experienced with the GA release. Now that this release is out I think it’s a good time to upgrade if you haven’t already. You can read the release notes here for a full list of what is included. If you need a reminder of what’s new and improved in vSphere 5.1 and why you should move to it you can check out the What’s New in vSphere 5.1 document.

If you do choose to upgrade I recommend that you consider the best options for deployment of Single Sign-on and keep your architecture as simple as possible. There are good reasons to split out Single Sign-on from the vCenter Server in some cases, such as if you have multiple vCenters. I would recommend keeping the other services such as Inventory Service on the vCenter Server itself. If you need high availability configurations in addition to what is provided by vSphere HA for vCenter and SSO you should choose to use vCenter Server Heartbeat. If you don’t already have vCenter as a virtual machine running out of a Management Cluster then now is the perfect time to introduce this best practice to your architecture. If you want to use Linked-mode then you will need to configure a multi-site SSO configuration and I would recommend that you test it in a test environment before implementing it in production.

Upgrading from a previous version of vSphere to 5.1 really isn’t a minor upgrade as it requires an architectural shift due to the introduction of SSO. This requires some planning and preparations in order to be successful. But this is the ideal opportunity to review your architecture and your designs and make sure they will support your requirements for the next 3 to 5 years. It’s also the ideal time to start designing an architecture that will support Monster VM’s. In the long run SSO improves security and integration for the vCloud Suite and will make it easier to administer. Future upgrades should also be much less onerous.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I’ve been getting feedback and questions from a number of different places of people wanting to disable Single Sign-on in vSphere 5.1 for various reasons (with vCenter). This is mainly due to difficulties around implementation of SSO in combination with other VMware solutions, such as VMware View, vCloud Director. My response to the questions is very simple. DON’T DO IT! At least not with vCenter itself. vSphere 5.1 and vCenter was not designed to run without SSO and this is definitely not supported and will likely result in a broken environment. This brief article will give you some tips on how you can be successful with SSO.

Firstly some reference material you should read:

VMware KB; vCenter Single Sign-on FAQ: Q: Can I disable SSO and revert to the old method of authentication in vCenter Server? A: NO.

VMware KB: Troubleshooting Issues with Single Sign-on in a VMware View Environment

VMware vCenter Blog: vCenter Single Sign-on Deployment Options

VMware vCenter Blog: vCenter Single Sign-on Availability

vSphere 5.1 Gotcha with Single Sign On (SSO)

vSphere 5.1 Generally Available – Important Upgrade Considerations

VMware KB: Backup and Restore of vCenter Single Sign-on Configuration

VMware Support Insider: SSO Best Practices and KB’s

Tips for Single Sign-on Success

1. Keep it simple. Put SSO on the vCenter if you have a single vCenter. The resource consumption is minimal and it is easier to protect and manage. If you have a multi-vCenter environment consider putting SSO on a separate standalone VM, potentially protected with vCenter Server Heartbeat, else just use vSphere HA. For most environments vSphere HA will be sufficient for availability requirements. Only use a multi-site configuration where it is absolutely essential and if necessary get VMware Support and PSO advice.

2. Read the vCenter Single Sign-on FAQ and references above.

3.  Do not cluster the vCenter Single Sign-on Database, Database clustering isn’t supported and won’t work (instead of sometimes where it isn’t supported but does work). Both MS SQL deployed on a cluster and Oracle RAC are not supported at the moment for vCenter Single Sign-on. You can protect the SSO Database by using vSphere HA or vCenter Server Heartbeat. As the DB is small and not very resource intensive you could have it on the same system as SSO itself.

4. Make sure you’re running the latest version of vCenter and Single Sign-on. A lot of enhancements and bug fixes have been provided in vSphere / vCenter 5.1b.

5. Test your deployment of vCenter Single Sign-on thoroughly in your lab or test environment first. Make sure you are specifying the correct Windows AD DN and credentials. Be aware of how SSO works in a multi-domain / multi-forest environment. It would be a good idea to maintain a separate lab or sandpit from your production vSphere environment for testing purposes (doesn’t have to be big at all).

Where can you disable SSO? 

You may  disable SSO integration from vCloud Director. SSO is only used for vCloud administrator authentication, not tenant authentication. If you already have a management AD for vCloud Director authentication then SSO integration is optional. If SSO authentication is used client devices will need access to the SSO system and this would normally be blocked by firewalls. This may complicate the solution. Be aware though that (from what I understand) if you disable SSO you won’t be able to use SAML. So this should not be done lightly, and in any case should be thoroughly tested.

Final Word

Don’t disable SSO in vCenter / vSphere 5.1. Keep it simple. That way you’ll have less problems and you’ll benefit from the integration that SSO provides now and in the future. As always feedback is appreciated. If for some reason you want to not use SSO for vCenter right now the only supported method is to stick with vCenter / vSphere 5.0 U2. If you are on an earlier versions of vSphere than 5.0 I would strongly recommend you consider upgrading to 5.0 U2, which includes great performance and functionality enhancements.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Recently I wrote about Updating CA SSL Certificates in vSphere 5.1 which applied to the Windows installable version of the vCenter 5.1 and it’s supporting components including SSO. VMware has now also released the instructions to update the CA SSL certificates in the vSphere 5.1 vCenter Virtual Appliance.

While there are a total of 136 steps in the process to update the CA SSL Certificates in the Windows vCenter 5.1 there are only 81 steps to update it in the vSphere 5.1 vCenter Virtual Appliance. But note that these steps do not include update manager. I will include the link below to the KB regarding update manager also.

Here are the KB articles required to update the vSphere 5.1 vCenter Virtual Appliance and Update Manager.

Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 – http://kb.vmware.com/kb/2036744

Configuring CA signed SSL certificates for vSphere Update Manager in vCenter 5.1 – http://kb.vmware.com/kb/2037581

It was another great team effort across the globe within VMware to put these instructions together and test them. Hopefully you find this information useful.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Over the past few weeks I have been working behind the scenes with a team of people at VMware spread around the globe on the process to successfully change out the self-signed certificates in vSphere 5.1. With the introduction of Single Sign-On in vSphere 5.1 the process is somewhat more complicated than vSphere 5 (ok quite a lot more complicated). But now I’m able to bring you some of the solutions you’ve all been waiting for.

This work covers vCenter, and all the related core components such as SSO, Inventory Service, Update Manager etc. The great news is that this work has resulted in KB’s that I and a number of others have tested and verified to work with vSphere 5.1 GA for the Windows installable version of vCenter. There are also updates to some previously released KB’s for vSphere 5.0. These processes will also work with the recently released patches to vCenter. The KB articles for the vCenter Virtual Appliance edition will also be published shortly and I will update this article when they are available.

Below are the links to all of the articles and a note with regard to Update Manager. I want to say a massive thank you to all of the people at VMware that made this happen. It was a big team effort. I’m glad I could make a contribution to the effort.  I will be making sure the process is automated for you as part of the vCert Manager project that I’m working on. My goal would be to automate both the Windows Installable and Virtual Appliance editions for vSphere 5.1.

Note you should start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1.

VMware has also put out a blog article on these KB’s titled Implementing CA Signed SSL Certificates with vSphere 5.1.

Note: I have found a problem with Update Manager when vCenter system is an all in one configuration with everything on the same VM and using a local MS SQL Server database. Update Manager will not be able to log into or register with vCenter when the SSL certificates have been changed. This prevents you from updating the SSL certs for Update Manager and Update Manager may no longer work. This does not appear to occur when the MS SQL Server database is remote. I have not tested this with a local Oracle or other supported local database. I am continuing to work with VMware on this issue and will update this article when it is resolved. In the meantime I would recommend placing the databases for vCenter and it’s other core components on a separate VM, even in small environments.

Final Word

Although changing out the self-signed SSL Certificates is not simple, and is very time consuming to do manually, the above articles make it possible and give you a tested and verified process. I will be automating the processes to take this pain away as part of the vCert Manager project. In the meantime I would recommend you start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1 and work your way through the rest. I hope you get a lot of value out of these articles and the effort that the team has put in. As always your feedback is appreciated.

Derek Seaman has put together a great series of articles on VMware vCenter 5.1 Installation that includes coverage of SSL certificates. I would highly recommend you check it out. Derek has made a great contribution to the process for SSL Certificate Replacement in vSphere 5.1.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

To be honest this is more of a PEBKAC (Problem Exists Between Keyboard and Chair) issue on my part. I was doing an upgrade from vSphere 4.1 to vSphere 5.1 and in the process upgrading vCenter (Simple Install). After the upgrade had completed successfully I logged in to the vSphere Web Client as the admin@system-domain user (who is the admin for Single Sign On). To my horror I could not see any vCenter objects registered and couldn’t access vCenter. After a little head scratching I remembered why.

This is by design. This is a measure to ensure separation of duties between authentication admin and virtualization admin for security reasons. The admin@system-domain user doesn’t have any access or authority to vCenter. So if you wish to use an SSO user to access vCenter you should set up a separate account and then log into vSphere Web Client or vSphere Client using a vCenter administrator and grant permission to the newly created SSO user (not the admin user). You are not prompted or warned of this if you do a simple install. However if you’re doing a split install (each component installed individually) you will be prompted to select who you’d like the vCenter Administrator to be. This is covered in the vSphere 5.1 Installation and Setup Guide – see How vCenter Single Sign On Deployment Scenarios Affect Log In Behavior.

While I was going through this process I also ran into vCenter Single Sign On installer reports: Error 29155. Identity source discovery error (2034374), which is one of the errors that I spoke about in my article vSphere 5.1 Generally Available – Important Upgrade Considerations. When you run into this error you will have to sign into vSphere Web Client using the admin@system-domain user and manually register your AD domain. Make sure that when you’re specifying the distinguished name for users and groups that you do it correctly. For example, OU=Users,DC=CORP,DC=DOMAIN,DC=COM, OU=Groups,DC=CORP,DC=DOMAIN,DC=COM. It is not case sensitive and note that specifying the OU is optional (Thanks Erik Bussink for the reminder). However if you don’t specify the OU there may be a performance impact as the searches will traverse the entire directory. I would recommend narrowing it down to an OU if possible. Once you’ve configured your AD correctly and run a test connection which is successful you should consider changing the order of the default domains and making the AD first.

Be aware that if you have hardened your environment and removed any local users on the vCenter Server from being vCenter Admins you could easily get locked out of vCenter if you are unable to communicate with AD (or configure it incorrectly in SSO). This is because no SSO users will have rights to vCenter by default as explained above. Also be aware that if SSO is installed on a different server from vCenter that it will not have any knowledge of the local accounts on the vCenter Server that were granted access. This could be a major problem for you if you have put your Domain Groups into the Local Groups on your vCenter Server and then assigned permissions from there (all local group and user permissions have been removed remember). The first thing I’d recommend when you get SSO working is to create a new SSO user to use in case of emergencies and troubleshooting. Carefully plan and execute your upgrade and you’ll avoid these issues.

Because SSO is using token based authorization (based on RSA technology) time sync in your environment will be critical. If your vSphere Hosts do not have consistent time, or your SSO / vCenter Server and other components don’t have consistent time you will run into trouble. You could find yourself being locked out of the environment, or services will failing to start. If something weird starts happening that you don’t expect you might want to look at all the system clocks and ensure they are in sync.

Good luck and I hope you are successful with your upgrade process.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.