To support Chrome inside RDP session you have two options.

A: run AdminTool GUI > Server > Session Opening Preference > Use native Windows shell when opening sessions > Save > Reboot (mandatory)
If you don't find the feature in AdminTool, then install latest Tsplus update, reboot and retry A: again.

or

B: add --allow-no-sandbox-job switch as run time parameter to chrome.exe (however that may work unexpected on different systems)



The main difference between TSplus shell and Windows Shell is technical, and should be transparent for remote users.

TSplus shell:
This is the method we have been using for the past 10 years.
We use the RDP registry named InitialProgram to start logonsession.exe, which handles application publishing for users and groups.
In fact, Windows considers the use of this setting as if mstsc.exe has request him to start a specific program at logon
As result, we are in the Remote Desktop “paradigm”.

Windows Shell:
This method is a new one.
We use the system registry named UserInit to start logonsession.exe
This means that any Windows opening session process is going to start logonsession.exe at the very first step of Windows session opening processes.
Doing so, we do not care about the RDP environment and the Windows behavior is a little bit different. We are more “basic”.

So basically for the end user there should not be any difference, since this method of handling session opening is fairly new, we kept both ways to ensure compatibility with most systems. Most probably we will switch to native windows shell in the future and remove tsplus shell.