Hi, I work at a school in Sweden, we have some 4500 computers in our network. Problem is that we are installing some programs (via Novell Zenworks) Webroot gets in the way.
What we do now is that in a script we uninstall Webroot, install the tricky program (f.ex Client for Novell Network) and then reinstall Webroot.
As there is a so many PC's to handle we can not go to one or another computer to change a setting, or to do it with the web console.
So, instead of completly uninstalling Webroot is it possible to disable it?
/Mats
Answer
Is it possible to temporary disable/enable Webroot from a script?
Best answer by JohnnyS
Hello,
I wanted to inform those interested in this post that we have found a resolution. The following policy setting needs to be disabled in order to allow the patch information to be reported correctly.
Realtime Shield - Scan files when written or modified - OFF
After researching Process Monitor logs from a machine experiencing this issue; the Webroot process WRSA.exe is messing with every change to the data/temp files in the working directory for ZENworks patch manager. Therefor disabling this policy setting makes sense to resolve the issue.
Turning off "Scan file when written or modified" will not affect the protection. This setting is turned off by default in the Recommended Server Defaults policy for performance reasons. Webroot will continue to block, pick up and remove infections from the machines.
Best Regards,
Johnny S.
Webroot Enterprise Support Engineer
I wanted to inform those interested in this post that we have found a resolution. The following policy setting needs to be disabled in order to allow the patch information to be reported correctly.
Realtime Shield - Scan files when written or modified - OFF
After researching Process Monitor logs from a machine experiencing this issue; the Webroot process WRSA.exe is messing with every change to the data/temp files in the working directory for ZENworks patch manager. Therefor disabling this policy setting makes sense to resolve the issue.
Turning off "Scan file when written or modified" will not affect the protection. This setting is turned off by default in the Recommended Server Defaults policy for performance reasons. Webroot will continue to block, pick up and remove infections from the machines.
Best Regards,
Johnny S.
Webroot Enterprise Support Engineer
+56So I checked with the folks here and there isn't. The closest would be to set them to manual management, but you'd still have to disable by hand. Probably the best bet is the uninstall/reinstall route. There is an entry for this in our future feature database, but it hasn't gotten to the level of being implemented yet. If you could contact support and work with them on this, that would help get some awareness of the issue. Having a customer support ticket to attach to the feature reqeust helps :)
Support here.
Support here.
+7- OpenText Employee
One thing that you might do is try to find out what programs are being found as untrusted by the Webroot Agent. You can do that by running a scan on a machine with the new software and then creating a scan log. In the scan log look for files labled {U} Those are unknown and could be causing the agent to delay the install enough that zen times out. You can whitelist these yourself in your console or contact support and we can do it very quickly.
Another thought: Should not such a "common" program like Client for Novell Network be whitelisted long time ago? I´d guess that we have installed the present client more than 10 000 times.
+56It could be a new version that we haven't had the opportunity to see yet.
+56No I mean a newer version of the Novell client.@ wrote:
Naaa, we have had the same problem for the 1 1/2 year we used Webroot...
+6You need to contact Webroot business support directly and send them the logs from a machine where the Novell installation didn't work correctly. There should be no inherent incompatibility, it's likely that the client is touching sensitive parts of the system and WSA is blocking it due to lack of reputation. They'll either advise you which file to whitelist in your admin console or forward it to development and get their feedback.
+56Welcome back explanoit!@ wrote:
You need to contact Webroot business support directly and send them the logs from a machine where the Novell installation didn't work correctly. There should be no inherent incompatibility, it's likely that the client is touching very sensitive parts of the system and WSA is blocking it.
Thanks for helping us with this!
The problem with installation of Novell Client is not that Webroot block any files, but that under installation we get a message something like "File not found". The "missing file" is not missing (different files every time) and by clicking on a "Try again-button" installation continues.
On a single PC if you sit at the desk it is not a big problem, just click and go on, but when installing remotely or over night it does not work.
What we do to get the complete installation to work is that (in the installation script) we uninstall Webroot before installing Novell Client, and at the end of the installation Webroot installs again.
The problem with installation of Novell Client is not that Webroot block any files, but that under installation we get a message something like "File not found". The "missing file" is not missing (different files every time) and by clicking on a "Try again-button" installation continues.
On a single PC if you sit at the desk it is not a big problem, just click and go on, but when installing remotely or over night it does not work.
What we do to get the complete installation to work is that (in the installation script) we uninstall Webroot before installing Novell Client, and at the end of the installation Webroot installs again.
+56Glad to hear you got a workaround - sorry for the hassle of the uninstall/reinstall though.
+6
- OpenText Employee
Hey all,
I am looking for a remote session on a system that can easily reproduce this issue. I understand it won't be easy as it is many times intermittent.
My thoughts are, can we possible use system restore to revert patch changes back for debug testing and keep doing that until we have what we need?
How about a VM that reproduced the issue, can you revert to previous snapshot and reproduce the issue?
Thanks all and please let me know!
I am looking for a remote session on a system that can easily reproduce this issue. I understand it won't be easy as it is many times intermittent.
My thoughts are, can we possible use system restore to revert patch changes back for debug testing and keep doing that until we have what we need?
How about a VM that reproduced the issue, can you revert to previous snapshot and reproduce the issue?
Thanks all and please let me know!
One more piece of information: Before we install this (anything) the installation package is copied to the local disk (C:/TEMP/NC) and from that location the actual installation is done.
In the installation of Novell Client many files are only copied from this location to an other on the drive and it is at that stage we get an error about "file not found".
That is, if Webroot is active...
In the installation of Novell Client many files are only copied from this location to an other on the drive and it is at that stage we get an error about "file not found".
That is, if Webroot is active...
Hey all...New to the forums and webroot...testing it to deploy with my clients. In regards to your situation, why are you copying the files to the temp directory to do the install? Many malicious software execute from the temp file and I would assume it is being blocked by the heuristic functions of the AV.
Did you try running it from a share possibly? Or from the local desktop?
Did you try running it from a share possibly? Or from the local desktop?
+6Making sure @ saw the update
Hi mokester,
We have found that by copying to the local disc and installing "locally" we get a much cleaner process.
But maybe with Novell Client this might work. We have a few programs that still installs from share.
/M
We have found that by copying to the local disc and installing "locally" we get a much cleaner process.
But maybe with Novell Client this might work. We have a few programs that still installs from share.
/M
- OpenText Employee
- Answer
Hello,
I wanted to inform those interested in this post that we have found a resolution. The following policy setting needs to be disabled in order to allow the patch information to be reported correctly.
Realtime Shield - Scan files when written or modified - OFF
After researching Process Monitor logs from a machine experiencing this issue; the Webroot process WRSA.exe is messing with every change to the data/temp files in the working directory for ZENworks patch manager. Therefor disabling this policy setting makes sense to resolve the issue.
Turning off "Scan file when written or modified" will not affect the protection. This setting is turned off by default in the Recommended Server Defaults policy for performance reasons. Webroot will continue to block, pick up and remove infections from the machines.
Best Regards,
Johnny S.
Webroot Enterprise Support Engineer
I wanted to inform those interested in this post that we have found a resolution. The following policy setting needs to be disabled in order to allow the patch information to be reported correctly.
Realtime Shield - Scan files when written or modified - OFF
After researching Process Monitor logs from a machine experiencing this issue; the Webroot process WRSA.exe is messing with every change to the data/temp files in the working directory for ZENworks patch manager. Therefor disabling this policy setting makes sense to resolve the issue.
Turning off "Scan file when written or modified" will not affect the protection. This setting is turned off by default in the Recommended Server Defaults policy for performance reasons. Webroot will continue to block, pick up and remove infections from the machines.
Best Regards,
Johnny S.
Webroot Enterprise Support Engineer
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.