Over the weekend, I had to re-deploy a portion of my VCF 9.1 Fleet, including VCF Operations, VCF Management Services, VCF License Server, SDDC Manager and VCF Automation, due to some workflows I was testing.
Luckily, my core SDDC components vCenter, NSX and vSAN was not touched and I could simply re-use those components by running the VCF Installer Import/Converge process to quickly rebuild my VCF 9.1 Fleet!
Prior to deleting VCF Operations, I had VCF Single Sign-On (SSO) configured and I wanted to make sure the core SDDC components were properly cleaned up. I successfully ran through the VCF SSO unjoin operation for all components and cleaned up the vCenter Server Advanced Setting (config.OPERATIONS.vcf.sso.ops.cluster.id), which was required with VCF 9.0.x before you could add it to a new VCF SSO configuration.
After my VCF 9.1 Fleet was re-deployed, the first thing I wanted to go setup was VCF SSO and I noticed the configuration button was grayed out and it had the following message:
No VCF instance available due to one of the following: no existing instance, invalid license, version below 9.0, setup in progress, already configured via another Operations or running ELM.
After reaching out to Engineering, I came to learn there was a new process to reset and reclaim the VCF SSO configuration ownership within VCF Operations, in case you had a prior VCF SSO configuration. Long story short, there is an VCF Operations AI that must be performed on each of the Identity Broker components.
To assist with this reset, I have created a PowerShell script called reset_idb_vcf91_sso_for_vcf_operations.ps1 which will connect to your VCF Operations instance and list all Identity Broker components along with their eligibility status and their underlying reasons for ineligibility.
In my setup, I was not able to configure VCF SSO since the new VCF Operations instance had detected that a prior VCF SSO deployment was configured with another VCF Operations instance and prevents us from making any changes, which is a nice feature!
Since I had re-deployed a new VCF Operations instance, I am okay with reclaiming or resetting the VCF SSO configuration with the new VCF Operations instance, so I just need to make a note of the IDs for the Identity Brokers that is displaying VCF SSO CONFIGURED OTHER OPS reasons.
Within the script, you will see $PURGE_VIDB_SSO_CONFIGURATION_IDS variable which is an empty array by default. You can now add the Identity Broker IDs into that array like the following:
$PURGE_VIDB_SSO_CONFIGURATION_IDS=$("ab9310ed-9966-42a3-9986-3b7da6864fb7","cd461bc9-45a4-48de-8572-8c84f3a3d968")
Now when you re-run the script, it will check whether there are matching Identity Broker IDs that should be reclaimed using the VCF Operations API that I had mentioned earlier. Upon successful clean up, you should see HTTP 204 (no output) as shown in the screenshot below.
Once reset has successfully completed, I am now able to configure VCF SSO within VCF Operations!
I think this a nice feature to prevent users from accidentally touching the VCF SSO configuration for an VCF Operations instance but it definitely would have been nice to have a UI option to see the ineligibility reasons and be able to reclaim this directly from VCF Operations UI, but perhaps this should not be that easy as I can see the argument for someone accidentally resetting the VCF SSO configuration for another VCF Operations instance!
Note: In VCF 9.1, it is no longer required to edit the vCenter Server Advanced Setting config.operations.vcf.sso.ops.cluster.id as that is no longer sufficient to reset VCF SSO for a prior deployment.
Thanks for the comment!