Jump to content

mackintire

Members
  • Posts

    23
  • Joined

  • Last visited

About mackintire

  • Rank
    Newbie
    Newbie

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

561 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 package A less desirable option would be to: FIX your deployment scripts to notify an Admin that the package is no longer available and that my selecting YES, the newer replacement package will be used Breaking deployments because you have something newer and better is not acceptable in an enterprise environment. WE are responsible for the software we deploy. Taking packages away is NOT acceptable.
  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 like this that drives me nuts...
  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 allow rules for. A second question is: Also what is the syntax to write an allow rule to ALL IPs? is that 0.0.0.0/1 or is it something else.
  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 it saved as a known/trusted network. If we disable this setting, the system ignores windows (domain firewall profile IS was in effect according to windows before ESET takes it over) and decides that the local network is a new one. Company.local configured as public??? There's no apparent rhyme or reason to this. I deployed this to 20 developers and 6 were locked out on the next restart. All of them are connecting through the same VPN concentrator so the source IP is the same... I ended up logging into 6 machines to change the profile to home/work. This sucks for our traveling developers and us for deployment, as we want everything to work, in house, and give them the choice when connecting at a different location if the network is safe or not. Disabling this setting, gives them the choice and breaks the local network.....until we go into each affected client and manually change the network connection type Enabling this setting, prevents them from having a choice and makes it difficult or impossible for them to work in the field without completely turning off the firewall. (Because all new networks are treated as hostile, "public") My workaround is creating ANOTHER profile with this one difference and manually fixing all the affected machines. Please fix this. If a machine is on the domain, ESET should NOT default to public network when you disable this feature. OR fix the detection for what the state was before this setting is enabled, users should not be locked out by changing this setting, as this setting should be for NEWLY detected networks and not ones that you are already connected to. The network hasn't changed. Or is this feature just broken?
  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 policy to turn features back on. Which I can dump user's into...for a short time to change their settings to what I want...regardless of their choices. (like re-enabling AV protection) The only omission for the above is visibility/notification of compliance to compared to the baseline policy. It's not perfect but it's better than the....so sorry our product cannot do X response, thanks for all the fishes...
  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 feature should be changed back to the way you want. Since you can layer policies you can make one that turns just X feature on, similar to what you suggested. In the meantime, Please give us the ability to re-apply a policy manually. Right now I have users in a group and see no way to re-apply the policy other then to remove them from that group, wait and move them back into that group. This above is a ugly cumbersome workaround. Unfortunately if this doesn't get resolved in the next 6 months, I'm afraid your going to lose us as a client. We have 200+ licenses presently. Best Regards, Mackintire
  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 cranky ones...often cranky in a totally different way" [a week min] Official Beta [15 additional Developers] a week min Deploy out to a different department every 2-3 days if no issues are detected (8 departments) After all departments have been updated, update Senior Management machines The fastest full company deploy possible on the above schedule is 2 months. If any issues arise all deployments stop until the issue has been resolved. With 6.2 I never made it into alpha deployment. I think we have 6 machines in the console.
×
×
  • Create New...