I plan on opening a ticket tomorrow but figured I might fish for perhaps an obvious answer.
Two PODs both 7.3.2, two connection servers in each POD with a LB in front of them which then point to a global load balancer. Global entitlements, some with single POD pools available (dedicated) and others both PODs have pools involved.
I do the upgrade on POD 2 (was the POD brought in second after the original federation) from 7.3.2 to 7.7 following the VMWare designated process. Composers, then Connection servers. All goes well. Can create new pool, can compose and users coming from POD 1 are honoring global conditions and are able to access their VMs.
Last check is we go to Global Conditions tab in the Admin console of the upgraded "Connection Server master" and you immediately get a very generic Server Error message. Debug logs don't really show much (to my eyes).
Effect of this issue. If a user is sent to POD 1 (still at 7.3.2) they can access a pool whether it is in that POD or in POD 2 (the upgraded one). There are essentially no issues.
However, if a user first lands in the upgraded POD and their pool is not local (part of a Global Entitlement with only an active pool in the un-upgraded POD) the user will receive "The desktop is currently not available" as if it can't reach out and see that pool as available in POD 1 (unupgraded).
I checked the ports on the upgraded connection server and there are multiple established connections over the VAPI 8742 telling me the upgraded connection server is able to communicate to the other POD.
Now, the thought came that we should just update the other POD and it should be fixed. My concern is that not only will that not fix it, it might put that POD in the same broken condition. We are currently sending all connections to the non-upgraded POD and the users are fine.
My main question is did I miss something that says this is expected behavior while in a "mid-upgrade process"? I did with our upgrade from 7.0.3 to 7.3.2 and don't remember the same issue.
Any insight would be great. As I mentioned a ticket is going to go up but I figured I would check with the experts to see if anyone else has seen this behavior and if so...how did they resolved?
If you haven't already opena ticket with support, I read something recently where this happened if you had a corrupted global assignment in the adls database horizon uses for the cloud pod. I can't seem to find the record but they found it and removed it and it went away.
Thanks for that reply. It really seems like my situation and that would make total sense. I have a ticket opened with support (just waiting for them to contact me) and have already uploaded Connection Server logs.
I can manage the Cloud POD on the affected Connection servers using the command line utility: lmvutil
I tested and was able to add a local pool to a global entitlement using the utlity and also have it report back on the POD servers and sites so it really does seem like most of functionality is working. Just not the GUI and it is not able to find specific resources in other POD.
I will update this when I am done with VMWare support.
After working with support and identifying the issue occurring in the logs their "official answer" was the cause of my issue was in fact the different version. Their resolution is to upgrade the other POD.
I have this scheduled for tomorrow and I will report back if it does indeed fix the problem. If it doesn't I am going to have some rather unpleasant issues.
We have the same error accessing Global entitlements page.. Any luck after the upgrade of other POD?
Ours.. Both the POD's are upgraded but no luck. We tried rebooting the connection servers.. Still no luck..
I was also facing same issue,but i have got an solution from one of my.Will try it and report u back in case if something positive outcome is produced,or else if u find some working solution then u too can tell me..Regards.mybkexperience
Upgrade is completed.. Global entitlements are accessible via commandline (lmvutil) and users are able to login.. its only the Global entitlements from horizon admin page that doesn't open and returns "server error". Still looking for a fix.
Any update on this case?
I am facing the same issue after upgrading an dual pod configuration from 7.5.1 to 7.8.
It isn`t possible to create / add an extra Global Entitlement from the admin console...
Very strange behaviour.
We did an update from 7.5.1 to 7.8 with 2 PODs within one site (2x connection servers in each POD).
After update of the first POD also Global Entitlements were not visible.
But using CLI (lmvutil.cmd) anything was ready for management and visible!
We added one Global Entitlement per View Administrator - nothing happened. But per CLI we could see the new Entitlement.
Also adding another Entitlement per CLI works as expected, but in the GUI nothing was visible.
Always we got the "Server Error" message.
Appr. one day later the Global Entitlements were shown again. We changed nothing in the meantime between update and this mystical moment when the Global Entitlements appeared again.
We updated the second POD after that without any problems.
I am just off the phone with support. There is a new security check in the new Horizon version (7.7 and beyond) that checks SID's. In my case there was a non existing SID in the Horizon POD ADAM database that need to be deleted. Support did that and after that the error and issues where gone.
Our issues: We experienced that global entitled users couldn't connect to the "non local" POD and the site assignments where in error. Users where logedin in the wrong site etc. After the fix everything setteled down and is just fine now (it took some time)
So: Call support and let them fix the POD architecture ADAM database. You CAN run POD's with different versions and upgrading the other POD to the new version is not always the sollution...
@lookandfeel: Appr. one day later the Global Entitlements were shown again. We changed nothing in the meantime between update and this mystical moment when the Global Entitlements appeared again.
Support told me this is because of the POD ADAM database replication taking some time. They told me to wait 24 hours..
We upgraded one pod from 7.4.0 to 7.8.0 and seeing the same problem in the upgraded pod.
Upgrade done 3 days ago so long replication time can be ruled out I believe.
Now waiting for the VMware support case to play out.
Edit: The global entitlements magically appeared a few hours later... Maybe generating the support bundle on a connection server triggered "something somewhere"™.