While the Block Exe from %AppData% policy is very powerful in preventing remote attacks, it can have an immediate and negative impact to existing workstations as users find they can no longer run applications they rely upon.  This document will show you how to apply this policy without blocking current applications.

The key to this is running an Application Scan before enabling the policy.  To do this, open the Client window of the intended recipient.  Press the 'Third Wall' tab and then click the blue AppData Exe Exceptions & Discovery link on the top right.  That will bring you to this screen:

Before you run the scan, determine how this policy is going to be applied.  Will you also be blocking executables running from %LocalAppData%?  Will you block all executable types?

If (and only if) you are blocking all executable types on the policy, you need to scan for all executable types from this screen.  By default, the scan will only look for and report found executables which reside in %AppData% and %LocalAppData%.  To change this behavior, click the blue Scan Targets link.  This will bring up a new window:

None of the checks will be selected on load.  You may check each desired filetype or just press the 'Check/Uncheck All' option on the bottom-right.  The above image is Third Wall's recommendation.  When done, press the 'Apply' button.

Now you're ready to scan the environment.  Remember, there is no %AppData% or %LocalAppData% folder when the remote computer doesn't have a user currently signed in so you'll want to do this scan during peak usage.  Click the 'Scan Now' button and acknowledge the confirmation.  This will instruct all remote workstations in the Client to scan and report any files that may be blocked by this policy which reside on the local system.  After a few minutes (no more than ten), the list should be fully populated.

At this point, no exceptions have been made; we've only just populated our 'Scan Results' list.  Now it is time to apply those findings to the 'Current Exceptions' list.  Use the checkboxes on the left of the screen to select which files will be excepted.  Alternatively, you can opt to except all findings by checking the 'Check\Uncheck All' button.  Another option is to use the 'Search' field and button.

If you are only blocking the %AppData% folder, you only need to except files in that path.  Enter '%AppData%' in the search field and press the 'Search' button.  Any Scan Result that has '%AppData%' in the string will be selected.  Likewise, if you only want to approve products from a certain vendor (e.g. Microsoft) then that term may be searched for and checked as well.  Multiple searches are supported, just do them one at a time.

When the selection is complete, press the 'Save' button.  Your screen will now display the 'Scan Results' list and any files selected in the previous step will be shown here.

Next, we need to communicate these exceptions to the target computers.  Run 'Update Config' (Commands -> Inventory -> Update Config) on the Client.  This will cause all remotes to load the new Current Exceptions list and apply them.  You are now ready to enable the policy.

If the policy is already applied, there is one more step you'll need to do to allow a remote computer to run the excepted file which is currently being blocked.  Microsoft requires the remote computer be restarted when the Exception List is changed and the policy is already applied.  We've found a logging out and back in works as well.  If that's not possible, a restart of the 'Windows Explorer' will also reload the current exception list.

You may find one or two users still have blocks applied.  This is most likely due to their not being signed-on to their computer when the scan was run.  You can rerun the scan at any time.  Running a new scan does not impact the Current Exception list, it only clears and rebuilds the 'Scan Result'.  All lists are de-duplicated so if you save results from the new scan which are already excepted, they will not be excepted twice.

No matter your configuration, Third Wall strongly recommends enabling the 'Alert on File Block' feature on the policy.  This will alert you anytime a file is blocked from running on the remote with a ticket and will provide the full path to the blocked file.

Upon receiving this ticket, first determine if this application should run.  If it should, you can copy and paste the filepath directly into the 'Current Exception' list using the 'Add Manual Exception' button.  This will except the current file from the policy for this one user.  If you prefer to make the exception apply for any user, replace the explicit path with a wildcard path.  In the example above, you would except:

%AppData%\Google\Chrome\User Data\SwReporter\80.231.200\software_reporter_tool.exe.

As with the initial setup, you will again need to run 'Update Config' after making the change.  Once the command is run on the remote, have them log out and back in.  They will now be able to run the software_reporter_tool.exe.