This time around Iwan Rahabok will lead the next session of the vROps Webinar Series while Sunny and myself will support him to deliver some awesome content which Iwan has developed over the past few months.

Yes, this time around we will move our focus from vROps as a Product and related features to the concept of running your SDDC operations with vRealize Operations Dashboards. Just to clarify, this is not a session where we will teach you to create dashboards, but this is a session where we would share how a set of Customised Dashboards can help any organisation’s IT to get an insight into Storage, Network & Compute within your SDDC. While vROps is primarily a Performance Management and Capacity Planning tool, we will take you to the other important aspects as well such as Availability and Configuration.

The session would start with discussing the concept first. Then you will see the concept turning into reality with the Custom Dashboards which we are going to showcase. Later, we will also share details on how to get all those dashboards into your environments with a few easy steps and hopefully this will either get you started on your vROps journey, or accelerate the journey for those who have already started and now looking to maximise their investments they made in to vROps.

So join us for this edition and learn more about how to operationalize Software Defined Datacenter.

vCAC 6.1 build out to distributed model: Clustered vCAC Appliances

With the release of vCAC 6.1 there have been some great improvements in the setup of the clustered vCAC appliances – none of the previous copying of configuration files between appliances – just a simple wizard to do it all for you. In my opinion this is superb.

As a little learning project, I thought I’d take on Simon’s previous post about backing up ESXi configurations and extend it to vCenter Orchestrator (vCO), and document how I go about building up a workflow. I’m learning more and more about vCO all the time, but I found it has a really steep entry point, and finding use cases is hard if you haven’t explored capabilities.

The steps I want to create in this post are:

Right click host to trigger

Sync and then back up the configuration to file

Copy the file to a datastore, creating a folder based on date and the host

Ideas for future extensions of this workflow include – trigger from cluster/datastore/host folder, email notifications, emailing the backup files and backup config before triggering a VMware Update Manager remediation. Hopefully all this will come in future posts – for now, lets get stuck into the creation of this workflow.

In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.

The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution. However, I can envisage situations (similar to mine) when the SSO administrator account is not used for a long time and expired – that causes headaches.

To modify the SSO password policy log onto the vSphere Web Client as the SSO admin (admin@system-domain for 5.1 or administrator@vsphere.local 5.5) and select Administration, then Sign-On and Discovery > Configuration. Select the Policies tab – you should see the default config:

Click edit and set the password policy as required. This only applies to SSO users (i.e. those in the System-Domain or vSphere.local domains). To set the password to never expire in 5.1, set the Maximum Lifetime to 0 – for vSphere 5.5 you need to set to 9999 (Thanks to Hywel for his comments). IF you chose to do that, I’d beef up the complexity of your password policy to include upper, lower, numeric and special characters and increase the length from 8 to 13.

Similarly, you can edit the lockout policy which by default will lock you out if it has 3 failed attempts within 24 days. It will lock you out for 15 minutes. Setting the lockout time to 0 forces a manual unlock by an SSO admin.

The second option seems preferable to me (and Anthony and Grant) – that is to add some AD users or groups to the SSO administrators group. To do this, again log in as an SSO admin and select Administration, then Access > SSO Users and Groups, then the Groups tab. Select “__Administrators__” and click on the add principals button below. Select your AD domain from in the Identity Source field and search for your required user or group. Add them and click OK. Now those users, or group members have the ability to log on and reset or unlock the SSO admin account. AD accounts are obviously subject to your AD password policy, but can be reset independently of SSO and therefore don’t require you to use some command-line kung-fu to unlock.