Hey gang,
Is there a new client for Webroot Endpoint Protection? 8.0.3.3?
Is there someone I can go to see information on the new updates?
Why did some of my clients get updated automatically and some did not?
Rich
Solved
new client?
Best answer by Jack
Hi PLPsupport
What@ is suggesting is to over write your installation with the 2014 version on the consumer update path.
We have many update paths for WSA, for example the normal consumer installer 'wsainstall.exe' is on a different update path to the business product 'wsasme.exe'. The actual functionality of your installation is determined by your product keycode.
The business product will receive the update to the 2014 version very very soon.
explanoits suggestion may indeed help, as many of our recent improvement or bug fixes are contained within the 2014 release.
That being said however, 8.0.3.3 is entirely stable.
You mention a WOL, I presume this is a 'wake on LAN' event? Does this log a user in? I'm not sure that an update would require that but it would be a good point to tick off the list.
Are the endpoints that have failed to update on the same network as some that have updated successfully?
And have you confirmed that they all have auto updates turn on in their policy? Wouldn't hurt to switch one of them from one policy to another to ensure it knows its on a policy with updates.
There is also another possibility. Would you mind sending me a few of the hostnames that are failing to update? We recognise an individual endpoint based on a number of identifiers including the SID from the Windows install. If you have endpoints that share some of these values, for example machines based off a cloned image, it is very possible they are competing for a position on our backend. Normally the expected symptom would be endpoints not showing within your online console or one day endpoint A shows and the next day endpoint B shows. However I have heard of this affecting updates, although all endpoints show in the console when endpoint A checks for updates, it looks so much like endpoint B to our backend, we tell it there is no further updates.
The resolution for this is to install with a -clone switch, instructions for this are as follows -
Please uninstall Webroot SecureAnywhere Business – Endpoint Protection from the affected endpoint(s). Afterward, you can reinstall it with the command line option "-clone ", which will cause SecureAnywhere to create a unique identification for that system.
Example (x’s represent your license key):
wsasme.exe /key=xxxx-xxxx-xxxx-xxxx-xxxx /silent -clone
After installation, a new hostname appears in the Account Management website; e.g., hostname PCHOSTNAME might become PCHOSTNAME-C8137921. This value will persist if the agent is uninstalled or reinstalled so that existing agents won’t move to other IDs. However, if the OS is reinstalled, the ID will change.
If we have ruled out firewall or proxy based communication issues, and that the correct policy settings are in place, I suggest redeploying to a small sample of the affected endpoints using the -clone instructions above. If you perform this soon using the standard sme installer you will initially receive 8.0.3.3 but we will know if we were successful when the 8.0.4.x update comes to the business customer base.
Please let me know if you have any further questions
Jack
View originalWhat
We have many update paths for WSA, for example the normal consumer installer 'wsainstall.exe' is on a different update path to the business product 'wsasme.exe'. The actual functionality of your installation is determined by your product keycode.
The business product will receive the update to the 2014 version very very soon.
explanoits suggestion may indeed help, as many of our recent improvement or bug fixes are contained within the 2014 release.
That being said however, 8.0.3.3 is entirely stable.
You mention a WOL, I presume this is a 'wake on LAN' event? Does this log a user in? I'm not sure that an update would require that but it would be a good point to tick off the list.
Are the endpoints that have failed to update on the same network as some that have updated successfully?
And have you confirmed that they all have auto updates turn on in their policy? Wouldn't hurt to switch one of them from one policy to another to ensure it knows its on a policy with updates.
There is also another possibility. Would you mind sending me a few of the hostnames that are failing to update? We recognise an individual endpoint based on a number of identifiers including the SID from the Windows install. If you have endpoints that share some of these values, for example machines based off a cloned image, it is very possible they are competing for a position on our backend. Normally the expected symptom would be endpoints not showing within your online console or one day endpoint A shows and the next day endpoint B shows. However I have heard of this affecting updates, although all endpoints show in the console when endpoint A checks for updates, it looks so much like endpoint B to our backend, we tell it there is no further updates.
The resolution for this is to install with a -clone switch, instructions for this are as follows -
Please uninstall Webroot SecureAnywhere Business – Endpoint Protection from the affected endpoint(s). Afterward, you can reinstall it with the command line option "-clone ", which will cause SecureAnywhere to create a unique identification for that system.
Example (x’s represent your license key):
wsasme.exe /key=xxxx-xxxx-xxxx-xxxx-xxxx /silent -clone
After installation, a new hostname appears in the Account Management website; e.g., hostname PCHOSTNAME might become PCHOSTNAME-C8137921. This value will persist if the agent is uninstalled or reinstalled so that existing agents won’t move to other IDs. However, if the OS is reinstalled, the ID will change.
If we have ruled out firewall or proxy based communication issues, and that the correct policy settings are in place, I suggest redeploying to a small sample of the affected endpoints using the -clone instructions above. If you perform this soon using the standard sme installer you will initially receive 8.0.3.3 but we will know if we were successful when the 8.0.4.x update comes to the business customer base.
Please let me know if you have any further questions
Jack
8.0.3.3 is indeed the latest version.
Release notes can be found here: https://community.webroot.com/t5/Release-Notes/bd-p/ReleaseNotesWSA
In regards to why some updated and others didn't. I've seen that happen in the past, but over time they all updated. Not sure why they all don't update at the same time.
Release notes can be found here: https://community.webroot.com/t5/Release-Notes/bd-p/ReleaseNotesWSA
In regards to why some updated and others didn't. I've seen that happen in the past, but over time they all updated. Not sure why they all don't update at the same time.
Hi Guys, im currently facing the same issue. Majority of endpoints have automatically updated to 8.0.3.3 however i have a few endpoints as such
- 7 on 8.0.2.147
- 7 on 8.0.2.155
- 23 on 8.0.2.167
- 19 on 8.0.2.174
Why are they not updating to the same version equally? what could be causing this?
2ndly
we currently have a edited msi that is deployed via GPO. That msi file is of an older version and would like to know if it was possible to replace the msi file with a newer version (8.0.3.3). Would that work?
If anyone else has already done this please share your experiences.
- 7 on 8.0.2.147
- 7 on 8.0.2.155
- 23 on 8.0.2.167
- 19 on 8.0.2.174
Why are they not updating to the same version equally? what could be causing this?
2ndly
we currently have a edited msi that is deployed via GPO. That msi file is of an older version and would like to know if it was possible to replace the msi file with a newer version (8.0.3.3). Would that work?
If anyone else has already done this please share your experiences.
Hi PLPsupport
Updates usually take about 72 hours to roll out globally.
8.0.3.3 has been out for over a week now so all your endpoints should have updated.
First thing to check is that the policy applied to each endpoint allows updates.
The most likely issue here is the agents ability to communicate with the cloud and receive updates.
Are you behind a proxy or firewall?
If so please ensure you have followed the steps https:///t5/Webroot-Education/Recommended-Proxy-Firewall-Bypass-List/ta-p/55156#.UlPe1hB7kQo
Can you let me know the host names of a few of the endpoints on 2.147 or 2.155 please? (PM me these if you like)
As for updating the .msi, we recommend you update the .msi on a regular basis to ensure any new deployments are receiving the most up to date version on install. I havent tested it myself but you could force the .msi to reinstall when updated by using advanced parametrs within the .msi such as /fo (reinstalls a file if it is missing or if an older version of the file is present on the user's system)
However this would not necessarily fix the issue you are experiencing as these endpoints really should have updated by now, so a communications issue or settings issue is more likely.
Jack
Updates usually take about 72 hours to roll out globally.
8.0.3.3 has been out for over a week now so all your endpoints should have updated.
First thing to check is that the policy applied to each endpoint allows updates.
The most likely issue here is the agents ability to communicate with the cloud and receive updates.
Are you behind a proxy or firewall?
If so please ensure you have followed the steps https:///t5/Webroot-Education/Recommended-Proxy-Firewall-Bypass-List/ta-p/55156#.UlPe1hB7kQo
Can you let me know the host names of a few of the endpoints on 2.147 or 2.155 please? (PM me these if you like)
As for updating the .msi, we recommend you update the .msi on a regular basis to ensure any new deployments are receiving the most up to date version on install. I havent tested it myself but you could force the .msi to reinstall when updated by using advanced parametrs within the .msi such as /fo (reinstalls a file if it is missing or if an older version of the file is present on the user's system)
However this would not necessarily fix the issue you are experiencing as these endpoints really should have updated by now, so a communications issue or settings issue is more likely.
Jack
1 person likes this
The end points that typically don't update immediately are the same each new version they tend to be the C level guy's laptops that they forget we gave them and have been powered off for a month at their house...
hey Jack
Apologies for the late response. We have a naming convention for our PC's Laptops depending on Geographical location.
AU for australia office PC's
FJ for Fiji Office PC's
Endpoints on 2.147 are AU PC's. Its weird cause these endpoints are the only ones on our AU site that does not update. We have about 100 other endpoints that have successfully updated to 8.0.3.3.
We run a nightly WOL for scheduled sweeps and is set to 2hours even though the sweeps take less than 10minutes to complete.
Apologies for the late response. We have a naming convention for our PC's Laptops depending on Geographical location.
AU for australia office PC's
FJ for Fiji Office PC's
Endpoints on 2.147 are AU PC's. Its weird cause these endpoints are the only ones on our AU site that does not update. We have about 100 other endpoints that have successfully updated to 8.0.3.3.
We run a nightly WOL for scheduled sweeps and is set to 2hours even though the sweeps take less than 10minutes to complete.
+6This fixed our updating issues on many endpoints. But it's not supported yet.
https://community.webroot.com/t5/Webroot-Discussions/Living-dangerously-Be-a-WSA-2014-guinea-pig/m-p/60879/highlight/true#M315
So i tested your link out and downloaded and installed the wsa.exe which updated the client to V8.0.4.24. However now im not to sure what you mean when you say its not supported....
care to elaborate?
Hi PLPsupport
What@ is suggesting is to over write your installation with the 2014 version on the consumer update path.
We have many update paths for WSA, for example the normal consumer installer 'wsainstall.exe' is on a different update path to the business product 'wsasme.exe'. The actual functionality of your installation is determined by your product keycode.
The business product will receive the update to the 2014 version very very soon.
explanoits suggestion may indeed help, as many of our recent improvement or bug fixes are contained within the 2014 release.
That being said however, 8.0.3.3 is entirely stable.
You mention a WOL, I presume this is a 'wake on LAN' event? Does this log a user in? I'm not sure that an update would require that but it would be a good point to tick off the list.
Are the endpoints that have failed to update on the same network as some that have updated successfully?
And have you confirmed that they all have auto updates turn on in their policy? Wouldn't hurt to switch one of them from one policy to another to ensure it knows its on a policy with updates.
There is also another possibility. Would you mind sending me a few of the hostnames that are failing to update? We recognise an individual endpoint based on a number of identifiers including the SID from the Windows install. If you have endpoints that share some of these values, for example machines based off a cloned image, it is very possible they are competing for a position on our backend. Normally the expected symptom would be endpoints not showing within your online console or one day endpoint A shows and the next day endpoint B shows. However I have heard of this affecting updates, although all endpoints show in the console when endpoint A checks for updates, it looks so much like endpoint B to our backend, we tell it there is no further updates.
The resolution for this is to install with a -clone switch, instructions for this are as follows -
Please uninstall Webroot SecureAnywhere Business – Endpoint Protection from the affected endpoint(s). Afterward, you can reinstall it with the command line option "-clone ", which will cause SecureAnywhere to create a unique identification for that system.
Example (x’s represent your license key):
wsasme.exe /key=xxxx-xxxx-xxxx-xxxx-xxxx /silent -clone
After installation, a new hostname appears in the Account Management website; e.g., hostname PCHOSTNAME might become PCHOSTNAME-C8137921. This value will persist if the agent is uninstalled or reinstalled so that existing agents won’t move to other IDs. However, if the OS is reinstalled, the ID will change.
If we have ruled out firewall or proxy based communication issues, and that the correct policy settings are in place, I suggest redeploying to a small sample of the affected endpoints using the -clone instructions above. If you perform this soon using the standard sme installer you will initially receive 8.0.3.3 but we will know if we were successful when the 8.0.4.x update comes to the business customer base.
Please let me know if you have any further questions
Jack
What
We have many update paths for WSA, for example the normal consumer installer 'wsainstall.exe' is on a different update path to the business product 'wsasme.exe'. The actual functionality of your installation is determined by your product keycode.
The business product will receive the update to the 2014 version very very soon.
explanoits suggestion may indeed help, as many of our recent improvement or bug fixes are contained within the 2014 release.
That being said however, 8.0.3.3 is entirely stable.
You mention a WOL, I presume this is a 'wake on LAN' event? Does this log a user in? I'm not sure that an update would require that but it would be a good point to tick off the list.
Are the endpoints that have failed to update on the same network as some that have updated successfully?
And have you confirmed that they all have auto updates turn on in their policy? Wouldn't hurt to switch one of them from one policy to another to ensure it knows its on a policy with updates.
There is also another possibility. Would you mind sending me a few of the hostnames that are failing to update? We recognise an individual endpoint based on a number of identifiers including the SID from the Windows install. If you have endpoints that share some of these values, for example machines based off a cloned image, it is very possible they are competing for a position on our backend. Normally the expected symptom would be endpoints not showing within your online console or one day endpoint A shows and the next day endpoint B shows. However I have heard of this affecting updates, although all endpoints show in the console when endpoint A checks for updates, it looks so much like endpoint B to our backend, we tell it there is no further updates.
The resolution for this is to install with a -clone switch, instructions for this are as follows -
Please uninstall Webroot SecureAnywhere Business – Endpoint Protection from the affected endpoint(s). Afterward, you can reinstall it with the command line option "-clone ", which will cause SecureAnywhere to create a unique identification for that system.
Example (x’s represent your license key):
wsasme.exe /key=xxxx-xxxx-xxxx-xxxx-xxxx /silent -clone
After installation, a new hostname appears in the Account Management website; e.g., hostname PCHOSTNAME might become PCHOSTNAME-C8137921. This value will persist if the agent is uninstalled or reinstalled so that existing agents won’t move to other IDs. However, if the OS is reinstalled, the ID will change.
If we have ruled out firewall or proxy based communication issues, and that the correct policy settings are in place, I suggest redeploying to a small sample of the affected endpoints using the -clone instructions above. If you perform this soon using the standard sme installer you will initially receive 8.0.3.3 but we will know if we were successful when the 8.0.4.x update comes to the business customer base.
Please let me know if you have any further questions
Jack
Hi Jack,
thanks for that explanation.
Our endpoints not updating are named
AUPCDXXXX (D-Staff)
AUPCAXXXX (A - Senior management)
AUPCD0001
AUPCD0120
x being number to the workstation on our production floor.
Correct (WOL) is wake on lan. The PC's are scheduled to wake up at a certain time and we have set sweeps to run half hour later without having any user to log in. We have about 90% of endpoints that get updated successfully.
Note to mention: this scheduled task runs at both geographical sites (FJ and AU).
i will try your suggestion and get back to you later on this week. Thanks again for your opinions and suggestions.
thanks for that explanation.
Our endpoints not updating are named
AUPCDXXXX (D-Staff)
AUPCAXXXX (A - Senior management)
AUPCD0001
AUPCD0120
x being number to the workstation on our production floor.
Correct (WOL) is wake on lan. The PC's are scheduled to wake up at a certain time and we have set sweeps to run half hour later without having any user to log in. We have about 90% of endpoints that get updated successfully.
Note to mention: this scheduled task runs at both geographical sites (FJ and AU).
i will try your suggestion and get back to you later on this week. Thanks again for your opinions and suggestions.
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.