Jump to content

mackintire

Members
  • Content Count

    23
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

486 profile views
  1. So I get a call that ESET smart security deployments are no longer working. I check the logs and the package is no longer available. I ended up rebuilding all 5 of our deployment tasks to use the newer clients.... but I have no clue if they will break our software. So now I have to explain that we have limited choices if we want to use the current deployment set in ERA. Stupid, Stupid, Stupid ESET. ESET Remote Administrator should: give me the ability to always deploy the latest give me the ability to AUTOMATICALLY keep a local copy of the deployment if it includes a pack
  2. As I understand it, Known networks, bulk subnets into large buckets that filter into zones. The Trusted Zone is one of those zones with predefined rules that match it. Kinda like opening up IE and you have Internet, Trusted, Intranet, and restricted sites. That are akin to Zones.
  3. Another strange issue I was able to resolve, was the firewall rules not consistently being applied when I used the "192.168.1.0/255.255.255.0" syntax "192.168.1.0/24" works even though both syntax are supposed to be valid. I discovered this while trying to debug why communication to a trusted subnet wasn't working. Once placed into interactive mode, the system created a rule that used the 1.1.1.0/24 syntax for the same rule I already had defined as 1.1.1.0/255.255.255.0 So I deleted the new rule and changed the original one to the alternate syntax. It's stuff
  4. So I figured out, it the DNS suffix flag detection works as long as the IP address is being picked up via DHCP. It does not appear to work if you set the IP address static. Lots of undocumented gotcha s in the product still.
  5. So... It appears that each time a policy refresh occurs our user's are getting disconnected from active RDP sessions. I've re-written the RDP rules a bit so maybe this will change with the new rules. If I had a timer that would allow a policy to be refreshed at X each day, this would no longer be an issue. I could split each policy into specific timed refreshes or count down type refreshes. Outside of that... Have you seen this behavior before? The RDP session is not coming from an IP in the trusted Zone. It is coming from another defined zone which I've written RDP
  6. Usually ESET responds fairly quickly... I'm guessing that they never tested this.... and need to check/test.
  7. The client machines are on the domain. When we disable this setting in policy: "Do not ask for protection type of new networks. Automatically mark new networks as public." The ESET firewall gets stupid 50% of the time and changes the profile to Network #, even though the machine is on the domain and the windows network profile is known by windows labeled "work/company.local" Three choices for windows are public/private/domain. Basically if we leave the setting enabled, the system correctly identifies or defaults our network as being safe possibly because we also have
  8. Not being satisfied by the response from ESET... I've discovered I can use a policy as a template to deploy my preferred settings, Then move those users to use another policy that unlocks (no preference) the settings I want them to be able to modify. (The first policy's setting stay) This does NOT prevent the user from changing the unlocked settings or deleting settings, and I have informed our users that if they choose to do so, we may reapply the default preferences again...wiping out there's personal settings to enforce the default policy. I've also created another forced pol
  9. Winter? Wow... I was hoping for end of summer.
  10. Is this accurate even if you don't change the policy? Will the policy reapply itself automatically, will features turn themselves back on?
  11. This is a big issue for us. Please implement a trigger that allows policies to be applied or re-applied based on a scheduled time, or reoccuring time (ever x hours). My supervisor has been asking if we should migrate to kaspersky later this year, due to the obstacles seen in ESET 6. Please convince us that we should stay with ESET. Switching on a feature is 2 levels below what I need, and IF you are using the policy feature is a lazy way of doing what you should without using policy control. Ex. If a feature is off, you should be able to just click apply policy and that
  12. How can I get event driven policy to be re-applied. Ex. We're a development house, so my developers need to be able to disable their AV at times. But some of them forget to turn it back on. So how do I configure policy so that specific setting re-enable on a timer or based on an event??? (like logoff)
  13. I'll be upgrading in March from 6.2 but I wanted to see what you think about the changes/improvements.
  14. The install wizard in 6.2 gets you in 5 minutes where you would normally be on a 6.1 install after 45 without the guesswork.
  15. Fortunately we're an SMB with 200 users. Assuming that 6.3 has enough broken and missing bits fixed and present..... My deployment roll out usually goes as follows: Day 1, Update the remote Adminstration server [wait 24 hours w/no issues] 2-3 test machine [wait 48 hours w/no issues] Myself [a week min] My supervisor [a week min] Deploy out to all new clients or those clients whom have had problems with ESET 5 Official Alpha "The cranky ones" (5 of my most easily agitated software developers) [a week min] 5 users in "Hardware R&D, have a different tool set and use case than the
×
×
  • Create New...