We currently use Horizon View at three of our clinics that cannot obtain a connection faster than 20+ mbps from any ISP because of their physical location. Because of the lack of bandwidth, we have to house the VM's onsite for them to remote into. Our environment houses individual pools based on an optimized template that has all of the necessary software installed on it for each facility - this makes things pretty easy for us, as all of our clinics need the same software suites. Pools are automatically adjusted based on the requests for logins, so if there's not enough VM's in the pool, a new one will automatically be created and composed for the user attempting to sign in.
We use scanners, SSO badge taps, and all sorts of other peripherals through the View client without many issues, as they are just loading and passing the host drivers through to the VM. There is one odd issue that I haven't been able to figure out, as it's pretty sporadic and it deals with networked printers. The printers that the clinics need are installed on the base image of the VM and are then passed through the client to CPS for it to take advantage of them. At random times, our users will call us and say that they cannot print to their main printer from the VM. When remoting in with them, checking their defaults in CPS and in Windows, you will see that everything is normal. But when you go to actually print an item from within CPS, you are presented with a different printer name than normal. Normally along the lines of: "PCFC #1" instead of "PCFC". The fix is to default to any other printer, then back to the original in Windows and then reopen the item you want to print and things will magically be fixed.
Not entirely sure if it's a driver issue, or if Windows has a cached printer port when a new session is launched. Like I said, it's random and doesn't happen often, but it's an easy enough fix. As for the latency on the View client, there's only so much you can do when you only have so much bandwidth to consume. In our case, all the work is happening at the server level, so all that's really happening is the "view" is being transferred over a much slower network to present to the user. I do occasionally test speed issues from within Centricity by putting some on-site users on the View client and have them compare against other fat-client users. Typically the VM's will always be faster, since they are at the server level.
Hope this helps a little.
Posted : May 30, 2017 6:54 am
