curtisbrown_01's Posts

I'm familiar with the TLS fix for PCoIP sessions, the issue was hitting the connection servers itself.  After much fighting with it, we eventually nailed it down to a firmware issue - put the lat... See more...
I'm familiar with the TLS fix for PCoIP sessions, the issue was hitting the connection servers itself.  After much fighting with it, we eventually nailed it down to a firmware issue - put the latest release onto the client and we were running. Thanks anyway.
Hi All, This one is entertaining me! I have a nice new Horizon 7.4 Connection Server (no load balancer) set up with a single pool of a handful of desktops.  It's all working fine if you use... See more...
Hi All, This one is entertaining me! I have a nice new Horizon 7.4 Connection Server (no load balancer) set up with a single pool of a handful of desktops.  It's all working fine if you use HTML5 or traditional clients.  However, the customer has some old Tera1 based Wyse P20 zero clients.  Now, with previous releases, Tera1 based clients would log onto the broker without much difficulty, but couldn't load a session - the fix was to enable TLSv1 in PCoIP.  Less than ideal, but it worked. With more recent releases (at least 7.4, but I've heard 7.3 too), however, the situation is worse.  The problem now starts at the Connection server itself, before we even try to launch a session.  At first, the zero client was being prevented from connecting to the Connection Server at all.  I isolated this to a TLS error - adding TLSv1 to Locked.properties (using secureProtocols.1=TLSv1) moved me forward - the client will now connect to the Connection server enough to provide a Domain logon box. However, if I try and log on with an entitled user (directly assigned to the pool or Cloud Pod Entitlement), the client states 'not authenticated' and drops you back to the logon screen.  The Events database happily says that the user is authenticated.  If I put in a bad password, it tells me I've got a bad username or password - so the client is being passed authentication information properly when there's an intentional failed attempt. Any ideas before I look at tearing it down and go for 7.1 (the earliest that supports vSphere 6.5U1 and might work)?  And before you ask - yes, I know the Tera1 chipset hasn't been supported since 6.0.....
One approach is to use Storage Group Replication.  Configure an NFS datastore that can be accessible by both the primary and second site's ESXi hosts - don't worry, we won't be running anything f... See more...
One approach is to use Storage Group Replication.  Configure an NFS datastore that can be accessible by both the primary and second site's ESXi hosts - don't worry, we won't be running anything from this. We set up App Volumes on each site and set up a storage group set to replicate and auto-import App Stacks - we add the NFS data store to this.  We set the NFS data store's configuration in App Volumes to disable it's use by desktops too. On the primary site, we configure an App Stack in the Storage Group.  This will replicate the stack amongst all the datastores in the Storage Group on the Primary Site.  As the Secondary also sees the NFS store, it auto-imports the App Stacks and replicates this across this site App Volumes too.  The only thing you need to do after that is look at managing entitlements to the App Stacks at the secondary location (Could be a stretch App Volumes?). Another approach is to use the App Volumes Fling to properly back up the App Stacks and import them in DR.
+1 on the link above. It depends on what you want to test in the lab of course, but assuming you want to test linked clones and external access, you'll need to look at the following: An Ac... See more...
+1 on the link above. It depends on what you want to test in the lab of course, but assuming you want to test linked clones and external access, you'll need to look at the following: An Active Directory Domain Controller (ideally a Certificate Authority too so you can pop signed certificates onto the lab).  You could use this as a file server too for hosting ThinApp packages, and User Environment Manager if you want to look to deploying a full solution. DNS and DHCP A single Horizon Connection server - In a lab environment, you could squeeze this down to 4GB RAM and a single vCPU. At this point you could build an RDSH VM or a desktop, install View Agent and set up manual pools purely to test publishing apps and desktops. For provisioning desktops with Linked Clones: An ESXi host with capacity for a few desktops (rather depends on the spec of the desktop - you could squeeze a 2GB 1 or 2 vCPU desktop). vCenter - appliance is easiest, plus you don't need to worry about SQL. A single Composer server - you could go SQL Express with this. A Security Server or Access Gateway if you want to test external access. For bonus points, if you have vCenter and ESXi hosts for desktops, you could deploy a single App Volumes manager and deploy AppStacks too. All this is possible within 64GB ram (I've put it together using a pair of ESXi hosts with 32GB, no HA admission control).
You're right on the vSphere compatibility (https://partnerweb.vmware.com/comp_guide2/pdf/VMware_GOS_Compatibility_Guide.pdf ).  With respect to Horizon 7.2, Supported versions of Windows 10 on Ho... See more...
You're right on the vSphere compatibility (https://partnerweb.vmware.com/comp_guide2/pdf/VMware_GOS_Compatibility_Guide.pdf ).  With respect to Horizon 7.2, Supported versions of Windows 10 on Horizon 7 Including All VDI Clones (Full Clones, Linked Clones, Instant Clones) (214… has some more specific support information.  Win10 Pro 1607 is only in 'non-production support' unless it's the LTSB branch. Try a re-install of the Horizon Agent in the template (I've had funnies like this with the agent in the past).
Application hosting (so RDSH to deliver applications) would need Advanced or Enterprise.  If you want to publish ThinApps alone to endpoints, you're looking at either Workspace ONE (Identity Mana... See more...
Application hosting (so RDSH to deliver applications) would need Advanced or Enterprise.  If you want to publish ThinApps alone to endpoints, you're looking at either Workspace ONE (Identity Manager - as has already been suggested, but again not part of Horizon Standard) or some other software distribution solution.
I'm curious - what response do you get from other protocols (PCoIP or RDP)?  I'd imagine RDP will work (this doesn't use the GPU or it's driver), but PCoIP is certainly worth checking. I know th... See more...
I'm curious - what response do you get from other protocols (PCoIP or RDP)?  I'd imagine RDP will work (this doesn't use the GPU or it's driver), but PCoIP is certainly worth checking. I know that black screens with PCoIP can occur when the video driver is installed or upgraded after installing View Agent.  PCoIP might end up being your get out of jail card here.
I cracked it using this approach: http://xtravirt.com/horizon-view-app-publishing-custom-icons/blog Might help.
Disconnect is present on RDP because you're effectively running a terminal services session to the desktop - so you get the option to disconnect the RDP session, which in turn drops that from the... See more...
Disconnect is present on RDP because you're effectively running a terminal services session to the desktop - so you get the option to disconnect the RDP session, which in turn drops that from the View client. With a PCoIP session, you're logging into the actual console (hence you see the usual logoff restart and so on, but don't see disconnect). As you say, you can use the Group Policy to remove and prevent access to Shutdown, restart, sleep and hibernate (For info - User configuration>Policies>Administrative Templates>Start Menu and Task Bar>Remove and prevent access to the Shutdown, restart etc etc) for a start.  This will hide these items and force the user to disconnect from the session from the View client You could try pinning a shortcut to the Start Menu for C:\Windows\System32\tsdiscon.exe - this is the Terminal Session Disconnect utility - this will trigger a disconnect of the running Windows session, but whether that will end the PCoIP session to the Horizon Client, I don't know.  Might be fun to test though.
As cH1LL1@cH1LL1 says, it's somewhat dependent on use case, and how mobile your users are but heavy use of folder redirection Group Policy out to DFS-R presented file shares for user data is a go... See more...
As cH1LL1@cH1LL1 says, it's somewhat dependent on use case, and how mobile your users are but heavy use of folder redirection Group Policy out to DFS-R presented file shares for user data is a good place to start. For the user profile, well, this is trickier.  DFS-R isn't recommended for Roaming Profiles due to rate-of-change of data and using VMware Persona Manager won't help much here.  However, using UEM to manage the user profiles might be a better approach (subject, of course, to licensing). Use UEM to capture Application profiles for all of your applications and host the UEM Config Share on DFS-R. Then the remainder of the profile (which after application profile and folder redirection will be quite small) can sit on a straight file share.  You could go DFS-R here as users are unlikely to flit between sites rapidly, but it would also work with regular file shares for each site and allocating users accordingly.
Hi All, I'm running up an evaluation in a lab environment.  I have a vSphere 5.5 environment and I've built my App Volumes Manager. Everything seems to configure OK, but when I try and upload... See more...
Hi All, I'm running up an evaluation in a lab environment.  I have a vSphere 5.5 environment and I've built my App Volumes Manager. Everything seems to configure OK, but when I try and upload the prepackaged volumes, I get errors. The folder structure is set up without a problem on the destination datastore, but I get the following events in the system logs.  Any ideas? Jan 06 2015 11:35AM Failed to upload file "template_workstation.vmdk": https://(VCSERVER)/folder/cloudvolumes/apps_templates/template_workstation.vmdk?dcPath=CentralDC&dsName=iSCSI2 Jan 06 2015 11:35AM Error with https://(VCSERVER)/folder/cloudvolumes/apps_templates/template_workstation.vmdk?dcPath=CentralDC&dsName=iSCSI2: Maximum number of download attempts 2 surpassed Jan 06 2015 11:35AM Exception message: An established connection was aborted by the software in your host machine.