Considering the points raised in Part 1. How should you deploy Chrome for ease of management and to deliver the best experience while reducing the risk of it’s resource draining ways?
- Traditional Deployment to Physical Workstations
Deploying through SCCM or any other ESD product to your workstations works. You can also control the auto-updates via group policy so you don’t constantly have to package deploy for each release. By delivering to the physical workstations you avoid resource issues on your RDSH due to Chrome being a RAM hog. You’ll still need to keep on your toes and actively manage two browsers but it should deliver a good end user experience.
You could just deploy Chrome on as needed basis and remove the desktop, start menu and quick launch shortcuts so users aren’t aware they have it on their workstation.
Chrome gives you the ability to go to a site and generate a shortcut which when launched will open the site in the browser but with the tab menu and all other menus removed. It’s pretty limited and not at all easy to deploy (unless using App-V or a different appvirt product), when extensions are required it may not help much. Also, as soon as a user clicks on a sublink to a different site, it’ll just open a new Chrome instance which by default will be pretty open to the users and allow them to browse all day to their heart’s content. I will being post a part 3 of this series which gets into this in more detail but I also posted a short synopsis on creating and deploying this shortcut to physical workstations:
It doesn’t help much, eh? Wouldn’t it be cool if it did work better? If users couldn’t just break out into a new window for external links? If it wasn’t such a hassle to deploy? Keep reading, I’ve got some good suggestions which execute this type of scenario much better.
2. Hybrid Deployment
Image sourced from Citrix.com
A cool hybrid solution for some use cases are Workspace products such as Citrix Workspace App (assuming this is how it will function!), VMware WorkspaceOne and Software2 AppsAnywhere. Most of the web apps I have come across over the last 3 years which have not worked in IE but do in Chrome have been web based SaaS apps. These can be accessed externally with multifactor authentication. This can be perfect for scenarios in which an organization has a mix of remote and on-premises workers or even more ideally have 100% remote workers.
You can publish icons for the web apps that require Chrome and have those launch within Chrome on your user’s personal device. If Chrome is not installed, it can prompt them to install themselves. Self service baby!
For those working on-premises, you can deploy Chrome locally and remove the shortcuts, instead delivering the shortcut through for the app through your Workspace.
This isn’t a very complete picture of a great user experience however. If they are on-prem or you want to deploy in RDSH or VDI, this won’t help you contain the resource usage, manage the updates better and it’s not the best way to enhance your Chrome security. Also, what happens if your users try to access a web app or site which will only work in Chrome from Internet Explorer? That could generate helpdesk calls and who wants to deal with that?
Another option is to publish shortcuts with chrome.exe –kiosk {URL}
You could use whitelisting to control what sites the users can then get to but again, it’s not the best solution.
3. Kickass 3rd Party Products
Turbo.net and Browsium Ion both offer the ability to redirect certain whitelist URLs from one browser to another. So, it can help eliminate helpdesk calls from users who try to browser to a web app which only works in Chrome when in IE or even vice versa, if you have sites or apps that should only launch in IE you can redirect from Chrome to IE.
Browsium’s suite can also selectively render web apps for a legacy version of IE e.g. a site which only works in IE can run and look like it’s working natively within IE 11. I have a comprehensive rundown of Browsium which you can read here. It’s a really impressive suite of products. It can help you manage multiple version of Java, enhance Java security, ActiveX and more. It’s pretty much a one stop shop for all things browser management.
Turbo.net is a Windows containerization product. Unlike other container products which are more developer and server app focused. Turbo.net covers the entire spectrum of developer, server and desktop applications including browsers. By leveraging the isolated dedicated network stack, you can create redirection rules similar to those described in my Browsium post and you can restrict the browser to certain sites similar to Chrome shortcut in my video BUT since it’s an isolated network stack with custom routing rules you can restrict users from getting out to wherever they please.
This makes delivering Chrome on RDSH or VDI much more realistic. By restricting use to only cases in which it’s required you limit the possibility of it draining memory. You can also selectively deliver extensions to those who need extensions. You can have as many iterations of these Chrome containers as you please and you don’t have the same Chrome update headaches as the Turbo.net plugin\agent can pull new versions as they are release on the Turbo.net hub.
If you work for an organization who are not willing to open the wallet, your best bet may be a mix of different products you already own. If you are a Microsoft shop, you might have App-V. Keep an eye out for part 3 in this series which will be posted in the coming weeks.
