We had experienced this bizarre situation with one of our vCenter Servers, and it was not able to start the “vpxd” service giving “localized”: “An Error Occurred While Starting Service ‘vmware-sts-idmd'” error message. Actually, vCenter was configured with VMware VCHA feature, and server was not operational. VCHA failed to recover from the secondary node, and it was totally disconnected from the network. We were able to fix it following these steps, then we led to this unusual situation. In this post, I just wanted to share my experience, and the steps, which I followed to fix it.
I just wanted to highlight few things in this post, as I think those could be very useful for someone who encountered the similar situation. Because, many people had gave up on fixing this, and redeployed the vCenter as a workaround. While I was searching around, I found this VMware Community article, which didn’t help me to fix this.
This error message appeared, while I was connecting from the vSphere web client.
 SSO error: AFD Native Error Occurred: 9234
Check the vSphere Web Client server logs for details.
Not to mention that, I was not able to directly identify the issue after checking the Web client logs, so I tried to restart the services again.
Then, the “vpxd” and “vmware-sts-idmd” didn’t start properly. Manual start ended up with the below error.
“localized”: “An Error Occurred While Starting Service ‘vmware-sts-idmd'”,
“translatable”: “An error occurred while starting service ‘%(0)s'”
While I was scraping the error logs, I identified password errors in the machine account in “vmdird-syslog.log” file located in “storage/log/vmware/vmdird“.
It was a good sign, and I reset the machine account password with “vdcadmintool” located in “/usr/lib/vmware-dir/bin”.
Option “3” was the reset password for machine account. You have to provide the UPN of your Machine account. If you don’t know that, you can find it in the “vmdird-syslog.log” file. Normally it goes as “FQDN@SSODOMAIN”.
One important thing in this step, we need to note the generated password for the next step.
Then likewise registration tool used to update the password, which I reset in the previous step. Execute these commands one at a time.
#specify new password within the double quotes
set_value dcAccountPassword "NEW_PASSWORD"
Then I rebooted the vCenter to take these changes come to the effect. Finally, I was able to start my “vpxd” and login to the vCenter server.
I suppose, VCHA didn’t break the vCenter server, and this machine account did. Due to the communication or the authentication of this so called “Machine Account” made the cluster break situation of VCHA, and it was out of service. I’m not quite sure this is a bug of the VMware build version we used or some other reason, as we are looking in to this at the time of writing this article.
Troubleshooting was two steps, fixing VCHA to come vCenter alive in the network, and resetting the “Machine Account“.
I hope this helps.