Moderator: Moved to vSAN
Welcome to Communities.
Can you please share screenshot or details of what it is specifically saying is the reason for vCenter is not authoritative (and which hosts are shown in the alert if not all) - this can be for a number of reasons including last changes made in a different vCenter but also disparities between the vSphere-level cluster settings and those applied to the cluster (e.g. Dedupe, Encryption etc.) - please validate that you created the new vSphere-level cluster with the same settings and features enabled (and that these are adequately licensed for).
Potentially vC can't push down unicast list check/change because this was left disabled on some/all nodes, this can be checked with the following command via CLI and if it is set to '1' then vC can't push down such changes:
# esxcfg-advcfg -g /VSAN/IgnoreClusterMemberListUpdates
After reading your reply it hit me I had changed the unicast list to ignore because I had to manually add neighbors for each host (Could this be because my vSAN network are connected through LACP into a switch)?
But after IgnoreClusterMemberListUpdates were set back to 0, I could run update ESXI configuration and it went back to green.
If the cluster was fully-formed and all nodes had correct and complete unicastagent lists when IgnoreClusterMemberListUpdates was enabled then manually editing or adding to lists shouldn't be necessary unless you are adding new nodes (or re-installed ESXi on any) - whether using LACP or not shouldn't matter provided you didn't change IPs etc.
Note that even if the unicastagent lists on all nodes are correct and reflective of the vSphere cluster members, this check will remain red if vCenter is prevented from pushing down changes
Another thing to note is that it is imperative that if using IgnoreClusterMemberListUpdates that it be used consistently applied to all nodes in the cluster as otherwise there are scenarios whereby the cluster can become partitioned.