Home > Blogs > VMware Consulting Blog > Monthly Archives: September 2015

Monthly Archives: September 2015

New! Making Your Move to the Cloud – Part 2: Best Practices for Building a Migration Plan

In Part 2 of the “Making Your Move to the Cloud” series, Michael Francis and RadhaKrishna (RK) Dasari discuss best practices for building a Cloud migration plan for your organization.migration to cloud

“The primary technological goal of any migration project is to transfer an existing compute resource/application from one environment to another, as quickly, efficiently, and cost effectively as possible. This is especially critical when considering a migration to a public cloud; considerations must include security controls, latency and subsequent performance, operations practices for backup/recovery and others. Though VMware now provides technology in Hybrid Cloud Manager to minimize any downtime or eliminate downtime; these considerations persist. VMware Professional Services often assist customers with assessing their environment and focusing on generating an effective, actionable migration plan to achieve this goal. It adopts the philosophy of spending the time up front in the plan to reduce the time and increase likelihood of success of a subsequent migration project.”

Read the full blog for more information: http://vmw.re/1LhuAQ8 

VMware Certificate Authority, Part 2: My Favorite New Feature of vSphere 6.0 – The Architecture

jonathanm-profileBy Jonathan McDonald

Picking up where Part 1 left off, I will now discuss the architecture decisions I have seen commonly used for the VMware Certificate Authority. This comes from many conversations with customers, VMware Professional Services, VMware Engineering and even VMware Support. In addition to these sources I recently participated in many conversations at VMworld. I spoke at several sessions as well while I was manning the VMworld booth. I ended up with the opportunity to better appreciate the complexities, and also got to talk with some fantastic people about their environments.

Architecture of the Environment

Getting back to the conversation, the architecture of the environment becomes one that is incredibly important to design up front. This allows an administrator to avoid much of the complexity and allows for security to be kept. That being said, from my current experiences I have seen three different ways that environments are most frequently configured:

  • VMware Certificate Authority as the root CA in the default configuration
  • VMware Certificate Authority used but operating as a subordinate CA
  • Hybrid model using custom Machine SSL Certificates, but using VMware Certificate Authority in its default configuration.

Before we get into them, however, keep in mind that as I mentioned in my previous blog series regarding the architecture changes for vSphere 6.0, there are two basic platform service controller architectures that should be considered when designing your certificate infrastructure.

Be sure to note up-front whether an external or embedded Platform Services controller is to be used as this is quite important. The difference here is that a separate Machine SSL endpoint certificate would be required for each system.

This means that on an embedded system a single certificate is required as shown below:

JMcDonald 1

Or, for an external environment, two or more will be needed depending on the size of the infrastructure, as can be seen in the following figure.

JMcDonald 2

For further details on the different platform services controller architectures, and to become familiar with them before proceeding, see http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-1.html.

Using VMware Certificate Authority as the Root CA in the Default Configuration

This is by far the most common configuration I have seen deployed. Of course this is also the default, which explains why this is the case. Personally, I fully support and recommend actually using this configuration in almost all circumstances. The beauty of it is that it takes very little configuration to be fully secured. Why change something if you do not need to, right? By default, after installation everything is already configured to use VMware Certificate Authority and has already had certificates granted, which are deployed to all solutions and ESXi hosts, and are then added to vCenter Server.

In this situation the only thing required to secure the environment is to download and install the root certificate (or chain) from VMware Certificate Authority.

JMcDonald 3

Note: When you download this file in vSphere 6.0, it is simply called ‘download.’ This is a known issue in some browsers. It is actually a ZIP file, which contains the root certificate chain.

Once downloaded and extracted, the certificate(s) are the file(s) ending in .0. To install simply rename .0 to .cer and double-click to import to the Windows certificate store. Repeat the procedure for all certificates in the chain. The certificates should be installed into the Local Machine’s Trusted Root Certificate Authority or the Intermediate Certificate Authority stores respectively. If using Firefox, import to its proper store to ensure the chain is trusted.

The next time you go to the web page, it will show as trusted as in the following screenshot.

JMcDonald 4

This can potentially take some time if there are many clients who need to have certificates imported to them, however, this is the easiest (and default) deployment model.

Using VMware Certificate Authority as a Subordinate CA

This mode is less commonly used but it is the second largest deployment type I have seen. This takes a bit of work, but essentially it allows you to integrate VMware Certificate Authority into an existing certificate infrastructure. The big benefit to this is that you will issue completely signed certificates in the existing hierarchy, and in many cases no installation of the certificate chain is required. The downside is you will need a subordinate CA certificate to be able to implement the configuration in this way. I have seen this in some cases but it is simply not allowed by policy. This is where the hybrid configuration comes into play as discussed next.

To configure this use the command line utility called certificate-manager.

JMcDonald 5

Once launched, Option 2 is used to Replace VMCA Root Certificate with Custom Signing Certificate and to replace all certificates. The first part of the process is to generate the private key, and the certificate request that will be submitted to the Certificate Authority. To do this, select Option 1:
JMcDonald 6

Once generated, submit the request to the CA for issuance of the certificate, as well as collection of the root certificate chain. For more details, see KB article Configuring VMware vSphere 6.0 VMware Certificate Authority as a subordinate Certificate Authority (2112016).

When the new certificate has been collected, it is a matter of providing this new certificate, as well as the key, to the manager utility. If the certificate-manager screen is still open, select Option 1 to continue, otherwise select Option 2 and then Option 2 again. You will be prompted to provide the details for the certificate including all details for the certificate being issued. Once complete, services are stopped and restarted:

JMcDonald 7

After this the Machine Certificate (aka the Reverse Proxy certificate) can be regenerated from the VMware Certificate Authority for the vCenter Server(s) that are in the environment. This is done by selecting Option 3 from the menu:

JMcDonald 8

This will prompt for a Single Sign-On administrator password—as well as the Platform Services Controller IP—if the system is a distributed installation. It will then prompt you to enter the information for the certificate and restart the vCenter services. The server has its reverse proxy certificate replaced at this point.

The next step is to replace the solution user certificates by running Option 6 from certificate-manager:

JMcDonald 9

This completes the configuration of the custom certificate authority certificates for the vCenter components, but it is not quite done yet.

The final step is to replace the ESXi host certificates. This is done directly from each host’s configuration in the Web Client. The first step here is to set the details for the certificate in the advanced settings for the vCenter Server:

JMcDonald 10

When complete, navigate to an ESXi host and select Manage > Certificates. On this screen, click Renew. This will regenerate the certificate for this host.

JMcDonald 11

In any case, this is the most complex of the architectures shown, but it also is the most environmentally integrated as well. It provides an additional level of security that is required to satisfy compliance regulatory requirements.

Using Hybrid Configurations for the Reverse Proxy – but VMware Certificate Authority for All Other Certificates

Hybrid configurations are the middle ground in this discussion. It is a balance between security and complexity and also satisfies the security team in many cases as well. The biggest issues I have seen that require such a configuration such are:

  • Granting or purchasing a Subordinate CA certificate is not possible due to policy or cost.
  • Issuing multiple certificates to the same server, one for each service, is not something that can be done due to policy or regulatory requirements.
  • Controls to approve or deny certificate requests are required.

In these cases, although it may not be possible to fully integrate VMware Certificate Authority into the existing CA Hierarchy, it is possible to still provide added levels of security. In this case it is possible to leave VMware Certificate Authority in the default configuration, and replace the Machine certificate only. You can do this by using Option 1 from the Certificate Manager tool.

JMcDonald 12

When configured, the environment will use the corporate CA certificate for external user-facing communication because everything now goes through the reverse proxy. On the other side of things components are still secured by certificates from VMware Certificate Authority. The configuration should look like this:

JMcDonald 13

As you can see, the architectures are varied and also provide quite a bit of flexibility for the configuration.

Which Configuration Method Should You Use?

The only remaining question is – which method is the best for you to use? As stated in a previous section, my personal preference is actually to use the “keep it simple” methodology, and use the default configuration. The reason is it’s the simplest configuration, and the only requirement is that the root certificate is installed on clients rather than regenerating custom certificates, and then modifying the configuration.

Obviously where policy or regulatory compliance is concerned there may be a need to integrate it. This, although more complex than doing nothing, is also something that is much easier than it was in prior versions.

Hopefully all of this information has been of use to you for consideration when designing or configuring your different vSphere environments. As can be seen, the complexity has been dramatically reduced, and only promises to get better. I can’t wait till I complete the next blog in this series—part 3—which will provide even more detail that will make all of this even simpler.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

New! Making Your Move to the Cloud – Part 1: Building a Structured Approach to the Cloud



“If you’re considering moving to the cloud, you no doubt recognize that cloud computing represents the opportunity to minimize overhead and maximize agility so IT can deliver significant value back to the organization. By leveraging a more agile and efficient IT environment that leverages pools of elastic, self-managed virtual infrastructure—consumed as a service at the lowest possible cost—you can innovate more rapidly while maintaining reliability, security and governance for all applications and services under IT control.”

In this new blog post, Michael Francis and RadhaKrishna (RK) Dasari share their approach to the cloud. This four-part weekly series will help continue the discussion about the benefits of the cloud, address challenges, and provide tips and best practices.

Read the full blog here.

App Volumes Writable Volumes Orphaned

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and how Writable Volumes can become orphaned.

In some cases Writable Volumes can become orphaned as shown below.

JDavidson Writable Volumes 1

This status message can be confusing. The status message makes it seem as if the Writable Volume may be missing, or there is some other issue at hand. However, that may not be the case.

In some cases this orphaned state occurs when the owner user account in Active Directory is disabled, as shown below.

JDavidson Writable Volumes 2

When an account in Active Directory has been assigned an App Volumes—or a Writable Volume is disabled or deleted—the users’ Writable Volume can become orphaned when App Volumes synchronizes with Active Directory. As a result of this process, the status of the Writable Volume changes to orphaned.

Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.


User Environment Manager: Personal Management and Profile Unity to UEM

Jeremy WheelerBy Jeremy Wheeler

User Environment Management is the concept of managing a user’s persona across devices and locations. Using dynamic contextual policy control, VMware User Environment Manager gives IT a comprehensive profile management tool that supports physical, virtual, and cloud-hosted desktops and applications.  These policies deliver a consistent experience that adapts to the end-user’s needs. Regardless of how delivery is performed, end-users can access their desktops and applications with personalized and consistent settings across devices. UEM is focused entirely on the context of the user, and not the device the user is working on.

Have a look at this User Environment Manager Migrations technical document for step-by-step instructions on preparation and migration of Persona Management to UEM, and preparation, configuration and  migration of Profile Unity to UEM.

Jeremy Wheeler, Consulting Architect with the VMware End-User Computing Professional Services team, created this paper.

VMware would like to acknowledge the following people for their contributions to this document:

  • Devon Cassidy, Technical Support Engineer End User Computing, Global Tech Lead, VMware
  • Pim van de Vis, Technical, IT Infrastructure Architect, VMware

App Volumes AD Objects Move Issue

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and things to check when you are having trouble logging in.

There are times when a user may not be able to login to the App Volumes Manager Server. Users might get a message similar to “You must be in the Administrators group to login” as shown below. There can be a few reasons for this issue to occur.

App Volumes AD Objects Move Issue JDavidson 1

The first is that an administrators group needs to be defined in the App Volumes configuration, which is done during the initial setup of the App Volumes instance. Users need to be members of this group in order to login to the App Volumes Manager Server.

Secondly, you need to validate the App Volumes Manager Server to be able to communicate with the SQL instance configured during installation and Active Directory. The credentials for connectivity to both environments should be verified.

If you have validated that all of the above configurations are accurate and the services are running, there is one other thing you should investigate; this issue can occur if the user object has been moved in Active Directory. For example, a user was in the “Chicago” organizational unit (OU) and has been moved to the “Cleveland” OU. When an object is moved in this way, App Volumes can have trouble finding the user because its distinguished name (DN) value in Active Directory has changed. App Volumes stores the user DN value in the “Users” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 2

To restore App Volumes functionality to the object, the App Volumes SQL database needs to be updated with the new Active Directory DN value. This is done by retrieving the correct DN value from Active Directory, then updating the database record for that user.

App Volumes AD Objects Move Issue JDavidson 3

Updating the SQL record can be done directly through SQL Server Management Studio.

If this issue is occurring for all users then you will want to validate that the Active Directory group—defined as the App Volumes Administrators group—has not been move. In this circumstance you will want to validate the DN of the group specified in the App Volumes SQL Database against its location in Active Directory. The administrators group DN is stored in the “group_permissions” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 4

If the group has been moved you will need to update the App Volumes SQL Database with the DN value of the new group.

App Volumes AD Objects Move Issue JDavidson 5

This record can also be updated directly through SQL Server Management Studio.

Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.