All Answers

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.

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.

I wrote from my e-mail (emulty@yandex.ru). Previously you answered very fast.

I didn’t change any settings on our server last few month. The problem appeared more than a week ago.

Today I completely reinstalled WSE RemoteApp and nothing changes. Now I can’t activate simultaneous connections to server. Tomorrow morning our employees should start working… :'(

I’m ready to provide credentials for you to check anything you need.

In server log I discovered such records:

WSERemoteApp

Error code 0

System.Net.WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. —> System.Security.Authentication.AuthenticationException: Удаленный сертификат недействителен согласно результатам проверки подлинности.
в System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
в System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
в System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
в System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
в System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
в System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
в System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
в System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
в System.Net.ConnectStream.WriteHeaders(Boolean async)
— Конец трассировки внутреннего стека исключений —
в System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
в System.Net.WebClient.DownloadString(Uri address)
в #=zqaw57GIe7hodl6sAZ1qi6o0n6O16.#=zyhX2Aj6iiNYQS7wV1whSVdk=.#=zoZ1IzvNBisdFvTutVA==()
в #=zlNIAKAsSorSQ5FcgGDXUhGD5HzyV.#=zDXDX3GspHiLm52zCIg==[T](Int32 #=z3LFQUb31ANk2, Int32 #=zYVFX20IQStx6, Func`1 #=zmpQ_VzcJOHUjg1hwlg==)
— Конец трассировка стека из предыдущего расположения, где возникло исключение —
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=zjy$qFGsSR8hnmoBOuw==(Exception #=z4C7bZdc=)
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=zYnzRKppgD0r4LPx1yhFTCW_Eq$xU(Object #=z4C7bZdc=)
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=zs9SexslixL8452h0qP7FTmY2QfUzw1s4cujC6lCHyr27(MethodBase #=z4C7bZdc=, Boolean #=zp6q2Cu8=)
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=zsNy4ub0AYiX0mxVFefKmIbJEK5N6(#=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE= #=z4C7bZdc=, #=qQmRRx12M4YUF1Lxv2IQkMQISKgH1MRrRbPytzAFDtjM= #=zp6q2Cu8=)
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=zpegoskdICIAtPU$B8w6W6eY=()
в #=q2cbU8Ns_6qZpvI0dtw3NXUkV0IKBiYcLXS6V32sYzsE=.#=z92JRzFYrvKeXhOUwwLuSq4wUaegyNAo7PMndDVprhYvZ(Boolean #=z4C7bZdc=)

WSERemoteApp

Error code 0

An error occurred while validating your license!

System.Net.WebException
Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS.

System.Security.Authentication.AuthenticationException
Удаленный сертификат недействителен согласно результатам проверки подлинности.

Web Exception Status: 9 (TrustFailure)

Alas, I’m not sure what else to tell you here other than to make sure that all of the latest Windows Updates are installed on your server. Nothing in WSE RemoteApp 2012 has been touched since way back in March of this year (i.e. nothing has changed over on our end that should have caused this to happen, and we can’t reproduce the issue over here).

Other than that, you will probably need to restore the server from backup back to a point in time when you know things were last working properly (hopefully you have Server Backup enabled!).

Restore or repair your server running Windows Server Essentials

I don’t believe that this has anything to do with WSE RemoteApp per se, but it’s more to do with your server not being able to communicate with our website because it’s not trusting the SSL/TLS connection for whatever reason. Our webserver requires TLS 1.2 communication, and so if it hasn’t been enabled on your server, that could be the issue. Did you try the suggestion that I offered you above about enabling TLS 1.2 on your server? If you can’t (because WSE RemoteApp won’t allow you to proceed), then you can try downloading this .REG file and running it on your server (and then REBOOT) in order to enable it:

DotNetFrameworkTlsSettings.reg

For a bit more info see: Enabling TLS 1.2 On Windows Server Essentials

Sorry that I don’t have a better answer for you on this one.

BTW, out of curiosity, do you have Anywhere Access enabled on your Essentials server? If so, are you able to successfully sign in to the server’s built-in Remote Web Access website (e.g. https://YourHostName.remotewebaccess.com/remote, etc.)?

I found in logs CAPI2 repetitved record with error ID 36885 and it lead me to this page: https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/ssltls-communication-problems-after-install-kb931125

Problem solved. Anyway many thanks Mike! : )

Interesting! I’ll have to dig into that one and check to see if KB931125 is installed on any of our in house 2012 servers or not. Anyway… I’m glad that you got it resolved now. Thank you for letting everyone know how you managed to resolve the issue. Nice sleuthing!

Anywhere Access enabled on server and our accountant department using it everyday.

Still this morning it working, but gave an error message TLS when start session, but all the same connection establish.
Now error disappeared.

I’m getting this same error on a 2016 datacenter edition.  Happened after the last update I installed for remoteapp.  I’ll post some info tomorrow.  Tried deleting the certificate key as stated in that microsoft article but that didn’t resolve it.

I’ve tried manually adding the Work Folders role through the Server Manager on the server itself, but this didn’t work, either (see image). Thanks for trying to help me.

On another topic: I’ve been working with Microsoft engineers for six months, trying to get my WS16E system to recover client files from backup, and they can’t fix this simple file restoration issue. Not being able to install your Work Folders add-on is the last straw. I’m fed up with my WS16E system. I’m going to build a new WS22S system and use your installer to add the Essentials app to it. I bought a copy of Work Folders today and will install it on the new new server.

OK, so it sounds like per-user licensing. Fair ’nuff.

Is it the same for WSE Work Folders?

Thanks,
Jeff Bowman
http://www.intexx.com

Well since you’re getting the exact same error when attempting to add the Work Folders server role manually via the Server Manager, that indicates to me that the error has nothing to do with the WSE WorkFolders add-in. Rather, it’s something that’s missing from the server itself that’s causing the issue. You could try opening up the Event Viewer applet and looking in there for the logged error to see if it gives a better indication of what referenced assembly is missing. As I’ve mentioned previously, I’ve never encountered such an issue before, and so I don’t know where else to go form here without knowing that information.

As for building a Windows Server 2022 system… Just contact us with the User Name from the license of your purchased product, and we’ll provide you with access to the WSEE Installer.

Very good, thank you.

Keep up the good work!

Thanks,
Jeff Bowman
http://www.intexx.com