1 2 Previous Next 17 Replies Latest reply on May 13, 2019 3:50 AM by vXav

    Upgrading View 7 Cloud Pod from 7.3.2 to 7.7 - One POD done and going to Global Entitlements Results in "Server Error"

    DaveG_QVC Lurker

      I plan on opening a ticket tomorrow but figured I might fish for perhaps an obvious answer.

       

      Details:

       

      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?

       

      Thanks!

      Dave

        1 2 Previous Next