Jump to content

JoeC

Members
  • Posts

    11
  • Joined

  • Last visited

About JoeC

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA
  1. Does the update to 7.3.2039 from 7.3.2036 require a reboot? I held off on the update to .2036 because of the reboot stuff. We're all working remotely and can't risk rebooting and then the the computer not coming back up. Had to wait until someone was going to be in the office, just in case. I'm personally 1700 miles from the office, so it's not exactly convenient when a reboot is required and no one is around.
  2. For those that have upgraded, did any of the clients just shut down and not reboot? That's my concern since no one is in the office to restart them, and I'm physically located 1700 miles from the office. If they're rebooting, I'm okay with that. It's the shutting down that was the problem for me.
  3. Oh, I see what you're saying. Yes, that does work. In my case, I only needed to add a single rule for the RPC Endpoint Mapper. The caveat here is I have to enable the functionality in ESET to evaluation Windows Firewall rules. Otherwise, it won't work. I'll consider this as a possible solution. Not sure I want to touch Windows Firewall rules on every desktop, not knowing which ones have and haven't been hardened. But it's definitely a consideration. Thanks for that!
  4. Thanks for those links. When I turn off the ESET firewall, it works fine, so that's not it. Besides, I have ESET to set to not evaluate Windows Firewall rules. I looked at this possibility early on.
  5. Yes, that's what mine shows. In the troubleshooter, it shows TCP in on port 11146. My understanding of RPC is that first port 135 is connected, and the portmapper gives the calling app the real port number, which is randomized to some large range. In my case, it appears for tasklist, the port is 11146. What's strange is that's not in the normal dynamic port range, either low or high. However, DCOM, which WMI uses, can have pretty much any port between 1024 and 65535. DCOM uses RPC as a transport, so starts out on port 135. At least that's my understanding. I'm no expert in this. I have a suspicion that this is more of a DCOM/WMI issue than an RPC issue, and perhaps previously, we just got lucky that the DCOM port was randomly assigned into the normal RPC range. When I get more time, I may try to limit the DCOM port range on the server I'm using for tasklist, if I can figure out how to do that. Fortunately, it's a sandbox server, so anything I do there won't affect anyone else. So, yeah, I'm reversing my opinion that this is an ESET issue, and thinking it's more of a DCOM/WMI issue on my end.
  6. For Windows Instrument Management (svchost.exe), it simply says "No usable rule found". I'm not certain the port is useful here as I understand RPC Port Mapper uses a random port in a rather large range. Reading up on RPC in ESET, the Allow incoming RPC works with the MS RPC service and the RPC/DCOM service. As I understand it, the initial connection will tell which RPC port to actually use, and then ESET would allow that communication. And it is, for some RPC things, like event viewer, services, remote desktop, etc., but not for tasklist. That's what's baffling me. I know the local service rule for Winmgmt works. It seems like something that shouldn't need to be done if Allow incoming RPC from Trusted Zone is enabled. But if that's what I have to do, so be it. Oh, and thanks for helping me out. I appreciate it.
  7. That was the first thing I did when I got the RPC unavailable error message. And, as I stated, other RPC stuff is working (connecting to another computer in event viewer and services), but not tasklist. It's like tasklist is doing something different, though all of them require RPC to be enabled. Once I create an ESET firewall rule to allow Winmgmt as a local service, it works. But I didn't have to have a rule a few weeks ago when tasklist was working fine. And that's what's confusing me. I noticed this issue about two weeks ago, but have been too busy to address it. My next move is to start looking at Windows updates in the past month or so to see if there's anything in those that may have cause this odd behavior. Or maybe it's an ESET bug. I don't know.
  8. Yes, it is enabled both in the firewall section of the policy, and within ESET on the client. This is why I think it SHOULD be working. I disabled that, then re-enabled that in case it needed to rewrite a setting, but that had no effect.
  9. I spent the better part of the day trying to figure out why only some RPC is blocked and some is not. I can view services on a remote computer, and view event logs. No problem. I cannot run tasklist, though. I get "RPC server is unavailable". This started a couple of weeks ago. Prior to today, I was using the base "Antivirus - Balanced" policy with no modifications. I have used tasklist from time to time over the past couple of months for remote troubleshooting with no trouble. Then suddenly, it started giving that RPC unavailable error. I confirmed the ESET firewall is the culprit. Today, I added our IP range as the Trusted Zone and locked the filtering mode to Automatic (policy-based cut off all network connection, so that was bad) and confirmed that Allow incoming RPC communication in the Trusted Zone is enabled under Allowed Services. That should be working, but it's not. The only way I've gotten it to work is by adding a specific firewall rule for Winmgmt as a local service. However, if I do that from ECA, then Firewall rules are locked (which is not a bad thing, except I don't want to do that at this moment.) Right now, I don't have this rule in place. I will put it in as a last resort, but I think with the Trusted Zone and Allow incoming RPC, it should be working. I'm more concerned that it WAS working a few weeks ago, but now it's not. Is there anything else I should be looking at? We're on Product Version 7.2.2055.0.
  10. I want to add to this that this also happened to me on two computers that I was testing the upgrade on where it immediately performed a scan after the upgrade was completed and promptly shut down the computers. The event log confirmed it was an ESET-initiated shutdown after a scan completion. This is the same as the others have reported, but not a scheduled task, and not on demand, but immediately after the upgrade. Being located 1700 miles away from the office, and during a pandemic where no one else is in the office on a regular basis, it took a full week to get someone in there to turn these computers on. Fortunately, they were computers that were not in use by anyone, so were perfect candidates for this upgrade. Of course, I can't risk updating any other computers to 7.3 until this is confirmed as resolved.
×
×
  • Create New...