RDP sessions not opening post upgrade to SPS 7.5.1

[uobnsturner]

I've just upgraded to SPS 7.5.1.

During my post upgrade tests, when i click on 'Start RDP Session', nothing happens. This was definitely working before the upgrade.

SSH does work but, after reading through https://support.oneidentity.com/kb/4259921/why-does-the-launch-button-on-safeguard-s-web-interface-not-initiate-the-session-as-expected, I assume it still works because I have WinSCP installed:

"SSH sessions use a ssh:// URI scheme. Later versions of WinSCP do install a handler to support ssh:// schemes. Any SSH session initiated from Safeguard’s web interface will initiate Putty if WinSCP is installed."

Not sure if it's just a local issue but thought i'd flag whilst i try and find the fix.

[ChangsGit]

Is your OS Windows 11?
I can run RDP normally in a Windows 10 environment with SPS 7.5.1, but I currently cannot through Windows 11. It seems to be caused by a Windows security update (KB5044285).

[uobnsturner]

Yep, I'm running Windows 11.

I raised a support call yesterday - looks like it's broke for lots of people:

We’ve identified that this issue arose following a recent update to both Chrome and Edge browsers it working fine in Firefox. we have marked this issue as defect 468532 for further investigation.
It appears that the problem is affecting only RDP session launches using SCALUS, while SSH sessions are working fine.
As a temporary workaround, you can either download the .RDP file or use Firefox to launch your RDP sessions without any issues.

[Kevin-Andrew]

See:
https://issues.chromium.org/issues/373928202

Another possible workaround is to revert the behaviour change in Chrome and Edge by setting flag --disable-features=StandardCompliantNonSpecialSchemeURLParsing.

[PrernaAtwal]

This issue seems to be due to the latest chromium updates which is breaking custom urls in 130 version.
https://issues.chromium.org/issues/373928202

Workaround
Immediate workaround will be to launch browser by disabling flag "C:\ProgramFiles\Google\Chrome\Application\chrome.exe" --disable-features=StandardCompliantNonSpecialSchemeURLParsing which resolves this issue or switching to firefox.

Here are the steps to disable flag for chrome:

1. Right-click on the shortcut for Google Chrome.
2. From the right click menu, select Properties.
3. Append --disable-features=StandardCompliantNonSpecialSchemeURLParsin g after the .exe portion in the Target box.
4. Launch the browser with the modified shortcut.

[jakekz801]

The --disable-features=StandardCompliantNonSpecialSchemeURLParsing will be removed in M134 planned around Tue, Mar 4, 2025.
Reference: https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA

[altiris4ever]

This issue seems to be due to the latest chromium updates which is breaking custom urls in 130 version. https://issues.chromium.org/issues/373928202

Workaround Immediate workaround will be to launch browser by disabling flag "C:\ProgramFiles\Google\Chrome\Application\chrome.exe" --disable-features=StandardCompliantNonSpecialSchemeURLParsing which resolves this issue or switching to firefox.

Here are the steps to disable flag for chrome:

1. Right-click on the shortcut for Google Chrome.
2. From the right click menu, select Properties.
3. Append --disable-features=StandardCompliantNonSpecialSchemeURLParsin g after the .exe portion in the Target box.
4. Launch the browser with the modified shortcut.

We deploy the Scalus msi automatically to our users now with a job that also is installing the cert and trusting the rdp so they get no nags, I guess I will have to deploy a couple of shortcut to both Edge and Chrome called something like "Scalus RDP fix for Edge" and Scalus RDP fix for Chrome". It's not ideal, but at least it will work. The difficult task is to inform the endusers how to use this workaround ......

[ChangsGit]

Today I tested the Edge browser and could successfully call Scalus. My version is 130.0.2849.56

[toru-haraguchi-iijglobal]

According to Chrome team, it seems that Chrome's new behavior is as intended except dropping ":" after "//" and then will persist after M134 which drops the work around "--disable-features=...".
Does the new behavior so said "standard compliant" which will be introduced into M131 continue to affect SCALUS? If so, how will SCALUS team react against the change?

[Kevin-Andrew]

If so, how will SCALUS team react against the change?

Unfortunately, the problem cannot be fixed, nor worked around by SCALUS. It is the web UI application that tries to "launch" the RDP URL, but the web browser blocks it. So SCALUS isn't even involved at that point.

Either the Safeguard API or web UI (or both) will have to change. And then when it does, SCALUS will also have to change.

And then there is the issue of backwards compatibility. This problem doesn't exist with Firefox. So if changes are made to either the Safeguard API or web UI, then it will break people using Firefox. Or they would be forced to update SCALUS or modify their configuration.

[dmy2000]

I can still open a torrent client by clicking magnet: URI
So it can be fixed, by going from rdp:// to something compliant with the modern browsers!

[dmy2000]

If so, how will SCALUS team react against the change?

Unfortunately, the problem cannot be fixed, nor worked around by SCALUS. It is the web UI application that tries to "launch" the RDP URL, but the web browser blocks it. So SCALUS isn't even involved at that point.

Either the Safeguard API or web UI (or both) will have to change. And then when it does, SCALUS will also have to change.

And then there is the issue of backwards compatibility. This problem doesn't exist with Firefox. So if changes are made to either the Safeguard API or web UI, then it will break people using Firefox. Or they would be forced to update SCALUS or modify their configuration.

SCALUS can suppot both compliant and legacy URIs, for 2.6% of Firefox users

[toru-haraguchi-iijglobal]

Though this is a change in SPP UI, here is pseudo code:

if $BROWSER in $NEW_PARSER_BROWSERS
  $URL.gsub( /^([\w]+:)\/\//, '\1' ) unless $URL in $SPECIAL_URLs
end

[altiris4ever]

I have used the --disable-features=StandardCompliantNonSpecialSchemeURLParsing parameter as part of my shortcuts since this new behavior was known in both Edge and Chrome. But today it doesn't work in my edge browser, v. 133.0.3065.59.
Chrome is still working v. 133.0.6943.60 and later updated to 133.0.6943.99 and still working.