Hocshop's Accepted Solutions

Update, I think I found the source of the problem. I just found out that the domain functional level that they are using is at Win 2008 level. That is not compatible with vCenter 7.0 and i... See more...
Update, I think I found the source of the problem. I just found out that the domain functional level that they are using is at Win 2008 level. That is not compatible with vCenter 7.0 and is not even supported by Microsoft anymore. Here is the AD compatibility matrix just in case anyone else needs to find it: VMware Knowledge Base I hope that helps someone else. Regards
Hi all, I eventually raised a case with GSS and they told me that it is not possible to install a PSC HA on 2 PSCs if another PSC already exists in the SSO site. That implies that it is only ... See more...
Hi all, I eventually raised a case with GSS and they told me that it is not possible to install a PSC HA on 2 PSCs if another PSC already exists in the SSO site. That implies that it is only possible to install a PSC HA NLB from zero i.e. without NSX. Also in vSphere 6.5 it is again not possible to repoint a vCenter to another PSC in a different SSO site (it was possible in vSphere 6.0). So it isn´t an option to move the temporary PSC to another site either. The support rep could not tell me why it is not possible to run the command in my type of environment nor could he point me to the official KB or a well known blog that mentions that point neither. Also if you check the official KB for VMware on how to configure a NSX NLB for the PSC HA, there is a small note that says that it is assumed that NSX is already installed and configured. All this points to the fact that in vSphere 6.5 you cannot deploy a PSC HA, using an NSX NLB, from zero. It is because of the classic chicken and egg syndrome: You need a vCenter to install the NSX software but you need the PSC HA to install the vCenter and NSX. That leads me to believe that the only way to get to the ideal configuration (and what VMware officially support) is to use a third party NLB like NetScaler first, install the PSC HA using the 3rd party NLB and then deploy the vCenter by pointing it to the VIP of the 3rd party NLB. Then when the NSX is deployed, configure the NLB component of NSX with the same information as the 3rd party NLB and then simply turn off the 3rd party NLB leaving just the NSX NLB servicing the PSC HA. I feel a little bit hard done by because of the lack of documentation regarding this limitation of PSC HA and now I will have to destroy my vCenter and the temporary PSC to be able to run the above mentioned process. Its worth mentioning also that in the blogs and KBs regarding the configuration of PSC HA with NSX, the key file that you need (to be able to import the certificate into NSX) does not come in the correct format. You need to run the openssl command with the rsa parameter. Here is an example of that command: openssl rsa -in lb.key -out rsalb.key I hope that VMware put this limitation in writing so as to not have anyone else fall into the same trap. Hopefully this helps someone. Regards
Hi everyone, Just to let you know that this problem was resolved. What happened is that, after the installation of the environment, the DC in the secondary site was demoted for some reason.... See more...
Hi everyone, Just to let you know that this problem was resolved. What happened is that, after the installation of the environment, the DC in the secondary site was demoted for some reason. When it was re-promoted the PSC had lost its trust relationship and so the authentication stopped working. We had to remove the PSC from the domain, reboot, re-join the PSC to the domain and reboot again. Then it started to work as expected. A very good source of information was the log bundle from the PSC, in particular the vmware-sts-idmd log file. Hope that helps anyone who has the same problem in the future. Regards