alienjoker's Posts

Hi all, I'd like to reach out to the community to determine the success ratio of people deploying VMware Horizon View 7 in association with AppVolumes. A client of mine recently embarked upon the upgrade of their existing VMware View 5.3 environment to Horizon 7 in order to remain within support compliance but unfortunately, the journey has not been the most pleasant and still continues to be plagued with daily problems. I'll try to keep things as succinct as possible but here are the high level steps taken to get to where we are now. a) Deploy vSphere 6 U2 hosts (having come from vSphere 5.5 U2) b) Deploy new 7.0.1 Connection Servers (7.0.2 was not out at the time of start having come from 5.3.4) c) Deploy new 2.5.1 Access Points (2.7.2 was not out at the time of start) d) Deploy new 2.11 AppVolumes Managers (having come from 2.6) e) Upgrade existing Gold image to reflect updated VM hardware version and include updated VMware tools, AppVolumes 2.11 Agent and Horizon 7.0.1 Agent with Instant Clone Support Pilot phase identified the following the following problems:- 1) AppStacks would randomly disconnect mid session (SR logged - no resolution) 2) Logon times would be continually inconsistent and in some cases longer than the previous user experience in the old environment (SR logged - advised limitation of the AppVolumes product and the way it mounts stacks - no resolution) 3) AppVolumes issues whereby a user could not successfully delete a file that had been created on the local disk with a Windows Error - (SR logged, filter driver problem private fix available, but not production ready- pending AppVolumes 2.12) 4) Remote Sessions would disconnect after 10 hours (SR logged - known issue under KB2131762 or KB2145172) 5) Sessions would sometimes disconnect and could not be reconnected to unless HTML access/Blast Exterme was used or the old session terminated (SR raised - no resolution) 6) LAN based sessions would sometimes disconnect after 20 hours despite having set to Never disconnect (KB 2091458) - FIXED 7) Performance problems mid session and logon/logoffs were really slow (VMware tools version needed upgrading to 10.0.9 as per KB2144236) - FIXED Off the back of the above and in terms of priority and show stoppers, given we couldn't proceed with a non supported filter driver fix, we resorted to AppVolumes v2.10 which immediately meant we had to drop the ability to use Instant Clones. Once we had downgraded the AppVolumes agent and changed the Horizon 7 agent to linked clones in the Gold build, here's a summary of where we're at regarding the issues above: 1) No Resolution : This has happened even on 2.10 (we use Mount on host, the SR is still pending) 2) Much better, and more consistent 3) No longer a problem 4) No resolution : Doesn't look likely that there will be a fix until a re-release 5) No resolution. 6) FIXED as per above 7) FIXED as per above As you can see, we're still in a bad place with items 1) and 5) with too greater risks for users to be left with an unworkable system. Item 4) whilst an education issue, is simply not acceptable. Is anyone else out there able to share their pain and or comment/help above beyond what GSS are already investigating? I look forward to hearing peoples experiences. Thanks Andrew

Hi, We originally deployed the access point with single factor and were then asked to append two factor. Rather then redeploy, we considered adding the two factor to an existing deployment. This appeared to be nothing more than a couple of JSON requests, correctly formed to make the changes. Initially, we successfully issued a PUT to : https://accesspoint.domain.com:9443/rest/v1/config/edgeservice/view with a JSON request of : "authMethods:" "securid-auth && sp-auth" and all the other required parameters, however when we are attempting to issue the commands needed for the securid components via a PUT to https://accesspoint.domain.com:9443/rest/v1/config/authmethod/securid-auth as per documentation (replacing the HostNames and serverConfig with the sdconf.rec Base64 Encode (single line) it always fails:- VMware Access Point 2.7 Documentation Center { "enabled": "true", "name": "securid-auth", "numIterations": "5", "externalHostName": "10.20.30.40", "internalHostName": "10.20.30.40", "nameIdSuffix": "" "serverConfig": ""OwYFI7owv5UrAdlfnOsW2nVesmbkLRjNOYxqm" } "Error - failed to set adapter configuration" A SecurID Connectivity or configuration error has occured" Does anyone know which part I'm doing wrong? Best regards Andrew

Hi i would like to ask a couple of questions regarding our deployment to integrate access points and wondered if anyone could please provide some guidance. ‌ We are currently load balancing (behind Kemp) two Horizon 7 view connection servers using an internal CA cert via horizon.domain.com. The plan has been to use a different fqdn of login.domain.com which will use public certs, deployed to the access points, configured to connect to horizon.domain.com Is there any issue using two different fqdns for internal/external access for shared view connection servers? When it comes to using two factor auth, given that the configuration is enabled on the connection servers, does this mean I need two separate connection servers for the access points to provide the two factor auth as internally for thin clients etc, this is not a requirement. Many thanks Andrew

Hi, I thought I'd reach out to the community to get a view on the feasibility of using a feature such as URL Content Redirection in Horizon 7. Whilst on paper, it sounds like a benefit to offload URL clicks/entries to sites such as YouTube so as to place the overhead on a ThinClient for example, there are many user experience caveats/complexities. For example, if you are using a full screen VDI session, upon attempts to access YouTube, the local browser does successfully appear in front of your active session to continue use of the redirected site, but if you minimize the window, you are helpless to bring it back as the ALT-TAB you issue is sent to the VDI session, not the underlying device and therefore your users have no method of regaining control of the local browser the VDI session called. Making a comparison to Citrix, their local application access technique successfully integrates the locally run application into the taskbar of the VDI session, allowing you to transparently use the application as if it was genuinely hosted within the Virtual Desktop. Perhaps I'm missing something, but unless you operate a Windowed virtual desktop (and therefore present two taskbars/start menus, which brings a whole new level of complexity for the end user), I'm struggling to understand how the feature at this stage of development would even stand the test of time in a production environment. I look forward to hearing other peoples views or successes/failures with this "feature". Thanks Andrew

Hi, I was wondering if there was a way to create multiple pools, all referencing the same Parent VM, but automatically adjusting the compute resource of the VMs within the target Pool as part of the compose/recompose process (on the assumption that any compute change wouldn't be drastic enough to invoke a HAL change or prompt to restart the OS)? For example, to keep master images down to one to reduce administrative overhead for patching etc, is there any way to specify the following three pools to all use Parent VM X but with slight variations to CPU/RAM: Pool (Small) - 2GB RAM, 1vCPU Pool (Medium) - 4GB RAM, 2vCPU Pool (Large) - 8GB RAM, 4vCPU I realise you could quite easily patch Parent VM X and clone it to Y and Z and adjust the specification of X, Y and Z as the new Parent VMs to meet the compute requirements of the pools, but this seems just another unnecessary administrative overhead as would need to be done at each patch cycle. I was considering leveraging the post-synchronization script as a task that shuts down the VM, sends the VM name as a variable to a PowerCLI command, adjusts the compute as dictated by the script called by the pool and subsequently powers it back on? Has anyone done anything similar, or is there a feature in the product I've simply overlooked. (VMware Horizon View 5.3.4) Thanks