WSE Work Folder computers are all "Unknown"

Answered
0

Hello! I am testing out the Work Folders add-in, and so far everything has been great! The only piece I can’t seem to figure out is the “Computers” tab. All 3 of my computers show as “Unknown” despite having fully setup work folders on 2 of them. Is there another step to get them to not be “Unknown”

  • You must to post comments.
Great Answer
0

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:

Revoke Access to Work Files on Compromised Computers

  • cainmp
    I have version 1.0.200.0 installed on both, as that’s the version that installed when I downloaded the software on Wednesday. Internet access appears to be fine for the server, and it is fully patched as of today (Server 2016 Essentials).
  • Mike
    My mistake… I meant to say Version 1.0.200.0 or greater. I have corrected it above now. Other than that, I’m not seeing any issues here on any of our in-house test servers (2019, 2016, or 2012 R2). Everything appears to be working just fine (i.e. I’m seeing “Not applicable” for all computers that have not had access to their work files revoked, and either “Unknown” or “Confirmed” for those that have.). BTW, have you tried rebooting your Essentials server just to see if that happens to shake things loose for you? Also, if you’d care to provide a screenshot I’ll be more than happy to look into it a bit further for you.
  • You must to post comments.
0

Ok, so I have rebooted the server (and applied updates yesterday) and nothing has changed. I am attaching screenshots

 

Screenshots
  • You must to post comments.
0

Remaining screenshots

Screenshots
  • You must to post comments.
0

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?

  • You must to post comments.
0

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.

Screenshots
  • You must to post comments.
0

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.

Screenshots
  • You must to post comments.
0

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.

  • cainmp
    Yes, thank you. Never would have connected the two without the extra logging, so thanks a ton!
  • You must to post comments.
Showing 7 results
Your Answer
Post as a guest by filling out the fields below, or you may to post using your existing user account (register to create a user account if you do not already have one). Guest's questions will be moderated before being posted. NOTE: Your email address will not be published, nor will it be used for marketing purposes, etc. (as per our privacy statement).
Name*
E-mail*
Answer Details*
Screenshots
File Name Size
There are currently no files uploaded.
Maximum number of files 4, maximum file size 5MB.
Supported file formats: gif jpeg jpg png

Featured Questions

Recent Questions & Answers

Q&A Toolbox