Chat, messaging and notifications do not appear on a Windows target system when user is logged in via RDP

[McPhilabuster]

Describe the bug Chat, messaging and notifications do not work when trying to initiate chat/messaging, etc.. with a user connected via RDP on a target Windows device. All work fine when connected to a console session. In other words, if logged in physically to a machine or to a VM console session it works, but if a user is connected via RDP and you attempt to initiate a chat session, send a message or perform an action that should produce a notification these functions do not work.

To Reproduce Steps to reproduce the behavior:

1. User logs in via RDP to the intended target system.
2. From Mesh Central initiate a chat session, send a message or perform an action that should produce a notification.
3. No chat sessions, notifications, etc... are shown to the user.

Expected behavior Chats, notifications and messages should appear on the screen in the logged in user's session.

Server Software (please complete the following information):

• OS: Ubuntu
• Virtualization: Docker
• Network: standard docker network settings Default config from template docker-compose.yml file. No reverse proxy.
• Version: latest docker image
• Node: latest docker image

Client Device (please complete the following information):

• Device: Desktop
• OS: Windows 10 21H2
• Network: LAN
• Browser: MS Edge
• MeshCentralRouter Version: n/a

Remote Device (please complete the following information):

• Device: Virtual Machine
• OS: Windows 10 20H2
• Network: LAN
• Current Core Version (if known): whatever is used in latest docker image

Your config.json file Unchanged from default docker config.

Additional notes It appears that the mesh central service is targeting only the console session for on screen notifications and launching of the browser window for a chat session. I tested and reproduced this issue on serval VMs, but I expect the behavior would be the same on physical systems.

[krayon007]

Normally on the kvm, it prompts the user to select which session to connect to. I don't think this prompt is there for the chat. The agent needs to spawn the browser window into a user desktop session. Normally it selects the session ID of the physical console. But all the logic is there to support other sessions, so this should be easy to fix, as it would just be a server side change to the meshcore.

[McPhilabuster]

@krayon007 I figured something like this was the case. I did see that you can target the console session from the desktop tab. As such, I also figured it would not be difficult to target the RDP session of the user at least for the chat and possibly message functions. What about the notifications? Let me know if you need more info or need anyone to test any changes. I just started testing Mesh Central so it's not in production and I can always spin up a new docker instance if I need to. Thanks!

[McPhilabuster]

Another thought, while I'm sure this is possible to adjust via server-side changes, at least for the chat function, the notifications and such would probably need to be adjusted on the agent side. Windows client operating systems by default only allow one active session at a time unless you go mucking about and change things and break the terms of service. As such, targeting the currently active session on the agent side would correct this as well.

[Avessalom608]

I also noticed that if I completely shut down the user's session via "logout" and re-login, then the console session and the user's session in Mesh will not be separated and therefore chat and notifications will work correctly.