different mouse pointer?
If I log onto a client computer and change the mouse pointer, it stays the same the next time I log in. The same is true if I log into the server using RDP. But, if I log into the server using WSE RemoteApp, it changes it to default. Other pointer options like shadows and trails remain in effect but the pointer always gets changed to default and stays that way for subsequent logins, even through RDP. Is there a way to change the mouse pointer in WSE RemoteApp windows and have it stay that way?
- SomebodyInGNV asked 3 years ago
-
Scratch that. Now it’s sticky. I have no idea why it’s different, and I did try to test in an orderly controlled way.
- You must log in to post comments.
I’ve never come across this issue before in WSE RemoteApp, but admittedly, I’ve never attempted to change the cursor in any of my remote sessions before either (and as far as I can remember off the top of my head, that’s not a setting that WSE RemoteApp ever messes around with). Anyway, I’m glad to hear that it managed to resolve itself for you. Thanks for the update.
- Mike answered 3 years ago
- You must log in to post comments.
Well, now it switched back. The only connection I’ve made to the server since my correspondence above is through WSE. Not sure why Windows isn’t respecting the per-account settings.
- SomebodyInGNV answered 3 years ago
-
Probably not a priority seeing as I don’t know how many folks would ever want/need to do this, but I’ll certainly take a look at it and post back here if I can replicate the issue.
- You must log in to post comments.
Thinking about this one a bit more… It’s possible that RemoteApp sessions (as compared to full Remote Desktop sessions) just don’t support retaining the mouse pointer setting across different sessions (and what you saw initially was just a disconnected session vs a signed out session behavior). However, I don’t really think that’s actually the case.
Rather, and off the top of my head, I believe that features such as wallpaper, font smoothing, desktop composition, window drag, menu animations, themes, etc. are controlled within the remote session via redirection settings that are being set based upon the “Connection speed” Remote Desktop Option that you’ve chosen for the remote session. By default, I have the connection speed set to “Detect connection quality automatically“, and this setting automatically makes the connection speed choice for you based on the quality of the INITAL remote connection (and it is not readjusted later on within the session even if the quality improves).
Therefore, if your initial connection is not of very good quality, the connection speed will automatically be set to a lower value (in order to improve performance of the remote connection), and many (if not all) of those miscellaneous redirections will be disabled within the remote session. Again, I haven’t really spent any time looking into this yet, but this could be the cause of the mouse pointer setting not being sticky behavior that you’re seeing. You could test this by simply forcing the connection speed of your RemoteApp sessions to always be at WAN or LAN speeds (even when they truly aren’t), and see if that changes things for you (i.e. force WSE RemoteApp to always enable all of those miscellaneous redirections within the session no matter what the actual connection quality is).
Just be aware that there are three different ways to connect to a WSE RemoteApp session (locally via the Launchpad, remotely via the server’s built-in Remote Web Access website, or remotely via WSE RemoteApp’s RADC web feed feature), and each of those different connection methods have their very own set of Remote Desktop Options. Therefore, you need to make sure that you’re setting the correct options for how you’re connecting to your WSE RemoteApp sessions (with the Launchpad and Remote Web Access Remote Desktop Options being set on a per-user basis as shown here, and with the RADC web feed Remote Desktop Options being set on an all-users basis as shown here).
Hope that makes sense.
- Mike answered 3 years ago
- You must log in to post comments.