Julian, please take a look as you were the owner of  bug 888694 . Thanks!

This is fixed in LBS 5.5.

Hi, i agree with the fact that LBS 5.5 resolve the issue with the Alternative browser parameters. 
But, i call the google support again because i have some findings to share with you after testing IE calls via the LBS 5.5.  After a discussion with our Google TAM, let me share you the explanation i transmit to the google support when i re-open this case :

"My last words were about the test of Chrome Legacy Browser Support beta version (v 5.5 - ebojbgfomggiamdflnhekjfkmdbeblpb;https://clients2.google.com/service/update2/crx. ). I confirm the alternate browser argument was correctly set. 
   But, finally, the different arguments set for the launch of IE (Internet Explorer) through the LBS, did not have the expected behavior to fix the bug we had with the management of Internet Explorer process.

   We tested different ways to find a workaround about our problem and I would to share these findings with Google Support and Chrome Engineering team. 


   Before you start to investigate, I want to explain our browsing Process context at Arkéa.

Context :
------------

Concerning our problem, it is a matter of setting up a specific gateway between our Front Office Application Desktop and applications currently run via IE. But with a special process management since we must systematically associate a new process with each launch of IE. We have to use a method of browser navigation close to the version 6 of IE. Each IE window is equal to a single process. It is like saying that one tab equals one IE window.
We made settings that go in this direction in the setting of IE (via Windows GPO). These settings allow us to manage a particular process filiation/connection (through the use of a custom desktop service present on our agency workstations) and to visually link application windows to a customer number.
We still need to use IE because we need use ActiveX (for launching EXE via a browser window) for some application scope.

      I record our user experience (with our current workaround) on a video that I can share and upload you (https://drive.google.com/open?id=1D-1FQEWTAhIBu4rs0k5HoX3lZlARJ6zC). 

But before watching this recorded session, I want to explain you the workaround I found when I did the debugging our browsing problem.

Workaround :

The Chrome LBS does not seem to handle disconnections to Firefox, Safari and IE in the same way. In order to debug the problem we faced and potentially find a workaround to our interactions with IE, I was able to make the disconnections working according to our target operation in 2 different ways:

The first way is, from the LBS, to call a binary other than IE and that supports the launch of IE by systematically creating a new process (create process process). I used the $ {safari} path (as the alternate browser path) to get the call to our binary that encapsulates the launch of IE. To do this, I had to modify the HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ App Paths \ SAFARI.EXE registry key and point it to our binary. The risk is very limited because no Arkea banking agency workstation has Safari.

The second way is to modify the HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ App Paths \ SAFARI.EXE registry key and point it to the IEXPLORE.EXE binary


In these two cases the disconnection to IE seems to be, via the creation in a different process each time. Theses methods solve our browsing interaction between Chrome and IE. The first method is shown in this recorded video : https://drive.google.com/open?id=1D-1FQEWTAhIBu4rs0k5HoX3lZlARJ6zC


On the other hand, if I use the classic IE disconnection with the $ {ie} option (as the alternate Browser path), the new IE window is attached to an existing Iexplore.exe process and is potentially captured by our office service (Chapnet.exe) which associates it with a client number, even if this window has nothing to do with this client.

In this case, shown in the recorded video https://drive.google.com/open?id=1bHP1Lg8uz2HWrh6bjCoP7ZnglZgPzxYN 


Next Steps ?
-----------------

So, for the moment we are in a PreProduction phase and not blocked to test our principal application in Chrome but iI am not satisfied with the current workaround I found to generalize deployment of our principal application on the 6 000 Arkea agency desktops. This workaround is considered as “dirty” and not viable.

=>Could you propose me a better solution to manage the IE calls/disconnection from Chrome ? 

For example : Is it possible to have a LBS option to launch IE ( systematically in a new process), in a similar way than Safari or is it possible to have a custom “alternate browser path” option we can use to call our custom IE Launcher ?"

I'm sorry if this explanation was a bit long...

Gilles Tomasino (Credit Mutuel Arkea - G Suite project technical team).

Hello Gilles,

The AlternativeBrowserPath support not only the special variables ${<browser_name>} but also direct local paths like C:\Program Files (x86)\Internet Explorer\iexplore.exe or to your custom binary. If you specify the path to iexplore.exe directly instead of using the ${ie} alias you should get new process each time as well because we only try to connect to existing Explorer instances if the ${ie} variable is used. This is needed to support users that wish to open URLs as new tabs instead of new windows in IE.

I hope this information is useful in resolving your issue.

Hello, 

  I didn't understand that, the first time i read the article on GPO. 

  I tested a settings with a direct local path and it works too. So i can manage my workaround in a more clean way. 

  So thank you for your help. 

Best regards. 
Gilles.