Deprecated VMFS volume(s) found on the host warning message

Last week I ran into a VMFS version warning message while building a new vSphere 6 environment for a enterprise customer. This environment is a green field deployment, so everything is new from SAN infrastructure, Network, Compute and Storage.
When I started adding payload ESXi hosts to their respective HA clusters, the only warning message I received was about the System logs being stored on non-persistent storage. This was expected as the hosts where Blades (without any local harddisks) which booted the hypervisor of a embedded USB device and there was no shared storage available yet.
After presenting shared storage and adding it to the ESXi hosts, being formatted in the process as VMFS 5 (VMFS 5.61 to be exact) all looked fine.
But when I rebooted the ESXi hosts, they came back online within vCenter and there was a extra warning message: Deprecated VMFS volume(s) found on the host. Please consider upgrading volume(s) to the latest version

The only action I had done on the environment between adding the shared storage and rebooting the hosts was deploying a OVA. This was the EMC VSI (Virtual Storage Integrator) appliance, deployment, configuration and installing of the plug-in went without any trouble.
Not sure if deploying the EMC OVA had anything to do with the warning message. In any case VMware has a KB article about the false positive deprecated VMFS warning.
KB2109735 does not disclose what is causing this false positive, but it does suggest a simple yet effective solution to the problem. At least it did solve the problem in my case.
By restarting the hosts management services the warning message is gone, the easiest way to do this is to run services.sh restart from either the DCUI or through a SSH session.

Installing vSphere 6 gotcha

The last couple of weeks I have been involved in the deployment of a vSphere 6.0 environment. This was my first vSphere 6.0 customer deployment.
Most of the implementation plan I wrote and as this was my first customer deployment I had to do some rework on my default implementation, which I have used on vSphere 5.5 implementations. To write this implementation plan I used the official VMware installation and configuration documentation as guideline. At the time of writing all implementation steps seamed logical, but when we came to the actual implementation we ran into a issue when we tried to add Identity Sources to the PSC (Platform Service Controller).
This customer vSphere environment is a large, multi tenant and multi site environment and for this reason together with the need for flexibility and scalability a design choice was made to use external PSC's. Also during the design sessions with the customer the decision had been made to use the vCSA (vCenter Server Appliance) instead of the up until vSphere 5.5 generally chose Windows based vCenter.
The issue we ran in to has to do with in which order you go to the configuration steps after the PSC is deployed. At some point you want to be able to join a PSC to the Active Directory domain to be able to use AD integrated authentication. When using external PSC's like in this particular case you don't join vCenter (vCSA) to the domain but the PSC. The reason for this is simple, SSO (Single Sign On) and Authentication services are provided by the PSC not vCenter.
The implementation plan followed the exact same steps for this part of the configuration as the VMware documentation and we followed the each en every step as they where documented in the implementation plan, but for some reason we still got a error message.
After verifying that I had used the most recent version of the VMware documentation I did a quick check on the VMware communities to see if anyone else had ran into the same issue.
There was a post dated March 27 2015 called "Wrong information in VMware 6.0 documentation vCSA 6.0" which described the exact issue and the writer came to the same conclusion that the VMware documentation has the configuration steps in the wrong order.
This community post was posted two and a half months ago, clearly VMware hadn't been able to update their online documentation.
Below you will find in short the correct steps and order to join a PSC (internal or external) to a Active Directory domain followed by adding Identity Sources to the PSC. For more details please have a look at the community post.

1. Use the vSphere Web Client to log in as administrator@your_domain_name to the vCenter Server instance.
2. Under Deployment, click System Configuration.
3. Under System Configuration, click Nodes.
4. Under Nodes, select a node and click the Manage tab.
5. Under Advanced, select Active Directory, and click Join.
6. Type the Active Directory details (use the administrator@your_domain_name syntax for the user).
7. Reboot the appliance, after the reboot login as described in step 1.
8. Navigate to Administration > Single Sign-On > Configuration.
9. On the Identity Sources tab, click the Add Identity Source icon.
10. Add the Active Directory domain as an identity source, enter the identity source settings, and click OK.
11. Finished, you can now continue with the rest of the configuration like adding AD security groups to the roles defined in Global Permissions.

I am sure that VMware eventually will update their online documentation. In the mean time, if you follow the steps described above the configuration should be easy. Alternatively you still could follow the steps as described in the VMware documentation, but you will run into this issue. The error message has gotten a link to the correct webpage where you can first join your PSC to a Active Directory domain. After a reboot you can then restart your configuration. Although the second option will take more time the end result will be the same.