Best answer by JimMView original
endpoints not seen
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 ?
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.
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.
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.
I have found that some endpoints....
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:
Since when is this a URL that WR requires?
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.
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.
The consumer version of the new build went out today, and the business version should be out in a day or two.
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.
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'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.
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:
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 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. 🙂
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.