I am testing msi deployment as we are about to roll this out to an enterprise client. I am using a "live" test environment of various server and client operating systems. When I first deployed this to a client machine, the webroot icon in the system tray had a warning triangle stating that a scan was required.
Is there anyway to get Webroot to scan immediately anyway, as with 200 + machines to roll this out to, we could do without manual intervention.
TIA
Solved
Behaviour after .msi deployment
Best answer by Shawn
Hello Amanda,
Yes that is correct that a "Learning Scan" is required for the endpoint to register in the management console. This is randomized to reduce network load during the deployment phase but hostnames should start to appear in the console shortly after.
GPO deployment is the recommended method if systems are on a domain. The MSI is easily modified to include any required switches, arguments, parameters and keycode.
The issue that explanoit is referring to is if someone was to install with the executable then run the MSI over the top, you will see two entries for WSA in appwiz.cpl. Running the MSI then the executable does not result in duplicate entries.
I have not had reports of this causing the console to display the incorrect build either, explaniot - if you are seeing this please open a support ticket so this can be escalated to development.
Once having deployed the agents will continue to auto update if enabled without issue.
Thank you Amanda and please let us know if you have any further quesitons,
Shawn T
Webroot Enterprise Support
View originalYes that is correct that a "Learning Scan" is required for the endpoint to register in the management console. This is randomized to reduce network load during the deployment phase but hostnames should start to appear in the console shortly after.
GPO deployment is the recommended method if systems are on a domain. The MSI is easily modified to include any required switches, arguments, parameters and keycode.
The issue that explanoit is referring to is if someone was to install with the executable then run the MSI over the top, you will see two entries for WSA in appwiz.cpl. Running the MSI then the executable does not result in duplicate entries.
I have not had reports of this causing the console to display the incorrect build either, explaniot - if you are seeing this please open a support ticket so this can be escalated to development.
Once having deployed the agents will continue to auto update if enabled without issue.
Thank you Amanda and please let us know if you have any further quesitons,
Shawn T
Webroot Enterprise Support
- OpenText Employee
- 80 replies
Hello Amanada,
Welcome to the Webroot Community!
Can you please tell me a little more about how you are deploying the MSI?
Are you using GPO or the SecureAnywhere Remote Deployment tool?
Thank you,
Shawn Townsend | US Enterprise Support Team Lead
__________________________________
Webroot Inc.
Welcome to the Webroot Community!
Can you please tell me a little more about how you are deploying the MSI?
Are you using GPO or the SecureAnywhere Remote Deployment tool?
Thank you,
Shawn Townsend | US Enterprise Support Team Lead
__________________________________
Webroot Inc.
Hi Shawn,
After having a complete failure using the RDT, I'm using Group Policy.
I followed the Education post about modifying the .msi, but have been dealing with Group Policy for the best part of 5 years anyway.
After having a complete failure using the RDT, I'm using Group Policy.
I followed the Education post about modifying the .msi, but have been dealing with Group Policy for the best part of 5 years anyway.
Although obviously there is more going on with this issue. In terms of issuing a scan to 200+ machines, you can use Your Webroot Portal for this.
Go to "Group Management" and select "All Endpoints". Pick the machines you wish to scan (or hit the box to select them all) and under "Agent Commands" select "Agent" and "Scan". This will trigger all your machines to execute a scan.
Go to "Group Management" and select "All Endpoints". Pick the machines you wish to scan (or hit the box to select them all) and under "Agent Commands" select "Agent" and "Scan". This will trigger all your machines to execute a scan.
Hi Johan,
That's all very well, if the PC's are showing in the console in the first place. It's my understanding that an initial scan is required prior to the PC reporting to the console?
That's all very well, if the PC's are showing in the console in the first place. It's my understanding that an initial scan is required prior to the PC reporting to the console?
Not sure if it's the Actual scan that is the requirement for it, but yes, you are right. It needs to complete it's start up set of actions and that includes an initial scan.
+6If you're going to be using MSI deployment make sure you're fully committed to always using MSI deployment and turn off the auto-update option in the Webroot console.
Make sure you test your ability to update the product between versions.
Make sure you test your ability to update the product between versions.
I have found, that if left alone for a little while, the scan will start and it then reports to the console. That'll teach me for being impatient.
explanoit - I don't understand; surely msi deployment is sufficient to get the product out to client machines, and then have the console update?
explanoit - I don't understand; surely msi deployment is sufficient to get the product out to client machines, and then have the console update?
+6Webroot staff can response, but as of last year the EXE and MSI installation methods are NOT compatible. Self-updating does not update the MSI so the computer will always report the old version. In addition, eventually many computers now have two versions of WSA in Add/Remove programs.
The only way for me to fix this is to eventually develop a script to remove all traces of the MSI-based installation which is not fun or safe.
Using MSI was the worst WSA-related decision I ever made. I'd like to hear from Webroot if they have improved this. It has been a year since this happened.
The only way for me to fix this is to eventually develop a script to remove all traces of the MSI-based installation which is not fun or safe.
Using MSI was the worst WSA-related decision I ever made. I'd like to hear from Webroot if they have improved this. It has been a year since this happened.
So that kinda rules out the remote deployment tool also... and any other method of installing as the download from the console is an .exe
So which method should we be using for multiple client deployment?
So which method should we be using for multiple client deployment?
+6I would wait for a response from Webroot, I should have made that more clear in my post.
I deployed WSA in literally the very first stages of public release. Much has been changed and improved since then. I have not used MSI or investigated how it currently works. I suspect they've fixed it since so many businesses rely on that deployment method.
I deployed WSA in literally the very first stages of public release. Much has been changed and improved since then. I have not used MSI or investigated how it currently works. I suspect they've fixed it since so many businesses rely on that deployment method.
+6You're welcome! I'm interested to see what they say. Hopefully they don't think I'm crazy if they're never heard of this issue before...
- OpenText Employee
- 80 replies
- Answer
Hello Amanda,
Yes that is correct that a "Learning Scan" is required for the endpoint to register in the management console. This is randomized to reduce network load during the deployment phase but hostnames should start to appear in the console shortly after.
GPO deployment is the recommended method if systems are on a domain. The MSI is easily modified to include any required switches, arguments, parameters and keycode.
The issue that explanoit is referring to is if someone was to install with the executable then run the MSI over the top, you will see two entries for WSA in appwiz.cpl. Running the MSI then the executable does not result in duplicate entries.
I have not had reports of this causing the console to display the incorrect build either, explaniot - if you are seeing this please open a support ticket so this can be escalated to development.
Once having deployed the agents will continue to auto update if enabled without issue.
Thank you Amanda and please let us know if you have any further quesitons,
Shawn T
Webroot Enterprise Support
Yes that is correct that a "Learning Scan" is required for the endpoint to register in the management console. This is randomized to reduce network load during the deployment phase but hostnames should start to appear in the console shortly after.
GPO deployment is the recommended method if systems are on a domain. The MSI is easily modified to include any required switches, arguments, parameters and keycode.
The issue that explanoit is referring to is if someone was to install with the executable then run the MSI over the top, you will see two entries for WSA in appwiz.cpl. Running the MSI then the executable does not result in duplicate entries.
I have not had reports of this causing the console to display the incorrect build either, explaniot - if you are seeing this please open a support ticket so this can be escalated to development.
Once having deployed the agents will continue to auto update if enabled without issue.
Thank you Amanda and please let us know if you have any further quesitons,
Shawn T
Webroot Enterprise Support
Shawn Townsend Webroot Manager, Product Support
We experienced the same issue. We use Dell's KBOX product to deploy software. After seeing the multiple copies of Webroot in add/remove programs, we contacted support and was told they are working on a cleaner update method.
To clean up, we are uninstalling all versions then redeploying through KBOX. We now limit the software distribution to only devices that do not have any version of Webroot installed. After the initial install we let Webroot auto-update. May not be the cleanest deployment but it works for us.
To clean up, we are uninstalling all versions then redeploying through KBOX. We now limit the software distribution to only devices that do not have any version of Webroot installed. After the initial install we let Webroot auto-update. May not be the cleanest deployment but it works for us.
1 person likes this
+6Thanks vehmeier.
Yes, I installed via MSI and allowed self-update. It installed a second version in the add/remove programs and did not update the MSI installation. Very annoying.
Yes, I installed via MSI and allowed self-update. It installed a second version in the add/remove programs and did not update the MSI installation. Very annoying.
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.