Solved
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?
Best answer by coscooper
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.
https://download.webroot.com/WSAB_GSM_BestPracticesGuide.pdf
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.
+63Hello @ZiggyStardust32 and Welcome to the Webroot Community!
I will ping a couple of people to see if they can help you@JGiffard @NicCrockett but you can always contact Business Support on the weekends: https://www.webroot.com/us/en/business/support/contact
Business Technical Support
Submit a Support Ticket
Call 1-866-254-8400
Thanks,
I will ping a couple of people to see if they can help you
Business Technical Support
Submit a Support Ticket
Call 1-866-254-8400
Thanks,
Daniel - Microsoft MVP Consumer Security (2012-2016) Windows 10 Pro x64 for Workstations 22H2 on my Alienware 17R2 and Alienware 17R5 Laptops with Webroot SecureAnywhere Complete Beta Tester for PC & Android Moto G9 Plus OS 11. "Take Them to the Train Station" ¯\_(ツ)_/¯
+261) 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.
HTH
Shane Cooper | Manager, Channels Sales (RMM & Strategic Partners)
Well...... according to support the local Allow/Block cannot be manipulated by the GSM console. The only thing that can be done to it by the console is allowing the end-users to manipulate it by moving the endpoint to and unmanaged group in the console and......
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......
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......
+28In 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:
- Older Windows OS: C:\Documents and Settings\All Users\Application Data\WRData\
- Newer Windows OS: C:\ProgramData\WRData\
Hope all that wasn't too confusing and was helpful. Let me know if you have questions and I'll respond when I can.
Good Luck!
NicCrockett | NicCrockett.me
+26creating 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.
Shane Cooper | Manager, Channels Sales (RMM & Strategic Partners)
1 person likes this
Creating the whitlists isn't the issue and really MD5 hashes aren't either. Webroot gives you no real way to know if whitelists are in affect. They have this really nice Block/Allow on the local client but don't use it (or don't allow you to manipulate it via the console). Seems like a waste to me.
+28It's not really a waste, but I understand why you might see it that way. It's set-up that way because they use one product that can be managed via the console or locally. It has to do with the users needs and how they have it set-up. Did you look to see if your Ovr.db file was in date? As you can see, mine is 19 days out-of-date. If this file isn't updating properly, you can add all the overrides in the world and it won't make any difference. They really need to fix this issue!
NicCrockett | NicCrockett.me
1 person likes this
That is kind of the problem. It can't be managed via the console (other then to tell it the enduser can manage it). They do not fix things fast if at all. Duplicating endpoints due to Windows 10 Features updates has been since the first feature update and they haven't fixed that yet either. Along with the issue of not putting itself in the Add/Remove programs. Getting a little burned out on their lack of ability to fix issues.....
1 person likes this
+28Believe me, I completely understand your frustration! However, for now we have to work within the parameters they've set and the issues they haven't fixed. I wouldn't normally suggest this and I haven't tried it, but have you tried setting up a policy that allows the endpoint to completely manage itself. This might allow you to have access to these settings directly on the endpoint. However, it might also remove any overrides or other settings you currently have in place for that endpoint. If you try this, do so with great care and understanding of what you are doing!
+26So, 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.
https://download.webroot.com/WSAB_GSM_BestPracticesGuide.pdf
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.
Shane Cooper | Manager, Channels Sales (RMM & Strategic Partners)
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.
@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.
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.