VMware Content Libraries are a 6.x "new" functionality (I use quotations because 6.x has been out for a while) that I've really grown to enjoy. Content Libraries allow you to store objects such as ISOs, templates, etc. in a central repository that can be shared with other vCenter environments. One of the biggest use-cases is to clear up all those random "ISOs" folders on various datastores as engineers, who are searching for an ISO, look in just the wrong folder first and create their own.
When Content Libraries were first released, there were a few issues that made it difficult to use. The main issue was that in order to use an ISO in the library, I had to download it first, and then connect it to through the web client. For that matter, I may as well just continue to use the locally stored ISOs on my system anyway. You could still deploy templates from the library, which helped, but ISOs were what I really was looking forward to.
vCenter 6.5 (and 6.7) fixed this and allowed you to connect ISO images directly from a Content Library. When I stood up our 6.5 cluster internally, I started setting this up and created a repository on a FreeNAS device with the share exposed via NFS so that I could use some cheaper storage to hold this content. Growing excited, I tried to create my first VM with an ISO image stored in the library. And it didn't work. Turns out, in order to connect an ISO from a Content Library, the backend storage must either be a VMFS datastore directly connected to the host so that the VM can "see" it.
I recently built a new VM with Windows Server 2016 and installed Exchange Server 2016. As part of hardening the server, I implemented our normal security header and cipher suite hardening steps. The Exchange Control Panel (ECP) appeared to function properly after these changes were implemented, but about a week later I found an issue where one of the less commonly used pages would not open. The page would not load the style sheets and you could not navigate to the page when using the FQDN from the local server. The page mostly worked when accessing it via https://localhost/ecp or from the FQDN outside the network.
During troubleshooting, I decided to remove the security headers to see if that would resolve the issue and it did. I determined that adding the X-Content-Type-Options security header broke some pages in ECP. The only option for X-Content-Type-Options is "nosniff", so there is no alternate value to set. Basically, the Exchange style sheets aren't specifying the content in the style sheets and "nosniffs" tells the browser not to guess the MIME types. I implemented all of the other common security headers, but did not implement X-Content-Type-Options.
For our audits, we run VMware Health Analyzer (VMHA) on any vCenters to collect information on ESXi build numbers, snapshots, dormant VMs, etc. Recently, a customer we were scanning had two vCenters, and while VMHA worked fine on one of them, we were getting errors on the other. Standard troubleshooting didn't work, and the customer didn't know why we weren't able to collect the information this year. After running nmap on the vCenter, we determined the customer had redefined the port used for this vCenter instance and simply defining the port in our scan credentials solved the issue.