The following statement resolved my issue in my test lab at home, which is not documented ever on any website including Microsoft TechNet, Exchange Blogs. Funny thing is, no one ever mentioned it or experienced closely like you, and now me :-).

“After some digging, I found that our Root CA Certificate was only located in the Trusted Root Certification Authorities machine certificate store. I went ahead and imported our Root CA Certificate into the Third-Party Root Certification Authorities store on the EXCAS servers and then checked the status of the Exchange Certificate again. It was now showing ThirdParty.”

Simply fantastic, I understood the foolish logic it plays around with just CA issuer. I don’t know, I guess I spent several months to figure out. I am using free certificate from startcomca.com, so I thought something is missing from their side. I had created so many free certificates repeatedly for this to work. But here it was !!!!

What a welcoming year 2018 seems to me with this great success !!

One again, cheers Matt, Have an excellent year 2018.

Thanks for your comment.

If you currently have two embedded deployment in 2 sites, they will be in their own vsphere.local domains. At this point in time, there is no way to merge these into a single vsphere.local domain.

I suspect you would be best doing something such as:

1) Externalise PSC in site 1, so you have a vCenter Server with External PSC
2) Deploy a new PSC in Site 2
3) Deploy a new vCenter Server in Site 2, pointed to the PSC in site 2. At this point you now have 1 external PSC in each site and one VC in each site, pointing to the local PSC
4) Migrate hosts, VMs and other settings from the old VC in site 2 to the new VC in site 2
5) Decommission the old embedded VC at site 2

Does that help?

Cheers, Matt.

I have question related limitation on VCSA v6.5. In your statement
“And now with 6.5, it seems we have taken a step back again and we’re now back to how it was in 6.0GA, which is we can repoint the VC between PSC nodes in the same SSO site, but not cross site and not to a PSC in a different SSO domain.”

In my existing using VCSA 6.5 Update 1 embedded deployment on 2 sites and i want to change to external deployment. Can i use both PSC to using 1 SSO domain and 1 Site Name and from VCSA each sites repointing to PSC each sites to make as Enhanced Linked Mode ?

Please answer because very much effort to deploy again all component of VCSA 6.5 using external deployment and configuring again.

Thanks

Regards,

Haikal

As they say, no such thing as a stupid question. There is no down times to the VMs being managed by vCenter that you are repointing. vCenter is simply the management plane, VMs will continue to run on the ESXi hosts while you do the repointing. vSphere High Availability will continue to work (if configured), but vCenter operations such as DRS will not work while the vCenter server is being repointed. And obviously if you needed to get access to a VM console etc, you would need to log directly in to the ESXi host while the vCenter Server services are restarting.

Cheers, Matt.

No worries at all. Glad it was helpful!

1. Yes that’s correct, but for the second PSC on wards you need to use a slightly different template. In the templates folder on the VCSA ISO, you will notice there is “PSC_first_instance*” and then “PSC_replication_on*”. When deploying the second PSC (or 3rd, 4th, etc), you need to use the second template of “PSC_replication_on*”. The difference is that these templates have a property of “replication-pertner-hostname”, where you specify the PSC name of the PSC you want this newly deployed PSC to replicate with.

2. Yes, these can certainly be scripted. In fact, William Lam wrote a script to deploy a nested vSphere environment for lab purposes and I made some enhancements and changes. The details, including links to William’s original script can be found here – https://virtualtassie.com/2017/additions-to-vghetto-automated-vsphere-lab-deployment/

Cheers, Matt.