I am having issues with endpoints not being seen in some of our remote location. I have talked to tech support and they told me to go allow it in our filter which is webroot security service. I have done that but with no luck has anyone else had this problem ?
Page 1 / 1
Hello mike8497 and welcome to the community!!
If you would be able to PM me the email address used to access the portal I would be happy to look into the situation further.
Thanks!
If you would be able to PM me the email address used to access the portal I would be happy to look into the situation further.
Thanks!
Just wondering if anyone has had this problem and it was fixed.
We haven't seen anybody else come forward with such an issue on the forums, for example, but perhaps somebody who has had it (if anybody has had it) will come forward. It's either not something we've seen at all, or is a very rare situation with one-off causes, otherwise we'd generally have an answer for you right here on the forum itself.
In the meantime, TechToc's offer is specifically to get the situation fixed for you. We take SecureAnywhere very seriously, to the point where we actually code fixes or workarounds for individual cases in situations that warrant. It might be a case where a configuration completely unique to an individual computer out of millions is causing a problem, however we'll still both find a temporary workaround and code a permanent fix for it.
If you have no gotten in touch with TechToc or somebody in Enterprise Support already, then I highly recommend you do so and we'll take a look and get things working properly. If it looks like it's not a one-of situation that others could benefit from the information on, we or you can post that here as well. Otherwise, if you prefer to simply see if anybody else has had the problem, you may wait and see if anybody comes forward. 🙂
In the meantime, TechToc's offer is specifically to get the situation fixed for you. We take SecureAnywhere very seriously, to the point where we actually code fixes or workarounds for individual cases in situations that warrant. It might be a case where a configuration completely unique to an individual computer out of millions is causing a problem, however we'll still both find a temporary workaround and code a permanent fix for it.
If you have no gotten in touch with TechToc or somebody in Enterprise Support already, then I highly recommend you do so and we'll take a look and get things working properly. If it looks like it's not a one-of situation that others could benefit from the information on, we or you can post that here as well. Otherwise, if you prefer to simply see if anybody else has had the problem, you may wait and see if anybody comes forward. 🙂
I'm looking through our Enterprise cases, and I came across yours. It would appear that this case was resolved by adding *webrootcloudav.com as a browser bypass to a proxy system that was running on these computers.
Hello Mike,
In cases where the client is not communicating with our servers, the endpoint will not show up in the console. This is always caused by something blocking the communication like a proxy server, firewall, ISA server, etc.
Have the endpoints ever shown up in the console?
Does the Secure Anywhere software display that it is expired on the endpoint?
In proxy environments you may want to try manually adding your proxy configuration in the Secure Anywhere under Settings > Proxy. With our Webroot Webfiltering service you will want to enter the host and port only. It will authenticate automatically.
If that resolves the issue you will want to install the Secure Anywhere software using proxy arguments, such as:
XXXX-XXXX-XXXX-XXXX-XXXX.exe -proxyhost="Ip Address" -proxyauth=1 -proxyuser=proxy -proxypass= -proxyport="Proxy Port"
Note: Executable will need to be renamed as your key code for auto install. "IP Address" and "Proxy Port" will need to be entered without quotes.
Further deployment information can be found in the Webroot Secure Anywhere Endpoint Protection Guide:
https://my.webrootanywhere.com/smehelp.asp
If that does not resolve the issue let me know the answers to the above questions and that will tell us a little more about the behavior.
Webroot Enterprise Support
In cases where the client is not communicating with our servers, the endpoint will not show up in the console. This is always caused by something blocking the communication like a proxy server, firewall, ISA server, etc.
Have the endpoints ever shown up in the console?
Does the Secure Anywhere software display that it is expired on the endpoint?
In proxy environments you may want to try manually adding your proxy configuration in the Secure Anywhere under Settings > Proxy. With our Webroot Webfiltering service you will want to enter the host and port only. It will authenticate automatically.
If that resolves the issue you will want to install the Secure Anywhere software using proxy arguments, such as:
XXXX-XXXX-XXXX-XXXX-XXXX.exe -proxyhost="Ip Address" -proxyauth=1 -proxyuser=proxy -proxypass= -proxyport="Proxy Port"
Note: Executable will need to be renamed as your key code for auto install. "IP Address" and "Proxy Port" will need to be entered without quotes.
Further deployment information can be found in the Webroot Secure Anywhere Endpoint Protection Guide:
https://my.webrootanywhere.com/smehelp.asp
If that does not resolve the issue let me know the answers to the above questions and that will tell us a little more about the behavior.
Webroot Enterprise Support
Hey,
We've actually seen this at work. I have one endpoint that hasn't run a scan since August 20th. We used to see this fairly often with the previous version of "Webroot AntiSpyware with AntiVirus". Some endpoints would stop getting updates, some would stop communicating altogether. The quick and dirty brute-force work-around was to force an uninstall/re-install which would clear whatever was causing the endpoint to get stuck.
With SecureAnywhere, I'm starting to see a problem that looks similar at first glance. I connected to one of our endpoints having this problem. The tray icon was not running, which leads me to believe that webroot must have seg-faulted or something. I rebooted the PC, logged in as an admin, ran webroot manually, performed a manual scan, then selected "Check for updates". This seems to have worked. I'm hopeful this will resolve the issue for a while on that endpoint.
Cheers.
We've actually seen this at work. I have one endpoint that hasn't run a scan since August 20th. We used to see this fairly often with the previous version of "Webroot AntiSpyware with AntiVirus". Some endpoints would stop getting updates, some would stop communicating altogether. The quick and dirty brute-force work-around was to force an uninstall/re-install which would clear whatever was causing the endpoint to get stuck.
With SecureAnywhere, I'm starting to see a problem that looks similar at first glance. I connected to one of our endpoints having this problem. The tray icon was not running, which leads me to believe that webroot must have seg-faulted or something. I rebooted the PC, logged in as an admin, ran webroot manually, performed a manual scan, then selected "Check for updates". This seems to have worked. I'm hopeful this will resolve the issue for a while on that endpoint.
Cheers.
Just to add my 2cents to this article....
We often have issues with "endpoints not seen" even though they are running just fine.
Unfortunaly we use Webroot as AV on servers and some of these are not easy to take out of production just for the sake of some buggy AV.
We have logged support cases with Webroot tech support but they don't give useful responses.
Be good if Webroot could sort this out.
We often have issues with "endpoints not seen" even though they are running just fine.
Unfortunaly we use Webroot as AV on servers and some of these are not easy to take out of production just for the sake of some buggy AV.
We have logged support cases with Webroot tech support but they don't give useful responses.
Be good if Webroot could sort this out.
This one is under active investigation. Let me see what the latest info is.
So we have a couple of bug fixes - one that is already out, and one that is coming out in the next build, that should be fixing these. After the next build comes out, let me know if the issue persists and we'll get your case to support so that we can delve into it.
Thanks Nic,
I have spent time with tech support on this issue. The main problem is that there does not seem to be any method to debug this easily.
It would be nice if there was a "check in" button command that you could run on a client that would force it to connect to its cloud server, and there was some logging. This would force the client to download any new policies, or run any commands that had been sent to the client (such as uninstall, change keycode etc)
At the moment tech support runs a scan, with and a wireshark at the same time, and you have to troll through the logs looking for something.
Tip for anyone else trying to fix these sort of issues, one trick I have found to find the webroot server a client is trying to connect to is to go to command prompt, run:
ipconfig /display dns | findstr webroot
That command will show the dns entries for webroot servers.
I have spent time with tech support on this issue. The main problem is that there does not seem to be any method to debug this easily.
It would be nice if there was a "check in" button command that you could run on a client that would force it to connect to its cloud server, and there was some logging. This would force the client to download any new policies, or run any commands that had been sent to the client (such as uninstall, change keycode etc)
At the moment tech support runs a scan, with and a wireshark at the same time, and you have to troll through the logs looking for something.
Tip for anyone else trying to fix these sort of issues, one trick I have found to find the webroot server a client is trying to connect to is to go to command prompt, run:
ipconfig /display dns | findstr webroot
That command will show the dns entries for webroot servers.
Yeah, would be nice to have an easier way to debug. If the next patch doesn't fix it then I'll suggest that to them.
The consumer version of the new build went out today, and the business version should be out in a day or two.
The consumer version of the new build went out today, and the business version should be out in a day or two.
Hi,
i can confirm that the issue is still present and actually not resolved. On my instll basis (around 700 endpoints now) i've found at least 12 endpoints affected by this issue. Even trying to remove and reinstall the agent did not solve the problem.
WHat happen is this: you install the agent, the av does a first scan and send the result up to the cloud but after that it simply stop contacting the cloud.
I'm getting mad this enpoints are totally uncoverd from protection as far as i can understand.
Regards
giorgio
i can confirm that the issue is still present and actually not resolved. On my instll basis (around 700 endpoints now) i've found at least 12 endpoints affected by this issue. Even trying to remove and reinstall the agent did not solve the problem.
WHat happen is this: you install the agent, the av does a first scan and send the result up to the cloud but after that it simply stop contacting the cloud.
I'm getting mad this enpoints are totally uncoverd from protection as far as i can understand.
Regards
giorgio
Sorry about that - have you worked with support on it yet? I can have them contact you again to troubleshoot further.
Hi,
first of all i contacted the support but the problem is still present. Some random endpoints do not contact and cannot upgrade their release and transit daily scan result.
The workaround after reinstalling the whole shebang on all the endpoints without noticeable result wasto put in place Computer GPO that force a check in at the user login an create a scheduled task for a periodic update.
I do think it's definetely a bug, i sent up several logs but still no results.
Regards
first of all i contacted the support but the problem is still present. Some random endpoints do not contact and cannot upgrade their release and transit daily scan result.
The workaround after reinstalling the whole shebang on all the endpoints without noticeable result wasto put in place Computer GPO that force a check in at the user login an create a scheduled task for a periodic update.
I do think it's definetely a bug, i sent up several logs but still no results.
Regards
I can escalate your case internally and get someone to take another look at things if you like.
Interesting. I was troublshooting the exact same issue last night, and unfortunatly will have to continue today.
I have found that some endpoints....
don't contact
do contact but don't seem to update to new versions
I contacted support and they suggested I need to stop webroot rename the "WRdata" folder and restart it. I can't even find a WRdata, so they were not much use
I was doing some packet sniffing on affected endpoint and I found that webroot was asking for this URL:
http://wrskynet.s3.amazonaws.com/skysettings/skysettingsWAI.txt?AWSAccesKeyId=.........
Since when is this a URL that WR requires?
I have found that some endpoints....
don't contact
do contact but don't seem to update to new versions
I contacted support and they suggested I need to stop webroot rename the "WRdata" folder and restart it. I can't even find a WRdata, so they were not much use
I was doing some packet sniffing on affected endpoint and I found that webroot was asking for this URL:
http://wrskynet.s3.amazonaws.com/skysettings/skysettingsWAI.txt?AWSAccesKeyId=.........
Since when is this a URL that WR requires?
I've alerted one of the folks here to take a look at this thread and look up your cases.
I'ved logged a support case if you want to follow it up:
12537
Thanks
12537
Thanks
Thanks - I sent that info over to the support team manager to look into.
Thanks Nic,
I've had fast and prompt response from the Support but unfortunately the problem is there and as you can ubderstand it's worrying me a lot. I also do understand that is a real tricky stuff bit even adopting the workaround i described above I do think it should be necessary to investigate further.
As reported on the original ticket and the opened discussion that followed the endpoints that do not communicate are on the same subnet of other endpoints that are correctly working with dame navigation rulesband network.
One thing i noticed (don't know of this helps) all the endpoints are used by power users (not macchine admin), it could be only a coincidence because we do have also other endpoint with no admin Users that seems to work.
One other thing to underline that is another malfunction, all the endpoints that loose connection and are forced by the script i put in place , to pull to the cloud and sync do not send up the scan result or warning of deletion.
Regards
I've had fast and prompt response from the Support but unfortunately the problem is there and as you can ubderstand it's worrying me a lot. I also do understand that is a real tricky stuff bit even adopting the workaround i described above I do think it should be necessary to investigate further.
As reported on the original ticket and the opened discussion that followed the endpoints that do not communicate are on the same subnet of other endpoints that are correctly working with dame navigation rulesband network.
One thing i noticed (don't know of this helps) all the endpoints are used by power users (not macchine admin), it could be only a coincidence because we do have also other endpoint with no admin Users that seems to work.
One other thing to underline that is another malfunction, all the endpoints that loose connection and are forced by the script i put in place , to pull to the cloud and sync do not send up the scan result or warning of deletion.
Regards
Thanks for the additional info. I'll pass that along and let you know when I hear back.
We're having the same issue with clients that cannot connect to the server. Please let us know if you resolved this issue. THanks.
What we did by now is to put a scheduled action (made through GPO) that runs as system user each hour.
The action recall wsrsa.exe -poll.
But the issue remains and there is another worst thing that techincal dept is looking into, all these affected endpoints now with this workaround do connect the cloud but do not send up the scan result (scheduled at 1.p.m. daily).
This is a most general issue that affects almost all endpoints that do not send up the scan result daily a expected.
Regards
The action recall wsrsa.exe -poll.
But the issue remains and there is another worst thing that techincal dept is looking into, all these affected endpoints now with this workaround do connect the cloud but do not send up the scan result (scheduled at 1.p.m. daily).
This is a most general issue that affects almost all endpoints that do not send up the scan result daily a expected.
Regards
There isn't one single root cause on this one, so best bet is to contact support and have them investigate.
We have this bug also, some of our endpoints have incorrectly reported status, not seen for a long period of time, even their scan logs stops, found out further that it seems using an unmanaged endpoint policy even though in the webroot web console it's using a default managed policy, that means the end user can easily change its settings. I've tried re-applying different endpoint policies, clear logs, reset to original settings but nothing works. But I found a certain solution that works, by importing a configuration settings from our other working endpoints.
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.