Installing VMware vCenter (Windows)

Introduction to vCenter

Version: vSphere 5.5

Features and Functions

VMware vCenter is the companies core management platform, and its common for other technologies both from VMware and third-parties to use it as the central point for accessing ESX hosts and clusters, as well accessing VMs and other components upon which they can add value or further orchestration. At the time of writing VMware support two version of vCenter – an installable version which runs on the Microsoft Windows platform and virtual appliance edition which runs on the SUSE Linux platform. In terms of their core APIs, the two editions are functionally the same. However, there are some features that are for the moment only available on the Windows editions. Historically, third-party add-ons have run as Windows plug-ins. Finally, whilst the scale of vCenter Server Appliance (VCSA) has increased in recent releases, it has lower configurable maximums. In production environments it is the Windows edition that predominates – and this is combination of history (the first version of vCenter was Windows only) and compatibility. With this said, the VCSA is considerably easier to deploy and update/upgrade than the Windows edition – and for this reason it might be more suitable for a small-medium sized deployment where ‘core” virtualization is all that is required. Currently, the features that are only supported by the Windows edition or require a Windows instance to function include:

  • Linked Mode

Linked mode allows for multiple vCenter instances to be chained together. This might be required if different vCenters are needed for different regions (a combination of network bandwidth limitations or legal requirements perhaps) are deployed, and yet the administration team want to make lift easy by opening one UI to manage these multiple instances. Linked Mode requires the Microsoft ADAM technology to distribute other management data held within the vCenter Database. It’s for this reason you do not see “linked mode” with the VCSA.

  • Role Sharing

This feature is subset of “linked mode”, and it enables the creation of role for administration delegation to be replicated to other vCenter instances.

  • License Sharing

Perhaps the most valuable aspect of “linked mode” is the replication of license data from one vCenter instances to another. It means the organizations license entitlements are available across vCenter instances, and are not “orphan” in the case of stand-alone vCenter instances.

Additionally, there are some features and functions that VCSA is either not compatible with or not directly compatible with. For instance the VCSA does not yet support IPv6 or the vCenter Heartbeat Service. The vCSA doesn’t include an “Update Manager” (VUM) component, although it is possible to run on a Windows instance, and register it with the VCSA.

The Windows version of vCenter has a number of sub-services and components, these are explained below:

  • Single Sign-On

Is service design to easy the logon process for administrators of VMware solutions. This is not aimed at ordinary end-users, and at the time of writing has not associated with single sign-on or pass-through authentication for end-user computing. The idea is the administrator logs in once to the “web-client”, and a token is generate which can be used to pass on that authentication to other technologies such as vCloud Director. It should if implemented well, mean the administrator has to log on once, to then gain access to all other VMware technologies they manage.

  • Web-Client

This is the core interface of managing VMware ESX hosts and clusters, Virtual Machines and templates – as well as configuring storage and networking. It’s a replacement for the older legacy “C#” vSphere Client. At the moment the older C# vSphere Client is still supported for direct management of a VMware ESX host.

  • Inventory Service

The Inventory Service enumerates vCenter objects such as VMs, Templates, Hosts and Clusters. The intention of the Inventory Service is remove the workload on the core vCenter service, and improve the process of searching and browsing the vCenter environment.

  • Update Manager

VMware patch management solutions updates both ESX hosts, virtual appliances – and be also used to upgrade the “VMware Tools” software. This is small package which is installed the guest operating system and adds improved drivers, heartbeat services and an API model that allows for communication from the vCenter management layer into the guest operating system.

  • Dump Collector

By default if the VMware ESX host encounters a critical error that causes a kernel panic (commonly referred to as a Purple Screen of Death – PSOD), the system will dump system data (not memory contents) that can assist in diagnosing problems. For diskless systems that do not have local storage, the “dump collector” service can be configured. This forces the VMware ESX host to send this diagnostics data across the network. It is particular interest to customers who adopt the “Auto Deploy” method of rolling out VMware ESX in their datacenters.

  • Syslog Collector

VMware has its own simple “Syslog Collector” which collates all the log files on each VMware ESX into a central location. Whilst the service is useful – you may wish to look at VMware’s Log Insight technology, or alternative look at other syslog tools such as Splunk.

  • Auto Deploy

Auto Deploy is a method of rolling out VMware ESX host which allows for diskless and stateless operations. The physical server boots across the network using the PXE, and the configuration is delivered by associating the server with a “Host Profile” held within vCenter. It offers a very rapid deployment and easy way to “upgrade” from one distribution of VMware ESX to another. Currently, Auto Deploy requires Enterprize+ licensing.

  • Authentication Proxy

This an optional and complementary service to Auto Deploy. It allows a VMware ESX host to join a Microsoft Active Directory domain without using administrator credentials. It requires Microsoft .NET SP1 or higher, and Microsoft Internet Information Services (IIS) web-server.

  • Host Agent Pre-Upgrade Checker

This validates the vSphere environment prior to an upgrade.

  • Certificate Automation Tool

vCenter and its associated use system generated SSL certificates to encrypt management information. The Certificate Automation Tools allows the administrator replace the installer generate certificates with their own trusted certificates if required.

As the vSphere platform has grown, vCenter has evolved from a “nice to have” in the VMware ESX 2.x era, into an absolute “must have”. This is because important features such as VMware Clustering in the shape of High Availability, Distributed Resource Scheduling, Distributed vSwitches and Tolerance. Additionally, vCenter act the linchpin for other technologies from VMware such as Horizon View, Site Recovery Manager, vCloud Director, vCloud Connector, vCloud Automation Center and so on. vCenter now standards at the centre of many the orchestration tools from VMware, and such customers are increasingly concerned about its availability as a management service. VMware do support a virtual instance of vCenter, and indeed the clustering technologies in the platform do offer resiliency and availability. For customers with higher uptime requirements VMware supports a technology called “vCenter Heartbeat Service” (a OEM version of NeverFail’s technology) which improves vCenters over all uptime. It has system by which the administrator can configure a “Primary” and “Secondary” server that act as mirror of each other. If the “Primary” goes down the “Secondary” automatically takes over. The vCenter Heartbeat Service is licensed separately from the vCenter product itself, and some organizations regarded as optional extra that is beyond their needs. Other availability solution such as Microsoft Clustering Service (MSCS) can and do work, but VMware does not certify these solutions. VMware does with vSphere 5.5 support the clustering of the database that backs the vCenter service itself. KB Article 1024051 outlines VMware’s current position on the availability of the Windows edition of vCenter.

Hardware & Software Requirements

Hardware Requirements:

For the core services (SSO, Web-Client, Inventory, vCenter)

  • 12GB – or more based on the allocation of memory allocated to the Inventory Service during installation
  • 2xvCPU
  • 100GB recommended – with 40-60GB free space. Log allocation size is now 450MB larger than previous 4.x release
  • If the vCenter is also configured to run Update Manager (VMware’s patch management and upgrade system), the partition where patches are held should have 120GB or more of free space.

Note: In a modest homelab environment you maybe able to reduce these values, but beware that your mileage my vary in terms of the quality of your experience.

Software Requirements:

  • SQL Native Drivers relative to the version of Microsoft SQL used
  • .NET 3.5 SP1 (vCenter will download this if not present, assuming Internet access is present)
  • Web-Browser: IE8/9/10, Mozilla FireFox 24.0, Chrome 30. Safari is not supported.
  • Flash: Adobe Flash Player 11.5.0 or higher

Database Requirements:

The Windows edition of VMware vCenter supports a number of different database venders including Microsoft SQL and Oracle specifically:

  • Microsoft SQL Server 2008 R2 Express (For small deployments with 5 hosts, and 50 VMs)
  • Microsoft SQL Server 2005
  • Microsoft SQL Server 2008 R2
  • Oracle 10g/11g

Note: There is anecdotal evidence that vCenter 5.5 will work with Microsoft SQL Server 2012, but for the moment it is unsupported.

Creating vCenter Service Accounts in Microsoft Active Directory

Like many Windows based systems, vCenter does require “service accounts” to run the core services securely. These service accounts can also be used to assign permissions to the databases the service accesses

It’s not considered best practise for the “Administrator” account to be used by background system services, as the “Administrator” account is often renamed or disabled to prevent miss use. These service accounts can be located in Microsoft’s Active Directory, and be given local rights to carry out the installation of vCenter. Since vSphere4.0, VMware has support “Windows Authentication for SQL Servers”. This is where the core service and database user accounts are stored in the directory services rather than using either local accounts or accounts stored in Microsoft SQL databases (often referred to as “SQL Authentication”. “Windows Authentication to Microsoft SQL Server” is regarded as being more secure than “SQL Authentication”, with the added benefit of the user accounts concerned being located in central directory service. This should make them easier to manage from a password reset perspective, if it the service account becomes regarded as compromised.

Both the core vCenter service and the vCenter Update Manager (VUM) service require database – and therefore its not uncommon for service account be created for each service.

1. Open up Active Directory Users and Computers

2. Create an OU for the VMware Service Accounts [OPTIONAL]

3. Create a user for the vCenter Database/Service Account and for the vCenter VUM

Screen Shot 2013-10-30 at 14.28.17.png

4. Enabled the option to set “User cannot change password” and “Password never expires”. This prevents the account becoming locked out due to password reset policies on the domain. [OPTIONAL, BUT RECOMMENDED]

Configuring Microsoft 2008 SQL R2 for vCenter

Creating the Database

In this tutorial we will be configuring Microsoft 2008 R2 for vCenter using Windows Authentication. For this to work “Windows Authentication” will be enabled during the installation of Microsoft SQL Server. The default is for “Windows Authentication” only, although the SQL Administrator has the option to set both “SQL Server and Windows Authentication Mode”. If you are ensure of what mode is currently in use, it can be checked by opening the “Microsoft SQL Server Management Studio”, right-clicking the server (local), Properties and the Security tab like so:

Screen Shot 2013-10-30 at 14.48.08.png

1. Open Microsoft SQL Server Management Studio

2. Login to the SQL Server

3. Right-click the +Database node, and choose New Database

Screen Shot 2013-10-30 at 14.51.17.png

4. Type a name for the new database, and change the location for the database files. Microsoft SQL Server can by default point to location on the C: drive within Program Files. It’s better practise to store the database files in separate partition/disk to avoid situations where database files grow rapidly and fill the operating systems root partition.

Screen Shot 2013-10-30 at 14.55.59.png

5. Click OK to create the database

Set Permissions to the Database

Next we need to grant our service account user rights to the database. This involves allocating the user, and then setting the rights to the database itself.

1. In the Microsoft SQL Server Management Studio expand the +Security node

2. Right-click the +Logins node, and select New Login

Screen Shot 2013-10-30 at 15.09.26.png

3. Use the “Search” button to locate the vCenter Service Account created earlier. In this case the account is called vcdbuser-nyc. Alternatively, you can type the location for the user account manually.

4. In the same dialog box, change the default database to be the database created earlier. In this case the database is called vcdb-nyc

Screen Shot 2013-10-30 at 15.14.26.png

5. Click OK to add the user.

6. Next we need to set the permissions on this database, Right-click the user account – and then under User Mappings. Grant the vCenter Service Account the privilege of DB Owner to both the MSDB and the vCenter database.

Screen Shot 2013-10-30 at 15.18.51.png

IMPORTANT:: These privileges maybe regarded is too permissive for your organizations SQL security policies. The official VM guide to SQL permissions has extensive detail on setting these privileges. Please refer to the “Preparing vCenter Server Databases” in the official “vSphere Installation and Setup” guide for further information

Installing vCenter


VMware vCenter is composed of many different services as well as the core “vCenter” (vxpd) service itself. In simple lab or SMB environment one Windows instance could be created, and all the roles could be installed to that single instance. The vCenter installer refers to this configuration as a “Simple Install”

In larger corporate or enterprize environment a more “distributed” model exists where each of these roles could be installed to separate Windows instances. In some cases (such as the Single Sign-On vCenter Service) you can have more than one server instance, and have them distributed geographically. If couple with a load-balancer some of these services can be made to have greater resiliency. If you are attempting a “Custom Install”, VMware does recommend installing the various components that make up vCenter in this order:

1. vCenter Single Sign-On

2. vSphere Web Client

3. vCenter Inventory Service

4. vCenter Server

Screen Shot 2013-10-30 at 15.56.45.png

Installing the SQL Native Drivers and Configuring a DSN Connection to Microsoft SQL Server

The vCenter server will need the “SQL Native Drivers” installed relative to your version of Microsoft SQL Server. These are contained in what Microsoft call “Feature Packs” located on Microsoft website here:

SQL 2008 Native Drivers:

SQL 2012 Native Drivers:

Once these have been installed by the administrator, you can allow your vCenter Service Account local administrator rights to configure a ODBC “Data Source Name” or DSN connection, and carry out the installation itself.

Screen Shot 2013-10-31 at 17.05.36.png

To configure the ODBC DSN Connection to the SQL Server:

1. Login as the vCenter Service Account, in this example this is the vcdbuser-nyc

2. Open the Data Source (ODBC) control panel

3. Select the System DSN tab, and the Add button – and select the SQL Native Driver that was installed earlier

Screen Shot 2013-10-31 at 17.13.23.png

4. In the “Create a New Data Source to SQL Server” wizard, assign a name for the DSN, and select the SQL server. In this case “vCenter” is the name of the DSN, and SQL2K8NYC is the name of the SQL Server:

Screen Shot 2013-10-31 at 17.16.13.png

5. In this example “Windows Authentication” is being used, and the vCenter Service Account is logged in locally. So clicking next should use these credentials and pass them through to the SQL server:

Screen Shot 2013-10-31 at 17.17.56.png

6. The next page should have the vCenter Database created in SQL select automatically, if not use the X Change default database option to select the correct database:

Screen Shot 2013-10-31 at 17.20.01.png

7. Clicking Next and Finish should trigger a test attempt to connect to the SQL Server. This a relatively crude test that merely tests basic connectivity, it does not test such options as having the right permissions on the database.

Screen Shot 2013-10-31 at 17.21.40.png

A Simple vCenter Install

Once you have attached the vCenter .ISO to the vCenter Server, you should find the “autorun.exe” opens, at the welcome screen:

Screen Shot 2013-10-31 at 19.33.33.png

Installing SSO Service

A simple install essentially chains four different installations together of the four core primary services that make vCenter work – SSO, Web-Client, Inventory and vCenter service itself.

1. Ensure that “Simple Install” is selected, and click Install

2. Click Next, to the welcome screen for the SSO service

3. Accept the EULA

4. The installer will check the pre-requistites for the SSO service – the vCenter should have both a forward and reverse lookup records in DNS (Aname and PTR records), and joined to an Active Directory domain.

Screen Shot 2013-10-31 at 19.39.33.png

5. SSO establishes a “Domain”. The default name is vSphere.Local. It contains its own “administrator” account, and is separate and discrete from the “administrator” account on the Microsoft Active Directory domain. The password here must be >8 long and contain four character classes – 1xUppercase, 1xLowercase, 1xDigit, and 1xCharacter. Therefore P@ssw0rd is a valid password.

Screen Shot 2013-10-31 at 19.42.29.png

IMPORTANT: This account is the first and only account that can logon to vCenter in the first instance. The logon name would be administrator@vSphere.Local and the password set here. This account is both the SSO administrator account AND the vCenter default administrator account. Once configured it is possible to browse the Microsoft Active Directory Domain, and delegate responsibility to others and groups. Be careful with different keyboard types and county codes, as its very easy to assign a password twice that has unexpected characters included in it. If in doubt type the password into a test editor to confirm the characters inputed. A classic example is accidentally using the US Keyboard type on a UK Keyboard, and finding the £ is actually the # character, and that ” is actually the @ character. This can also cause logon head-aches if you move from one computer to another.

6. Specify the site name:

Screen Shot 2013-11-05 at 14.22.17.png

7. Specify the HTTPs TCP Port number for the SSO Service, the default is port 7444

Screen Shot 2013-10-31 at 19.51.23.png

8. Accept or change the path for where the files that make up SSO will be copied

9. As this first installation of vCenter in the domain, this will be configured as the first SSO server in that domain:

Screen Shot 2013-10-31 at 19.54.09.png

Installing the vCenter Web-Client Service

The installation of the web-client is non-interactive. The administrator has no configuration options to address.

Installing the Inventory Service

The installation of the Inventory Service is non-interactive. The administrator has no configuration options to address. During the installation the Inventory Service registers itself with the SSO Service.

Installing the vCenter Service

1. The install of vCenter begins with a request to input the license key. The license is not required for an installation, and vCenter can be run in a evaluation mode for 60-days

Screen Shot 2013-10-31 at 20.32.27.png

2. For small installations you can use a Microsoft SQL Server 2008 Express instance (this does require more memory to be assigned to the vCenter). In this case we are using an external SQL Server using DSN configuration to access the database:

Screen Shot 2013-10-31 at 20.34.40.png

3. If you are using SQL Authentication, you will need to provide the username/password to access the SQL database, in this case we used “Windows Authentication”, and we were logged in with the vCenter Service Account – so no further configuration was required.

Screen Shot 2013-10-31 at 20.36.15.png

When you click next you will see a pop-up warning.

Screen Shot 2013-10-31 at 20.40.33.png

This is an informational message – and is not a problem with the installation. The warning concerns the fact that SQL Server is set to a “Full Recovery Model”. This is a good feature because it causes SQL Server to use full transactional log, and ensures that if there an outage no data is lost from the database. Transactional Logs can grow incrementally if you do not have an effect backup strategy in place for SQL Server. Regular backs causes the transaction logs to played against the database, and reduced in size. Without a regular backup strategy, these transaction logs grow incrementally until there is no free space left on the SQL Server. Backup your database – you know it makes sense!

4. Next set the password for the vCenter Server Service account password. Configuring this option also sets the right to “Logon on as a service” to this account.

Screen Shot 2013-10-31 at 20.43.32.png

5. The installation does allow you to change the default TCP ports used by vCenter. One port number to watch out for is the vCenter Server HTTP port. The optional “BLAH SERVICE” leverages IIS which default to HTTP/80. If you do intend to install the “blah service” at later stage – watch out for port conflicts with this service.

Screen Shot 2013-10-31 at 20.46.18.png

6. Finally, we need to assign an allocation of memory to the JVM. This is reservation of memory to the JVM process, and the larger your vCenter environment the greater the reservation of memory should be.

Screen Shot 2013-10-31 at 20.48.20.png

At the end of the install wizard you can click “Install”.

During the installation a number of additional components are installed including the vCenter Orchestrator and Storage Profile-Driven Storage. The Simple Installation ends with this confirmation.

Screen Shot 2013-10-31 at 21.27.24.png

Post-Configuration of vCenter Install (Web Client)

Using to the vSphere Web-Client

The Legacy C# vSphere Client:

Screen Shot 2013-11-01 at 08.04.51.png

The All-New vSphere Web Client:

Screen Shot 2013-11-01 at 08.05.21.png

The vSphere Web Client is VMware’s replacement of the desktop installed vSphere Client (commonly referred to the C# vSphere Client. Although vSphere5.5 supports both the web-client and the vSphere Client since vSphere 5.1, new features and options are being exposed to the web-client only. Currently, the vSphere Client has a warning about this period of transition. The vSphere Client is still used currently for VMware VUM and a few other solutions such as Site Recovery Manager and vCloud Connector. Another ancillary use of the legacy vSphere Client is to establish direct connections to the VMware ESX host in environments where vCenter is not in use, unavailable or yet to be deployed.

Screen Shot 2013-11-01 at 07.51.41.png

For the web-client to work the web-browser will need Adobe Flash installed, and at the logon screen there is an installer for “Client Integration Plug-in”. This needs to be downloaded and installed in order for the web-client to be able to connect a console to the virtual machine. Additionally, the plug in is required as part of the process of enabling the “Windows Session Authentication” feature. This allows the web client to accept the local logon credentials from a Windows system

Screen Shot 2013-11-01 at 08.27.22.png

Whilst a wide range of web-browsers work with the vSphere Web Client, many users in the community prefer Mozilla FireFox, as it appears to handle untrusted certificates generated by the installer in an easier way than

Adding Microsoft Active Directory and Delegating Responsibility

With a clean installation vCenter use its own internal director service called “Single Sign-On” (SSO) as the primary authentication domain. The default username is administrator@vsphere.local. It is possible add the Active Directory domain to SSO, and enable user accounts and groups from it as the logon to the web-client.

1. Login to the vSphere Web Client as administrator@vsphere.local

2. From the home location, navigate to >>Administration >>Singe Sign-on >>Configuration

Screen Shot 2013-11-01 at 09.00.37.png

Note: Click the green + to update the configuration.

3. Select the radio button – “Active Directory (Integrated Windows Authentication”.

Screen Shot 2013-11-01 at 09.06.52.png

Note: This type of authentication enables the pass-though of your logged on local credentials from the Windows domain to the web-client.

Note: In a simple installation of vCenter, SSO should pick up on the single domain that vCenter is joined to.

4. After clicking OK, this should add the domain to the list

Screen Shot 2013-11-01 at 09.10.55.png

Next we can add in accounts to the vCenter to delegate responsibility. The best method it create a group in Active Directory called “vCenter Admins”, and populate it with user accounts from the administration team.

5. Navigate to >>vCenter >> vCenter Servers

6. Select the Manage tab, and the Permissions category

Screen Shot 2013-11-01 at 09.25.16.png

Note: Click the green + to update the configuration.

7. Click Add, in the subsequent dialog box select the domain, and from the second pull-down list “Show Groups First”. Select the group created – and click Add

Screen Shot 2013-11-01 at 09.32.58.png

8. Finally, assign the “Administrator” role and click OK

Screen Shot 2013-11-01 at 09.36.03.png

Once enabled, you should be able to enable the “Use Windows Session Authentication” option at the web-client:

Screen Shot 2013-11-01 at 09.49.27.png

Enabling AD User/Groups to Manage VMware SSO

Even if you give a Microsoft AD user/group complete rights to vCenter from a top-level container – this doesn’t necessarily give those AD user/groups rights to manage SSO itself. This handled by different subset of permissions and rights. Typically, SysAdmins like to do this delegation to prevent situations such as loosing, forgetting or getting locked out of VMware SSO, which then prevents further administration. VMware SSO has its own systems of password policies and lockouts.

1. Login to the vSphere Web Client as administrator@vsphere.local

2. From the home location, navigate to >>Administration >>Singe Sign-on >>Users & Groups

3. Select the Groups Tab and Select the Administrators group

4. Click the Add Member icon which resembles the figure of person with small green +

Screen Shot 2013-12-04 at 14.16.21.png

5. From the Domain and User and Group pull-down lists – select your Microsoft Active Directory Domain, and Show Groups First

6. Locate your delegated user/group from the list, and click the Add button

Screen Shot 2013-12-04 at 14.19.59.png

Creating vCenter Datacenters (Web Client)

A “Datacenter” in vCenter is a logical construct which could be compared to an object like a “domain” in Active Directory. It acts as an administrative boundary, separating generally one site from another. Therefore its not uncommon for datacenters to be named after locations like “New York” and “New Jersey”. Whether one vCenter instance will be sufficient for organisation with many sites is large dependent on factors outside of the control of VMware. These include the quality of the network links from one site to another – as well as the internal politics of a given organization. It may have always been the case that the West Coast of the USA is managed independently of the East Coast of the USA – this might reflect the timezone difference between the regions. Similarly in a European context each country within the EU maybe administrated separately because of language differences, and that fact that despite existence of European Law, systems of data protection, compliance and audit rule still differ from one member state to another.

Screen Shot 2013-11-02 at 01.52.06.png

Note: Screen grab from the vSphere 5.5 Configuration Maximum guide.

One datacenter can contain many clusters, and clusters can contain many VMware ESX hosts. This means vCenter scales quite well for large datacenters which have been packed with a large number of servers to maximise economies of scale. Nonetheless, vCenter like VMware ESX has its own configurable maximums. This might force organizations to adopt a multiple vCenters because they are rubbing up to those configurable maximums. It’s salutatory to remember that increasingly these maximums are only of theoretical interest. The numbers are now so large, most customers will find they run out of physical resource on the host before they hit the configurable maximums.

VMware publishes a list of configurable maximums of vSphere which is well worth consulting if you know your organization is going to have many hundreds of ESX hosts, and many thousands of VMs. The configuration maximum guide for vSphere 5.5 is located here:

Creating a datacenter

1. Select the Go to vCenter button

Screen Shot 2013-11-02 at 02.07.32.png

2. In the Inventory List, select Datacenters

Screen Shot 2013-11-02 at 02.10.24.png

3. Click the New Datacetner icon

Screen Shot 2013-11-02 at 02.12.40.png

4. In the New Datacenter dialog box, type in a friendly name for the datacenter – in this case “New York”

Screen Shot 2013-11-04 at 17.04.10.png

Note: You must select a vCenter Server or folder (if one exists) to create the datacenter.

Adding VMware ESX hosts

Once a datacenter object is created in vCenter, you can start to add VMware ESX hosts. This then allows you to perform further post-configuration tasks such as managing the network and storage layers, ready for creating a VM. Adding a VMware ESX hosts is relatively simple affair, but not a terrifically exciting task, so you may wish to automate this process with a PowerCLI script if you dealing with a rollout of large number of servers.

1. In the Datacenter view, select the datacenter

2. Click the Actions button, and from the menu select Add Host

Screen Shot 2013-11-02 at 03.06.30.png

3. In the Add Host wizard, type the FQDN of the ESX host

Screen Shot 2013-11-02 at 03.12.11.png

4. Type in the root account and password

Screen Shot 2013-11-02 at 03.12.42.png

Note: You should prompted by warning that the ESX host certificate is untrusted (as it was auto-generated during the installation), together with its SHA1 Thumbprint.

Screen Shot 2013-11-02 at 03.16.46.png

Once the certificate is accepted the host information page should be refreshed with a table of data that shows – the FQDN, Vendor and Model of Server, and ESX version and build number. If the host has virtual machines present on it these will be listed as well.

5. Assign a license to the host if these have been inputed, alternative continue to use the evaluation period.

Screen Shot 2013-11-02 at 03.19.33.png

6. Enabled Lockdown Mode [OPTIONAL]

Screen Shot 2013-11-02 at 03.20.56.png

This is an optional configuration. Lockdown mode does improve security, but at the expense of ease of management. Consult the policies of your organization if any.

7. Select a VM location – This maybe blank on clean system. But on existing system with virtual machine folder hierachy, and with a host with pre-existing VMs on it, the option can be used to control where VMs are located in the vCenter Inventory

Screen Shot 2013-11-02 at 03.22.08.png

8. Click Next and Finish to add the host.

Creating vCenter Folder Structure

vCenter supports the creation of folder structure for virtual machines and templates, as well for datastores. Like a folder structure on hard disk or an OU structure in Active Directory – the intention is to create a layout that allows the administration team to collect and sort objects in such a way that makes them easy to find. Additionally, these folder structures can be used to hold permissions – and limit the view of a user or groups to a subset objects. The folder structure is entirely free form, and its entirely up to your organization how to lay these folders out. It’s useful to have these folders created upfront as it means VMs are being sorted and categorised from day one. However, its entirely possible to create and modify these folder structures after the fact, and move VMs from one folder to another at will. It’s worth mentioning that some technologies from VMware (and others) such as Horizon View and vCloud Director will automatically create folders for you, as these management systems create new objects in the vCenter inventory.

Typically, the folders top-level might reflect departmental subgroups

  • Templates
  • Sales
  • Accounts
  • Distribution

or they may reflect the servers operational role

  • Templates
  • Web Servers
  • Databases
  • Mail

alternatively they may reflect the relationship between the VMs

  • Templates
  • CRM Application
  • Horizon EUC
  • Sharepoint

in a more “cloud” like environment each of the top-level folders may reflect different “tenants” within the system. For example imagine “Corp, Inc” has four distinct subsidiaries – the Corporate Headquarters (CorpHQ), Corp Overseas Investment Group, Inc (CIOG), iStocks Inc, (a stocks and shares, day trading company) and Quark AlgoTrading, Inc (a company that trades on the international exchanges using the latest algorithms for the short-selling of stocks). Using this folder structure keep the tenants separate from each other, and allows permissions to reflect the appropriate rights needed to manage them.

Each subsidiary might be top-level folder

  • Templates
  • CorpHQ
  • COIG
  • Quark
  • iStocks

Creating these folders is as easy as creating a folder on a hard-drive.

1. Select VMs & Templates within the Web Client

2. Select the appropriate datacenter

3. Click the Actions button

4. Select in the menu – All vCenter Actions, and New “VM Template and Folder

Screen Shot 2013-11-04 at 11.56.25.png

5. Type in a friendly label for your folder name

Screen Shot 2013-11-04 at 12.08.18.png

Note: You may notice a folder called “Discovered virtual machines”. This is created by default when new hosts are added into vCenter. It is used to hold VMs that have been found to be pre-existing on the VMware ESX host. Additionally, it maybe used if a rogue administrator bypasses vCenter, and creates a VM directly on the VMware ESX host. Once you have a VM folder created, selecting it makes subfolders.

Finally, it is possible to create folders in the “Host & Clusters”, Network and Storage View. Depending on the size, scale and complexity of your environment you may or may not find these useful.

Licensing vCenter and ESX Hosts

Most VMware products are licensed by text string. For vCenter integrated technologies these licenses are stored and inputted in the licensing section of the vCenter server. Other technologies store these strings under the context of their management front-end. For example VMware Horizon View, the companies “Virtual Desktop” solutions stores the license string inside its dedicate management portal. Without a valid license key most VMware technologies expire on their evaluation by 60s day. When this occurs assets like VMware ESX hosts become disconnected and unmanageable.

Currently, two license policies dominate – either licensing by the number of physical CPU sockets (as is the case with vSphere) or by the number of VMs (as is the case with VMware Site Recovery Manager). Within the vSphere product different SKUs exist for SMB as well as Enterprize – with each progressively offering more features and functionality. Somewhat confusingly the “vCloud Suite Enterprize” edition contains the “Enterprize Plus” version of vSphere. The terminology is little skewed by the inherited history of previous editions, flavours and licensing models used in the past.

vCenter is licensed by the number of instances of vCenter that you have running in your environment.

Pricing and Packaging of VMware Technologies is an endless evolving process – we recommend you consult VMware’s online documentation for up to the minute data. vSphere Enterprise Plus (the most functional version of vSphere) is available as part of the vCloud Suite – which offers not just vSphere but other components required to build the “cloud” or the new “Software Defined Datacenter”.

This white paper (PDF) offers a high level view of vCloud Suite licensing for version 5.5:

Screen Shot 2013-11-04 at 13.22.49.png

Adding Licenses to vCenter:

1. Navigate to >> Licensing >> License

2. Click the Green + symbol to add a license

Screen Shot 2013-11-04 at 13.27.22.png

3. Type your license key into the edit box.

4. The key should then be validated – and report the Product Type, Capacity, and expiration date (if applicable)

Screen Shot 2013-11-04 at 13.32.17.png 5. Next we can assign these license keys to the appropriate asset. In this case these are VMware ESX host licenses. Select the Host tab

6. Select the all the VMware ESX hosts, and click the Assign License Key button

Screen Shot 2013-11-04 at 13.34.58.png

7. In the subsequent dialog box, select the license key to be assigned

Screen Shot 2013-11-04 at 13.35.59.png

Note: This self same workflow can be used to input the vCenter license and assign them to the vCenter. Once the license have been inputted and assigned, the licensing node shows a very simple view of what licenses have been used, and how much free is available.

Screen Shot 2013-11-04 at 13.40.56.png

In this case 1 vCenter license has been assign, and there is 1 vCenter license left. Three VMware ESX hosts with two physical CPU sockets completed – consume 6 CPU license in total, leave 10 CPU socket license left. This would allow for another 5 VMware ESX host of this specification to be added before the organization would run out license allocation.

Enabling Network Time Protocol (NTP) Settings

In most cases, Virtual Machines acquire their system time from the VMware ESXi Host. In this case the “VMware Tools” service synchronises time with the underlying physical host. For this reason its imperative that the VMware ESXi host has the correct time allocated to it. Additionally, other system process such as logging will display skewed time information if the system date/time is inaccurate, further complicating the troubleshooting process. Typically, VMware ESXi hosts are configured to use an external time source running the NTP protocol. This can be a local to the organization network, or alternatively utilizes the network of public NTP servers available on the Internet.

1. In the vSphere Web Client navigate to: >>Hosts & Clusters >>Select vCenter >>Select Datacenter >> Select ESX host

2. Select the Manage tab, and Settings column 3. Expand >> System and select Time Configuration

Screen Shot 2013-11-11 at 13.16.16.png

4. Click the Edit button to modify the configuration

5. In Edit Time Configuration dialog box, select the radio button Use Network Time Protocol

6. Change the Start-up Policy to be Start and Stop with host

7. In the NTP Server field type the IP address or name of the NTP servers you wish to use. Multiple NTP servers can be specified for resiliency, each separated with comma.

Screen Shot 2013-11-11 at 13.21.12.png

8. Click OK to confirm the configuration.

9. Finally, click the Edit button again – and click the button to Start the NTP Service.

Screen Shot 2013-11-11 at 13.23.52.png

Adding ESX host to Microsoft Active Directory Domain

By default a VMware ESXi host a local database of user accounts where the ‘root’ account is held. Typically, these user accounts are only visible from the now legacy ‘vSphere Client’ when directed directly at the ESXi host under the “Local Users & Groups” tab.

Screen Shot 2013-11-11 at 13.47.59.png

Note: The VPX and DCUI accounts are system accounts used by vCenter and Direct Console User Interface respectively.

It is possible to reconfigure the ESXi host to be joined to the Microsoft Active Directory Domain, and source users and groups from this LDAP source, rather than using local groups. There are two main ways to achieve this configuration. One uses either the vSphere Client or PowerCLI to join the ESXi host to the domain. This requires credentials sufficient in Active Director to complete the process. Alternatively, the vSphere Authentication Proxy can achieve the same result without the need for domain credentials.

Join VMware ESXi host to Domain:

1. Open the vSphere Client on the ESX host click the Configuration tab and select Authentication Services under the Software Pane.

2. Click the Properties… link

Screen Shot 2013-11-11 at 14.34.14.png

3. Select Active Directory under the Directory Services Type

4. Under Domain Settings, type in the name of name – for example

5. Click the Join Domain button

Screen Shot 2013-11-11 at 14.37.10.png

6. In the subsequent Join Domain dialog box, provide credentials to join the ESXi host to the domain

Screen Shot 2013-11-11 at 14.38.28.png

“Assign Permissions to Active Directory Group”

1. Under the Permission tab. right-click and select Add Permission

Screen Shot 2013-11-11 at 14.48.58.png

2. In the Assign Permissions dialog box, click the Add button

3. Select the AD Domain from the Domain list

4. Select Shows Groups First from the pull-down list, and select a group to have admin rights, and Click Add

Screen Shot 2013-11-11 at 15.08.19.png

5. Assign the role of Administrator to the group

Anyone who is member of the group added should be able to log into the vSphere Client on the ESX host. This includes other protocols and utilities such as SSH/PuTTy (assuming they have been enabled) so long as the user supplies their credentials in the DOMAIN\username format.

Screen Shot 2013-11-11 at 15.13.53.png

Post-Configuration of vCenter Install (PowerCLI)

This section essentially repeats the same configuration as carried out in the web-client, but instead uses VMware’s PowerCLI extensions to Microsoft’s PowerShell. It does include “bulk administration” methods which can substantially reduce the time it takes to complete repetitive tasks. If you wish to carry on in the next part of the wiki on vCenter, then you can buy pass this section to look how vCenter is installed and configured in the context of multiple vCenters and Linked Mode:

A Simple Install of vCenter – Linked Mode

Alternatively, if you are working in a single vCenter environment you may wish to move to look at installing VMware’s patch management solution called “Update Manager” or consider installing some of the more ancillary services associated with vCenter.

Creating vCenter Datacenters

Screen Shot 2013-10-21 at 14.01.16.pngCreating Datacenter Example:

New-Datacenter -Location (Get-Folder -NoRecursion) -Name "New York"
Adding VMware ESX hosts

Adding ESX host using PowerCLI can be done in a number of ways. Individually, by specifying each ESX hosts, or in a more bulk methods. One bulk method is to use a .CSV file to hold the names of the ESX hosts you wish to add, another uses a for each loop to add ESX hosts from 01-08. This methods assumes you have a naming convention that includes an number to differentiate one host from another such as esx01nyc, esx02nyc, esx03nyc and so on. The add-vmhost cmdlet does not support the enablement of the lockdown feature – and if required has to be configured as separate PowerCLI step.

Screen Shot 2013-10-21 at 14.01.16.pngSimple Add and Lockdown Example

add-vmhost -location "New York" -user root -password Password1 -force:$true
(get-vmhost| get-view).EnterLockdownMode()

Screen Shot 2013-10-21 at 14.01.16.pngBulk Add by using a unique number

In this script ESX hosts are added by their unique number. The script loops round from 1 to 9 times using a “range” in PowerShell, adding esx01nyc, esx02nyc and so on. The “{0:00}” handles the situation where the naming convention contains a leading zero in the series such as 01, 02, 03, 04, 05, 06, 07, 08, 09, 10 and so on…

Acknowledgement: This script to was written with assistance from Alan Renouf. Alan’s personal blog is available at and he tweets as @AlanRenouf

1..16 | Foreach {
	$Num = "{0:00}" -f $_
	add-vmhost esx"$Num" -location "New York" -user root -password Password1 -force

Screen Shot 2013-10-21 at 14.01.16.pngBulk Add of ESX hosts by CSV File Example

Create a a CSV file called vmhosts.csv and formatted like so. CSV files can be populated with any number of variables that can be in turn called by your PowerCLI scripts. PowerCLI scripts are merely text files saved with the .PS1 extension, and executed from the PowerCLI prompt with a ./addhost.ps1 command.

Screen Shot 2013-11-04 at 10.29.18.png

Then create an addhosts.ps1 script file with a text editor:

Import-CSV c:\vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
add-vmhost $hostname -location "New York" -user root -password Password1 -force

Below is the results of the script using the CSV method to bulk add many ESX hosts:

Screen Shot 2013-11-04 at 11.01.48.png

Creating vCenter Folder Structure

Creating folders for VMs and Templates can be carried out using the New-Folder cmdlet. The default location if no location is specified is the “Hosts & Clusters” view in vCenter. Using a combination of Get-Datacenter and Get-Folder cmdlet we can force the folder to be created any view that supports the creation of folders. For example the following scripts creates this folder structure in the “VM & Templates” view.

It uses the variable $toplevel to find the upmost location in the inventory in a datacenter called “New York”, and then re-uses that variable to create the top level folder structure:

Screen Shot 2013-11-04 at 12.33.43.png

Screen Shot 2013-10-21 at 14.01.16.pngSimple VM Folder Creation Example

$toplevel = (Get-Datacenter "New York" | Get-Folder -name vm)
New-Folder -name "CorpHQ" $toplevel
New-Folder -name "COIG" $toplevel
New-Folder -name "iStocks" $toplevel
New-Folder -name "Quark" $toplevel
Remove-Folder -Folder "Discovered Virtual Machine" -Confirm:$False

Note: Remove-Folder supports a -DeletePermanently switch which could be dangerous. The Remove-Folder cmdlet can also delete and destroy VMs that are contained within the folder. Use with caution.

Licensing vCenter and ESX Hosts

Screen Shot 2013-10-21 at 14.01.16.pngAdding Licenses to vCenter

$si = Get-View ServiceInstance

$LicManView=Get-View $LicManRef
$license = New-Object VMware.Vim.LicenseManagerLicenseInfo

$si = Get-View ServiceInstance
$LicManView=Get-View $LicManRef
$license = New-Object VMware.Vim.LicenseManagerLicenseInfo

The result of this script outputs like so:

Screen Shot 2013-11-04 at 15.23.01.png

Screen Shot 2013-10-21 at 14.01.16.pngAssigning Licenses to ESX hosts

Foreach ($vmhost in (get-vmhost))

	$targethostMoRef = (get-VMHost $vmhost | get-view).MoRef
	$si = Get-View ServiceInstance
	$LicManView=Get-View $LicManRef
	$licassman = Get-View $LicManView.LicenseAssignmentManager
	$licassman.UpdateAssignedLicense($targethostMoRef.value,"XXXXX-XXXXX-XXXXX-XXXXX-XXXXX","VMware vCloud Suite Enterprise")


The result of this scripts outputs like so:

Screen Shot 2013-11-04 at 15.23.01.png

Screen Shot 2013-10-21 at 14.01.16.pngRetrieving License Data

Acknowledgement: This script to retrieve licensing data originally appeared in the official VMware PowerCLI blog and was written by Alan Renouf. Alan’s personal blog is available at and he tweets as @AlanRenouf

# Get the license info from each VC in turn 
$vSphereLicInfo = @() 
$ServiceInstance = Get-View ServiceInstance 
Foreach ($LicenseMan in Get-View ($ServiceInstance | Select -First 1).Content.LicenseManager) { 
    Foreach ($License in ($LicenseMan | Select -ExpandProperty Licenses)) { 
        $Details = "" |Select VC, Name, Key, Total, Used, ExpirationDate , Information 
        $Details.VC = ([Uri]$LicenseMan.Client.ServiceUrl).Host 
        $Details.Name= $License.Name 
        $Details.Key= $License.LicenseKey 
        $Details.Total= $License.Total 
        $Details.Used= $License.Used 
        $Details.Information= $License.Labels | Select -expand Value 
        $Details.ExpirationDate = $License.Properties | Where { $_.key -eq "expirationDate" } | Select -ExpandProperty Value 
        $vSphereLicInfo += $Details 
$vSphereLicInfo | Format-Table -AutoSize
Enabling Network Time Protocol (NTP) Settings

Screen Shot 2013-10-21 at 14.01.16.pngEnabling NTP Service

The cmdlet Add-VmhostNtpServer and Get-VMHostService can be used to both configure the NTP servers, the start-up policy as well as starting the service.

Foreach ($vmhost in (get-vmhost))
Add-VmHostNtpServer -NtpServer "","" -VMHost $vmHost | Out-Null
Get-VMHostService -VMHost $vmHost | where{$_.Key -eq "ntpd"} | set-vmhostservice -policy "on" -Confirm:$false
Get-VmHostService -VMHost $vmHost | Where-Object {$_.key -eq "ntpd"} | Start-VMHostService -Confirm:$false | Out-Null

Screen Shot 2013-10-21 at 14.01.16.pngConfirming NTP Service has started & configured correctly

Confirming the NTP Service has started and viewing its configuration can be achieved with this PowerCLI “one-liner”. This was found on Alan Renouf’s website –

Get-VMHost |Sort Name|Select Name, @{N=“NTPServer“;E={$_ |Get-VMHostNtpServer}}, @{N=“ServiceRunning“;E={(Get-VmHostService -VMHost $_ |Where-Object {$_.key-eq “ntpd“}).Running}}

Screen Shot 2013-11-11 at 13.43.04.png

Adding ESXi hosts to Microsoft Active Directory Domain

Screen Shot 2013-10-21 at 14.01.16.pngAdding ESXi Host to Active Directory & Assigning a Group Permissions

Foreach ($vmhost in (get-vmhost))
Get-VMHostAuthentication -VMHost $vmhost | Set-VMHostAuthentication -Domain -User administrator -Password Password1 -JoinDomain -Confirm:$false

A Simple Install of vCenter – MultiSite SSO and Linked Mode Configuration

IMPORTANT: In order for “Linked Mode” to work during installation the user account carrying out the installation needs rights to both installations. To quote from the vCenter installation guide:

When you join a vCenter Server instance to a Linked Mode group, the installer must be run by a domain user who is an administrator on both the machine where vCenter Server is installed and the target machine of the Linked Mode group.

For instance insufficient rights can cause these types of warnings and errors:

Screen Shot 2013-11-05 at 19.56.44.png

For this reason some administrators prefer carry out the linked mode configuration after the main installation has completed, and once both vCenter have a user account with full administration rights.

It’s entirely possible that you may wish to install another vCenter at different site or location. The installation of subsequent vCenters looks and feels different dependent on the configuration you are building. This caused by installation of SSO differs in this respect around the technologies of SSO. We have not chosen not to repeat the same configuration steps as shown previously. Instead we emphasised what is different about this first installation. In this configuration we had a single SSO and single Active Directory Domain – but with two SSO sites – one called New York, and the other called New Jersey.

SSO in a Multi-Site Configuration

1. Once the prerequisites have been checked, if the install detects that SSO has already been installed once before to the same domain, you will be challenged with this dialog box:

Screen Shot 2014-07-29 at 12.09.05.png

As the radio buttons indicate the 1st option is used for first install of SSO, the other two options allow you indicate if subsequent SSO/vCenter installations are for a new vCenter in the SAME site, or a new vCenter in a DIFFERENT site. In our case, we are installing a second vCenter called “vcnj” which is the vCenter for the site of New Jersey which is in the same CORP.COM domain. In this case we would select the 3rd radio button.

2. SSO Server are paired together to allow them share credential data, as such we need to supply the FQDN/password of the partner SSO/vCenter service in New York.

Screen Shot 2013-11-05 at 14.16.46.png

3. This should then retrieve the certificate of the partner SSO/vCenter:

Screen Shot 2013-11-05 at 14.20.20.png

4. In this case we are able to specify the new SSO site name (if the 2nd radio button had been used, you would only be able to select the site defined by the installation of the 1st SSO server.

Screen Shot 2013-11-05 at 14.22.02.png

5. A summary appears outlining the configuration selected.

Screen Shot 2013-11-05 at 14.22.48.png

Note: There is an error in the screen grab it should read “Selected Site name is NewJersey, and partner site name is NewYork”

Web Client installation in a Multi-Site Configuration

1. The installation of Web-Client to subsequent vCenters differs because during the part of the process where the Web Client registers with the SSO, you will be challenged for the SSO administrator password. Providing this will retrieve the SSO Lookup certificate:

Screen Shot 2013-11-05 at 14.46.55.png

Inventory Service installation in a Multi-Site Configuration:

1. As with the Web Client installation the Inventory Service install will also need credentials to register itself correctly:

Screen Shot 2013-11-05 at 15.22.49.png

2. In order for the Web-Client to work with the URL’s provided a certificate must be installed.

Screen Shot 2013-11-05 at 14.51.10.png

3. The rest of the installation follows a familiar partner of registering the vCenter server with appropriate components

Screen Shot 2013-11-05 at 19.59.05.png

Screen Shot 2013-11-05 at 20.00.53.png

Screen Shot 2013-11-05 at 20.01.24.png

vCenter with Linked Mode in a Multi-Site SSO Configuration

Once you have completed most of the vCenter installation, the administrator is asked if “Linked Mode” should be enabled. Linked Mode is a very powerful feature, and can make administration tasks much simpler as from one Web Client or vSphere Client the administrator can manage multiple environments seamlessly.

1. On the vCenter server login as “administrator”, and run the vCenter Server Linked Mode Configuration from the >>Start >>Program >>VMware folder

2. Select to Modify Linked Mode configuration

3. Select Join vCenter Server instance to an existing Linked Mode group or another instance

You should receive a secondary prompt, warning to confirm that both vCenters are of the same version

Screen Shot 2013-11-05 at 18.24.00.png

4. Next type the URL of the vCenter at the other site, in our case this is the New York vCenter Server

Screen Shot 2013-11-05 at 18.25.06.png

Granting User Rights in the Second vCenter

At this stage only the shared, built-in SSO user of administrator@vsphere.local will have rights to BOTH vCenters. If you want to both vCenters to be available to the administration team, the administrator would need to grant this group rights.

1. Login to the Web Client vCenter server as administrator@vsphere.local

2. Select >>vCenter >>vCenter Servers

3. Select the new vCenter server in the Inventory.

4. Select the Manage tab, and the Permissions column

5. Click the green + to add a user group

6. Use the Add button to browse the Active Directory domain, and add your group

7. Grant this group the appropriate rights. In our case the CORP\vCenter Admins group was allocated the Administrator the role

Screen Shot 2013-11-05 at 21.38.34.png

Installing VMware Update Manager (VUM)

VMware Update Manager (commonly abbreviated to VUM) is currently the companies primary method updating both VMware ESX hosts, and all so “upgrading” the VMs “virtual hardware” and small software package installed to the guest operating system called “VMware Tools”. As new versions of VMware ESX are released, the version of the VM evolves accordingly. This referred to as virtual machine “compatibility” levels. VUM can be used to update VMware ESX from one sub-release to another, and it can also be used to whole sale upgrades from one release to another as well.

VUM may not be appropriate for all methods of deploying VMware ESX. If the organization for instance has opted for stateless “Auto Deploy” model then VUM would not be applicable. Auto Deploy boots the ESX host across the network using a “image” and profile. In this model if a new version of ESX is release the image is merely replaced, and the host placed in maintenance mode, and rebooted. The first boot cause the new image to be loaded across the network and made resident in memory. VUM usage is more relevant to an scenario where ESX has been “installed” to disk. With this said, some organizations scripted installation are so sophisticated – they find it as easy to merely re-install the host when need additions are released. Alternatively, occasionally organizations opt for a twin-track approach using VUM for patching the ESX host within a sub-release, but opting to redeploy when new major release is shipped.

Like vCenter, VUM requires backend database – and allocation of disk space for storing the download of patches and updates. In our case we opted to install VUM to the same Windows instance that vCenter executes on – and separate D: drive has been created to hold the downloads. VUM does require access to the internet for downloading updates, but in highly secure environments it is possible to have the VUM service “offline”, and move these patches from separate internet connected system.

Unlike vCenter, VUM is 32-bit application – and as such requires 32-bit DSN to communicate to the VUM database.

When VUM is installed it will ask for location for downloading and saving patches. The location selected should have at least 120GB or greater otherwise you will receive a warning during the installation.

Screen Shot 2013-11-06 at 20.38.19.png

Creating a 32-bit DSN

1. Login as the VUM Service Account. In this example it is called “vumdbuser-nj”. Ensure this account has local administrator rights to complete the installation

2. Open the 32-bit ODBC Manager located at C:\Windows\SysWOW64 and is called odbcad32.exe

3. Select the System DSN tab and Click Add

4. From the long list select SQL Server Native Driver

5. In the Create a New Data Source to SQL Server, type a friendly name for the DSN Connection, and the name of the SQL Server

Screen Shot 2013-11-06 at 18.19.03.png

6. Select “with Integrated Windows Authentication

Screen Shot 2013-11-06 at 18.20.32.png

7. Ensure the default database is the VUM Database in SQL Server

Screen Shot 2013-11-06 at 18.21.42.png

Installing VMware Update Manager

1. Open the main autorun.exe to view the VMware vCenter Installer

2. Under the VMware vCenter Support Tools, select vSphere Update Manager and Click the Install button

Screen Shot 2013-11-06 at 18.25.36.png

3. In this simple install we will have a single repository, rather than multiple VUM Server sharing a repository

Screen Shot 2013-11-06 at 18.48.07.png

4. Next we need to register the VUM server with vCenter, as well specifying an administrative account to complete the registration. This dialog box defaults to the IP address of the vCenter (when same Windows instance is being used). Many administrators prefer to use a FQDN instead.

Screen Shot 2013-11-06 at 18.53.57.png

5. Select the option to Use a supported database, and from the pull-down list select the DSN Connection earlier

Screen Shot 2013-11-06 at 20.33.46.png

6. Click Next to the Authentication Settings.

Screen Shot 2013-11-06 at 20.33.58.png

7. Set the connection information. This dialog box defaults to an IP address. Many administrator prefer to use the FQDN in case they need to change the IP address at later stage.

Screen Shot 2013-11-06 at 20.37.28.png

8. Adjust the paths to the location for the software, and the patches…

Screen Shot 2013-11-06 at 20.38.42.png

Note: One aspect of the VUM installation that some people have observed is the inability of the installer to set the “service account” used by VUM when using Windows Authentication for SQL. This can result in the service starting, but not being able to access the database correctly. To fix this issue one merely needs to change the “Service Account” back the VUM Service to be the user account used to carry out the installation and access the database. The service account can be modified using the Services MMC, and locating the “VMware vSphere Update Manager Service” in the list. Next browse for the account in Active Directory, and supply the password – click yes to the message the grant the account the right to logon as service.

Screen Shot 2013-11-25 at 10.48.43.png

Installing VMware Update Manager Plug-in

VUM has not been integrated to the vSphere Web Client, instead it is managed by the now legacy vSphere Client. A plug-in needs to be installed to extend the functionality of the vSphere Client to allows its management.

1. Open the vSphere Client, and log into the vCenter

2. From Plug-ins menu, select Manage Plug-ins

3. This should show the plug-in manager, that will show the VMware vSphere Update Manager, and blue link to download and install the plug-in.

Screen Shot 2013-11-06 at 21.09.48.png

4. At the end of the install, the plug-in will attempt to connect to the VUM server, accept the default certificate that is presented.

Screen Shot 2013-11-06 at 21.16.51.png

Note: This should add an Update Manager icon to the “Solutions and Application” portion of the vSphere Client:

Screen Shot 2013-11-06 at 22.08.17.png

Installing Other Optional vCenter Services

ESXi Dump Collector

By default if a critical error happens to the VMware ESX host a “dump” will take this place. This is not dump of memory, but of configuration data. VMware ESX hosts with local storage are capable of dumping this data to local storage, but stateless system may not have storage to carry out this process. Regardless of how VMware ESX is installed, your organization might prefer to have these centrally located. The ESXi Dump Collector allows for this type of configuration.

1. Open the vSphere vCenter Installer

2. Under VMware vCenter Support Tools, select vSphere ESXi Dump Collector and click Install

3. Adjust you paths to reflect a storage location that keeps the dump files away from your operating system.

Screen Shot 2013-11-08 at 18.38.38.png

Note: It is possible to limit the amount of disk space allocated to the Dump Collector Repository in increments of GB. Whatever allocation of storage you assign, you must ensure the destination has the free space on that storage location.

4. In this case the ESXi Dump Collector is being installed to the vCenter Instance, so selecting “VMware vCenter Server Installation” is the most appropriate option.

Screen Shot 2013-11-08 at 18.41.26.png

5. Next complete the standard dialog box to register the ESXi Dump Collector with the vCenter instance.

Screen Shot 2013-11-08 at 18.43.27.png

Note: You should be presented with a certificate thumbprint to accept. Typically VMware redirects port 80 connections to port 443 or some other SSL secure port number.

6. Accept the default ESXi Dump Collection TCP port number

Screen Shot 2013-11-08 at 18.58.26.png

7. Accept the FQDN as the method by which the ESXi Dump Collector identifies itself to the ESXi host

Screen Shot 2013-11-08 at 19.01.28.png

In whether in a vCenter mode or stand-alone , the VMware ESX hosts will need to be manually configured for the ESXi Dump Collector. This can be done using PowerCLI which in turn calls the esxcli interface can be used to get, set and enable the configuration on the ESXi host. The configuration only support an IP address for specifying the ESXi Dump Collector identity.

Acknowledgement: I would like to thank Chris Murray blogger at for his article Using the vSphere 5.1 ESXi Dump Collector

Screen Shot 2013-10-21 at 14.01.16.pngCheck the ESXi Dump Collector Configuration Example:

Foreach ($vmhost in (get-vmhost))
$esxcli = Get-EsxCli -vmhost $vmhost

Screen Shot 2013-10-21 at 14.01.16.pngSetting the ESXi Dump Collector Example:

Foreach ($vmhost in (get-vmhost))
$esxcli = Get-EsxCli -vmhost $vmhost
$$null, "vmk0", "", "6500")

Acknowledgement: This part of this article was found online at Kyle Gleed’s blogpost Setting up the ESXi 5.0 Dump Collector.

If you wish to hard test this – a crash can be invoked at the physical console with the vsish command

# vsish -e set /reliability/crashMe/Panic 1

Issuing this command at the physical console will cause the ESX host to panic, and produce a purple screen of death (PSOD). Notice how the dump process is transferring configuration data to the ESX Dump Collector IP address.

Screen Shot 2013-11-09 at 14.13.05.png

You should find the dump file in the path specified during the installation, held in subdirectories which reflect the Management IP address of the ESX host. Generally, these dump files are uploaded to VMware Support for further analysis. PSOD are in the main caused by faulty hardware such as fault RAM or badly seat memory after an upgrade.

Screen Shot 2013-11-09 at 14.38.37.png

Finally, you should find that with “vCenter Installation” that there is an icon for the ESXi Dump Collector. This icon doesn’t actually do much, but it does show what the current configuration is for the service. Incidentally, this icon does not currently appear in the vSphere Web Client.

Screen Shot 2013-11-09 at 15.25.24.png

Syslog Collector

By default VMware ESXi stores its core log files on a local partition. These can be accessed in a number of different ways remotely using an array of different client tools. However, so administrator prefer to collect these at a central location for ease of access or for further parsing by log analyse tools. Again, the SysLog Collector will be of specific interest to those who have adopted a stateless “Auto Deploy” model for rolling out VMware ESXi. In this scenario log files are stored temporarily on scratch storage, and lost after a reboot.

1. Open the vSphere vCenter Installer

2. Under VMware vCenter Support Tools, select vSphere SysLog Collector and click Install

3. Adjust you paths to reflect a storage location that keeps the logs files away from your operating system. You can set the size of the log files, and frequently they should be rotated

Screen Shot 2013-11-09 at 14.48.48.png

4. Select a VMware vCenter Server Installation. This registers icon with the vCenter Server.

Screen Shot 2013-11-09 at 14.50.56.png

5. In the subsequent dialog box, complete the fields to register the SysLog Connector with vCenter, and accept the certificate when prompted.

Screen Shot 2013-11-09 at 14.52.12.png

6. Accept or modify the TCP port settings relative to your environment

Screen Shot 2013-11-09 at 14.57.27.png

7. Select how the SysLog Collector will identify its self on the network, in this case by FQDN rather than by IP address.

Screen Shot 2013-11-09 at 15.00.34.png

In whether in a vCenter mode or stand-alone , the VMware ESX hosts will need to be manually configured for the ESXi SysLog Collector. This is the same situation as with the ESXi Dump Collector service. Similarly, this configuration can be done using PowerCLI which in turn calls the esxcli interface can be used to get, set and enable the configuration on the ESXi host. The configuration only support an IP address for specifying the ESXi SysLog Collector identity.

Screen Shot 2013-10-21 at 14.01.16.pngCheck the ESXi Dump Collector Configuration Example:

The field “RemoteHost” should indicate <none> indicating now host is configured to hold its SysLog files on the SysLog Collector.

Foreach ($vmhost in (get-vmhost))
$esxcli = Get-EsxCli -vmhost $vmhost

Screen Shot 2013-10-21 at 14.01.16.pngSetting the ESXi Dump Collector Example:

In this case, PowerCLI enabled the “Remote Host” parameter, restarts the syslog service – and then opens the Syslog port on 514.

Foreach ($vmhost in (get-vmhost))
$esxcli = Get-EsxCli -vmhost $vmhost
$esxcli.system.syslog.config.set($null, $null, $null, $null,"udp://")
get-vmhost| Get-VMHostFirewallException |?{$_.Name -eq 'syslog'} | Set-VMHostFirewallException -Enabled:$true

After a short while you should see syslog populating the directory structure in the SysLog collector by IP address of the ESX host.

Screen Shot 2013-11-11 at 11.59.44.png

Auto Deploy

Auto Deploy is method of rolling out VMware ESXi that allows for stateless configuration – in which the physical host does not boot from media, but instead boots over the network using the Pre-Execution Environment (PXE) capabilities of many modern network cards. In Auto Deploy the ESXi Host boot to PXE, and an “image” of ESXi is loaded across the network. Once booted the ESXi hosts retrieve the remainder of their configuration from vCenter system of “Host Profiles”. Auto Deploy does require use of Enterprize Plus vSphere licensing, and is therefore a feature not every vSphere environment has access to. Auto Deploy will appeal to large scale environments that have many ESX hosts to manage, and want a simple and easy method to both deploy ESX to the environment, but also do away with the process of patch management with technologies like VMware Update Manager which is used to patch and upgrade systems that have been installed to disk.

Note: If your organization has no intention of using the Auto Deploy feature or is not licensed to use Host Profiles – this installation can be skipped altogether.

The use of Auto Deploy is covered elsewhere in the vmWIKI, this article merely covers the base installation.

1. Open the vSphere vCenter Installer

2. Under VMware vCenter Support Tools, select vSphere Auto Deploy and click Install

3. In the Destination Folder options change the location for the Auto Deploy files to reflect your preferred storage location. You can also set a maximum size of the auto deploy repository.

Screen Shot 2013-11-11 at 12.58.51.png

4. Next specify the connection options to communicate with the vCenter Server, and accept the default certificate.

Screen Shot 2013-11-11 at 12.59.51.png

5. Next accept or adjust the Auto Deploy TCP port settings as fits your network

Screen Shot 2013-11-11 at 13.01.26.png

6. Finally, specify how the Auto Deploy service will be identified on the network

Screen Shot 2013-11-11 at 13.02.39.png

Authentication Proxy

The Authentication Proxy allows an VMware Administrator to join VMware ESXI hosts to the Active Directory domain without the need of domain privileges. It’s a service which is dependent on both IIS and Microsoft .NET 3.5 SP1 to function. Both vCenter and IIS attempt to claim TCP 80 for their use. So its important after install Microsoft IIS, to change the default port for http/80 to a different port number to prevent conflicts. Alternatively, the Authentication Proxy could be installed to a different Windows Instance where no such conflict could occur.

The configuration of the Authentication Proxy is not a small undertaking. You should really examine your requirements closely before embarking on its setup.

Installing Microsoft IIS on Windows 2008 R2:

1. Open Server Manager, and under Roles – select Add Roles

2. In the Select Server Roles dialog box select Web Server (IIS)

Note: If Prompted select to Add Required Features

Screen Shot 2013-11-11 at 17.56.31.png

3. Carry out a default installation of IIS adding these additional components:

  • IIS6 MetaBase Compatibility
  • ISAPI Extensions
  • IP and Domain Restrictions

Note: Once the installation has completed we need to change the IIS Default Port number for the Default Site.

4. In Administrative Tools open the Internet Information Service (IIS) Manager. Expand +ServerName, +Sites +Default Site

Screen Shot 2013-11-11 at 18.14.35.png

Notice: The Default Site has stopped as it encountered a TCP Port conflict with vCenter.

5. Under the Actions pane on the right-hand side, select Site Binding

6. Click the Edit button, and change the port number to a free TCP Port Number. The command netstat -a -p TCP will list all the TCP ports used. Using this with the FINDSTR command can be used to check if a port number is in use such as “netstat -a -p TCP | FINDSTR 1080. If no response is given the port number is free. If a port number and service is return then the port is in use. For example netstat -a -p TCP | FINDSTR 8080 returns a value that it is in use.

Screen Shot 2013-11-11 at 18.24.15.png

Screen Shot 2013-11-11 at 18.24.50.png

7. Next right-click the Server and Stop/Start the Service, and then right-click the Default Site and Start it.

Installing the Authentication Proxy:

1. Unlike other additional components the authentication proxy is service that does consume or generate much disk space – unlike the Dump Collector, SysLog Connector or Auto Deploy. In this case it is safe to install it to the default location on the C drive assuming you have free space.

Screen Shot 2013-11-11 at 18.47.15.png

2. Specify the connection details for the vCenter server

Screen Shot 2013-11-11 at 18.47.36.png

3. Select how the Authentication Proxy will identify itself on the network

4. Once the installation has completed, the Authentication Proxy will have defined a new website in IIS. Security settings need to be adjust on this site to reflect your organisations configuration. This includes adding an IPv4 allow range for any ESX hosts that act as DHCP Clients, and also downloading the certificate generated during the installation.

Screen Shot 2013-11-11 at 19.40.52.png

5. In IIS Manager, Expand the +Computer Account Management Web Site, Select the virtual directory CAM ISAPI

6. In the left pane and open IPv4 Address and Domain Restrictions.

7. Select Add Allow Entry > IPv4 Address Range

Screen Shot 2013-11-11 at 19.47.45.png

8. Click Computer Account Management Web Site in the left pane.

9. Select Site Bindings

10. Select https binding

11. Select Edit and View SSL Certificate

12. Select Details and Copy to File

Screen Shot 2013-11-11 at 19.52.55.png

13. Select the options Do Not Export the Private Key and Base-64 encoded X.509 (CER).

14. Next this certificate file needs to be upload to the ESX host. Using the Datastore Browser, and then imported into the ESXi Host

Screen Shot 2013-11-11 at 19.58.37.png

15. Open the vSphere Client on the ESX host click the Configuration tab and select Authentication Services under the Software Pane.

16. Click the Import Certificate… link. Type the datastore location and file path to the certificate together with the IP address of the Authentication Proxy. The syntax is the name of the datastore with angle brackets [datastorename] followed by a space and the name of the certificate in this case “AuthenticationProxyCertificate.cer”

Screen Shot 2013-11-26 at 14.29.20.png

Configure the VMware ESX host to use the Authentication Proxy:

Note: During the install a domain account is generated with appropriate privileges to run the authentication proxy service. The account name begins with the prefix CAM- and has a 32-character, randomly generated password associated with it. The password is set to never expire. Do not change the account settings.

Screen Shot 2013-11-11 at 19.36.52.png

1. Open the vSphere Client on the ESX host click the Configuration tab and select Authentication Services under the Software Pane.

2. Click the Properties… link

Screen Shot 2013-11-11 at 14.34.14.png

3. Select Active Directory under the Directory Services Type

4. Under Domain Settings, type in the name of name – for example

5. Enable the option X Use vSphere Authentication Proxy, and type the IP address of the Authentication Proxy

Screen Shot 2013-11-11 at 19.30.30.png

6. Click the Join Domain button

Using the Certificate Automation Tool



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s