Start ShellAppRuntime.exe during session initialization so Microsoft 365 sign-in works in published applications (ref ticket #142934)

The alternate shell is typically what the TSplus HTML5 web client uses, so this affects anyone accessing their session through a browser as well as conventional published applications. In both cases Microsoft 365 sign-in fails inside the TSplus session. Office apps show error 7q6ch and the underlying error is 0x80040154 (Class not registered). OneDrive is affected in the same way.

The root cause is that modern Office builds authenticate exclusively through Windows Web Account Manager (WAM). The WAM broker is hosted by ShellAppRuntime.exe, which is normally started as part of the Explorer shell during logon. In a TSplus session that launches a published application or alternate shell instead of Explorer, ShellAppRuntime.exe is never started, so the WAM broker is unavailable and every Microsoft 365 sign-in attempt fails.

The old workaround of forcing Office back to the legacy ADAL stack and disabling WAM no longer works. Microsoft has deprecated ADAL and current Office builds (we confirmed on Office 2408) ignore the DisableAADWAM registry setting, so WAM is now mandatory. There is no supported way to avoid it going forward.

We confirmed the fix in our environment: launching ShellAppRuntime.exe at session initialization, without starting Explorer, restores the WAM broker and Microsoft 365 and OneDrive sign-in then works normally in published applications. We currently do this via a GPO logon script, but that is a per-customer workaround that has to be discovered, deployed and maintained by each admin independently.

One thing to be aware of when implementing this: starting shell initialization in this way also causes any applications registered under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to launch in the session, which would not normally happen without Explorer as the shell. Admins should review what is in that key before rolling this out, and it is worth TSplus considering whether that behaviour should be controllable as part of the feature.

The request is for TSplus to start ShellAppRuntime.exe as part of its own session initialization for published application and alternate shell sessions. This would benefit every customer who publishes applications without a full desktop, since they will all hit this as Windows and Office updates roll through their estates. It also removes a very hard to diagnose failure mode, because the error codes give no hint that a missing shell process is the cause.

Full technical details, process traces and the confirmed workaround are documented in support ticket #142934, which your support team have reviewed and agreed reflects the correct direction for modern environments.