I have came up with four sessions that I would like to present at VMworld 2013, but I need your help to make it reality. As you know VMworld sessions are chosen based on the community voting, so I need every vote I can get specially when many of the other sessions are done by commercial contributors who got an army of employees and partners who would vote for them. I would appreciate your vote on the sessions you would like to see at VMworld 2013. Please find my sessions information below:

4795 vCenter & Single Sign On 5.1 Best Practices

This session will discuss the various design considerations when architecting the foundation for every solid vSphere 5.1 environment. The introduction of vCenter Single Sign On & the ability to deploy vCenter components across multiple machines in vCenter 5.1 has dramatically changed & added new set of rules to vCenter best practices. This session will help you understand & relate such best practices to your VMware Virtual Infrastructure.

4797 vCenter & vCenter SSO 5.1 best practices.

This session will have open discussions for the various design considerations when architecting the foundation for every solid vSphere 5.1 environment. The introduction of vCenter Single Sign On & the ability to deploy vCenter components across multiple machines in vCenter 5.1 has dramatically changed & added new set of rules to vCenter best practices. Further this has raised up the number of questions and concerns around this area lately. This session will help you understand & relate such best practices to your VMware Virtual Infrastructure. Further, it will allow you to get such questions answered by the experts.

4831 Multi-Site vCloud Challenges & Solutions

The idea of Multi-Site vCloud has been gaining interest for global cooperation, though most over look it is challenges and in turn miss the right solution. In this session, I will demonstrate the recommended Multi-Site scenario, it is challenges, & how to over come them.
4816 Knowing Your Apps is Half Way to Success

Carrying out a migration, Consolidation, Virtualization, building Disaster Recovery, or even moving to the Cloud will require a holistic understanding of your APPs. This session will help you discover the type of information you need to collect about your APPs before starting out such transformation effort.

Vote Now: You can vote for my sessions by logging into http://www.vmworld.com/cfp.jspa then find my session and thumb it up. I appreciate every vote that you can help me with, & I promise to do my best to make sure these sessions as beneficial & fun if it make it to this year VMworld.

I have recently been delivering a Virtualization Assessment engagement for an Enterprise customer, where they have benefited of the recently introduced VMware Application Dependency Planner(ADP). I thought many enterprises & consultants out there would be interested to find out the what, why, when & how they can benefit of this new offering. Below I will try to give a brief of the answers:

What is Application Dependency Planner (ADP)?

VMware Application Dependency Planner is a consulting tool that provides automated, real-time application discovery and dependency mapping to accelerate datacenter migration, precisely plan infrastructure consolidations, and confidently virtualize business critical applications. VMware and partner consultants can use this agentless, non-intrusive, and continuous dependency mapping tool across physical and virtual application infrastructures to quickly gain an understanding of service dependencies with accuracy and efficiency.

Not to confuse it with VMware vCenter Application Discovery Manager (ADM). Where ADM had to be licensed by the customer to use it & permanently run it to keep an updated Application Dependency Mapping, ADP is a consulting tool that VMware Consultants and partners can use to help customer prepare for any Data Center transformation being Virtualization, Cloud Computing, SDDC, or even a disaster recovery. The customer does not have to purchase an ADP license, & the consultant will deliver the Application Dependency mapping for the customer applications as a service as a part of consulting engagement (Ex: Virtualization Assessment Engagements offered by VMware & its partners). This should give customers quicker results at lower costs, & help them succeed with their Data Center transformation.

Why do I need to use VMware Application Dependency Planner (ADP)?

Having depth knowledge of the applications in your environment is critical to the success of any Data Center transformation effort being Virtualization, Cloud Computing, SDDC, or even just building your Disaster Recovery. You will need to know your Applications SLAs, Required Capacity, Security Constrains, Application Dependency, & more. While most of these requirements and knowledge can be collected by conducting interviews across the SMEs and business owners of the applications, application dependency mapping has proved to be more challenging due to the dynamic nature of application dependance as well the lack of complete application dependency knowledge in most enterprises.

While being challenging, Application dependency mapping knowledge is critical prior to any Data Center transformation effort to avoid a catastrophic failure. Imagine the case where you build a disaster recovery solution, & when the time come to use it you discover that your most critical business application is not coming up as no one has thought of one of its forgotten about dependency. I am sure that is not a scenario that any of us wish for. Luckily today there is automated tools & consultancy service that can help you with it including VMware Virtualization Assessment Service (Include Capacity Planning & the use of Application Dependency Planner).

When should I consider VMware Virtualization Assessment service?

As mentioned earlier in this post, VMware Virtualization Assessment consist usually of two main parts Capacity Planning & Application Dependency planning where it can be customized to give a more in depth understanding of the customer applications. This make such a service crucial before or while planning for any Data Center Transformation effort being Virtualization,  Moving to the Cloud, SDDC, or even Building a Disaster Recovery.

How to obtain a VMware Application Dependency Planner or VMware Virtualization Assessment Service?

If you are a customer then your best bet is to contact your VMware Sales Rep/SE/TAM, & as a start you might want to check the VMware Virtualization Assessment Service Datasheet that can be found at: Virtualization Assessment Data Sheet

How to install & Configure VMware Application Dependency Planner?

If you are a VMware Consultant, then the tool can be downloaded from the Savo pages though partners can get it from the partners portal. Below are the steps to install and configure VMware ADP to scan Application Dependency for an environment running vSphere & where you will deploy multiple collectors and a Separate aggregator.

Deploy ADP DB:

1.  First deploy the Postgres DB Appliance using the supplied OVF (at least 80GB disk available for DB & Thick provisioning it with lazy zeroed is recommended)
2. Power on the ADP DB.
3. When the Postgres DB appliance first powered on a password is randomly generated for the user root.  To change it use /opt/aurora/sbin/set_password
4. Change the PermitRootLogin to yes in /etc/ssh/sshd_config
5. Enable time Sync using: /usr/bin/vmware-toolbox-cmd timesync enable
6.  Logout

Deploy ADP Aggregator:

1. Deploy ADP Aggregator Virtual Appliance using the downloaded OVF(it takes about 80GB as well).
2. After booting the ADP Aggregator choose yes to run the setup
3. Change the Password
4. provide IP Information
5. Setup the time zone
6. Use an NTP for time sync option when asked to sync time
7. When rebooting the ADP Aggregator(This happen automatically as a part of the setup) it will take a while to reboot it 10-15 minutes
8. Choose yes to setup the appliance roles, Choose installation type, Then enter the DB IP & Password (Take several minutes to complete). In our Scenario, we will choose Aggregator with Separate Postgress DB.
9. Login again with the root user
10. Browse to /home/nlayers/Seneca/tools using: cd /home/nlayers/Seneca/tools
11. Run the following command to configure the Postgress DB # ./update_postgress_configurations.sh  (This command is run on the Aggregator VA as well).
12. If you get asked for the DB password again and installation stuck at that point, this means you have entered it incorrectly and you will need to re-do the role installation. Entering the password again does not work. You can use the role_setup command to re-setup the appliance role.
13. To complete the DB Configuration run the following commands on the ADP Aggregator VA

su – nlayers

cd /home/nlayers/Seneca/db_scripts/postgress/

./db_create.sh prod

./db_create.sh dev

14-  Use the below commands to start the service of the ADP Aggregator Appliance:

su – root

adm_control.pl — restart all            (This restart take several minutes)

You have just completed the ADP Aggregator installation; now let’s configure the Aggregator before proceeding with installing the collectors.

1. Get the ADP License Key by opening /home/nlayers/license-key.txt file on the ADP Aggregator. Note it down or copy it somewhere as you will need it in further steps.
2. Access your ADP Aggregator page using IP/URL from IE(The only supported browser at the moment)
3. Login using the default user name and password: admin/123456
4. As soon you are login to the ADP aggregator you will be hitting the license properties page. You will need to hit the upload a new license then enter the license key obtained in step one before you can do anything at the web interface.
5. Run the self test to ensure the system is installed correctly by going to Manage => System => Start Self Test   (Make sure all component has a result of OK in green).

      Installing the Collector:

1. At every ESXi host where you are planning to deploy a collector you will need to create a port group with Promiscuous mode set to accept and that where you will connect your ADP Collector Discovery port to.
2. Deploy the collector OVF to every host you need to collect Data from & make sure you connect the Network ports to the right network.
3. Power on the collectors & go through the setup where you will need to provide IP configurations as well the IP of the aggregator.

       Configuring the Aggregator:

1. Configure the IP range and scope of Servers to discover from: Manage => Passive Discovery.
2. Initialize the Discovery by going to Manage => System => Restart Discovery
3. Now you are ready should start seeing data popping up in your dashboard.

Hope you find this helpful.

With the release of vSphere 5.1 certificates started to play a much more vital role, where having invalid certificates in your environment is not an option anymore as it could break the operation of your environment as well forbid you from logging in. This change has been done to increase the security of your Virtual Infrastructure Management Components (vCenter Service, Inventory Services, SSO, Web Client, vCO, Update Manager, & vCenter Log Browser) & to compact the possibilities of man in the middle attacks. This change has brought a lot of challenges to many VMware customers who had invalid and expired certificates in their environment without even noticing it. The tedious process of replacing any of these certificates have not been a pleasure work for many, the good news is that VMware has just released vCenter Certificate Automation Tool 1.0 to streamline the process & release much of that pain.

VMware has just announced the general availability of vCenter Certificate Automation Tool 1.0. This tool provides an automated mechanism to replace certificates in the following components of the vCenter management platform:

• vCenter Server
• vCenter Single Sign On
• vCenter Inventory Service
• vSphere Web Client
• vCenter Log Browser
• vCenter Orchestrator (VCO)
• vSphere Update Manager (VUM)

The tool can be downloaded for free from: https://my.vmware.com/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/5_1#drivers_tools

Before you jump on the tool, please make sure you read the instructions on the requirements for using the tool, the steps to use it, as well the limitations & known issues to avoid any trouble. You can find all that info put nicely for you at: http://kb.vmware.com/kb/2041600

This tool is fully supported by VMware as well & I am sure it will be quite useful to many of VMware customers. This is the first step in improving certificates management in vSphere environment, keep tuned as it will just improve as we go.

Yop, it is that time of the year again where all of us are looking for a way to get free VMworld Passes. Below is not one opportunity, but two of them & I will update it as soon I hear of more.

1- VMworld Calls for Papers: As with every year VMware is calling Employees, Partners, Alliance, Customers & everyone interested in presenting at VMware to  submit their requests before April 12, 2013 for consideration. If your paper  is accepted, you will be offered to present and a free pass to VMworld. Check out the following link for more details : https://www.vmworld.com/cfp.jspa

2- Veeam VMworld 2013 Pass Drawing: All you need to participate for a chance to win a VMworld 2013 pass from Veeam is to register for their VMworld 2013 Pass Drawing at: FREE full pass to VMworld 2013 by Veeam.

Good luck to everyone! & hope more vendors will copy Veeam initiative and offer more chances for Free VMworld Passes.

Since vCenter Single Sign On was introduced in vSphere 5.1, many questions have been rising around it. There seems to be a very limited amount of resources out there that document best practices related to vCenter Single Sign On, which is the reason for me to develop this post where I will try to combine as many best practices and answers related to vCenter 5.1 Single Sign On as possible.

I have been one of the lucky consultants who has already got to design/implement vSphere 5.1 for quite few enterprise customers where I have got to debate and drive best practices that I used across those implementations. I am sharing them here where others can benefit from them as well to allow a room for others to debate them and contribute their feedback.

Where to install vCenter Single Sign On (Physical vs Virtual)?

Just as the recommendations have always been for vCenter using virtual machine(s) is the best practice to save on cost and benefit of the availability features built in vSphere, that is no difference in vSphere 5.1. You can host all vCenter 5.1 components including SSO on virtual or physical machine, where virtual machine is the recommended practice due to the same reason mentioned earlier. Further, implementing vCenter 5.1 components including Single Sign On in a virtual machine will not limit its scalability by any mean and it still can deliver up to vCenter current maximums of 10,000VMs & 1,000 hosts.

Where to install vCenter Single Sign On (Combine it with vCenter Service & Inventory Service or on its own VM)?

As Single Sign On has became a mandatory requirement when installing vCenter 5.1, & as the option of breaking out the different vCenter components across multiple machines was introduced in vSphere 5.1 this has became the most vCenter Single Sign On related question. Although I titled this article as vCenter Single Sign On best practices, I would like to break in at this question and cover when to combine and when not to combine vCenter Service, vCenter Inventory Service, & SSO.

vCenter Inventory Service: vCenter Inventory Service can be resource intensive at larger environments especially ones that is approaching the 10,000VM/1000hosts vCenter limit. From scalability perspective, you will want to move the inventory service to a separate VM from the one running the vCenter service in environment approaching the vCenter limit (No exact number provided, but I will say anything larger than 8,000VMs/800hosts will fall into that category). In most other environments (>90% of the time), it will make much more sense to keep it running with the vCenter Service on the same VM.

vCenter Single Sign On: Unlike vCenter Inventory Service, SSO is a very light service that is not intense on resources even for the largest environment out there, which leads to scalability not being a concern when combining it with vCenter Service on the same VM.

On the other hand, you will need to decide on whether to place Single Sign On on the same VM as your vCenter service or not based on the importance of its availability & how are you planning to protect it. If your environment is made up of a single vCenter instance & you are quite sure that you will not grow or ever have a reason to have a second vCenter or other service like vCOPs or vCD sharing that same Single Sign On Instance then it is safe to host SSO on the same VM hosting the other vCenter Services. In this scenario, your SSO is only used for a single vCenter instance and it does not matter much if it goes down with it.

On the other hand, if you are having or planning to multiple vCenters in your environment, the importance of SSO is now beyond the importance of any single vCenter as losing it means you can not access any of the other vCenters. Imagine the scenario where you have to carry out maintenance on the vCenter VM hosting your SSO, you will not be only affecting access to that vCenter but every other vCenter & tool that is dependent on that SSO instance. For that in such a case when the availability of SSO is beyond affecting just a single vCenter then you will want to have it on a separate VM and make sure its well protected.

Which vCenter Single Sign On Deployment Mode should I use in my environment?

Before I go through which vCenter Single Sign On Deployment Mode to use in your environment & why, lets recall the vCenter Single Sign On Deployment modes definition as stated in vSphere 5.1 Documentation Center:

Simple mode:  installs vCenter Single Sign On, vCenter Inventory Service, and vCenter Server together on a single host machine using the vCenter Server Simple Install option. This option is appropriate for small deployments.

Basic mode: installs a standalone version of vCenter Single Sign-On. Multiple vCenter Server and Inventory Service instances can point to it. If the Single Sign-On server or the virtual machine hosting the server fails, administrators cannot access vCenter Server, but ESXi hosts continue to function normally. Multiple Active Directory and OpenLDAP instances can be added as identity sources.

High Availability Cluster: Cluster mode installs two or more vCenter Single Sign-On instances in high availability mode. All instances use the same database and point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, will see the primary Single Sign-On instance.

Multisite mode: is designed for deployments with multiple physical locations. Installing a Single Sign-On instance at each site allows fast access to local authentication-related services. Each Single Sign-On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups. In each datacenter, you can install Single Sign-On in standalone or clustered mode, pointing to the identity sources in that location.

Now that we have covered the different SSO deployment modes, let’s discuss which one you should use. The answer in its most diplomatic forms “It depends”. Different modes are used in different scenarios, though below I will talk about the use cases of each:

Simple Mode: This one should only be used for smaller deployments where having all the components on a single VM will not affect their scalability and availability requirements. The next question, I can see running in many people heads is what being regarded a smaller deployment. I have not seen any official statement on this, but it seems 10-25hosts/100-250VMs is where most of the answers I were getting. Something to remember in basic mode, you will be forced to install all your components on a single VM and your SSO availability will be tight to that vCenter instance.

Basic mode: While Basic mode allows you to combine vCenter Service, vCenter Inventory Service, & Single Sign On on the same VM, unlike the Simple Mode it will allow you as well to spread these services across multiple VMs when required for scalability or availability reasons. If vSphere HA or vCenter Heartbeat is your preferred method for protecting your SSO, and you are not planning to use the Multisite mode then Basic mode might be the right deployment mode for you. Unlike Simple mode, Basic mode fit organizations of all sizes and not limited for smaller deployments.

High Availability Cluster: This is my preferred method of deployment (When obtaining vCenter Heartbeat is not an option), even if all you are planning to deploy initially is a single SSO VM, using this method will give you the chance to cluster your SSO without having to re-build it in the future.

Note: SSO HA provides limited availability, The database is a single point of failure (no cluster support) and the administration of SSO unavailable when failed over.  vCenter Heartbeat provide better protection and with a simplified configuration of SSO. As you can see vCenter Heartbeat is worth its tag price if you can stretch your budget a bit. 

Multisite mode: The only time I would recommend using multisite mode at the moment is if you are planning to use vCenter Linked Mode. In case you missed it, vCenters setup in linked mode must be connected to the same vCenter SSO instance where the goal of Multisite mode is to allow you to have a single vCenter SSO instance spanning across two different physical locations where each site will have its own SSO nodes(Single or clustered).  While this sound great in theory, there is few hiccups in there that you should be aware off:

• Multisite mode does not offer any kind off availability across the sites. For example if the SSO server at site A fail while it is setup in a Multisite mode with another SSO server at site B which is working fine, you will still lose access to vCenters dependent on the SSO server in site A. The good news is that you can configure each SSO involved in multisite configuration in High Availability Cluster within the same site to protect against its failure.
• SSO does not currently have any built-in replication to keep the nodes across sites within a Multisite mode in sync, where you will have to script the process of SSO database replication across the sites to achieve such configuration which is required by vCenter Linked mode.

I guess depending on your environment, you will have the choose the deployment mode that fit you best. In my opinion, the safest option and where most medium to large installation will utilize is the Basic mode when vCenter Heartbeat is an option, else High Availability mode even if they set it up with a single SSO node during the initial installation.

Do you recommend vCenter Linked Mode to obtain a single view of your multiple vCenters?

I have recommended vCenter Linked Mode in vSphere 5.1 environment as long all the vCenters involved were on the same site and have LAN like connectivity. I have usually recommended against the Multi-Site(different physical location) vCenter Linked Mode at the moment due to the complexity as well manual work and amount of maintenance required to keep it going in the long run. As I mentioned earlier, setting up vCenter Linked Mode across sites will require you to setup your SSO in a multi-site configuration as well to script a database synchronization between the two sites. Although its currently supported and workable, I am not advising for it unless it is a mandatory requirements. I am confident though this will improve as vCenter SSO evolve.

Can you recommend on sizing for the SSO VM?

KB2021202 has provided a great sizing recommendation for vCenter components & I referred to it consistently when I started working with vSphere 5.1 & I believe you should give it a look. It has actually recommended a minimum of (2vCPU, 3GB of RAM, 2GB of disk) for vCenter Single Sign On VM. In practice, what I have usually used and recommend for the SSO VM size is (2vCPU, 4GB of RAM, 20GB of disk).

 Where Do I install vCenter SSO Database?

This question has been popping up quite often lately. Do I actually install vCenter Single Sign on database with it on the same VM, or on the DB Server hosting my vCenter DB? While both options work pretty well, consider the below recommendations when making your choice:

- If vCenter DB is hosted on the vCenter VM,  & you have decided to host SSO on a separate VM for availability perspective then you should not host your SSO DB next your vCenter DB on that VM. It just does not make sense, as you will be tying your SSO availability again to vCenter and that is the reason you decided to host SSO on a separate VM from vCenter in the first place.

- If you have a production SQL Server setup and maintained by your DBAs and it is not running on your vCenter VM & maintained separately from it then this might be your best place to install your SSO DB as this will give you the advantage of your DBA maintaining & backing up the DB for you.

- If you like to have a self contained SSO server & not being dependent on any external DB or you don’t have a production DB server that is well maintained and centralize, then your best option will be to host your SSO on an SQL Express Database server that get installed on the vCenter Single Sign On VM it self.

 How to size my vCenter Single Sign On DB?

I hear this question a lot as VMware has not published any numbers on the size of the Single Sign On DB beside saying it is small. Actually after digging it a bit, I have found it to be small enough for most customers that sizing for it can almost be ignored. I have to still see a customer who use even close to 100MB of db size for vCenter Single Sign On. That have been said, I would actually keep a capacity of 1GB for the vCenter Single Sign On just to give you a lot of cushions in case you forget to trim your logs or so on, but in general you will not be using much of space for it at all as it only store the below three main items:

1. Identity Source Configurations
2. Users & Groups membership
3. Password Policies for SSO Users.

Will Microsoft SQL Express be sufficient for my vCenter Single Sign On DB?

Unlike vCenter which is limited to support 5 hosts & 50 VM if you are using Microsoft SQL Express to host its DB, SSO can grow to support the maximums of your vCenter 5.1 (10,000VMs/1,000 hosts) while running on Microsoft SQL Express which make it definitely an option specially if you are planning to install the SSO DB on the same VM as your SSO to keep it self contained and ease image backup and restore of it.

 Additional vCenter Single Sign On Resources:

While in this article I have tried to addressed few of the best practice questions that keep popping up in the field, there is quite valuable resources out there that I thought would be useful to point out in here:

1. Preparing the Database for Single Sign On installation
2. vCenter 5.1 Installation(Part 2) – Single Sign On Installation(Step by Step)
3. VMware vSphere 5.1 new vCenter architecture & Single Sign on
4. Frequently Asked Questions: VMware vCenter Single Sign On 5.1
5. vCenter Single Sign-On FAQ (2034918)
6. VMware SSO Blog

Feedback:

I am really interested in hearing your feedback, thoughts, what best practices that should have been on this list and needed to be added. Anything that you agree with or disagree with. Please keep those productive feedback comings so we can improve this list for everyone benefits.

While working with my home vSphere 5.1 lab the other day, I was trying to create a VMFS5 datastores on my local SATA disk. Each time I tried to do that I was just welcomed with the following error:

Call “HostDatastoreSystem.CreateVmfsDatastore” for object “ha-datastoresystem” on ESXi “xxx.xxx.xxx.xxx” failed.

Please note xxx.xxx.xxx.xxx stand for my host IP. To visualize the error below is a screen shot of the error as it has appeared in my home lab

After fuzzing around trying to figure out what happened, I have remembered this particular disk was used by one of my old lab ESXi hosts. As I do all kind of crazy things in my labs, I thought I should try to wipe the disk clean then try to format it with VMFS5 afterward. That has actually solved the problem. This error seems to happen if you have a file system on that LUN/disk that ESXi does not understand, cannot overwrite or if You don’t have a full write access to the disk/LUN(ex: SRM replication target)

Below is how I went about doing it if you are not familiar with the procedure:

Note: In previous versions of ESXi fdisk was your friend in such a situation, though if you try it in vSphere 5.x you will get the following error message:

*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Please use partedUtil ***

I am sure from the above error you got where I am going next, you will need to use partedUtil instead of fdisk to wipe that disk clean so you can use it. Alright, Alright, here is your one line magical command that will wipe that disk clean:

#PartedUtil mklabel /dev/disks/<disk id> msdos

Below is an example of how it looked like in my environment.

#partedUtil mklabel /dev/disks/t10.ATA____WDC_WD5000AK52000UU340___________WD2DWCAYU6597660 msdos

Alright in case you have wondered how did I figured out my disk id, all I had to do to get that info is to run the following command just as demonstrated in the previous screenshot:

#ls /dev/disks

After wiping the LUN/Disk clean, now you should be able to use it to create your new VMFS datastore by adding it through the vSphere client(business as usual). Hope this help someone out there!

It seems there has been quite few articles that try to explain the vCloud Director 5.1 Upgrade Process out there in the blog sphere, but most of them focus on the steps on how to upgrade vCloud Director Cells and the Database. As many of them do quite good job at that, I am not going to re-invent the wheel and will just list few of them through this blog post. Though what seems to me missing of most of these articles is the order to carry out the vCloud Director environment components upgrade process in.

vCloud Director includes quite few moving parts and integrations, so you will need to ensure you upgrade all of these pieces in the correct order to avoid mixing incompatible products versions and wreck your vCloud environment. In such a situation, VMware interoperability matrix is your big friend and can be accessed at: http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?

Alright, Alright, you already know where to find the interoperability matrix, but still scratching your head which product to upgrade first & which one second. Do you upgrade vCenter Chargeback, vCloud Director, vCenter, or vShield first & in what order should you upgrade all of these components involved in your vCloud Solution. In this post, I will document the best order I have came up with, which reduce your downtime to minimum and reduce the risk of you breaking the interoperability matrix.

The approach I usually follow during upgrading a vCloud Director 1.5 environment to vCloud Director 5.1 environment is something I like to call a Top Down Approach. Start from the top of the tree and go down as you complete the upgrade for the top of the tree products. This usually work pretty well, as products running higher in the chain usually support current release and previous version and the opposite is not true. For example, vCD 5.1 support both vCenter 5.1 & vCenter 5.0 where vCenter 5.1 is not supported by vCD 1.5. I guess you get the story. Below is the order I usually do my upgrade in:

My Top Down Approach:

1- Upgrade vCenter ChargeBack (Optional & if used)

Alright so if you have vCenter ChargeBack in your vCloud Director environment, which is most likely it will be the first thing you will need to upgrade. While might be surprising, it is the sole truth as older versions of vCenter ChargeBack does not support vCloud Director 5.1 & you will need to at least step up to vCenter ChargeBack 2.5.

2- Upgrade vCloud Director Cells & DB

Now that you have vCenter ChargeBack and other products higher in the chain than vCD upgraded, it is time to update your vCloud Directors Cells & Databases. The upgrade will require a bit of downtime on the vCD side at least equivalent to the time it required to update the vCD DB. The upgrade order of your Cells and DB depend on if you are having a Load Balancer in front of your vCD or not and how critical is downtime to you. Below is a highlight of both scenario:

No Load Balancer:

- Disable user access to vCloud Director Cells.

- Quiesce all vCD cells in the server group and shut down vCloud Director service.

- Upgrade vCloud Director software on all members of the server group.

- Upgrade the vCloud Director database.

- Restart vCloud Director on the upgraded servers.

Load Balancer Scenario:

I would use this method if you have quite few cells in your environment and you have a load balance that balance between them and you require more than one vCD Cell to handle your environment workload. If your full environment workload can be handled by a single vCD Cell & you only have two vCD Cell in your environment following the extra steps in here will not save you any downtime. Alright so let’s look at the scenario where you have 6 vCD Cells, where your environment require at least 3 vCD Cells to handle the workload. The below give steps highlight of the upgrade steps in such a scenario:

- Disable user access to three vCloud Director Cells.

- Quiesce the same three vCD cells pointed out in the first step and shut down vCloud Director service on them.

- Upgrade vCloud Director software on those 3 vCD Cells. By the end of this step, your Cells should look like below:

vCD 1 <== Stopped <== Upgraded
vCD 2 <== Stopped <== Upgraded
vCD 3 <== Stopped <== Upgraded
vCD 4 <== Started <== Not Upgraded
vCD 5 <== Started <== Not Upgraded
vCD 6 <== Started  <== Not Upgraded

- After finishing the upgrade of the first three Cells go ahead and stop access to the non upgraded cells, quiesce them, & Stop the service on them. Your Cells will look as follow:

vCD 1 <== Stopped <== Upgraded
vCD 2 <== Stopped <== Upgraded
vCD 3 <== Stopped <== Upgraded
vCD 4 <== Stopped <== Not Upgraded
vCD 5 <== Stopped <== Not Upgraded
vCD 6 <== Stopped  <== Not Upgraded

- Upgrade the vCloud Director database.

- Restart vCloud Director on the upgraded Cells. Now your setup should look like:

vCD 1 <== Started <== Upgraded
vCD 2 <== Started <== Upgraded
vCD 3 <== Started <== Upgraded
vCD 4 <== Stopped <== Not Upgraded
vCD 5 <== Stopped <== Not Upgraded
vCD 6 <== Stopped  <== Not Upgraded

- Upgrade and start the rest of your vCD Cells.

Note: Using the load balancer upgrade approach in this scenario will shorten your downtime by the time it would have taken to upgrade three vCD Cells, though it will not eliminate vCD Downtime required for updating the vCD DB.

3- Upgrade vCNS Manager & Edge Appliances

- Update your vCNS Manager using the update package. Make sure to update to at least 5.1.2 to avoid any bugs with earlier releases especially if you are using VXLANs.

- Update your edge appliances using your upgraded vCNS Manager

4- Upgrade vCenter Orchestrator (Optional & if used)

5- Upgrade vSphere 5.1.

Last but not least, you will need to upgrade your vSphere environment to 5.1 to benefits of new vSphere 5.1 features in your vCD environment. Below is just steps highlights.

- Create DB for SSO
- Install SSO
- Install Web Client & Confirm operation of SSO.

- Install vCenter Inventory Service

- Upgrade vCenter Service

- Upgrade your ESXi hosts

- Upgrade VMFS & vDS if required.

- Upgrade VMware Tools

- Upgrade VMware Hardware.

Note: This upgrade guidance is assuming you are starting with vCD 1.5 & vSphere 5.0. If you are using vSphere 4.x you will need to upgrade to vSphere 5 before following up the steps documented in here.

Hope this help guide some one with the upgrade process.

While installing vCloud Director 5.1 in my home lab, I have faced an odd problem while configuring vCloud Networking and Security 5.1.1 for VXLANs. If you follow VMware Configuration guides for VXLAN or any of the many articles on configuring vCloud Director/vCloud Networking & Security 5.1.1 for VXLAN, it will always mention that as soon you complete the configuration vCloud Networking & Security 5.1.1 will automatically create a dvPort Group that has a name of the format  vxw-vmknicPg-dvs-xx-xx-xx-xx, as well a vmknic interface. Few samples of such instructions can be found at:

http://www.punchingclouds.com/2012/09/09/vcloud-director-5-1-vxlan-configuration/

http://www.kendrickcoleman.com/index.php/Tech-Blog/how-to-configure-vxlan-in-vcloud-director-step-by-step.html

http://www.mikelaverick.com/2012/11/part-23-my-vcloud-journey-journal-creating-vxlan-backed-network-pool/

In my lab I was facing the odd case of the dvPort Group being created, but no vmknic interface what so ever being created. After investigating the situation & a bit of internal research I have discovered that this is due to vCloud Networking and Security 5.1.1 depending on VMware Update Manager to push the VIB to each host to configure it for VXLAN, where in some cases VUM has proved problematic pushing these or a flaky VUM installation could cause such a problem. The good news is that vCloud Networking & Security 5.1.2a has just been released and handle pushing these VIBs differently and does not depend on VUM to do it eliminating all the trouble You can get the new vCloud Networking & Security 5.1.2a at: https://my.vmware.com/group/vmware/info?slug=security_products/vmware_vcloud_networking_and_security/5_1.

If you have upgraded your vCloud Networking & Security to 5.1.2a and that did not fix the problem, then try to follow the below steps which seems to fix the problem in most scenarios:

- Remove the original VXLAN configuration from vCNS.

- Restart the vCNS web service

manager> enable
manager# configure terminal
manager(config)# no web-manager
manager(config)# web-manager

- Re-Add vCenter to vCNS

- Add the VXLAN Configuration again.

This should hopefully get you up and running and now your VXLAN should be green in your vCloud Networking & Security Manager as per the below screenshot from my lab:

For those who want to find out more about what other bugs have been fixed with vCloud Networking & Security 5.1.2, you can check vCNS 5.1.2 release notes at:  http://wwwcontentdev.vmware.com:9998/support/vshield/doc/releasenotes_vshield_512a.html  , where I have include a copy of the release note below for your convenience.

What’s in the Release Notes

The release notes cover the following topics:

• What’s New
• System Requirements and Installation
• Known Issues
• Resolved Issues

What’s New

The vCloud Networking and Security 5.1.2a patch release fixes an issue where vShield Manager needs to be restarted frequently.

System Requirements and Installation

For information about system requirements and installation instructions, see the vShield Installation and Upgrade Guide.

Known Issues

The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter in this release.

The known issues are grouped as follows:

• vShield Manager Issues
• vShield App Issues
• vShield Edge Issues

vShield Manager Issues

vShield Manager upgrade fails with an error
When vShield Manager has been upgraded from 4.1 to 5.0 to 5.1, vShield Manager fails to connect to the vCenter Server and the UI displays an Internal Server Error.
Workaround: Re-enter the vCenter Server credentials. If connectivity is not restored, reboot the vShield Manager.

vShield Manager fills the /common directory very fast
vShield Manager filled 20% of the /common directory in 30 minutes.
Workaround: If DRS is enabled, you must add at least two hosts from the same cluster in a dvSwitch.

vShield App Issues

If the vCenter Server becomes unavailable during the vShield App upgrade process, the upgrade fails and the Update link is not available
See Update link not available during vShield App upgrade.

vShield Edge Issues

Additional steps to install SSL VPN client on Mountain Lion
Cannot install the SSL VPN client on the Mountain Lion operating system.
Workaround: Mountain Lion does not allow you to install the SSL VPN client since it is unsigned. CONTROL-click on the installer to proceed.

Cannot configure different certificates for two different features
Cannot configure different certificates for two different features. For example, you cannot use certificate a for IPsec and certificate b for SSL VPN.
Workaround: Use the same certificate for both features and then change the certificate for one of the features.

Resolved Issues

The following issue has been resolved in the 5.1.2a patch release.

• vShield Manager needs to be restarted
• vShield Manager becomes unresponsive and needs to be restarted.

In earlier versions of VMware vSphere, many of us used to configure VMware tools settings by double clicking VMware tools inside the guest OS. This was most often used to configure NTP in the Virtual Machine VMware tools. Just to remind you of what that looked like:

Alright if you try to do the same in vSphere 5.1, you will be surprised that you will not have any options to choose when double clicking on VMware tools inside the guest OS. What you will get will look like the below screen shot:

Maybe what I have mentioned so far is already what you know and its why you got here. Now let’s cover how you can configure your VMware Tools to sync the VM time with your host. The way this is done in vSphere 5.1 is a bit different. You actually don’t need to login to the VM to change VMware tools setting & in most use cases the VMware Tools NTP Sync setting, but now you can do it from the VMware setting page. The VMware tools settings now can be accessed  in Virtual Machine –> Edit Settings –> Options –> VMware Tools. The below screenshot show just how to set it up.

As you can see the “Synchronize guest time with host” has been moved to the VM settings window rather than the VMware tools screen inside the OS where it used to be. The main benefits of this, the virtual infrastructure team does not have to have permissions to login to the VM to be able to control time synchronization which can be a great asset for any secure environment, where the Virtual infrastructure admin has no access to guest OS running in a VM. As I have been asked about this increasingly lately, I thought I would share it on here for every one to benefit of it!

I know most of my readers are already aware that Microsoft Exchange & Microsoft SQL have been supported on VMware vSphere for quite long time. In fact, there is so many companies are using it at unbelievably large production scale. Though today while going back from my customer site by train, I was talking to two of their engineers. One of them worked within their Virtual Infrastructure team & the other one within their Microsoft Infrastructure team. What sparked the idea of this post is when the Virtual Infrastructure engineer asked his colleagues what he think of virtualizing their Exchange 2010 setup. The shocking answer was “Our Exchange 2010 environment is too large to be virtualized as we have about 10,000 users. Further, if we virtualize we have have to use Hyper-V to be supported by Microsoft although I know it will run better on VMware vSphere.”

Let me address the status of Microsoft support for running MS Exchange 2010 on VMware vSphere, as it seems there is a lot of misleading believe that Microsoft Exchange 2010 is only supported on Hyper-v. Unfortunately, this seems to be fueled even further by few Microsoft Sales Reps that does not play fair and welling to do anything to win a deal even by misrepresenting facts. They warn customers of not being fully supported when hosting MS Exchange 2010 on VMware vSphere. This is so untrue. Actually if you read Microsoft support statement for their software supported on Hardware Virtualization Platform, you will notice that they combine Hyper-V and any hypervisor supported on the SVVP program in the same support statement. To be exact below is how Microsoft Support Statement for Hardware Virtualization of their supported products look like: “All the below listed Microsoft Server-focused application versions, as well as all later versions of those applications, are supported on Hyper-V and Server Virtualization Validation Program (SVVP) validated products, so long as the virtualization product supports the correct operating system version and platform architecture(s) required by a specific application.”. The source of this statement can be found at Microsoft site at: http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm . Microsoft Exchange 2010 is one of the products supported by that support statement as you will see on the bottom of that page. Further, VMware was the first vendor to be included in the SVVP program and to give you the evidence of VMware being on that list, you can find the list of Virtualization Vendors supported by the SVVP program posted at: http://www.windowsservercatalog.com/results.aspx?&chtext=&cstext=&csttext=&chbtext=&bCatID=1521&cpID=2274&avc=0&ava=0&avq=0&OR=1&PGS=25&ready=0

Being included in the generic statements is not the only place that prove such support, but Microsoft has included the SVVP program members in their products support statements updates. A good example to that when Microsoft has decided to support UM in a virtualized environment & combining Hypervisor availability for features such VMware HA with VMware DAGs. The following statement demonstrate  just that: http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx . When running MS Exchange 2010 on VMware vSphere, you don’t only have Microsoft support but VMware will back you up when running Exchange 2010 on VMware. Below is the VMware statement:

“Any VMware support customer is covered by the VMware Safety Net for Microsoft products. Through VMware’s Premier Agreement with Microsoft, customer issues can be escalated to Microsoft engineering and pursued jointly. VMware will determine when this approach is appropriate, but has found that it can produce excellent results in particularly challenging situations.” This statement which include excellent information on Exchange 2010 support on VMware can be found at: http://www.vmware.com/support/policies/ms_support_statement.html

Alright so now we have covered the support part, let’s look at the part of my environment is too big for being virtualized. I have worked with customers in different sectors that have over 20K, 30K, & even 40K  Microsoft Exchange mailboxes being virtualized on VMware. As unfortunately, I can not share those customers names on my blog for confidentiality reasons I am going to share with you few of the customers who allowed VMware to publish their success stories:

• Navy Marine Corps Intranet (350,000 mailboxes)
  Virtualize 350,000 Exchange mailboxes to control costs, improve availability, and increase manageability.
• University of Plymouth
  Run a large 50,000 mailbox Exchange deployment at lower cost, simplify availability and disaster recovery, while increasing Exchange manageability.
• For more Success stories & tips on virtualizing Exchange 2010 on VMware you should visit: http://www.vmware.com/technical-resources/enterprise-applications/microsoft-exchange.html

Alright I believe those examples of such large Exchange deployment on VMware send the message loud and clear on how large of an Exchange environment VMware vSphere could support. At last, I know each company will decide on the hypervisor to use based on their business needs, I just wanted to help customers avoid taking the decision based on misleading information/input. I hope some of you out there find this post useful, & avoid choosing the wrong solution for the wrong cause. Please leave your comments/opinions in the comments area below.

Alright now that you got your vCenter 5.1 up and running & ready to start managing it. I know vSphere Client will be the first thing to come to your mind in here, but its worth mentioning that all the new features in vSphere 5.1 is only included in the vSphere Web Client not the traditional Installable vSphere Client. Alright that should get you enough reason to install and try to get used to the new vSphere Web Client. Though the new vSphere Web Client has been improved dramatically from the one included in vSphere 5.0 that it feels it is a fully different client. It is much faster, smoother and with tons more functionality that can replace almost every functionality in the traditional vSphere Client.

While this post show you how to install the vSphere Web Client in a step by step fashion, if you have not yet setup vCenter 5.1 then you might want to look at previous posts in this series which document vCenter 5.1 installation including preparing the DBs.

vCenter 5.1 Installation(Part 1) – Preparing the Databases

vCenter 5.1 Installation(Part 2) – Single Sign On Installation

vCenter 5.1 Installation(Part 3) – vCenter 5.1 Inventory Service Installation

vCenter 5.1 Installation(Part 4) – vCenter Service Step by Step

Alright for those of you ready to install the vSphere 5.1 Web Client,  please find the promised step by step instruction below.

To install vSphere Web Client

1-Launch the installer using an account with administrator privileges.

2-Select VMware vSphere Web Clientfrom the VMware Product Installers menu and click Install. 

3- Select the Language for the installation.

4- Click next to proceed with the web client installation

5- Click Next to accept the End User Patent Agreement

6- Accept the End User License Agreement

7- Choose the Installation Destination Folder

8- Confirm the Web Client Port Settings and click Next.

9- Enter the information to register the Web Client with vCenter Single Sign On

10- Click Install to begin the Installation

11- Hit finish to complete the installation and Exit.

Hope you have found this series of vCenter 5.1 Step by Step Installation posts useful. Please leave your feedback, opinion, anything I missed in the below comments area.

As covered in my previous three posts, vCenter Service is the third component to be installed. As a reminder the order of installing vCenter 5.1 components is as follow:

Single Sign On ==> vCenter inventory Service ==> vCenter Service.

In this post, I will demonstrate in a step by step fashion how to install the vCenter Service though if you have not followed earlier parts in this series you will need to check them out before you install the vCenter Service. The earlier posts in this series can be found at:

vCenter 5.1 Installation(Part 1) – Preparing the Databases

vCenter 5.1 Installation(Part 2) – Single Sign On Installation

vCenter 5.1 Installation(Part 3) – vCenter 5.1 Inventory Service Installation

Alright so now that you have completed the installation of SSO and Inventory Service, you are ready to start the installation of vCenter 5.1 Service & below is a step by step instruction on how to do just that.

To install vCenter Server

1.Launch the installer using an account with administrator privileges.

2.Select vCenter Serverfrom the VMware Product Installers menu and click Install.

3.Select the setup language and click OK.

4.Wait while the installation process begins.

5.After the Welcome screen is displayed, click Next.

6.On the End-User Patent Agreementscreen, click Next.

7.On the License Agreement screen, select the radio button to accept the terms of the license agreement, and click Next.

8.You can enter a License key for ESXi now, or you can enter it later. The system can run in evaluation mode for 60 days.

9.On the Database Options screen, select either Install a Microsoft SQL Server 2008 Express instance(Only supported for small environment less than 5 hosts & 50 VMs) or Use an existing supported database and specify an appropriate ODBC Data Source Name. Click Next.

10.If Use an existing supported database is selected, enter the Database Username and Database Password, and click Next. 

11.Specify the account to be used by the vCenter Server Service. Select Use SYSTEM Account (default), or deselect it and specify another local or domain account name and password (if needed). Click Next. To specify a domain account, precede the account name with the domain name and a forward slash (/) as in: domain_name/account_name.

12.On the vCenter Server Linked Mode Options screen, select the standalone or linked mode option, and click Next.

• Select Create a standalone VMware vCenter Server instance (default) to install either a standalone instance of vCenter Server or the first in a series of linked vCenter systems.
• Select Join a VMware vCenter Server group using linked mode to share information to direct the installer to link this vCenter Server to an existing vCenter Server system.

13.Confirm the ports to be used by vCenter Server and click Next.

14.Choose the size of your environment

15.Complete your Single Sign On and Lookup Service information and click Next.

16.Register a vCenter Server administrator user or group with vCenter Single Sign On.

17- Enter the vCenter Inventory Service Information

18- Select vCenter Installation Destination Folder

19- Hit install to start the installation.

20- Hit finish to exit the installation wizard

After completing the installation of the vCenter Service, now your vCenter is up and running and ready to be used. Go a head and enjoy your new vCenter 5.1 or check out my next post for steps on how to install the vSphere Web Client Service which can be found at: vCenter 5.1 Installation(Part 5) – vSphere Web Client Step by Step

In my previous two posts, I have demonstrated how to prepare the databases required for the different vCenter 5.1 components(SSO, vCenter Service, & Update Manager)  as well how to install vCenter Single Sign On. If you have not went through these earlier two posts, then you will need to follow them before proceeding with this one. These two posts can be found at:

vCenter 5.1 Installation(Part 1) – Preparing the Databases

vCenter 5.1 Installation(Part 2) – Single Sign On Installation

As I have mentioned in my earlier post, the next vCenter 5.1 component to install would be vCenter Inventory Service. In this post, I will demonstrate how to install the vCenter Inventory Service in a step by step fashion. It is important to note that in vCenter 5.1 you have the option to install the vCenter Inventory Service with other vCenter components or on a different server/vm. As I mentioned in my first post in the series, the main reason why sometime you want to install it on a separate VM/Server is if scalability is a concern in your organization and you are approaching the vCenter Scalability limits of 1,000 hosts and 10,000 VMs. In most organizations, where these limits are not even close then installing the vCenter Inventory Server on the same VM/Server running the vCenter Service is a no brainer.

To Install vCenter 5.1 Inventory Service

1. Launch the installer using an account with administrator privileges

2. Select VMware vCenter Inventory Service from the VMware Product Installers menu and click Install.

3. Select the setup language and click OK.

4- After the Welcome screen is displayed, click Next.

5- Accept the agreements and hit next

6- Choose the installation Destination folder and hit Next

7- Fill your vCenter Server FQDN and hit next

8- Confirm the ports to be utilized by vCenter Inventory Service and hit Next.

9- Select the inventory size that best describes your vCenter Server deployment and hit next.

10 – Enter the information to register Inventory Service with vCenter Single Sign On.

11- Hit Install Certificates when prompted.

12 – On the ready to install page hit install.

13- Wait till the installation is completed and that should conclude your vCenter 5.1 Inventory Service Installation.

The next service to install is the vCenter Service and the next post in the series which will demonstrate just that can be found at: vCenter 5.1 Installation(Part 4) – vCenter Service Step by Step

During the installation of vCenter 5.1, you will need to install 3 components in the following order: Single Sign On => Inventory Service => vCenter Service. In a new installation I would normally install the Web Service after installing the vCenter Service, though during an upgrade I would install the web service right after the Single Sign On service to be able to use it just in case I wanted to check on my Single Sign On configuration or want to troubleshoot. As this guide assuming a new installation we will leave the Web Client Service to the end. In this post, I will demonstrate the installation of the Single Sign On Service.

Preparing Databases for vCenter Components

Three vCenter components require a database. Single Sign On, vCenter Service, & Update Manager each of those components require its own database, where the creation of those databases have been documented at the first post in this series found at:  vCenter 5.1 Installation(Part 1) – Preparing the Databases.

Alright now you have your databases ready let’s start the process of installing vCenter Components. The first component to install as mentioned earlier is the Single Sign On Service, which is documented in a step by step fashion below.

To install Single Sign On

1-Start the vCenter Installation Wizard

2-Click on vCenter Single Sign On, click Install to start the Single Sign On installer.

3-Select the desired installation language and hit OK

4-Click next to start the Single Sign On Installation Wizard

5-Accept the agreement and click next

6- Choose the “Create the primary node for a new vCenter Single Sign On installation” as this is the first vCenter Single Sign On instant & Click Next.

7-Check the “Create the primary node for a new vCenter Single Sign On Installation”. This will allow us to setup high availability mode in the future.

8-Fill the admin@System-Domain password then hit next.

9-Choose the “Use an Existing Supported Database” as the built in database is limited to a small environment.

10-Fill the database information with the earlier created databases info as shown in the below screenshot. 

11-Fill the fully qualified  domain name of your SSO server name as per the screenshot below and hit next.

12- Choose the SSO installation destination folder and hit next

13-Confirm the https port to be used by SSO and hit next.

14-On the Ready to Install screen hit install to start the installation.

15-On the SSO installation completion screen hit finish and then check the installation logs for errors

This should conclude the installation of the Single Sign On service. To continue with the installation of the rest of vCenter Components you will want to follow the rest of this series posts found at:

vCenter 5.1 Installation(Part 3) – vCenter 5.1 Inventory Service Installation

vCenter 5.1 Installation(Part 4) – vCenter Service Step by Step

vCenter 5.1 Installation(Part 5) – vSphere Web Client Step by Step

After the introduction of vSphere 5.1, there seemed to be a lot of fuzz about the installation of the new vCenter components. I believe most of the hype was caused about how the initial vSphere 5.1 release behaved differently against expired certificates from how vSphere version prior to 5.1 behaved. In earlier releases, vCenter has only checked the expiry date of the certificate used during the initial install and fall to a backup mechanism if the certificate fail though the service would went up and the user would use vCenter as nothing has happened. To increase the security of vCenter and prevent man in the middle attacks, this behavior was changed in vCenter 5.1. vCenter 5.1 is always checking the validity of its certificates every time the service is being started & it would report an error if it does not find a valid certificate. As many customers had an expired vCenter certificates and did not know about it before upgrading to vSphere 5.1 they were caught off guard by this small behavior change where VMware has quickly released a quick workaround for it and a new patch were released to improve how vCenter response to this behavior.

The installation of vCenter 5.1 has been much smoother after releasing vCenter 5.1b & ESXi 5.1a, & to calm my readers nerve about installing vCenter 5.1, I will be showing in here a step by step the installation process of vCenter 5.1 in a simple way that show its not much more difficult than what used to be done in vSphere 5.0 if you know what you are doing. I will actually show the process of even creating and preparing the Databases required for vCenter. I know there is few posts out there describing the process, but they have either not included the DB part or still impeding many of the initial vSphere 5.1 release installation issues and workaround in them which can make the installation seems much more complex than it really is.

So before I share the installation steps with you, let’s talk a bit about what has changed in vSphere 5.1 installation from what used to be done in prior vSphere versions. vSphere 5.1 has added the feature of Single Sign On, which should allow you to login once and access multiple vCenters in your environment and should be able to help you to access many more VMware products in the future without having to over and over again each time you access each product portal. As well Single Sign On will allow companies to use different kind of LDAP servers like Active Directory, Open LDAP, NIS. Further, it will allow you to use multiple LDAP source at once even from the same LDAP type. For example you can assign permissions to vCenter for users from different Active Directory Domains without having any trust relationship between those domains which was not possible with earlier versions of vSphere.

In addition to Single Sign being added, now you have the option to separate vCenter components to multiple servers, which will allow vCenter to scale up even further. Unlike earlier versions of vCenter, now you can install each of vCenter Components(vCenter Service, Inventory Service, Single Sign On(SSO)) to different VMs or machines. One thing to remember though there is nothing stopping you from installing all of them to the same host unless you are reaching the scalability limit of vCenter at 10,000VMs and 1000 hosts. For most environments where they are not even close to those limits, there is nothing stopping them from installing all the components on a single host/VM. Actually If you are not approaching that limit I would always install the inventory service on the same host/VM with the vCenter Service.

The main one to decide on where to place it is the SSO Service. If you only have one vCenter and you don’t see yourself adding any more vCenters then having SSO share the same vCenter Service host/VM is a no brainier. Though if you have multiple vCenters that will utilize the same SSO, then you want to consider how will you protect the SSO service. If you have vCenter Heartbeat then you can install SSO on the same vCenter VM, & protect all the vCenter services with vCenter heartbeat. Another choice would be to install SSO on a separate VM and the protect it with its own availability mode. As you can see the decision of where to place the SSO service is more dependent on how you are planning to protect your SSO machine and what you are going to use it for, though if you have a small deployment then its safe to put all the vCenter components together. If you have a larger deployment its safe to put them all on the same host unless you are reaching the limits or if you want to protect your SSO with its built-in availability mode.

Before starting the installation of the vCenter services, you will need to prepare the prerequisites. To find out all of the supported operating systems & Databases supported by vCenter you can check the following VMware KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2021202 where the same KB will help you with sizing vCenter for your requirements. For this installation, I am going to utilize Windows 2008 R2 for the vCenter Server OS, & MS SQL Server 2008 R2 for the Database. The instruction below assume you have already installed the database and the Windows OS prior to following the below instructions.

Below I will demonstrate how prepare the SQL Databases for your vCenter 5.1 installation in step-by-step fashion, though its worth mentioning setting up the vCenter Service DB & Update Manager DB has not changed since the previous vSphere version so if you are familiar with earlier vCenter installation feel free to set them up the way you always did though I included the instruction for them below for new comers. Though the main difference in setting up the DBs in preparation of vCenter Installation in vSphere 5.1 is the extra requirement of the SSO Database and the creation of two DB users for it. The below instruction walk you through the preparation of all the required DBs:

Preparing Database for vCenter 5.1  Components:

vCenter & Update Manager Databases preperation:

1-    Right click database and click on new database

2-    Fill the database name then hit OK to create the DB

3-    Repeat the step 1 & 2 to create the Update Manager DB

4-    Create new DB login by expanding security, then right click login, then click on New Login

5-    Complete the form of the new login as shown in the below screenshot. Make sure to untick the enforce password expiration and user must change password at next login

6-    Repeat steps 4 & 5 for the UM database

7-    Assign the vc user a db_owner access to both created databases(vCenter DB & UM DB) & MSDB by

8-    Expand your database => security => users => New user

9-    Assign db_owner privillages to the vc user created earlier. Repeat these steps for both vCenter & Update Manager Database as in the below screen shot.

10-To create the SSO database use the DB Script that come up with the vCenter CD and can be found at: D:\Single Sign On\DBScripts\SSOServer\schema\mssql\rsaIMSLiteMSSQLSetupTablespaces.sql

11-Open the script in Microsoft SQL Server management Studio File => Open =>File & Choose the script file

Once the script is opened in Microsoft SQL Server management Studio Replace all 3 occurrences of C:\CHANGE ME with the path to the folder you want your databases to reside in as shown in the below screen shot. As well Make sure that you have created the folder to contain the DBs before executing the script.

12-         Press the Execute button to execute the script and create the required databases.

13-         Expand your database and make sure the RSA database is created as shown at the left side of the below screenshot

14-         Create two new logins RSA_USER & RSA_DBA and assign each of them a DB Owner on the RSA DB. You can achieve this by following step 4-9 though for the RSA DB this time & using the RSA_USER & RSA_DBA users.

This should get your SQL DBs ready to start your vCenter Services installation, though if this is a totally new SQL server you have setup for the environment, you want to ensure it allow TCP/IP Protocol connectivity as well remote connections. Follow the below steps to check on that quickly.

1- Make sure in SQL Server the “Allow remote connections to this server” is checked.

2- Ensure in SQL Server Configuration Manager that the TCP/IP protocol is enabled.

Alright so you are now ready to proceed with vCenter Components Installation (vCenter Service, Inventory Service, & Single Sign On). I will be adding posts showing the steps by steps installation of each of those components quite soon as I have it written in a word document, but it take a lot of efforts to clean it up and make it ready for a blog post. Though keep checking as they will be here soon!

Update: The following Parts of this series have been Published.

vCenter 5.1 Installation(Part 2) – Single Sign On Installation

vCenter 5.1 Installation(Part 3) – vCenter 5.1 Inventory Service Installation

vCenter 5.1 Installation(Part 4) – vCenter Service Step by Step

vCenter 5.1 Installation(Part 5) – vSphere Web Client Step by Step