Best answer by coscooperView original
Whitelisting Files and Folders
I went in to the GSM console 3 days ago and whitelisted several a couple for a site yet when I look at Webroot on one of those endpoints nothing shows up under Block/Allow files. It is all done via the GSM because when I try and and "allow" files on the endpoint it says I can't and that they must be added via the console. So.... what am I doing wrong?
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
I will ping a couple of people to see if they can help you
Business Technical Support
Submit a Support Ticket
So, to answer your question about are overrides are aren't overrides in effect, it's quit easy.
1) the block/allow will actually show if the override is in effect as if the application in question has an override applied in the console, that list, when the application in question is running, will display in the allow. Again, it's an "ACTIVE" processes list, not an at rest override list.
2) If you create an override and the "cloud" determination is "unknown" - then it's in effect. No magic and the agent will not interfere with the software.
3) If the determination is set to "good", then delete the override as its irrelevant.
To help even further, there is a "undetermined software" report that is available at the site level. In our best practice guide, we do not suggest you go through and proactively make an override for everything, rather look at the converse. Review the undetermined report and see what the agent isn't aware or is unknown and create an override accordingly.
In that report, if you notice the "last seen" date, it's a reference to when the agent last determined it was an unknown. After an override is created, that date will stop updating.
There is no issue with Windows 10 updates, unless you use the -clone switch which is applied through CW Automate. Which, we recommend turning off "use unique identifier" in the settings. That setup will be deprecated in the next plugin.
Otherwise, normal updates without an additional MID switches will update fine and not duplicate.
As far as the overrides discussion, there is nothing broken and there is usually no need to display to the end user what is set/configured to override if it's fully managed by an MSP. It's not been nor is an issue with many other MSPs given most do not build a lot of overrides once they know whether the LOB is in the undetermined report or not.
Just so you're aware, duplications is due to many factors that are all based upon how the agent creates MID (Machine ID) and to modify that is not an easy feat with 40M endpoints deployed today, so it's a challenging issue, not a will we or wont we issue. Dev has been working on several modified methods of creating that uniqueness and retaining reference to the old method during transition. Again, no easy task and may change under the hood sometime in the future.
1) Block/Allow in the endpoint GUI is for active processes only. If a process you created an override for is in that list and running, it should be checked under the "allow" column. Otherwise, nothing will display until it's actually running in memory.
2) Did you create path overrides or MD5?
> If Path overrides, again, timing will depend on the poll cycle of your policy as this is setting appends a local file for the agent to reference anytime.
> If MD5, this override is instantly available to the agent as it references the cloud data, not local.
In the Endpoint Protection Console you need to go to Overrides -> File & Folder Overrides -> Whitelist -> Create to create an override for a specific file or folder.
When you click the Create button, you'll get the following screen:
Unless you know the MD5 Hash, you'll probably want to change this to Path/File. There's an easy way to create these with the MD5. If you want more info on that method let me know. When you change it to Path/File, the screen changes to this:
Fill in the relevant fields and you'll have an override. Here's examples of both an MD5 and a Path/File in my list. The MD5 is the one called FujiFilm XMF Workflow Installer in the first image above, The Path/File ones are called Unitrends Agent Installer and Unitrends Agent Directory. I included two Path/File ones because one shows how to use generic paths to places like the Windows directory and a specific file, while the other shows a specific path using a file mask to override all files in that folder/subfolders.
That tells you basically how to create an override in the Endpoint Protection Console and for the most part the GSM is the same. As you can see, even in the Endpoint Protection Console you can assign an override to the GSM. However, creating these doesn't guarantee that it takes effect on the endpoint. I've come across a flaw in the software where the override database stored on the endpoint doesn't get updated properly. This means you need to make sure the Ovr.db file on your endpoints is getting updated. This file is located in the following locations:
Hope all that wasn't too confusing and was helpful. Let me know if you have questions and I'll respond when I can.
creating overrides is well documented above and you can often capture the MD5 locally though the logs and create it at the console.
For it the more aggressive local I’d shield, local overrides with unmanaged policy is the correct method. There are discussions about allowing local management via admin credentials, but that’s a roadmap item and may be available later this year.
@Anpoo Yes, you can enter files and folders in the Whitelist Scripts tab. However, Webroot ignores the entries. I added a folder where I keep my AutoHotKey keyboard scripts. Even though I entered the root folder containing the scripts, every time I edit and recompile a script, Webroot pops up it’s threat warning dialog and tells me I’m infected. I not only listed the root folder, I listed every one of my script executables but Webroot still ignores this whitelist.
To anyone looking at this now, if you go to PC Security > whitelisted scripts > advanced whitelist, you can put in the path of a folder.
the only way to see the whitelist entries created in the GSM on the endpoint is by looking in the log on the endpoint for entries marked "Determination Flags Modified". That mean the only time you will see it in the log is essentially when it tries to scan something in the whitelist and before it scans it is is determined that the "Determination Flags Modified".
Seems kind of a waste to that that local Block/Allow tab and not be able to manipulate it via the GSM......