Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Location
  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 suspi
  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 serv
  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 l
  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
  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 thes
  • Create New...