1 person found this helpful
Solved. The problem was causes by a bug in the Connection-Server 7.9 installer. It upgrades Connection-brokers just fine but it disables the Inter-POD API Firewall rules in the Windows firewall. Well, it does not actually disable the rules, it forgets to re-enable them. Let me explain:
- The installer uninstalls the old Connection Server version
- It also uninstalls all the firewall rules that came with it. This includes the Inter-POD Rules that had to be manually enabled in the first place to allow the PODs to communicate with each other.
- It then installs the new version (7.9 in this case)
- It installs the firewall rules again, incl. the Inter-POD rules but DOES NOT ENABLE THEM
- So directly after the upgrade, this POD is now unreachable by all the other PODs.
Manually re-enabling the Inter-POD rules on that connection server solves the problem and this POD is reachable by the other PODs and all is good. Repeat for every connection-broker in every POD being upgraded.
I regard this is a bug. It is easy for the installer to see that this POD is part of a CloudPOD infrastructure and knowing this, can enable the Inter-POD rules to avoid this problem. But it does not.
After an installation often it remains helpful monitoring pods.
Pod federation health, site info, pod endpoint health and local pod status are exposed horizon apis. You may have a look to this master piece PowerCLI-Example-Scripts/VMware.HV.Helper.psm1 at master · vmware/PowerCLI-Example-Scripts · GitHub .
local pod status is equal false in a non pod constellation, and local pod status=enabled (<>true!), as in a pod.
Some years ago I put some work on this based on the source above VMwareHorizonPoolsReport/Get-VMwareHorizonPoolsReport.ps1 at master · dcasota/VMwareHorizonPoolsReport · GitHub. The repo contains some fake output as well.
vipa port off could be detectable by processing pod information.