All Answers
The computer versions are:
- Client – Windows 10 1803
- Server – Windows Server 2016 Datacenter 1607
Outlook is 365 – 16.0.10730.20264
Also I’ve been having another issue where if there is a program on the same screen where outlook is open and I put it behind outlook then sometimes the background program pops up randomly.
I’ve added a link, https://photos.app.goo.gl/LDviYMVubNHUxM51A, to a video where you can see the behaviour. As I move my mouse across the screen you see Spotify popping up with PowerShell behind it, then it goes back to Outlook and so on.
- Kal answered 7 years ago
- last active 7 years ago
Alas, I’m afraid that those particular “issues” (i.e. bugs) have absolutely nothing whatsoever to do with WSE RemoteApp. They are actually being caused by bugs within the Remote Desktop Connection client that’s built into Windows 10. The problems did not exist under Windows 10 Version 1703 (or earlier), but appeared when Microsoft released Windows 10 Version 1709.
Microsoft has since released some Windows Updates that have lessened the issues somewhat, but they still persist to this day (even under Version 1803 and 1809). Microsoft’s “Remote Desktop Services” TechNet forum is absolutely littered with folks complaining of the same issues (but Microsoft doesn’t seem to care very much – if at all!):
RemoteAPP after windows 10 update 1803 are slow and right mouse button is not responding (it reacts only sometimes)
(note that this one is totally insane with 625 replies and 112,091 views!!!)
W10 1709 RemoteApp – Pop-ups hidden behind main window
RDS 2016 – Outlook showing underlaying window
Windows Server 2012 R1 RemoteApp is bugged with Windows 10 1809 clients
Thus, I’m afraid that there’s nothing I can do about it from my end. We’ll just have to sit tight and wait to see if Microsoft steps up and fixes the issues with a future Windows Update, or in a newer version of Windows 10.
- Mike answered 7 years ago
- last active 7 years ago
Microsoft has released KB4480977 (January 17, 2019), which brings Windows Server 2016 up to OS Build 14393.2759. One of the “improvements and fixes” listed for the update is:
Addresses an issue that causes RemoteApp windows to disappear and reappear intermittently on Windows Server 2016.
Therefore, you might want to try installing all of the latest Windows Updates on your server just to see if it helps resolve the issue for you.
- Mike answered 7 years ago
- last active 7 years ago
I installed it, restarted and still having the issue above.
- Kal answered 7 years ago
- last active 6 years ago
If you are only planning on using WSE RemoteApp locally (i.e. from the Launchpad of any of your Essentials server connected client computers), then you do not need to have Anywhere Access/Remote Web Access enabled on your Essentials server in order to use QuickBooks (or any other published RemoteApp program) from WSE RemoteApp.
However, if you want to be able to access WSE RemoteApp remotely (i.e. from the Essentials server’s built-in Remote Web Access website, or via the add-in’s RADC web feed feature), then you do indeed have to have Anywhere Access/Remote Web Access set up and properly configured with a domain name and a trusted SSL certificate much be associated with the domain name.
For more information see:
Successful Connections Require Secure Remote Web Access Setup!
- Mike answered 7 years ago
- last active 7 years ago
You cannot enable printer redirection in WSE RemoteApp via the method that you’ve shown within your attached screenshot. WSE RemoteApp has it’s own built-in way of enabling printer redirection for the RemoteApp sessions it generates (i.e. via its “Remote Desktop Options” dialog boxes). I’ve discussed two of those methods within the article I believe you are referencing. While the article was indeed written back in September 2014 (and last updated in November 2017), it can still be applied to WSE RemoteApp as it exists in its current form.
- Mike answered 7 years ago
- last active 7 years ago
Actually, that is completely expected, and is “by design”. The reason for this is that you don’t really want your users being able to easily uninstall the WSE WorkFolders client component from their computers since it is what implements the revocation of access to their work files should the client computer be compromised as is discussed here:
Revoke Access to Work Files on Compromised Computers
That being said… The WSE WorkFolders client component “should” get uninstalled automatically whenever you uninstall the WSE WorkFolders add-in from the Essentials server (i.e. when you uninstall the add-in via the “APPLICATIONS” page of the server Dashboard), or whenever you uninstall the Windows Server Essentials Connector software (i.e. the Launchpad, etc.) from the client computer. If not, then please feel free to contact us via a private support message and I can give you further instructions on how to remove it from the client.
- Mike answered 7 years ago
Ah, I see. I had considered that this might be a possibility, but I did not want to uninstall the server component to test for this.
Thank you Mike.
- Silversee answered 7 years ago
- last active 7 years ago
Typically, a computer will show “Unknown” in the “Wipe Status” column if you have revoked access to its work files (via the “Revoke access to work files” task), and the add-in is currently unable to communicate with the client computer in order to verify that it has been successfully wiped or not.
In a nut shell, when you run the “Revoke access to work files” task on a computer, WSE WorkFolders sets a flag for that computer (on our webserver) indicating that access to its work files has been revoked by its administrator. The next time the client computer comes online, WSE WorkFolder’s client-side add-in will then check that flag to see if it has been set or not. If it has been set, then it will automatically wipe the device (i.e. revoke access to the work files stored on the device by revoking its work files encryption key), and then set an additional flag confirming that the wipe has indeed taken place. When WSE WorkFolder’s server-side add-in sees that the additional flag has been set, it will then change the “Wipe Status” for the client computer from “Unknown” to “Confirmed“.
So… If you’re seeing an “Unknown” wipe status for the revoked computers, then it simply means that they haven’t (yet) come online in order to receive their wipe command. Whereas, if you’re seeing a “Confirmed” wipe status, then you know for certain that they have come online and that the encryption key for its work files has indeed been successfully revoked.
That being said… If you’re seeing an “Unknown” across the board for all of your client computers (without revoking access to any of them), then please make sure that your server has a valid Internet connection, AND that you have the latest version of WSE WorkFolders (i.e. Version 1.0.200.0 or greater) installed on BOTH the Essentials server, AND on the client computers themselves.
NOTE: You can check the version of WSE WorkFolders that is currently installed on your Essentials server by opening up the server Dashboard, going to the “WORK FOLDERS” page, and clicking on the “About” task.
NOTE: You can check the version of WSE WorkFolders that is currently installed on your client computers by opening up the “Programs And Features” Control Panel applet (or the “Apps & Features” Settings page on newer Windows 10 clients), and clicking on the “Client Connector for WSE WorkFolders” program/app.
Additional information about WSE WorkFolder’s “Revoke access to work files” feature can be found here:
- Mike answered 7 years ago
- last active 7 years ago
Ok, so I have rebooted the server (and applied updates yesterday) and nothing has changed. I am attaching screenshots
- cainmp answered 7 years ago
Remaining screenshots
- cainmp answered 7 years ago
Sorry for the delay in responding. It took me a while to look into this one a bit more thoroughly for you…
First off, thank you for the terrific screenshots as they really are a big help to me when trying to understand exactly what’s happening. That being said… I’m just not able to reproduce the problem you’re seeing over here on any of our in house test servers.
The only reason that the “Work Files Access” column would be showing “Unknown” for all of your client computers like that (as well as them all being grouped as “Unknown Computers“) is if the add-in were unable to communicate with our webserver in order to verify if the wipe flag has been set for the computers. If WSE WorkFolders is unable to communicate with our webserver, then it simply defaults to showing “Unknown” in that column. Most commonly, that would happen when the server does not have a working Internet connection. However, it could also happen if access to theofficemaven.com is somehow being blocked on your server (by a firewall, antivirus program, proxy, etc.).
If you’re sure that’s not the case on your server, then I’ve just posted a new version of WSE WorkFolders 2016 (i.e. Version 1.0.201.0) in which I’ve added a bit better error handling/logging to it in this area. Therefore, if you’d like to download and install the new version (you can download it straight from the WSE WorkFolders home page and install it right over-the-top of your existing installation), you can then start a standard Remote Desktop connection to your server, sign in as an administrator, open the server Dashboard, open the Event Viewer applet (by clicking on the Start menu and typing “Event Viewer“), go to the Windows Logs -> Applications log, and see if any entries show up there with the “WSEWorkFolders” source (note that you can filter the log file by that source using the “Filter Current Log” task, and checking “WSEWorkFolders” under the “Event sources” drop-down list).
Does anything show up there after installing the latest version?
- Mike answered 7 years ago
- last active 7 years ago
That pointed me in the right direction! (Error attached) I have modified the default SSL settings using IIS Crypto. I used the “BestPractices” (See attached)
I will work to revert to default to see if the error goes away. That said, I performed the SSL modifications in order to fall closer to best practice for IIS, so I encourage digging into this further to see what setting is causing issues.
- cainmp answered 7 years ago
Ok, I bit the bullet on the restart and went ahead and restored SSL settings to default. That brought all computers to “Allowed Computers”, so that’s great. I then noticed there was an update to the IIS Crypto software, so I downloaded that and re-applied the “Best Practices” and now everything appears to be working as expected. So I would chalk this one up to old or outdated SSL best practice settings from the IIS Crypto software.
- cainmp answered 7 years ago
Bingo! Looks like you’ve found the culprit then. Kudos!
All communication with our webserver is performed over SSL/TLS 1.2 (https) so that it is always completely secure. I’m not familiar with the IIS Crypto app (but I am aware of it), and so I’m not exactly sure what it’s doing (or what you’re doing with it). However, I can tell you that an Essentials server absolutely requires that TLS 1.0 be enabled in order to properly function.
You cannot disable TLS 1.0 on an Essentials server seeing as doing so will cause all kinds of problems/failures just like this to creep up; including loosing client backup functionality, causing add-ins with client-side components such as WSE WorkFolders and WSE RemoteApp to fail to install/update their client-side components, and making it so that the server can no longer properly communicate with the clients, client-side add-ins, etc.). For a bit more info see:
Essentials Server PCI Compliance and TLS 1.0
https://windowsserveressentials.com/?s=TLS
In all of my WSE RemoteApp add-ins, I have actually added a feature that will properly set up IIS for SSL perfect forward secrecy and TLS 1.2, as well as enable HTTP Strict Transport Security, on the Essentials servers without disabling TLS 1.0 and breaking all of the above mentioned Essentials functionality (i.e. it gets you as close as you can possibly get to PCI Compliance on an Essentials server). The script that I use is based on work done by Hass Alexander:
Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2
However, the script needs to be modified somewhat in order for it to work properly with an Essentials server.
Anyway, I’m glad to hear that the extra error handling/logging I added helped you discover what was causing the issue.
- Mike answered 7 years ago
As far as I am aware… Work Folders is a web server, and as such, it performs its duties over a HTTP/HTTPS WAN connection. Thus, I’m not currently aware of any way to force it to use an internal LAN connection (and if it is indeed possible, then I’ve simply not come across that before, and I’ve certainly not set up WSE WorkFolders to work in that fashion). Doing a quick Internet search revealed only this one hit for me:
Work folders without support for synching over the Internet – LAN use only
Other than that… There is a “Storage at Microsoft” blog post that discusses how to limit Work Folders client bandwidth (via Group Policy) if upstream bandwidth usage is a problem for your network, but I’ve never tried/tested it with WSE WorkFolders before, and so I have no idea if it will actually work or not:
How to limit Work Folders client bandwidth
I’m sorry that I don’t have a better answer for you on this one.
- Mike answered 7 years ago
Alas, I’m afraid not. That’s most likely an issue with whatever connection client it is that you’re using in order to connect to the server from your iPad.
- Mike answered 7 years ago
Yes, it’s in the “What’s New?” release notes:
NOTE: The ability to add the list of published RemoteApp programs to the WSE RemoteApp Launcher‘s context menu has been depreciated seeing as this would sometimes result in an uncaught Win32Exception exception (Error creating window handle.) being thrown when the user clicked on the notification area icon in order to show the context menu. Users should now access all published RemoteApp programs directly from the main launcher window instead.
It was a really hard fought battle on this one, but I lost… After spending nearly three days trying to fix/work around the problem, I finally had to admit defeat, and remove the feature altogether I’m afraid. I’ll keep thinking about it/looking at it, and if I can ever figure out what’s causing the crashes, then I’ll fix it, and add the feature back in again.
Build 1700/1701 was a HUGE release with lots of new features, changes, fixes and enhancement. Something within all of that is triggering the crashes, but I’ll be damned if I can figure out what it is. I’ve tried rolling everything back to square one, but still couldn’t get rid of the crashes under every scenario. In the end, I simply gave up and removed the feature entirely. I guess you just can’t win them all.
Sorry for the inconvenience on this one.
- Mike answered 7 years ago
- last active 7 years ago
Sorry, but WSE RemoteApp would have no control over doing something like that I’m afraid. The desktop application that you’re publishing as a RemoteApp program would need to natively support the ability to start itself in (or minimized to) the taskbar’s notification area in order for that to happen.
WSE RemoteApp simply launches the program as a RemoteApp, and then gets out of the way. It has no control whatsoever over how the program’s windows behave (i.e. whether they become visible or not, etc.) once it is running within the RemoteApp session.
Sorry that I don’t have a better answer for you on this one.
EDIT: It looks like Outlook has the ability to hide itself (in the tray) when minimized. I’ve never tried it, but you might be able to enable that setting, and then tell WSE RemoteApp to always hide it from the main Launcher window, and start it minimized (in which case it “should” go to the tray instead of the taskbar). Totally unsupported/untested by me, but hopefully it helps you out some:
- Mike answered 7 years ago
- last active 7 years ago
FYI… I’ve just released Version 1.255.1706.0 in which I’ve now added back in the functionality that was removed from the prior build. However, instead of adding it back to the existing “right-click” notification area icon context menu, I’ve created a brand new “left-click” context menu that now displays the list of published RemoteApp programs instead (i.e. from now on you can just left-click the icon to see the list of published RemoteApps instead of right-clicking on it as you previously did).
This was the only way that I could find to resolve the issue with the uncaught exceptions/crashes. However, I think that things actually work out much better this way seeing as it’s a lot cleaner having the list of published RemoteApps completely separate from all of the other program settings, etc. Otherwise, the context menu would become very unwieldly when you had a large number of published RmeoteApps.
In addition, I’ve now added in a cap/limit of having a maximum number of 20 unassigned RemoteApps and/or program groups being added to the new left-click context menu (in order to conserve resources and screen real estate). If you have more published RemoteApps than that, then a “More RemoteApps…” item will appear within the list. And, when it’s clicked, it will simply open up the main launcher window (for access to those additional RemoteApps).
I hope that works for everyone. I myself think that it’s a decent compromise.
- Mike answered 7 years ago
- last active 7 years ago
