BYOD adds complexity to hosted VDI implementations
We compared hosted virtual desktop infrastructure (VDI) products from Microsoft, Citrix, VMware, Oracle and Ericom and came to many conclusions, but the most important one is this: Setting up hosted desktop sessions in a BYOD world is a complex undertaking.
When a user grabs a device and wants to access a session, the first step is downloading an app for the device, which may or may not have additional configuration steps. Thankfully, most of the client-side apps we tested needed no more than an IP or DNS address name -- and one (Oracle) could do an automated search by an address pre-seeded in the client.
If and where possible, we strongly recommend mandating a VPN connection before linking to a network, but this isn't always possible or feasible. Once a user initiates a session, a connection broker takes the user's request, and after an authentication step, the broker chooses an ad hoc or persistent session.
Here's where things get thick. The session is a live instance running as a virtual machine on the network, therefore, the session must wake up and be a fully functioning member on that network so as to reach its resources and deliver some of the characteristics of the session to the user's remote device. No matter what device they’re on or where they are, users want a beautiful analog of what they might see on their desktop at the office.
The user must also be authenticated, often through a local user database, LDAP or Microsoft's Active Directory. Printing resources must be defined. By user or group attribute, an administrator must determine sharing of information in concepts like: do you allow the user to store data away from the host session? Can a user launch a web session on the virtualized and remotely connected session? Is there just one or a handful of apps to use, or is the session wide-open? Does the user get to own the session for the next reuse, thus burning a license?
Indeed licensing issues, and how Microsoft treats Windows licenses, cause VDI makers considerable grief, because of the many licensing plans Microsoft offers, and how VDI sessions might use up available licenses. Careful consideration is required as in some cases, 100 non-persistent sessions could decrement the entire 100-license pool quickly and permanently until the problem is found and resolved.
Then there are session customizations, so that users land with the correct session customizations. The sessions must work well, perhaps in ugly circumstances such as over-subscribed Wi-Fi access points in remote locations.
Uncontrollable events can occur, such as logon storms, when many people must suddenly meet for online meetings using VDI, or other event storms that can task building ad hoc sessions. It's a lot of work. We know because we did it. And there were items we had to gloss, like multi-monitor capabilities (Horizon View has it), constraining video characteristics (shared by most all), super-multimedia (too many device differences), and strict adherence to policies (Active Directory or session-managed).
We compared hosted virtual desktop infrastructure (VDI) products from Microsoft, Citrix, VMware, Oracle and Ericom and came to many conclusions, but the most important one is this: Setting up hosted desktop sessions in a BYOD world is a complex undertaking.
When a user grabs a device and wants to access a session, the first step is downloading an app for the device, which may or may not have additional configuration steps. Thankfully, most of the client-side apps we tested needed no more than an IP or DNS address name -- and one (Oracle) could do an automated search by an address pre-seeded in the client.
If and where possible, we strongly recommend mandating a VPN connection before linking to a network, but this isn't always possible or feasible. Once a user initiates a session, a connection broker takes the user's request, and after an authentication step, the broker chooses an ad hoc or persistent session.
Here's where things get thick. The session is a live instance running as a virtual machine on the network, therefore, the session must wake up and be a fully functioning member on that network so as to reach its resources and deliver some of the characteristics of the session to the user's remote device. No matter what device they’re on or where they are, users want a beautiful analog of what they might see on their desktop at the office.
The user must also be authenticated, often through a local user database, LDAP or Microsoft's Active Directory. Printing resources must be defined. By user or group attribute, an administrator must determine sharing of information in concepts like: do you allow the user to store data away from the host session? Can a user launch a web session on the virtualized and remotely connected session? Is there just one or a handful of apps to use, or is the session wide-open? Does the user get to own the session for the next reuse, thus burning a license?
Indeed licensing issues, and how Microsoft treats Windows licenses, cause VDI makers considerable grief, because of the many licensing plans Microsoft offers, and how VDI sessions might use up available licenses. Careful consideration is required as in some cases, 100 non-persistent sessions could decrement the entire 100-license pool quickly and permanently until the problem is found and resolved.
Then there are session customizations, so that users land with the correct session customizations. The sessions must work well, perhaps in ugly circumstances such as over-subscribed Wi-Fi access points in remote locations.
Uncontrollable events can occur, such as logon storms, when many people must suddenly meet for online meetings using VDI, or other event storms that can task building ad hoc sessions. It's a lot of work. We know because we did it. And there were items we had to gloss, like multi-monitor capabilities (Horizon View has it), constraining video characteristics (shared by most all), super-multimedia (too many device differences), and strict adherence to policies (Active Directory or session-managed).
No comments:
Post a Comment